把普通表drop掉然后重建查询就很快

ShineCQY

  数据库环境：11.2.0.3 RAC
  一张普通的表drop掉然后重建查询就很快。查询走全表扫描。
附件中是10046事件和AWR报告。希望老大给点儿思路。
需要其他信息我会补充。 uprr_2.html.zip (63.9 KB, 下载次数: 2049)

2013-1-9 17:21 上传

点击文件名下载附件

UPRR1_ora_25977_UPRR2013.trc.zip (24.77 KB, 下载次数: 2020)

2013-1-9 17:21 上传

点击文件名下载附件

ShineCQY

我不知道在oracle中使用CTAS重新创建表，是不是底层的存储结构会改变？会使用列存？不同于insert into ？

ShineCQY

改前的10046 trace 包括执行计划


UPRR1_ora_25977_UPRR2013.trc.zip (24.77 KB, 下载次数: 2025)

2013-1-9 22:17 上传

点击文件名下载附件

修改后的 10046 trace 包括执行计划


uprr1_ora_10046.zip (6.71 KB, 下载次数: 1838)

2013-1-9 22:17 上传

点击文件名下载附件

统计信息：
--after recreate 重新创建后
Statistics
----------------------------------------------------------
          7  recursive calls
          1  db block gets
      13022  consistent gets
      10773  physical reads
          0  redo size
     106622  bytes sent via SQL*Net to client
       1073  bytes received via SQL*Net from client
         52  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        751  rows processed

--after use exits 修改sql后
Statistics
----------------------------------------------------------
          1  recursive calls
          1  db block gets
      13460  consistent gets
        241  physical reads
        116  redo size
     106622  bytes sent via SQL*Net to client
       1073  bytes received via SQL*Net from client
         52  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        751  rows processed

--原始，很慢  ctrl+c 断开
Statistics
----------------------------------------------------------
          1  recursive calls
      15876  db block gets
   32483167  consistent gets
          0  physical reads
          0  redo size
       6421  bytes sent via SQL*Net to client
        545  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         30  rows processed

ShineCQY

SQL> select count(*) from tmp_t_base_account;

  COUNT(*)
----------
    414043


SQL> select count(*) from tmp_account_status;

  COUNT(*)
----------
       954
附件中重新创建表后的10046事件  

Maclean Liu(刘相兵

信息不足，需要 ：

修改前的10046 trace 包括执行计划+　修改后的 10046 trace 包括执行计划

set timing on;
select count(*) from tmp_t_base_account;

select count(*) from tmp_account_status;

ShineCQY

又一次重建了表，重建后 统计信息中一致性读很少，get blocks 为1 ，但是shrink   分析表后。再看下统计信息 发现 一致性读很多，get blocks更多 （上千倍），这样是导致 查询（全表扫描）的原因。 疑问是为什么shrink 或者move 后 性能下降了呢？

ShineCQY

楼上分析的一针见血啊，果然是这样。 我把and s.account_status in ('11', '12')  改为 and exits (select account_status from tmp_account_status where account_status='11' or account_status='12') 后查询速度很快，执行计划中改为  filter     hash join
但是还是不明白为什么，我又把表删除了重建下，执行计划（分析过）和使用and s.account_status in ('11', '12')几乎完全一样，又一次陷入迷茫中...

lianjie1229

1. Rows     Row Source Operation
   
2. -------  ---------------------------------------------------
   
3.     751  NESTED LOOPS  (cr=847142964 pr=699 pw=0 time=1193495938 us cost=108 size=20705 card=101)
   
4. 414043   TABLE ACCESS FULL TMP_T_BASE_ACCOUNT (cr=10833 pr=692 pw=0 time=4077405 us cost=3 size=22656 card=128)
   
5.     751   TABLE ACCESS FULL TMP_ACCOUNT_STATUS (cr=847132131 pr=7 pw=0 time=2374069537 us cost=1 size=28 card=1)
   
6. NESTED LOOPS

复制代码

是嵌套连接，需要看下表重建后的执行计划，可能表的连接方法有问题，各位拍砖吧。