翻译mos文章rman复原的先决条件

                            进行rman复原时要确认的条目

                             Checklist for an RMAN Restore (文档 ID 1554636.1)

适用于oracle10.2.0.1及以后的企业版
在使用rman复原之前，有一些确定的行为去确认rman复原是否能够成功。
不是通过等待执行花费数小时的rman复原失败却只是发现某些
导致失败的问题都是可以避免的，比如丢失备份片，而是提前的获取完全的
环境信息，了解复原的可执行性。
解决方案


1）确认操作系统版本和数据库版本
一般来讲，应该复原到相同的操作系统版本和数据库版本。如果复原到一个不同的操作系统
版本，需要执行一个位端的转换。
如果要复原到一个高版本的数据库需要执行一个数据库升级。
不同的操作系统和数据库版本之间有复杂的组合，详细信息参考(Doc ID 369644.1)
2）确认空间需求
随着数据库的运行数据增长和收缩，空间的使用可能很大
使用REPORT SCHEMA来确认文件目录或者磁盘组的空间是否够用






RMAN> run {
set until time "to_date('2013 JUN 11 15:31','YYYY MON DD HH24:MI')";
report schema;
}2> 3> 4> 


executing command: SET until clause


using target database control file instead of recovery catalog
Report of database schema for database with db_unique_name ORA112


List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    830      SYSTEM               ***     /opt/app/oracle/oradata/ORA112/system01.dbf
2    980      SYSAUX               ***     /opt/app/oracle/oradata/ORA112/sysaux01.dbf
3    205      UNDOTBS1             ***     +DG1/ora112/datafile/undotbs1.256.807783447
4    100      USERS                ***     +DG1/ora112/datafile/users.264.817484131
5    345      EXAMPLE              ***     /opt/app/oracle/oradata/ORA112/example01.dbf
6    100      MYTS                 ***     +DG1/ora112/datafile/myts.267.816708795


从上面的示例看出表空间、数据文件、空间需求。
数据文件的目录和磁盘组必须是预先存在的并且有足够空间存放这些数据文件，否则你需要使用set newname 来
复原一个可替换的并且有权限和空间的位置。


注意：如果使用备份片要用到归档日志，那么就要考虑归档日志的空间。


3）备份脚步和日志
准备rman备份，手边需要有备份脚本和日志，rman命令的的输出结果将默认以标准方式显示。
如果交互的运行，结果就会显示在屏幕上。也可以使用命令将结果输出到文本中。
RMAN> SPOOL TRACE TO X.OUT
SET ECHO ON
# place the rest of your rman commands here
SPOOL TRACE OFF;


一个rman备份将帮助你确认备份是否成功，哪些备份确实备份过，什么时候开始的备份，什么时候结束的的备份还有备份
执行的时间。
如果复原到相同的主机，建议临时关闭备份的计划任务。既然开启了rman复原，就不希望有备份工作在运行，另外，需要的
归档日志不能被移走。
4)如果用来复原控制文件，rman将执行一个隐藏的校验并且将信息记录到FRA里如果FRA被启用的话。这个过程会延长复原】
时间，并且如果数据库resetlogs过会产生incarnation问题


如果你不需要这些文件在fra中，你可以从你的fra目录中移走他们或者在复原期间禁用他们。


5）获得rman备份情况的一个概览


快速的获得备份的一个概览
RMAN> spool trace to bk.out;
set echo on;
list incarnation of database;
list backup summary;
list backup of datafile 1;
list copy of datafile 1;
spool trace off;
6）复查复原和修复
你可以使用RESTORE ... PREVIEW 到任何复原操作中来创建一个在复原操作中被需求的的备份列表，列表中
还包复员后的scn号。这个命令访问rman档案库查询备份元数据，并不实际的读取备份文件，只是单纯的确认他们
是否可以被复原。


块恢复通常这样被复查
RMAN> blockrecover corruption list preview;


整个库的复原复查情况可以在一条命令中写道
RMAN> run {
set until time "to_date('2013 JUN 11 15:31','YYYY MON DD HH24:MI')";
restore controlfile database preview;
}


一个复原复检将列出整个复原和修复过程中需要的备份。按照这个列表，你可以事先确认备份片的存在信息


有用的复原复查项目


RMAN> run {
2> set until time "to_date('2014 MAY 02 11:22','YYYY MON DD HH24:MI')";
3> restore database preview;
4> }
...
BS Key  Type LV         Size            Device Type    Elapsed Time   Completion Time     
------- ---- --         ----------      -----------    ------------   --------------------
266     Incr 0 [1]      1.49G[2]        DISK[3]        00:01:31[4]       02 MAY 2014 11:21:57 [5]
        BP Key: 268   Status: AVAILABLE[6]  Compressed: NO[7] Tag: TAG20140502T112027
        Piece Name: /opt/app/oracle/fra/ORA112/backupset/2014_05_02/o1_mf_nnnd0_TAG20140502T112027_9p5wpwp4_.bkp [8]


  List of Datafiles in backup set 266 [9]
  File LV Type Ckp SCN    Ckp Time             Name
  ---- -- ---- ---------- -------------------- ----
  1    0  Incr 53204035   02 MAY 2014 11:20:27 /opt/app/oracle/oradata/ora112b/data_D-ORA112_TS-SYSTEM_FNO-1
  4    0  Incr 53204035   02 MAY 2014 11:20:27 /opt/app/oracle/oradata/ora112b/data_D-ORA112_TS-USERS_FNO-4
  7    0  Incr 53204035   02 MAY 2014 11:20:27 /opt/app/oracle/oradata/ora112b/data_D-ORA112_TS-RMAN_TS_FNO-7
  9    0  Incr 53204035   02 MAY 2014 11:20:27 /opt/app/oracle/fra/ORA112/datafile/o1_mf_fda_ts_9nw1gqt5_.dbf
...
  List of Archived Logs in backup set 268
  Thrd Seq     Low SCN    Low Time             Next SCN   Next Time
  ---- ------- ---------- -------------------- ---------- ---------
  1    317     53204027   02 MAY 2014 11:20:25 53204084   02 MAY 2014 11:22:03
Media recovery start SCN is 53204027
Recovery must be done beyond SCN 53204036 to clear datafile fuzziness[10]


[1] This is an incremental level 0 backup
[2] The backuppiece is 1.49G in size 
[3] This is a backup to DISK rather than tape
[4] The backuppiece took 1 minute and 31 seconds to backup
[5] The time when this backuppiece completed
[6] The backuppiece is available for use according to the RMAN repository
[7] This is NOT a compressed backup
[8] This is the backuppiece. It must exist on disk for use:


1.这是一个0级增量备份。
2.备份片式1.49G
3.这个备份在硬盘上不实在磁带上
4.产生这个备份片用了1分钟31秒
5.备份完成的时间
6.这个备份片在rman档案库里是有效的
7.这个备份没有压缩
8.这个备份片需要在磁盘上的确定位置来使用
9.备份片包含哪些数据文件
10.这只是一个告知信息，数据库需要在这个告知的scn基础上进行set until time/scn命令的操作进行修复或 打开数据库。


a 复查控制文件复原
如果复原一个数据库到过去的某个时间点，你需要复原相依的控制文件，因为控制文件记录了那个时间的数据库结构。这一点
尤其重要，如果在过去的时间里数据库增加或删除表空间或数据文件


一个关于控制文件复原的复查例子


Recovery Manager: Release 11.2.0.3.0 - Production on Tue Jun 18 22:27:47 2013


Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.


connected to target database: HRPRD91 (DBID=756818178, not open)


RMAN> run {
2> allocate channel 'dev_0' type 'sbt_tape'
3> parms 'SBT_LIBRARY=/opt/omni/lib/libob2oracle8_64bit.so,ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=HRPRD91,OB2BARLIST=VTL_hp909npc_HRPRD91_logs1)';
set until time "to_date('Jun 18 2013 08:00:00','Mon DD YYYY HH24:MI:SS')";
4> restore controlfile preview;
5> 6> }


using target database control file instead of recovery catalog
allocated channel: dev_0
channel dev_0: SID=6 device type=SBT_TAPE
channel dev_0: Data Protector A.06.20/406


executing command: SET until clause


Starting restore at 06/18/2013 22:28:04




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




BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
52857   Full    19.00M     SBT_TAPE    00:00:09     06/18/2013 04:02:04
       BP Key: 52857   Status: AVAILABLE  Compressed: NO  Tag: TAG20130618T040153
       Handle: VTL_hp909npc_HRPRD91_logs1<HRPRD91_53186:818395315:1>.dbf [1]  Media: 0a226c50:513b5915:6b9f:12cc [2]
 Control File Included: Ckp SCN: 238614135722   Ckp time: 06/18/2013 04:01:55


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




BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
52858   430.50M    SBT_TAPE    00:00:36     06/18/2013 09:01:10
       BP Key: 52858   Status: AVAILABLE  Compressed: NO  Tag: TAG20130618T090033
       Handle: VTL_hp909npc_HRPRD91_logs1<HRPRD91_53187:818413234:1>.dbf [1]   Media: 0a226c50:5091d0b9:120c:4f13 [2]


 List of Archived Logs in backup set 52858
 Thrd Seq     Low SCN    Low Time            Next SCN   Next Time
 ---- ------- ---------- ------------------- ---------- ---------
 1    14822   238614135104 06/18/2013 04:00:28 238614215594 06/18/2013 08:40:24 [3]
validation succeeded for backup piece
Media recovery start SCN is 238614135722
Recovery must be done beyond SCN 238614135722 to clear datafile fuzziness
validation succeeded for backup piece
Finished restore at 06/18/2013 22:28:13
released channel: dev_0


[1] "Handle" is the backuppiece name
[2] Media is the lable given to the tape
[3] This is the achivelog needed to recover this controlfile


That is, you need to ensure that the backuppiece [1] on tape [2] is loaded and ready for use




1.备份片的路径名称
2.介质在磁带上的标签
3.控制文件复原需要的归档日志
就是说，你需要确定备份集在磁带上名称信息及是否加载可用。


b）
数据库复原复查


一个指定时间的复原复查例子


RMAN> spool trace to res.prev
run {
set until time "to_date('2013 JUN 11 15:31','YYYY MON DD HH24:MI')";
restore database preview;
}
spool trace off


从复查结果中寻找这样的错误提示。“某个数据文件不能被执行”，“某个数据文件将被创建”，“归档日志没有备份”，
“某个文件被数据库备份排除”,"不能定位某个备份集的备份片”等等


RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 4 found to restore


RMAN-06100: no channel to restore a backup or copy of datafile 18
no channel to restore a backup or copy of log thread 1 seq 186 lowscn 609321




只读的数据文件


在10g 只读文件仅在使用check readonly的时候被复原。然而在11g，只读数据文件都是默认被复原的，除非使用skip readonly命令
跳过
datafile 29 not processed because file is read-only


如果复原到一个新的主机，你希望只读数据文件被复原么


数据文件将被创建而不是复原


在复检信息中，如果你获得如下信息：
data file 25 will be created automatically during restore operation


这时你要确认为什么看起来没有这个数据文件的备份，却生成了该文件。如果你有在复原时间段的包含该文件的创建和完成信息的
归档日志，那么这个创建过程是没有问题的。否则，你要确认rman是在使用的这个备份，甚至有这个备份么


如果你得到信息1号文件将被创建，那是有问题的。因为1号文件是system数据文件，不能够被复原进程创建，只能从备份中复原。


丢失归档
复原将会用当归档日志 你需要找到包含归档的备份片或者，单独的归档备份


RMAN-06100没有通道来复原备份或者镜像


这是一个没有合适通道被分配执行复原的标志，例如，如果备份存放在磁带上确定分配一个sbt通道


c）修复复查
修复复查功能实从11g开始支持的
一旦数据库复原完成，挂载，这时可以使用修复复查：


RMAN> run {
set until time "to_date('2013 JUN 11 15:31','YYYY MON DD HH24:MI')";
recover database preview;
}


7）执行复原需要多长时间
如果复原到相同的主机，并且的环境都一样，那么复原操作的时间基本与备份的时间相同。从复原复查里查看
执行时间
BS Key  Type   LV   Size        Device Type  Elapsed Time  Completion Time     
------- ----   --  ----------   -----------  ------------  --------------------
258     Full       1.49G        DISK         00:01:33      02 MAY 2014 10:14:55


8）有效的复原
如果选择RESTORE ... PREVIEW命令，你可以使用RESTORE ... VALIDATE HEADER命令。除了能够列出复原和修复所需要的文件外，
RESTORE ... VALIDATE HEADER命令可以验证文件头来确定在磁盘上或者其他介质上的文件的记录是否与在rman档案库的元数据
一致。


当你打算进行复原和修复操作时，这两个命令能确定备份中可用的和有效的备份，这样你可以在rman中直接指定或者避开某些备份






 RMAN> restore database validate;


Starting restore at 26 JUN 2013 14:41:23
using channel ORA_DISK_1
using channel ORA_DISK_2


skipping datafile 6; already restored to file +DG1/ora112/datafile/myts.267.816708795
datafile 7 will be created automatically during restore operation
channel ORA_DISK_1: starting validation of datafile backup set
channel ORA_DISK_2: starting validation of datafile backup set
channel ORA_DISK_1: reading from backup piece /opt/app/oracle/fra/ORA112/backupset/2013_06_11/o1_mf_nnndf_TAG20130611T152919_8vfffl84_.bkp
channel ORA_DISK_2: reading from backup piece /opt/app/oracle/fra/ORA112/backupset/2013_06_11/o1_mf_nnndf_TAG20130611T152919_8vffflhp_.bkp
channel ORA_DISK_2: ORA-19870: error while restoring backup piece 


/opt/app/oracle/fra/ORA112/backupset/2013_06_11/o1_mf_nnndf_TAG20130611T152919_8vffflhp_.bkp
ORA-19505: failed to identify file "/opt/app/oracle/fra/ORA112/backupset/2013_06_11/o1_mf_nnndf_TAG20130611T152919_8vffflhp_.bkp"
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3


channel ORA_DISK_1: piece handle=/opt/app/oracle/fra/ORA112/backupset/2013_06_11/o1_mf_nnndf_TAG20130611T152919_8vfffl84_.bkp 


tag=TAG20130611T152919
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: validation complete, elapsed time: 00:00:03
failover to previous backup


datafile 7 will be created automatically during restore operation
channel ORA_DISK_1: scanning datafile copy /opt/app/oracle/fra/ORA112/datafile/o1_mf_system_8v2s25b8_.dbf
channel ORA_DISK_2: scanning datafile copy /opt/app/oracle/fra/ORA112/datafile/o1_mf_example_8v2s48b4_.dbf
failover to previous backup


datafile 7 will be created automatically during restore operation
Finished restore at 26 JUN 2013 14:41:53




RMAN> list backuppiece '/opt/app/oracle/fra/ORA112/backupset/2013_06_11/o1_mf_nnndf_TAG20130611T152919_8vffflhp_.bkp';




List of Backup Pieces
BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
43      43      1   1   AVAILABLE   DISK        /opt/app/oracle/fra/ORA112/backupset/2013_06_11/o1_mf_nnndf_TAG20130611T152919_8vffflhp_.bkp




从上面的备份中我们可以看到
/opt/app/oracle/fra/ORA112/backupset/2013_06_11/o1_mf_nnndf_TAG20130611T152919_8vffflhp_.bkp 这个备份片虽然显示有效
但是实际物理备份已经丢失，因此你要在实际复原前定位到这个备份片。
9）陷阱
没有日志记录
没有日志记录的操作是需要注意的。数据库的初始状态是强制日志模式么。当你执行没有日志记录的操作时一旦数据库修复将导致没有日志的
故障