Continuing with the example shown in Figure 6-37, suppose the first two transactions (ITLs x01 and x02) commit, making their transactions inactive. The third transaction, ITL x03, has not yet committed. Immediately after the first two transactions commit, the same block dump command, alter system dump datafile 1 block 75847 is issued, with the results shown in Figure 6-38. Notice the flag has changed, and an SCN has been assigned to the transaction.

Figure 6-38. Shown is a data block (1,75847) dumped immediately after the first two transactions committed and the third transaction remaining active. Notice the committed inactive transaction flags have changed from ---- to --U-.

The two flags ---- and --U- are needed because a row involved in an active transaction or even a past active transaction can have a valid ITL entry in its row data. So simply referencing the row data and seeing an ITL entry does not imply the row is currently involved in an active transaction and is therefore locked. To check if the row is locked, a server process must get the ITL reference from the row data and then check the flag in the block's variable ITL area. If the flag is ----, then a server process knows the row is indeed involved in an active transaction and is locked. However, if the flag is --U, a server process knows the row is not locked. Part of the block cleanout process is removing nonactive transaction row data ITL entries, changing their respective ITL entry's in the block's variable portion flag to a status of C---, and consolidating the row data.