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

发布于：2025-06-12 ⋅ 阅读:(26) ⋅ 点赞:(0)

一、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 工具查看和管理日志：

      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=$?
    fi
if [ $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 OFFLINE
2025-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: completed
2025-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 6
05/31/22 10:36:38: CSSD starting
05/31/22 10:46:44: CSSD starting
05/31/22 10:56:50: CSSD starting
05/31/22 11:07:01: CSSD starting
05/31/22 11:17:12: CSSD starting
06/10/22 14:33:33: CSSD starting
02/01/24 05:47:24: CSSD starting
02/01/24 05:57:31: CSSD starting
02/01/24 06:07:43: CSSD starting
02/01/24 06:17:54: CSSD starting
02/01/24 06:28:06: CSSD starting
02/01/24 06:38:18: CSSD starting
02/01/24 06:48:30: CSSD starting
02/01/24 07:23:43: CSSD starting
02/06/24 14:25:51: CSSD starting
06/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 日志：

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

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

  2. 分析 Trace 文件：

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

  3. 检查监听日志：

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

    • 关注 TNS- 系列错误。

  4. 检查归档日志：

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

  5. 使用工具：

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

      adrci> show incident

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

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

2. 集群故障排查

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

  1. 检查集群 Alert 日志：

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

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

  2. 检查 CRS 和 CSS 日志：

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

  3. 检查 ASM 日志：

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

  4. 检查集群状态：

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

      crsctl check cluster -all

    • 检查 ASM 磁盘组：

      SQL> select name, state from v$asm_diskgroup;

  5. 网络和存储检查：

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

      ping <other_node_private_ip>

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

五、日志路径查询方法

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

  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）文档深入分析。

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章

最新发布