关于ASM下的数据文件分布问题

Yong Huang

What do you mean by "问题已经解决了"? Running time is significantly shorter in Dev? How about buffer gets? Do this in Dev and Prod:

set autotrace on stat
--run the SQL here

Show the consistent gets at the bottom.

How did you check the plan?

Yong Huang

alexanderr

抱歉隔了这几天才回来反馈

我说问题解决了，是指测试库上之前一运行这条语句CPU就彪很高，磁盘100%busy的现象消失了
OEM上做ADDM也没有这条语句需要调整的提示了
整个机器的资源使用处于平稳了，恢复到以前了

我说执行计划没有变是指前后两次在测试库上查看的执行计划都一样
使用explain plan for SQL查看的

做trace的话只能做现在的了，清recyclebin前SQL没有做trace，没法对比了

alexanderr

今天又发现测试库的cpu和硬盘busy有些繁忙
OEM又再次定位到那条语句

我就又purge recyclebin
系统的loading又恢复了正常

我还是不明白这个跟recyclebin有什么关系？

flying_warrior

看一下 你这2个执行计划里  关于这一段 就明白了
--------------------------------------------------------------------------------------------------------------------
|* 45 |         HASH JOIN                    |                  |  3130 |   125K|   109   (1)| 00:00:02 |
|  46 |          TABLE ACCESS FULL           | RECYCLEBIN$      |  9391 |   100K|   108   (1)| 00:00:02 |
|* 47 |          TABLE ACCESS BY INDEX ROWID | TS$              |     1 |    30 |     1   (0)| 00:00:01 |
|* 48 |           INDEX UNIQUE SCAN          | I_TS1            |     1 |       |     1   (0)| 00:00:01 |
|* 49 |         FIXED TABLE FIXED INDEX      | X$KTFBUE (ind:1) |     1 |    65 |    17 (100)| 00

alexanderr

明白了
就是因为recyclebin内的数据太多，影响了SQL的效率
那这个就得定期清理recyclebin才能解决这个问题吗？
还有其他办法吗？

Yong Huang

In production, it may be a good idea to set recyclebin parameter to off.

Yong Huang

alexanderr

get it
thx

magic007

主要是recyclebin影响了查询dba_free_space的效率，这是一个普通的问题。要么把recyclebin关闭，要么需要将dba_free_space视图改为9i中的dba_free_space定义。