如何管理Data Guard Broker日志文件_drc[SID].log文件分析与Broker进程诊断-Oracle-PHP中文网

broker日志\_drc[sid].log位于$oracle_base/diag/rdbms/[db_unique_name]/[instance_name]/trace/下，非adrci管理、不轮转，超200mb需干预，超1gb表明存在持续异常；正确清理方式为cat /dev/null > \_drc[sid].log。

broker日志文件 `_drc[sid].log` 存在哪、多大才该管

oracle data guard broker 的诊断日志默认写在 $oracle_base/diag/rdbms/[db_unique_name]/[instance_name]/trace/ 下，文件名是 _drc[sid].log（比如 _drccdb1.log）。它不是归档日志，也不走 adrci 管理，而是 broker 进程（d000 或 dmon）自己写的纯文本日志。

这个文件会持续追加，不自动轮转。一旦 Broker 配置频繁变更、主备切换反复失败或网络抖动，日志可能几小时内暴涨到数 GB —— 此时 tail -f 会卡，vi 打不开，甚至影响 DMON 进程写入性能。

检查大小：ls -lh $ORACLE_BASE/diag/rdbms/*/trace/_drc*.log
超过 200MB 就该干预；超过 1GB 说明有持续异常，别只清日志
不能直接 rm _drc*.log：Broker 进程仍持有文件句柄，磁盘空间不会释放，且重启 DMON 前新日志还会往旧 inode 写
正确清理方式：cat /dev/null > _drc[SID].log（清空内容但保留文件和句柄）

从 `_drc[SID].log` 里快速定位 Broker 卡住或命令超时的原因

Broker 命令 hang 住（比如 EDIT DATABASE ... SET STATE='APPLY-ON' 卡住不动），90% 是因为底层 SQL 执行失败或等待超时，而这些细节只记在 _drc[SID].log 里，DGMGRL 输出只显示 “Command not complete”。

关键线索藏在时间戳 + ERROR + ORA- 开头的行里，但要注意：Broker 日志里的 ORA 错误往往是下游操作引发的（比如备库没开 REDO APPLY，主库发过来的 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 就会报 ORA-16766），不是 Broker 自身 bug。

搜最近 10 分钟的错误：grep -A 2 -B 2 "ERROR\|ORA-" _drc[SID].log | grep "$(date -d '10 minutes ago' '+%b %d %H:%M')"
重点看 ERROR 行之后紧跟着的 SQL 语句，尤其是含 ALTER DATABASE、START APPLY、SWITCHOVER 的那条
常见干扰项：日志里大量重复的 Waiting for message from database，说明 Broker 进程在等备库响应，此时要立刻查备库的 MRP0 进程状态和 alert.log

`DMON` 进程异常退出后，`_drc[SID].log` 不再更新怎么办

DMON 是 Broker 的守护进程，如果它意外终止（比如被 kill、内存溢出、或 Oracle Bug 导致 core dump），_drc[SID].log 就彻底停更 —— 你改任何配置、执行任何 DGMGRL 命令，日志都不会多一行。这时候光看日志是死路一条。

必须先确认 DMON 是否活着：ps -ef | grep [D]MON（注意中括号防匹配 grep 自身）。如果没进程，Broker 功能已瘫痪，所有 DGMGRL 命令都会返回 ORA-16500: Data Guard broker error。

不要盲目重启实例：Broker 配置元数据存在控制文件里，重启 DB 不会自动拉起 DMON
手动启动 DMON：srvctl start mgmt db -db <code>db_unique_name（RAC）或 sqlplus / as sysdba 中执行 ALTER SYSTEM SET dg_broker_start=TRUE;
启动后检查日志是否恢复写入：tail -f _drc[SID].log 看有没有新时间戳行出现
如果启动失败，看 alert_[SID].log 里是否有 DMON failed to start 或 ORA-16532（Broker 已禁用）

Broker 配置变更后日志暴增，但 `DGMGRL SHOW CONFIGURATION` 显示正常

有时候改了个很简单的东西，比如 EDIT DATABASE 'STBY' SET PROPERTY 'LogXptMode'='SYNC';，_drc[SID].log 却开始每秒刷几十行 “Updating property …”，持续数小时。这通常不是配置问题，而是 Broker 在后台反复尝试同步状态，却始终收不到备库确认。

根本原因在于 Broker 的“状态收敛机制”：它会周期性向每个数据库发心跳 SQL（如 SELECT DB_UNIQUE_NAME FROM V$DATABASE），并比对返回值与本地缓存。只要某一个库响应慢、SQL 超时、或返回结果不一致（比如备库 DB_UNIQUE_NAME 实际是小写，Broker 元数据存的是大写），它就判定“未收敛”，继续重试。

查当前收敛状态：DGMGRL> SHOW DATABASE VERBOSITY 'STBY'，关注 State 和 Transport Lag 字段是否稳定
临时降低日志量：在 init.ora 或 SPFILE 中设置 _dg_broker_debug_level=0（默认是 16），重启 DMON 生效
真正治本：确认所有数据库的 DB_UNIQUE_NAME 大小写与 Broker 配置完全一致；检查主备间 tnsnames.ora 是否能低延迟解析、连接

Broker 日志本身不记录 SQL 执行耗时，只记成功或失败。想定位哪一步慢，得配合备库的 MRP0 trace 文件和主库的 LGWR trace 看网络往返和重做传输延迟。