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
[EMAIL PROTECTED]
214.954.1781
-----Original Message-----
[EMAIL PROTECTED]
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: [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).
