RE: LOCKS - Reading Block Dumps

From: Larry Elkins <elkinsl_at_flash.net>
Date: Tue, 04 Dec 2001 16:27:22 -0800
Message-ID: <F001.003D54C4.20011204161141@fatcity.com>

Riyaj,

Thanks for taking the time to provide this information. After running across a few comments from people talking about the need to dump a block to get at the nitty gritty, I decided it was time to explore this area and learn. You and others have been a great help in this effort.

And the internals class is something I'm interested in. I hope to get around to taking it sometime.

Regards,

Larry G. Elkins
elkinsl_at_flash.net
214.954.1781
-----Original Message-----
Riyaj_Shamsudeen_at_i2.com
Sent: Tuesday, December 04, 2001 4:11 PM To: Multiple recipients of list ORACLE-L

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

--

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). Received on Tue Dec 04 2001 - 18:27:22 CST