诊断性能问题的一种常见方法是启用 sql_trace 来跟踪数据库调用，然后使用 tkprof 等工具来分析输出。但是，这种方法在具有共享服务器体系结构的数据库中具有严重的局限性。在这种配置中，创建了若干个共享服务器进程，为用户的请求提供服务。当用户 BILL 连接数据库时，调度程序将连接传递到一个可用的共享服务器进程。如果没有可用的共享服务器进程，则创建一个新进程。如果开始跟踪该会话，则会跟踪由共享服务器进程所进行的调用。[@more@]现在假设 BILL 的会话变为空闲状态，而 LORA 的会话变为活动状态。此时最初为 BILL 提供服务的共享服务器被分配给 LORA 的会话。这样，发出的跟踪信息不是来自 BILL 的会话，而是来自 LORA 的会话。当 LORA 的会话变为非活动状态时，该共享服务器可以被分配给另外的活动会话，这个会话将具有完全不同的信息。

在 10g 中，通过使用端到端跟踪，已经有效地解决了这一问题。在这种情况下，跟踪不仅根据会话进行，还可根据客户标识符等可识别的名称来进行。一个名为 DBMS_MONITOR 的新程序包可用于此目的。

例如，您可能希望跟踪所有具有标识符 account_update 的会话。为建立跟踪，您可以执行：

exec DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE('account_update');

此命令开始跟踪所有具有标识符 account_update 的会话。当 BILL 连接数据库时，他可以使用以下语句来设置客户标识符：

exec DBMS_SESSION.SET_IDENTIFIER ('account_update')

跟踪对于具有标识符 account_update 的会话起作用，因此以上的会话将会被跟踪，并会在用户卸出目标目录中产生一个跟踪文件。如果另一个用户连接数据库并将其客户标识符设置为 account_update，则自动跟踪该会话，不需要在代码中设置任何其他的命令。直到使用以下命令禁用跟踪功能前，将跟踪所有具有客户标识符 account_update 的会话：

exec DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE('account_update');

作为结果的跟踪文件可以由 tkprof 进行分析。但是，每个会话都产生不同的跟踪文件。为了正确地诊断故障，我们关心合并的跟踪文件而不是单独的跟踪文件。我们如何获得合并的跟踪文件呢？

很简单。利用一种称为 trcsess 的工具，您可以将那些与客户标识符 account_update 相关的信息提取到一个单独的文件中，通过 tkprof 可以处理该文件。在以上的案例中，您可以转到用户卸出目标目录中并运行：

trcsess output=account_update_trc.txt clientid=account_update *

此命令创建一个名为 account_update_trc.txt 的文件，该文件与常规的跟踪文件类似，但它只包含与那些具有客户标识符 account_update 的会话相关的信息。该文件可以使用 tkprof 进行处理，以获得经过分析的输出。

将这种方法和前一种更困难的跟踪信息收集方法对比此外，跟踪是由客户标识符这样的变量来启用和禁止的，而不需要从该会话中调用 alter session set sql_trace = true。同一程序包中的另一个过程 SERV_MOD_ACT_TRACE_ENABLE 能够在其他组合方式中启用跟踪功能，如用于特定服务、模块或操作的组合，可以利用 dbms_application_info package 来进行设置.

ITPub博客

ORACLE 10G 新特性之-----端到端跟踪（TRACE）

最新文章