ORACLE 11G 中采用rman备份异机恢复数据库详细过程

2018-01-06 11:02:54来源:oschina作者:rootliu人点击

分享
ORACLE 11G 中采用rman备份异机恢复数据库详细过程

原创 2015年02月03日 16:29:14

场景: 有一个生产库的用户下面所有的表都不见了,怀疑人为被删除了,现在需要用备份去恢复下,找出原来的表,线上是oracle dataguard环境,有全库备份文件,准备去测试库恢复一下。 1,从生产库上copy好全备份文件 恢复数据库需要准备的文件:rman完整备份(包括数据文件、日志文件、控制文件、参数文件),记录源数据库的DBID安装的测试数据库ORACLE数据库软件并创建跟源数据库同名和数据库SID并修改数据库DBID跟源数据库DBID一样,创建跟源数据库服务器相同的数据文件目录、日志文件目录、控制文件目录。查看环境 1.1,查看参数文件信息 RMAN> list backup of spfile; using target database control file instead of recovery catalog List of Backup Sets =================== BS Key Type LV SizeDevice Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 7Full1.05M DISK00:00:01 30-JAN-15 BP Key: 7Status: AVAILABLE Compressed: YES Tag: TAG20150130T201758 Piece Name: /data/oracle/backup/data/2015-01-30/full_stuorcl_20150130_7.bakSPFILE Included: Modification time: 30-JAN-15SPFILE db_unique_name: stuorcl BS Key Type LV SizeDevice Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 11 Full9.39M DISK00:00:01 31-JAN-15 BP Key: 11Status: AVAILABLE Compressed: NO Tag: TAG20150131T180139 Piece Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015_01_31/o1_mf_ncsnf_TAG20150131T180139_bdsb18jn_.bkpSPFILE Included: Modification time: 31-JAN-15SPFILE db_unique_name: stuorcl 1.2查看控制文件信息: RMAN> list backup of controlfile; List of Backup Sets =================== BS Key Type LV SizeDevice Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 7Full1.05M DISK00:00:01 30-JAN-15 BP Key: 7Status: AVAILABLE Compressed: YES Tag: TAG20150130T201758 Piece Name: /data/oracle/backup/data/2015-01-30/full_stuorcl_20150130_7.bakControl File Included: Ckp SCN: 1635989 Ckp time: 30-JAN-15 BS Key Type LV SizeDevice Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 11 Full9.39M DISK00:00:01 31-JAN-15 BP Key: 11Status: AVAILABLE Compressed: NO Tag: TAG20150131T180139 Piece Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015_01_31/o1_mf_ncsnf_TAG20150131T180139_bdsb18jn_.bkpControl File Included: Ckp SCN: 1758247 Ckp time: 31-JAN-151.3 查看数据库信息: RMAN> list backup of database; List of Backup Sets =================== BS Key Type LV SizeDevice Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 6Full270.16MDISK00:00:56 30-JAN-15 BP Key: 6Status: AVAILABLE Compressed: YES Tag: TAG20150130T201758 Piece Name: /data/oracle/backup/data/2015-01-30/full_stuorcl_20150130_6.bakList of Datafiles in backup set 6File LV Type Ckp SCNCkp Time Name---- -- ---- ---------- --------- ----1Full 163557330-JAN-15 /oracle/data_ora/stuorcl/system01.dbf2Full 163557330-JAN-15 /oracle/data_ora/stuorcl/sysaux01.dbf3Full 163557330-JAN-15 /oracle/data_ora/stuorcl/undotbs01.dbf4Full 163557330-JAN-15 /oracle/data_ora/stuorcl/users01.dbf5Full 163557330-JAN-15 /oracle/data_ora/stuorcl/SBXTAX01.dbf6Full 163557330-JAN-15 /oracle/data_ora/stuorcl/SMS01.dbf BS Key Type LV SizeDevice Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 10 Full1.11G DISK00:00:29 31-JAN-15 BP Key: 10Status: AVAILABLE Compressed: NO Tag: TAG20150131T180139 Piece Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015_01_31/o1_mf_nnndf_TAG20150131T180139_bdsb04jz_.bkpList of Datafiles in backup set 10File LV Type Ckp SCNCkp Time Name---- -- ---- ---------- --------- ----1Full 175807731-JAN-15 /oracle/data_ora/stuorcl/system01.dbf2Full 175807731-JAN-15 /oracle/data_ora/stuorcl/sysaux01.dbf3Full 175807731-JAN-15 /oracle/data_ora/stuorcl/undotbs01.dbf4Full 175807731-JAN-15 /oracle/data_ora/stuorcl/users01.dbf5Full 175807731-JAN-15 /oracle/data_ora/stuorcl/SBXTAX01.dbf6Full 175807731-JAN-15 /oracle/data_ora/stuorcl/SMS01.dbf1.4 查看归档日志信息: RMAN> list backup of archivelog all; List of Backup Sets =================== BS Key SizeDevice Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 81.26M DISK00:00:00 30-JAN-15 BP Key: 8Status: AVAILABLE Compressed: YES Tag: TAG20150130T201906 Piece Name: /data/oracle/backup/data/2015-01-30/arch_stuorcl_20150130_8.bakList of Archived Logs in backup set 8Thrd Seq Low SCNLow Time Next SCNNext Time---- ------- ---------- --------- ---------- ---------1104 163556230-JAN-15 163599530-JAN-15 BS Key SizeDevice Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 9195.19MDISK00:00:04 31-JAN-15 BP Key: 9Status: AVAILABLE Compressed: NO Tag: TAG20150131T180132 Piece Name: /data/oracle/backup/data/ALL_0cpu493s_1_1.BKPList of Archived Logs in backup set 9Thrd Seq Low SCNLow Time Next SCNNext Time---- ------- ---------- --------- ---------- ---------1105 163599530-JAN-15 163601330-JAN-151106 163601330-JAN-15 165330430-JAN-151107 165330430-JAN-15 167921731-JAN-151108 167921731-JAN-15 170316831-JAN-151109 170316831-JAN-15 173169531-JAN-151110 173169531-JAN-15 175718931-JAN-151111 175718931-JAN-15 175800531-JAN-151112 175800531-JAN-15 175803931-JAN-151113 175803931-JAN-15 175805531-JAN-15 BS Key SizeDevice Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 12 1.12M DISK00:00:00 31-JAN-15 BP Key: 12Status: AVAILABLE Compressed: NO Tag: TAG20150131T180218 Piece Name: /data/oracle/backup/data/ALL_0fpu495a_1_1.BKPList of Archived Logs in backup set 12Thrd Seq Low SCNLow Time Next SCNNext Time---- ------- ---------- --------- ---------- ---------1114 175805531-JAN-15 175825231-JAN-15 RMAN>2、开始恢复参数文件控制文件: SQL> select dbid from v$database; DBID ---------- 3391761643 SQL> 2.1 设置DBID: 注意:在rman下即使没有参数文件,默认也会启动一个DUMMY实例,以便能够恢复参数文件。 set dbid 3391761643 2.2 恢复spfile文件 startup到open状态,先查看spfile文件位置: SQL> show parameter spfile; NAME TYPE ------------------------------------ ---------------------- VALUE ------------------------------ spfile string /oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfilestuorcl.ora SQL>shutdown后,再startup 到 nomount状态 startup nomount再恢复 restore spfile to '/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfilestuorcl.ora' from '/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/full_stuorcl_20150127_3069.bak'; 恢复报错,去生产环境查看备份信息: RMAN> show all;using target database control file instead of recovery catalog RMAN configuration parameters for database with db_unique_name stuunq are:CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/pddata2/oracle/backup/data/ctl_auto/%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_stuorcl.f'; # defaultRMAN> 有CONFIGURE CONTROLFILE AUTOBACKUP ON; 表示参数文件和控制文件有备份 restore spfile to '/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfilestuorcl.ora' from '/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/c-3391761643-20150127-03'; RMAN> restore spfile to '/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfilestuorcl.ora' from '/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/c-3391761643-20150127-03'; Starting restore at 02-FEB-15 using channel ORA_DISK_1 channel ORA_DISK_1: no AUTOBACKUP in 7 days found RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 02/02/2015 11:36:30 RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece restore spfile to '/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfilestuorcl.ora' from '/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/c-3391761643-20150127-03' until time 'sysdate - 30' RMAN> restore spfile to '/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfilestuorcl.ora' from '/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/c-3391761643-20150127-03' until time 'sysdate - 30'; Starting restore at 02-FEB-15 using channel ORA_DISK_1 channel ORA_DISK_1: restoring spfile from AUTOBACKUP /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/c-3391761643-20150127-03 channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete Finished restore at 02-FEB-15 RMAN> OK,成功了,参数文件恢复成功。 CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS; CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default 这是两个库不一样的地方 2.3,恢复控制文件位置 查看控制文件位置 SQL> show parameter control NAME TYPE ------------------------------------ ---------------------- VALUE ------------------------------ control_file_record_keep_time integer 7 control_files string /oracle/data_ora/stuorcl/control01.ctl, /oracle/app/oracle/flash_recovery_area/stuorcl/control02.ctl control_management_pack_access string DIAGNOSTIC+TUNING SQL> 恢复控制文件: restore controlfile to '/oracle/data_ora/stuorcl/control01.ctl' from '/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/c-3391761643-20150127-03'; RMAN> restore controlfile to '/oracle/data_ora/stuorcl/control01.ctl' from '/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/c-3391761643-20150127-03'; Starting restore at 02-FEB-15 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=130 device type=DISK channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 Finished restore at 02-FEB-15 RMAN> 2.4, 在新控制文件中注册数据文件备份和归档备份 catalog start with '/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/'; RMAN> catalog start with '/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/'; searching for all files that match the pattern /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/ List of Files Unknown to the Database ===================================== File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/arch_stuorcl_20150127_3068.bak File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/rman_backup.log File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/arch_stuorcl_20150127_3067.bak File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/full_stuorcl_20150127_3069.bak File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/c-3391761643-20150127-03 File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/arch_stuorcl_20150127_3070.bak Do you really want to catalog the above files (enter YES or NO)? YES cataloging files... cataloging done List of Cataloged Files ======================= File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/arch_stuorcl_20150127_3068.bak File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/arch_stuorcl_20150127_3067.bak File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/full_stuorcl_20150127_3069.bak File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/c-3391761643-20150127-03 File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/arch_stuorcl_20150127_3070.bak List of Files Which Where Not Cataloged ======================================= File Name: /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/rman_backup.logRMAN-07517: Reason: The file header is corrupted RMAN> 2.5,恢复整个库 因为前面恢复了整个spfile已经controlfile,所以接下来恢复所有库的话,就不用带参数,直接恢复restore database就可以 ; RMAN> restore database; Starting restore at 02-FEB-15 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to /home/oradata/stuorcl/system01.dbf channel ORA_DISK_1: restoring datafile 00002 to /home/oradata/stuorcl/sysaux01.dbf channel ORA_DISK_1: restoring datafile 00003 to /home/oradata/stuorcl/undotbs01.dbf channel ORA_DISK_1: restoring datafile 00004 to /home/oradata/stuorcl/users01.dbf channel ORA_DISK_1: restoring datafile 00005 to /home/oradata/stuorcl/stuorclk01.dbf channel ORA_DISK_1: restoring datafile 00006 to /home/oradata/stuorcl/plas01.dbf channel ORA_DISK_1: restoring datafile 00007 to /home/oradata/stuorcl/pl01.dbf channel ORA_DISK_1: restoring datafile 00008 to /home/oradata/stuorcl/help01.dbf channel ORA_DISK_1: restoring datafile 00009 to /home/oradata/stuorcl/adobelc01.dbf channel ORA_DISK_1: restoring datafile 00010 to /home/oradata/stuorcl/sms01.dbf channel ORA_DISK_1: reading from backup piece /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/full_stuorcl_20150127_3069.bak ^[ ^[ channel ORA_DISK_1: piece handle=/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/full_stuorcl_20150127_3069.bak tag=TAG20150127T030346 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 01:10:36 Finished restore at 02-FEB-15 RMAN> RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-00558: error encountered while parsing input commands RMAN-01006: error signaled during parse RMAN-02003: unrecognized character: MAN> RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-00558: error encountered while parsing input commands RMAN-01006: error signaled during parse RMAN-02003: unrecognized character: MAN> restore 结束,开始recover: MAN> recover database; Starting recover at 02-FEB-15 using channel ORA_DISK_1 starting media recovery RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 02/02/2015 17:01:10 RMAN-06053: unable to perform media recovery because of missing log RMAN-06025: no backup of archived log for thread 1 with sequence 29186 and starting SCN of 10909658066 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29185 and starting SCN of 10909532300 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29184 and starting SCN of 10909335334 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29183 and starting SCN of 10909087538 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29182 and starting SCN of 10909083077 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29181 and starting SCN of 10909082462 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29180 and starting SCN of 10908905530 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29179 and starting SCN of 10908836337 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29178 and starting SCN of 10908811866 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29177 and starting SCN of 10908758627 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29176 and starting SCN of 10908700866 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29175 and starting SCN of 10908695942 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29174 and starting SCN of 10908693157 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29173 and starting SCN of 10908683795 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29172 and starting SCN of 10908674478 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29171 and starting SCN of 10908665325 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29170 and starting SCN of 10908660283 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29169 and starting SCN of 10908655368 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29168 and starting SCN of 10908650498 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 29167 and starting SCN of 10908638287 found to restore RMAN> 3,recover问题分析 去原来备份库上找到缺失的 29167到29186的dbf文件,copy到测试库(需要恢复的db服务器)的归档日志目录下,如果不知道现在归档日志,可以直接用sysdba登录查看当前归档日志目录,如下所示: 3.1,查看原来备份库上的归档信息 [oracle@xuexi4 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 2 18:35:52 2015 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> SQL> archive log list; Database log modeArchive Mode Automatic archivalEnabled Archive destination/oracle/app/oracle/flash_recovery_area/archivelog Oldest online log sequence 29185 Next log sequence to archive29187 Current log sequence29187 SQL>3.2,copy备份库上面的 29167到29186的dbf归档日志文件到测试库的归档日志目录下面 cp *29186* /tmp/rmanbakcp *29185* /tmp/rmanbak cp *29184* /tmp/rmanbak cp *29183* /tmp/rmanbak cp *29182* /tmp/rmanbak cp *29181* /tmp/rmanbak cp *29180* /tmp/rmanbak cp *29179* /tmp/rmanbak cp *29178* /tmp/rmanbak cp *29177* /tmp/rmanbak cp *29176* /tmp/rmanbak cp *29175* /tmp/rmanbak cp *29174* /tmp/rmanbak cp *29173* /tmp/rmanbak cp *29172* /tmp/rmanbak cp *29171* /tmp/rmanbak cp *29170* /tmp/rmanbak cp *29169* /tmp/rmanbak cp *29168* /tmp/rmanbak cp *29167* /tmp/rmanbak scp /tmp/rmanbak/* 192.168.121.217:/oracle/app/oracle/flash_recovery_area/archivelog/3.3,查看到原来的归档目录和测试库一样,所以尝试下继续执行recover命令,然后继续在测试库的rman界面,进行recover操作: RMAN> recover database; Starting recover at 02-FEB-15 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=385 device type=DISK starting media recovery archived log for thread 1 with sequence 29167 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29167_821708334.dbf archived log for thread 1 with sequence 29168 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29168_821708334.dbf archived log for thread 1 with sequence 29169 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29169_821708334.dbf archived log for thread 1 with sequence 29170 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29170_821708334.dbf archived log for thread 1 with sequence 29171 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29171_821708334.dbf archived log for thread 1 with sequence 29172 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29172_821708334.dbf archived log for thread 1 with sequence 29173 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29173_821708334.dbf archived log for thread 1 with sequence 29174 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29174_821708334.dbf archived log for thread 1 with sequence 29175 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29175_821708334.dbf archived log for thread 1 with sequence 29176 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29176_821708334.dbf archived log for thread 1 with sequence 29177 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29177_821708334.dbf archived log for thread 1 with sequence 29178 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29178_821708334.dbf archived log for thread 1 with sequence 29179 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29179_821708334.dbf archived log for thread 1 with sequence 29180 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29180_821708334.dbf archived log for thread 1 with sequence 29181 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29181_821708334.dbf archived log for thread 1 with sequence 29182 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29182_821708334.dbf archived log for thread 1 with sequence 29183 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29183_821708334.dbf archived log for thread 1 with sequence 29184 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29184_821708334.dbf archived log for thread 1 with sequence 29185 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29185_821708334.dbf archived log for thread 1 with sequence 29186 is already on disk as file /oracle/app/oracle/flash_recovery_area/archivelog/1_29186_821708334.dbf channel ORA_DISK_1: starting archived log restore to default destination channel ORA_DISK_1: restoring archived log archived log thread=1 sequence=29166 channel ORA_DISK_1: reading from backup piece /oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/arch_stuorcl_20150127_3070.bak channel ORA_DISK_1: piece handle=/oracle/app/oracle/flash_recovery_area/stuorcl/backupset/2015-01-27/arch_stuorcl_20150127_3070.bak tag=TAG20150127T033013 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29166_821708334.dbf thread=1 sequence=29166 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29167_821708334.dbf thread=1 sequence=29167 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29168_821708334.dbf thread=1 sequence=29168 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29169_821708334.dbf thread=1 sequence=29169 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29170_821708334.dbf thread=1 sequence=29170 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29171_821708334.dbf thread=1 sequence=29171 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29172_821708334.dbf thread=1 sequence=29172 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29173_821708334.dbf thread=1 sequence=29173 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29174_821708334.dbf thread=1 sequence=29174 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29175_821708334.dbf thread=1 sequence=29175 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29176_821708334.dbf thread=1 sequence=29176 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29177_821708334.dbf thread=1 sequence=29177 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29178_821708334.dbf thread=1 sequence=29178 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29179_821708334.dbf thread=1 sequence=29179 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29180_821708334.dbf thread=1 sequence=29180 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29181_821708334.dbf thread=1 sequence=29181 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29182_821708334.dbf thread=1 sequence=29182 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29183_821708334.dbf thread=1 sequence=29183 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29184_821708334.dbf thread=1 sequence=29184 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29185_821708334.dbf thread=1 sequence=29185 archived log file name=/oracle/app/oracle/flash_recovery_area/archivelog/1_29186_821708334.dbf thread=1 sequence=29186 unable to find archived log archived log thread=1 sequence=29187 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 02/02/2015 18:50:21 RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 29187 and starting SCN of 10909913626 RMAN>3.3,看到有报错,还是缺失归档日志包,去现在测试库/oracle/app/oracle/flash_recovery_area/archivelog/下面看了没有新的29187归档日志,所以从原来备份库上copy过来的归档日志都应该执行完了,直接试试打开open。 RMAN> alter database open resetlogs; database opened RMAN> OK,到这里rman恢复已经完全成功结束。 4,登录连接验证,验证连接报错: [oracle@xuexi4 admin]$ sqlplus "sys/sys@SC_PD"; SQL*Plus: Release 11.2.0.1.0 Production on Mon Feb 2 19:23:32 2015 Copyright (c) 1982, 2009, Oracle. All rights reserved. ERROR: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor 去检查tnsnames.ora SC_XDB =(DESCRIPTION = (ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.121.217)(PORT = 1521)) ) (CONNECT_DATA =(SERVICE_NAME = stuorcl) )) 登录去检查当前库的db_unique_name信息 SQL> show parameter name; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_file_name_convert string /home/oradata/stuorcl, /home/ oradata/pwerdes db_name string stuorcl db_unique_name string stuunq global_names boolean FALSE instance_name string stuorcl lock_name_space string log_file_name_convert string /home/oradata/stuorcl, /home/ oradata/stuorcl service_names string stuunq SQL> 发现db_unique_name是另外一个,所以将tnsnames.ora里面的service_name从stuorcl换成了stuunq,就可以连接成功了。 5,找到原来的用户下的表,导出来恢复到线上。 总结步骤: 1,scp全备文件到测试库,在备份库上查询好参数文件控制文件归档路径等信息 2,关闭测试库,启动到nomount状态,恢复参数文件控制文件 3,启动到mount状态,restore、recover操作 4,打开数据库alter database open resetlogs;---------------------------------------------------------------------------------------------------------------- <版权所有,文章允许转载,但必须以链接方式注明源地址,否则追究法律责任!> 原博客地址:http://blog.itpub.net/26230597/viewspace-1425212/ 原作者:黄杉 (mchdba) ----------------------------------------------------------------------------------------------------------------

最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台