诊断性能问题的一种常见方法是启用 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博客 ” ,链接:http://blog.itpub.net/58242/viewspace-891095/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/58242/viewspace-891095/