Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
Oracle - User Tracing

Oracle - User Tracing

Ratings: (0)|Views: 12|Likes:
Published by oracle412
oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java
oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java

More info:

Published by: oracle412 on Jun 17, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

07/17/2014

pdf

text

original

 
Tracing Users' SQL Statements Administration TipsCopyright © Howard Rogers 2001 10/18/2001 Page
1 of 4
 
Tracing Users' SQL Statements
When tuning a database, it's important to know what SQL is being issued by Users, and howit is being parsed and executed. There are a number of approaches to obtaining suchinformation.
EXPLAIN PLAN 
If you know the SQL being submitted, you can simply generate an explain plan for it, andhave that plan sotred within a table created specially for the purpose.To create the explain plan table, you execute the utlxplan.sql script provided by Oracle inthe ORACLE_HOME/rdbms/admin directory. It creates a table called, cunningly enough,PLAN_TABLE. Once that's done (and, since it's a genuine table, it only needs to be doneonce), you issue this sort of command:
EXPLAIN PLAN FOR 
 
SELECT
*
FROM SCOTT
.
EMP
;
This doesn't actually execute the query (so there are no performance or I/O complicationsto worry about), but the plan that
would
be produced were it to be submitted by a Userfor real is written into PLAN_TABLE. You can thus simply query the table, and see whatsort of execution plan is being produced for each statement. You probably want totruncate the table after each analysis, so it doesn't get cluttered with a myriad ofexecution plans.
SQL TRACE and TKPROF 
Instead of writing the plan into a static table, Oracle is able to generate a user-processtrace file containing the crucial information. Unfortunately, the tracefile output is onlyreadable by humans if they have advanced degrees in hieroglyphics and the subtleties ofSumerian palace intrigues. Therefore, we have to pipe the raw stuff through the TKPROFutility to turn it into something mere mortals can make sense of.To enable this functionality, you need first to make sure that the init.ora parametertimed_statistics is set to TRUE, and that user_dump_dest is set to something sensible (adirectory where trace files can be found easily). You might also want to check thatmax_dump_file_size is set to, say, 1M so as to prevent absolutely mammoth trace filesbeing generated by mistake.Then you need simply switch tracing on. If it's your own session, you simply issue thecommand:
 
Tracing Users' SQL Statements Administration TipsCopyright © Howard Rogers 2001 10/18/2001 Page
2 of 4
 
 ALTER SESSION SET SQL
 _
TRACE
=TRUE
But if you are doing this on behalf of another User, you need first to determine the SID andSERIAL# that uniquely identify their session:
SELECT USERNAME
,
SID
,
SERIAL
#
FROM V 
$
SESSION
;
...followed by:
EXECUTE DBMS
 _
SESSION
.
SET
 _
SQL
 _
TRACE
 _
IN
 _
SESSION
(7,32,TRUE)
Those two numbers in the brackets are the SID and SERIAL# just determined by queryingv$session. Note that you'll probably need to be connected as SYS for this to work.Any new SQL statements issued by the specified session will now be traced, and the outputwill be going to some trace file in the directory pointed at by the user_dump_destparameter. You may find it tricky to work out which tracefile belongs to which session,because if you do tracing even vaguely regularly, there will probably be dozens of likelycandidates to choose from.The simplest way to sort that out is to use the time and date stamp on the files themselves,but if you need a more accurate way to determine the filename in which to get interested,try this query:
SELECT P
.SPID
FROM V 
$
PROCESS P
,
 V 
$
SESSION S
 
 WHERE P
.ADDR=
S
.PADDR 
 AND S
.
SID
=&
SID AND S
.
SERIAL
#=&
SERIALNO
;
When run, you'll be prompted to supply the SID and SERIAL# values previously used whenswitching tracing on in the first place ...and that gives you the process number that will beincluded in the trace file name (on NT, you'll have a file calledORA0<process_number>.TRC, and on Unix it will generally be calledsid_ora_<process_no>.trc).
Do not attempt to work with the tracefile, though, until you have remembered toswitch SQL tracing OFF for the relevant session -otherwise the tracefile doesn't getclosed properly, and if it has any contents at all, they probably won't be useable.
To switch tracing off for a session, simply enter the command:
EXECUTE DBMS
 _
SESSION
.
SET
 _
SQL
 _
TRACE
 _
IN
 _
SESSION
(7,32,FALSE)
Again, the two numbers specified there are the SID and SERIAL# numbers, determined fromv$session, that uniquely identify any Oracle session.
 
Tracing Users' SQL Statements Administration TipsCopyright © Howard Rogers 2001 10/18/2001 Page
3 of 4
 
Now you have a tracefile, properly identifiable, it's time to format it using the tkprofutility. Just type the following command at the operating system prompt:
TKPROF
TRACEFILE 
.TRC 
OUTPUTFILE 
.
TXT 
 
...and that will produce a text file (of whatever name you specify) which contains the fullparse and execute statistics for the previously-selected session for the time during whichtracing was switched on. Obviously, when you do this for real, substitute in the correctname for the trace file being formatted, and choose an appropriate output file name.The tkprof utility takes a number of options, but probably the most useful one would be toswitch off recursive SQL. This means that all the internal queries that go on under thehood when a User issues a SQL command are stripped out of the output file, leaving behindonly the commands that the User would identify as having been issued by himself. To dothat, you'd type the following command:
TKPROF TRACEFILE
.
TRC OUTPUT
.
TXT SYS
=
 NO
 
AUTOTRAC
An alternative way of obtaining trace information is to use the SQL Plus feature called'autotrace'. For this to work, you still need an explain plan table (see above for how tocreate one, but the script involved is called utlxplan.sql). Additionally, you need toexecute the plustrace.sql script (supplied by Oracle, and available in theORACLE_HOME/sqlplus/admin directory), in order to create a PLUSTRACE role. You canthen grant that role to Users who don't have the DBA role, and they'll be able to generatetraces successfully. Without this step, only DBAs can enable autotrace.The final step is to issue the command:
SET AUTOTRACE ON
 
Note that this is an internal SQL Plus command, not a SQL statement -so there's noconcluding semi-colon, and the command won't work in something like Server Manager.After that, every SQL statement issued in the session will not only cause the statement tobe executed, but will display trace statistics for that statement, too.The advantages of this over setting sql traceing on are obvious: the feedback is immediate,and there's no need to run tkprof to format the output before it makes sense. There aresevere drawbacks, too, though: you can't set autotrace on on behalf of another User -ithas to be enabled by a session, and then only that session's SQL statements are traced.What's more, unlike the Explain Plan, the SQL statements being issued within the session

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->