Re: LOCKS - Reading Block Dumps

Larry
        fb: indicates the flags.H means header in this rows. F means First piece of the row. L means last piece of the row. Since both FL are present in here there is no row-chaining.
        lb: lock byte indicates the ITL array index of the transaction that is holding the lock on the row. It is probably one for your test since initrans is 1 for the table. This alone can not determine whether the row is locked or not. This value with the status flag of the transaction from the ITL determines the status of the row lock itself.
        cc: indicates # of columns and there are 3 columns in this table.

Block header portion works differently.

        scn/fsc: fsc stands for free space credit. fsc is actually have two components. Scn component is copied in to fsc during block cleanout operations. The change that you are seeing is due to fast commit cleanout.  
        Flag indicates the status of the transaction itself. C indicates the commit SCN is copied and U indicates the SCN copied is the upper bound rather than commit SCN itself.

        So, whether to determine a row is locked or not, here is the logic:
                1. Check the lock byte in the row header.
                2.  If the lock byte is non zero, then go to ITL array entry for that lock byte and check the status of the transaction in the ITL. 0x01 will take to the first member of the ITL array.
                3.  If the status is C or U then the transaction is committed, then clean up the lock bytes and modify for the current transaction.
                4.  If the status is null then go to the rollback segment header and try to determine the status of the transaction.
                5.  If the wrap# of the transaction table entry for the transaction and the transaction in the ITL are the same, then the transaction table entry is not overwritten. Depending upon the transaction status here, enqueue for the resource. If the transaction is committed, then use take the commit SCN of the transaction and update the scn/fsc field. Set the flag to 'C'.
                6. If the wrap# of the transaction table entry is higher then the ITL entry wrap#, then use the control SCN to populate the  scn/fsc field and set the flag to 'U'.
                7. Continue...        
        Hope this helps to understand the concepts..Of course, the internal classes is probably better place to get more information.
        All right, there may be minor mistakes with this logic, but you get the point, I didn't spend enough time to review this..But the logic is good.
       

Thanks
Riyaj "Re-yas" Shamsudeen
Certified Oracle DBA
i2 technologies   www.i2.com

"Larry Elkins" <elkinsl_at_flash.net>
Sent by: root_at_fatcity.com
12/04/01 11:36 AM
Please respond to ORACLE-L

       
        To:        Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        cc:        
        Subject:        LOCKS - Reading Block Dumps

Listers,

Playing around with dumping a block to determine rows which are locked. I did an update to a single row in a table and did not commit. I dumped the block. Here is the relevant info:

tab 0, row 0, @0x19c3
tl: 21 fb: --H-FL-- lb: 0x1 cc: 3

After rolling back and dumping the block, I get the following:

tab 0, row 0, @0x1977
tl: 27 fb: --H-FL-- lb: 0x0 cc: 3

It looks like to me that the "lb:" value indicates the presence of a lock on the row -- 0x1 for a lock, 0x0 for not locked. I've been googling for a bit, searching usenet, and the typical web sites for info on this and came up empty handed. So, can anyone confirm this idea of lb: 0x0 meaning no lock and 0x1 meaning the row is locked?

Also, there seems to be some differences in the block header info related to ITL's:

Lock present:

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc 0x01   xid:  0x0002.018.00000482    uba: 0x0080c4a8.0340.0e  ----    1  fsc 0x0006.00000000

No lock:

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc 0x01   xid:  0x0001.037.000004c3    uba: 0x00800107.06dc.31  C---    0  scn 0x0000.00594c1b

Can I assume that Scn/Fsc value of non-zero means there is a lock? And last but not least, any good info anywhere on reading block dumps?

Regards,

Larry G. Elkins
elkinsl_at_flash.net
214.954.1781

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Larry Elkins
  INET: elkinsl_at_flash.net

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).