假如现在有个数据库每天的归档量在300GB左右，需要对该数据库做容灾或备份。目前有一个具有相同操作系统平台的备份主机，而且网络条件允许，备份存储性能足够，那么笔者会毫不犹豫地选择物理Data Guard作为数据库的容灾或备份产品。选择理由很简单：
- ❑Data Guard作为Oracle自己的产品，其技术成熟完善，稳定可靠。
- ❑可以随时验证业务数据的有效性。很多第三方容灾备份产品本身就是黑盒子，只能通过界面观察容灾备份是否有效，而Data Guard随时可以校验数据的有效性，并且从Oracle 11g开始，备份端的校验工作更加简单方便。
- ❑Data Guard为免费产品，而且对硬件环境要求不高，一般来说只要存在相同操作系统的主机就可以实施Data Guard。
Data Guard作为Oracle的一款容灾备份产品，非常适合95%以上的数据库（另外5%指的是归档量特别巨大的数据库，如运行商的一些数据库或者数据仓库）。尽管Data Guard这款产品非常优秀，但由于维护它需要一定的技术能力，再加上一些客户单位不缺资金，所以很多DBA宁愿花大价钱买一些第三方的容灾备份软件也不使用Data Guard。其实Data Guard具有一些第三方容灾备份软件所不具备的功能，而且维护起来也没有想象得那么难，应该说还算比较简单。
Data Guard分为物理Data Guard和逻辑Data Guard，由于逻辑Data Guard在市面上的竞争力不够，再加上Oracle本身就有很多产品可以替代逻辑Data Guard，如Stream或Oracle GoldenGate，所以我们主要关注物理Data Guard的配置和日常运维中的一些注意点。
1.Data Guard的原理
Oracle Data Guard的前身叫做STANDBY（Oracle 8i时代的叫法）。从Oracle 9i开始，STANDBY的功能得到了进一步的完善，并且改名为Oracle Data Guard。从Oracle 10g开始，Data Guard推出了在备份端开启闪回的功能。从Oracle 11g开始，Data Guard允许备份端在只读打开模式下应用归档日志。在19C中，支持DML重定向等功能。虽然Data Guard的功能点一直在增多，但其核心原理一直未改变。
1.1.解析Data Guard原理图
❑Data Guard由主库（PRIMARY DATABASE）和备库（STANDBY DATABASE）组成。一般来讲主、备库分别位于不同的主机上。主库即生产库，主要用于日常业务操作，备库则可以选择性地运行报表业务（备库只读打开时）。物理Data Guard本质上就是数据库的备份集在异机的恢复过程。在这里，数据库备份集指的是Data Guard运行之前在备份主机上必须要有生产数据库的0级镜像备份存在。恢复指的是在0级镜像备份集基础上的应用归档日志，其中归档日志可以是手动应用，也可以是开启MRP（Media Recovery Process）进程自动应用。在Data Guard中，由于备份端通过应用归档日志来“追”生产库产生的变化，因此在部署Data Guard之前要确保生产库所有的操作都写入在线日志中了，即生产库需要打开FORCE LOGGING模式。
❑如果配置了Data Guard，在生产库产生日志后，生产端的LGWR/ARCH进程会自动将日志传到备份端指定的目录或文件中。其中LGWR进程日志传输的是在线日志，其传输方式可以配置成同步模式（Synchronous）或者异步模式（Asynchronous）。如果LGWR进程使用同步模式传输在线日志，那么生产库的LGWR进程要等到在线日志成功写入备份端STANDBY LOGFILE后才能返回成功，所以网络带宽和备份端磁盘的性能很可能会成为生产库的性能瓶颈。如果LGWR进程使用异步模式传输在线日志或者使用ARCH进程传输归档日志，那么生产库的LGWR进程不需要等到在线日志成功写入备份端STANDBY LOGFILE后就能返回成功，但存在丢失数据的风险。备份端通过RFS进程接受生产库日志。如果生产库使用LGWR进程传输在线日志，RFS进程则将在线日志写入备份端的STANDBY LOGFILE中。在生产库切换归档后，备库的ARCH进程读取STANDBY LOGFILE生成归档日志，其大小和内容与生产库的归档日志完全相同。
❑备份端的归档日志是否连续决定着Data Guard的运行是否正常。所以在生产端要使用FAL（Fetch Archive Log Process）检测备份端归档日志是否断档。
1.2.Data Guard正常运行的前提
通过1.1节的分析，Data Guard正常运行的前提如下：
❑不同的操作系统，其大小字节（ENDIAN FORMAT）可能不同，所以Oracle在线日志的块大小也可能不同。Data Guard运行正常的重要前提是备库能物理地应用归档日志，所以要求生产主机和备份主机具有相同的操作系统。从Oracle 11g开始Windows和Linux之间可以搭建Data guard，具体的内容可以参考MOS文章413484.1。
❑由于Data Guard要求生产库产生的日志能够自动传输至备份端，因此在备份端必须启动监听以便接受生产端的连接。如果需要实现主备切换功能，那么主备库之间必须能够互相连接。
❑生产端和备份端的网络带宽要满足归档日志传输的要求。如果网络带宽不能满足要求，那么生产库的日志传输就会延迟，延迟越大丢失数据的可能性越大。假设网络有30%的损耗，那么网络带宽的计算公式如下：
Required bandwidth=((Redo rate bytes per sec./0.7)*8)/1000000=bandwidth in Mbps
❑备份端存储的性能要满足应用归档日志的要求。如果存储性能不能满足要求，那么备份库的日志应用就会延迟。延迟越大，数据库高可用性越差。
需要注意的是，物理Data Guard不能防止逻辑CORRUPTION，当Oracle内部程序计算出错时，由于生产库会将计算过程及结果记录到日志文件中，因此备份端会由于应用这些日志而会出现损坏。
以下为主库由于逻辑CORRUPTION而导致的宕机，不幸的是该错误也经归档日志传播到了备库，导致了备库不可用。警告日志如下所示：
Tue May 29 19:39:54 2012 ORACLE Instance suncard(pid=9)-Error 600 encountered while recovering transaction(10，10)on object 92826. Tue May 29 19:39:54 2012 Errors in file/oracle/app/oracle/admin/suncard/bdump/suncard_smon_229562.trc: ORA-00600:internal error code,arguments:[kdourp_inorder1]，[66]，[15]，[195]， [44]，[93]，[1]，[]
2.Data Guard的保护模式
前面提到，可以将Data Guard备库可以配置成不丢数据和丢数据两种。针对不同的配置模式，Data Guard有3种保护模式，如下所示：
❑最大保护模式（MAXIMUM PROTECTION）
❑最大可用模式（MAXIMUM AVAILABILITY）
❑最大性能模式（MAXIMUM PERFORMANCE）
下面分别对3种保护模式进行说明。
2.1.最大保护模式
最大保护模式指的是事务提交时，LGWR进程不仅要写生产端的在线日志，还要调度备份端的RFS进程写STANDBY LOGFILE，只有两者全部写成功后事务提交才算完成，所以最大保护模式能保证不丢数据。当主、备主机之间网络出现故障或者备库故障时，会导致生产库不可用。最大保护模式的配置要求如下：
❑日志传输进程为LGWR。
❑网络传输模式为SYNC，即同步模式。
❑写磁盘模式为AFFIRM，即确认模式。
❑备份端必须要有STANDBY LOGFILE。
注意 最大保护模式要求备份主机具有高稳定性，网络带宽有低延迟性，且备份存储要有高性能。任何一个环节出现问题，均会引起生产数据库不可用，所以这种模式在实际生产环境中很少采用。
2.2.最大可用模式
最大可用模式和最大保护一样，也可以做到不丢数据。但最大可用模式和最大保护模式的最大区别就是当备份端故障或主备之间网络出现故障时，生产库会自动进行RESYNCHRONIZATION，由最大可用模式切换到最大性能模式，所以生产库依然能正常运行。当故障恢复时，生产库会自动恢复成最大可用模式。最大可用模式在保证数据不丢的同时，还保障了生产库的高可用性。最大可用模式的配置要求如下：
❑日志传输进程为LGWR。
❑网络传输模式为SYNC，即同步模式。设置日志传输参数时最好设置REOPEN参数，即使出现网络故障，也不会引发主库挂起。
❑写磁盘模式为AFFIRM，即确认模式。
❑备份端必须要有STANDBY LOGFILE。
注意 理论上，Data Guard配置成最大可用模式既能保证数据不丢失，当备库发生故障时也不会影响生产库。但实践表明，当备库发生问题时，尤其是主、备库之间网络不稳定时，主库还是会受到些影响，甚至挂起。
2.3.最大性能模式
在配置Data Guard时，默认采用就是最大性能模式。顾名思义，最大性能模式就是最大程度保证生产库的性能。即提交生产库事务时，LGWR进程不需要等待在线日志在STANDBY LOGFILE写入成功之后才显示成功。最大性能模式的配置要求如下：
❑日志传输进程为LGWR或者ARCH。
❑网络传输模式为ASYNC，但仅适用于LGWR进程。
❑写磁盘模式为NOAFFIRM，即非确认模式。
❑备份端不一定需要STANDBY LOGFILE，但建议配置STANDBY LOGFILE。
2.4.切换保护模式
Data Guard的保护模式之间进行切换是很简单的，以下为切换流程。
（1）确保日志传输参数LOG_ARCHIVE_DEST_N配置了相应保护模式的参数。比如，数据库处于最大保护模式，则LOG_ARCHIVE_DEST_N必须配置如下参数（其中STBY为备库的连接串，配置在tnsnames.ora文件中）：
SQL＞alter system set log_archive_dest_2='service=STBY LGWR SYNC AFFIRM...'；
SQL＞alter system set log_archive_dest_state_2=enable；
（2）如果数据库是Oracle 9.2或需要升级保护模式，则执行如下步骤：
SQL＞shutdown immediate SQL＞startup mount
（3）切换保护模式（如果执行了步骤2，则打开数据库），如下所示：
SQL＞alter database set standby database to maximize
{AVAILABILITY|PERFORMANCE|PROTECTION}；
（4）查看切换之后的生产库保护模式，如下所示：
SQL＞select protection_mode,protection_level from v$database；
