Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

0

积分

0

好友

5

主题
1#
发表于 2015-4-3 00:13:49 | 查看: 2936| 回复: 2
如图所示
这个sql遇到严重的latch:cache buffer chains,等待的时间对应Concurrency Wait Time 。
为什么并发等待的时间这么少,+cpu time+io wait+cluster wait也远小于elapsed time,
请问刘大这怎么理解?

QQ图片20150403000559.png (23.66 KB, 下载次数: 224)

QQ图片20150403000559.png

2#
发表于 2015-4-3 00:28:01
环境是10g,绑定变量,有直方图,轻微的数据倾斜。
执行计划中的索引访问路径是最优的,同时也能适用于重复值最高的字段值。
表总数500w左右,字段重复值最高的行数11w左右,大部分字段重复值是1。
数据倾斜情况如下:
SQL>select num,count(*) from
(SELECT COUNT(*) num,PARENTDIMNUMBER2DIMNUMBER FROM CRAMER.DIMNUMBER group by PARENTDIMNUMBER2DIMNUMBER )
group by num order by 1 desc;
       NUM   COUNT(*)
---------- ----------
   3469555          1
    110964          1
     66361          1
     65923          1
     65896          1
     65892          1
     65824          1
     65698          1
     65676          1
     65663          1
     65658          1
     65606          1
     65535          1
     65534          6
     65533          1
     21552          1
     18310          1
..........省略
        21        111
        20        176
        19        143
        18        244
        17        224
        16        601
        15        706
        14       2791
        13        449
        12        367
        11        382
        10        703
         9        507
         8       1057
         7       1242
         6       6182
         5       1501
         4       3430
         3       3689
         2      53682
         1     157564

执行计划如下:
--------------------------------------------------------------------------------------------
| Id  | Operation                     | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |            |       |       |     6 (100)|          |
|   1 |  SORT AGGREGATE               |            |     1 |    19 |            |          |
|*  2 |   FILTER                      |            |       |       |            |          |
|*  3 |    TABLE ACCESS BY INDEX ROWID| DIMNUMBER  |     1 |    19 |     6   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | DN_DN_FK_I |    12 |       |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(:B5+:B4>=:B5+:B4)
   3 - filter((INTERNAL_FUNCTION("DIMNUMBER2DIMNUMBERTYPE") AND
              TO_NUMBER("VALUEFROM")<=:B5+:B4 AND TO_NUMBER("VALUEFROM")>=:B5+:B4))
   4 - access("PARENTDIMNUMBER2DIMNUMBER"=:B3)

单列索引,索引段的块数并不多,但从awrsqrpt来看,平均块buffer_gets,远大于理论值。
SQL>select blocks ,name,lf_rows,lf_blks,br_rows,br_blks,pct_used from index_stats;

    BLOCKS NAME                              LF_ROWS    LF_BLKS    BR_ROWS    BR_BLKS   PCT_USED
---------- ------------------------------ ---------- ---------- ---------- ---------- ----------
    12288 DN_DN_FK_I                        3115915      11609      11608         48        103

考虑到复合索引也无法降低选择率,于是增大索引的pctfree,尽量打散数据。
但由于应用端没有再执行这些sql,还无法观测到效果。

----------------------------------------------
这个帖子主要的主题是对逻辑读和时间花销的统计方面感到不解。

回复 只看该作者 道具 举报

3#
发表于 2015-4-3 12:36:13
补充:关于数据分布重复行数3469555的字段值为null,所以不考虑
       NUM   COUNT(*)
---------- ----------
   3469555          1

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-5-20 12:17 , Processed in 0.050799 second(s), 23 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569