物理 standby
我们知道物理 standby 与 primary 数据库完全一模一样 ( 默认情况下，当然也可以不一样，事无绝对嘛 ) ， Dataguard 通过 redo 应用维护物理 standby 数据库。通常在不应用恢复的时候，可以以 read-only 模式打开，如果数据库指定了 flashback area 的话，也可以被临时性的置为 read-write 模式。
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

物理 standby 所使用的 redo 应用技术使用最底层的恢复机制，这种机制能够绕过 sql 级代码层，因此效率最高。

 

 

逻辑 standby
逻辑 standby 有三种 工作 模式：
最大保护 (Maximum protection) ：必须确保 redo 写到至少一个 standby 数据库 , 才提交本事务 .
这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其 redo 不仅被写入到本地的 online redo log ，还要同时提交到 standby 数据库的 standby redo log ，并确认 redo 数据至少在一个 standby 数据库可用 ( 如果有多个的话 ) ，然后才会在 primary 数据库上提交。如果出现了什么故障导致 standby 数据库不可用的话， primary 数据库会被 shutdown 。
最高性能 (Maximum performance) ：
这种模式提供在不影响 primary 数据库性能前提下最高级别的数据保护策略。事务可以随时提交，当前 primary 数据库的 redo 数据也需要至少写入一个 standby 数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护而仅对 primary 数据库有轻微的性能影响。
最高可用性 (Maximum availability) ：必须确保 redo 写到至少一个 standby 数据库 , 才提交本事务 .
这种模式提供在不影响 primary 数据库可用前提下最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求所有事务在提交前必须保障 redo 数据至少在一个 standby 数据库可用，不过与之不同的是，如果出现故障导入无法同时写入 standby 数据库 redo log ， primary 数据库并不会 shutdown ，而是自动转为最高性能模式，等 standby 数据库恢复正常之后，它又会再自动转换成最高可用性模式。最大保护及最高可用性需要至少一个 standby 数据库 redo 数据被同步写入。三种模式都需要指定 LOG_ARCHIVE_DEST_n 初始化参数

 

 

注：此对比只适用于 ORACLE 9i 或<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /> 10g 版本。
GoldenGate TDM 容灾方案与DataGuard容灾方案的对比

 
GoldenGate TDM
Oracle DataGuard(物理)
Oracle DataGuard(逻辑)
基本原理
抽取在线日志中的数据变化，转换为GGS自定义的数据格式存放在本地队列或远端队列中。
复制归档日志（9i）
复制归档日志或在线日志（10g）
抽取归档日志中数据的变化（9i）
抽取归档日志或在线日志中数据的变化（10g）
系统整体性能
两端数据库是活动的，备份端可以提供实时的数据查询及报表业务等，从而提高系统整体的业务处理能力，充分利用备份端的计算能力，提升系统整体业务处理性能。可以实现两端数据的同时写入。
备份端处于恢复或只读状态，在只读状态下不能同时进行恢复。只读状态只能短时间内存在，对外提供查询也是短时间的。
两端数据库是活动的，备份端可以提供实时的数据查询及报表业务等，但不能两端都有数据写入。

 

接管时间
可实现立即接管
数据库工作在mount状态下,如果要接管业务,数据库要到open状态.接管时间不定。
在最大性能模式下需等待日志应用完毕然后改变数据库模式完成切换，如果是只传输归档日志接管时间更长。
复制方式
GoldenGate可以提供秒一级的大量数据实时捕捉和投递，异步复制方式，无法实现同步复制。
物理standby数据库与主数据库同步是利用oracle的恢复机制实现的，无法实现同步复制。
可以实现日志同步和异步传输，但日志同步复制时主数据库必须等待本事务成功写到standby数据库端才能进行下面的事务，为此主数据库的性能会受到严重影响，很少采用。日志应用9i只能应用归档日志，10g开始可以实现实时应用。
资源占用
GoldenGate TDM对主机资源的占用非常小，根据实际的监控数据，源端CPU占用不超过1%，内存占用不超过2%，对I/O资源占用微乎其微。
复制是靠数据库的LGWR进程或ARCN进程完成的，占用数据库的一部份资源，对数据库有较大的影响，使数据性能下降。
复制是靠数据库的LGWR进程或ARCN进程完成的，占用数据库的一部份资源，对数据库有较大的影响，使数据性能下降。
异构数据库支持
可以在不同类型和版本的数据库之间进行数据复制。如ORACLE，DB2，SYBASE，SQL SERVER，INFORMIX、Teradata等。
适用于不同操作系统如windows、linux、unix、aix等
单一数据库解决方案，仅运行在ORACLE数据库上。
源端和目标端操作系统必须相同，版本号可以不同。
单一数据库解决方案，仅运行在ORACLE数据库上。
源端和目标端操作系统必须相同，版本号可以不同。
带宽占用
利用TCP/IP传输数据变化，集成数据压缩，提供可达到9：1压缩比的数据压缩特性，可以有效的利用网络带宽。
带宽占用低。
使用Oracle Net传输日志，Oracle Net握手协议多，数据冗余大，速度慢且无数据压缩。
带宽占用高。
使用Oracle Net传输日志，Oracle Net握手协议多，数据冗余大，速度慢且无数据压缩。
带宽占用高。
拓扑结构
GoldenGate TDM可以实现一对一、一对多、多对一、双向复制等多种灵活的拓扑结构，它可以实现数据的分发和集中以及对等复制，非常灵活。
只可以实现一对多模式,且standby数据库最多为9个。
只可以实现一对多模式,且standby数据库最多为9个。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

案例：

1、×××海关总署H2000工程远程灾备系统 （×××海关总署）
2、税务系统灾备试点项目 （×××）
3、×××体育×××管理中心销售系统数据整合系统 （×××体育×××管理中心） 
4、国家质量监督检验检疫总局“大通关”远程灾备系统 （国家质量监督检验检疫总局）
5、中国电子口岸同城灾备系统 （中国电子口岸）
6、中国第一重型机器集团公司远程灾备系统 （中国第一重型机器集团公司）
7、海南移动BOSS应急系统 （中国移动通信集团海南有限公司）