来源：http://blog.csdn.net/sopost/article/details/5860241
一 、双机热备
从广义上讲，双机热备（双机容错）就是对于重要的服务，使用两台服务器，互相备份，共同执行同一服务。当一台服务器出现故障时，可以由另一台服务器承担服务任务，从而在不需要人工干预的情况下，自动保证系统能持续提供服务 双机热备由备用的服务器解决了在主服务器故障时服务不中断的问题。但在实际应用中，可能会出现多台服务器的情况，即服务器集群 双机热备一般情况下需要有共享的存储设备。但某些情况下也可以使用两台独立的服务器 实现双机热备，需要通过专业的集群软件或双机软件。
从狭义上讲，双机热备特指基于active/standby方式的服务器热备。服务器数据包括数据库数据同时往两台或多台服务器写，或者使用一个共享的存储设备。在同一时间内只有一台服务器运行。当其中运行着的一台服务器出现故障无法启动时，另一台备份服务器会通过双机软件的诊测（一般是通过心跳诊断）将standby机器激活，保证应用在短时间内完全恢复正常使用.
所以，像VCS (VERITAS Cluster Manager)等软件实现的Oracle Cluster Server以及Oracle Standby ,Oracle RAC(Real Application Cluster),高级复制(Advanced Replication), Streams等技术都能认为是双机热备。
二．Physical Standby，Logical Standby (物理Standby及逻辑Standby)
Physical standby直接从主库接受archived log，然后直接做基于block的物理恢复（更新或调整变化的block），所以physical standby在物理文件一级完全都等同于主库。physical standby恢复只是底层的block apply, OS层面的工作,数据库SCHEMA，包括索引都是一样的。它是直接应用REDO或归档实现同步的 。不会涉及temp ,undo等。物理STANDBY可能的模式：只读模式（OPEN READONLY）和恢复模式（MANANGED RECOVERY）。
在逻辑STANDBY中，逻辑信息是相同的，但物理组织和数据结构可以不同，它和主库保持同步的方法是将接收的REDO转换成SQL语句，然后在STANDBY上执行SQL语句（SQL Apply）。逻辑STANDBY除灾难恢复外还有其它用途，比如用于用户进行查询和报表。
在9i R2之前，data guard的服务器只能运行在read only或者recover模式， 一个physical standby database在物理上完全等同主库，当physical standby database正在做恢复的时候，不能打开用作其他用途。 而logical standby database只是在logical上等同需要恢复的schema， 所以在恢复的时候，可以同时打开做report(做查询动作)，也可以用户和主库不一样的 数据对象等等，极大了提高了备用库的利用率。
三．Dataguard
都是Standby。在Oracle 9i之前称为Standby，9i或之后的Standby被改名为Data guard。不过功能上也有了很多的改进和区别 。
四．Standby下LGWR / ARCH传输
查看数据库保护模式：
SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
1.最大性能(maximize performance):
这是data guard默认的保护模式。primay上的事务commit前不需要从standby上收到反馈信息（主数据库的提交操作不等待STANDBY），该模式在primary故障时可能丢失数据，但standby对primary的性能影响最小。 可以使用LGWR ASYNC或者ARCH两种传输模式。
ARCH传输模式：Primary DB上的online redo log写满或其他条件引起redo log写归档的时候，redo log生成的archived log file写到本地归档目录的同时，写入了Standby归档目录。只是Primary db上的online redo log切换不必等Standby上的写归档动作结束。
2.最大可用(maximize availability):
在正常情况下，最大可用模式和最大保护模式一样；在standby不可用时，最大可用模式会自动降低成最大性能模式，所以standby故障不会导致primay不可用。在问题纠正之后，Standby和主数据库进行再同步，至少有一个standby可用的情况下，即使primary down机，也能保证不丢失数据。(不过当问题修复，再同步之前有必要FAILOVER,那么有些数据可能会丢失)。最大可用性模式Standby必须配置Standby Redo log，Oracle推荐最大可用模式使用LGWR ASYNC（异步）模式传输。
采用最大可用的data guard模式，主库往备库传递在线日志(online redo log)信息，在线日志信息写入备用库的standby redo log,这些standby redo log归档后，备用库应用归档日志。
LGWR还分为LGWR ASYNC(异步)和LGWR SYNC(同步)两种。
|
|
最大保护 |
最大可用 |
最大性能 |
|
进程 |
LGWR |
LGWR |
LGWR或ARCH |
|
网络传输模式 |
SYNC |
SYNC |
LGWR时设置ASYNC |
|
磁盘写操作 |
AFFIRM |
AFFIRM |
NOAFFIRM |
|
备用日志 |
YES |
物理备用需要 |
LGWR和物理备用时需要 |
|
备用库类型 |
物理Standby |
物理或逻辑 |
物理或逻辑 |
最大保护(maximize protection):
最高级别的保护模式。primay上的事务在commit前必须确认redo已经传递到至少一个standby上，如果所有standby不可用，则primary会挂起。该模式能保证零数据丢失。对于最大保护和最高可用性模式，Standby数据库必须配置standby redo log，并且oracle推荐所有数据库都使用LGWR SYNC模式传输。
====================================
前几天，一客户的2个oracle双机热备瘫了，经我查明原因是这两套DG主机和备机服务器盘符不一致导致数据文件同步失败，比如主机有C，D,E三个磁盘分区，而备机只有一个磁盘分区为D盘。当主机数据库在非D盘的路径下写入数据的时候，这个所谓的双机热备就不同步了。显而易见的事。磁盘都不一致，后面写入的数据怎么可能同步。首先申明这两套DG是客户请第三方公司弄得。踩了一个大坑。这种数据服务器热备架构明显不合理。并没有达到分摊IO负载的效果。而且还不能往主机其他盘符写数据，否则就无法同步。鉴于是公司的一个客户，我接了这个坑。把DG重新搭建了，方法是备机服务器磁盘分区保持和主机磁盘分区盘符一致即可。说明本来也不在我的服务范围之内，出于人道主义救援。
————————————————
版权声明：本文为CSDN博主「DBA_fashion」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/p6620582/article/details/85048338
====================================
