Sometimes we may also generate a redo when we perform a select operation, and one of the possible reasons for this is the removal of oracle blocks.
When a block purge is performed, if it is a large transaction, a delayed block purge is performed.
Block purge is to delete the modified data on the block and"Locked"information, i.e., transaction information.
Oracle records a list of modified blocks in the transaction-related commit list, each of which records 20 blocks, and may allocate as many such lists as needed.
There is an upper limit to this block list, which is 10% of the buffer cache size
If the blocks are modified at one time, and the blocks are in memory, the transaction information on the block will be cleared when committing, otherwise, it will not be ignored until the next time the blocks are accessed, and then the transaction information in the block will be cleared, which is called delayed block purging.
Because this select modifies the transaction information of the block, it will generate redo
The following is based on the information on ITPUB and my understanding of the filling of the SCN when the block is cleared, and what happens"The snapshot is too old"Errors.
The next reader of the delayed clearing block will first look up the commit when the undo is recorded according to the rollback information recorded in the block, but the undo segment may have been winded, and the commit SCN cannot be found, but the minimum commit scn can be obtained from the undo segment and the transaction committed must be less than the minimum SCN that still exists in the undo segment.
The oracle then assigns the chunk-cleared transaction a minimum transaction SCN found from the rollback segment.
This is inaccurate, but it is secure and does not affect data access. That's why it's called upper bound and guesses the upper limit of an SCN.
If the read SCN of the delayed cleared block is smaller than the smallest SCN in the detract segment (the undo segment has been wound), then the number cannot be found in the detract segment.
According to this, Oracle has no way to determine the relationship between the SCN of the select and the size of the data block to be purged, so ORA-01555 appears, and the Oracle does not know the data block.
The data is not the data that is required for the query moment.
If the select scn is larger than the smallest scn in the undo segment, then oracle uses the smallest scn as the scn of the transaction to update the itl of the block, thus completing the block purging.