Oracle Session Tracing Part I James F. Koopmann posted 5/18/2007 | Comments (2) This is the first in a series to introduce some of the new tracing concepts and options within Oracle. This installment focuses on the new CLIENT_IDENTIFIER environment variable that can be assigned to sessions. The goal of this series is to inform DBAs on how to track and trace connected sessions so that they can properly determine where sessions are experiencing performance problems. This article presents the very important concept of assigning a client identifier to a session. This client identifier will be used in future articles as this will be one way to initiate traces. This article first presents the issue of why we should use the client identifier and then how we can utilize it when looking at sessions as they are connected in real time. To begin, we must first come to grips with the simple concept of the globalization of sessions within Oracle that occurs. The days of single dedicated server connections and one connection uniquely identifying a single user are long gone. Now many middle-tier applications make use of pooling mechanisms that hide the identity of a connected user or session that does not allow you or me to adequately track and trace effectively because of the reuse of session ids. This is where you need to start thinking of defining your own client identifier for the users that use your database systems. This is just what Oracle now has and through the use of a client identifier allows for you to either further segregate or consolidate sessions by assigning an identifier that describes the connection for a particular user or set of users.. For example, suppose you have a development environment where everyone logs in as a particular schema user and because of the connection mechanisms employed, users will reuse the same session id sometimes when they connect. Well, if you ever wanted to trace these sessions to determine who was consuming vast amounts of resources or was issuing particular SQL, you would be very hard pressed to run a trace and filter for
Transcript
Oracle Session Tracing Part I James F. Koopmann posted 5/18/2007 | Comments (2) This is the first in a series to introduce some of the new tracing concepts and options within Oracle.
This installment focuses on the new CLIENT_IDENTIFIER environment variable that can be assigned to sessions.
The goal of this series is to inform DBAs on how to track and trace connected sessions so that they can properly determine where sessions are experiencing performance problems. This article presents the very important concept of assigning a client identifier to a session. This client identifier will be used in future articles as this will be one way to initiate traces. This article first presents the issue of why we should use the client identifier and then how we can utilize it when looking at sessions as they are connected in real time.
To begin, we must first come to grips with the simple concept of the globalization of sessions within Oracle that occurs. The days of single dedicated server connections and one connection uniquely identifying a single user are long gone. Now many middle-tier applications make use of pooling mechanisms that hide the identity of a connected user or session that does not allow you or me to adequately track and trace effectively because of the reuse of session ids. This is where you need to start thinking of defining your own client identifier for the users that use your database systems. This is just what Oracle now has and through the use of a client identifier allows for you to either further segregate or consolidate sessions by assigning an identifier that describes the connection for a particular user or set of users.. For example, suppose you have a development environment where everyone logs in as a particular schema user and because of the connection mechanisms employed, users will reuse the same session id sometimes when they connect. Well, if you ever wanted to trace these sessions to determine who was consuming vast amounts of resources or was issuing particular SQL, you would be very hard pressed to run a trace and filter for that user since the high activity would not guarantee any one user was on a particular session id. This is where you could employ the use of a client identifier as Oracle now lets us trace and trace reports on a unique client identifier. To get this going all you need to do is invoke the DBMS_SESSION.SET_IDENTIFIER procedure when the session logs in. Figure 1 gives a very simplistic method through a logon trigger to set the client identifier. You can use anything to distinguish the session such as IP address, computer / host name, o/s user, or a predefined application name. I have taken use of the DBMS_CONTXT calls for user environment information.
Figure 1Logon trigger to set client_identifier
CREATE OR REPLACE TRIGGER LOGON_TRIGGERAFTER LOGON ON DATABASEDECLAREv_user_identifier varchar2(64);BEGINSELECT SYS_CONTEXT('USERENV', 'OS_USER')
||':'|| SYS_CONTEXT('USERENV', 'IP_ADDRESS') INTO v_user_identifier FROM dual;DBMS_SESSION.SET_IDENTIFIER(v_user_identifier);END;/
Now when we take a look at the V$SESSION view, we can see this CLIENT_IDENTIFIER set for various sessions. Listing 1 gives this type of output. Now if we had the same database user connect through some polling mechanism, if we set our client identifier properly, we have the potential to see a different client identifier. Also if we want to set the same client identifier for a group of users, we could do that also. There are also methods of setting the client identifier from within OCI and JDBC.
We will get to actually tracing in a future article but basically the columns supplied in the SQL select statement in Listing 1 are all allowed to filter and consolidate tracing statistics on. Hopefully you can see that by setting a client identifier we have just added great power in determining the unknown users of our database. We can now through extra tracing options determine who and what's causing problems in our database. Also note that because this field can be changed at will, there is nothing to limit you to keeping the same CLIENT_IDENTIFIER for the life of the session. This may come in handy if your session actually performs different tasks that distinguish it from other sessions that originally had the same identifier.
After setting this client identifier, we have already seen that you may view this setting by the a query to the V$SESSION view. You may can also see the statistics around a particular CLIENT_IDENTIFIER from the V$ACTIVE_SESSION_HISTORY view. Listing 2 gives a query that we would typically issue to see the historical wait activity for sessions in the last 30 minutes. Notice that we have the same client identifier (CLIENT_ID) for each of the rows. This is fine if you are concerned with only tracking down one session that might be experiencing high wait times but sometimes it is the accumulated wait time that is caused by an application you are concerned about. To answer that question we can group on the CLIENT_ID column now and get a summation for a particular client identifier. This does assume you have set your client identifier to something more than what I have set mine to and something in line with the application area
of interest. Listing 3 shows just such a query you might issue to sum total waits for an application area or in my case user connection across multiple sessions.
Listing 2Looking at individual session wait activity
select session_id, client_id, event, sum(wait_time + time_waited) ttl_wait_time from v$active_session_history active_session_history where sample_time between sysdate - 60/2880 and sysdate group by session_id, client_id, event order by 2;
SESSION_ID CLIENT_ID EVENT TTL_WAIT_TIME---------- -------------------- ------------------------------ ------------- 145 jkoopmann:127.0.0.1 SQL*Net message to client 3 145 jkoopmann:127.0.0.1 db file scattered read 111167 145 jkoopmann:127.0.0.1 db file sequential read 59003 145 jkoopmann:127.0.0.1 direct path read temp 93314 145 jkoopmann:127.0.0.1 direct path write temp 2 156 jkoopmann:127.0.0.1 SQL*Net message from client 243192681 160 jkoopmann:127.0.0.1 db file scattered read 18657 160 jkoopmann:127.0.0.1 db file sequential read 28141 160 jkoopmann:127.0.0.1 direct path read temp 4887 160 jkoopmann:127.0.0.1 direct path write temp 24
Listing 3Accumulated wait activity for an application area or user defined area
select client_id, event, sum(wait_time + time_waited) ttl_wait_time from v$active_session_history active_session_history where sample_time between sysdate - 60/2880 and sysdate group by client_id, event order by 1;
CLIENT_ID EVENT TTL_WAIT_TIME-------------------- ------------------------------ -------------jkoopmann:127.0.0.1 SQL*Net message from client 243192681jkoopmann:127.0.0.1 SQL*Net message to client 3jkoopmann:127.0.0.1 db file scattered read 129824jkoopmann:127.0.0.1 db file sequential read 115553jkoopmann:127.0.0.1 direct path read temp 98201jkoopmann:127.0.0.1 direct path write temp 26
Also if you ever find yourself wanting to know what your CLIENT_IDENTIFIER is set to so that you can monitor or take some for of logical action within an application, you need only issue the following SQL.
SELECT SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER') CLIENT_IDENTIFIER FROM DUAL;
If you ever wish to clear out the CLIENT_IDENTIFIER for a session, you need only execute the following procedure.DBMS_SESSION.CLEAR_IDENTIFIER
The use of a CLIENT_IDENTIFIER can come in handy for many situations where monitoring individual sessions or a group of sessions is required. It does not matter if those sessions connect to the same session id or different ones. If you choose your client identifier properly for groups of applications or users, you can now generate true wait related information that tells you exactly what they have been doing. Stay tuned for more session tracing in the next part of this series.
Oracle Session Tracing Part II James F. Koopmann posted 5/26/2007 | Comments (1) Read on and learn how to set the module and action names.In Part I of this Session Tracing Series we learned how to set the CLIENT_IDENTIFIER session variable and how we could query it from the V$SESSION view. We also looked at how to look at the resources consumed in real-time for that CLIENT_IDENTIFER so that we could determine if large amounts of resources were attributed to a unique or group of client connections. If you remember from Part I, we invoked a logon trigger whenever a session connected and then queried the V$SESSION view. This gave us output similar to that of Listing 1. From this output you can see a CLIENT_IDENTIFIER that is being set, I changed the logon trigger to put in host name instead of IP address in this example, and you can see that the module name did get populated for the applications I used to connect from (SQL*Plus and Oracle Administrative Assistant). Also note that the action field is blank. Also notice that the there are two connections using SQL*Plus from host FINE-ALE and one connection from host PAULANER.
Listing 1V$SESSION output
SQL> SELECT sid, client_identifier, action, module FROM V$SESSION
granularity on the actual amount of resources that are being consumed within certain modules of code or within certain business units of work we need to now look at the DBMS_APPLICATION_INFO package provided by Oracle. Most applications will give some form of module name when you see connections coming across but will leave the ACTION name unset. The setting of a module name is fine for some circumstances but to get a real indication of where in the code resources are being done both fields should be considered when writing applications. This naming will allow you as a DBA or developer the ability to track down unique connections that you are concerned with in real-time or for latter tracing runs. This granularity is highly desired when debugging a performance bottleneck and you will want to pin point what application module is consuming the most resources through the MODULE name and what is being done (ACTION) within the code. To do this, it is imperative, that the applications set the name of the module and the action being performed each and every time it enters a new module or the action of the transaction changes. The module name could be the section of code or procedure being executed, while the action could be a business unit of work or an individual statement. The purpose is to be able to tie resources used to a unit of work that you are concerned about.
Calling the DBMS_APPLICATION_INFO PackageUsing the DBMS_APPLICATION_INFO package is quite simplistic. A simple call to SET_ACTION is all that is required to set the ACTION name. This call has the form of:
DBMS_APPLICATION_INFO.SET_ACTION (action_name IN VARCHAR2);
So if you wanted to set the ACTION to 'LOGON TRIGGER' you could construct the call as:
This action name should be very descriptive of the type of action being done within the code and is always best to set this before the actual action is performed. That way when the action is being performed you will see the ACTION in the V$SESSION view and know that it is currently being done. When the transaction or specific action is complete within your code you should set it back to NULL or to the next action to be performed. This setting of to NULL or a valid next transaction type is very important. If you do not adhere to this pattern, future resources will be attributed to the last ACTION and you will lose any true performance statistics.The setting of the MODULE name is done through a call to the SET_MODULE procedure and has the form of:
DBMS_APPLICATION_INFO.SET_MODULE( module_name IN VARCHAR2, action_name IN VARCHAR2);
All of the suggestions around setting the ACTION apply to the setting the MODULE name as well. When setting this naming field, you want to set it before the actual execution within the code is started and you want to make sure to set the MODULE back to NULL or to the next MODULE to be executed so as to not miss-represent any statistics encountered after the true execution of the code is complete. As you might have recognized, this SET_MODULE procedure allows for the setting of the ACTION name also. You should use this to set your MODULE and ACTION name when first entering a new module of code but use the
SET_ACTION procedure after in the module. This will limit some of the overhead of setting these names as I am sure there are some miniscule locking going on behind the scenes. So for our logon trigger if I wanted to now set the actual MODULE and ACTION names it would look like that of Figure 1. You should note that this is quite an extreme example of setting these session variables but really just wanted to give a flavor for how to do this. Notice that the MODULE name was set to 'LOGON_TRIGGER' and the ACTION is to indicate a SELECT from DUAL. Also note that at the end of the trigger we set the MODULE and ACTION back to NULL so that we are certain not to mess up statistical collection. Also please note that I have put in a call to the DBMS_LOCK package to sleep so that I could see this setting of the MODULE and ACTION names.
Figure 1Logon trigger to set client_identifier, module, and action
CREATE OR REPLACE TRIGGER LOGON_TRIGGERAFTER LOGON ON DATABASEDECLAREv_user_identifier varchar2(64);BEGINDBMS_APPLICATION_INFO.SET_MODULE( module_name => 'LOGON_TRIGGER', action_name => 'SELECT FROM DUAL');SELECT SYS_CONTEXT('USERENV', 'OS_USER') ||':'|| SYS_CONTEXT('USERENV', 'HOST') INTO v_user_identifier FROM dual;DBMS_SESSION.SET_IDENTIFIER(v_user_identifier); dbms_lock.sleep(5);DBMS_APPLICATION_INFO.SET_MODULE(NULL,NULL);END;/
Now when we query the V$SESSION view we can see the setting of these variables through Listing 2. After the DBMS_LOCK.SLEEP call is complete the MODULE name returns to 'SQL*Plus' and the ACTION is NULL. I am thinking this is a function of just using SQL*Plus and you should not rely on Oracle setting these back to the original call.Listing 2V$SESSION output after setting MODULE and ACTION names
SQL> SELECT sid, client_identifier, action, module FROM V$SESSION
Proper setting of the ACTION and MODULE name are imperative for collecting statistics around specific code functions and transactions. Once they are set you can now begin getting those fine grain details about the area of code that is performing poorly. Next time we start looking at how to actually pull out of current sessions that fine grain information to zero in on where we need to concentrate our tuning efforts.
Oracle Session Tracing Part III James F. Koopmann posted 6/1/2007 | Comments (1) Explore how to enable and disable Oracle tracing with DBMS_MONITOR package in 10g.
In Part I we learned how to set the CLIENT_IDENTIFIER session variable to more accurately pinpoint resource consumption for an individual user or group of users. We did this through queries to real-time activity views such as V$SESSION and V$ACTIVE_SESSION_HISTORY.
In Part II we learned how to set the ACTION and MODULE name so that we could track where in our code transactions where being executed and track the use of resources by transaction type or section of code.
Along with these possibly new session identifiers, there has always been three session environment variables that get set from when a user connects to the database and are important when talking about tracing a particular session or group of sessions. These would be the SID, SERIAL#, and SERVICE_NAME. These have been around Oracle sessions for quite some time but are presented in Table 1 with the three new variables presented in Parts I & II of this series to provide for a quick refresher. This set of six session variables now gives us the ability to activate tracing for the session in a variety of ways.
Table 1Session Variable DescriptionSID Identifier for the connected session.SERIAL# Serial number of the connected. SERVICE_NAME Service name of the session and represents the database connected to.MODULE Name to represent the module or code being executed. ACTION Name to represent the action being performed by the module.CLIENT_IDENTIFIER Identifier to represent the client session
DBMS_MONITOR Package
In Oracle 10g, we have been given the DBMS_MONITOR package. This package allows us to interact and control the tracing and statistics gathering of sessions through a PL/SQL interface. Table 2 gives all of the programs we can call through the DBMS_MONITOR package. As you can see, all our six variables are represented for us to begin tracing through. Table 3 gives a
DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE (client_id, waits, binds);(Notes)waits : If TRUE, wait information is present in the trace.Binds : If TRUE, bind information is present in the trace.
SERV_MOD_ACT_STAT_ENABLESERV_MOD_ACT_STAT_DISABLE
DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE (service_name, module_name, action_name);(Notes)Action_name, may be an empty field if not defined for the session.
To reference ALL sessions that have an action_name defined, use the DBMS_MONITOR.ALL_ACTIONS variable. To reference ALL sessions that do not have this variable defined, use NULL.The contents of this field is actually '###ALL_ACTIONS' and you should avoid naming any actions or module names with this.
DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE (service_name, module_name, action_name, waits, binds, instance_name);(Notes)Action_name, may be an empty field if not defined for the session. To reference ALL sessions that have an action_name defined, use the DBMS_MONITOR.ALL_ACTIONS variable. To reference ALL sessions that do not have this variable defined, use NULL.The contents of this field is actually '###ALL_ACTIONS' and you should avoid naming any actions or module names with this.waits : If TRUE, wait information is present in the trace.Binds : If TRUE, bind information is present in the trace.instance_name restricts tracing to the named instance_name.
SESSION_TRACE_ENABLE SESSION_TRACE_DISABLE
DBMS_MONITOR.SESSION_TRACE_ENABLE (session_id, serial_number, waits, binds)(Notes)session_id, Must provide. If just a session_id is given than all serial numbers will be traced. If session_id and serial_number are NULL than you trace your own current session.waits : If TRUE, wait information is present in the trace.Binds : If TRUE, bind information is present in the trace.
Examples to Enable / Disable Tracing
Before you can enable or disable tracing you need to first determine the connected session or group of sessions you would like to trace. If you have set the CLIENT_IDENTIFIER, MODULE_NAME, or ACTION_NAME as prescribed in the previous parts to this series you do not necessarily need to look for them as you should have a list that describes their actions. Although sometimes you are tuning in a more adhoc environment where you are only concerned with what is effecting your system currently. This could be an individual session or a group of sessions which will be defined by their CLIENT_IDENTIFIER, MODULE_NAME, ACTION_NAME, or SERVICE_NAME. To get a feel for what is executing currently on your
system you need only query the V$SESSION view. Listing 1 gives the SQL and results of what you might see.
2. Enable tracing for CLIENT_IDENTIFIER johnny:127.0.0.2 with wait information but no bind information EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE('johnny:127:0.0.2',TRUE,FALSE);
3. Enable statistics gathering for service_name ACCT, module PAYROLL, and all actions EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE('ACCT','PAYROLL',DBMS_MONITOR.ALL_ACTIONS);
4. Enable tracing for servide_name HR but only for the ADDEMPLOYEE module and include wait and bind information. EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE('HR','ADDEMPLOYEE', DBMS_MONITOR.ALL_ACTIONS,TRUE,TRUE,NULL);
5. Enable tracing for session id 142 and include wait and bind information
6. Trace my current sessionEXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE(NULL,NULL, TRUE, TRUE);
View your Enabled Tracing
To take a look at what you have enabled tracing and statistics gathering for you need only take a look at the two views DBA_ENABLED_TRACES and DBA_ENABLED_AGGREGATIONS. Listing 2 gives the output from selecting from these two views for our examples. Notice that the examples 5 & 6 where we started a trace for the sessions did not show up in Listing 2. These must still be recognized by going to the user dump location on disk and looking for the trace files generated.
AGGREGATION SERVICE MODULE ACTION-------------------- -------------------- -------------------- --------------------CLIENT_ID webclientSERVICE_MODULE ACCT PAYROLL
Enabling and disabling tracing and statistical gathering has taken on a whole new meaning in Oracle 10g. It has become easier to enable and manage with the DBMS_MONITOR package. We are not strapped by the old methods of tracing where we could just trace an individual session but can now trace across sessions by using the CLIENT_IDENTIFIER, SERVICE_NAME, MODULE_NAME, and ACTION_NAME. Next time we will look at where some of the actual tracing information resides and how to query from internal tables in Oracle.
Oracle Session Tracing Part IV James F. Koopmann posted 6/8/2007 | Comments (0) In Part III we left off displaying the enabled traces and statistic gatherings we enabled through the DBMS_MONITOR package.Recall that in Part III we queried the DBA_ENABLED_AGGREGATIONS view and had a listing such as in Listing 1. Table 1 gives a breakdown of the DBA_ENABLED_AGGREGATIONS view as I have renamed some of the columns for Listing 1.
Listing 1
DBA_ENABLED_AGGREGATIONSSQL> SELECT * FROM DBA_ENABLED_AGGREGATIONS ;
AGGREGATION SERVICE MODULE ACTION-------------------- -------------------- -------------------- --------------------CLIENT_ID webclientSERVICE_MODULE ACCT PAYROLL
This is the type of statistical aggregation being done. This relates to the actual procedure called in the DBMS_MONITOR package. In Listing 1 I we have called the CLIENT_ID_STAT_ENABLE and SERV_MOD_ACT_STAT_ENABLE procedures
PRIMARY_ID This is the CLIENT_IDENTIFIER or SERVICE_NAME in the callQUALIFIER_ID1 The module nameQUALIFIER_ID2 The action name
In the last three parts of this series we have also zeroed in on setting different session environment variables. Those variables were CLIENT_IDENTIFIER, ACTION, and MODULE. We have also tracked some of the sessions by SID, SESSION_ID, SERVICE_NAME, and SERIAL#. I thought it might be interesting to take a look at where within Oracle's internal views these columns might be defined as this could help us in our future needs of investigation. Instead of searching through the endless documentation of Oracle, I instead decided to produce a query (Listing 2) in which I queried the DBA_TAB_COLUMNS view to take a look at what internal Oracle views or objects have these columns in common. I can then from the output take a look at the definitions of those named objects that intrigue me. Listing 2 is only a partial listing and I encourage you to execute the query and see the total output. That way if you are ever interested in searching for a singe column or combination of columns you will know where within the Oracle internal views this information is stored. Do not take this output too lightly. If you remember that we were enabling statistics gathering and tracing in the previous parts to this article for combinations of these columns, you can quickly see where in this listing the information is kept and where aggregates on columns are stored. Be also warned that most of the output you will see are for Oracle's workload repository, advisories, and snapshots mechanisms and are not of any real use unless you are using those utilities. For us I have only left the objects we will be concerned with for looking at the gathered statistics we have enabled. Table 2 gives a brief explanation of these views, how you might use them, and some things to look out for.
Listing 2Query to investigate Oracle Views that contain our statistical information
where owner = 'SYS' and column_name in ('SID', 'SESSION_ID', 'CLIENT_ID', 'CLIENT_IDENTIFIER', 'SERVICE_NAME', 'ACTION', 'MODULE', 'SERIAL#'))group by table_nameorder by table_name/
The V$ACTIVE_SESSION_HISTORY view is a holding area for sampled session data performed on your behalf from the Oracle engine. This data is sampled once per second and is a great resource for determining where the true bottleneck lies in your system.
Use this view in conjunction with setting the CLIENT_IDENTIFIER, ACTION, and MODULE to aggregate (GROUP BY) and find the largest consumers of resources within your system.
DBA_HIST_ACTIVE_SESS_HISTORY
This view is just a historical representation of the V$ACTIVE_SESSION_HISTORY view above. While it is good for some historical information, be warned that it does not contain all the collected statistics that were captured in the V$ACTIVE_SESSION_HISTORY view. Please read the above mentioned article to get an understanding how this works.
V_$CLIENT_STATS If you have enabled any statistics for a CLIENT_IDENTIFIER you will see the aggregated statistics for that CLIENT_IDENTIFIER in this view
that are currently active.
statistics are only good for current activity and troubleshooting and thus should only be used for getting a glimpse of what clients are consuming the most resources.
Very valuable for a quick current view but if you need to drill to a particular client you will end up going to V$ACTIVE_SESSION_HISTORY.
V_$SERVICE_STATS
Provides a reduced set of statistics that can be used to determine how well an instance is performing for the requests made upon it.
is typically the SID_NAME but beware it may be different if you are not connecting through TNS.
V_$SERV_MOD_ACT_STATS
This view provides an aggregated view for the combination of SERVICE_NAME, MODULE, and ACTION you have defined when you enabled aggregated statistics.
Just be careful to name these aggregates appropriately so that you can quickly determine where bottlenecks reside. The use of these views is quite straight forward. You need only query them for the statistical aggregation you have set up through the DBMS_MONITOR package. The real difficulty lies in setting up those aggregations stepped through in earlier Parts of this series. Next time we will get into the new reporting options available for traces in Oracle 10g.
Oracle Session Tracing Part V James F. Koopmann posted 6/15/2007 | Comments (1) Part V in our series will get closer to what we have for years experienced as Oracle's tracing mechanism. Read On and get re-acquainted with creating trace files for TKPROF.
For many years DBAs have been getting low level tracing information about session through the creating and reading of Oracle generated trace files. These trace files can be generated against a full system load or individual sessions. The types of information generated by these traces in Table 1 clearly show why they have been used for many years. There just wasn't an easy way to get this information from within Oracle's internal views. While Oracle 10g has provided quite a few mechanisms to trace the session by querying internal views, the generation of trace files is still around and still quite viable. In addition Oracle 10g allows us to generate trace files and analyze them with added functionality. This article will focus in on how we can generate trace
Table 1 Laundry list of information gathered by tracing SQL Statements
Explain Plans Parse, execute, and fetch counts
CPU and elapsed times
Physical reads and logical reads
Number of rows processed
Misses on the library cache
Username under which each parse occurred
Each commit and rollback
Wait event data
Row operations
logical, physical and elapsed times I/O types
Creating a Trace Old Method It use to be that if you wanted to create a trace file you had to enable it at the session level through the use of the DBM_SESSION.SQL_TRACE procedure or through the ALTER SESSION SET SQL_TRACE command. While these accomplished the task we will quickly see they are very limited in scope compared with the new method. Not only are they limited in scope there usage is quite limited. In order to use these two statements you need to issue them from the connected session. That means that if you wanted to generate a trace file your application would need to be modified to issue these commands. Many programmers got around this by reading a control structure during execution to see if they should turn on trace. And if someone wanted to trace an application they would just flip a flag in the control structure. Below are two examples just in case you wish to try these methods or have a need.
SQL> exec dbms_session.set_sql_trace(true); SQL> ALTER SESSION SET SQL_TRACE = TRUE;
New Method Using DBMS_MONITOR Package to generate trace files In Part III of this series we discussed how to generate trace files with the DBMS_MONITOR package. Revisit Table 2 and take a look at the procedure calls required to generate a trace file.
Be sure to look at the description box and example given as it signifies the method you can trace against (by CLIENT_IDENTIFIER, SERVICE_NAME, MODULE, ACTION or SID). In Oracle 10g, we have been given the DBMS_MONITOR package. This package allows us to interact and control the tracing and statistics gathering of sessions through a PL/SQL interface which I think is much easier than the old method of DBMS_SESSION and ALTER SESSION commands. Also these methods in table 2 give you more flexability in what you can trace against. You are now able to do fine grain or group tracing across sessions giving you the DBA much needed control. Also remember from Part III there is the auditability of the tracing through the Oracle DBA_ENABLED_TRACES view to show you what tracing you have enabled. These new methods also give the DBA the ability to enable trace for sessions and those applications do not need to issue the command themselves.
Table 2 Program Description Notes CLIENT_ID_TRACE_ENABLE
Enable / Disable Tracing for A given Client Identifier
Trace data may be written to many trace files as the trace may effect multiple connected sessions with the same client identifier.
CLIENT_ID_TRACE_DISABLE
Enable tracing for CLIENT_IDENTIFIER johnny:127.0.0.2 with wait information but no bind information EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE('johnny:127:0.0.2',TRUE,FALSE);
SERV_MOD_ACT_TRACE_ENABLE
Enable / Disable Tracing for (Service Name/MODULE/ACTION) combination.
Trace data may be written to many trace files as the trace may effect multiple connected sessions.
SERV_MOD_ACT_TRACE_DISABLE Enable tracing for servide_name HR but only for the
ADDEMPLOYEE module and include wait and bind information.
Enable / Disable Tracing for a session identifier (SID)
Session must exist Traces only a given session Enables / Disables a trace for the instance submitter is connected to.
SESSION_TRACE_EISABLE
Enable tracing for session id 142 and include wait and bind information EXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE(145,34, TRUE, TRUE);
Where is my trace file When you enable traces Oracle dumps this information out to a system file in a destination on disk referred to as USER_DUMP_DEST. This is an actual parameter within Oracle and you will need to know what it is set to if you ever want to view the contents of the trace file you just generated. There are a couple ways you can determine this parameter that I have given below.
SQL > show parameter user_dump_dest SQL > select value from v$parameter where name = 'user_dump_dest';
When you go searching for your trace file in the USER_DUMP_DEST area you may quickly find that it is loaded with other users' trace files. To make matters worse Oracle generates a somewhat criptic name for your trace file that makes it somewhat hard for you to find them. You can modify the name of the trace file by adding a TRACEFILE_IDENTIFIER to it. You can do this by an ALTER SESSION command such as what is below. SQL > alter session set TRACEFILE_IDENTIFIER = 'something_here';
While we can get a lot of real-time session information through Oracle internal views, the Oracle trace still a valuable tool for extracting statistics for a single session or across a grouping of sessions by the added functionality given through the DBMS_MONITOR package. After generating trace files, we can now use the TKPROF or new Oracle 10g trcsess utility to extract and read the collected information in a readable form. But that is next time and will wrap up this series.
Oracle Session Tracing Part VI James F. Koopmann posted 6/21/2007 | Comments (2) Part VI in our series will show you how to access and generate reports off of the trace files we generated in Part V through the use of the TKPROF and trcsess utilities.In the last part of this series we re-visited methods on how to generate trace files. These trace files generated were in a raw format that doesn't allow for us to read them very easily. This article will be the last in this series and will show how to take these generated trace files and produce reports in a more readable form.
What does a trace file look likeIn Part IV of this series we discussed how to find where your trace files are generated but are typically stored in the $ORACLE_BASE/SID/udump directory of the database server. Listing 1 gives the top end of a trace file I generated so that you could get a flavor if you have never seen a trace file before. Through out this series we have zeroed in on setting and monitoring the SESSION_ID, CLIENT_IDENTIFIER, SERVICE_NAME, MODULE_NAME, and ACTION_NAME environment variables. At the bottom of this abbreviated trace file listing (Listing 1) you can see exactly how Oracle now stores this in each and every trace file. Note that you can change these environment variables throughout an application and these output lines
may be scattered throughout a trace file. Also, I have explicitly defined each of these client variables so as to show them here but if you were not to have set them you would end up with an empty string for those variables. If we were to set these variables religiously, you can see how easy it is to issue a Unix GREP command or Windows FIND command to give you all the trace files generated by a particular user, was in a particular module, or was performing a certain type of task.
Listing 1Top part of a trace file*** TRACE DUMP CONTINUED FROM FILE ***Dump file c:\oracle\admin\lager\udump\lager_ora_2100_jfk.trcTue Jan 25 09:48:56 2005ORACLE V10.1.0.2.0 - Production vsnsta=0vsnsql=13 vsnxtr=3Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - ProductionWith the Partitioning, OLAP and Data Mining optionsWindows 2000 Version V5.0 Service Pack 4CPU : 1 - type 586Process Affinity: 0x00000000Memory (A/P) : PH:19M/509M, PG:633M/1247M, VA:1752M/2047MInstance name: lager
What is the trcsess UtilityAfter you have determined which trace files include the particular combinations of SID, CLIENT_IDENTIFIER, SERVICE_NAME, ACTION_NAM, or MODULE_NAME variables you need to be able to pull all the information together for analysis. The trcsess utility is a java app that gets executed through the command line of your O/S and will consolidate trace information in multiple trace files for the information across these SID, CLIENT_IDENTIFIER, SERVICE_NAME, ACTION_NAME, and MODULE_NAME variables. Not to worry about invoking java, Oracle has provided a shell script for you particular operating system that can be executed instead. The output of the trcsess utility is a single file that can be the input into the TKPROF reporting utility. This is of great importance for finding true bottlenecks or an application that is consuming large amounts of resources. It would be nearly impossible to tally all the trace files for all the individual times an application or user accessed the database without this utility. Also it gives us the ability to pick out of a trace file, if we set ACTION_NAME and
MODULE_NAME properly, the statistics generated around a certain application or statement types across trace files. Also if you are in a connection polling environment where the user's session is never the same, this utility gives you the ability to zero in and pick out that user easily from all the trace files generated during the performance tuning time slice you are interested in and giving you a true look into the user's session. Listing 2 gives the syntax for the new trcsess utility and a simple example.
What Can TKPROF DoUp to this point we have just generated trace files and consolidated trace files based on a search criteria through the trcsess utility. As stated before, you can edit these trace files and read them by hand but they do tend to be cryptic. Oracle has provides us with a reporting mechanism on these trace files in the form of the TKPROF utility. This utility provides for the following mechanisms. Listing 3 also gives the syntax and example on running the TKPROF utility.
Formats all the cryptic information in a more readable form that is understandable for you and me.
Breaks out each statement executed during the trace period and present various statistics that enable us to determine where bottlenecks lay and where we might spend our time tuning application code.
Can generate a SQL script that allows us to store the captured statistics into a database.
Will determine the explain plan for executed SQL statements.
Provides for summary as well as detail information for collected statistics
Listing 3Syntax & Example for TKPROFtkprof trace_file report_file [waits = yes|no] [sort = option] [print = n] [aggregate = yes|no]
Example: Produce report for all users within the Employee Maintenance Module (EMP_MAINT).
SQL > tkprof emp_maint.trc emp_maint.rpt
Sample Output:TKPROF: Release 10.1.0.2.0 - Production on Tue Jan 25 10:34:27 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Trace file: emp_maint.trcSort options: default
***************************************************************************count = number of times OCI procedure was executedcpu = cpu time in seconds executingelapsed = elapsed time in seconds executingdisk = number of physical reads of buffers from diskquery = number of buffers gotten for consistent readcurrent = number of buffers gotten in current mode (usually for update)rows = number of rows processed by the fetch or execute call***************************************************************************UPDATE emp SET salary = 350000WHERE empid = 101
13 user SQL statements in session. 0 internal SQL statements in session. 13 SQL statements in session.********************************************************************************Trace file: emp_maint.trcTrace file compatibility: 10.01.00Sort options: default
0 session in tracefile. 13 user SQL statements in trace file. 0 internal SQL statements in trace file. 13 SQL statements in trace file.
10 unique SQL statements in trace file. 102 lines in trace file. 816 elapsed seconds in trace file.
Tracing EnhancementsThe world of tracing Oracle sessions has changed drastically with Oracle 10g. Not so much as the mechanisms but in the way we can initiate a trace for one session or a group of sessions. We are now able to "tag" sessions as they are connected to Oracle and move through applications. We can now accurately pinpoint where in the application a session is, the amount of resources being consumed, and more importantly if the session is having difficulty and is in need of tuning. This is extremely important in a multi-tier environment where connection polling takes place and we would be lost if it where not for these new tracing features.
