oracle应用升级时的安全策略

mahan

在进行核心业务系统的应用服务器升级时，暂时关闭备库的日志应用（MRP 进程），可以确保备库的数据完全停留在升级前的安全状态。

这种操作逻辑清晰，但在 ORACLE RAC + ADG 环境中，有几种不同的实现方式和更优的替代方案。以下是具体的操作指南和建议：

方案一：手动停止备库同步
你可以仅停止备库的日志应用 (Redo Apply)，但保持日志传输 (Redo Transport) 正常。这样主库的归档日志依然会传到备库服务器上，只是不立刻写入数据文件，既起到了保护作用，又避免了主库归档积压的风险。

1. 升级前（关闭同步）：
在备库（任意一个节点即可）执行以下命令，取消持续恢复进程：

SQL
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
此时备库依然可以以 READ ONLY 模式对外提供查询服务，但数据不再推进。

2. 升级结果处理：

如果升级成功： 直接重新开启实时应用即可，ADG 会自动应用累积的归档日志，追平主库。

SQL
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
如果升级失败（数据被污染）： 如果决定放弃主库，你可以将这个备库激活（Activate）为新的主库来临时接管业务。

缺点： 一旦将备库激活（Failover），原有的 Data Guard 主备关系就会破裂。后续你需要花费大量时间重新搭建备库（或者通过 Flashback 恢复原主库），这期间数据库处于单点运行，存在风险。

方案二：主库创建保证还原点
在 Oracle 19c 环境下，为了应对应用升级失败导致的数据错误，最佳实践其实不是停备库，而是在主库使用保证还原点（Guaranteed Restore Point, GRP）。

19c 的 Data Guard 有一个非常强大的特性：如果主库执行了闪回（Flashback），备库会自动跟着闪回并同步新的数据分支（Incarnation），完全不需要重新搭建备库。

操作步骤：

确认开启闪回： 确保主库开启了 FLASHBACK ON 且有足够的闪回恢复区空间。

升级前（创建还原点）：

SQL
CREATE RESTORE POINT before_app_upgrade GUARANTEE FLASHBACK DATABASE;

升级结果处理：
如果升级失败：关闭应用，直接在主库闪回到该节点。

SQL
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
FLASHBACK DATABASE TO RESTORE POINT before_app_upgrade;
ALTER DATABASE OPEN RESETLOGS;
此时，ADG 备库会自动识别到主库的 RESETLOGS，并自动进行回退和重新同步，省去了重建 DG 的巨大工作量。*

如果升级成功：务必记得删除还原点，否则 FRA 空间会被撑爆。

SQL
DROP RESTORE POINT before_app_upgrade;


方案三：设置备库延迟应用 (Delay Apply)

如果你不想手动启停备库同步，也可以通过设置延迟时间来获得一个“缓冲窗口”。

操作步骤：
在主库修改日志归档目的地参数，增加 `DELAY` 属性（例如延迟 120 分钟应用）：
SQL
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_tns ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db DELAY=120' SCOPE=BOTH;
这样备库会自动滞后主库 2 小时。

如果升级在 2 小时内失败，你可以立即停止备库应用，此时备库数据还是干净的。

升级确认成功后，将 DELAY 改回 0 即可恢复实时同步。

总结建议
如果你只是想简单、快速地锁定备库状态，方案一（停止 MRP 进程）最直接。但考虑到灾备体系的完整性和恢复成本，方案二（主库 GRP 结合 19c 的备库自动跟随闪回特性）是更符合现代 Oracle 运维标准的做法，它能在保障数据安全的同时，避免破坏 Data Guard 拓扑图。