Oracle的跟踪文件(trace file)

跟踪文件通常都是因为通过DBMS_MONITOR(在Oracle Database 9i Relese 2)及更早版本中则是ALTER
SESSION SET SQL_TRACE=TRUE启用了跟踪的结果,或者是通过10046事件使用扩展的跟踪工具生成的,如下

这些跟踪文件包含与诊断和性能有关的信息。它们对于了解数据库应用的内部工作有着非凡的意义。在一个正常运行的数据库中,你会经常看到这些跟踪文件,而且远比看到其他类型的跟踪文件多得多。

1 文件位置

不论是使用DBMS_MONITOR、SQL_TRACE还是扩展的跟踪工具,Oracle都会在数据库服务器主机的以下两个位置生成一个跟踪文件。

  • 如果使用专用服务器连接,会在user_dump_dest参数指定的目录中生成跟踪文件。
  • 如果使用共享服务器连接,则会在background_dump_dest参数指定的目录中生成跟踪文件。

注意:11g版本中background_dump_dest和user_dump_dest参数将要被废弃掉,虽然还可以使用这两个参数进行查询但可以使用使用新的参数或视图进行查询。

使用show parameter
dump_dest命令来查看目录,也可以直接查询V$PARAMETER视图,或查询新的V$DIAG_INFO 视图。

V$DIAG_INFO是Oracle Database 11g新增的视图,这在较早的版本中还没有。它是访问新增ADR工具所用跟踪信息的一个更容易的接口。

Oracle Database 11g调整了很多文件的默认存储位置,使它们组织得更好一些,从而能更容易地记录对Oracle的服务请求。其中最重要的行包括下面两项:

  • Diag Trace:这是Oracle Database
        11g中跟踪文件(包括后台和用户转储目标)所在的位置。
  • Default Trace File:这是当前会话的跟踪文件名。在较早的版本中,这个文件名可能很难得到。在Oracle Database
        11g中,只需要对V$DIAG_INFO简单的查询就可以返回这个文件的完全限定文件名。

2命名约定

Oracle中跟踪文件的命名约定总在变化,示例如下:


跟踪文件名


数据库版本


ora_10583.trc


9i Release 1


ora9ir2_ora_1905.trc


9i Release 2


ora10gr2_ora_6793.trc


10g Release 2


ora11gr2_ora_1990.trc


11g Release 2

跟踪文件名可以分为以下几个部分。

文件名的第一部分是ORACLE_SID(但9i Release 1例外)

文件名的下一部分只有一个ora。

跟踪文件名中的数字是专用服务器的进程ID,可以从V$PROCESS视图得到。

Oracle Database 11g能方便使用V$DIAG_INFO视图,在该版本之前,实际(假设使用专用服务器模式)需要访问4个视图。

V$PARAMETER:找到USER_DUMP_DEST指定的跟踪文件位置,找到可能在跟踪文件名中用到的可选的tracefile_identifier。

V$PROCESS:查找进程ID。

V$SESSION:正确地标识其他视图中的会话信息。

V$INSTALCE:得到ORACLE_SID。

使用下面的查询可以生成跟踪文件名:

SELECT C.VALUE ||
‘/‘ || D.INSTANCE_NAME || ‘_ora_‘ || A.SPID || CASE

WHEN E.VALUE IS NOT NULL THEN

‘_‘ || E.VALUE

END || ‘.trc‘ TRACE

FROM V$PROCESS A, V$SESSION B, V$PARAMETER C,
V$INSTANCE D, V$PARAMETER E

WHERE A.ADDR = B.PADDR

AND B.SID = USERENV(‘sid‘)

AND C.NAME = ‘user_dump_dest‘

AND E.NAME = ‘tracefile_identifier‘;

如果文件存在就可以通过名字访问它。只有在启用跟踪后才能出现跟踪文件。在Windows平台上要把/换成\。

3 对跟踪文件加标记

有一种办法可以对跟踪文件“加标记”,这样即便无权访问V$PROCESS和V$SESSION,也能找到跟踪文件。假设你能读取user_dump_dest目录,就可以使用会话参数tracefile_identifier。采用这种方法可以为跟踪文件名增加一个可以唯一标识的串:

可以看到,跟踪文件还是采用标准的<ORACLE_SID>_ora_<PROCESS_ID>格式命名,但是这里还有为它指定的唯一的串,这样就能很容易找到跟踪文件名。

参考《Oracle 9i 10g 11g编程艺术  深入数据库体系结构 》

时间: 2024-10-16 05:16:40

Oracle的跟踪文件(trace file)的相关文章

oracle &nbsp; 11g 诊断文件

show parameter diagnostic_dest; SQL> show parameter diagnostic_dest NAME                     TYPE     VALUE------------------------------------ ----------- ------------------------------diagnostic_dest              string     /opt/oracle/app linux命令查

Oracle警告、跟踪文件(10046、死锁等跟踪)

跟踪文件由各个后台进程生成,警报日志中记录关键操作包括:     ·所有启动和关闭命令,包括中间命令,如alter database mount     ·实例的所有内部错误(ORA-600错误,只能报告给Oracle Support解决)     ·任何检测到的数据文件块损坏情况     ·任何已经发生的死锁     ·影响数据库物理结构的所有操作,如创建或重命名数据文件和联机重做日志     ·调整内部参数值的alter system命令     ·所有日志开关和日志归档文件 以Oracle

oracle之 利用 controlfile trace文件重建控制文件

一. 11g RAC 重建控制文件 1. --"create controlfile"命令生成到追踪文件中:alter database backup controlfile to trace; 2. --确认追踪文件的路径:SQL> select value from v$diag_info where name='Default Trace File'; 3. -- 截取脚本 在追踪文件中找到并执行NORESETLOGS版本的"create controlfile&

如何查找ORACLE中的跟踪文件

一.跟踪文件是干什么用的? 跟踪文件中包含了大量而详细的诊断和调试信息.通过对跟踪文件的解读和分析,我们可以定位问题.分析问题和解决问题.从跟踪文件的产生的来源来看,跟踪文件又可以分为两类:一类是数据库的操作人员有意生成的:另一类则是由于出现了异常错误,由数据库自动生成的.对于后一类,只对Oracle内部的技术支持人员是有用的,但对于我们,则多半看不懂.前一类,则是我们经常用到的,帮助我们分析.调整和优化应用性能,处理并解决问题. 二.跟踪文件是如何命名的? 一个跟踪文件的名字一般由以下几部分组

oracle中如何使用TKPROF命令查看Trace file

Trace file(追踪文件)是以trc为后续的文本文件,它记录了各种sql操作及所消耗的时间等,根据trace文件我们就可以了解哪些sql导致了系统的性能瓶颈,进而采取恰当的方式调优. 当我们操作oracle数据库,每次都会产生一个会话(session),session中记录了所有操作,这些操作都会记录在trace文件中. 如何使用TKPROF命令查看Trace file: SQL>alter session set sql_trace=true; SQL>select count(*)

使用SQL Profiler trace(2005)的经验分享(新建跟踪、分析跟踪文件)

转载:使用SQL Profiler trace(2005)的经验分享(新建跟踪.分析跟踪文件) SQL Server Profiler的使用方法可以见这篇Sql2005性能工具(SQL Server Profiler和数据库引擎优化顾问)使用方法详解 昨日,跟踪了某个程序的sql执行,然后打开trc(SQL Server Profiler的跟踪文件)一看,2分钟就记录了800条数据, 绝大多数都不是我想要的数据,这个工具也没有筛选功能,要从这么多数据中找出我想要的,还真是麻烦. 必应了一把,在S

ORACLE告警日志文件

告警日志介绍 告警日志文件是一类特殊的跟踪文件(trace file).告警日志文件命名一般为alert_<SID>.log,其中SID为ORACLE数据库实例名称.数据库告警日志是按时间顺序记录message和错误信息. 告警日志位置 在ORACLE 10g中,BACKGROUND_DUMP_DEST参数确定了告警日志的位置,但是告警日志的文件名无法修改,告警日志的名称为:alert_<SID>.log ,其中<SID>是实例的名称.BACKGROUND_DUMP_D

【翻译自mos文章】 在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容?

在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容? 參考原文: How to Find the Content of Trace File Generated for an Oracle Process after Removing the Trace File by Mistake at OS Level (Doc ID 805083.1) 适用于: Oracle Database - Enterprise Edition - Version

SQL Server中关于跟踪(Trace)那点事

前言 一提到跟踪俩字,很多人想到警匪片中的场景,同样在我们的SQL Server数据库中“跟踪”也是无处不在的,如果我们利用好了跟踪技巧,就可以针对某些特定的场景做定向分析,找出充足的证据来破案. 简单的举几个应用场景: 在线生产库为何突然宕机?数百张数据表为何不翼而飞?刚打好补丁的系统为何屡遭黑手?新添加的信息表为何频频丢失?某张表字段的突然更改,究竟为何人所为?这些个匿名的访问背后,究竟是人是鬼?突然增加的增量数据,究竟是对是错?数百兆的日志爆炸式的增长背后又隐藏着什么?这一且的背后,是应用