| 比较项目 | 最大保护（maximum protection） | 最高可用（maximum availability） | 最高性能（maximum performance） |
| 简介 | 最大保护模式能够确保绝无数据丢失，该模式要求主库所有事务在提交前其REDO不仅写入本地的online redo logs,还要同时写入到备库的standby redo logs,并确认redo数据至少在一个备库中可用（若有多个的话），然后才会在主库上提交。如果出现了导致备库不可用的故障（例如网络中断），那么主库就会被关闭。因此，在该模式的保护下，数据库必须配置SYNC传输模式，且必须和备库联通，否则会导致主库不能启动。 | 最高可用模式在不影响主库可用的前提下，提供最高级别的数据保护。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台备库的standby redo logs中，不过与最大保护模式不同的是，如果出现故障导致备库无法访问，那么主库并不会被关闭，而是自动转为最高性能模式，等到备库恢复正常后，主库又自动转为最高可用模式。最高可用模式适用于想要确保零数据丢失，但不想让生产数据库受网络/备用服务器故障影响的场景下。 | 在最高性能模式下，事务可以随时提交。如果网络条件理想的话，那么这种模式能够提供类似最高可用性的数据保护，而仅对主库的性能有轻微影响。这也是在创建备库时，系统的默认保护模式。最高性能模式区别于最大保护模式的地方是，它并不需要将日志信息实时的传递到备库上，也不需要确保日志在其中的至少一台备库上应用。 |
| 切换命令 | alter database set standby database to MAXIMIZE PROTECTION; | alter database set standby database to MAXIMIZE AVAILABILITY; | alter database set standby database to MAXIMIZE PERFORMANCEN; |
| 数据丢失情况 | 零数据丢失 | 零数据丢失 | 最小数据丢失 |
| 主库事务完成情况 | 主库redo需要同时写入主库、至少一个备库，主库事务才能完成 | 主库redo需要同时写入主库、至少一个备库，主库事务才能完成 | 主库事务可以随时提交 |
| 是否默认的保护模式 | 否 | 否 | 是 |
| 性能影响 | 对数据库性能影响最大 | 介于最大保护和最高性能之间 | 对数据库性能影响最小 |
| 网络传输模式 | 同步（SYNC） | 同步（SYNC） | 使用LGWR归档传递时采用同步（SYNC）或异步（ASYNC），使用ARCH进程传递归档时采用同步（SYNC） |
| 是否需要standby redo logs | YES | YES | 可以没有，但推荐有 |
| redo写进程 | LGWR | LGWR | LGWR或者ARCH |
| 磁盘写操作 | AFFIRM | AFFIRM | AFFIRM或者NOAFFIRM |
| 优点 | 该模式可以保护备库没有数据丢失 | 该模式可以在没有问题出现的情况下，保证备库没有数据丢失，是一种折中的方法 | 避免了备库对主数据库的性能和可用性造成影响 |
| 缺点 | 要求网络高度稳定，如果出现了导致备库不可用的故障（如网络中断），那么主库会被关闭。备库的自动关闭会影响到主库的可用性，同时需要备库恢复后才能提交，对网络等客观条件要求非常高，主库性能会因此受到非常大的冲击。最大保护模式损害了系统的可用性。 | 在正常运行的过程中缺点是主库性能受到诸多因素的影响。要求备库必须配置standby redo logs,而主库必须使用LGWR SYNC AFFIRM方式归档到备库 | 如果与主库提交的事务相关的恢复数据没有发送到备库，那么这些事务数据将被丢失，不能保证数据无损失。如果主库发生灾难性故障，日志全部丢失，那么备库和主库可能会出现一个左右的日志信息差异。当然可以通过设置主库增加归档频率来缩小可能的数据损失。最高性能模式损害了系统的数据安全性。 |