最大保护模式下主库频繁停机是正常设计行为，因备库日志写入失败（如standby redo log未配置、affirm缺失、网络闪断等）触发强制中止；改用最大可用模式可避免停机，但需同步完善备库日志组、归档参数及监控追平状态。
最大保护模式（maximum protection）下主库频繁停机，不是配置没生效，而是它本该如此——只要备库日志写入失败，主库立刻 shutdown abort。 这不是故障，是强制兜底行为。改成最大可用模式（maximum availability）能解决“频繁停机”问题，但必须清楚改了什么、漏了什么、代价是什么。
为什么 MAXIMUM PROTECTION 会“主动关机”
这个模式的设计目标就是零数据丢失，所以它把一致性看得比可用性重得多。一旦主库的 LGWR 进程无法将 redo 同步写入至少一个备库的 standby redo log，实例就立即中止，不给任何缓冲余地。
- 常见触发点：
v$standby_log查询为空（备库根本没建 standby redo log）、LOG_ARCHIVE_DEST_2缺少AFFIRM属性、网络闪断超 15 秒、DB_UNIQUE_NAME配错导致归档目的地不可达 - 验证是否真在该模式：
SELECT protection_mode, protection_level FROM v$database—— 两个字段必须都返回MAXIMUM PROTECTION，否则你只是“以为”在用它 - 日志里搜
LGWR: Standby redo logfile not allocated，这是最直接的证据，说明备库连日志接收能力都没有
改成 MAXIMUM AVAILABILITY 的关键动作
改模式本身只是一条命令，但真正起作用的是背后一整套同步保障机制。光改 PROTECTION MODE 不补全配套，等于换了个名字继续出问题。
- 必须确保备库已启用
standby redo log：组数 ≥ 主库online redo log组数 + 1，大小严格一致；否则即使模式改了，SYSLOG仍会报ORA-16475或同步卡住 -
LOG_ARCHIVE_DEST_2必须含AFFIRM SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=xxx—— 少任何一个参数，v$archive_dest_status.status就可能显示DEFERRED或ERROR - 切换后立刻查
v$archive_gap：如果非空，说明有归档断档，MAXIMUM AVAILABILITY虽不会关机，但数据完整性已受损
最大可用模式的真实代价与边界
MAXIMUM AVAILABILITY 的“弹性”是有前提的：备库必须最终能追平。它不是容忍丢数据，而是容忍短暂不同步。一旦网络恢复、备库重启，它会自动补齐落下的 redo，实现最终零丢失。
- 主库不会因备库宕机而停机，但会降级为异步传输（
ASYNC），此时窗口期的数据存在丢失风险 - 如果备库长期无法恢复（比如磁盘损坏未及时重建），主库持续异步运行，那和
MAXIMUM PERFORMANCE实际上没区别 - 监控重点要从“是否关机”转向“是否追平”：盯紧
v$managed_standby.process = 'MRP0'是否在运行、APPLIED_SCN和主库CURRENT_SCN差距是否稳定在毫秒级
真正容易被忽略的，是 VALID_FOR 参数和 v$archive_dest_status.error 列。很多人改完模式就以为万事大吉，结果发现 LOG_ARCHIVE_DEST_2 其实一直 ERROR 状态，只是主库没关机而已——这等于裸奔。
