物理备库是块级镜像，逻辑备库是行级重演：前者通过REDO APPLY保持物理一致、只读/挂载，后者通过SQL APPLY实现逻辑一致、可读写定制；选错类型将导致同步中断、切换失败或无法读写分离。
物理备库是块级镜像，逻辑备库是行级重演——选错类型会导致同步中断、角色切换失败或无法满足读写分离需求。
物理备库：块级复制，只读或挂载状态
物理备库通过 REDO APPLY 将主库传输来的 redo 日志直接应用到本地数据文件，保持与主库完全一致的物理结构（包括块地址、文件布局、字节序）。它只能以 MOUNT 或 READ ONLY 模式打开，不能写入任何用户数据。
- 同步机制依赖底层存储一致性，不解析 SQL，所以速度极快，延迟通常在秒级
- 不能在备库上创建额外索引、触发器或物化视图；一旦手动修改数据文件（如用
dd写入），REDO APPLY会报错中断 - 启用 Data Guard Broker 后，
switchover是原子操作，但failover后原主库需重建，不可逆 - 使用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE控制应用进程，日志传输必须配置STANDBY REDO LOG
逻辑备库：SQL重放，支持读写与定制化
逻辑备库通过 SQL APPLY 将接收到的 redo 解析为 DML/DDL 语句，在本地数据库中重新执行。这意味着它不要求物理结构一致——表空间名、数据文件路径、甚至字符集都可以不同。
- 可以以
READ WRITE模式打开，允许创建本地索引、物化视图、审计表等辅助对象 - 不支持所有 DDL（比如
ALTER DATABASE、TRUNCATE部分版本）、也不支持某些数据类型（如ANYDATA、XMLType存储在对象表中时） - 开启
LOGICAL STANDBY前必须运行DBMS_LOGSTDBY.BUILD，否则SQL APPLY启动即报ORA-16115 - 性能瓶颈明显：高并发 DML 下容易积压
logminer分析队列，V$LOGSTDBY_PROGRESS中的APPLIED_SCN和RECEIVED_SCN差值持续增大就是信号
保护模式与故障场景响应差异
物理备库可参与 MAXIMUM PROTECTION 和 MAXIMUM AVAILABILITY 模式，主库事务提交必须等待备库写入 standby redo log 才返回成功；逻辑备库仅支持 MAXIMUM PERFORMANCE，主库完全异步发送 redo，丢失风险更高。
- 主库误删表？物理备库只能 failover 后从备份恢复该表；逻辑备库可停掉
SQL APPLY，手工DROP对应表再重启，避免全库回退 - 备库磁盘满导致归档堆积？物理备库会卡在
ARCHIVE LOG CURRENT，主库可能 hang 住；逻辑备库只影响LOGMINER分析，主库不受限 - 升级主库前，必须先升级逻辑备库（且需检查
DBA_LOGSTDBY_UNSUPPORTED视图），物理备库只要 Oracle 版本兼容即可
真正容易被忽略的是：逻辑备库的 SQL APPLY 进程不是“执行 SQL”，而是按事务顺序重放，一旦遇到不支持的操作（比如含 SYSDATE 的插入），会跳过整条事务并记录到 DBA_LOGSTDBY_EVENTS——这不会报错中断，但数据已悄然不一致。
