码迷,mamicode.com
首页 > 数据库 > 详细

一次被Oracle全局临时表坑的个人心得

时间:2014-10-15 13:49:00      阅读:296      评论:0      收藏:0      [点我收藏+]

标签:style   使用   ar   sp   数据   on   问题   amp   时间   

【e良师益友网】使用Oracle开发的时候很多时候遇到一些你意想不到的问题,往往在于细节方面出现了不可回避的错误,下面分享一个难忘的事件,这次中表明基础方面的知识真的很重要

那 是凌晨4点多钟,在客户现场的负责人打电话给我,说很奇怪,下载功能时快时慢。此下载功能非常复杂,之前一直是我优化,在半梦半醒中打开电脑,通过远程看 着现场同事在PL/SQL developer中操作。执行同一条SQL,时快时慢,快的时候大概0.6s,慢的时候超过1分钟。

这条SQL有调用一个函数,功能是动态生成接近200条查询语句,SQL中都是有绑定变量的。是现场的测试环境,刚刚部署,心想应该不是数据库负载所致。

1、抓取数据库AWR报告,完全没有压力,数据库服务器配置都是杠杠的。此刻心里有点乱,头一次遇到这种问题。现场9点钟要跟客户演示,此时已经快5点钟了。

2、神器出场,打算用10046 trace定位到到底是那条SQL有问题,trace了多次,只有一次是慢的。期间也有插曲,现场不太会用sqlplus,交互化了很多时间。从众多的SQL中抽丝剥茧,终于定位到SQL,对比是:

SELECT DISTINCT D.ID, D.TABLE_NAME, DCT.COLUMN_NAME, GG.DATA_TYPE,
GG.TECHPARAM_NAME,DCT.SORT_NO FROM GG_CLASSIFY_TECHPARAM DCT, GG_TECHPARAM
GG, GG_CLASSIFY D, REL_OID_CLASSIFY T WHERE DCT.TECHPARAM_ID = GG.ID AND
D.ID = DCT.CLASSIFY_ID AND T.CLASSIFY_ID = D.ID
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 61.00 61.04 0 25968917 0 156
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 61.00 61.04 0 25968917 0 156

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.80 0.81 0 32461 0 156
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.80 0.81 0 32461 0 156

3、分析问题,第一感觉是SQL逻辑是否有问题,可惜10046里面没有trace到执行计划,不过看逻辑读,慢的那次应该是产生了笛卡尔积。经过简单的检查,SQL逻辑没有问题,人的第一感觉不一定靠谱。

4、 我在想是什么导致执行计划不准呢,猛然想起REL_OID_CLASSIFY是全局临时表,快速的想到一种可能,REL_OID_CLASSIFY的统计 信息不准导致,通过user_tables查看这张表是没有统计信息的。那就是每次执行都动态采集啰,在Oracle11g中执行autotrace,发 现level=2,我想试试把动态采样的级别,说干就干。

SELECT /*+ dynamic_sampling(T 10) */DISTINCT D.ID, D.TABLE_NAME, DCT.COLUMN_NAME, GG.DATA_TYPE,
GG.TECHPARAM_NAME,DCT.SORT_NO FROM GG_CLASSIFY_TECHPARAM DCT, GG_TECHPARAM
GG, GG_CLASSIFY D, REL_OID_CLASSIFY T WHERE DCT.TECHPARAM_ID = GG.ID AND
D.ID = DCT.CLASSIFY_ID AND T.CLASSIFY_ID = D.ID;

发给开发人员,修改相关函数。增量后,多次测试后发现问题解决了。此时已经快7点了,天已经大亮,我有点倦意,但无法再次入睡。

个人对于这事件的心得总结:对于这次临时表的问题,我想问题在于采样率低了以后造成的恶果。对于全局临时表要注意两点,一是要锁定临时表收集统计信息的功能,因为你收集的统计信息肯定是错的;二是使用它时最好是使用动态采用。学习知识,基础很重要。

一次被Oracle全局临时表坑的个人心得

标签:style   使用   ar   sp   数据   on   问题   amp   时间   

原文地址:http://www.cnblogs.com/yuguotianqing/p/4025813.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!