Oracle Restore Internal principle: Reset Log Resetlogs

The Reset log option is used for the first time when the database is opened after the following situations:

Not fully restored

Recovery based on backup control files

CREATE Controlfile ... Resetlogs

The primary role of the reset log is to discard redo logs that are not used in incomplete recovery and to ensure that subsequent restores are no longer needed. To do this, the Reset log option will discard all online and archived logs. The side effect is that all previous backups are useless for future recoveries.

The Redo Log option also initializes content about the online log and redo threads in the control file, clears the contents of the currently existing online redo log, creates if the online log file does not exist, and resets the log number of all threads.

8.1 Vague files

The most important thing to do when you open a database in the Redo Log option is to verify that all data files are restored to the same point in time. This ensures that all changes to the single redo log are automatically applied. This is also important for other reasons of consistency. If all of the thread redo logs are applied to all the online data files, you can say that the database is consistent.

If you do not have a full recovery, it is possible that a file is not recovered from a backup that is old enough. Typically this can be found by detecting inconsistencies in the head of the data file with other data files (the exception is offline files and read-only files).

Another possibility is that the file is "vague". It may contain changes that exceed the SCN of its checkpoint. The previous chapters know that the data file header maintains the following "Blur state bits" to determine whether the data file is "fuzzy":

Online blur bit (see 3.5,6.7.2)

Hot backup blur bit (see 4,6.7.3)

Medium restoration Fuzzy bit (see 6.7.1)

When you open a database in a reset log after an incomplete restore, if the blur of the online data file is set, the failure opens.

A redo log record is written at the end of a hot or crash recovery to enable media recovery to determine when these ambiguous bits can be cleared. Redo logs will complain if these blur bits have not been cleared.

When there is a checkpoint in the data file that ends the recovery the SCN is inconsistent with the checkpoint SCN (reset log scn, see 8.2) In other data files, and the reset log will complain unless it is the following:

1. A data file recovery to a specific weighting the SCN is acceptable if it has no redo logs between the two. For example, the data file is read-only or offline, and the offline scope overrides the SCN and reset SCN at the end of the restore. In this case, the redo log allows the data file to be set offline.

2. A data file does the SCN portion of the checkpoint to do SCN later, provided that its creation SCN (allocated at the time of creating the data file, saved in the file header) shows that it was created after the SCN was reset. Checking the data dictionary and the control file while you redo the log discovers that the data file does not exist in the data dictionary but is present in the control file. As a result, it is purged from the control file.

8.2 Resetting the SCN and counter

The Database Information section of the control file records the SCN and the point-in-time of the reset log (collectively reset log data). The log data is reset to uniquely identify the operation to open the database for each redo log, as well as for each data file header and log file header. The Reset log data in the log file cannot be applied to the redo log in the log file if it is inconsistent with the records in the control file. Redo log data in a data file if it is inconsistent with the records in the control file, the data file cannot be accessed or restored unless there are special circumstances (such as the table space where the data file is normally offline or read-only). This ensures that redo logs discarded by the reset log are no longer applied to the database, and that any previous backups are useless for future recoveries. So it's smart to make a backup immediately after you redo the log.

8.3 The impact of reset logs on threads

When the log is reset, each thread's control file record clears the thread to open the tag and sets the thread checkpoint SCN to reset the SCN. So it looks like the thread is shutting down at the reset SCN. The list of enabled threads that is part of the Database Information section of the control file is still available. It is not important at this point which thread is enabled at the end of the restore because the redo log is no longer needed. The log sequence number for all threads is set to 1, and one of the thread's checkpoints is selected as the database checkpoint.