Data recovery with no backup after Resetlogs

Media recovery is fully and incompletely restored. Incomplete recovery can be restored to a specified time or system change number, but the remaining log files are not available after incomplete recovery, the log sequence number must be reset, the database is opened with the Resetlogs option, and the database becomes a new form, and a consistent backup must be repeated for future recovery. Also, the backup before Resetlogs is no longer available. However, it is likely that after the resetlogs did not do a consistent backup of the database, and the database does not know resetlogs before the backup, at this time how to restore the resetlogs after the data? Although this article provides the technology to be able to use the backup before the Resetlogs to restore to a time after the resetlogs data, but this is also a rescue measure, I strongly recommend that the reader to do resetlogs after the consistent database backup.

The theoretical basis of technology

Oracle restores only based on the system change number (SCN), all data files must be restored to the same point in time, and no changes have been made after that point to open the database. The SCN of the database is unique and increases (possibly discontinuous) as operational transactions increase during the lifetime of the database. The SCN value will never be 0 unless the database is re-created. The incremental nature of the SCN's sequence does not change with any operation of the database, even resetlogs. Resetlogs clears the redo records not applied in all the online log files, resetlogs only resets the log file's serial number to 1, but has no effect on the SCN, and the SCN is still incremented by the original sequence.

Save the Resetlogs SCN and counters in the control file to uniquely identify each open database operation performed with the Resetlogs option. This value is written into each data file header and redo log file. If the log sequence number of the redo log file does not match the Oracle requirement value, the Redo log file cannot be applied in recovery. After performing an incomplete restore, the database requires a log file with a log sequence number of 1, so the remaining log files in the original log sequence will not be available. The resetlogs operation creates a new form of the database, a database that has a new stream of log sequence numbers starting with 1.

According to the above theory, the SCN is sequential data stream, always incrementing during the existence of the database, and the log file sequence stream is an increment sequence, but it will be reset because of the resetlogs, but the SCN sequence flow in the log file sequence stream keeps increasing inconvenience. Therefore, the SCN sequence stream can be connected and renewed with the archive log stream before resetlogs and the Resetlogs archive log stream, thus realizing the data after resetlogs with Resetlogs backup. The prerequisite is to ensure that the two-strand log stream (Resetlogs before the archive log stream and the Resetlogs archive log stream) is complete and has a corresponding two-strand log flow control file.

Even if the data can be saved, the following conditions are met

(1) The Oracle version is equal to or higher than 7.3.3.

(2) Incomplete media recovery before resetlogs can be successfully implemented.

(3) No consistent backup is provided after Resetlogs.

(4) Provide consistent backup (cold or hot) before resetlogs.

(5) The control files before and after Resetlogs must be backed up.

(6) Save the archived log files before and after resetlogs to different locations, provide all archived logs for recovery, and ensure that the logs are available.

Suggestions

(i) It is strongly recommended that the database be backed up after resetlogs.

(ii) To ensure that the data previously backed up by the database is secure before resetlogs, a consistent database backup created before resetlogs must not be deleted until a consistent backup after Resetlogs is created. If not for space purposes, it is recommended that you permanently preserve a consistent database backup that was created before resetlogs, including data files, control files, and archive logs.

(iii) Create a backup of the control files immediately after Resetlogs and store the archive logs separately.

(d) Back up all archived logs and online redo logs used in the recovery before you open the database in Resetlogs mode.

(v) After Resetlogs, back up the Alter.log file because the file holds the change# (System change SCN) that was recorded after Point-in-time recovery.

(vi) Save the archived log files before and after resetlogs to a different location for recovery. Because the following scenarios may exist: If the archive log files before and after Resetlogs are saved to the same location, and the archive log file sequence number after Resetlogs starts at 1, and as the log switch continues to occur, The new log sequence number is increased to the same time as the log sequence number before the Resetlogs, when Resetlogs archive log files will be overwritten by the new log file, causing the Resetlogs log sequence to appear empty.