Pls/sql in trace file

Hi!
The problem is appearence of pl/sql code in trace file instead of separate cursors of SQL statements. So, I can't get information about each SQL statement separatelly. What's wrong? How to separate SQL statements?
Nosorog

As Satish indicated, the "SQL*Net message from client" wait is an event which indicates that the database server was waiting for the next request from the client computer, and not an indication that the query needs to be tuned. Manually review the trace file. At one point in the trace file, you will see this wait event with an ela= value which begins with 14142 - please post to this thread that line from the trace file along with the 20 lines before that line and the 20 lines after that line. You may just have a long wait on this event at the beginning, and another long wait on this event at the end of the query.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Similar Messages

  • Sql net trace file

    Hi All,
    Our prod db is 2 nodes RAC 10g in MS window 2003 servers. It is located in a remote place. Recently one of our local app servers lost connection to this db although we can tnsping it but got ORA3113 error when we tried to logon using sql plus. Most of our local PCs did not have problem logon at all. We enabled the sql net trace on this app server and network administrators spent a lot of time on this and finally shutdown one of the app servers in the same remote location which seemed cause a lot of network traffic with a local app server. So the problem went away and the app server can logon to the db now. I (I know nothing about network) tried to read the sql net trace file generated during the trouble time using the help outlined in the “Examining Oracle Net Trace Files” written by Kevin Reardon. The error happened after client sending server character set and conversion graph it supports and before receiving character set and conversion graph from the server. It took a minute in this step and finally gave up. Following is a section of the trace file where error happens. My question is: even we know when the error happens and at what step how can we use this info to further identify the root cause: Is this because we have too much network traffic which caused timeout or other reason(s)? By the way our db servers have “INBOUND_CONNECT_TIMEOUT=180" (3 minutes) in the sqlnet.ora file and whole trace file starts at [06-NOV-2009 14:50:23:352] and ends at [06-NOV-2009 14:51:24:758] which is a little over 1 minute. Greatly appreciate your insights and thoughts.
    Shirley
    [06-NOV-2009 14:50:23:836] nsdo: normal exit
    [06-NOV-2009 14:50:23:836] nsdo: entry
    [06-NOV-2009 14:50:23:836] nsdo: cid=0, opcode=85, *bl=0, *what=0, uflgs=0x0, cflgs=0x3
    [06-NOV-2009 14:50:23:836] nsdo: rank=64, nsctxrnk=0
    [06-NOV-2009 14:50:23:836] nsdo: nsctx: state=8, flg=0x400d, mvd=0
    [06-NOV-2009 14:50:23:836] nsdo: gtn=127, gtc=127, ptn=10, ptc=32730
    [06-NOV-2009 14:50:23:836] nsdo: switching to application buffer
    [06-NOV-2009 14:50:23:836] nsrdr: entry
    [06-NOV-2009 14:50:23:836] nsrdr: recving a packet
    [06-NOV-2009 14:50:23:836] nsprecv: entry
    [06-NOV-2009 14:50:23:836] nsprecv: reading from transport...
    [06-NOV-2009 14:50:23:836] nttrd: entry
    [06-NOV-2009 14:51:24:742] nttrd: exit
    [06-NOV-2009 14:51:24:742] ntt2err: entry
    [06-NOV-2009 14:51:24:742] ntt2err: Read unexpected EOF ERROR on 644
    [06-NOV-2009 14:51:24:742] ntt2err: exit
    [06-NOV-2009 14:51:24:742] nsprecv: error exit
    [06-NOV-2009 14:51:24:742] nserror: entry
    [06-NOV-2009 14:51:24:742] nserror: nsres: id=0, op=68, ns=12537, ns2=12560; nt[0]=507, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
    [06-NOV-2009 14:51:24:742] nsrdr: error exit
    [06-NOV-2009 14:51:24:742] nsdo: nsctxrnk=0
    [06-NOV-2009 14:51:24:742] nsdo: error exit
    [06-NOV-2009 14:51:24:742] nioqer: entry
    [06-NOV-2009 14:51:24:742] nioqer: incoming err = 12151
    [06-NOV-2009 14:51:24:742] nioqce: entry
    [06-NOV-2009 14:51:24:742] nioqce: exit
    [06-NOV-2009 14:51:24:742] nioqer: returning err = 3113
    [06-NOV-2009 14:51:24:742] nioqer: exit
    [06-NOV-2009 14:51:24:742] nioqrc: exit
    [06-NOV-2009 14:51:24:742] nioqrs: entry

    I am certainly not an expert in this area, but these lines are of interest
    >
    06-NOV-2009 14:51:24:742 ntt2err: Read unexpected EOF ERROR on 644
    06-NOV-2009 14:51:24:742 nserror: nsres: id=0, op=68, ns=12537, ns2=12560; nt[0]=507, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
    06-NOV-2009 14:51:24:742 nioqer: incoming err = 12151
    >
    The TNS 12537, 12560 and 12151 codes indicate network errors.
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14219/tnsus.htm#sthref14851
    Is this a consistently reproducible error ? Do other applications on this network operate without error ?
    HTH
    Srini

  • Record type variables in the SQL database trace file

    Hi,
    I turned on the trace with binds and waits in a ebusiness form and captured the database SQL trace file. It lists the values for the generic datatypes for the call, but does not list the values of record type variables. Is there a way to identify the values of record type variables? The below section lists the procedure call and the values passed. Thanks in advance.
    RPC CALL:PROCEDURE APPS.HZ_PARTY_SEARCH.FIND_PARTY_DETAILS(P_INIT_MSG_LIST IN VARCHAR2, P_RULE_ID IN NUMBER, P_PARTY_SEARCH_REC IN PARTY_SEARCH_REC_TYPE, P_PARTY_SITE_LIST IN PARTY_SITE_LIST, P_CONTACT_LIST IN CONTACT_LIST, P_CONTACT_POINT_LIST IN CONTACT_POINT_LIST
    , P_RESTRICT_SQL IN VARCHAR2, P_MATCH_TYPE IN VARCHAR2, P_SEARCH_MERGED IN VARCHAR2, X_SEARCH_CTX_ID OUT NUMBER, X_NUM_MATCHES OUT NUMBER, X_RETURN_STATUS OUT VARCHAR2, X_MSG_COUNT OUT NUMBER, X_MSG_DATA OUT VARCHAR2);
    RPC BINDS:
    bind 0: dty=1 bfp=2ae5927c13c8 flg=08 avl=01 mxl=01 val="T"
    bind 1: dty=6 bfp=2ae5927c13f0 flg=00 avl=02 mxl=22 val=8
    bind 2: dty=118 bfp=2ae593432e48 flg=00 avl=00 mxl=00 val=00
    bind 3: dty=251 bfp=2ae5929ac0b8 flg=00 avl=1944 mxl=00 val=00
    bind 4: dty=251 bfp=2ae592d85548 flg=00 avl=5336 mxl=00 val=00
    bind 5: dty=251 bfp=2ae592d84d58 flg=00 avl=4984 mxl=00 val=00
    bind 6: dty=1 bfp=2ae5927c1550 flg=08 avl=125 mxl=2000 val="exists (select 'x' from hz_parties where party_id =stage.party_id and party_type = 'ORGANIZATION') and party_id <>1002277174"
    bind 7: dty=1 bfp=2ae5927c1d50 flg=0a avl=00 mxl=00 val=""
    bind 8: dty=1 bfp=2ae5927c1d80 flg=08 avl=01 mxl=01 val="I"
    bind 9: dty=6 bfp=2ae5927c1da8 flg=02 avl=00 mxl=22 val=00
    bind 10: dty=6 bfp=2ae5927c1de0 flg=02 avl=00 mxl=22 val=00
    bind 11: dty=1 bfp=2ae5927c1e28 flg=0a avl=00 mxl=01 val=""
    bind 12: dty=6 bfp=2ae5927c1e50 flg=02 avl=00 mxl=22 val=00
    bind 13: dty=1 bfp=2ae5927c1e98 flg=0a avl=00 mxl=2000 val=""

    Hello,
    From the sounds of it, when you are adding a child the application is not maintaining the Company's reference to it. For instance, in a 1:M and M:1 relationship, the application seems to be setting only the M:1 part (child to parent) which will cause the database to be updated, but both sides need to be set to keep the cache in synch with the database.
    Setting the cache type to be none is not a good idea - it prevents any caching, which will hurt performance and object identity. What instead is recommended is disabling the shared cache using the
    toplink.cache.shared.<ENTITY>=false property. This still might not help though if the Company's reference to the child hasn't been set as mentioned above if you are reading Company from the same context you are adding the child.
    The Cache is described for TopLink Essentials in the blog at:
    http://weblogs.java.net/blog/guruwons/archive/2006/09/understanding_t.html
    Best Regards,
    Chris

  • [JDBC] trace file

    Hi
    Is it possible to configure JDBC on OC4J to create SQL query
    trace file ( for debug purpose)

    A very easy way to achieve this is to use the Open Source P6SPY utility. It acts as a wrapper over a JDBC DataSource, which intercepts and logs the JDBC calls, then delegates the call to the underlying DataSource.
    It's trivial to setup and use, and is a pretty handy utility to have in your toolkit.
    http://www.p6spy.org/
    -steve-

  • Listener trace file: Winsock 54 errors

    I am seeing many of the following error ("soc nnn error - operation=5, ntresnt[0]=517, ntresnt[1]=54...") in my Listener trace file.
    This is on an Oracle 9.2.0.4 server (Windows 2003 Server R2).
    If my intepretation of the Listener trace is correct, this corresponds to Winsock Error 10054 (Connection reset by peer).
    SQL*net trace files at the client side (a separate host) do not indicate a corresponding error - all the trace files appear "clean".
    So what is the peer in this context? My initial thought was that the Oracle server had established a session for the client, but then the client
    had appeared to disappear from the network. But I would have expected to see something in the client trace files at the same time.
    This is an example from the Listener trace file.
    nscon: sending NSPTRD packet
    nspsend: entry
    nspsend: plen=65, type=5
    nttmwr: entry
    nttmwr: socket 332 had bytes written=65
    nttmwr: exit
    nspsend: 65 bytes to transport
    nspsend: packet dump
    nspsend: 00 41 00 00 05 00 00 00 |.A......|
    nspsend: 00 37 28 41 44 44 52 45 |.7(ADDRE|
    nspsend: 53 53 3D 28 50 52 4F 54 |SS=(PROT|
    nspsend: 4F 43 4F 4C 3D 74 63 70 |OCOL=tcp|
    nspsend: 29 28 48 4F 53 54 3D 31 |)(HOST=1|
    nspsend: 39 32 2E 31 36 38 2E 32 |92.168.2|
    nspsend: 2E 32 35 34 29 28 50 4F |.254)(PO|
    nspsend: 52 54 3D 34 34 35 37 29 |RT=4457)|
    nspsend: 29 |) |
    nspsend: normal exit
    nscon: exit (0)
    nsdo: nsctxrnk=0
    nsdo: normal exit
    nsrah: entry
    nsrah: reading (asynchronously) from transport...
    nsrah: ...into overflow area...
    nttmrd: entry
    ntt2err: entry
    ntt2err: soc 332 error - operation=5, ntresnt[0]=517, ntresnt[1]=54, ntresnt[2]=0
    ntt2err: exit
    ntt2err: entry
    ntt2err: Read unexpected EOF ERROR on 332
    ntt2err: exit
    nttmrd: socket 332 had bytes read=0
    nttmrd: exit
    nserror: entry
    nserror: nsres: id=4, op=68, ns=12537, ns2=12560; nt[0]=507, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
    nsrah: exit (-1)
    nsclose: entry
    nstimarmed: entry
    nstimarmed: no timer allocated
    nstimarmed: normal exit
    Any thoughts/recommendations on this would be gratefully received, thanks.
    Andy.

    nspsend: 4F 43 4F 4C 3D 74 63 70 |OCOL=tcp|
    nspsend: 29 28 48 4F 53 54 3D 31 |)(HOST=1|
    nspsend: 39 32 2E 31 36 38 2E 32 |92.168.2|
    nspsend: 2E 32 35 34 29 28 50 4F |.254)(PO|
    nspsend: 52 54 3D 34 34 35 37 29 |RT=4457)|
    So what is the peer in this context?192.168.2.245 port=4457
    go to http://download.oracle.com/docs/cd/B10501_01/network.920/a96580/troubles.htm
    then Find: EOF ERROR

  • Create sql trace files on client machine

    Hi
    oracle creates sql trace files on server side, what are possible and best ways of sharing those files with end users? is it possible to create them on client side instead?

    Dbb wrote:
    Hi
    Hi
    oracle creates sql trace files on server side,
    Yes
    what are possible and best ways of sharing those files with end users?
    Using shared directory. Use the parameters dump to point to it
    is it possible to create them on client side instead?
    No
    . :-) any help with my english is wellcome :-) .does this mean sharing user_dump destination at linux level and then mounting it from client machines ( win xp )?is there any doc on this?

  • Moving Default Trace File in SQL Server

    How can I move the default trace file in SQL server?
    SQL Server 2012?
    Thanks in advance
    ebro

    Please have a look at these links:
    Change path for default SQL Server trace
    Steps to change the default location of SQL Server /SQL Server Agent - Error log files
    DETERMINING DEFAULT TRACE LOCATION
    Collecting the Information in the Default Trace
    T-SQL Articles
    T-SQL e-book by TechNet Wiki Community
    T-SQL blog

  • Trace file in bdump (SQL ID with large Version Count encountered.)

    Hi, all.
    I found tons of this trace file in one of my oracle servers. What does this mean? did anyone ever see this? How to solve it?
    Thanks.
    *** ACTION NAME:(Auto-Flush Slave Action) 2009-01-28 18:00:10.985
    *** MODULE NAME:(MMON_SLAVE) 2009-01-28 18:00:10.985
    *** SERVICE NAME:(SYS$BACKGROUND) 2009-01-28 18:00:10.985
    *** SESSION ID:(84.5246) 2009-01-28 18:00:10.985
    SQL ID with large Version Count encountered.
    SQL Id: b221muwskhm6
    Version Count: 299, Parse Calls: 12, Shareable Mem: 11907351
    Elapsed Time: 0, CPU Time: 0, Executions: 0
    Disk reads: 0, Buffer Gets: 0, I/O Wait Class: 0
    Application WC: 0, Concurrency WC: 0, Cluster WC: 0

    Refer Oracle Support note 4632024.8

  • Unable to generate SQL trace file on a 10.2.0.1.0 database

    Hello,
    I am unable to generate SQL trace files on a 10.2.0.1.0 database (OS is Win2003 server 64 bits).
    First I tried the way I used to do it on older databases (8i and 9i) :
    execute dbms_system.set_sql_trace_in_session(sid, serial#, true);
    I got no error, but no file was created in the user dump dest directory.
    Then I've been searching and I've tried other things :
    - I changed the user_dump_dest parameter
    - I changed the tracefiles_public parameter value to "true", by modifying the init.ora file
    - I tried another package :
    exec dbms_monitor.session_trace_enable(139)
    Nothing worked, I can't create any trace file...
    Does anyone have an idea about this issue ?
    thank you for you help !
    Antoine

    Hello,
    thank you all for replying.
    I have 2 instances on this machine, and I've just realized that with the other one I have no problem to generate sql trace files as usual.
    But why the hell is it impossible on the first instance ? What difference between the 2 instances can explain this ?
    This is pretty weird...
    Otherwise I am experiencing serious performance problems on the instance where I can't creat trace files, there must be something wrong with it, but I can't figure it out
    regards,
    Antoine

  • SQL Query taking longer time as seen from Trace file

    Below Query Execution timings:
    Any help will be benefitial as its affecting business needs.
    SELECT MATERIAL_DETAIL_ID
    FROM
    GME_MATERIAL_DETAILS WHERE BATCH_ID = :B1 FOR UPDATE OF ACTUAL_QTY NOWAIT
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.70 0 0 0 0
    Execute 2256 8100.00 24033.51 627 12298 31739 0
    Fetch 2256 900.00 949.82 0 12187 0 30547
    total 4513 9000.00 24984.03 627 24485 31739 30547
    Thanks and Regards

    Thanks Buddy.
    Data Collected from Trace file:
    SELECT STEP_CLOSE_DATE
    FROM
    GME_BATCH_STEPS WHERE BATCH_ID
    IN (SELECT
    DISTINCT BATCH_ID FROM
    GME_MATERIAL_DETAILS START WITH BATCH_ID = :B2 CONNECT BY PRIOR PHANTOM_ID=BATCH_ID)
    AND NVL(STEP_CLOSE_DATE, :B1) > :B1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.54 0 0 0 0
    Execute 2256 800.00 1120.32 0 0 0 0
    Fetch 2256 9100.00 13551.45 396 77718 0 0
    total 4513 9900.00 14672.31 396 77718 0 0
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 66 (recursive depth: 1)
    Rows Row Source Operation
    0 TABLE ACCESS BY INDEX ROWID GME_BATCH_STEPS
    13160 NESTED LOOPS
    6518 VIEW
    6518 SORT UNIQUE
    53736 CONNECT BY WITH FILTERING
    30547 NESTED LOOPS
    30547 INDEX RANGE SCAN GME_MATERIAL_DETAILS_U1 (object id 146151)
    30547 TABLE ACCESS BY USER ROWID GME_MATERIAL_DETAILS
    23189 NESTED LOOPS
    53736 BUFFER SORT
    53736 CONNECT BY PUMP
    23189 TABLE ACCESS BY INDEX ROWID GME_MATERIAL_DETAILS
    23189 INDEX RANGE SCAN GME_MATERIAL_DETAILS_U1 (object id 146151)
    4386 INDEX RANGE SCAN GME_BATCH_STEPS_U1 (object id 146144)
    In the Package there are lots of SQL Statements using CONNECT BY CLAUSE.
    Does the use of CONNECT BY Clause degrades performance?
    As you can see the Rows Section is 0 but the Query and elapsed time is taking longer
    Regards

  • Explain plan not displayed in sql trace file

    Hello,
    I don't understand why in sql trace file, after tkprof transformation, for several queries the explain plan is displayed and for several queries, no explain plan is displayed.
    How can I have the explain plan for all queries?
    Thanks for your help.

    Was this a trace started on an already running task? Was the trace stopped before the task completed? Did the trace file reach its set size limit before the task compled?
    In all three cases above you would have cursors that were not closed and stats information not written to the trace file resulting in incomplete data for some SQL.
    HTH -- Mark D Powell --

  • SQL Developer generates strange trace files on server

    Hello out there,
    I observed the generation of some strange trace files on the database server (Oracle 11.0.2.0.2 64bit on Win 2008R2).
    Whenever I start SQL Developer (3.2.20.09.87 64bit with JDK 1.7.0_17 64bit on Win7 64bit) for each connection I defined one trace file like this is generated:
    Trace file C:\ORACLE\diag\rdbms\ora\ora\trace\ora_ora_8500.trc
    Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
    Windows NT Version V6.1 Service Pack 1
    CPU                 : 2 - type 8664, 2 Physical Cores
    Process Affinity    : 0x0x0000000000000000
    Memory (Avail/Total): Ph:990M/3959M, Ph+PgF:3743M/7918M
    Instance name: ora
    Redo thread mounted by this instance: 1
    Oracle process number: 23
    Windows thread id: 8500, image: ORACLE.EXE (SHAD)
    *** 2013-03-06 08:04:13.842
    *** CLIENT ID:() 2013-03-06 08:04:13.842
    *** SERVICE NAME:() 2013-03-06 08:04:13.842
    *** MODULE NAME:() 2013-03-06 08:04:13.842
    *** ACTION NAME:() 2013-03-06 08:04:13.842
    Breaking the connection before proto/dty negotiation, error raised 3113I enabled listener log to find out the origin of this and it contains lines like the following:
    06-MRZ-2013 08:04:13 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49320)) * establish * ora.vu * 0
    06-MRZ-2013 08:04:13 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49322)) * establish * ora.vu * 0
    06-MRZ-2013 08:04:13 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49323)) * establish * ora.vu * 0
    06-MRZ-2013 08:04:13 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49325)) * establish * ora.vu * 0
    06-MRZ-2013 08:04:14 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49329)) * establish * ora.vu * 0
    06-MRZ-2013 08:04:14 * (CONNECT_DATA=(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))(SERVICE_NAME=ora.vu)(CID=(PROGRAM=null)(HOST=__jdbc__)(USER=null))) * (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.36.143)(PORT=49331)) * establish * ora.vu * 0The IP address is mine and I have excatly 6 connections defined for that server. On other servers, similar trace files are generated, one for each connection in my SQL Developer.
    This also occurred with JDK 1.6 so I don't think it's a Java issue.
    Besides the generation of the trace files there seem to be no other problems.
    Any ideas?

    Hi,
    I think Srini is probably correct. The noted bug applies to 11.2.0.1 and up, is fixed in 12c, and included in an 11.2.0.3 patch. However the version of SQL Developer also affects the creation of trace files on product startup (prior to any user initiated db connect attempts).
    For example,
    A. SQL Developer 3.1.07.42 - no such trace files created.
    B. SQL Developer 3.2.20.09.87 - such trace files created for 11.2.0.1 connections, but not 10g XE or 12c connections.
    So I presume an OCIServerAttach call got added in 3.2.2, not sure in support of which feature, but the bug will only impact users of 11.2.0.1, 11.2.0.2, and unpatched 11.2.0.3 DB releases.
    Regards,
    Gary
    SQL Developer Team

  • I am not able to see the trace files for SQL query

    Hello, I am using windows vista OS.
    SQL> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Prod
    PL/SQL Release 10.2.0.3.0 - Production
    CORE 10.2.0.3.0 Production
    TNS for 32-bit Windows: Version 10.2.0.3.0 - Production
    NLSRTL Version 10.2.0.3.0 - Production
    SQL>
    I enabled the trace as below
    alter system set timed_statistics=TRUE
    alter system set sql_trace=TRUE
    After this, I ran sql query from scott as below.
    select count(*) from emp;
    After this, i checked in user dump directory. The trace files are generating... But this sql code is not appearing in the trace files...
    Am i missing anything... Any help is appreciated.
    Thanks

    This may happen when the trace file is not completely closed.You may try again doing like this,
    alter session set sql_trace=true;
    select * from emp;
    alter session set sql_trace=false;After this,disconnect and exit from your session as well. This should close the file completely and you should be able to see your command in it.
    HTH
    Aman....

  • High SQL*Net message values in trace file.

    Hi all,
    This is my first post here. I will try to more less describe the problem i am facing.
    Any help is more than welcome!
    I am facing some performance issues with application. Slow GUI. I run some tests, i tracked the session. what i found in trace file is:
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse     1734     1.61   1.61             0            0            0              0
    Execute   1734   32.52  32.56           0           26          15             4
    Fetch     1737     14.46  14.51           2        41867        84          2847
    total     5205     48.59   48.69            2        41893        99          2851
    Misses in library cache during parse: 7
    Misses in library cache during execute: 5
    Elapsed times include waiting on following events:
      Event waited on                             Times       Max. Wait     Total Waited
      ----------------------------------------           Waited       ----------            ------------
      SQL*Net message to client            5207           0.00               0.02
      SQL*Net message from client        5206          106.18             339.72
      log file sync                                    3               0.00               0.00
      SQL*Net more data to client            51              0.00               0.00
      SQL*Net more data from client        10              0.00               0.00
      Disk file operations I/O                    1               0.00               0.00
      db file sequential read                     2               0.00               0.01
      library cache: mutex X                    1               0.05               0.05
    Look at Max. Wait and Total Waited columns. Is it possible to safely tune it by changing SDU in sql*net ? and if so, is it needed to change the SDU value on client and server sides ?

    66ff73bb-87bd-4c84-bada-0141fb25344b wrote:
    Hi all,
    This is my first post here. I will try to more less describe the problem i am facing.
    Any help is more than welcome!
    I am facing some performance issues with application. Slow GUI. I run some tests, i tracked the session. what i found in trace file is:
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse     1734     1.61   1.61             0            0            0              0
    Execute   1734   32.52  32.56           0           26          15             4
    Fetch     1737     14.46  14.51           2        41867        84          2847
    total     5205     48.59   48.69            2        41893        99          2851
    Misses in library cache during parse: 7
    Misses in library cache during execute: 5
    Elapsed times include waiting on following events:
      Event waited on                             Times       Max. Wait     Total Waited
      ----------------------------------------           Waited       ----------            ------------
      SQL*Net message to client            5207           0.00               0.02
      SQL*Net message from client        5206          106.18             339.72
      log file sync                                    3               0.00               0.00
      SQL*Net more data to client            51              0.00               0.00
      SQL*Net more data from client        10              0.00               0.00
      Disk file operations I/O                    1               0.00               0.00
      db file sequential read                     2               0.00               0.01
      library cache: mutex X                    1               0.05               0.05
    Look at Max. Wait and Total Waited columns. Is it possible to safely tune it by changing SDU in sql*net ? and if so, is it needed to change the SDU value on client and server sides ?
    When you start with the wrong question, no matter how good an answer you get, it won't matter very much.
    you do NOT have any problem; just a useless observation.

  • Tkprof : 0  user  SQL statement in trace file

    Hello!
    Please explain , what is difference of tkprof-converting of user session trace file and an internal/background process ?
    Get I message "0 user SQL statement in trace file" cause this difference?
    In my target session I issued :
    begin
    sys.dbms_system.set_ev(...., .., 10046, 12, '');
    end;
    begin
    sys.dbms_system.set_ev(..., .., 10053, 1, '');
    end;
    /Thanks and regards,
    Pavel

    Did you try to tkprof a 10053 trace ?
    That is not going to show anything. 10053 traces are meant to be read as they are. tkprof is there to deal with 10046 traces.

Maybe you are looking for