Rman backup recovery test

Rman backup recovery test 1, Open Database new test data $ sqlplus/nolog SQL> conn/as sysdba SQL> startup SQL> create table cds (id number (1 ), name varchar2 (20); SQL> insert into cds (id, name) values ('1', 'litao'); 2, start to archive mode $ sqlplus/nolog SQL> conn/as sysdba SQL> alter database archivelog; SQL> archive log list; * # data record time, add the time point to the recovery script 3 and perform full database backup $ rman target/RMAN> configure controlfile autobackup on; RMAN> configure channel dev Ice type disk format '/home/oracle/backup/% U'; RMAN> backup database; 4. modify database SQL> drop table cds; 5, start the database to the mount Status $ sqlplus/nolog SQL> conn/as sysdba SQL> startup mount 6, recover database $ rman target/RMAN> configure channel device type disk format'/home/oracle/backup/% U'; RMAN> restore database; RMAN> recover database until time "to_date ('2017-02-17 12:30:00 ', 'yyyy-mm-dd hh24: mi: ss')"; restore to a certain time point, the time point is when the database is deleted Previous system time # RMAN> release channel t1; (in fact, rman is also a database connection. We generally start a channel during testing. If it is in a production environment, we may open multiple channels at the same time to back up the database and release the channel after recovery is completed.) 7. Check the recovered database $ sqlplus/nolog SQL> conn/as sysdba SQL> startup mount; SQL> alter database open resetlogs; SQL> select * from cds; RMAN> shutdown immediate; database dismounted Oracle instance shut down RMAN> startup nomount connected to target database (not started) Oracle instance started Total System Global Area 167772160 bytes Fixed Size 1260672 bytes Variable Size 150995840 bytes Database Buffers 8388608 bytes Redo Buffers 7127040 bytes RMAN> alter database mount 2>; database mounted released channel: ORA_DISK_1 RMAN> reset database to incarnation 2; RMAN> list incarnation; List of Database Incarnations DB Key Inc Key DB Name db id status Reset SCN Reset Time -------------- -------- ---------------- --- ---------- 1 ORCL 1168992346 PARENT 1 2006-11-16 18:40:24 2 2 2 ORCL 1168992346 CURRENT 456954 10:20:12 3 3 3 ORCL 1168992346 ORPHAN 3326890 2008-06-23 11:07:57 RMAN> restore database until scn 3326890 2>; starting restore at 12:27:19 using channel ORA_DISK_1 skipping datafile 1; already restored to file/u/app/oracle/oradata/orcl/syste Mf skipping datafile 2; already restored to file/u/app/oracle/oradata/orcl/undotbf skipping datafile 3; already restored to file/u/app/oracle/oradata/orcl/sysauxf skipping datafile 4; already restored to file/u/app/oracle/oradata/orcl/users0f restore not done; all files readonly, offline, or already restored Finished restore at 2008-06-23 12:27:19 RMAN> alter database open resetlogs; database o Pened RMAN> list incarnation; list of Database Incarnations DB Key Inc Key DB Name db id status Reset SCN Reset Time ------- -------- ---------------- --- ---------- 1 1 ORCL 1168992346 PARENT 1 2006-11-16 18:40:24 2 2 ORCL 1168992346 PARENT 456954 10:20:12 4 4 ORCL 1168992346 CURRENT 3326784 12:27:43 3 3 ORCL 1168992346 ORPHAN 3326890 2008-06-23 11:07:57 The database is restored to the previous time point. If you execute the same recovery script repeatedly, the following error will be reported: 21:01:49 Am? Date: 2011-3-1HAHA 9:13:41 D: \> rman target/nocatalog recovery Manager: Release 10.2.0.1.0-Production on Thursday March 27 00:18:13 2008 Copyright (c) 1982,200 5, Oracle. all rights reserved. connect to the target database: ORCL (DBID = 1176767170) uses the target database control file to replace the recovery directory RMAN> list incarnation; database prototype list DB keyword Inc keyword DB name db id status reset SCN reset time ------- -------- ---------------- --- ---------- 1 1 ORCL 1176767170 PARENT 1 10-3 month-082 2 ORCL 1176767170 PARENT 472611 25-3 month-083 3 ORCL 1176767170 PARENT 474163 25-3 month-084 4 ORCL 1176767170 PARENT 488631 26-3 month-085 5 ORCL 1176767170 PARENT 490308 26-3 month-086 6 ORCL 1176767170 PARENT 506067 month-087 7 ORCL 1176767170 CURRENT 506961 month-08-found object loss, time-based recovery is required, but the lost object occurs in the running process of entity 5, therefore, using the physical 5 backup for Incomplete recovery RMAN> reset database to incarnationHAHA 9:13:52 this is a typical rman error: Mu Yushan 9:27:27 RMAN> RESTO Re database until scn 490308 Mu Yushan 9:27:32 is this OK haha 9:27:44 can HAHA 9:27:57 this is according to scn good recovery Mu Yushan 9:28:24 I mean after that error occurs HAHA 9:29:01 reset database incarnation 9:29:12 am Yushan need to execute this command First HAHA 9:29:12 RMAN> list incarnation; database prototype list DB keyword Inc keyword DB name db id status reset SCN reset time ------- -------- ---------------- --- ---------- 1 1 ORCL 1176767170 PARENT 1 10-3 month-082 2 ORCL 1176767170 PARENT 4726 11 month-083 3 ORCL 1176767170 PARENT 474163 month-084 4 ORCL 1176767170 PARENT 488631 month-085 5 ORCL 1176767170 PARENT 490308 month-086 6 ORCL 1176767170 PARENT 506067 month-3 month- 087 7 ORCL 1176767170 CURRENT 506961-08 -- Object loss found, time-based recovery is required, but the lost object occurs in the running process of entity 5, therefore, using the physical 5 backup for Incomplete recovery RMAN> reset database to incarnationHAHA 9:29:51 this is the cause of this error after alter database open resetlogs HAHA 9:30:22 if you put the recovery point to the execution This problem will not occur after resetlogs at 9:34:23 AM. I don't understand HAHA at 9:34:52 am. You can see the error message "rman20207". The error message "9:38:36 am" is good at archiving and online logs (if necessary. The automatic recovery process generally does not require human control.) restore to the appropriate time point (I chose the same time point as the control file) RMAN> recover database until time '2017-03-10 18:07:00 '; start recover from 10-3-09 using channel ORA_DISK_1 is starting media recovery archiving log thread 1 sequence 3 has been used as file E: \ ORACLE \ PRODUCT \ 10.2.0 \ ORADATA \ TEST \ REDO03.LO G exists on the disk. The archived log file name = E: \ ORACLE \ PRODUCT \ 10.2.0 \ ORADATA \ TEST \ REDO03.LOG thread = 1 sequence = 3 Media Recovery completed, time spent: 00:00:04 completed recover on month-3-09 RMAN> alter database open resetlogs; (resetlogs will reset the log switch sequence And initialize online logs. Therefore, we recommend that you perform a full backup immediately after resetlogs in almost all oracle textbooks. It is best to back up the database offline.) When the database is enabled, you can log on to the database to verify that it has been found, table space test1 and table t1 and data recovery (ps: Intermediate has reported ora-01153: an incompatible media recovery is active error, the reason is not found) 2. The elder incarnation cross-resetlogs version is restored based on the previous section. If we want to restore the database to the condition after the tablespace test1 is deleted. Run RMAN> startup nomount; RMAN> SQL 'alter session set nls_date_format = ''yyyy-mm-dd hh24: mi: s ''"; RMAN> restore controlfile from autobackup until time '2017-03-10 18:15:00 '; (Note that you still need to restore the control file properly. Because, after the last restoration, the table space test1 was returned, resulting in a database structure change. rman automatically backed up the control file containing the 'test01. dbf' data file location again. If the data is restored directly, the test1 tablespace cannot be removed.) RMAN> alter database mount; RMAN> restore database; RMAN> SQL "alter session set nls_date_format = ''yyyy-mm-dd hh24: mi: ss ''"; RMAN> recover database until time '2017-03-10 18:15:00 '; the following error occurs: RMAN-03002: recover command (on 2009 19:21:19) failed RMAN-20207: until time or recovery window before RESETLOGS time 20207 error: Default think until TIME or recovery window time cannot be earlier than resetlogs TIME (we used resetlogs in the previous scenario The time when the data is opened ). The reason may be (I guess): Since resetlogs is used, I do not know the archived log information. Exclude the previously archived logs from the options available for recovery. This is only the default behavior and may be considered to save system resources. After all, data reuse before resetlogs may be small. Regardless of the cause, we can solve the problem as follows: 1. find the current incarnation Number of the database: RMAN> list incarnation of database "test "; database prototype list DB keyword Inc keyword DB name db id status reset SCN reset time ------- -------- ---------------- --- ---------- 1 1 TEST 1978860036 PARENT 1 30-8 month-05 2 2 TEST 1978860036 PARENT 534907 05-3 month-09 3 3 TEST 1978860036 PARENT 762990 10-3 month-09 4 4 TEST 1978860036 PARENT 764885 10-3 month-09 5 5 TEST 1978860036 PARENT 765443 10-3 months-09 6 TEST 1978860036 PARENT 767488 10-3 months-09 7 TEST 1978860036 PARENT 771807 10-3 months-09 8 TEST 1978860036 PARENT 774320 10-3 months-09 9 TEST 1978860036 PARENT 779541 10-3 months-09 10 TEST 1978860036 PARENT 782000 10-3 months-09 11 11 TEST 1978860036 PARENT 783792 10-3 months-09 12 12 TEST 1978860036 CURRENT 801599 10-3 months-09 -- this row prototype (incarnation) number status is current, that is, the current, the original model before the database (before resetlogs) 11. restart the database to the mount state (because you need to know which database to reset, so you need to attach) 2. reset the database to the previous prototype (note: the control file has been restored to an appropriate time point in the previous step. In fact, we should restore the control file before nomount, of course, this is not a required step to reset the db prototype) RMAN> reset database to incarnation 11; reset the database to the prototype 11 RMAN> SQL "alter session set nls_date_format = ''yyyy-mm-dd hh24: mi: s''"; RMAN> restore database; RMAN> recover database until time '2017-03-10 18:15:00 '; RMAN> alter database open resetlogs; (at this time, the database's incarnation number will rise again) open the database to connect to the database, check that the table space test1 is no longer available.