RE: 20 blocks on modified block list

From: Yong Huang <yong321_at_yahoo.com>
Date: Thu, 4 Feb 2010 13:34:49 -0800 (PST)
Message-ID: <457621.69682.qm_at_web80605.mail.mud.yahoo.com>

Earlier I asked how to interpret the rdba (relative data block address) in the 10g process state dump, because dbms_utility.data_block_address_file would return a way too big file#. Timothy Hopkins emailed me a way to partially "decode" it (take 0x1010015c8 as an example):

SQL> variable rba_hex varchar2(9)
SQL> exec :rba_hex := '1010015C8'

PL/SQL procedure successfully completed.

SQL> select bitand(to_number(:rba_hex,'XXXXXXXXX'),to_number('FFFFFFFF00000000','XXXXXXXXXXXXXXXX')) / power(2,32) UNKNOWN#

  2 ,bitand(to_number(:rba_hex,'XXXXXXXXX'),to_number('FFC00000','XXXXXXXX')) / power(2,22) RFILE#   3 ,bitand(to_number(:rba_hex,'XXXXXXXXX'),to_number('3FFFFF','XXXXXX')) BLOCK#   4 from dual;

    UNKNOWN# RFILE# BLOCK#
------------ ------------ ------------
1.0039075483 4 5576

The rfile# and block# are very correct, which I verified. But the first part is unknown.

After further test, I observed that these process state dump rdba's differ from the regular rdba's (from simple block dump) in a simple way: prepended with 1 to the regular rdba in hex. For instance, if I

alter system dump datafile 4 block 5576;

I have in the trace:

buffer tsn: 4 rdba: 0x010015c8 (4/5576)

This rule does not seem to change with different tablespace number.

Thanks Tim for your initial test.

Yong Huang

-----Original Message-----

Rich posted this message six months ago
http://www.freelists.org/post/oracle-l/expdp-and-ORA01555,10

• begin quote ***** From Tom Kyte - page 314 of his book "Expert Oracle Database Architecture": "Oracle will keep lists of blocks we have modified; each of these lists is 20 blocks long. Oracle will allocate as many of these lists as it needs up to 10 percent of the block buffer cache size."
• end quote *****

We tried to find these 20 blocks on the modified block list. Today I came across this old note
http://www.fors.com/velpuri2/Oracle%20block%20structure/Delayedcleanout

• begin quote ***** Every time a transaction changes a data block, a "block entry state object" has to be added to the commit list of the transaction.... These block entries are grouped by 20 : the allocation unit is 20.... Once the number of entries used by the transaction reaches 10% of the <Parameter:DB_BLOCK_BUFFERS> subsequent blocks changed by the transaction will not be recorded in the list (hence no fast cleanout on these blocks)"
• end quote *****

Cross-referencing other postings on the Internet, I believe either that state object is an old name or it's spelled wrong. It should be "block list state object" ("bk list" for short in some Oracle dumps). To view the actual list(s), all you need to do is dump the process state (or system state). For example, dump your own session's process state:

delete from big_table;
alter session set events 'immediate trace name PROCESSSTATE level 10';

The trace file has

        SO: 0x15ab34a10, type: 39, owner: 0x15ad5f0b0, flag: -/-/-/0x00
        (List of Blocks) next index = 20
        index   itli   buffer hint   rdba       savepoint
        -----------------------------------------------------------
            0      2   0x9ff78a98    0x1010015c8   0x2b41
            1      2   0x9ffed678    0x1010015d1   0x2d06
...
           19      1   0xe7fb55b8    0x101002665   0x539b
        -----------------------------------------------------------

Somebody can help me figure out how to "decode" the rdba in 10g. Using the functions in dbms_utility I get way too big file number. 9i doesn't have this problem. My table is completely in file# 4.

Yong Huang       

--
http://www.freelists.org/webpage/oracle-l

Received on Thu Feb 04 2010 - 15:34:49 CST