RAC+ASM在单机上恢复的过程-技术开发专区

RAC+ASM在单机上恢复的过程

作者：IT168 ZALBB 编辑：晓熊 2008-08-04 09:31 来源：IT168�

-- 查看恢复数据库需要的备份集，日志信息
RMAN> restore database preview summary;

Starting restore at 2008-06-26 15:21:43
using channel ORA_DISK_1

List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- ------------------- ------- ------- ---------- ---
899 B A A DISK 2008-06-20 12:02:50 1 1 YES TAG20080620T120249
Media recovery start SCN is 26818078494
Recovery must be done beyond SCN 26818078494 to clear data files fuzziness
Finished restore at 2008-06-26 15:21:45

-- 查看库的数据文件的路径。
RMAN> report schema;

RMAN-06139: WARNING: control file is not current for REPORT SCHEMA
Report of database schema

List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 0 SYSTEM *** +ASMDISK/ccdb/datafile/system.256.648572847
2 0 UNDOTBS1 *** +ASMDISK/ccdb/datafile/undotbs1.258.648572847
3 0 SYSAUX *** +ASMDISK/ccdb/datafile/sysaux.257.648572847
4 0 USERS *** +ASMDISK/ccdb/datafile/users.259.648572847
5 0 UNDOTBS2 *** +ASMDISK/ccdb/datafile/undotbs2.269.648572973
6 0 UNICALL2X *** +ASMDISK/ccdb/datafile/unicall2x.279.648578659
7 0 UNICALL2X_IDX *** +ASMDISK/ccdb/datafile/unicall2x_idx.280.648578725

List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1 0 TEMP 32767 +ASMDISK/ccdb/tempfile/temp.268.648572939

-- 恢复数据库，其中需要重新指定恢复时，数据文件的存放路径，由ASM到文件系统。
RMAN> run
{allocate2> channel d1 type disk;
set newname for datafile 1 to '/oradata/ccdb/system.dbf';
set newname for datafile 2 to '/oradata/ccdb/undotbs1.dbf';
set newname for 3> datafile 3 to '/oradata/ccdb/sysaux.dbf';
set newname for da4> 5> 6> tafile 4 to '/oradata/ccdb/users.dbf';
set newname for data7> file 5 to '/oradata/ccdb/undotbs2.dbf';
set newname for datafile 6 to '/orada8> ta/ccdb/unicall2x.dbf';
set newname for datafile 7 to9> '/oradata/ccdb/unicall2x_idx.dbf';
restore database;
switch d10> atafile 11> all;
release c12> hannel d1;
}13>

released channel: ORA_DISK_1
allocated channel: d1
channel d1: sid=1090 devtype=DISK

executing command: SET NEWNAME

Starting restore at 2008-06-26 15:29:49

channel d1: starting datafile backupset restore
channel d1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /oradata/ccdb/system.dbf
restoring datafile 00002 to /oradata/ccdb/undotbs1.dbf
restoring datafile 00003 to /oradata/ccdb/sysaux.dbf
restoring datafile 00004 to /oradata/ccdb/users.dbf
restoring datafile 00005 to /oradata/ccdb/undotbs2.dbf
restoring datafile 00006 to /oradata/ccdb/unicall2x.dbf
restoring datafile 00007 to /oradata/ccdb/unicall2x_idx.dbf
channel d1: reading from backup piece /oradata/orabak/databackup/db_CCDB_900_1_20080620
channel d1: restored backup piece 1
piece handle=/oradata/orabak/databackup/db_CCDB_900_1_20080620 tag=TAG20080620T120035
channel d1: restore complete, elapsed time: 00:04:33
Finished restore at 2008-06-26 15:34:23

datafile 1 switched to datafile copy
input datafile copy recid=8 stamp=658424064 filename=/oradata/ccdb/system.dbf
datafile 2 switched to datafile copy
input datafile copy recid=9 stamp=658424064 filename=/oradata/ccdb/undotbs1.dbf
datafile 3 switched to datafile copy
input datafile copy recid=10 stamp=658424064 filename=/oradata/ccdb/sysaux.dbf
datafile 4 switched to datafile copy
input datafile copy recid=11 stamp=658424064 filename=/oradata/ccdb/users.dbf
datafile 5 switched to datafile copy
input datafile copy recid=12 stamp=658424064 filename=/oradata/ccdb/undotbs2.dbf
datafile 6 switched to datafile copy
input datafile copy recid=13 stamp=658424064 filename=/oradata/ccdb/unicall2x.dbf
datafile 7 switched to datafile copy
input datafile copy recid=14 stamp=658424064 filename=/oradata/ccdb/unicall2x_idx.dbf

released channel: d1

-- 作介质恢复，注意RMAN最后的提示信息，thread 2 seq 688 lowscn 26818080041。
RMAN> recover database;

Starting recover at 2008-06-26 15:38:07
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=1090 devtype=DISK

starting media recovery

channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=2 sequence=687
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=695
channel ORA_DISK_1: reading from backup piece /oradata/orabak/logbackup/log_CCDB_901_1_20080620
channel ORA_DISK_1: restored backup piece 1
piece handle=/oradata/orabak/logbackup/log_CCDB_901_1_20080620 tag=TAG20080620T120249
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
archive log filename=/oralog/ccdb/1_695_648572915.dbf thread=1 sequence=695
archive log filename=/oralog/ccdb/2_687_648572915.dbf thread=2 sequence=687
unable to find archive log
archive log thread=2 sequence=688
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 06/26/2008 15:38:21
RMAN-06054: media recovery requesting unknown log: thread 2 seq 688 lowscn 26818080041

-- 而从库中归档日志的日志号，scn 号的情况，可以看出，归档日志只有thread 2 日志号为 687,该日志的最高scn 小于 26818080041
-- 故，可以断定，上面的介质恢复错误，是因为缺少归档日志的原因，由于上上步的restore database preview summary 已经说明:
-- 介质恢复需要超过 SCN 26818078494，才能清除库的模糊信息，而上面的步骤要求的SCN 26818080041,已经超过26818078494，故：
RMAN> list backup of archivelog all;

List of Backup Sets
===================

BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
899 1.62M DISK 00:00:01 2008-06-20 12:02:50
BP Key: 901 Status: AVAILABLE Compressed: YES Tag: TAG20080620T120249
Piece Name: /oradata/orabak/logbackup/log_CCDB_901_1_20080620

List of Archived Logs in backup set 899
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- ------------------- ---------- ---------
1 695 26818077573 2008-06-20 12:00:05 26818080043 2008-06-20 12:02:40
2 687 26818077558 2008-06-20 11:59:51 26818080041 2008-06-20 12:02:27

-- 故：open resetlogs 操作肯定成功。

RMAN> alter database open resetlogs;

database opened

RMAN>

第1页：背景介绍第2页：准备工作，把备份集拷贝到IBM1下第3页：恢复操作过程第4页：删除不存在的备份集第5页：查看恢复数据库需要的备份集，日志信息第6页：分开执行步骤5和步骤10

关注我们