Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: trap sql without using tkprof

Re: trap sql without using tkprof

From: Thomas Kyte <tkyte_at_us.oracle.com>
Date: Fri, 12 Nov 1999 07:47:59 -0500
Message-ID: <vgssOJNWBZb86=c0dmiFjwRtDs4Y@4ax.com>


A copy of this was sent to screwbai_at_my-deja.com (if that email address didn't require changing) On Thu, 11 Nov 1999 22:32:46 GMT, you wrote:

>Is there any other tool than tkprof that can be used to trap sql's.
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.

well, tkprof doesn't trap sql -- it formats a trace file that was generated by setting an event or sql_trace=true (and sql_trace=true just sets an event).

On the client side, if you are using sqlnet, you can set

trace_level_client=16

in the sqlnet.ora file (typically in $oracle_home/network/admin). then a trace file will be generated with packet dumps and you'll see stuff like:

nspsend: 103 bytes to transport
nspsend: packet dump
nspsend:00 67 00 00 06 00 00 00  |.g......|
nspsend:00 00 03 5E 3A 02 80 61  |...^:..a|
nspsend:00 74 3C CD 01 01 18 78  |.t<....x|
nspsend:04 CD 01 01 0A 00 00 00  |........|
nspsend:00 9C 04 CD 01 00 01 01  |........|
nspsend:00 00 00 00 00 00 00 00  |........|
nspsend:00 00 00 00 00 00 00 00  |........|
nspsend:00 00 00 00 00 00 9E 04  |........|
nspsend:CD 01 73 65 6C 65 63 74  |..select|
nspsend:20 2A 20 66 72 6F 6D 20  | * from |
nspsend:73 63 6F 74 74 2E 65 6D  |scott.em|
nspsend:70 0A 01 01 00 00 00 00  |p.......|
nspsend:00 00 01 01 00 01 04 00  |........|
nspsend: normal exit


It is not *nearly* as nice or readable as a tkprof formatted report but it is another way.

--
See http://osi.oracle.com/~tkyte/ for my columns 'Digging-in to Oracle8i'... Current article is "Part I of V, Autonomous Transactions" updated June 21'st  

Thomas Kyte                   tkyte_at_us.oracle.com
Oracle Service Industries     Reston, VA   USA

Opinions are mine and do not necessarily reflect those of Oracle Corporation Received on Fri Nov 12 1999 - 06:47:59 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US