Usertracing

376 views

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
376
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Usertracing

  1. 1. Tracing Users SQL Statements Administration TipsTracing Users SQL StatementsWhen tuning a database, its 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 PLANIf 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 thats done (and, since its a genuine table, it only needs to be doneonce), you issue this sort of command:EXPLAIN PLAN FORSELECT * FROM SCOTT.EMP;This doesnt 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 doesnt get cluttered with a myriad ofexecution plans.SQL TRACE and TKPROFInstead 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 its your own session, you simply issue thecommand:Copyright © Howard Rogers 2001 10/18/2001 Page 1 of 4
  2. 2. Tracing Users SQL Statements Administration TipsALTER SESSION SET SQL_TRACE=TRUEBut 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 youll 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.SPIDFROM V$PROCESS P,V$SESSION SWHERE P.ADDR=S.PADDRAND S.SID=&SID AND S.SERIAL#=&SERIALNO;When run, youll 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, youll 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 doesnt getclosed properly, and if it has any contents at all, they probably wont 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.Copyright © Howard Rogers 2001 10/18/2001 Page 2 of 4
  3. 3. Tracing Users SQL Statements Administration TipsNow you have a tracefile, properly identifiable, its 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, youd type the following command:TKPROF TRACEFILE.TRC OUTPUT.TXT SYS=NOAUTOTRACEAn alternative way of obtaining trace information is to use the SQL Plus feature calledautotrace. 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 dont have the DBA role, and theyll be able to generatetraces successfully. Without this step, only DBAs can enable autotrace.The final step is to issue the command:SET AUTOTRACE ONNote that this is an internal SQL Plus command, not a SQL statement -so theres noconcluding semi-colon, and the command wont 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 theres no need to run tkprof to format the output before it makes sense. There aresevere drawbacks, too, though: you cant set autotrace on on behalf of another User -ithas to be enabled by a session, and then only that sessions SQL statements are traced.Whats more, unlike the Explain Plan, the SQL statements being issued within the sessionCopyright © Howard Rogers 2001 10/18/2001 Page 3 of 4
  4. 4. Tracing Users SQL Statements Administration Tipsare actually executed. When you use the "explain plan for..." method, the ensuing SQLstatement is not actually executed, but merely parsed. The final killer drawback is thatautotrace is SQL Plus specific -it cant work in 3rd party applications, nor in Server Manager.Note that autotrace can be set to various other states than simply ON and OFF. Forexample, there are these variants:SET AUTOTRACE TRACEONLYSET AUTOTRACE ON EXPLAINSET AUTOTRACE TRACEONLY STATISTICSThe first of these variants suppresses the display of the actual results of the SQLstatements being issued. The execution of the SQL still takes place, but no results areactually returned to the session. All you see are the trace statistics for the parse andexecute phases.The second option displays the result set of the SQL statement being traced, along withthe execution plan, but no parse or execute statistics are displayed.And the third option suppresses the result set of the SQL statement being traced, alongwith the parse and execute statistics, but the execution plan is not shownWhen youve finished tracing a session, just issue the command:SET AUTOTRACE OFF...and SQL Plus will revert to its normal behaviour.Copyright © Howard Rogers 2001 10/18/2001 Page 4 of 4

×