ADG不能防勒索病毒或逻辑损坏，因其物理备库会忠实地重放主库所有操作（含DROP、TRUNCATE等），仅提供物理块级实时复制；防护依赖人工干预窗口与架构设计，如只读隔离、延迟应用（DELAY=3600）、空临时表空间及Broker固化策略。
ADG 本身不防勒索病毒，也不能自动修复逻辑损坏；它只保证物理块级的实时复制。真正起防护作用的是你如何用好它的“时间差”和“角色隔离”能力。
为什么ADG不能直接防勒索或误删
Oracle 19c ADG 的物理备用库（Physical Standby）会忠实地重放主库的所有重做记录——包括 DROP TABLE、UPDATE ... SET salary = 0、甚至被恶意脚本触发的全库 TRUNCATE。只要这些操作在主库提交了，备库几秒内就会同步执行。所谓“防”，其实是靠人工干预窗口和架构设计抢出时间，不是靠自动拦截。
常见误解：以为开了 ADG 就等于有了“后悔键”。实际不是。备库不是快照，也不是闪回数据库（Flashback Database），它只是另一个正在运行的、同步的实例。
利用 ADG 的只读特性隔离高危操作
把 ADG 备库设为只读（ALTER DATABASE OPEN READ ONLY），并严格限制访问路径，是防范逻辑损坏的第一道防线：
- 所有报表、ETL 查询、BI 工具连接串必须指向备库 TNS 别名（如
ORCL_STBY），严禁直连主库做分析类查询 - 禁用备库上的
SQL*Plus、sqlcl等交互式客户端的远程登录（通过sqlnet.ora中tcp.validnode_checking = yes+tcp.invited_nodes白名单控制） - 不给应用账号
CREATE SESSION以外的权限；特别要 revokeSELECT ANY DICTIONARY和EXECUTE ANY PROCEDURE - 主库上启用统一审计（
AUDIT POLICY ORA_SECURECONFIG），重点捕获DROP、TRUNCATE、ALTER SYSTEM类语句，日志发往独立服务器存储
用延迟应用（DELAY）争取黄金恢复时间
在 LOG_ARCHIVE_DEST_n 中显式配置 DELAY=3600（单位秒），让备库的日志应用滞后主库 1 小时。这不是默认行为，必须手动加：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=ORCL_STBY LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCL_STBY DELAY=3600';
这样做的效果是：
- 勒索程序加密完主库数据后，至少 1 小时内备库仍保留干净状态
- DBA 可在发现异常后，立刻在备库执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;停止应用，再用FLASHBACK DATABASE TO SCN xxx或切换到更早的归档点完成回退 - 注意：延迟模式下，
SWITCHOVER不可用；故障切换（FAILOVER）前必须先取消延迟（DELAY=0），否则会报ORA-16826
备库临时表空间陷阱反而成了安全缓冲区
ADG 备库默认没有临时文件（ORA-25153: Temporary Tablespace is Empty），这看似是缺陷，实则是天然保护层：
当攻击者试图在备库执行大排序、哈希连接或物化视图刷新时，会直接报错退出，无法消耗资源或写入临时段——而这些操作恰恰是勒索脚本常用来“撑爆磁盘”或“拖慢主库”的手段。
但别指望它永远帮你挡着：一旦你手动执行 ALTER TABLESPACE temp ADD TEMPFILE ...，这个缓冲就消失了。所以除非业务真需要备库跑大型报表，否则保持空临时表空间是更稳妥的选择。
最关键的一点：延迟配置、只读策略、临时表空间空置，这三者必须在 DG Broker 配置里固化（EDIT DATABASE ... SET PROPERTY），不能只靠手工命令临时生效。Broker 重启或 switchover 后，未持久化的设置会丢失，防护就断了。
