ORA-30036在DG备库出现的根本原因是主库undo不足，导致MRP进程应用日志时因缺失前镜像而反复重试；需从主库查UNXPSTEALCNT、SSOLDERRCNT、undo_retention及enq: US争用，调高retention、禁用_autotune、清理长事务、确保undo数据文件自动扩展，备库无需调整undo表空间。
ora-30036 在 dg 备库出现，基本不是备库自己在写 undo，而是主库长事务/大事务产生的 undo 量过大，导致备库重做应用（mrp）卡住或变慢——必须从主库查起，不能只盯着备库的 undotbs1。
为什么备库会因主库 undo 不足而同步变慢
备库本身不生成 undo（undo_management=MANUAL 或未启用 AUM），但 MRP 进程在应用主库归档日志时，需构造一致性读视图，依赖主库写入的 undo 记录。若主库 undo 表空间长期高水位、UNXPSTEALCNT > 0 或 SSOLDERRCNT > 0，说明其 undo 被强制覆盖或保留失效，备库在回放含长查询/闪回逻辑的 DML 时就会反复失败、退避、重试，表现为同步延迟上升、V$MANAGED_STANDBY 中 MRP 状态在 APPLYING_LOG 和 WAIT_FOR_GAP 间震荡。
- 主库
undo_retention设置过短（如 ORA-01555，MRP 内部模拟一致性读失败后降级为串行重放，速度骤降 - RAC 主库中某实例存在未提交事务（
v$transaction.status = 'ACTIVE'），该事务生成的 undo 持续占用空间，阻塞其他事务的 undo 回收，连带拖慢所有归档的备库应用节奏 - 主库使用了
RETENTION GUARANTEE且 undo 数据文件不可 autoextend，物理空间耗尽后新事务直接报ORA-30036，归档中断，备库自然停滞
查主库 undo 压力：重点看 AWR 里的三个计数器
别只跑 SELECT SUM(bytes)/1024/1024 FROM dba_undo_extents 看“用了多少 MB”——这毫无意义。打开最近两小时的 AWR 报告，直奔「Undo Segment Stats」小节，盯死以下三列：
-
UNXPSTEALCNT> 0：说明undo_retention形同虚设，旧 undo 被新事务强占，备库重放时大概率看到被覆盖的前镜像 → 同步卡顿 -
OOS（Out of Space）持续增长：确认是物理空间真不够，不是参数问题；立刻检查dba_data_files对应数据文件是否AUTOEXTENSIBLE = 'NO' -
SSOLDERRCNT非零：快照过旧错误已发生，主库上必有长查询或低undo_retention，备库 MRP 正在 silently retry
顺手执行：SELECT event, COUNT(*) FROM dba_hist_active_sess_history WHERE sample_time > SYSDATE-0.5 AND event LIKE 'enq: US%' GROUP BY event —— 若 enq: US - contention 出现频次高，直接锁定主库争用源头。
主库侧快速止血操作（不重启、不切换表空间）
多数场景下，备库同步慢是主库 undo 治理滞后所致。优先执行这些低风险动作：
- 临时调高
undo_retention：执行ALTER SYSTEM SET undo_retention=1800 SCOPE=BOTH（30 分钟），给备库留出足够缓冲窗口，避免刚传过来的日志就被主库覆盖 - 禁用自动调优（Oracle 12c+ 默认开启）：执行
ALTER SYSTEM SET "_undo_autotune"=FALSE SCOPE=SPFILE，否则你设的undo_retention会被后台进程悄悄覆盖 - 清理孤立事务：查
v$transaction中start_time早于 30 分钟的status = 'ACTIVE'记录，联系业务确认能否 kill：ALTER SYSTEM KILL SESSION '&sid,&serial#' - 确认 undo 数据文件可扩展：
ALTER DATABASE DATAFILE '/path/to/undotbs01.dbf' AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED
注意：以上操作均作用于主库，无需碰备库任何参数或表空间。
备库仅需验证和兜底，别乱动 undo 表空间
备库的 UNDOTBS1 是只读的（除非你手动启用了 Active Data Guard 并开了 DML），它不参与事务生成，也不回收 undo。此时对备库做任何 undo 表空间操作都是徒劳甚至危险的：
- 不要执行
ALTER TABLESPACE UNDOTBS1 ADD DATAFILE—— 备库不需要更多 undo 空间，加了也用不上 - 不要尝试
DROP TABLESPACE UNDOTBS1—— 即使你建了新 undo 表空间，MRP 进程仍绑定原名，会直接报ORA-30013 - 唯一要检查的是 FRA（
DB_RECOVERY_FILE_DEST）是否满：查V$RECOVERY_FILE_DEST.SPACE_USED / SPACE_LIMIT，若 > 95%，用RMAN TARGET / DELETE FORCE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-1'清理，否则 MRP 连写 checkpoint 文件都失败
真正影响备库同步速度的，从来不是它自己的 undo 表空间大小，而是主库 undo 的健康度与归档日志的完整性——这点最容易被忽略，却最致命。
