当前位置：首页 > 数据库 > Oracle教程 > Oracle日志体系和遇到问题后日志排查路径 > 正文

Oracle日志体系和遇到问题后日志排查路径

来源：这里教程网 时间：2026-03-03 22:06:39 作者：

一、Oracle  日志体系概述

Oracle 11g 引入了 Automatic Diagnostic Repository (ADR)，用于统一管理数据库和集群相关的诊断日志和跟踪文件，取代了 10g 及之前版本的分散日志结构（如 bdump、udump 等目录）。日志主要分为以下几类：

  1. Alert 日志：记录数据库或集群的重大事件（如启动、关闭、错误、死锁等）。

  2. Trace 文件：记录详细的诊断信息，通常与特定进程或错误相关。

  3. 监听日志：记录数据库监听器的连接和错误信息。

  4. 集群日志（仅限 RAC 环境）：记录 Grid Infrastructure 的集群活动和错误信息。

日志的存储位置由环境变量（如 $ORACLE_BASE、$ORACLE_HOME）和初始化参数（如 DIAGNOSTIC_DEST）决定。以下分别从 Oracle 用户和 Grid 用户的角度进行分析。

二、Oracle 用户相关的日志（数据库相关）

Oracle 用户主要负责管理数据库实例（RDBMS），其日志主要用于诊断数据库实例的故障。以下是 Oracle 用户需要关注的日志类型、路径及常见报错内容。

1. Alert 日志

  • 作用：记录数据库的重大事件，包括：

  • 数据库启动和关闭

  • 重做日志（Redo Log）切换

  • 数据库结构变更（如表空间创建、删除）

  • 死锁（Deadlock）

  • 内部错误（如 ORA-00600、ORA-07445）

  • 归档日志相关信息

  • 路径：

  • Oracle 11g 中，Alert 日志存储在 ADR 目录下，路径为：

    $ORACLE_BASE/diag/rdbms/<db_name>/<instance_name>/trace/alert_<instance_name>.log

  • 例如，数据库名为 orcl，实例名为 orcl1：（本文居然是以此为例）

    /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/alert_orcl1.log

  • 查询路径的 SQL 命令：

    SQL> show parameter diagnostic_dest;
SQL> select value from v$diag_info where name = 'Diag Trace';

  • 常见报错内容：

  • ORA-00600：内部错误，通常伴随详细的参数信息，需结合 trace 文件进一步分析，可能涉及 Oracle 内部 bug。

  • ORA-01555：快照过旧错误，可能由于回滚段不足或查询时间过长。

  • ORA-00257：归档日志空间不足，需清理归档日志。

  • Deadlock detected：死锁信息，通常会记录导致死锁的事务和 SQL。

  • 排查建议：

  • 定期检查 Alert 日志，关注错误码（如 ORA- 系列错误）。

  • 使用 adrci 工具查看和管理日志：

    bash

    adrci> show alert

  • 若发现 ORA-00600 或 ORA-07445，需结合对应的 trace 文件，联系 Oracle 支持并提供日志。

  • alert log自动检查ora报错脚本 
  • #!/bin/bash#check alert log
    . /home/oracle/.bash_profile 
  ORACLE_SID=orcl2   #设置sid  export ORACLE_SID
  ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1  export ORACLE_HOME
  HOST_NAME=`uname -n`  export HOST_NAME
  JOB_HOME=$HOME/jobs
  export JOB_HOME
  DUMP_DEST=/u01/app/oracle/diag/rdbms/orcl/"$ORACLE_SID"/trace  export DUMP_DEST
  IPADDR=`ifconfig |grep "inet addr"|awk -F: 'NR==1{print substr($2,1,14)}'`  export IPADDR
  LOG_NAME="alert_$ORACLE_SID.log"
  CHECK_LINES=50
  ERR_MSG="ORA-|Failure|alter|unusable|shutdown|startup"
  ERR_EXC="ORA-02068|ORA-03113|ORA-02050|ORA-12012|ORA-06512|ORA-12541|ORA-12005|ORA-03113|ORA-02396|ORA-02063|ORA-01012|ORA-000060|ORA-02054|ORA-12535|ORA-02053|ORA-01013|ORA-3136|ORA-03135"
  OLD_LOG_1=`echo "old_1_$ORACLE_SID.log"`
  OLD_LOG_2=`echo "old_2_$ORACLE_SID.log"`  export LOG_NAME CHECK_LINES ERR_MSG OLD_LOG_1 OLD_LOG_2 ERR_EXC
  tail -$CHECK_LINES $DUMP_DEST/$LOG_NAME|egrep -i $ERR_MSG|egrep -v $ERR_EXC|egrep -v "ALTER DATABASE BACKUP CONTROLFILE"|egrep -v "ALTER SYSTEM ARCHIVE LOG" > /tmp/new.log
  num=`cat /tmp/new.log |wc -l`  if [ $num -gt 0 ]  then
    if [ ! -f /tmp/$OLD_LOG_1 ]    then
      touch /tmp/$OLD_LOG_1
    fi
    if [ ! -f /tmp/$OLD_LOG_2 ]    then
      touch /tmp/$OLD_LOG_2
    fi
    if [ `cat /tmp/$OLD_LOG_2|wc -l` -eq 0 ]    then
      var=$num
    else
      cmp -s /tmp/new.log /tmp/$OLD_LOG_2
      var=$?    fiif [ $var -ge 1 ]    then
      # echo "**********************************************************************"
      # echo "There are alerts"
      tail -$CHECK_LINES $DUMP_DEST/$LOG_NAME|mail -s "$IPADDR csmes_102 Check Alert Log" `cat $JOB_HOME/dba_mail.addr|grep -v \#`   ###dba_mail.addr报错接受报警邮件地址
       echo "**********************************************************************"
      cp /tmp/$OLD_LOG_1 /tmp/$OLD_LOG_2
      cp /tmp/new.log /tmp/$OLD_LOG_1
    fi
  else
    >/tmp/$OLD_LOG_1
    >/tmp/$OLD_LOG_2
  fi
  shift

    2. Trace 文件

  • 作用：记录特定进程或错误的详细诊断信息，例如后台进程（SMON、PMON、DBWR 等）的错误、用户会话问题等。

  • 路径：

  • 与 Alert 日志同目录，存储在：

    $ORACLE_BASE/diag/rdbms/<db_name>/<instance_name>/trace/

  • 文件名通常以进程名或会话 ID 命名，例如 orcl1_smon_12345.trc。

  • 常见报错内容：

  • 与 Alert 日志中的错误关联，例如 ORA-00600 会在 trace 文件中生成详细的调用堆栈。

  • 会话超时、内存分配失败（如 SGA/PGA 不足）。

  • 排查建议：

  • 根据 Alert 日志中提到的 trace 文件名，定位具体文件。

  • 使用 tkprof 工具分析 trace 文件中的性能问题：

    tkprof orcl1_12345.trc output.txt

    3. 监听日志

  • 作用：记录监听器（listener）的连接请求、错误和状态信息。

  • 路径：

  • 监听日志位于：

    $ORACLE_BASE/diag/tnslsnr/<hostname>/listener/trace/listener.log

  • 例如：

    /u01/app/oracle/diag/tnslsnr/rac1/listener/trace/listener.log

  • 警告日志（XML 格式）位于（一般不看XML格式）：

    /u01/app/oracle/diag/tnslsnr/<hostname>/listener/alert/log.xml

  • 常见报错内容：

  • TNS-12541：无监听器，可能是监听器未启动或配置错误。

  • TNS-01153：监听器名称解析失败，可能涉及 listener.ora 配置错误。

  • Log file size exceeded：监听日志文件过大（常见于高并发环境）。

  • 排查建议：

  • 检查监听器状态：

    lsnrctl status

  • 若日志文件过大（如达到 4GB 导致连接失败），可备份后清空：

    cp listener.log listener.log.bak
>listener.log

    三、Grid 用户相关的日志（集群相关）

    Grid 用户负责管理 Grid Infrastructure（GI），包括 Clusterware 和 ASM（Automatic Storage Management），其日志主要用于诊断 RAC 集群故障。以下是 Grid 用户需要关注的日志类型、路径及常见报错内容。

    1. 集群 Alert 日志

  • 作用：记录 Grid Infrastructure 的重大事件，包括：

  • 节点启动和关闭

  • CRS（Cluster Ready Services）组件状态变化

  • 资源（如 ASM、VIP）故障

  • 网络或磁盘心跳问题

  • 路径：

  • 集群 Alert 日志位于：

    $ORACLE_CRS_HOME/log/<hostname>/alert<hostname>.log

  • 例如，有的环境变量中没有设置$ORACLE_CRS_HOME，一般为：/u01/app/11.2.0/grid

    /u01/app/11.2.0/grid/log/rac1/alert_rac1.log

  • 查询 ADR 路径：

    [grid@rac1 ~]$ adrci
adrci> show home
ADR Homes: 
diag/tnslsnr/db2/listener
diag/asm/+asm/+ASM2
adrci> show alert
Choose the alert log from the following homes to view:
1: diag/tnslsnr/db2/listener
2: diag/asm/+asm/+ASM2
Q: to quit
Please select option: 2

  • 常见报错内容：

  • CRS-1006：资源无法启动，可能涉及 VIP 或 ASM 故障。

  • CRS-4639：节点间心跳失败，可能由于网络中断。

  • ORA-15040：ASM 磁盘组挂载失败，可能磁盘不可用。

  • 排查建议：

  • 检查 Alert 日志，关注 CRS 和 OHASD 相关错误。

  • 使用 crsctl 检查集群状态：

    crsctl status resource -t

  • 查看具体节点的诊断日志：

     tail -n 200 /u01/app/11.2.0/grid/log/rac1/alert_rac1.log ##查看最近200行alert日志

    2. 集群CRS日志

    集群日志路径  $ORA_CRS_HOME/log/<hostname>/, 但是有些环境可能没有设置 $ORA_CRS_HOME，一般就是/u01/app/11.2.0/grid

    实例如下：

    以下日志文件在集群故障诊断中尤为重要，建议优先关注：

    2.1 alert<hostname>.log： 集群 Alert 日志，记录所有重大事件，是排查集群问题的入口。 如下是截取一段，集群中节点db2重启后的部分log

    2025-06-07 09:42:07.988: 
[cssd(8783)]CRS-1601:CSSD Reconfiguration complete. Active nodes are db1 db2 .2025-06-07 10:05:03.419: 
[ctssd(19614)]CRS-2407:The new Cluster Time Synchronization Service reference node is host db1.2025-06-07 10:05:03.419: 
[ctssd(19614)]CRS-2401:The Cluster Time Synchronization Service started on host db2.2025-06-07 10:05:05.137: 
[ohasd(7860)]CRS-2767:Resource state recovery not attempted for 'ora.diskmon' as its target state is OFFLINE2025-06-07 10:05:05.137: 
[ohasd(7860)]CRS-2769:Unable to failover resource 'ora.diskmon'.
[client(19780)]CRS-10001:07-Jun-25 10:05 ACFS-9391: Checking for existing ADVM/ACFS installation.
[client(19785)]CRS-10001:07-Jun-25 10:05 ACFS-9392: Validating ADVM/ACFS installation files for operating system.
[client(19787)]CRS-10001:07-Jun-25 10:05 ACFS-9393: Verifying ASM Administrator setup.
[client(19790)]CRS-10001:07-Jun-25 10:05 ACFS-9308: Loading installed ADVM/ACFS drivers.
[client(19793)]CRS-10001:07-Jun-25 10:05 ACFS-9154: Loading 'oracleoks.ko' driver.
[client(19825)]CRS-10001:07-Jun-25 10:05 ACFS-9154: Loading 'oracleadvm.ko' driver.
[client(19876)]CRS-10001:07-Jun-25 10:05 ACFS-9154: Loading 'oracleacfs.ko' driver.
[client(20064)]CRS-10001:07-Jun-25 10:05 ACFS-9327: Verifying ADVM/ACFS devices.
[client(20072)]CRS-10001:07-Jun-25 10:05 ACFS-9156: Detecting control device '/dev/asm/.asm_ctl_spec'.
[client(20076)]CRS-10001:07-Jun-25 10:05 ACFS-9156: Detecting control device '/dev/ofsctl'.
[client(20081)]CRS-10001:07-Jun-25 10:05 ACFS-9322: completed2025-06-07 10:05:17.105: 
[/u01/app/11.2.0/grid/bin/oraagent.bin(8598)]CRS-5011:Check of resource "+ASM" failed: details at "(:CLSN00006:)" in "/u01/app/11.2.0/grid/log/db2/agent/ohasd/oraagent_grid/oraagent_grid.log"2025-06-07 10:05:23.096: 
[/u01/app/11.2.0/grid/bin/oraagent.bin(8598)]CRS-5011:Check of resource "+ASM" failed: details at "(:CLSN00006:)" in "/u01/app/11.2.0/grid/log/db2/agent/ohasd/oraagent_grid/oraagent_grid.log"2025-06-07 10:05:44.763: 
[crsd(20719)]CRS-1012:The OCR service started on node db2.2025-06-07 10:05:44.838: 
[evmd(19642)]CRS-1401:EVMD started on node db2.2025-06-07 10:05:46.145: 
[crsd(20719)]CRS-1201:CRSD started on node db2. ##几个核心组件启动成功

    2.2 crsd.log： 记录资源管理操作，关键用于诊断资源启动/停止问题。

    路径： /u01/app/11.2.0/grid/log/<hostname>/crsd/crsd.log

    和上面的log同一个事件，可以看到相同时段 crsd.log中的 crsdamon starting的信息，如果有组件启动失败等 也可以找到

    2025-06-07 08:53:20.873: [UiServer][3792246528]{2:39394:52865} Done for ctx=0x7fff58012470
2025-06-07 10:05:38.154: [ CRSMAIN][4084950816] First attempt: init CSS context succeeded.
[  clsdmt][4078499584]Listening to (ADDRESS=(PROTOCOL=ipc)(KEY=db2DBG_CRSD))
2025-06-07 10:05:38.158: [  clsdmt][4078499584]PID for the Process [20719], connkey 1 
2025-06-07 10:05:38.158: [  clsdmt][4078499584]Creating PID [20719] file for home /u01/app/11.2.0/grid host db2 bin crs to /u01/app/11.2.0/grid/crs/init/
2025-06-07 10:05:38.158: [  clsdmt][4078499584]Writing PID [20719] to the file [/u01/app/11.2.0/grid/crs/init/db2.pid] 
2025-06-07 10:05:38.789: [ CRSMAIN][4078499584] Policy Engine is not initialized yet!
2025-06-07 10:05:38.789: [ CRSMAIN][4084950816] CRS Daemon Starting
2025-06-07 10:05:38.790: [    CRSD][4084950816] Logging level for Module: allcomp  0

    2.3 ocssd.log： 记录心跳和节点成员状态，关键用于诊断网络故障和节点驱逐。 路径：/u01/app/11.2.0/grid/log/<hostname>/cssd/ocssd.log 如下 ocssd.log会定期备份，比如我要想查6月10日异常 就是ocssd.l01这个日志，以此类推

    -rw------- 1 grid oinstall 77721600 10月  3 2021 core.65816-rw------- 1 grid oinstall 82620416 10月  3 2021 core.7948-rw------- 1 grid oinstall 80908288 5月  31 2022 core.9202-rw-rw-r-- 1 grid oinstall   181225 6月   7 10:04 cssdOUT.log-rw-r--r-- 1 grid oinstall 52567083 6月  10 10:45 ocssd.l01-rw-r--r-- 1 grid oinstall 52832381 6月   3 14:55 ocssd.l02-rw-r--r-- 1 grid oinstall 52836168 5月  29 01:13 ocssd.l03-rw-r--r-- 1 grid oinstall 52834711 5月  23 12:28 ocssd.l04-rw-r--r-- 1 grid oinstall 52831304 5月  17 23:41 ocssd.l05-rw-r--r-- 1 grid oinstall 52830850 5月  12 12:11 ocssd.l06-rw-r--r-- 1 grid oinstall 52849946 5月   6 23:16 ocssd.l07-rw-r--r-- 1 grid oinstall 52840214 5月   1 09:36 ocssd.l08-rw-r--r-- 1 grid oinstall 52829855 4月  25 21:01 ocssd.l09-rw-r--r-- 1 grid oinstall 52834565 4月  20 08:54 ocssd.l10-rw-r--r-- 1 grid oinstall  6552222 6月  11 15:47 ocssd.log

    还可以看cssdOUT.log 这log中保存了所有的cssd启动记录 可以按这个时间点 来追查集群异常

    ----- End of Call Stack Trace -----05/31/22 10:36:35: CSSD handling signal 605/31/22 10:36:38: CSSD starting05/31/22 10:46:44: CSSD starting05/31/22 10:56:50: CSSD starting05/31/22 11:07:01: CSSD starting05/31/22 11:17:12: CSSD starting06/10/22 14:33:33: CSSD starting02/01/24 05:47:24: CSSD starting02/01/24 05:57:31: CSSD starting02/01/24 06:07:43: CSSD starting02/01/24 06:17:54: CSSD starting02/01/24 06:28:06: CSSD starting02/01/24 06:38:18: CSSD starting02/01/24 06:48:30: CSSD starting02/01/24 07:23:43: CSSD starting02/06/24 14:25:51: CSSD starting06/07/25 10:04:43: CSSD starting

     2.4  OHASD 日志

    记录 Oracle High Availability Services Daemon 的运行状态。

    路径： $ORACLE_CRS_HOME/log/<hostname>/ohasd/ohasd.log

    2.5 Diskmon 日志 记录磁盘监控相关信息。

    路径： $ORACLE_CRS_HOME/log/<hostname>/diskmon/diskmon.log 常见报错内容： OHASD: Failed to start resource：资源启动失败，可能配置错误。 Diskmon: I/O error：磁盘 I/O 问题，可能硬件故障。 排查建议： 检查 OHASD 日志，确认是否有资源初始化失败。 使用 srvctl 检查服务状态： srvctl status database -d orcl

    3. ASM 日志

    作用：记录 ASM 实例的运行状态和错误信息。 路径： ASM Alert 日志： $ORACLE_BASE/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log ASM Trace 文件： $ORACLE_BASE/diag/asm/+asm/+ASM1/trace/ 常见报错内容： ORA-15025：无法打开 ASM 磁盘。 ORA-15042：ASM 磁盘组不可用。 排查建议： 检查 ASM 磁盘状态： SQL> select name, state from v$asm_diskgroup;

    确保存储设备正常连接，检查 multipath 配置 ，确保磁盘的权限正常，如果这些都正常但是dg 是dismount的，可以尝试手动mout。

    alter diskgroup ocr mount；

    四、数据库故障和集群故障的日志排查流程

    1. 数据库故障排查

    数据库故障可能包括无法连接、性能缓慢、错误码（如 ORA-00600）等。排查步骤如下：

    1. 检查 Alert 日志：

    2. 定位 $ORACLE_BASE/diag/rdbms/<db_name>/<instance_name>/trace/alert_<instance_name>.log。

    3. 查找 ORA- 错误码，记录相关时间点和 trace 文件名。

    4. 分析 Trace 文件：

    5. 根据 Alert 日志中提到的 trace 文件名，定位具体文件，分析详细错误堆栈。

    6. 检查监听日志：

    7. 若故障涉及连接问题，检查 $ORACLE_BASE/diag/tnslsnr/<hostname>/listener/trace/listener.log。

    8. 关注 TNS- 系列错误。

    9. 检查归档日志：

    10. 若涉及归档空间问题，检查 log_archive_dest_n 目录，清理旧日志。

    11. 使用工具：

    12. 使用 adrci 查看和管理日志：

      adrci> show incident

    13. 若涉及性能问题，可生成 AWR 报告：

      SQL> @?/rdbms/admin/awrrpt.sql

    2. 集群故障排查

    集群故障可能包括节点驱逐、网络中断、ASM 磁盘组不可用等。排查步骤如下：

    1. 检查集群 Alert 日志：

    2. 定位 $ORACLE_CRS_HOME/log/<hostname>/alert<hostname>.log。

    3. 查找 CRS- 或 ORA-150xx 错误，记录时间点。

    4. 检查 CRS 和 CSS 日志：

    5. 查看 $ORACLE_CRS_HOME/log/<hostname>/crsd/crsd.log 和 ocssd.log，关注心跳失败或资源错误。

    6. 检查 ASM 日志：

    7. 若涉及存储问题，检查 $ORACLE_BASE/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log。

    8. 检查集群状态：

    9. 使用 crsctl 检查集群资源状态：

      crsctl check cluster -all

    10. 检查 ASM 磁盘组：

      SQL> select name, state from v$asm_diskgroup;

    11. 网络和存储检查：

    12. 确认节点间私有网络连通性：

      ping <other_node_private_ip>

    13. 检查存储设备状态，确保多路径配置正常。

    五、日志路径查询方法

    以下是常用的日志路径查询命令：

    1. 数据库日志路径：

      SQL> show parameter diagnostic_dest;
SQL> select value from v$diag_info where name = 'Diag Trace';

    2. 归档日志路径：

      SQL> archive log list;

    3. 监听日志路径：

      find $ORACLE_HOME -name listener.log

    4. 集群日志路径：

      [grid@rac1 ~]$ adrci
adrci> show home

    六、总结

  • Oracle 用户日志：

  • 主要关注 Alert 日志、Trace 文件、监听日志和归档日志。

  • 路径：$ORACLE_BASE/diag/rdbms/<db_name>/<instance_name>/trace/。

  • 常见错误：ORA-00600、ORA-01555、TNS-12541 等。

  • Grid 用户日志：

  • 主要关注集群 Alert 日志、CRS/CSS 日志、ASM 日志。

  • 路径：$ORACLE_CRS_HOME/log/<hostname>/ 和 $ORACLE_BASE/diag/asm/。

  • 常见错误：CRS-1006、ORA-15040、CSSD 心跳失败等。

  • 排查工具：

  • 使用 adrci、crsctl、srvctl 和 SQL 命令快速定位日志和问题。

  • 建议：

  • 定期监控日志，设置日志清理策略。

  • 对于复杂错误（如 ORA-00600），结合 Oracle 支持和 MOS（My Oracle Support）文档深入分析。

    • 编辑推荐：

    相关推荐

    最新软件资讯

    Oracle日志体系和遇到问题后日志排查路径
    Oracle日志体系和遇到问题后日志排查路径

    热文推荐

    天极热推