Oracle9i数据库Data Guard实施及维护手册
By Kamus
一．Data Guard介绍
备用数据库（standby database）是ORACLE 推出的一种高可用性(HIGH AVAILABLE)数
据库方案，在主节点与备用节点间通过日志同步来保证数据的同步，备用节点作为主节点的
备份，可以实现快速切换与灾难性恢复。
ORACLE 从7.3 才开始支持standby database。7.3.x-8.0.x 需要手工拷贝所有归档日志并
手工同步，从ORACLE815开始，开始支持多节点复制，并实现了自动同步，但是这种同步
是数据异步模式的，可能引起数据丢失。
Oracle9i的Data Guard是对Oracle8i中Standby Database功能的加强，而Standby Database技术出现的主要初衷就是为了容灾（Disaster Recovery），所以具有更强大功能的Data Guard毫无疑问成了Oracle数据库高可用性解决方案中首选使用的产品。
Oracle 提供支持高可用性 (high availability) 相关产品主要有下面几种：
(1) Oracle Fail Safe on NT
(2) Oracle Real Application Cluster (RAC)
(3) Oracle Parallel Fail Safe
(4) Oracle Advanced Quening
(5) Oralce Advanced Replication
(6) Oracle Data Guard
这几种产品中，最让人困惑的是如何在 RAC，Data Guard 和 Advanced Replication 中选择适合自己生产环境的高可用性产品。
因此我就先将这三种产品做一下比较：
RAC (Oracle Real Application Cluster)
RAC的前身是Oracle8i中的OPS（Oracle Parallel Server），RAC 是多个单CPU机或
SMP(Symmetric Multi-Processing system) 或者MPP(Massively Parallel Processing)的cluster 。cluster 里面不同的服务器使用一个(一般是一个)或多个oracle instances 与一个database 连接。 主要的技术特点：
(1) 数据库中所有的数据文件，控制文件和重作日志文件都是建立在裸设备（raw devices）上的，虽然随着OCFS的推出，在某些平台上面已经开始支持Cluster文件系统，但是总体来说RAC在技术方面对操作系统的设置有很高的依赖性，需要有Cluster软件的支持，难度比较大。
(2)每个数据库实例都有自己单独的联机重作日志组，因此在做备份和恢复的时候，需要特殊的处理。
(3)RAC的存储方面并没有额外的冗余，因此在介质损坏的情况下，还是需要依靠RAID 等磁盘冗余方案来支持。
软件许可证方面，RAC并未包括在数据库使用许可证 (license) 之内，需要额外购买；同样，Oracle 产品的技术支持，也需在数据库支持之外另外购买 OPS/RAC 部分。
总体来说，RAC的设置与维护还是比Data Guard复杂和昂贵得多。
高级复制(Advanced Replication )
主要的技术特点：
(1) Replication 使用分布式数据库技术在多个站点之间共享数据。
(2) Replicated Database 和Distributed Database 并不一样，在分布式数据库系统中数据在
多个站点同时有效，但是一个表只会存在于一个站点中，而对于Replication 来说相同
的数据将同时存在于多个站点中。
(3) 使用replication 的原因：
1) Availability：也就是提供了优秀的failover保护
2) Performance：由于有多个server，所以可以将用户业务分布在不同的server 上
3) Disconnected computing：实体化视图允许用户在和master 断开后使用数据库
的子集，在重新连接上master 之后再进行两者的同步。
4) Network load reduction：由于有多个server，所以可以减少master 的网络请
求
5) Mass deployment：通过变量产生自定义的实体化视图以满足多种需求
(4) 在不同的Oracle 发行版本之间以及不同操作系统的Oracle 之间都可以使用Advanced Replication。这是高级复制的最大优势所在。而RAC和Data Guard都需要操作系统和数据库版本相同。
高级复制不需要除数据库之外额外的使用许可 (license) 。
高级复制要对需要同步的每个数据库对象都进行单独的复制生成准备工作，所以当数据库中存在大量对象需要同步的话，高级复制的初期准备工作非常耗时。而且高级复制对于DDL操作不能很好支持，必须要使用特殊的包来执行DDL操作，才能将操作复制到远方数据库。所以高级复制作为一个整体数据库的容灾方案并不十分理想，只有在由于费用问题，要求灾备数据库和主数据库的硬件架构不同的情况下，才应该选择这种方案。
Data Guard
与RAC或者OPS比较 Data Guard 在高可用性方面的使用性，可以从几个方面来探讨：
(1) 数据库备份：Data Guard克隆了原始数据库，因此原始数据库有备份，具有灾备要求的冗余量；而 RAC/OPS 只有一份数据库，如果数据所在的硬盘发生了问题，需要另外的方法(比如RAID)解决。
(2) 服务器的数量及利用率：RAC/OPS 至少需要双机支持，支持动态负载平衡，对於大量用户访问的环境，可以在多个服务器同时处理用户的请求。在多机系统环境，如果尚有一台服务器运行正常，不会造成整个数据库系统由于故障彻底停机。Data Guard可以设置在同一个服务器上面，理论上支持单机环境。
(3) 故障停机时间：如上面所说，OPS/RAC 环境只要还有一台服务器正常运行，就不会造成停机；Data Guard环境中，primary 数据库到 Standby 数据库的切换，至少需要几分钟的停机时间。
(4) 费用：使用许可证方面，Data Guard不需要购买数据库之外的使用许可。同时在维护费用方面，OPS/RAC 的实施也相对复杂，人力、物力相对昂贵。
通过上面几种产品的比较，再分析此次客户对于灾备的硬件投入和功能要求，我们认为Data Guard是比较合适的方案。
首先此次灾备环境中使用的都是SUN的小型机，符合Data Guard对于服务器同构的要求，其次由于灾备库在上海，而主库在北京，也同样满足Data Guard对于HA的要求。
而Data Guard在也同样能够满足最多丢失一分钟的数据，并且使用灾备库作为历史查询服务器这样的功能需求。
二．Data Guard类型的比较
Oracle9i在Data Guard的配置方面提供了几种不同的类型，根据客户对于高可用性的不同要求，可以选择不同的Data Guard类型。
下面对于Data Guard的几种类型作一个列举和比较。
Data Guard环境中包含一个产品数据库，这是正常运行用以支撑日常业务的主数据库，称为Primary Database。另外包含一个或者多个灾备数据库，称为Standby Database。
按照备用库（Standby Database）应用归档日志的不同方式，Standby Database可以分为物理备用库（Physical Standby）和逻辑备用库（Logical Standby）。
按照主数据库（Primary Database）的保护模式，整个Data Guard环境分为最大数据保护模式（MAXIMIZE PROTECTION），最大可用性模式（MAXIMIZE AVAILABILITY），最大性能模式（MAXIMIZE PERFORMANCE）。
按照主库向备用库传递重作信息的方式，可以分为ARCH方式和LGWR方式。
物理备用库可以运行在数据库三种保护模式中的任何一种模式下，逻辑备用库只可以运行在最大可用性模式或者最大性能模式下。无论物理备用库还是逻辑备用库都可以在传输日志上采用ARCH方式或者LGWR方式。
物理备用库（Physical Standby）：
提供了一份跟主数据库在物理级别上完全相同的copy，指在数据库的block级别都是完全相同的，比如数据库表中记录的rowid。物理备用库是通过不断地恢复Primary Database传入的重作日志数据信息来达到跟主数据库保持同步。
物理备用库在处于自动恢复重作日志信息的状态下，无法提供查询服务。因为此时的备用数据库并不是处于正常打开的状态，数据库的非sysdba用户无法登录备用库，自然也就无法进行普通的查询业务。
逻辑备用库（Logical Standby）：
指在逻辑上跟主数据库保持一致，但是在物理层面上跟主数据库并不相同。逻辑备用库是通过将Primary Database传入的重作日志数据信息转化为SQL语句，然后在备用库上重新执行来达到跟主数据库保持同步。
逻辑备用库在应用重作信息的同时也可以提供查询功能。但是由于逻辑备用库应用重作日志的方式限制，所以逻辑备用库在功能和性能上面都有所限制。以下是逻辑备用库的一些限制条件。
1. 以下数据类型不被支持：
NCLOB ，LONG ，LONG RAW ，BFILE ，ROWID ，UROWID
2. 以下操作不被支持：
ALTER DATABASE ，ALTER SESSION ，ALTER SNAPSHOT
ALTER SNAPSHOT LOG ，ALTER SYSTEM SWITCH LOG
CREATE CONTROL FILE ，CREATE DATABASE ，
CREATE DATABASE LINK ，CREATE PFILE FROM SPFILE ，
CREATE SCHEMA AUTHORIZATION
CREATE SNAPSHOT ，CREATE SNAPSHOT LOG ，CREATE SPFILE FROM PFILE
CREATE TABLE AS SELECT FROM A CLUSTER TABLE
DROP DATABASE LINK ，DROP SNAPSHOT ，DROP SNAPSHOT LOG
EXPLAIN ，LOCK TABLE ，RENAME ，SET CONSTRAINTS ，
SET ROLE ，SET TRANSACTION
3. 高级队列的管理和物化视图的刷新不被支持
4. 要求每张表应该有主键或者唯一性索引 ，如果必须有没有唯一性标识的表，那么可以激活Primary库的supplemental logging属性，但是这样将会在重作日志中记录该表中每一条记录的所有字段信息，会大大增加重作日志的记录量。
以下是Data Guard环境中物理备用库和逻辑备用库的配置图。
最大数据保护模式（MAXIMIZE PROTECTION）
提供最高等级的数据保护，重作信息从主库同步送到备用库。直到备用库成功接收重作信息，主库上的事务才会提交。如果由于网络等问题，导致备用库不可用，那么主库也同时会被关闭。这种模式保证了完全没有数据丢失。
最大可用性模式（MAXIMIZE AVAILABILITY）
在备用库正常的情况下，该模式提供了跟“最大数据保护模式”一样的机制，保证没有任何数据丢失。如果备用库不可用，那么将转换到“最大性能模式”，操作可以在主库上继续执行。当备用库重新可用之后，将会继续同步。但是如果在同步完成之前，主库由于故障损坏，将会丢失数据（当然，可以通过RAID，RMAN等方式尽量保护主库即使出现故障也不丢失数据）。
最大性能模式（MAXIMIZE PERFORMANCE）
这种模式下，主库上的重作信息是异步传递到备用库上，不论备用库上是否已经成功接收了重作信息，主库上的操作都会成功执行。所以这种模式提供了最好的性能，但是最低的数据保护。这是Oracle9i配置Data Guard的默认模式。
ARCH方式
当主库归档联机重作日志文件时，ARCH归档进程在归档到本机的同时，将重作数据传递到备用库，由备用库端的RFS进程（Remote File Server）接收，生成备用库端的归档日志文件，然后由备用库端的MRP进程（物理备用库类型）或者LSP进程（逻辑备用库类型）将归档日志文件恢复到备用库中。
传递方式如图：
LGWR方式
物理备用库类型下，主库的LGWR进程在将重作数据写到本地联机重作日志文件中的同时，将重作数据传递到备用库，备用库的RFS进程将收到的数据写入本地的备用重作日志文件（Standby Redo Log）中。当主库日志切换时也触发备用库的日志切换，切换发生时，备用库的归档进程将重作日志文件归档，然后由备用库端的MRP进程将归档日志文件恢复到备用库中。
传递方式如图：
逻辑备用库类型下，不可以创建备用重作日志文件（Standby Redo Log），所以处理流程跟物理备用库稍有不同。
主库的LGWR进程在将重作数据写到本地联机重作日志文件中的同时，将重作数据传递到备用库，备用库的RFS进程将收到的数据写入本地的归档日志文件中。当主库日志切换时也触发备用库的日志切换，切换发生时，备用库的归档进程完成归档日志文件的最后生成，然后由备用库端的LSP进程提取归档日志文件中的SQL语句，重新在备用库上运行一遍。
传递方式如图：
最后上述所有类型或者方式互相搭配进行一个比较。
|
Maximum Protection |
Maximum Availability |
Maximum Performance |
|
|
重作传递方式 |
LGWR |
LGWR |
LGWR或者ARCH |
|
网络传递模式 |
同步 |
同步 |
当使用LGWR传递方式时为异步方式，如果使用ARCH传递方式，那么不牵涉联机重作数据的网络传输 |
|
磁盘写入选项 |
AFFIRM |
AFFIRM |
NOAFFIRM |
|
是否需要备用重作日志文件 |
需要 |
只在物理备用库类型中需要 |
如果物理备用库使用LGWR传递方式，那么需要 |
|
备份库类型 |
物理 |
物理或逻辑 |
物理或逻辑 |
三．硬件配置
四．软件配置
五．实施Data Guard前提条件和注意事项
灾备环境中的所有节点必须安装相同的操作系统，但是操作系统的版本可以不相同。
灾备环境中的所有节点必须安装完全相同版本的Oracle数据库软件，包括版本号和发布号，比如必须都是Oracle
主库必须处于归档（ARCHIVELOG）模式。
灾备环境中所有节点的硬件和操作系统架构必须相同，比如主节点是Sparc 64-bit SunOS，那么备用节点也必须是Sparc 64-bit SunOS。
主库可以是单实例，也可以是RAC。
主节点和备用节点之间的硬件配置可以不同，比如CPU数量，内存数量，存储的配置等等。
配置灾备环境的数据库用户必须具有SYSDBA权限。
cluster环境中两个节点的tnsnames.ora, listener.ora, sqlnet.ora, spfile, pfile必须保证相同