比较项目 | 最大保护(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方式归档到备库 | 如果与主库提交的事务相关的恢复数据没有发送到备库,那么这些事务数据将被丢失,不能保证数据无损失。如果主库发生灾难性故障,日志全部丢失,那么备库和主库可能会出现一个左右的日志信息差异。当然可以通过设置主库增加归档频率来缩小可能的数据损失。最高性能模式损害了系统的数据安全性。 |