20 blocks on modified block list

From: Yong Huang <yong321_at_yahoo.com>
Date: Tue, 2 Feb 2010 14:39:27 -0800 (PST)
Message-ID: <205492.12874.qm_at_web80606.mail.mud.yahoo.com>



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;
--Note trace name has to be uppercase in 10g 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 Tue Feb 02 2010 - 16:39:27 CST

Original text of this message