Explore Oracle RMAN_07 non-consistent recovery (SET)

In the previous topic, we have actually made a complete introduction to the backup and recovery of rman, talked about the backup of databases, tablespaces, parameter files, control files, and also talked about

In the previous topic, we have actually made a complete introduction to the backup and recovery of rman, talked about the backup of databases, tablespaces, parameter files, control files, and also talked about

In the previous topic, we have actually made a complete introduction to the backup and recovery of rman. We talked about the backup of databases, tablespaces, parameter files, and control files ,, at the same time, we also talked about their recovery, including catastrophic recovery. The non-consistent recovery that we are talking about today has actually been used, but it is not explained. What is non-consistent recovery? Non-consistent recovery means that some data is lost during the recovery process.

Therefore, non-consistent recovery is mainly applied to the control file, redo log files, or archive log files that fail. When the database's complete media Recovery fails, in order to minimize the loss, in this case, the inconsistency of the database can be restored.

Related reading:

Exploring the RMAN_01 concept of Oracle

Explore the basic use of RMAN_02 in Oracle

Explore Oracle-based RMAN_03 non-consistent backup

Explore Oracle-based RMAN_04 non-consistent backup

Explore RMAN_05 Incremental Backup in Oracle

Exploring Oracle's RMAN_06 backup policy

Explore Oracle RMAN_07 restoration of single data file loss

Explore Oracle RMAN_07 recovery of whole business tablespace loss

Explore Oracle RMAN_07 disk corruption data loss recovery

Explore Oracle RMAN_07 recovery of all database files lost

Explore Oracle RMAN_07 redo log redu file loss recovery

Explore Oracle RMAN_07 parameter file loss recovery

Explore Oracle RMAN_07 control file loss recovery

Explore Oracle RMAN_07 system tablespace loss recovery

We can understand what non-consistent recovery is like:

In the migration process, the database was fully standby at 100, and the redo log captured the SCN between 500 and, and archived the same as the redo application. When, the database encountered a media failure; at this time, the backup at scn 100 and the archive and redo log information generated during the 100-500 period will be used for database recovery. If the archive is damaged at scn 300, it can only be restored to the point where scn is 200. That is, the database is not completely recovered.

Non-consistent recovery can be divided into the following four types:

Time-based recovery

Time-based recovery restores the database to a time point between the backup point and the failure point. Time-based recovery can be used not only when the media fails, but also when the database runs normally. For example, if a user accidentally deletes the data of a table, the deleted data can be restored through time-based restoration. For example:

1. view the table under the current user. There is only one WWL001

21:07:31 SQL> select * fromtab;

TNAME TABTYPE CLUSTERID

-----------------------------------------------

WWL001 TABLE

Elapsed: 00:00:00. 06

We use WWL001 to create a WWL002-WWL005 with four tables to test Incomplete recovery

21:08:28 SQL> create tablewwl002 as select * from wwl001;

Table created.

Elapsed: 00:00:00. 17

21:08:55 SQL> create tablewwl003 as select * from wwl001;

Table created.

Elapsed: 00:00:00. 04

21:09:00 SQL> create tablewwl004 as select * from wwl001;

Table created.

Elapsed: 00:00:00. 03

21:09:06 SQL> create tablewwl005 as select * from wwl001;

Table created.

Elapsed: 00:00:00. 05

As shown in the preceding table

2. We will delete the table at 21:13:13 (please note the time)

21:13:13 SQL> drop tablewwl002 purge;

Table dropped.

Elapsed: 00:00:00. 16

21:13:28 SQL> drop tablewwl003 purge;

Table dropped.

Elapsed: 00:00:00. 11

21:13:34 SQL> truncate tablewwl004;

Table truncated.

Elapsed: 00:00:00. 32

21:13:44 SQL & gt; truncate tablewwl005;

Table truncated.

Elapsed: 00:00:00. 07

21:13:47 SQL>

3. Start recovery. First, start the database to the mount status.

21:14:40 SQL> conn/assysdba

Connected.

21:14:44 SQL> shutdownimmediate

Database closed.

Database dismounted.

ORACLE instance shut down.

21:15:20 SQL> startup mount;

ORACLE instance started.

Total System Global Area 100663296 bytes

Fixed Size 1217884 bytes

Variable Size 88083108 bytes

Database Buffers 8388608 bytes

Redo Buffers 2973696 bytes

Database mounted.

21:15:46 SQL> e

4. Start executing restore to the current status of the backup database:

RMAN> restore database;

Starting restore at 12-JUL-12

Using target database controlfile instead of recovery catalog

Allocated channel: ORA_DISK_1

Channel ORA_DISK_1: sid = 47 devtype = DISK

Channel ORA_DISK_1: startingdatafile backupset restore

Channel ORA_DISK_1: specifyingdatafile (s) to restore from backup set

Restoring datafile 00001 to/DBBak2/oradata/WWL/system01.dbf

Restoring datafile 00002 to/DBBak2/oradata/WWL/undotbs01.dbf

Restoring datafile 00003 to/DBBak2/oradata/WWL/sysaux01.dbf

Restoring datafile 00004 to/DBBak2/oradata/WWL/users01.dbf

Restoring datafile 00005 to/DBBak2/oradata/WWL/wwl01.dbf

Restoring datafile 00006 to/DBBak2/oradata/WWL/wwl02.dbf

Restoring datafile 00007 to/DBBak2/oradata/WWL/wwl03.dbf

Channel ORA_DISK_1: readingfrom backup piece/DBSoft/product/10.2.0/db_1/dbs/01nft4mu_1_1

Channel ORA_DISK_1: restoredbackup piece 1

Piecehandle =/DBSoft/product/10.2.0/db_1/dbs/01nft4mu_1_1 tag = TAG20120712T095437

Channel ORA_DISK_1: restorecomplete, elapsed time: 00:01:35

Finished restore at 12-JUL-12

RMAN> exit

5. Perform Restoration Based on time points:

21:27:54 SQL> recover database until time 'yyyy-mm-ddhh24: mi: ss'

21:27:54 SQL> recoverdatabase until time '2017-07-12 21:10:00 ';

ORA-00279: change 1436429 generated at 07/12/2012 09:54:38 needed for thread 1

ORA-00289: suggestion:/DBSoft/product/10.2.0/db_1/dbs/arch1_3_788372282.dbf

ORA-00280: change 1436429 forthread 1 is in sequence #3

21:30:09 Specify log :{ = Suggested | filename | AUTO | CANCEL}

Auto

ORA-00279: change 1440657 generated at 07/12/2012 14:00:52 needed for thread 1

ORA-00289: suggestion:/DBSoft/product/10.2.0/db_1/dbs/arch1_00007880000452.dbf

ORA-00280: change 1440657 forthread 1 is in sequence #1

ORA-00279: change 1440855 generated at 07/12/2012 15:08:58 needed for thread 1

ORA-00289: suggestion:/DBSoft/product/10.2.0/db_1/dbs/arch1_rj788454538.dbf

ORA-00280: change 1440855 forthread 1 is in sequence #1

ORA-00279: change 1441316 generated at 07/12/2012 15:19:50 needed for thread 1

ORA-00289: suggestion:/DBSoft/product/10.2.0/db_1/dbs/arch1_rj788455190.dbf

ORA-00280: change 1441316 forthread 1 is in sequence #1

ORA-00279: change 1442275 generated at 07/12/2012 15:52:01 needed for thread 1

ORA-00289: suggestion:/DBSoft/product/10.2.0/db_1/dbs/arch1_2017788457121.dbf

ORA-00280: change 1442275 forthread 1 is in sequence #1

ORA-00279: change 1442953 generated at 07/12/2012 16:25:06 needed for thread 1

ORA-00289: suggestion:/DBSoft/product/10.2.0/db_1/dbs/arch1_rj788459106.dbf

ORA-00280: change 1442953 forthread 1 is in sequence #1

ORA-00279: change 1462958 generated at 07/12/2012 16:28:16 needed for thread 1

ORA-00289: suggestion:/DBSoft/product/10.2.0/db_1/dbs/arch1_2_788459106.dbf

ORA-00280: change 1462958 forthread 1 is in sequence #2

ORA-00278: log file '/DBSoft/product/10.2.0/db_1/dbs/arch1_0000788459106.dbf' no longer needed forthis recovery

ORA-00279: change 1462963 generated at 07/12/2012 17:17:59 needed for thread 1

ORA-00289: suggestion:/DBSoft/product/10.2.0/db_1/dbs/arch1_2017788462279.dbf

ORA-00280: change 1462963 forthread 1 is in sequence #1

ORA-00279: change 1483784 generated at 07/12/2012 17:54:25 needed for thread 1

ORA-00289: suggestion:/DBSoft/product/10.2.0/db_1/dbs/arch1_2_788462279.dbf

ORA-00280: change 1483784 forthread 1 is in sequence #2

ORA-00278: log file '/DBSoft/product/10.2.0/db_1/dbs/arch1_0000788462279.dbf' no longer needed forthis recovery

Log applied.

Media recovery complete.

21:30:29 SQL>

The recovery has been completed.

6. restlogs is required to open the database because it cannot be completely restored.

21:30:29 SQL> alter databaseopen restlogs;

Alter database open restlogs