网络通信 频道

广电再出狠招 IPTV前途坎坷

......接上篇

2.2 转储library cache
oracle提供了命令可以对library cache中的内容进行转储。于是我们可以对library cache进行转储,从而对上面所说的library cache的内容进行验证。
ALTER SESSION SET EVENTS 'immediate trace name library_cache level N';
这里的N可以取的值分别为:
1 转储library cache的统计信息
2 转储hash表的汇总信息
4 转储library cache object的基本信息
8 转储library cache object的详细信息
16 转储heap size的信息
32 转储heap的详细信息
在测试之前,我们先创建一个测试表,然后再显示该表的数据。从而在library cache中放入一些数据。
SQL> create table sharedpool_test as select * from dba_objects where rownum<10;
SQL> select object_id,object_name from sharedpool_test;
以level 1转储整个library cache。
SQL> ALTER SESSION SET EVENTS 'immediate trace name library_cache level 1';

    打开跟踪文件可以看到类似这样的信息,这实际就是v$librarycache里记录的信息,只不过v$librarycache中记录的是根据下面的信息合并汇总以后得到的。

namespace gets hit ratio pins hit ratio reloads invalids
-------------- --------- --------- --------- --------- ---------- ----------
CRSR 563 0.815 2717 0.916 15 0
TABL/PRCD/TYPE 403 0.730 568 0.653 0 0
BODY/TYBD 2 0.000 2 0.000 0 0
……………………
    然后,我们分别以level 4、8、16、32分别对library cache进行转储,生成的转储文件分别以4#、8#、16#和32#来表示。
打开4#文件,然后直接查找“select object_id,object_name from sharedpool_test”,因为我们前面说到过,对于SQL语句来说,整个SQL语句的文本就是library cache object的名称。于是,我们可以发现类似下图四所示的内容: 



      图四
    这里的BUCKET 62658就相当于图二中的2号bucket。该bucket上只挂了一个对象,其对象句柄号为6758cdbc。在这个对象句柄里存放了很多信息,这里可以看到该对象的namespace为CRSR,也就是SQL AREA。可以看到该SQL语句的hash值为541cf4c2,将其转换为十进制以后可以直接到v$sql中找到该SQL语句。我们还可以看到很复杂的flags字段,它会包括很多标记,比如RON表示只读(Read Only),SML表示当前句柄尺寸比较小(Small)等。而下面的lwt则表示正在等待lock的对象列表(Lock Waiters),对应图三中的“Lock Waiters”;ltm则表示临时正在持有lock的对象列表(Lock Temporary),对应图三中的“Lock Owners”;pwt则表示正在等待pin的对象列表(Pin Waiters)对应图三中的“Pin Waiters”;ptm则表示临时正在持有pin的对象列表(Pin Temporary),对应图三中的“Pin Owners”。再往下看,可以看到CHILDREN部分,这部分就是前面所说过的子游标的信息了。实际上,指向heap 0的指针也位于这一部分,这个指针也就是6758c840。
 
SQL> select sql_text from v$sql where hash_value=to_number('541cf4c2','xxxxxxxx');
SQL_TEXT
--------------------------------------------------------------------------------
select object_id,object_name from sharedpool_test

     然后,我们打开8#文件,查找6758c840,可以看到如下图五所示的内容。这就是heap 0中所包含的内容。可以看到该heap 0的handle正是6758c840,type为CRSR。还可以看到几个重要的table,这些table都是我们前面介绍过的,包括DEPENDENCIES、ACCESSES、TRANSACTIONS。从前面我们已经知道dependency table记录的是SQL语句所依赖的对象,这里我们可以看到我们的SQL语句依赖一个对象,同时该对象的handle为 675d0d74,很明显,它一定指向sharedpool_test表。同时,我们可以看到transaction table所记录的oracle底层解析的对象的handle也是675d0d74,它与dependency table所记录的对象是一样的,说明这个表是实实在在的表,而不是一个同名词。
 
  


                 图五
    于是我们继续在8#文件里查找675d0d74,也就是找到library cache中记录SQL所引用的对象的部分。
我们可以看到类似下图六所示的内容。从name列中可以看到,该对象正是sharedpool_test表,同时该表所在的schema为COST。而且从type为TABL也可以看到,对象sharedpool_test是一个表。 

    

     图六
    我们再次回到图五,也就是记录heap 0的部分。我们可以看到最后一部分是DATA BLOCKS,从我们前面介绍过的内容可以知道这部分的记录指向了其他的heap内存块。我们从data#列上可以知道,该SQL存在两个相关的heap,编号为0和6。我们知道,heap 0存放了SQL语句本身所涉及到的对象以及若干种表等的信息,而heap 6则存放了SQL语句的文本、执行计划等。于是,我们可以到32#文件中查找6758c7d0(heap 0)和67587c34(heap 6),如下图七所示。我们同时可以看到owner的值,实际上这正是在图五中的object的代号。同时从heap的name处也可以看到,heap 0为library cache,而heap 6为sql area,这也说明了这两个不同的heap所存放的不同内容。 

    


    图七

0
相关文章