Back
How to set trace for others sessions, for your own session and at instance level
4 March 2004 - This paper has been extensively update to include more methods to set trace and also to explore
the new ways to set trace in Oracle 10g for multi-tier client server applications
This short paper is not a polished white paper (so please do not expect lots of explanatory text) but is intended to be a good example to show the many ways
to set Oracle trace in your own session or in another session. let's get on with it:
Tools to analyse trace files
Up to and including Oracle 10g the tool that is generally used to analyse trace files is called tkprof. This tool formats the trace files that have been
generated into a more readable format. Understanding the trace file format seems daunting on first inspection. A good source for details on the trace file
format is a metalink note 39817.1. In 10g there is a new tool for formatting trace files called trcsess.
This tool has been designed to deal with the new trace facilities that allow trace to be identified based on client identifier or by a combination of
service name / module / action. This allows trace to be completed even if connection pooling and multi-threading is used. An individual client in these
circumstances could share many different sessions.
Find out where the trace file will be written to
If the user you are using is not a DBA or to be more specific has not been granted access to the data dictionary view V$PARAMETER then you will need to use
this technique to find out where your trace files are written to:
If the user you are using has access to the base views then you can do the following instead.
Making trace files available
There is an undocumented parameter _trace_files_public that if set to true changes the file permissions in the user_dump_dest directory
when trace files are created to allow everyone to read them. This parameter can be checked with the following SQL. Beware that this is an undocumented
parameter and should not be routinely set to true as some information in trace files can be used by hackers or malicious users. You can set this parameter
by adding the following line to the init.ora file:
Here is the SQL to check the value of this parameter:
Let's start with some examples of how to check trace for another session that is connected to the database.
Now find the SID and SERIAL# of the other session
We are using a simple example and the session we are looking for is for the user SCOTT and we are logged into this session with AS SYSDBA. We
need to be logged in as SYS or AS SYSDBA so that we can access the packages DBMS_SUPPORT and DBMS_SYSTEM needed to set trace
in another session or in our own session. Again as with the first example about access to v$parameter a user with access to the views V$SESSION and V$PROCESS is needed.
First lets find the SID and SERIAL#
great the SID and SERIAL# that we need are 10 and 20.
A word about trace levels
Before we use the DBMS_SYSTEM package to set trace in SCOTT's session we need to discuss what levels are. Trace
in fact sets an event in the Oracle kernel (what is an event? - An event is simply a flag to the Oracle kernel
to tell it to emit some trace messages or to add some additional processing or to activate some new functionality.
Some events are used by support analysts and developers to force certain conditions to occur for testing purposes).
In our case we want to look at event number 10046 - This event tells the Oracle kernel to emit trace lines and timings.
The levels available in Oracle through some of the interfaces used to set trace are:
For a complete list of events that can be set look at the file $ORACLE_HOME/rdmbs/mesg/oraus.msg on Unix or Linux. This file is not shipped
on Windows systems. Also setting any event other that trace (10046) should not be done without the guidance of Oracle support.
Set trace in another session using DBMS_SYSTEM
First lets set trace in SCOTT's session using the DBMS_SYSTEM package. Before we do let's turn on
timed statistics so that the trace files get timing info and also set the dump file size so that there is plenty of room for the trace being generated.
OK, here we set trace in SCOTT's session
A second way to set trace in another session - This time setting trace level as well
Next we can again use the DBMS_SYSTEM interface but this time use the set event syntax. This allows us to set any event
in the database. This is of course not sanctioned by Oracle support and can cause damage to your database if not done correctly.
Use this interface with care and just set 10046 (trace) events. Here is how it is done:
Installing the DBMS_SUPPORT package
Using the example above we set trace to level 8, you can of course set it to any level you wish from the list we discussed above. Next we will
use the DBMS_SUPPORT package to set trace. This package is not installed by default and is in fact undocumented and indeed on some platforms and versions its not even shipped and
you will need to talk to Oracle support and get it from metalink. First we will install the package:
Use DBMS_SUPPORT to set trace in another users session
Next use the interface to again set trace for SCOTT's session that we found earlier. here it is:
use DBMS_SUPPORT to set trace in your own session
OK, that's how to set trace in SCOTT's session. How do we set trace in our own session. Well first we can use all of the
approaches seen above and pass in the SID and SERIAL# for our own session. There are other methods for setting trace in your own session
though. The first is again using the DBMS_SUPPORT package. Here it is:
Use DBMS_SESSION to set trace in your own session
The next method for setting trace in our own session also is done using a built in package, this time DBMS_SESSION. here it is:
using oradebug to set trace through SQL*Plus
oradebug is a debugging utility that is essentially undocumented and is intended for use by Oracle support analysts for various tasks one of
which is that it can be used to set trace. oradebug is available from svrmgrl before Oracle 9i and from SQL*Plus after. The first step
in using this tool is to find the OS PID or the Oracle PID of the process you want to analyse. You can do this as follows:
Now that we have found the Operating System PID and Oracle PID (values 864 and 13 in this case) of SCOTT's session we can use this to set trace with the oradebug tool as follows:
Some things to be aware of
You should be aware that some of these methods allow setting of extended trace and some do not. Those that allow extended trace are
easy to spot. These methods include ways to set the trace level or include variables suitably named such as waits or binds
which again enable extended trace facilities. Some trace methods have a default level such as set sql_trace=true which sets trace
to level 8. The rest set trace to normal trace levels.
One other point to note is that we have looked first at ways to set trace in another session to the one you are logged into and also now
at ways of setting trace in your own session, there is a third option, which is to set trace for the whole system (i.e for all users sessions),
This is not recommended unless you know what you are doing and are monitoring trace as you can quickly fill the file system.
Setting trace at the instance level using the init.ora
Trace can be set in the database initialization file the init.ora file. If you use spfile then you can still use the init.ora file and
then copy it to the spfile. Simply add the following line to the init.ora file:
You can also set timed_statistics and max_dump_file_size in the init.ora file in the same way. i.e
Trace can also be disabled at the instance level by simply commenting out the same parameter or by deleting it. A commented line is
shown next:
Or you can set the same parameter to false:
A second instance level method - setting events
Another method that can be used to set trace at the instance level is to add an event (or multiple events)to the initialization
file, the init.ora as described above. Again if you use spfile's then you can copy the init.ora to spfile or use
ALTER SYSTEM to set the value in the spfile. Here is an example of setting the trace event 10046 to level 12 in the initialization file:
Using ALTER SESSION to set trace in your own session
The alter session command can be used to set trace for the current session as follows:
This method can also be used to set timing and dump file size for the current session as follows:
Using ALTER SESSION to set extended trace using events
One last method I want to demonstrate is the alter session syntax to set events. Again stick to 10046 (trace)
and do not attempt to set any of the other events that are available without Oracles say so in a supported system.
Here is the example of setting trace to level 12, including binds and waits:
A sample logon trigger to set trace
Quite often you would like trace to be set for a session as soon as the user logs on. Also you may want to be able to
set trace for a specific set of users when they log in. This can easily be done with a database logon trigger. Here is a
sample trigger.
OK, that was easy. You can also use the alter session set events '10046 trace name context forever,level 12' syntax if you prefer
You can also enable other checks within the trigger if need by using any valid PL/SQL logic that you prefer. One tip is that if you have
any troubles with your system trigger and it causes logins to fail is to always include, as I have, an exception handler that calls null;
for any error condition. If all else fails you can disable system triggers by setting the parameter _system_trig_enabled=false in the
initialisation file. This undocumented / hidden parameter stops the processing of system triggers such as logon triggers.
Using ALTER SYSTEM to set trace at the instance level
Finally you can also use the alter system syntax to set trace at the system level. Here is a simple example:
Checking the privileges of the packages used to set trace
Some of the packages used in this example have to be run as SYS or you need to be logged in AS SYSDBA or specific privileges
need to be granted against those packages for the user that will run them. The default privileges for DBMS_SYSTEM, DBMS_SUPPORT and
for DBMS_SESSION are showed next in output from who_can_access.sql (A script that shows privileges hierarchically for an object who's
name is passed in). Here they are:
That's it, there are many ways to set trace in your session, in others sessions and at system level. Also many ways to enable
extended trace. Beware of the privileges needed to run some of them and beware of setting events explicitly.
New tracing methods in Oracle 10g - DBMS_MONITOR
Oracle 10g offers a new package to allow sessions to be traced end to end in multi-tier architectures that share sessions using
connection pooling or multi-threading. This package allows applications written using for instance JDBC / Java or something like
Forte to be traced where it would normally be very difficult to identify a database session belonging to a client as the sessions
/ clients pairings change with time.
The new functionality works in three levels. You can use the old SID / SERIAL# pairings to identify a session but you can also use
a client identifier or a service name / module / action to identify a client session to be traced. The package also offers
a set of procedures to allow statistics to be gathered for the same groups. These statistics can then be selected from dynamic views.
let's now take a look at some of the features of this package.
Setting trace with DBMS_MONITOR using SID / SERIAL#
Trace can be set for the current user session, for the current session or for another users session. First lets look at tracing another
users session. First we need to get the SID and SERIAL# - we will use SCOTT connected through SQL*Plus as our sample session:
OK as with previous methods we can use a SID / SERIAL# pair of 248 and 153. lets set trace for
this user session:
Setting trace at the session level using DBMS_MONITOR
The same procedures can be used to set trace for the session by omitting the serial#. This is demonstrated next:
Setting trace for the current session using DBMS_MONITOR
Setting trace for the current user session is done by leaving
out the SID and SERIAL# altogether by setting them to NULL. Here is an example:
That completes some of the ways to use DBMS_MONITOR to set trace using SID, SERIAL#, or at the
session level or for the current session.
Set trace using a client identifier
Tracing using the client identifier allows trace to be set across multiple sessions as many
Oracle shadow processes can work on behalf of one client. Also trace is persistent across all
instances and restarts. First we need to see how the client identifier is set. This can be done
using the DBMS_SESSION package as follows:
We can check now for a specific identifier in the V$SESSION view with the client_identifier column.
OK, now we can use this information to set trace for this client identifier as follows:
That was quite easy!. next let's look at setting trace at the service, module action levels.
Setting trace for service/module/action with DBMS_MONITOR
This method of setting trace acts hierarchically. The first level is that trace is set globally for
the whole database (all instances) You can override this by setting an instance name in the call to
turn on trace. For this example as I am on a single instance database I will leave this parameter at
its default. There are three levels to the hierarchy. If we set ACTION to NULL then all actions for
the module and service are traced. The next level, if we set MODULE to NULL then all actions for all
modules for the specified service name are traced. The trace will be collected into multiple trace
files and the new tool trcsess must be used to collate all the trace files into one usable file.
The service name can be set using the package DBMS_SERVICE and the procedure CREATE_SERVICE. Here is an example:
The service name can quite often be set already by the tool. It could be used to group together a set
of programs / modules that perform some business task. Next let's see how the module and actions can be set.
To view the relevant service names, modules and actions for sessions in the database you can use
the v$SESSION view as follows:
As we deleted our sample service name set up with DBMS_SERVICE.CREATE_SERVICE we will just use
the default value SANS inserted by Oracle in our test case. Let's test some of the methods of
setting trace with this functionality.
OK, that wraps up the new procedures in 10g that can be used to turn on trace in different ways
to capture true end to end trace for multi-tier applications. You should also be aware that
DBMS_MONITOR also provides procedures to enable statistic gathering at the same levels of
client identifier and service name/module/action. These statistics are stored and can
then be accessed by selecting from V$SERV_MOD_ACT_STATS and V$CLIENT_STATS views. I will not
detail those procedures here as this short paper is concentrating on trace only.
One last idea - use AUTOTRACE in SQL*Plus
OK, one final way to set and get trace, is to use the SQL*Plus AUTOTRACE facilities. There
are a few settings that you can use. These are as follows:
One more final item - CBO trace 10053
One other event that you might like to try and experiment with is the 10053 event. This event traces the Cost Based Optimizer (CBO)
and shows all of the plans and costs assigned to them that it tried in its search for the best cost and also is shows how it came
to its decision. The 10053 event has two levels 1 and 2. More detail is emitted if level 1 is used rather than level 2. The output
is again sent to a trace file in the directory specified by user_dump_dest. The trace is only generated if the SQL is hard parsed
and also obviously uses the CBO. To get a trace file you can use any of the methods above that allow the event number to be specified. An
example is:
An excellent document describing how to interpret CBO trace files called "A Look under the Hood of CBO - the 10053 Event.pdf" has been written by
Wolfgang Breitling of Centrex Consulting Corporation. The URL for Wolfgangs site is http://www.centrexcc.com/papers.html
Thanks for update suggestions from:
Thanks very much for update suggestions from the following people, your comments were very valuable for me.
SQL> set serveroutput on size 1000000 for wra
SQL> declare
2 paramname varchar2(256);
3 integerval binary_integer;
4 stringval varchar2(256);
5 paramtype binary_integer;
6 begin
7 paramtype:=dbms_utility.get_parameter_value('user_dump_dest',integerval,stringval);
8 if paramtype=1 then
9 dbms_output.put_line(stringval);
10 else
11 dbms_output.put_line(integerval);
12 end if;
13 end;
14 /
C:\oracle\admin\sans\udump
PL/SQL procedure successfully completed.
SQL>
SQL> select name,value
2 from v$parameter
3 where name='user_dump_dest';
NAME
----------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
user_dump_dest
C:\oracle\admin\sans\udump
SQL>
# allow trace files to be created with public permissions
_trace_files_public=true
# disable this feature:
#_trace_files_public=true
# or =>
_trace_files_public=false
SQL> select x.ksppinm name,y.ksppstvl value
2 from sys.x$ksppi x,sys.x$ksppcv y
3 where x.inst_id=userenv('Instance')
4 and y.inst_id=userenv('Instance')
5 and x.indx=y.indx
6 and x.ksppinm='_trace_files_public';
NAME
----------------------------------------------------------------
VALUE
--------------------------------------------------------------------------------
_trace_files_public
FALSE
SQL>
SQL> connect system/manager@sans as sysdba
Connected.
SQL> col sid for 999999
SQL> col serial# for 999999
SQL> col username for a20
SQL> col osuser for a20
SQL> select s.sid,s.serial#,s.username,s.osuser
2 from v$session s,v$process p
3 where s.paddr=p.addr;
SID SERIAL# USERNAME OSUSER
------- ------- -------------------- --------------------
1 1 SYSTEM
2 1 SYSTEM
3 1 SYSTEM
4 1 SYSTEM
5 1 SYSTEM
6 1 SYSTEM
7 1 SYSTEM
8 1 SYSTEM
9 253 SYSTEM ZULIA\pete
10 20 SCOTT ZULIA\pete
10 rows selected.
SQL>
SQL> exec dbms_system.set_bool_param_in_session(10,20,'timed_statistics',true);
PL/SQL procedure successfully completed.
SQL> exec dbms_system.set_int_param_in_session(10,20,'max_dump_file_size',2147483647);
PL/SQL procedure successfully completed.
SQL> -- now use standard dbms_support interface
SQL> exec dbms_system.set_sql_trace_in_session(10,20,true);
PL/SQL procedure successfully completed.
SQL> -- execute some code
SQL> exec dbms_system.set_sql_trace_in_session(10,20,false);
PL/SQL procedure successfully completed.
SQL>
SQL> exec dbms_system.set_ev(10,20,10046,8,'');
PL/SQL procedure successfully completed.
SQL> -- execute some code
SQL> exec dbms_system.set_ev(10,20,10046,0,'');
PL/SQL procedure successfully completed.
SQL> -- now do the same with dbms_support
SQL> -- the package has to be installed first - you should ask Oracle first though!
SQL> @%ORACLE_HOME%\rdbms\admin\dbmssupp.sql
Package created.
Package body created.
SQL>
SQL> exec dbms_support.start_trace_in_session(10,20,waits=>true,binds=>false);
PL/SQL procedure successfully completed.
SQL> -- execute some code
SQL> exec dbms_support.stop_trace_in_session(10,20);
PL/SQL procedure successfully completed.
SQL>
SQL> exec dbms_support.start_trace(waits=>true,binds=>false);
PL/SQL procedure successfully completed.
SQL> -- run some code
SQL> exec dbms_support.stop_trace;
PL/SQL procedure successfully completed.
SQL>
SQL> -- in your own session using dbms_session
SQL> exec dbms_session.set_sql_trace(true);
PL/SQL procedure successfully completed.
SQL> -- execut some code
SQL> exec dbms_session.set_sql_trace(false);
PL/SQL procedure successfully completed.
SQL>
SQL> connect system/manager@sans as sysdba
Connected.
SQL> col sid for 999999
SQL> col serial# for 999999
SQL> col spid for a8
SQL> col username for a20
SQL> col osuser for a20
1 select s.sid,s.serial#,p.spid,p.pid,s.username,s.osuser
2 from v$session s,v$process p
3* where s.paddr=p.addr
SQL> /
SID SERIAL# SPID PID USERNAME OSUSER
------- ------- -------- ---------- -------------------- --------------------
1 1 2528 2 SYSTEM
2 1 2536 3 SYSTEM
3 1 2540 4 SYSTEM
4 1 2544 5 SYSTEM
5 1 2552 6 SYSTEM
6 1 2604 7 SYSTEM
7 1 2612 8 SYSTEM
8 1 2652 9 SYSTEM
10 343 3740 12 SYS ZULIA\pete
12 70 864 13 SCOTT ZULIA\pete
10 rows selected.
SQL> -- set the OS PID
SQL> oradebug setospid 864
Windows thread id: 864, image: ORACLE.EXE
SQL> -- or set the Oracle pid
SQL> oradebug setorapid 13
Windows thread id: 864, image: ORACLE.EXE
SQL> -- set the trace file size to unlimitd
SQL> oradebug unlimit
Statement processed.
SQL> -- now turn on trace for SCOTT
SQL> oradebug event 10046 trace name context forever, level 12
Statement processed.
SQL> -- run some queries in another session and then turn trace off
SQL> oradebug event 10046 trace name context off
Statement processed.
sql_trace=true
timed_statistics=true
max_dump_file_size=unlimited
#sql_trace=true
sql_trace=false
# set the event in the init.ora
event = "10046 trace name context forever, level 12"
# to turn off the event simply comment out the line as follows:
# event = "10046 trace name context forever, level 12"
SQL> alter session set sql_trace=true;
Session altered.
SQL> -- execute some code
SQL> alter session set sql_trace=false;
Session altered.
SQL>
SQL> alter session set timed_statistics=true;
Session altered.
SQL> alter session set max_dump_file_size=unlimited;
Session altered.
SQL>
SQL> alter session set events '10046 trace name context forever, level 12';
Session altered.
SQL> -- execute some code
SQL> alter session set events '10046 trace name context off';
Session altered.
SQL>
Connected to:
Personal Oracle9i Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
SQL> create or replace trigger set_trace after logon on database
2 begin
3 if user not in ('SYS','SYSTEM') then
4 execute immediate 'alter session set timed_statistics=true';
5 execute immediate 'alter session set max_dump_file_size=unlimited';
6 execute immediate 'alter session set sql_trace=true';
7 end if;
8 exception
9 when others then
10 null;
11 end;
12 /
Trigger created.
SQL> sho errors
No errors.
SQL>
SQL> alter system set sql_trace=true scope=spfile;
System altered.
SQL>
SQL> -- to turn it off again do:
SQL> alter system set sql_trace=false scope=spfile
System altered.
SQL>
-- check who has access to dbms_system
who_can_access: Release 1.0.0.0.0 - Production on Fri Feb 27 12:53:24 2004
Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.
get user input
NAME OF OBJECT TO CHECK [USER_OBJECTS]: dbms_system
OWNER OF THE OBJECT TO CHECK [USER]: sys
OUTPUT METHOD Screen/File [S]:
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [/tmp]:
Checking object => SYS.DBMS_SYSTEM
====================================================================
Object type is => PACKAGE (TAB)
Privilege => EXECUTE is granted to =>
Role => OEM_MONITOR which is granted to =>
User => SYS
PL/SQL procedure successfully completed.
For updates please visit http://www.petefinnigan.com/tools.htm
SQL>
-- check who has access to dbms_support
who_can_access: Release 1.0.0.0.0 - Production on Fri Feb 27 12:54:29 2004
Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.
get user input
NAME OF OBJECT TO CHECK [USER_OBJECTS]: dbms_support
OWNER OF THE OBJECT TO CHECK [USER]: sys
OUTPUT METHOD Screen/File [S]:
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [/tmp]:
Checking object => SYS.DBMS_SUPPORT
====================================================================
PL/SQL procedure successfully completed.
For updates please visit http://www.petefinnigan.com/tools.htm
SQL>
-- check who has access to dbms_session
who_can_access: Release 1.0.0.0.0 - Production on Fri Feb 27 12:55:31 2004
Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.
get user input
NAME OF OBJECT TO CHECK [USER_OBJECTS]: dbms_session
OWNER OF THE OBJECT TO CHECK [USER]: sys
OUTPUT METHOD Screen/File [S]:
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [/tmp]:
Checking object => SYS.DBMS_SESSION
====================================================================
Object type is => PACKAGE (TAB)
Privilege => EXECUTE is granted to =>
Role => PUBLIC
PL/SQL procedure successfully completed.
For updates please visit http://www.petefinnigan.com/tools.htm
SQL>
SQL> select s.sid,s.serial#,s.username
2 from v$session s, v$process p
3 where s.paddr=p.addr
SQL> /
...
SID SERIAL# USERNAME
---------- ---------- ------------------------------
248 153 SCOTT
258 61 DBSNMP
251 418 SYSMAN
255 961 SYS
249 215
27 rows selected.
SQL>
SQL> exec dbms_monitor.session_trace_enable(248,153,TRUE,FALSE);
PL/SQL procedure successfully completed.
SQL> -- execute some sql
SQL> -- in the other session
SQL> -- turn trace off
SQL> exec dbms_monitor.session_trace_disable(248,153);
PL/SQL procedure successfully completed.
SQL>
SQL> exec dbms_monitor.session_trace_enable(248);
PL/SQL procedure successfully completed.
SQL> -- execute some sql in the other session
SQL> -- turn off trace
SQL> exec dbms_monitor.session_trace_disable(248);
PL/SQL procedure successfully completed.
SQL> -- or you can turn it on with
SQL> exec dbms_monitor.session_trace_enable(248,null);
PL/SQL procedure successfully completed.
SQL> -- turn off again with:
SQL> exec dbms_monitor.session_trace_disable(248,null);
PL/SQL procedure successfully completed.
SQL>
SQL> -- trace the current session
SQL> exec dbms_monitor.session_trace_enable(null,null);
PL/SQL procedure successfully completed.
SQL> -- execute some code
SQL> -- turn it off again
SQL> exec dbms_monitor.session_trace_disable(null,null);
PL/SQL procedure successfully completed.
SQL> -- to get waits and binds do
SQL> exec dbms_monitor.session_trace_enable(null,null,true,true);
PL/SQL procedure successfully completed.
SQL> -- execute some code
SQL> -- then turn off tracec
SQL> exec dbms_monitor.session_trace_disable(null,null);
PL/SQL procedure successfully completed.
SQL> -- or turn it on like this
SQL> exec dbms_monitor.session_trace_enable();
PL/SQL procedure successfully completed.
SQL> -- execute some SQL and then turn off trace
SQL> exec dbms_monitor.session_trace_disable();
PL/SQL procedure successfully completed.
SQL>
SQL> exec dbms_session.set_identifier('pete id');
PL/SQL procedure successfully completed.
SQL>
SQL> select s.username,s.client_identifier
2 from v$session s,v$process p
3 where s.paddr=p.addr
4 and client_identifier is not null;
USERNAME
------------------------------
CLIENT_IDENTIFIER
----------------------------------------------------------------
SCOTT
pete id
SQL>
SQL> exec dbms_monitor.client_id_trace_enable('pete id',true,false);
PL/SQL procedure successfully completed.
SQL> -- wait for the client session to do something
SQL> -- turn off trace as follows:
SQL> exec dbms_monitor.client_id_trace_disable('pete id');
PL/SQL procedure successfully completed.
SQL>
SQL> exec dbms_service.create_service('Test Service','test network');
PL/SQL procedure successfully completed.
SQL> -- it can be deleted with
SQL> exec dbms_service.delete_service('Test Service');
PL/SQL procedure successfully completed.
SQL>
SQL> -- set action
SQL> exec dbms_application_info.set_action('PAYMENT');
PL/SQL procedure successfully completed.
SQL> -- set the module
SQL> exec dbms_application_info.set_module('ACCOUNTS','PAYMENT');
PL/SQL procedure successfully completed.
SQL>
SQL> col service_name for a15 wrapped
SQL> col username for a15 wrapped
SQL> col module for a15 wrapped
SQL> col action for a15 wrapped
SQL> select s.username,s.service_name,s.module,s.action
2 from v$session s,v$process p
3 where s.paddr=p.addr;
...
USERNAME SERVICE_NAME MODULE ACTION
--------------- --------------- --------------- ---------------
SYSMAN SANS
SYSMAN SANS OEM.SystemPool
DBSNMP SYS$USERS emagent@emil (T
NS V1-V3)
DBSNMP SYS$USERS emagent@emil (T
NS V1-V3)
SYS$USERS
SYS SANS ACCOUNTS PAYMENT
SCOTT SANS SQL*Plus
...
29 rows selected.
SQL>
SQL> -- set trace for all modules and actions for SANS service name
SQL> exec dbms_monitor.serv_mod_act_trace_enable('SANS',DBMS_MONITOR.ALL_MODULES,DBMS_MONITOR.ALL_ACTIONS,TRUE,FALSE,NULL);
PL/SQL procedure successfully completed.
SQL> -- turn it off
SQL> exec dbms_monitor.serv_mod_act_trace_disable('SANS');
PL/SQL procedure successfully completed.
SQL> -- now trace all actions for service SANS and module accounts
SQL> exec dbms_monitor.serv_mod_act_trace_enable('SANS','ACCOUNTS',DBMS_MONITOR.ALL_ACTIONS,TRUE,FALSE,NULL);
PL/SQL procedure successfully completed.
SQL> -- now turn it off
SQL> exec dbms_monitor.serv_mod_act_trace_disable('SANS','ACCOUNTS');
PL/SQL procedure successfully completed.
SQL> -- finally test service SANS, module ACCOUNTS and action PAYMENT
SQL> exec dbms_monitor.serv_mod_act_trace_enable('SANS','ACCOUNTS','PAYMENT',TRUE,FALSE,NULL);
PL/SQL procedure successfully completed.
SQL> -- turn it off
SQL> exec dbms_monitor.serv_mod_act_trace_disable('SANS','ACCOUNTS','PAYMENT');
PL/SQL procedure successfully completed.
SQL> -- you can turn on or off binds and waits as well or use the waits=>true
SQL> -- syntax instead.
SQL>
SQL> alter session set events '10053 trace name context forever, level 1
Session altered.
SQL> -- execute some SQL to create a CBO trace.
SQL> -- turn CBO trace off
SQL> alter session set events '10053 trace name context off';
Session altered.
SQL>
Back