Auditing an Oracle database for security issues is very important. PeteFinnigan.com provides all of the information and tools that you will need Click here for details of PeteFinnigan.com Limited's detailed Oracle database security audit service Click here for details of PeteFinnigan.com Limited's Oracle Security Training Courses
There are 61 visitors online    
Cookie Policy:We only use essential cookies on small sections of this website. For details see here.


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:

	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> 						
						

If the user you are using has access to the base views then you can do the following instead.

	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> 						
						

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:

	# 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						
						

Here is the SQL to check the value of this parameter:

	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> 						
						

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#

	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> 						
						

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:

  • Level 0 = No statistics generated
  • Level 1 = standard trace output including parsing, executes and fetches plus more.
  • Level 2 = Same as level 1.
  • Level 4 = Same as level 1 but includes bind information
  • Level 8 = Same as level 1 but includes wait's information
  • Level 12 = Same as level 1 but includes binds and waits

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.

	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.
						
						

OK, here we set trace in SCOTT's session

	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> 						
						

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:

	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.							
						

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:

	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> 						
						

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:

	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> 					
						

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:

	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> 						
						

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:

	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> 						
						

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:

	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.
				
						

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:

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.
						

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:

	sql_trace=true
						

You can also set timed_statistics and max_dump_file_size in the init.ora file in the same way. i.e

	timed_statistics=true
	max_dump_file_size=unlimited
						

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:

	#sql_trace=true
						

Or you can set the same parameter to false:

	sql_trace=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:

	# 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"	
						

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:

	SQL> alter session set sql_trace=true;
	
	Session altered.
	
	SQL> -- execute some code
	SQL> alter session set sql_trace=false;
	
	Session altered.
	
	SQL> 
						

This method can also be used to set timing and dump file size for the current session as follows:

	SQL> alter session set timed_statistics=true;
	
	Session altered.
	
	SQL> alter session set max_dump_file_size=unlimited;
	
	Session altered.						
	
	SQL>
						

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:

	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> 						
						

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.

	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> 						
						

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:

	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>
						

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:

	-- 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> 						
						

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:

	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>
						

OK as with previous methods we can use a SID / SERIAL# pair of 248 and 153. lets set trace for this user session:

	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>
						

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:

	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>
						

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:

	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> 
						

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:

	SQL> exec dbms_session.set_identifier('pete id');

	PL/SQL procedure successfully completed.

	SQL> 
						

We can check now for a specific identifier in the V$SESSION view with the client_identifier column.

	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>
						

OK, now we can use this information to set trace for this client identifier as follows:

	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>
						

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:

	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> 
						

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.

	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>
						

To view the relevant service names, modules and actions for sessions in the database you can use the v$SESSION view as follows:

	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> 
						

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.

	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> 
						

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:

  • set autotrace off - The default - no output
  • set autotrace on explain - This shows only the optimizer path
  • set autotrace on statistics - This only shows SQL statistics
  • set autotrace on - Includes both of the above
  • set autotrace traceonly - As above but the query output is not displayed

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:

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> 						
						

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.

  • Mladen Gogola
  • Henry Poras
  • Jacques Kilchoer
  • Nick Havard



Back