Maximum Protection模式下主库自动shutdown是设计强制兜底：只要无法将事务redo同步写入至少一个备库的standby redo log，即刻中止服务防数据丢失。
主库异常宕机时，data guard 本身不“处理”宕机，它只保障已成功传输并应用的 redo 数据不丢失；能否避免数据丢失，完全取决于你配置的 protection mode 和备库就绪状态。
Maximum Protection 模式下主库自动 shutdown 不是故障，是预期行为
该模式要求每个已提交事务的 redo 必须同步写入至少一个备库的 standby redo log，否则主库立即中止实例（SHUTDOWN ABORT）。这不是配置错误，而是设计强制兜底。
- 常见触发场景：
v$standby_log查询为空（备库未创建 standby redo log）、log_archive_dest_2缺失AFFIRM属性、DB_UNIQUE_NAME配错、网络闪断超 15 秒 - 验证是否生效：查
v$database.protection_mode和v$database.protection_level，二者必须都为MAXIMUM PROTECTION - 切完模式后仍是
MAXIMUM PERFORMANCE？重点检查VALID_FOR值（应为(ONLINE_LOGFILES, PRIMARY_ROLE)）、STATUS和ERROR列（来自v$archive_dest_status）
Maximum Availability 是生产环境更可行的零丢失选择
它允许主库在备库短暂不可用时继续服务，但一旦备库恢复，会立刻补齐落下的 redo；只要备库最终能追平，就仍可保证零数据丢失——比 Maximum Protection 更具容错弹性。
- 前提条件：备库必须启用
standby redo log（组数 ≥ 主库 online redo log 组数 + 1，大小严格一致） - 关键参数不能漏：
LOG_ARCHIVE_DEST_2 = 'SERVICE=stby_db AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stby_db' - 注意
SYSLOG或ALERT日志里是否出现LGWR: Standby redo logfile not allocated，这是 standby redo log 缺失的直接证据
主库宕机后，备库能否接管并保持数据完整？看这三点
切换不是一键操作，数据完整性取决于宕机瞬间的同步进度和备库状态。
- 先确认备库是否处于
MOUNT状态且已接收并应用了最新归档：查v$archive_gap是否为空、APPLIED_SCN与主库CURRENT_SCN差距是否在可接受范围（如 - 如果备库启用了 Active Data Guard（即
ALTER DATABASE OPEN READ ONLY后又RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT），它其实一直在实时应用 redo，切换延迟通常在秒级 - 切之前务必执行
ALTER SYSTEM FLUSH REDO TO stby_db（12cR2+），强制推送内存中未写出的 redo，减少最后窗口的数据丢失风险
真正容易被忽略的是 standby redo log 的维护——它不像 online redo log 那样有自动管理，必须手动创建、定期检查大小和组数匹配性；一次 ALTER DATABASE ADD STANDBY LOGFILE 执行失败，可能让整个 Maximum Protection 形同虚设。
