基于主备库节点通讯中断的故障场景，Oracle和db2的处理机制各有何差异？

通常这种数据库的主备库的数据复制都是基于数据库日志的复制，日志的复制又是建立在主备节点间的通讯网络之上的，这个网络通讯中断，只是影响了复制而已，对主库没有任何影响，备库的时间戳仍旧停留在中断的时间，但备库依旧可以对外提供查询服务，只不过数据已经跟不上主库了，当通讯恢复后，主库会自动判断主备间的日志时间戳，发现不匹配，立即将主库中大于备库时间戳的所有日志都复制至备库，备库根据这些日志，进行事物的提交，逐渐追上主库的数据，至到主备数据保持一致。
以上是基于DB2 HADR的场景，像ORACLE和MYSQL我估计也差不多，细节希望其他ORACLE和MYSQL的专家能够补充。

对于事务日志的复制技术，根据主库IO周期特点可以分为绝对同步模式、近似同步模式和异步模式三种。

1. 绝对同步模式是指主库的一个完整更新事务的结束既要包括主库的重做日志落盘也要包括备库的重做日志落盘，也就是说备库重做日志落盘之后返回给主库，主库才能执行下一个事务。
2. 近似同步模式是指在传输正常情况下保持与绝对同步模式一样的模式，在网络传输超时的情况下，就会剥离备库重做日志的过程，只要保证主库重做日志落盘就可以了。
3. 异步模式是指主库只保证本地重做日志落盘，并不会等待备库重做日志落盘的返回信号。

在后两种模式下，当主备库传输管理剥离之后，主库会主动通过以下两种方式探测并尝试重新和备库建立联系，第一是归档日志进程会周期性ping备库，成功情况下，它会根据获得的备库控制文件的记录的最后归档点和自己的归档日志决定向备库推送哪些归档日志。第二是日志发送进程会在重做日志准备发生归档的时刻点主动去ping备库日志接受进程并把剩余的重做条目发送给备库接受进程。

体现在具体数据库的配置模式上如下所述：

DB2 HADR:

SYNC：主服务器上的事务只在相关日志写入主服务器和备用服务器上的磁盘后才提交。SYNC 模式提供最好的数据保护。事务提交需要两份磁盘数据副本。这种模式的成本在于将数据写入备用数据库并将 ACK 消息发回主数据库所需的额外时间。日志只有在写入主磁盘后才发送到备用数据库。日志写入和复制事件按顺序进行。

NEARSYNC：主服务器上的事务只在相关日志写入主服务器上的磁盘且被备用服务器上的内存接收后才提交。NEARSYNC 模式几乎与 SYNC 模式一样出色，且其通信开销大量降低。在 NEARSYNC 模式中，发送日志到备用数据库和将日志写入主磁盘同时进行，备用服务器的内存接收到日志后立即发送一条确认（ACK）消息。在高速网络上，日志复制对主日志写入产生的开销很小甚至没有。如果主服务器失败且备用服务器在将接收到的日志写入磁盘之前也失败，则数据将丢失。这是一种非常少见的 “双失败”场景。因此，NEARSYNC 是很多应用程序的首选，因为它以非常低的性能损失提供近乎同步的保护。

ASYNC：主服务器上的事务只在相关日志写入本地磁盘并发送到备用服务器后才提交。发送日志到备用数据库和将日志写入主磁盘同时进行，这与 NEARSYNC 模式完全相同。由于 ASYNC 无需等待来自备用服务器的 ACK 消息，因此主系统流量是日志写入速度和日志发送速度二者之间的最小者。ASYNC 模式非常适用于 WAN 应用程序。网络传输延迟不会影响这种模式的性能，但如果主数据库失败，则正在传输的日志丢失（没有复制到备用数据库）的几率更大。

ORACLE ACTIVE DATAGUARD:

MAXIMUM PROTECTION：这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的OnlineRedologs，还要同时写入到Standby数据库的StandbyRedologs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可用的话（比如网络中断），Primary数据库会被Shutdown，以防止数据丢失。
使用这种方式要求StandbyDatabase必须配置StandbyRedoLog，而PrimaryDatabase必须使用LGWR，SYNC，AFFIRM方式归档到StandbyDatabase。

MAXIMUM AVAILABILITY：这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的StandbyRedologs中，不过与最大保护模式不同的是，如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求StandbyDatabase必须配置StandbyRedoLog，而PrimaryDatabase必须使用LGWR，SYNC，AFFIRM方式归档到StandbyDatabase.

MAXIMUM PERFORMANCE：缺省模式。这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时，系统的默认保护模式。

对于配置高可用灾难恢复HADR特性的DB2数据库，由于主备库网络距离远，为了不影响主库的正常交易。SYNC_MODE一般处于ASYNC或者SUPERASYNC模式，此两种方式primary db不会等待来自standy db的网络应答，所以网络中断或者网络瞬间闪断对于主库是没有影响的。