DBA手记:System State之Row Cache对象定位解析

在《Oracle DBA手记 3》即将出版之际，我将《Oracle DBA手记 2》上收录的一些文章发布出来，与大家分享。
前文参考：
http://www.eygle.com/archives/2011/05/dbasystem_state_file.html
http://www.eygle.com/archives/2011/05/dbasystem_state_rowcache.html
http://www.eygle.com/archives/2011/05/dbasystem_state_ass109.html

生成数据库出现问题时段的AWR报告，也可以辅助我们确定数据库的相关操作。在以下图示中显示，Top 4
SQL都运行超过3400秒没有完成，第一个正是任务调度：

相关的SQL简要列举如下：

call
dbms_space.auto_space_advisor_job_proc ( )

alter index
"CACI"."IDX_CACI_INV_BLB_DC" modify partition
"P_2010_Q1" shrink space CHECK

而如果你不关心空间建议，则可以取消这个定时任务，避免不比要的麻烦：

execute
dbms_scheduler.disable('AUTO_SPACE_ADVISOR_JOB');

 最后还有一点需要额外说明的是，既然是ROW Cache在DC（Dictionary
Cache）层面产生的竞争，那到底是什么对象呢？如何获得显示的证据呢？

我们再来回顾一下SO对象的以下部分信息：

data=

00000038 00134944 585f4341 43495f49 4e565f42 4c425f44 43000000
00000000

00000000 04000009 505f3230 31305f51 31000000 00000000
00000000 00000000

00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000
00000000 000209ca ffff0000 000209ca 14786e01 020e3239

786e0102 0e323978
6e01020e 32390100 00000000 00000000 00000000 00000000

00000000 00000006

这部分Data信息是什么呢？我们稍微逆向的转换一下。这次动作涉及的SQL是：

alter index
"CACI"."IDX_CACI_INV_BLB_DC" modify partition
"P_2010_Q1" shrink space CHECK

对象是IDX_CACI_INV_BLB_DC索引的P_2010_Q1分区，使用dump函数取一下16进制编码，获得如下输出：

SQL> select
dump('IDX_CACI_INV_BLB_DC',16) from dual;

 DUMP('IDX_CACI_INV_BLB_DC',16)

-----------------------------------------------------------------------

Typ=96 Len=19: 49,44,58,5f,43,41,43,49,5f,49,4e,56,5f,42,4c,42,5f,44,43

SQL> select
dump('P_2010_Q1',16) from dual;

DUMP('P_2010_Q1',16)

----------------------------------------

Typ=96 Len=9: 50,5f,32,30,31,30,5f,51,31

SO对象的Data部分正是指出了需要的对象内容，而当这个对象被排他锁定后，接下来的访问就处于了挂起状态。