Oracle 11g物理备用数据库“实况克隆”详解(1)

【51CTO独家特稿】相比Oracle 8i和Oracle 9i，Oracle 11g在数据库备份方面做出了极大的改善，特别是作为Oracle最大可用性架构（MAA）一部分的真正应用集群（RAC）特性。Oracle 11g现在创建一个备用数据库变得更加简单了，因为恢复管理器（RMAN）支持直接从主数据库使用DUPLICATE DATABASE命令集通过网络克隆一个备用数据库，只要目标数据库是活动的即可。这意味着再也不用先生成，再传输，最后在备用数据库上通过复杂的手工方式还原和恢复主数据库的RMAN备份集了，相反，RMAN在主站点上自动生成一个转换脚本在内存中，然后在备用站点上使用这个脚本管理克隆操作，实际上不用DBA进行任何干预。

下文将集中精力讲解备用数据库“实况克隆”特性。笔者的硬件基本情况是：双核AMD Athlon 64位CPU（Winchester 420），4GB内存，主机运行的是Windows xp系统，运行VMWare Server 1.0.8访问访问虚拟数据库服务器环境，每个虚拟机使用1个CPU，1200M内存，我选择Oracle Enterprise Linux (OEL) 4.5.1（Linux内核版本2.6.9-55.0.0.0.2.ELsmp）作为虚拟机客户端操作系统。

每个VMWare虚拟机配置好后，在每个虚拟机的/etc/hosts文件中添加合适的条目，让主站点（training）和备用站点（11gStdby）之间建立起网络连接，然后在每个节点上都安装Oracle 11g数据库，最后，在主站点上创建好标准的11g R1种子数据库，包括标准的示例方案。这个数据库的ORACLE_SID是orcl，接下来就可以开始执行实况克隆操作了。

克隆前准备工作：调整主数据库

在克隆主数据库到对应的备用环境中之前，我需要对主数据库做一些调整，下面的步骤未做特别说明没有先后顺序，只要在发出DUPLICATE DATABASE命令前这些步骤都执行完了即可，在克隆操作过程中应该没有什么让人意外的东西出现。

强制记录所有的交易

大多数组织实施数据卫士配置的主要原因是保证所有交易都不丢失，但遗憾的是，默认情况下，Oracle数据库是运行在NOFORCE LOGGING模式下的，这意味着对对象的改变可能丢失，因为他们的存储属性被设为NOLOGGING，为了确保所有的改变都被记录下来，我将执行ALTER DATABASE FORCE LOGGING命令，这个命令需要在执行ALTER DATABASE ARCHIVELOG命令将数据库ARCHIVELOG模式前执行，这些命令如清单1所示。

清单1 将主数据库切换到ARCHIVELOG模式