11g新特性:A useful View V$DIAG_INFO

在11g中引入了自动诊断资料档案库(AutomaticDiagnostic Repository--ADR)特性,默认情况下各种trace,dump存放的目录位置区别于9i/10g显得更加难以查找了。

ADR 基目录中可以包含多个 ADR 主目录,其中每个 ADR 主目录都是一个根目录,用于存放特定 Oracle 产品或组件的特定实例的全部诊断数据。前一张幻灯片的图形中显示了数据库的 ADR 主目录位置。

另外,还生成了两个预警文件。一个是文本形式的预警文件(与早期版本 Oracle DB 使用的预警文件非常相似),位于各个 ADR 主目录的 TRACE 目录下。还有一个符合 XML 标准的预警消息文件,存储在 ADR 主目录内的 ALERT 子目录下。可使用 Enterprise Manager 和 ADRCI 实用程序查看文本格式的预警日志(已删除了 XML 标记)。

此幻灯片中的图形显示了 ADR 主目录的目录结构。INCIDENT 目录包含多个子目录, 每个子目录均以特定意外事件命名,并且仅包含与该意外事件相关的转储。

HM 目录包含由健康状况监视器生成的检查器运行报告。

还有一个 METADATA 目录,其中包含资料档案库自身的重要文件。可以将此目录比作数据库字典。可使用 ADRCI 查询此字典。

ADR 命令解释器 (ADRCI) 是一个实用程序,可用于执行支持工作台允许的所有任务(但是仅限于在命令行环境中)。使用 ADRCI 实用程序,您还可以查看 ADR 中跟踪文件的名称以及删除了 XML 标记、具有和不具有内容筛选功能的预警日志。

此外,还可以使用 V$DIAG_INFO 列出一些重要的 ADR 位置。

一个需要注意的细节是启用了ADR自动诊断资料档案库后,LISTENER监听器日志的默认位置也被移动到diagnostic_dest下了,而不在如9i/10g那样存放在$ORACLE_HOME/network/log目录下,有不少人因为忘记了这个细节而花费了大量时间去寻找listener.log,这个人也包括我。实际上我们还是可以将listener.log日志的位置还原回10g的形式,这一点可以通过修改$ORACLE_HOME/network/admin/listener.ora来达成:

[oracle@ora11 admin]$ cat listener.ora 

# listener.ora Network Configuration File: /u01/app/oracle/11.2/network/admin/listener.ora
# Generated by Oracle configuration tools.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ora11)(PORT = 1521))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
    )
  )

ADR_BASE_LISTENER = /u01/app/oracle


将以上listener.ora文件的ADR_BASE_LISTENER条目删除,并加上

DIAG_ADR_ENABLED_LISTENER = OFF

重启监听服务
[oracle@ora11 admin]$ lsnrctl reload

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 06-MAY-2015 12:30:37

Copyright (c) 1991, 2013, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ora11)(PORT=1521)))
The command completed successfully

所幸的是在11g中提供了比传统的gettrcname.sql脚本更为给力的诊断文件位置信息汇总的视图V$DIAG_INFO:

V$DIAG_INFO    视图列出了所有重要的 ADR 位置:
ADR Base:       ADR 基目录的路径
ADR Home:      当前数据库实例的 ADR 主目录的路径
Diag Trace:      文本预警日志和后台/前台进程跟踪文件的位置
Diag Alert:        XML  版本的预警日志的位置
Default Trace File:会话的跟踪文件的路径。SQL 跟踪文件将写入到这里。
Health Monitor:   健康检查报告所在目录
Active Problem Count:当前激活的问题总数
Active Incident Count  当前激活的事故总数

SQL>  select name,value from v$diag_info;

NAME                                    VALUE
--------------------------------------- ------------------------------------------------------------

Diag Enabled                                       TRUE
ADR Base                                           /u01/app/oracle
ADR Home                                           /u01/app/oracle/diag/rdbms/xulq/xulq
Diag Trace                                         /u01/app/oracle/diag/rdbms/xulq/xulq/trace
Diag Alert                                         /u01/app/oracle/diag/rdbms/xulq/xulq/alert
Diag Incident                                      /u01/app/oracle/diag/rdbms/xulq/xulq/incident
Diag Cdump                                         /u01/app/oracle/diag/rdbms/xulq/xulq/cdump
Health Monitor                                     /u01/app/oracle/diag/rdbms/xulq/xulq/hm
Default Trace File                                 /u01/app/oracle/diag/rdbms/xulq/xulq/trace/xulq_ora_5099.trc
Active Problem Count                               0
Active Incident Count                              0

11 rows selected.

adrci> show hm_run
**********************************************************
HM RUN RECORD 119
**********************************************************
   RUN_ID                        2481
   RUN_NAME                      HM_RUN_2481
   CHECK_NAME                    DB Structure Integrity Check
   NAME_ID                       2
   MODE                          2
   START_TIME                    2011-05-21 20:11:38.612669 +08:00
   RESUME_TIME
   END_TIME                      2011-05-21 20:11:38.619530 +08:00
   MODIFIED_TIME                 2011-05-21 20:11:38.619530 +08:00
   TIMEOUT                       0
   FLAGS                         0
   STATUS                        5
   SRC_INCIDENT_ID               0
   NUM_INCIDENTS                 0
   ERR_NUMBER                    0
   REPORT_FILE                   

adrci> create report hm_run HM_RUN_2481
adrci> show hm_run  -p "RUN_ID=2481"
ADR Home = /s01/orabase/diag/rdbms/prod/PROD1:
*************************************************************************
**********************************************************
HM RUN RECORD 1
**********************************************************
   RUN_ID                        2481
   RUN_NAME                      HM_RUN_2481
   CHECK_NAME                    DB Structure Integrity Check
   NAME_ID                       2
   MODE                          2
   START_TIME                    2011-05-21 20:11:38.612669 +08:00
   RESUME_TIME
   END_TIME                      2011-05-21 20:11:38.619530 +08:00
   MODIFIED_TIME                 2011-05-30 21:09:43.071150 +08:00
   TIMEOUT                       0
   FLAGS                         0
   STATUS                        5
   SRC_INCIDENT_ID               0
   NUM_INCIDENTS                 0
   ERR_NUMBER                    0
   REPORT_FILE                   /s01/orabase/diag/rdbms/prod/PROD1/hm/HMREPORT_HM_RUN_2481.hm

[oracle@rh2 ~]$ cd /s01/orabase/diag/rdbms/prod/PROD1/hm

[oracle@rh2 hm]$ cat HMREPORT_HM_RUN_2481.hm

<?xml version="1.0" encoding="US-ASCII"?>
<HM-REPORT REPORT_ID="HM_RUN_2481">
 <TITLE>HM Report: HM_RUN_2481</TITLE>
 <RUN_INFO>
 <CHECK_NAME>DB Structure Integrity Check</CHECK_NAME>
 <RUN_ID>2481</RUN_ID>
 <RUN_NAME>HM_RUN_2481</RUN_NAME>
 <RUN_MODE>REACTIVE</RUN_MODE>
 <RUN_STATUS>COMPLETED</RUN_STATUS>
 <RUN_ERROR_NUM>0</RUN_ERROR_NUM>
 <SOURCE_INCIDENT_ID>0</SOURCE_INCIDENT_ID>
 <NUM_INCIDENTS_CREATED>0</NUM_INCIDENTS_CREATED>
 <RUN_START_TIME>2011-05-21 20:11:38.612669 +08:00</RUN_START_TIME>
 <RUN_END_TIME>2011-05-21 20:11:38.619530 +08:00</RUN_END_TIME>
 </RUN_INFO>
 <RUN_PARAMETERS/>
 <RUN-FINDINGS/>
</HM-REPORT>
通过查询V$diag_info可以很容易找到自身服务进程的trace文件位置,对于其他进程的trace文件则可以查询v$process新加入的tracefile列:
SQL> select spid,tracefile from v$process;

SPID                     TRACEFILE
------------------------ --------------------------------------------------------------------------------
                         /s01/orabase/diag/rdbms/prod/PROD1/trace/PROD1_ora_0.trc
22789                    /s01/orabase/diag/rdbms/prod/PROD1/trace/PROD1_pmon_22789.trc
22791                    /s01/orabase/diag/rdbms/prod/PROD1/trace/PROD1_psp0_22791.trc

<think>好的,我现在需要分析用户提供的日志,找出`diag_mdlog`命令执行失败的原因。首先,用户之前询问过这个命令的作用,现在遇到了问题,需要帮助解决。 首先,用户给出的日志中有几个关键错误信息。我需要逐一分析这些错误,看看它们之间的关系以及可能导致失败的原因。让我先看看日志中的每一行都说了什么。 第一部分的日志是命令参数的解析,比如`command = q`、`command = u`等,这可能是工具在解析用户输入的参数(-q、-u、-f、-o、-s)。接下来,系统显示内核支持的外设数量和连接情况,然后提示没有活动的会话(No Session is active for the given mask)。这可能意味着指定的队列或掩码没有激活的日志会话。 然后,工具尝试关闭临时文件描述符,并警告输出目录已经存在,但继续执行。接着显示Diag_LSM_Init初始化成功,但随后出现了关于远程处理器掩码的设置。之后的关键错误是`byte_cntr - block_size open fail`,无法找到`/sys/bus/coresight/devices/coresight-tmc-etr/block_size`这个路径,导致`diag_qdss_init`失败,掩码为2,最后进行了一些清理操作,线程退出。 可能的原因有几个方面: 1. **权限问题**:访问`/sys/`下的文件通常需要root权限,特别是像coresight这样的调试接口。如果设备没有root,或者selinux限制了访问,就会导致失败。 2. **内核配置或驱动缺失**:`coresight-tmc-etr`是内核中的调试组件,可能设备的内核没有启用相关配置,或者驱动未正确加载,导致路径不存在。 3. **参数问题**:用户使用的队列参数是`-q 2`,而日志中提到`mask = 2`失败,可能这个掩码对应的外设或日志类型在该设备上不可用,或者配置有误。 4. **输出目录问题**:虽然警告目录已存在,但可能权限不足导致无法写入,不过日志显示继续执行,所以可能不是主要原因。 我需要进一步确认这些可能性。例如,检查设备是否root,是否存在`/sys/bus/coresight`的相关路径,以及内核是否支持coresight功能。此外,用户使用的参数是否正确,特别是队列2是否适用于当前设备。可能还需要检查配置文件Default.cfg是否正确,是否有权限读取。 总结起来,最可能的失败原因是无法访问coresight的block_size文件,这通常与权限或内核支持有关。建议用户检查设备是否root,或者是否有调试接口的访问权限,同时确认内核配置是否包含必要的调试选项。</think>以下是您提供的日志分析及 `diag_mdlog` 执行失败的潜在原因: --- ### **关键错误信息提取** 1. **`byte_cntr - block_size open fail: /sys/bus/coresight/devices/coresight-tmc-etr/block_size error: No such file or directory`** - **核心问题**:无法访问内核调试组件 `coresight-tmc-etr` 的 `block_size` 文件。 - **可能原因**: - 设备未启用 **Coresight 调试功能**(需内核配置支持)。 - 访问 `/sys/` 路径需要 **Root 权限**,但当前未获取。 - 设备内核中未加载 `coresight-tmc-etr` 驱动模块。 2. **`diag: diag_qdss_init failed for mask = 2`** - **背景**:`mask=2` 对应 `-q 2` 指定的调制解调器日志队列。 - **失败影响**:因 `coresight-tmc-etr` 初始化失败,无法记录该队列的日志。 3. **`diag: No Session is active for the given mask`** - **可能原因**:指定队列(`-q 2`)未激活或设备不支持该日志通道。 --- ### **失败原因总结** #### **1. 权限不足** - **`/sys/` 路径访问限制**:读取 `coresight-tmc-etr` 调试接口需 **Root 权限**,普通用户或未解锁 Bootloader 的设备可能无法访问。 - **解决方案**: - 尝试使用 `adb root` 获取 Root 权限后重试。 - 确认设备已解锁调试限制(如 OEM 解锁)。 #### **2. 内核未支持 Coresight 调试** - **Coresight 功能缺失**:`coresight-tmc-etr` 是 ARM 调试跟踪组件,需内核配置启用以下选项: ```plaintext CONFIG_CORESIGHT=y CONFIG_CORESIGHT_TMC=y ``` - **解决方案**: - 检查内核配置是否包含上述选项(需设备厂商提供支持)。 - 部分商用设备可能移除调试功能以节省资源。 #### **3. 参数配置问题** - **无效的队列掩码(`-q 2`)**:设备可能不支持队列 2,或需其他参数组合激活。 - **解决方案**: - 尝试其他队列(如 `-q 1`)或省略 `-q` 参数。 - 检查配置文件 `Default.cfg` 是否与设备兼容。 #### **4. 日志目录权限** - **警告信息**:`Warning output directory already exists: /sdcard/diag_logs/` - **潜在问题**:若目录权限被限制(如 SELinux 策略),可能导致写入失败。 - **解决方案**: - 手动删除目录并重新创建:`adb shell rm -r /sdcard/diag_logs/ && mkdir /sdcard/diag_logs/` - 更换输出目录(如 `/data/local/tmp/`)。 --- ### **操作建议** 1. **获取 Root 权限**: ```bash adb root adb remount ``` 2. **验证 Coresight 驱动是否存在**: ```bash adb shell ls /sys/bus/coresight/devices/ ``` - 若输出包含 `coresight-tmc-etr`,则驱动已加载;否则需内核支持。 3. **简化命令测试**: ```bash adb shell diag_mdlog -o /data/local/tmp/ -s 100 ``` - 省略 `-q` 和 `-f` 参数,观察是否仍报错。 4. **联系设备厂商**:若为定制设备,需获取专用的诊断配置文件和内核支持。 --- ### **扩展说明** - **Coresight 调试框架**:ARM 处理器用于实时跟踪指令执行和内存访问的硬件级调试工具,常用于芯片厂商和深度内核调试。 - **高通诊断日志**:`diag_mdlog` 依赖芯片组与内核协同工作,若厂商裁剪了调试模块,则功能可能不可用。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值