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 小时。