[20120214]异常数据导致执行计划改变.txt

今天上午,用户反应一条sql执行有点慢。我检查发现,原来使用索引的语句现在变成了全表扫描,而且昨晚oracle数据库自动分析过这个表。

语句很复杂,抽取有问题的部分:

SELECT *
  FROM med_operation_schedule a
 WHERE (       scheduled_date_time >= TO_DATE ('2012-02-15 00:00', 'yyyy-mm-dd hh24:mi')
           AND scheduled_date_time         OR scheduled_date_time IS NULL
        OR NVL (emergency_indicator, 0) = 1 AND scheduled_date_time > TRUNC (SYSDATE, 'dd')
       )
执行计划是全表扫描。把那个or单独拆开来分析,发现这个条件走的是全表扫描NVL (emergency_indicator, 0) = 1 AND scheduled_date_time > TRUNC (SYSDATE, 'dd')。奇怪!这个条件scheduled_date_time > TRUNC (SYSDATE, 'dd')的记录不会很多。

select * from med_operation_schedule a where a.scheduled_date_time > TRUNC (SYSDATE, 'dd');

这才发现原来里面存在一条scheduled_date_time='5011-7-17 16:30:00' 异常记录。

这样造成优化器认为大于TRUNC (SYSDATE, 'dd')的记录不会很多,执行计划选择全表扫描。

解决方法:
1.要求操作员更正数据,再分析表,这个不能保证以后不再出现,或者程序要做必要的检查,不能输入这样的日期。
2.在该字段建立直方图,不过10g很麻烦,后台的分析Method_Opt=> 'FOR ALL COLUMNS SIZE AUTO ',这样可能下一次分析直方图又会被取消。看来自己该修改自动分析的缺省参数为Method_Opt=> 'FOR ALL COLUMNS SIZE REPEAT'
3.我实在不想跟他们提,我选择的方法是修改统计信息。

方法如下:
1.取出表定义:
exp system/xxxx@yyyy tables=(zzzz.med_operation_schedule) rows=N file=med.dmp

2.过滤出脚本:[注意要加-3参数,具体看man strings文档,不然会丢失信息]
strings -3 med.dmp > med.txt

3.找到如下内容:

DECLARE  SREC DBMS_STATS.STATREC; BEGIN SREC.MINVAL := '303231363032'; SREC.MAXVAL := '303231363036'; SREC.EAVS := 0; SREC.CHVALS := NULL; #
SREC.NOVALS := DBMS_STATS.NUMARRAY(I
250248268640273000000000000000000000,250248268640292000000000000000000000&
); SREC.BKVALS := DBMS_STATS.NUMARRAY(
0,1
); SREC.EPC := 2; DBMS_STATS.SET_COLUMN_STATS(NULL,'"MED_OPERATION_SCHEDULE"','"OPERATING_ROOM"', NULL ,NULL,NULL,4,.25,0,srec,7,6); END;

--删除一些怪异的字符,重新排版,这样可以很好检查是否写错!
DECLARE
   srec   DBMS_STATS.statrec;
BEGIN
   srec.minval := '786E0B1E090101';
   srec.maxval := '966F0711111F01';
   srec.eavs := 0;
   srec.chvals := NULL;
   srec.novals := DBMS_STATS.numarray (2455531.33333333, 3551487.6875);
   srec.bkvals := DBMS_STATS.numarray (0,1);
   srec.epc := 2;
   DBMS_STATS.set_column_stats (NULL,
                                '"MED_OPERATION_SCHEDULE"',
                                '"SCHEDULED_DATE_TIME"',
                                NULL,
                                NULL,
                                NULL,
                                7555,
                                .000132362673726009,
                                0,
                                srec,
                                8,
                                6
                               );
END;

4.最大最小如何修改呢?需要了解srec.minval以及srec.maxval转换。google找到如下链接:
http://mwidlake.wordpress.com/2010/02/24/update-to-decoding-high-and-low-values/

SELECT column_name, data_type, low_value,high_value, density,rtrim(
               to_char(100*(to_number(substr(low_value,1,2),'XX')-100)
                      + (to_number(substr(low_value,3,2),'XX')-100),'fm0000')||'-'||
               to_char(to_number(substr(low_value,5,2),'XX'),'fm00')||'-'||
               to_char(to_number(substr(low_value,7,2),'XX'),'fm00')||' '||
               to_char(to_number(substr(low_value,9,2),'XX')-1,'fm00')||':'||
               to_char(to_number(substr(low_value,11,2),'XX')-1,'fm00')||':'||
               to_char(to_number(substr(low_value,13,2),'XX')-1,'fm00')) l,
               rtrim(
               to_char(100*(to_number(substr(high_value,1,2),'XX')-100)
                      + (to_number(substr(high_value,3,2),'XX')-100),'fm0000')||'-'||
               to_char(to_number(substr(high_value,5,2),'XX'),'fm00')||'-'||
               to_char(to_number(substr(high_value,7,2),'XX'),'fm00')||' '||
               to_char(to_number(substr(high_value,9,2),'XX')-1,'fm00')||':'||
               to_char(to_number(substr(high_value,11,2),'XX')-1,'fm00')||':'||
               to_char(to_number(substr(high_value,13,2),'XX')-1,'fm00')) h
  FROM dba_tab_cols
 WHERE table_name = 'MED_OPERATION_SCHEDULE' AND column_name = 'SCHEDULED_DATE_TIME'

COLUMN_NAME,DATA_TYPE,LOW_VALUE,HIGH_VALUE,DENSITY,L,H
SCHEDULED_DATE_TIME,DATE,786E0B1E090101,966F0711111F01,0.000132362673726009,2010-11-30 08:00:00,5011-07-17 16:30:00,

--比较麻烦。放弃这样算的方法!

5.采用建立一个表的方法,在测试库建立:
export NLS_DATE_FORMAT="YYYY-MM-DD HH24:MI:SS"

SQL> create table t(vd date);
Table created.

SQL> insert into t values('2010-11-30 08:00:00');
1 row created.

SQL> insert into t values('2012-2-15 18:00:00');
1 row created.

SQL> commit;
Commit complete.

SQL> exec dbms_stats.gather_table_stats(ownname=>user, tabname=> 't', cascade=> true, estimate_percent=> null, method_opt=> 'FOR ALL COLUMNS SIZE 1');
PL/SQL procedure successfully completed.

SQL> column column_name format a10
SQL> column data_type format a10
SQL> column lower_value format a20
SQL> column high_value format a20
SQL> SELECT column_name, data_type, low_value, high_value, density   FROM dba_tab_cols WHERE table_name = 'T' AND column_name = 'VD';
COLUMN_NAM DATA_TYPE  LOW_VALUE                                                        HIGH_VALUE              DENSITY
---------- ---------- ---------------------------------------------------------------- -------------------- ----------
VD         DATE       786E0B1E090101                                                   7870020F130101               .5

HIGH_VALUE=7870020F130101

这个如何修改呢?srec.novals := DBMS_STATS.numarray (2455531.33333333, 3551487.6875);
还是使用emp的方法(略),与上面相同:

SREC.NOVALS := DBMS_STATS.NUMARRAY(2455531.33333333,2455973.75)

最后修改如下:

DECLARE
   srec   DBMS_STATS.statrec;
BEGIN
   srec.minval := '786E0B1E090101';
   srec.maxval := '7870020F130101';
   srec.eavs := 0;
   srec.chvals := NULL;
--   srec.novals := DBMS_STATS.numarray (2455531.33333333, 3551487.6875);
   SREC.NOVALS := DBMS_STATS.NUMARRAY(2455531.33333333,2455973.75);
   srec.bkvals := DBMS_STATS.numarray (0,1);
   srec.epc := 2;
   DBMS_STATS.set_column_stats (NULL,
                                '"MED_OPERATION_SCHEDULE"',
                                '"SCHEDULED_DATE_TIME"',
                                NULL,
                                NULL,
                                NULL,
                                7555,
                                .000132362673726009,
                                0,
                                srec,
                                8,
                                6
                               );
END;

6.在测试上面的sql语句,发现可以使用索引了。只不过加了bitmap convert+bitmap or操作。

7.锁定以后不分析表。
BEGIN
  SYS.DBMS_STATS.LOCK_TABLE_STATS (
      OwnName        => 'MEDSURGERY'
     ,TabName        => 'MED_OPERATION_SCHEDULE');
END;
/

整个优化完成!

8.BTW最终没有选择这样的方式,我还是建立了直方图。仅仅是为了学习!

9.补充学习:
关于SREC.NOVALS := DBMS_STATS.NUMARRAY(2455531.33333333,2455973.75);里面的数字,表示的是Julian format, ie number of days since 1st Jan 4712BC.
http://mwidlake.wordpress.com/2010/02/06/format-of-date-histograms/

SQL> select 2455973.75+to_date(1,'J')-1 from dual;

2455973.75+TO_DATE
-------------------
2012-02-15 18:00:00

SQL>  select TO_DATE(TRUNC(2455973.75),'J')+(2455973.75-TRUNC(2455973.75)) from dual;
TO_DATE(TRUNC(24559
-------------------
2012-02-15 18:00:00

反过来呢?如果知道日期如何转换呢?'J'仅仅取到整数部分。修改如下:

SQL> select to_char(to_date('2012-02-15 18:00:00','YYYY-MM-DD HH24:MI:SS') ,'J')+to_date('2012-02-15 18:00:00','YYYY-MM-DD HH24:MI:SS')
-trunc(to_date('2012-02-15 18:00:00','YYYY-MM-DD HH24:MI:SS')) x from dual
SQL> /
         X
----------
2455973.75

时间: 2024-09-18 17:04:51

[20120214]异常数据导致执行计划改变.txt的相关文章

[20120915]10046事件与执行计划改变.txt

    使用10046事件来跟踪解决oracle的许多问题,是非常常用的手段,但是实际上可能出现跟踪的sql执行计划与原来不同的情况,自己应该引起注意. 测试如下: 1.测试环境建立: SQL> select * from v$version ; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition

oracle 执行计划改变导致数据库负载过高解决办法

数据库主机负载 这里明显表现系统load 偏高,而且还在上升中:top的进程中,占用cpu都计划100% top - 16:25:39 up 123 days,  1:42,  4 users,  load average: 46.19, 45.08, 43.93 Tasks: 1469 total,  28 running, 1439 sleeping,   0 stopped,   2 zombie Cpu(s): 45.9%us,  1.1%sy,  0.0%ni, 47.1%id,  5

统计信息不准确导致执行计划走了笛卡尔积

统计信息不准确导致执行计划走了笛卡尔积   昨天有事没有上班,今天早上来查看系统的时候发现了很多笛卡尔积的sql,而且一直在跑,已经运行了10多个小时了,觉得这个比较典型,这里记录一下:   SELECT a.ELAPSED_TIME 已运行时间,a.MONITOR_TYPES,a.SQL_ID,a.SQL_TEXT FROM XT_SQL_RUBBISH_MONITOR_LHR a WHERE a.MONITOR_TYPES = '笛卡尔积监控' and a.ID>=45150 ORDER B

[20131121]奇怪的执行计划变化.txt

[20131121]奇怪的执行计划变化.txt SCOTT@test> @verBANNER--------------------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production create table t pctfree 99 as select rownum id,l

oracle11g中 connect by 语句执行计划改变

从10.2.0.3升级到11.2.0.4的朋友,如果细心会发现,以下sql在11.2.0.4中执行效率变低(该sql主要是获取连接用户获取权限信息) select privilege#,level from sysauth$ connect by grantee#=prior privilege# and privilege#>0 start with grantee#=:1 and privilege#>0 如果你接触是Oracle版本比较多,而且还比较细心,你可能会进一步发现在11.2.0

[20121212]谨慎使用set autotrace traceonly查看执行计划[补充].txt

使用toad自带sqlmonitor,toad10以上版本现在叫sqltrace. 12:00:24 SQL> set autotrace traceonly ;12:01:23 SQL> select * from t2 where id=45; 10000 rows selected. Execution Plan----------------------------------------------------------Plan hash value: 1513984157 ---

批量删除数据后, 未释放empty索引页导致mergejoin执行计划变慢 case - 分析与规避方法

标签 PostgreSQL , merge join , min , max , 优化器 , 索引倾斜 , 垃圾回收 背景 PostgreSQL支持三种JOIN的方法,nestloop, merge, hash. 这三种JOIN方法的差别和原理可以参考 https://www.postgresql.org/docs/devel/static/planner-optimizer.html <PostgreSQL nestloop/hash/merge join讲解> nested loop jo

[20120104]稳定一条sql语句的执行计划.txt

[20120104]稳定一条sql语句的执行计划.txt http://www.itpub.net/thread-1495845-1-1.htmlhttp://space.itpub.net/267265/viewspace-723066 ORACLE8I升级11G R2后,查询系统视图特别慢 我的测试版本:SQL> select * from v$version where rownumBANNER------------------------------------------------

一个执行计划异常变更引发的Oracle性能诊断优化

最近有一个OLTP应用使用的Oracle数据库突然出现性能问题,DBA发现有一些delete语句执行时间骤长,消耗大量系统资源,导致应用响应时间变长积Q.   辅助信息: 应用已经很久未做过更新上线了. 据开发人员反馈,从之前的应用日志看,未出现处理时间逐步变长的现象. 这是一套RAC+DG的环境,11g的版本. 这次突然出现大量执行时间超长的SQL语句,是一条删除语句,delete from table where key1=:1 and key2=:2 and ...(省略此案例不会用到的其