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" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 12/04/01 11:36 AM
|
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
214.954.1781
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Larry Elkins
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
