如何收集用来诊断性能问题的10046 Trace(SQL_TRACE) (文档 ID 1523462.1).pdf

让世界为你转身

7页

2次

2025-03-05

100墨值下载

如何收集用来诊断性能问题的10046 Trace(SQL_TRACE) (文档 ID 1523462.1)

文档内容

用途

问题和答案

收集10046 trace

参考

适用于:

Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) -

版本 N/A 和更高版本

Oracle Cloud Infrastructure - Database Service -

版本 N/A 和更高版本

Oracle Database Cloud Exadata Service -

版本 N/A 和更高版本

Oracle Database Backup Service -

版本 N/A 和更高版本

Oracle Database Exadata Express Cloud Service -

版本 N/A 和更高版本

本文档所含信息适用于所有平台

用途

这篇文档列举几种有效地收集10046

Trace的方法，用于诊断查询性能方面的问题。

此文档可供

DBA, 开发和技术支持人员使用。

问题和答案

收集

10046 trace

Event 10046

是为Oracle session收集扩展的sql_trace信息的标准方法, 这需要DBA权限。

关于这个

event的详细描述请参见以下文档：

Note 21154.1 EVENT: 10046 "enable SQL statement tracing (including binds/waits)"

通常为了诊断

SQL调优类问题，我们需要记录下这些语句在执行过程中产生的等待以及bind variables(绑定变量)的信息。这

些信息可以通过级别为12的10046

trace获得。下面的例子列举了在各种场景下，如何设定10046事件。

• Trace文件的位置

• 在Session级打开trace

• 跟踪一个已经开始的进程

• 实例层的跟踪

• 初始化参数设置

• 通过logon trigger设置跟踪

• 用SQLT收集trace

• 用DBMS_MONITOR进行跟踪

• 其它特定场景下打开跟踪的方法

• Trace文件解析

文档 1523462.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_a...

第1页共7页 2025/3/5 11:55

▪ Trace文件的位置

11g R1以上:

从11gR1开始，Oracle引入了新的诊断结构，以参数DIAGNOSTIC_DEST控制存放trace文件与core文

件的路径。

可以用以下命令，获取DIAGNOSTIC_DEST的位置：

SQL> show parameter diagnostic_dest

11gR1以前:

如果是用户进程，10046 trace文件会被生成在user_dump_dest下；如果是后台进程，trace文件会被

生成在background_dump_dest下。

下面的命令可以显示user_dump_dest:

SQL> show parameter user_dump_dest

注：下面的某些例子中会设定tracefile_identifier，通过这个设置可以帮助我们更容易的找到生成的

trace文件。

▪ 在Session级打开trace

适用于SQL语句可以在新的session创建后再运行。

在session级收集10046 trace：

alter session set tracefile_identifier='10046';

alter session set timed_statistics = true;

alter session set statistics_level=all;

alter session set max_dump_file_size = unlimited;

alter session set events '10046 trace name context forever,level 12';

执行需要被

trace

的

SQL --

select * from dual;

exit;

如果不退出当前session, 可以用以下命令关闭trace:

alter session set events '10046 trace name context off';

注意，如果session没有被彻底地关闭并且跟踪被停止了，某些重要的trace信息的可能会丢失。

注意：这里我们将"statistics_level"设置为all，这是因为有可能这个参数在系统级不是默认

值"TYPICAL"（比如 BASIC）。为了收集性能相关问题的信息我们需要打开某个级别的statistics。

我们推荐在 session 级将这个参数设置成 ALL 以便于收集更多的信息，尽管这不是必须的。

▪ 跟踪一个已经开始的进程

如果需要跟踪一个已经存在session，可以用 oradebug连接到session上，并发起10046 trace。

1. 首先，用某种方法找到需要被跟踪的session.

例如，在SQL*Plus里，找出目标session的OS的进程ID(spid):

select p.PID,p.SPID,s.SID

from v$process p,v$session s

where s.paddr = p.addr

文档 1523462.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_a...

第2页共7页 2025/3/5 11:55

and s.sid = &SESSION_ID

SPID 是操作系统的进程标识符（os pid）

PID 是Oracle的进程标识符(ora pid)

如果你不知道session的ID, 那么可以使用类似下面的SQL语句来帮助你找到它

column line format a79

set heading off

select 'ospid: ' || p.spid || ' # ''' ||s.sid||','||s.serial#||''' '||

s.osuser || ' ' ||s.machine ||' '||s.username ||' '||s.program line

from v$session s , v$process p

where p.addr = s.paddr

and s.username <> ' ';

如果是使用了12c的multi thread下，那么需要使用v$process中新的列stid来找到对应的

thread, 因为Oracle把多个processes放进了一个单独的 ospid 中。如果想找到特定的

thread, 使用下面的语法:

oradebug setospid <spid> <stid>

▪ 一旦找到OS PID，就可以用以下命令初始化跟踪：

假设需要被跟踪的OSPID是9834。

以sysdba的身份登录到SQL*Plus并执行下面的命令：

connect / as sysdba

oradebug setospid 9834

oradebug unlimit

oradebug event 10046 trace name context forever,level 12

记得把例子中的'9834' 替换成真实的os pid。

注：也可以通过oradebug使用 'setorapid'命令连接到一个session。

下面的例中，使用

PID

（Oracle进程标识符）(而不是SPID), oradebug命令将被改为：

connect / as sysdba

oradebug setorapid 9834

oradebug unlimit

oradebug event 10046 trace name context forever,level 12

记得把例子中的9834替换成真实的ora pid。

文档 1523462.1 https://support.oracle.com/epmos/faces/DocumentDisplay?_a...

第3页共7页 2025/3/5 11:55

of 7

100墨值下载

oracle

相关文档

评论