Oracle internal recovery principle (reset log RESETLOGS)

The primary role of log resetting is to Discard unused redo logs during Incomplete recovery and ensure that subsequent recovery is not needed. To do this, the reset log option adds all online logs and

The primary role of log resetting is to Discard unused redo logs during Incomplete recovery and ensure that subsequent recovery is not needed. To do this, the reset log option adds all online logs and

The reset log option is used when the database is opened for the first time in the following cases:

1. Incomplete recovery

2. Backup control file-based recovery

3. create controlfile... RESETLOGS

The primary role of log resetting is to Discard unused redo logs during Incomplete recovery and ensure that subsequent recovery is not needed. To this end, the reset log option will discard all online logs and archived logs. The side effect is that all previous backups are useless for future recovery.

The redo log option also initializes the online log and redo thread content in the control file, and clears the existing online redo log Content. If the online log file does not exist, it is created, and reset the log numbers of all threads.

Series of articles: Oracle internal recovery principles? Where = nkey & keyword = 19824

8.1 fuzzy files

When you use the redo log option to open the database, the most important thing is to check that all data files are restored to the same time point. This ensures that all changes to a single redo log are automatically applied. This is also important for other reasons for consistency. If the redo logs of all threads are applied to all online data files, the database is consistent.

If Incomplete recovery is performed, a file may not be recovered from an old backup. In general, this can be found by detecting that the checkpoint in the header of the data file is inconsistent with other data files (the exception is offline files and read-only files ).

Another possibility is that the file is "fuzzy ". It may include changes beyond its checkpoint SCN. The following "fuzzy state bit" is maintained in the data file header in the previous chapter to determine whether the data file is "fuzzy ":

1. Online fuzzy bit (see 3.5, 6.7.2)

2. Hot Backup fuzzy bit (see 4, 6.7.3)

3. Media recovery fuzzy bit (see 6.7.1)

If the fuzzy setting of the online data file is set when the database is opened in the log reset mode after Incomplete recovery, opening fails.

A redo log is written at the end of a hot backup or crash recovery so that the media can be restored to determine when these fuzzy bits can be cleared. Redo logs report errors if these fuzzy bits are not cleared.

When the checkpoint SCN at the end of a data file is different from the checkpoint SCN of other data files (For details, refer to 8.2), an error is reported when the log is reset, unless in the following situations:

1. It is acceptable to restore a data file to an SCN that is earlier than resetting the SCN, provided that no redo logs are redone between the two files for application. For example, the data file is read-only or offline, and the offline range covers the SCN and reset SCN at the end of restoration. In this case, redo logs allow this data file to be set offline.

2. it is too late for a data file to make the SCN proportion of the checkpoint, provided that it creates the SCN (allocated during data file creation and saved in the file header) it is displayed after the SCN is reset. When redo logs, check the data dictionary and control file to find that the data file does not exist in the data dictionary but the control file exists. Result, it is cleared from the control file.

8.2 reset SCN and counter

The database information section of the control file records the SCN and time (collectively called Log Data reset) of a reset log ). Log Data is reset to uniquely identify each redo log to open the database operation, also saved in each data file header and log file header. If the reset log data in the log file is inconsistent with that recorded in the control file, the redo log in the log file cannot be applied. If the redo log data in the data file is inconsistent with the record in the control file, the data file cannot be accessed or restored, unless in some special cases (for example, the tablespace where the data file is located is normally offline or read-only ). This ensures that the redo logs discarded by the reset log will not be applied to the database again, and declares that any previous backup is useless for future recovery. Therefore, it is smart to make a backup immediately after the logs are redone.

8.3 Effect of log resetting on threads

When the log is reset, the control file record of each thread clears the thread opening mark and sets the thread checkpoint SCN to reset the SCN. So it seems that the thread is closed at the SCN reset. The list of enabled threads recorded in the database information section in the control file can still be used. At this time, it is no longer important that the thread is enabled at the end of recovery because the previous redo log is no longer needed. The log serial number of all threads is set to 1, and the checkpoint of one thread is selected as the database checkpoint.

8.4 Effect of log resetting on Log Files

All online logs are cleared, meaning that all redo logs are permanently discarded. Unless online logs are backed up before redo logs, there is no way to restore these logs. Therefore, the only solution for clearing online logs with recovery errors is that online logs are backed up. To restore an incorrect log redo operation, you must restore all data files, control files, and online log files, and then restore all of them.

Each enabled thread selects a log file as the current log. The log header is written as log number 1. note that log files and related threads are obtained from the control file (use the thread number recorded in the control file and Its log set ). If this control file is a backup control file, it may be a little different from the last time the database was opened.