Recovery Manager (RMAN) 提示, 窍门和误区
作为一名有经验的DBA,您可能对RMAN非常熟悉而且为您的数据库创建了RMAN脚本，并且运行了很多年。即便如此，或许您对以下的RMAN提示和窍门感兴趣，让您的DBA工作更加简单而且还能避免一些常见的误区。请继续阅读，获得更多关于RMAN ’Duplicate’命令，恢复，备份和坏块的提示和误区。
'Duplicate' 命令的误区
RMAN 11.2 Duplicate – 控制文件是还原的，而不是重新创建的
Oracle 数据库版本11.2, RMAN‘Duplicate’命令会还原备份的控制文件到目标主机而不是创建新的控制文件。所以，一定要确保有一个满足duplicate时间的控制文件备份存在。否则会遇到下面的错误。
RMAN-03002: failure of Duplicate Db command at 07/23/2012 10:09:08
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-06026: some targets not found - aborting restore
RMAN-06024: no backup or copy of the control file found to restore
下面是一个简单的测试例子，可以在运行’Duplicate’命令之前验证是否存在有效的控制文件备份。
RMAN> run {
set until time "to_date('2012 MAY 18 07:37','YYYY MON DD HH24:MI')";
restore controlfile preview;
}
注意: 请修改 'SET UNTIL TIME' 中的时间来满足具体的要求。
RMAN 11.2 活动Duplicate 误区
活动Duplicate将已装载的或者在线的数据文件通过网络拷贝到目标实例。所以，并不需要对Duplicate作准备，不过，这意味着在进行活动Duplicate的时候会对源主机和网络产生一定的工作负载。
但是，我们可以使用RMAN的’Rate’参数来对数据的流量进行限制。请注意如果使用活动Duplicate的话，需要安装补丁Patch 13483981 Throttle Network Consumption during Active Duplicate来启用RMAN的‘Rate’参数。要了解更多的信息，请参考文档1436783.1 How to Throttle Network Consumption During Rman Active Duplicate。
另外，目标数据库和源数据库都必须通过静态注册的方式注册到Oracle监听程序，而不能动态注册数据库服务。因此，配置一个能够连接到数据库的客户端并将数据库的服务信息添加到监听程序。目标实例和源实例需要相同的sys用户口令，所以，在进行duplicate之前，需要将源数据库的口令文件拷贝到目标主机。
数据块改变跟踪 (BCT) 文件
已经发现了一些数据库启用了BTC后duplicate数据库时出现的问题。文档1098638.1'ORA-19755 Using RMAN Duplicate, Tries Open The Block Change Tracking File of Source DB'列出了常见的问题。
大多数的绕开问题的方法是，确保在进行duplicate之前，由源数据库控制文件标识的BTC文件，事先存在于目标主机。您可以在指定的位置创建一个空的文件。由于BCT文件的位置保存在控制文件中，在执行基于时间点的duplicate时需要留意该文件的位置。如果源数据库的BCT文件位置或名称发生了改变，您可能会遇到错误。当BCT文件或者和它相当的空文件在目标主机上存在，能够被访问,并且符合控制文件备份中的信息，duplicate就会成功。
备份误区
默认数据库初始化参数
首先，我们强烈建议使用RMAN catalog来管理备份，请参考文档1362501.1 Demystifying the RMAN Recovery Catalog 获得更多信息。
如果您不准备使用RMAN catalog，就一定要注意数据库初始化参数'controlfile_record_keep_time'的默认值为7天，也就是说控制文件中超过这个保留期限的RMAN信息可能会被交换出去，所以需要根据您的备份策略修改这个参数的设置。请参考文档397269.1 Relation between RMAN retention period and control_file_record_keep_time 获得更多的信息。
对于BCT，默认oracle保证追踪8个级别为1的增量备份。如果您做了多于8个级别为1的增量备份，您必须调整数据库的隐含参数 _bct_bitmaps_per_file来满足您的要求并且重新启动数据库。
离线和丢失的数据文件
请注意，RMAN会备份离线的数据文件，而且在备份的过程中不会报错， RMAN只会对丢失的或者无法访问的文件报错，就像下面显示的内容：
channel ORA_DISK_1: starting piece 1 at 02 AUG 2012 12:31:13
RMAN-00571: ==========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ==========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/02/2012 12:31:14
ORA-01116: error in opening database file 9
ORA-01110: data file 9: '/opt/app/oracle/oradata/ORA112/datafile/o1_mf_lb_ts_81mpb4x8_.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
如果一个数据文件已经被离线了一段时间，在恢复的过程中oracle会查看从数据文件被离线的时间点开始的所有归档日志文件，才能把数据文件恢复到最新的状态。为了避免这样的‘惊喜’，您或许需要编写额外的脚本来查看离线的数据文件信息:
select * from v$recover_file order by 1;
select distinct(status)from v$datafile;
select FILE#,TS# , status, NAME from v$datafile
where status not in ('SYSTEM','ONLINE')
order by 1;
在正常的情况下，您的数据库中不应该包含离线的，无法访问的或者需要恢复的数据文件，这些文件应该被还原并上线。只有当数据库的某些数据文件出现问题时，才应该考虑使用像'SKIP INACESSIBLE' 和 'SET MAXCORRUPT'这样的选项作为临时的办法。
最佳实践
作为一个生产数据库，备份是必要的，除非您能够通过其他的方式重建数据库。无论数据库的容量有多大，都需要为数据库备份分配存储或磁带空间。使用下面的RMAN命令可以列出需要备份的文件:
RMAN> report need backup;
另外，如果您需要将数据库通过备份前滚到一个特定的时间点，您需要启动归档模式，并且备份前滚所需要的归档日志文件。
备份的频率会决定还原和恢复所需的时间。例如，如果您只是每个星期进行备份，那么您不得不前滚一个星期的归档日志文件！
RMAN提供了很多辅助您制定备份策略的特性，例如增量备份合并，BCT和增量备份
Restore 陷阱
还原 oracle管理的数据文件 (OMF datafiles)
当使用OMF并且数据文件在磁盘上不存在的时候，restore操作会将数据文件还原到初始化参数'db_create_file_dest'所指定的位置，并且按照OMF的规范命名。这意味着您需要保证参数'db_create_file_dest'所指向的文件系统有足够的空闲空间存放所有的数据文件。（提示：使用视图V$DATAFILE确认数据文件尺寸）。
否则，如果需要将数据文件还原到原来的位置，您需要在进行还原时关闭OMF特性。
SQL> alter system set db_create_file_dest='';
SQL> show parameter create_file
NAME TYPE VALUE
------------------------ ----------- ------------------------------
db_create_file_dest string
表空间中的离线数据文件
如果一个数据文件需要还原，只离线这个数据文件，不要离线它所在的表空间，因为，如果表空间中的一个数据文件不能被恢复并上线，表空间就不能够上线，而且您会收到以下的错误：
RMAN> sql 'alter tablespace users online';
sql statement: alter tablespace users online
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 08/02/2012 11:04:54
RMAN-11003: failure during parse/execution of SQL statement: alter tablespace users online
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/opt/app/oracle/oradata/ORA112/datafile/o1_mf_users_81mm41rn_.dbf'
丢失一个数据文件的数据或许没有丢失整个表空间的数据严重。
手动克隆
如果您需要将数据库恢复到一个新的主机作容灾或克隆，那么在整个过程的最后一步就是使用NID工具至少将数据库的ID更改。
不要使用RMAN catalog进行这种手动克隆操作。但是，如果您一定要这么做，将RMAN catalog导出，使用导出文件进行克隆。更多详细信息，请参考文档 1338193.1： How to Move/Restore DB to New Host and File System using RMAN
RMAN 和坏块
坏块可能只有当进程访问到它的时候才会被发现。即使一个成功的RMAN备份也不能保证一定不包含坏块，因为RMAN只检查物理坏块，否则，备份过程会很长并对系统产生非常大的性能影响。
默认情况下，RMAN不会检查逻辑坏块，所以，建议您定期运行RMAN命令'backup validate'以确保您能够建立一个“已知”的没有坏块的备份状态。由于这个命令是I/O密集操作，建议您不要在数据库忙碌时间运行。
即使您不使用RMAN对数据库进行备份，仍然可以使用它验证坏块。如果数据库处于非归档模式，那么需要将数据库启动到‘MOUNTED’状态。
$ rman target /
RMAN> backup validate check logical database;
当RMAN验证过坏块后，请运行下面的查询语句确认坏块列表。
SQL> select * from v$database_block_corruption;
如果以上的查询显示多个坏块信息，请参考文档472231.1:How to Find All the Corrupted Objects in Your Database获得更多信息
如果您使用RMAN备份数据库，可以使用RMAN块恢复特性对物理坏块进行恢复。注意，RMAN不能对逻辑坏块进行恢复。
RMAN> blockrecover corruption list;
或者从Oracle 11.2开始，使用下面的命令：
RMAN> recover corruption list;
在数据库级别，请考虑打开参数'db_block_checking'和' db_block_checksum'，在数据被写入磁盘前，验证数据块的一致性。请参考文档 32969.1 TECH: Database Block Checking Features获取详细信息。
容灾(DR)
RMAN提供了很多命令预览和验证备份文件，例如：
RMAN> restore database preview;
RMAN> restore database validate;
但是，无论您如何预览和验证备份文件，都不如通过定期将备份文件还原到容灾站点的方法验证您的容灾策略。将数据库备份到次要的存储（例如灾备站点）或磁带以分担存储压力，避免磁盘损坏对备份产生影响也是个好主意。
更多信息
请参考以下的文档获得更多的信息:
| 
发表于 2013-11-17 19:59:16
|
查看: 3054|
回复: 1
发表于 2013-11-21 23:49:56
|手机版|Archiver|Oracle数据库数据恢复、性能优化
IP卡
狗仔卡
分享
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡