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.

Similar Messages

  • SQL*Net message from client - huge wait in trace file

    Dear All,
    I am facing a performance issue in a particular operation ( which was completed in 21 Minutes earlier). Now the same operation takes more than 35 Minutes. I took a trace for those session ( 10046 level 12 trace ) and found Lot of waits in SQL*Net message from client.
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQLNet message from client 611927 10.00 1121.35*
    I copied only the highest wait in the tkprof output.
    And I found from the tkprof and even in raw trace file this event waits more time after excuting
    SELECT sysdate AS SERVERDATE from dual;
    Elapsed times include waiting on following events:
    Event waited on Times Max. Wait Total Waited
    ---------------------------------------- Waited ---------- ------------
    SQL*Net message to client 115 0.00 0.00
    SQLNet message from client 115 10.00 724.52*
    Please help me to find out why this wait taking long time, especially on the above query..
    Regards,
    Vinodh

    Vinodh Kumar wrote:
    Hi,
    This is what available in the trace file
    PARSING IN CURSOR #2 len=38 dep=0 uid=60 oct=3 lid=60 tim=7052598842 hv=3788189359 ad='7d844fa0'
    *"SELECT sysdate AS SERVERDATE FROM dual"*
    END OF STMT
    PARSE #2:c=0,e=12,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=7052598839
    BINDS #2:
    EXEC #2:c=0,e=42,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=7052599002
    WAIT #2: nam='SQL*Net message to client' ela= 1 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=7052599058
    FETCH #2:c=0,e=15,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=7052599110
    *** 2012-01-02 17:07:30.364
    WAIT #2: nam='SQL*Net message from client' *" ela= 10007957"* driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=7062607120Please find the last line WAIT -- in the complete trace after executing this query
    In awr report , this query taken less than a sec for more than 2000 executions.
    Regards,
    VinodhGood idea to check the raw trace file. It is important to notice that this particular wait event appears after the fetch of the result from the database. The client receives the SYSDATE from the database server, and then the client performs some sort of action for about 10 seconds before submitting its next request to the database. The SQL statement that immediately follows and immediately preceeds this section of the trace file might provide clues regarding what caused the delay, and where that delay resides in the client side code. Maybe a creative developer added a "sleep for 10 seconds" routine when intending to sleep for 10ms? Maybe the client CPU is close to 100% utilization?
    Charles Hooper
    http://hoopercharles.wordpress.com/
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Process wait SQL*Net message from dblink /SQL*Net message from client

    Hi There,
    We have an ETL process that we kindly need your help with. The process been running since Sun, where it transfers the data from one server (via remote query). The process was running ok till last night where it appeared
    to have stopped working and/or the session is just idling doing nothing.
    Here are some tests that we did to figure out what's going on:
    1. when looking at the session IO, we noticed that it's not changing:
    etl_user@datap> select sess_io.sid,
      2         sess_io.block_gets,
      3         sess_io.consistent_gets,
      4         sess_io.physical_reads,
      5         sess_io.block_changes,
      6         sess_io.consistent_changes
      7    from v$sess_io sess_io, v$session sesion
      8   where sesion.sid = sess_io.sid
      9     and sesion.username is not null
    10     and sess_io.sid=301
    11  order by 1;
                        logical   physical
      SID BLOCK_GETS      reads      reads BLOCK_CHANGES CONSISTENT_CHANGES
      301  388131317   97721268   26687579     223052804             161334
    Elapsed: 00:00:00.012. Check there is nothing blocking the session
    etl_user@datap> select * from v$lock where sid=301;
    ADDR     KADDR           SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
    684703F0 6847041C        301 DX         35          0          1          0      45237          0
    684714C4 684714F0        301 AE     199675          0          4          0     260148          0
    619651EC 6196521C        301 TM      52733          0          3          0      45241          0
    67F86ACC 67F86B0C        301 TX     458763      52730          6          0      45241          03. Check if the session is still valid:
    etl_user@datap> select status from v$session where sid=301;
    STATUS
    ACTIVE4. Check if there is anything in long ops that has not completed:
    etl_user@datap> SELECT SID, SERIAL#, opname, SOFAR, TOTALWORK,
      2      ROUND(SOFAR/TOTALWORK*100,2) COMPLETE, TIME_REMAINING/60
      3      FROM   V$SESSION_LONGOPS
      4      WHERE
      5      TOTALWORK != 0
      6      AND    SOFAR != TOTALWORK
      7     order by 1;
    no rows selected
    Elapsed: 00:00:00.005. Check if there is anything in long ops for the session:
    etl_user@datap> r
      1* select SID,SOFAR,TOTALWORK,START_TIME,LAST_UPDATE_TIME,TIME_REMAINING,MESSAGE from V$SESSION_LONGOPS where sid=301
      SID      SOFAR  TOTALWORK START_TIM LAST_UPDA TIME_REMAINING MESSAGE
      301          0          0 22-JUL-12 22-JUL-12                Gather Table's Index Statistics: Table address_etl : 0 out of 0 Indexes done
    Elapsed: 00:00:00.00This is a bit odd!! This particular step have actually completed successfully on the 22nd of July, and we don't know why it's still showing in long opps!? any ideas?
    6. Looking at the sql and what's it actually doing:
    etl_user@datap> select a.sid, a.value session_cpu, c.physical_reads,
      2  c.consistent_gets,d.event,
      3  d.seconds_in_wait
      4  from v$sesstat a,v$statname b, v$sess_io c, v$session_wait d
      5  where a.sid= &p_sid_number
      6  and b.name = 'CPU used by this session'
      7  and a.statistic# = b.statistic#
      8  and a.sid=c.sid
      9  and a.sid=d.sid;
    Enter value for p_sid_number: 301
    old   5: where a.sid= &p_sid_number
    new   5: where a.sid= 301
                 CPU   physical    logical                                   seconds
      SID       used      reads      reads EVENT                             waiting
      301    1966595   26687579   97721268 SQL*Net message from dblink         45792
    Elapsed: 00:00:00.037. We looked at the remote DB where the data resides on, and we noticed that the remote session was also waiting on the db link:
    SYS@destp> select a.sid, a.value session_cpu, c.physical_reads,
      2  c.consistent_gets,d.event,
      3  d.seconds_in_wait
      4  from v$sesstat a,v$statname b, v$sess_io c, v$session_wait d
      5  where a.sid= &p_sid_number
      6  and b.name = 'CPU used by this session'
      7  and a.statistic# = b.statistic#
      8  and a.sid=c.sid
      9  and a.sid=d.sid;
    Enter value for p_sid_number: 388
    old   5: where a.sid= &p_sid_number
    new   5: where a.sid= 390
           SID SESSION_CPU PHYSICAL_READS CONSISTENT_GETS EVENT                                                    SECONDS_IN_WAIT
           390         136              0            7605 SQL*Net message from client                                        46101
    SYS@destp>We have had an issue in the past where the connection was being dropped by the network when the process runs for few days, hence we have added the following to the sqlnet.ora and listener.ora files:
    sqlnet.ora:
    SQLNET.EXPIRE_TIME = 1
    SQLNET.INBOUND_CONNECT_TIMEOUT = 6000
    listener.ora:
    INBOUND_CONNECT_TIMEOUT_LISTENER = 6000What else can we do and/or further investigate to work out the root cause of the problem, and may be help resolve this. We don't want to just stop and start the process again as it took few days already. We have
    had a chat to the infrastructure team and they've assured us that there have been no network outages.
    Also, the alert logs for both instances (local and remote) shows no errors what so ever!
    Your input is highly appreciated.
    Thanks
    Edited by: rsar001 on Jul 25, 2012 10:22 AM

    Ran the query on both local/remote db, and no rows returned:
    etl_user@datap> SELECT DECODE(request,0,'Holder: ','Waiter: ')||vl.sid sess, status,
      2  id1, id2, lmode, request, vl.type
      3  FROM V$LOCK vl, v$session vs
      4  WHERE (id1, id2, vl.type) IN
      5  (SELECT id1, id2, type FROM V$LOCK WHERE request>0)
      6  and vl.sid = vs.sid
      7  ORDER BY id1, request
      8  /
    no rows selected
    Elapsed: 00:00:00.21

  • Query started taking longer time with SQL*Net message from dblink

    Hi,
    Since Yesterday we started see one query which normally used to take 3 min but now it started taking 70 min after a small change do the query instead of accessing view we started accessing directly table.
    Both Schema's are on same DB.
    Oracle version=11.2.0.2
    OS=Solaris 10
    Existing Query
    WITH ot_symbol_data_v AS
         (SELECT   dat.symbol, dat.startdate, dat.enddate, oi.currencycode,
                   dat.primarymarket, primsymb.symbol primarysymbol, dat.mic,
                   dat.universeid, dat.symbology
              FROM onetick_symbol_data@refdata_link dat
                   LEFT JOIN
                   (SELECT   symbology, universeid, mic, MAX (enddate) enddate
                        FROM onetick_symbol_data@refdata_link
                    GROUP BY symbology, universeid, mic) prim
                   ON prim.symbology = dat.symbology
                 AND prim.universeid = dat.universeid
                 AND prim.mic = dat.primarymarket
                   LEFT JOIN onetick_symbol_data@refdata_link primsymb
                   ON prim.symbology = primsymb.symbology
                 AND prim.universeid = primsymb.universeid
                 AND prim.mic = primsymb.mic
                 AND prim.enddate = primsymb.enddate
                   JOIN onetick_isincur_data@refdata_link oi
                   ON dat.universeid = oi.universeid
                   JOIN
                   (SELECT   universeid, MAX (enddate) AS enddate
                        FROM onetick_isincur_data@refdata_link
                    GROUP BY universeid) oilatest
                   ON oi.universeid = oilatest.universeid
                 AND oi.enddate = oilatest.enddate
          ORDER BY dat.universeid, dat.mic, dat.symbology, dat.enddate)
    SELECT      i.instrumentid
             || '||'
             || i.firsttradingdate
             || '000000|'
             || NVL (i.delisteddate, '30001231')
             || '000000|'
             || i.home_market
             || '|'
             || DECODE (imfm.feedid, 0, 'FIXN_RFA', 1, 'ALGO', 2, 'FIXNETIX')
             || '::'
             || osdv.primarysymbol
        FROM tibex_meinstrumentview i JOIN tibex_instrumentmicfeedmapview imfm
             ON i.isin = imfm.isin
           AND i.currencycode = imfm.currencycode
           AND i.home_market = imfm.mic
             JOIN rd_universeview@refdata_link u
             ON i.instrumentid = u.instrumentid AND i.instrumentstatus != 3
             and active='Y'
             JOIN
             (SELECT   universeid, DECODE (symbology, 1, 0, 2, 2, -1) feedid,
                       primarysymbol
                  FROM ot_symbol_data_v
              GROUP BY universeid, symbology, primarysymbol) osdv
             ON u.universeid = osdv.universeid
       WHERE osdv.feedid = imfm.feedid
    ORDER BY i.isin, i.currencycode, i.instrumentid;
    New Query
    WITH ot_symbol_data_v AS
         (SELECT   dat.symbol, dat.startdate, dat.enddate, oi.currencycode,
                   dat.primarymarket, primsymb.symbol primarysymbol, dat.mic,
                   dat.universeid, dat.symbology
              FROM onetick_symbol_data@refdata_link dat
                   LEFT JOIN
                   (SELECT   symbology, universeid, mic, MAX (enddate) enddate
                        FROM onetick_symbol_data@refdata_link
                    GROUP BY symbology, universeid, mic) prim
                   ON prim.symbology = dat.symbology
                 AND prim.universeid = dat.universeid
                 AND prim.mic = dat.primarymarket
                   LEFT JOIN onetick_symbol_data@refdata_link primsymb
                   ON prim.symbology = primsymb.symbology
                 AND prim.universeid = primsymb.universeid
                 AND prim.mic = primsymb.mic
                 AND prim.enddate = primsymb.enddate
                   JOIN onetick_isincur_data@refdata_link oi
                   ON dat.universeid = oi.universeid
                   JOIN
                   (SELECT   universeid, MAX (enddate) AS enddate
                        FROM onetick_isincur_data@refdata_link
                    GROUP BY universeid) oilatest
                   ON oi.universeid = oilatest.universeid
                 AND oi.enddate = oilatest.enddate
          ORDER BY dat.universeid, dat.mic, dat.symbology, dat.enddate)
    SELECT      i.instrumentid
             || '||'
             || i.firsttradingdate
             || '000000|'
             || NVL (i.delisteddate, '30001231')
             || '000000|'
             || i.home_market
             || '|'
             || DECODE (imfm.feedid, 0, 'FIXN_RFA', 1, 'ALGO', 2, 'FIXNETIX')
             || '::'
             || osdv.primarysymbol
        FROM tibex_meinstrumentview i JOIN tibex_instrumentmicfeedmapview imfm
             ON i.isin = imfm.isin
           AND i.currencycode = imfm.currencycode
           AND i.home_market = imfm.mic
             JOIN universe@refdata_link u
             ON i.instrumentid = u.instrumentid AND i.instrumentstatus != 3
             and active='Y'
             JOIN
             (SELECT   universeid, DECODE (symbology, 1, 0, 2, 2, -1) feedid,
                       primarysymbol
                  FROM ot_symbol_data_v
              GROUP BY universeid, symbology, primarysymbol) osdv
             ON u.universeid = osdv.universeid
       WHERE osdv.feedid = imfm.feedid
    ORDER BY i.isin, i.currencycode, i.instrumentid;Most of the wait event is
    SQL*Net message from dblink
    SQL*Net message to dblink
    Regards
    NM

    Hi Kim,
    uat_trd_owner@UAT001> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 741667790
    | Id  | Operation                              | Name                           | Rows  | Bytes | Cost (%CPU)| Time     | Inst   |IN-OUT|
    |   0 | SELECT STATEMENT                       |                                |     1 |   137 | 21981   (2)| 00:04:24 |        |      |
    |   1 |  SORT ORDER BY                         |                                |     1 |   137 | 21981   (2)| 00:04:24 |        |      |
    |*  2 |   HASH JOIN OUTER                      |                                |     1 |   137 | 21980   (2)| 00:04:24 |        |      |
    |*  3 |    HASH JOIN OUTER                     |                                |     1 |   131 |   422   (4)| 00:00:06 |        |      |
    |   4 |     NESTED LOOPS                       |                                |       |       |            |          |        |      |
    |   5 |      NESTED LOOPS                      |                                |     1 |   125 |   107   (9)| 00:00:02 |        |      |
    |   6 |       NESTED LOOPS                     |                                |    20 |  1680 |    87  (11)| 00:00:02 |        |      |
    |*  7 |        HASH JOIN                       |                                |     1 |    64 |    86  (11)| 00:00:02 |        |      |
    |   8 |         VIEW                           | TIBEX_INSTRUMENTMICFEEDMAPVIEW |     1 |    34 |    84   (9)| 00:00:02 |        |      |
    |   9 |          HASH GROUP BY                 |                                |     1 |   166 |    84   (9)| 00:00:02 |        |      |
    |* 10 |           HASH JOIN RIGHT OUTER        |                                |   267 | 44322 |    83   (8)| 00:00:01 |        |      |
    |  11 |            TABLE ACCESS FULL           | TIBEX_BOARDFEEDMAP             |     1 |    20 |     3   (0)| 00:00:01 |        |      |
    |  12 |            NESTED LOOPS OUTER          |                                |   267 | 38982 |    80   (8)| 00:00:01 |        |      |
    |  13 |             NESTED LOOPS OUTER         |                                |   267 | 21627 |    80   (8)| 00:00:01 |        |      |
    |* 14 |              HASH JOIN                 |                                |   267 | 17088 |    80   (8)| 00:00:01 |        |      |
    |  15 |               MERGE JOIN CARTESIAN     |                                |  2004 | 88176 |    37   (0)| 00:00:01 |        |      |
    |  16 |                INDEX FULL SCAN         | TIBEX_EDPDEFAULTFEED_PK        |     1 |     3 |     1   (0)| 00:00:01 |        |      |
    |  17 |                BUFFER SORT             |                                |  2004 | 82164 |    36   (0)| 00:00:01 |        |      |
    |* 18 |                 TABLE ACCESS FULL      | TIBEX_INSTRUMENT               |  2004 | 82164 |    36   (0)| 00:00:01 |        |      |
    |  19 |               VIEW                     | TIBEX_EDPINSTRUMENTMARKETSVIEW | 22040 |   430K|    42  (12)| 00:00:01 |        |      |
    |  20 |                HASH GROUP BY           |                                | 22040 |   430K|    42  (12)| 00:00:01 |        |      |
    |  21 |                 VIEW                   |                                | 22040 |   430K|    41  (10)| 00:00:01 |        |      |
    |  22 |                  SORT UNIQUE           |                                | 22040 |   544K|    41  (57)| 00:00:01 |        |      |
    |  23 |                   UNION-ALL            |                                |       |       |            |          |        |      |
    |  24 |                    INDEX FAST FULL SCAN| TIBEX_EDPFIXNETIXL1_R01        |  7578 |   162K|    18   (0)| 00:00:01 |        |      |
    |  25 |                    TABLE ACCESS FULL   | TIBEX_EDPIXSYMBOLS             |  7494 |   197K|    12   (0)| 00:00:01 |        |      |
    |  26 |                    TABLE ACCESS FULL   | TIBEX_EDPRFALGOSUBSCRIPTION    |  6968 |   183K|     7   (0)| 00:00:01 |        |      |
    |* 27 |              INDEX RANGE SCAN          | TIBEX_MICFEEDMAP_PK            |     1 |    17 |     0   (0)| 00:00:01 |        |      |
    |  28 |             TABLE ACCESS BY INDEX ROWID| TIBEX_INSTRUMENTFEEDMAP        |     1 |    65 |     0   (0)| 00:00:01 |        |      |
    |* 29 |              INDEX UNIQUE SCAN         | TIBEX_INSTRUMENTFEEDMAP_PK     |     1 |       |     0   (0)| 00:00:01 |        |      |
    |  30 |         VIEW                           |                                |   100 |  3000 |     1 (100)| 00:00:01 |        |      |
    |  31 |          REMOTE                        |                                |       |       |            |          | REFDA~ | R->S |
    |  32 |        REMOTE                          | UNIVERSE                       |    20 |   400 |     1   (0)| 00:00:01 | REFDA~ | R->S |
    |* 33 |       INDEX UNIQUE SCAN                | XPKTIBEX_INSTRUMENT            |     1 |       |     0   (0)| 00:00:01 |        |      |
    |* 34 |      TABLE ACCESS BY INDEX ROWID       | TIBEX_INSTRUMENT               |     1 |    41 |     1   (0)| 00:00:01 |        |      |
    |  35 |     VIEW                               | TIBEX_MELASTEXPRICEINTVIEW     |    36 |   216 |   314   (2)| 00:00:04 |        |      |
    |  36 |      HASH UNIQUE                       |                                |    36 |  1656 |   314   (2)| 00:00:04 |        |      |
    |* 37 |       HASH JOIN                        |                                |    36 |  1656 |   313   (1)| 00:00:04 |        |      |
    |  38 |        VIEW                            | VW_SQ_1                        |   304 |  5776 |   157   (2)| 00:00:02 |        |      |
    |  39 |         HASH GROUP BY                  |                                |   304 |  7296 |   157   (2)| 00:00:02 |        |      |
    |* 40 |          TABLE ACCESS FULL             | TIBEX_EXECUTION                | 17462 |   409K|   156   (1)| 00:00:02 |        |      |
    |  41 |        TABLE ACCESS FULL               | TIBEX_EXECUTION                | 17463 |   460K|   156   (1)| 00:00:02 |        |      |
    |  42 |    VIEW                                | TIBEX_MSGSEQBYINSTRUMENT       |  3908 | 23448 | 21558   (2)| 00:04:19 |        |      |
    |  43 |     HASH GROUP BY                      |                                |  3908 | 74252 | 21558   (2)| 00:04:19 |        |      |
    |  44 |      VIEW                              |                                | 11626 |   215K| 21556   (2)| 00:04:19 |        |      |
    |  45 |       UNION-ALL                        |                                |       |       |            |          |        |      |
    |  46 |        HASH GROUP BY                   |                                |  1460 | 26280 |  8906   (1)| 00:01:47 |        |      |
    |  47 |         TABLE ACCESS FULL              | TIBEX_QUOTE                    |  1362K|    23M|  8866   (1)| 00:01:47 |        |      |
    |  48 |        HASH GROUP BY                   |                                |   677 | 12186 | 11750   (2)| 00:02:21 |        |      |
    |  49 |         TABLE ACCESS FULL              | TIBEX_ORDER                    |  1790K|    30M| 11696   (1)| 00:02:21 |        |      |
    |  50 |        HASH GROUP BY                   |                                |   304 |  5472 |   157   (2)| 00:00:02 |        |      |
    |* 51 |         TABLE ACCESS FULL              | TIBEX_EXECUTION                | 17463 |   306K|   156   (1)| 00:00:02 |        |      |
    |  52 |        HASH GROUP BY                   |                                |     1 |    40 |     3  (34)| 00:00:01 |        |      |
    |* 53 |         TABLE ACCESS FULL              | TIBEX_TSTRADE                  |     1 |    40 |     2   (0)| 00:00:01 |        |      |
    |  54 |        HASH GROUP BY                   |                                |   717 | 11472 |   229   (1)| 00:00:03 |        |      |
    |  55 |         INDEX FAST FULL SCAN           | IX_BESTEXREL                   |  7323 |   114K|   228   (0)| 00:00:03 |        |      |
    |  56 |        HASH GROUP BY                   |                                |  1911 | 34398 |    13   (8)| 00:00:01 |        |      |
    |* 57 |         TABLE ACCESS FULL              | TIBEX_MERESUMEPRDTRANSITION    |  5216 | 93888 |    12   (0)| 00:00:01 |        |      |
    PLAN_TABLE_OUTPUT
    |  58 |        HASH GROUP BY                   |                                |     3 |    51 |     5  (20)| 00:00:01 |        |      |
    |  59 |         TABLE ACCESS FULL              | TIBEX_EDPUPDATEREJECT          |    48 |   816 |     4   (0)| 00:00:01 |        |      |
    |  60 |        HASH GROUP BY                   |                                |  1587 | 46023 |   215   (2)| 00:00:03 |        |      |
    |* 61 |         HASH JOIN                      |                                | 35166 |   995K|   213   (1)| 00:00:03 |        |      |
    |  62 |          INDEX FULL SCAN               | XPKTIBEX_CONFIGMEGROUP         |     4 |    16 |     1   (0)| 00:00:01 |        |      |
    |  63 |          TABLE ACCESS FULL             | TIBEX_INSTRUMENTADMIN          | 87915 |  2146K|   212   (1)| 00:00:03 |        |      |
    |  64 |        HASH GROUP BY                   |                                |     6 |   102 |     5  (20)| 00:00:01 |        |      |
    |  65 |         TABLE ACCESS FULL              | TIBEX_BESTEXECPRICELOG         |   793 | 13481 |     4   (0)| 00:00:01 |        |      |
    |  66 |        HASH GROUP BY                   |                                |     1 |    40 |     3  (34)| 00:00:01 |        |      |
    |* 67 |         TABLE ACCESS FULL              | TIBEX_AUCTIONPRICE             |     1 |    40 |     2   (0)| 00:00:01 |        |      |
    |  68 |        HASH GROUP BY                   |                                |  1587 | 28566 |   236   (2)| 00:00:03 |        |      |
    |* 69 |         TABLE ACCESS FULL              | TIBEX_ADMINACK                 | 87915 |  1545K|   233   (1)| 00:00:03 |        |      |
    |  70 |        HASH GROUP BY                   |                                |  1914 | 34452 |    26   (8)| 00:00:01 |        |      |
    |  71 |         INDEX FAST FULL SCAN           | INSTRUMENTSTATEMSGSEQ          | 23705 |   416K|    24   (0)| 00:00:01 |        |      |
    |  72 |        HASH GROUP BY                   |                                |  1458 | 26244 |     8  (13)| 00:00:01 |        |      |
    |  73 |         INDEX FAST FULL SCAN           | TIBEX_FREEZEEOTPK              |  5890 |   103K|     7   (0)| 00:00:01 |        |      |
    Predicate Information (identified by operation id):
       2 - access("A"."INSTRUMENTID"="C"."INSTRUMENTID"(+))
       3 - access("A"."INSTRUMENTID"="B"."INSTRUMENTID"(+))
       7 - access("OSDV"."FEEDID"="IMFM"."FEEDID")
      10 - access("I"."PRIMARYSTATUSBOARDID"="BOARDFM"."BOARDID"(+))
      14 - access("SUBSC"."ISIN"="I"."ISIN" AND "SUBSC"."CURRENCYCODE"="I"."CURRENCYCODE")
           filter("SUBSC"."HOMEMARKET" IS NULL OR "SUBSC"."HOMEMARKET"="I"."HOME_MARKET")
      18 - filter("I"."INSTRUMENTSTATUS"<>3)
      27 - access("SUBSC"."MIC"="MICFM"."MIC"(+))
      29 - access("I"."INSTRUMENTID"="INSTRFM"."INSTRUMENTID"(+))
      33 - access("A"."INSTRUMENTID"="U"."INSTRUMENTID")
      34 - filter("A"."INSTRUMENTSTATUS"<>3 AND TO_DATE("A"."FIRSTTRADINGDATE",'YYYYMMDD')<=SYSDATE@! AND "A"."ISIN"="IMFM"."ISIN"
                  AND "A"."CURRENCYCODE"="IMFM"."CURRENCYCODE" AND "A"."HOME_MARKET"="IMFM"."MIC")
      37 - access("A"."MESSAGESEQUENCE"="MAX(B.MESSAGESEQUENCE)" AND "A"."INSTRUMENTID"="ITEM_0")
      40 - filter(("B"."SELLENTITYTYPE"=0 OR "B"."SELLENTITYTYPE"=2) AND ("B"."BUYENTITYTYPE"=0 OR "B"."BUYENTITYTYPE"=2))
      51 - filter("INSTRUMENTID" IS NOT NULL)
      53 - filter("INSTRUMENTID" IS NOT NULL)
      57 - filter("INSTRUMENTID" IS NOT NULL)
      61 - access("ADMINUSER"="MEGROUPID")
      67 - filter("INSTRUMENTID" IS NOT NULL)
      69 - filter("INSTRUMENTID" IS NOT NULL)
    Remote SQL Information (identified by operation id):
      31 - EXPLAIN PLAN INTO PLAN_TABLE@! FOR SELECT "A1"."UNIVERSEID",DECODE("A1"."SYMBOLOGY",1,0,2,2,(-1)),"A1"."PRIMARYSYMBOL"
            FROM  (SELECT "A6"."SYMBOL" "SYMBOL","A6"."STARTDATE" "STARTDATE","A6"."ENDDATE" "ENDDATE","A3"."CURRENCYCODE"
            "CURRENCYCODE","A6"."PRIMARYMARKET" "PRIMARYMARKET","A4"."SYMBOL" "PRIMARYSYMBOL","A6"."MIC" "MIC","A6"."UNIVERSEID"
            "UNIVERSEID","A6"."SYMBOLOGY" "SYMBOLOGY" FROM "ONETICK_SYMBOL_DATA" "A6", (SELECT "A7"."SYMBOLOGY"
            "SYMBOLOGY","A7"."UNIVERSEID" "UNIVERSEID","A7"."MIC" "MIC",MAX("A7"."ENDDATE") "ENDDATE" FROM "ONETICK_SYMBOL_DATA" "A7" GROUP
            BY "A7"."SYMBOLOGY","A7"."UNIVERSEID","A7"."MIC") "A5","ONETICK_SYMBOL_DATA" "A4","ONETICK_ISINCUR_DATA" "A3", (SELECT
            "A8"."UNIVERSEID" "UNIVERSEID",MAX("A8"."ENDDATE") "ENDDATE" FROM "ONETICK_ISINCUR_DATA" "A8" GROUP BY "A8"."UNIVERSEID") "A2"
            WHERE "A3"."UNIVERSEID"="A2"."UNIVERSEID" AND "A3"."ENDDATE"="A2"."ENDDATE" AND "A6"."UNIVERSEID"="A3"."UNIVERSEID" AND
            "A5"."ENDDATE"="A4"."ENDDATE"(+) AND "A5"."MIC"="A4"."MIC"(+) AND "A5"."UNIVERSEID"="A4"."UNIVERSEID"(+) AND
            "A5"."SYMBOLOGY"="A4"."SYMBOLOGY"(+) AND "A5"."MIC"(+)="A6"."PRIMARYMARKET" AND "A5"."UNIVERSEID"(+)="A6"."UNIVERSEID" AND
            "A5"."SYMBOLOGY"(+)="A6"."SYMBOLOGY" ORDER BY "A6"."UNIVERSEID","A6"."MIC","A6"."SYMBOLOGY","A6"."ENDDATE") "A1" GROUP BY
            "A1"."UNIVERSEID","A1"."SYMBOLOGY","A1"."PRIMARYSYMBOL" (accessing 'REFDATA_LINK' )
      32 - SELECT "INSTRUMENTID","UNIVERSEID" FROM "UNIVERSE" "U" WHERE "UNIVERSEID"=:1 (accessing 'REFDATA_LINK' )
    127 rows selected.
    For trace files
    WAIT #18446741324892119016: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151855125079
    WAIT #18446741324892119016: nam='SQL*Net message from client' ela= 182 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151855125694
    =====================
    PARSING IN CURSOR #18446741324892117968 len=52 dep=0 uid=474 oct=47 lid=474 tim=42151855125777 hv=1029988163 ad='af4d0890' sqlid='9babjv8yq8ru3'
    BEGIN DBMS_OUTPUT.GET_LINES(:LINES, :NUMLINES); END;
    END OF STMT
    PARSE #18446741324892117968:c=0,e=42,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=42151855125769
    WAIT #18446741324892117968: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151855126145
    EXEC #18446741324892117968:c=0,e=262,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,plh=0,tim=42151855126176
    *** 2012-11-20 15:18:56.839
    WAIT #18446741324892117968: nam='SQL*Net message from client' ela= 10252982 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865379208
    CLOSE #18446741324892119016:c=0,e=13,dep=0,type=1,tim=42151865379327
    CLOSE #18446741324892117968:c=0,e=28,dep=0,type=3,tim=42151865379370
    WAIT #18446741324892082152: nam='single-task message' ela= 47849 p1=0 p2=0 p3=0 obj#=-1 tim=42151865429221
    WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 107 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865429886
    WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865429945
    WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 926 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865430901
    WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865431578
    WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 2525 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865434125
    WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670108
    WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 58 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670178
    WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 0 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670235
    WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 60 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670310
    WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670337
    WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 59 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670407
    WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 0 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670464
    WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 60 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670539
    WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670566
    WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 59 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670636
    WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670693
    WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 60 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670768Regards
    NM

  • Sql statement appear twice in trace file

    Hi all,
    Just a little confused on why my sql statement appear twice in the sql trace file.
    the following is the sequence of steps to reproduce this.
    1. Enable sql trace in another session, say session B
    exec dbms_monitor.session_trace_enable(38,13330,TRUE,TRUE);2. Execute the following sql in session B
    select * from hosts where hostname = 'host19'3. Disable sql trace
    exec dbms_monitor.session_trace_disable(38,13330);I used TKPROF to parse the trace file
    tkprof DEV_ora_20621.trc DEV_ora_20621.out sys=noThe output is
    SQL ID: bcpw6ttb0xbqs
    Plan Hash: 0
    select *
    from
      hosts where hostname = 'host19'
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          5          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        1      0.00       0.00          0          5          0           0
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 88
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       1        0.00          0.00
      SQL*Net message from client                     1        0.00          0.00
    SQL ID: bcpw6ttb0xbqs
    Plan Hash: 3617124623
    select *
    from
      hosts where hostname = 'host19'
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      0.00       0.00          0          3          0           1
    total        3      0.00       0.00          0          3          0           1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 88
    Rows     Row Source Operation
          1  TABLE ACCESS BY INDEX ROWID HOSTS (cr=3 pr=0 pw=0 time=0 us cost=2 size=135 card=1)
          1   INDEX RANGE SCAN IDX_HOST01 (cr=2 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 78193)Why the sql is showing twice?
    I think the correct one would be the second since it's reporting the fetching of 1 row.
    Does anyone understand this?
    Cheers,
    -Joel
    Edited by: user12057365 on Jul 21, 2010 1:59 AM

    Could not reproduce this in my 10.2.0.4.0 environment. Whats your Oracle version?

  • How to drill down the cause of "SQL*Net message from/to client"

    Pretty frustrated with my tune up using suggestions from many papers for Oracle 10g R2 on AIX 5.3 L system. My users told me that the system (including Baan 5c) still responds slowly in some processes, some even worsen.
    Using both queries such as
    SELECT sid, schemaname, status FROM gv$session ORDER BY 2;
    SELECT inst_id, seq#, event, p1, p2, p3, wait_time FROM v$session_wait_history WHERE sid=<sid from above>
    INST_ID SEQ# EVENT P1 P2 P3 WAIT_TIME
    1 1 SQL*Net message from client 1413697536 1 0 6419
    1 2 SQL*Net message to client 1413697536 1 0 0
    and others similar, I found very large numbers (almost 97%) of the sessions have events as “SQL*Net message to client” and “SQL*Net message from client” on their wait_time even the sids are in inactive status. After checking the meaning of those messages in Oracle Performance and Tuning document, the document states that mainly they are probably network problems. So How can I drill down to what status of network from my client (the users) to server by Oracle or AIX? In Baan, it has its own parameter sets in its db_resource file controlling the connectivity. In average, there are 4000 “opened cursor current”, but most of them inactives.
    So my colleague asked me rollback all th changes I did on OS level such as minperm%=5
    maxperm%=90
    maxclient%=90,
    lgpg_regions lgpg_size,
    sys0 maxuproc=512,
    aio0 maxservers='260'
    and many ioo parameters to system defaults.
    I even removed the mulitplex copy of the redo log.
    I tried to proof them that there maybe the problem of the Baan/Oracle connectivity, ie due to message above,

    http://docs.oracle.com ... read them for configuration information.
    http://tahiti.oracle.com ... read them for recommendations.
    http://otn.oracle.com ... find the best practices docs.
    http://metalink.oracle.com ... look for similar issues to yours.
    People that change things, on production boxes, without first determining that metrics indicate they are a good idea, and then determining their impact on a test box, should be sold to zoos as leopard food.
    PS: Slowly likely has absolutely nothing to do with anything you touched. First you tune the application. Then you tune the database. Then you tune the operating system. Get out of the way and make the DBAs do their job.

  • Oracle - Informatica transfer speed fetch size and SQL*Net message from c

    Hi,
    I'm testing how fast informatica can take data from our 10.2.0.3 and using large (140GB 1 200 000 000 rows) table as source and doing simple
    select * from large_table .
    Here goes quite interesting wait time analyze :) .
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch   186994    131.84     198.25     127545     314167          0    25431184
    total   186994    131.84     198.25     127545     314167          0    25431184
    Misses in library cache during parse: 0
    Parsing user id: 400
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file scattered read                       9122        0.33         64.71
      SQL*Net more data to client                529327        0.00          8.34
      SQL*Net message from client                186994        0.21        478.74
      SQL*Net message to client                  186994        0.00          0.30
      db file sequential read                       145        0.01          0.49
      gc cr multi block request                    6998        0.01          6.30
      gc current grant 2-way                          9        0.00          0.00
      gc cr grant 2-way                              67        0.00          0.03The interesting part is ' SQL*Net message from client 186994 0.21 478.74'
    so looks like from Informaticka point of view (client side) is lagging 478 sec , so its lagging .
    Doing some math 25431184/186994 = 136 .
    Could You share with me Your experience in that matter ?
    Looks like to speed up I need to :
    1. increase fetch size (not sure how to do that).
    2. increase SDU client and probably server side .
    Network is 100Mbit ethernet so about 10MBytes per second .
    Regards
    GregG

    Have you solve your problem ?
    If yes I'm strongly interest by the solution.
    If you have a question of issue create your own thread and provide the particulars of your use case. This thread is year old.
    OP likely did NOT have any problem. As OP stated the max throughput for a 100 Mbit network is about 10 MB per second. So do the math for moving 140 GB and you will see that the network itself will be the limiting factor.

  • SQL*NET waits in trace file

    Hi All,
    There is a long running query, i generated trace file for this request. In trace file i found that there are huge waits on SQL*Net message from client
    The below is the trace file output:
    Elapsed times include waiting on following events:
    Event waited on Times Waited Max. Wait Total Waited
    SQL*Net message to client 16 0.00 0.00
    SQL*Net more data to client 17 0.00 0.00
    db file sequential read 1450 0.02 4.26
    SQL*Net message from client 16 1414.20 2702.84
    How to resolve this waits from SQL*NET message from client? I checked the network connection, there is no delays in network.
    Any inputs on this issue will be appreciated.

    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.

  • 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.

  • Trace files showing bind variables value=""

    10g on solaris
    Hi All,
    We have an issue with an informatica workflow issuing an update statment to Oracle in trems of performace.
    I switched the tracing on using DBMS_SUPPORT with binds set to TRUE. It has captured the trace files accordingly against a controlled set of data. Twot trace files were produced.
    The first trace files shows the SELECT statment being issues that identifies the records that will be updated.
    The 2nd trace file shows the actual UPDATE statment being issued as a PL/SQL loop to do the update.
    There were 20 records that the users have rigged to updated and the update statment shows 20 cases where updates took place. All updates took place succesfully after checking the post results. However my issue is why the trace files are showing the bind vaules as being set to ""?..any ideas appreciated!
    an extract of the trace file...
    PARSING IN CURSOR #1 len=123 dep=0 uid=1482 oct=6 lid=1482 tim=994827916280 hv=3649357857 ad='8b5b98f0'
    UPDATE /*+ index(FCT_TASK IDX_FCT_TASK_CASE_SBL_ROW_ID)*/ FCT_TASK SET DWH_LAST_UPD_DT = SYSDATE WHERE CASE_SBL_ROW_ID = :1
    END OF STMT
    PARSE #1:c=10000,e=980,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=994827916264
    =====================
    PARSING IN CURSOR #5 len=227 dep=1 uid=0 oct=3 lid=0 tim=994827919231 hv=2190775527 ad='8e622670'
    select u.name,o.name, t.update$, t.insert$, t.delete$, t.enabled from obj$ o,user$ u,trigger$ t where t.baseobject=:1 and t.obj#=o.obj# and o.owner#=u.user# and bitand(property,16)=0 and bitand(property,8
    )=0 order by o.obj#
    END OF STMT
    PARSE #5:c=0,e=1310,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,tim=994827919223
    BINDS #5:
    bind 0: dty=2 mxl=22(22) mal=00 scl=00 pre=00 oacflg=00 oacfl2=0001 size=24 offset=0
    bfp=ffffffff7c058d98 bln=22 avl=04 flg=05
    value=425212
    EXEC #5:c=10000,e=9476,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=994827928883
    FETCH #5:c=0,e=104,p=0,cr=1,cu=0,mis=0,r=0,dep=1,og=4,tim=994827929051
    STAT #5 id=1 cnt=0 pid=0 pos=1 obj=0 op='SORT ORDER BY (cr=1 pr=0 pw=0 time=172 us)'
    STAT #5 id=2 cnt=0 pid=1 pos=1 obj=0 op='NESTED LOOPS (cr=1 pr=0 pw=0 time=110 us)'
    STAT #5 id=3 cnt=0 pid=2 pos=1 obj=0 op='NESTED LOOPS (cr=1 pr=0 pw=0 time=105 us)'
    STAT #5 id=4 cnt=0 pid=3 pos=1 obj=79 op='TABLE ACCESS BY INDEX ROWID TRIGGER$ (cr=1 pr=0 pw=0 time=103 us)'
    STAT #5 id=5 cnt=0 pid=4 pos=1 obj=123 op='INDEX RANGE SCAN I_TRIGGER1 (cr=1 pr=0 pw=0 time=78 us)'
    STAT #5 id=6 cnt=0 pid=3 pos=2 obj=18 op='TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us)'
    STAT #5 id=7 cnt=0 pid=6 pos=1 obj=36 op='INDEX UNIQUE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us)'
    STAT #5 id=8 cnt=0 pid=2 pos=2 obj=22 op='TABLE ACCESS CLUSTER USER$ (cr=0 pr=0 pw=0 time=0 us)'
    STAT #5 id=9 cnt=0 pid=8 pos=1 obj=11 op='INDEX UNIQUE SCAN I_USER# (cr=0 pr=0 pw=0 time=0 us)'
    BINDS #1:
    bind 0: dty=1 mxl=32(30) mal=00 scl=00 pre=00 oacflg=01 oacfl2=800000 size=32 offset=0
    bfp=ffffffff7c17b0a0 bln=32 avl=04 flg=05
    value=""
    EXEC #1:c=8390000,e=8740989,p=55593,cr=55610,cu=3,mis=1,r=1,dep=0,og=1,tim=994836657483
    BINDS #1:
    bind 0: dty=1 mxl=32(30) mal=00 scl=00 pre=00 oacflg=01 oacfl2=800000 size=32 offset=0
    bfp=ffffffff7c17b0a0 bln=32 avl=04 flg=05
    value=""
    EXEC #1:c=7980000,e=7962369,p=55591,cr=55608,cu=1,mis=0,r=1,dep=0,og=1,tim=994844621479
    BINDS #1:
    bind 0: dty=1 mxl=32(30) mal=00 scl=00 pre=00 oacflg=01 oacfl2=800000 size=32 offset=0
    bfp=ffffffff7c17b0a0 bln=32 avl=04 flg=05
    value=""
    ect ect ect...
    Regards
    Satnam

    spliffer wrote:
    Having investigated on the comment of NVARCHAR2 not allowing bind variables to be displayed in the trace file... I checked the datatype of the table/column being used in the index and its is defined as VARCHAR2(15)... ? so Im still not sure as to why we are still getting this.. could it be to do with the clinet application and the way in which it passes the bind vlaues to the oracle update statment?
    any ideas appreciated?
    regards
    SatnamHere is a very brief demonstration.
    The script:
    VARIABLE V1 VARCHAR2
    VARIABLE V2 NVARCHAR2
    EXEC :V1:='A'
    EXEC :V2:='A'
    ALTER SESSION SET TRACEFILE_IDENTIFIER = 'FIND_ME';
    ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';
    SELECT
    FROM
      (SELECT
        ROWNUM COUNTER,
        CHR(MOD(ROWNUM-1,26)+65) CHARACTER
      FROM
        DUAL
      CONNECT BY
        LEVEL<=100)
    WHERE
      CHARACTER= :V1;
    SELECT
    FROM
      (SELECT
        ROWNUM COUNTER,
        CHR(MOD(ROWNUM-1,26)+65) CHARACTER
      FROM
        DUAL
      CONNECT BY
        LEVEL<=100)
    WHERE
      CHARACTER= :V2;
    SELECT SYSDATE FROM DUAL;
    ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';In the script we have two bind variables defined, the first a VARCHAR2 and the second a NVARCHAR2. The output of the script looks like this in both cases:
       COUNTER C
             1 A
            27 A
            53 A
            79 AThe 10046 trace file looks like this:
    PARSING IN CURSOR #3 len=152 dep=0 uid=31 oct=3 lid=31 tim=2874162497 hv=2898495116 ad='a5259590'
    SELECT
    FROM
      (SELECT
        ROWNUM COUNTER,
        CHR(MOD(ROWNUM-1,26)+65) CHARACTER
      FROM
        DUAL
      CONNECT BY
        LEVEL<=100)
    WHERE
      CHARACTER= :V1
    END OF STMT
    PARSE #3:c=0,e=128,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=2874162493
    BINDS #3:
    kkscoacd
    Bind#0
      oacdty=01 mxl=32(01) mxlc=00 mal=00 scl=00 pre=00
      oacflg=03 fl2=1000000 frm=01 csi=178 siz=32 off=0
      kxsbbbfp=0f176c88  bln=32  avl=01  flg=05
      value="A"
    EXEC #3:c=0,e=498,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=2874163947
    WAIT #3: nam='SQL*Net message to client' ela= 3 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874164058
    FETCH #3:c=0,e=68,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=2874164215
    WAIT #3: nam='SQL*Net message from client' ela= 299 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874164657
    WAIT #3: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874164903
    FETCH #3:c=15625,e=359,p=0,cr=0,cu=0,mis=0,r=3,dep=0,og=1,tim=2874165155
    WAIT #3: nam='SQL*Net message from client' ela= 1162 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874166774
    STAT #3 id=1 cnt=4 pid=0 pos=1 obj=0 op='VIEW  (cr=0 pr=0 pw=0 time=76 us)'
    STAT #3 id=2 cnt=100 pid=1 pos=1 obj=0 op='COUNT  (cr=0 pr=0 pw=0 time=50 us)'
    STAT #3 id=3 cnt=100 pid=2 pos=1 obj=0 op='CONNECT BY WITHOUT FILTERING (cr=0 pr=0 pw=0 time=47 us)'
    STAT #3 id=4 cnt=1 pid=3 pos=1 obj=0 op='FAST DUAL  (cr=0 pr=0 pw=0 time=4 us)'
    WAIT #0: nam='SQL*Net message to client' ela= 3 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874167438
    WAIT #0: nam='SQL*Net message from client' ela= 3939 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874171452
    =====================
    PARSING IN CURSOR #2 len=152 dep=0 uid=31 oct=3 lid=31 tim=2874171761 hv=2346424803 ad='a597e190'
    SELECT
    FROM
      (SELECT
        ROWNUM COUNTER,
        CHR(MOD(ROWNUM-1,26)+65) CHARACTER
      FROM
        DUAL
      CONNECT BY
        LEVEL<=100)
    WHERE
      CHARACTER= :V2
    END OF STMT
    PARSE #2:c=0,e=155,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=2874171757
    BINDS #2:
    kkscoacd
    Bind#0
      oacdty=01 mxl=32(02) mxlc=01 mal=00 scl=00 pre=00
      oacflg=03 fl2=1000010 frm=02 csi=2000 siz=32 off=0
      kxsbbbfp=0f176c88  bln=32  avl=02  flg=05
      value=""
    EXEC #2:c=0,e=489,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=2874173190
    WAIT #2: nam='SQL*Net message to client' ela= 3 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874173300
    FETCH #2:c=0,e=68,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,tim=2874173453
    WAIT #2: nam='SQL*Net message from client' ela= 326 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874173906
    WAIT #2: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874174137
    FETCH #2:c=0,e=334,p=0,cr=0,cu=0,mis=0,r=3,dep=0,og=1,tim=2874174398
    WAIT #2: nam='SQL*Net message from client' ela= 1052 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874175570
    STAT #2 id=1 cnt=4 pid=0 pos=1 obj=0 op='VIEW  (cr=0 pr=0 pw=0 time=76 us)'
    STAT #2 id=2 cnt=100 pid=1 pos=1 obj=0 op='COUNT  (cr=0 pr=0 pw=0 time=46 us)'
    STAT #2 id=3 cnt=100 pid=2 pos=1 obj=0 op='CONNECT BY WITHOUT FILTERING (cr=0 pr=0 pw=0 time=43 us)'
    STAT #2 id=4 cnt=1 pid=3 pos=1 obj=0 op='FAST DUAL  (cr=0 pr=0 pw=0 time=4 us)'
    WAIT #0: nam='SQL*Net message to client' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874176119
    WAIT #0: nam='SQL*Net message from client' ela= 998 driver id=1413697536 #bytes=1 p3=0 obj#=10192 tim=2874177197
    ...Notice that the value for the bind variable defined as VARCHAR2 printed in the trace file, while the value for the bind variable defined as NVARCHAR2 did not print in the trace file.
    If I had set the STATISTICS_LEVEL to ALL (or used a GATHER_PLAN_STATISTICS hint) I could retrieve the actual execution plan for the above SQL statements like this (if not, replace ALLSTATS LAST with TYPICAL):
    SET PAGESIZE 1000
    SET LINESIZE 160
    SELECT /*+ LEADING(S) */
      T.PLAN_TABLE_OUTPUT
    FROM
      (SELECT
        SQL_ID,
        CHILD_NUMBER
      FROM
        V$SQL
      WHERE
        SQL_TEXT LIKE '%  CHARACTER= :V_') S,
      TABLE(DBMS_XPLAN.DISPLAY_CURSOR(S.SQL_ID,S.CHILD_NUMBER,'ALLSTATS LAST +COST')) T;The output of the above looks like this:
    SQL_ID  33wwr3kqc71nc, child number 0
    SELECT   * FROM   (SELECT     ROWNUM COUNTER,     CHR(MOD(ROWNUM-1,26)+65) CHARACTER   FROM
        DUAL   CONNECT BY     LEVEL<=100) WHERE   CHARACTER= :V1
    Plan hash value: 761049541
    | Id  | Operation                      | Name | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   |
    |*  1 |  VIEW                          |      |      1 |      1 |     2   (0)|      4 |00:00:00.01 |
    |   2 |   COUNT                        |      |      1 |        |            |    100 |00:00:00.01 |
    |   3 |    CONNECT BY WITHOUT FILTERING|      |      1 |        |            |    100 |00:00:00.01 |
    |   4 |     FAST DUAL                  |      |      1 |      1 |     2   (0)|      1 |00:00:00.01 |
    Predicate Information (identified by operation id):
       1 - filter("CHARACTER"=:V1)
    SQL_ID  7qzd4aq5xr6g3, child number 0
    SELECT   * FROM   (SELECT     ROWNUM COUNTER,     CHR(MOD(ROWNUM-1,26)+65) CHARACTER   FROM
        DUAL   CONNECT BY     LEVEL<=100) WHERE   CHARACTER= :V2
    Plan hash value: 761049541
    | Id  | Operation                      | Name | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   |
    |*  1 |  VIEW                          |      |      1 |      1 |     2   (0)|      4 |00:00:00.01 |
    |   2 |   COUNT                        |      |      1 |        |            |    100 |00:00:00.01 |
    |   3 |    CONNECT BY WITHOUT FILTERING|      |      1 |        |            |    100 |00:00:00.01 |
    |   4 |     FAST DUAL                  |      |      1 |      1 |     2   (0)|      1 |00:00:00.01 |
    Predicate Information (identified by operation id):
       1 - filter(SYS_OP_C2C("CHARACTER")=:V2)Notice in the Predicate Information section of the second execution plan, a function is applied to the column - that SYS_OP_C2C function will likely prevent a normal (non-function based) index from helping to improve the execution performance.
    To answer your question, it is the client application that must correctly define the bind variable types.
    Charles Hooper
    Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
    http://hoopercharles.wordpress.com/
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Extract SQL history from 10046 trace files

    Hi all,
    I need to extract the complete sql history from sql trace files to "debug" a client application.
    I know I can read the raw trc file and rebuild the sql history looking for the PARSING / EXEC / FETCH entries.
    However, this is a very long and boring manual task: do you know if there is some free tool to automate this task?
    thanks
    Andrea

    user585511 wrote:
    I agree that the 10046 trace captures everything. If I do read the raw trc file I see the DML. The problem is that tkprof's record does not record the DML (maybe it thinks that some DML is recursive sql and it gets misleaded... I am not sure) so I am looking for an alternate tool to process 10046 trace files
    Regards
    AndreaReally?
    Generate a trace of some dml:
    oracle:orcl$
    oracle:orcl$ sqlplus /nolog
    SQL*Plus: Release 11.2.0.1.0 Production on Thu May 16 08:28:55 2013
    Copyright (c) 1982, 2009, Oracle.  All rights reserved.
    SQL> conn snuffy/snuffy
    Connected.
    SQL> alter session set tracefile_identifier = "snuffy_session";
    Session altered.
    SQL> alter session set events '10046 trace name context forever, level 12';
    Session altered.
    SQL> insert into mytest values (sysdate);
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> ALTER SESSION SET EVENTS '10046 trace name context off';
    Session altered.
    SQL> exitrun tkprof on the trace
    oracle:orcl$ ls -l $ORACLE_BASE/diag/rdbms/$ORACLE_SID/$ORACLE_SID/trace/*snuffy
    *.trc
    -rw-r----- 1 oracle asmadmin 3038 May 16 08:29 /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snuffy_session.trc
    oracle:orcl$ tkprof /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snu
    ffy_session.trc snuffy.rpt waits=YES sys=NO explain=system/halftrack
    TKPROF: Release 11.2.0.1.0 - Development on Thu May 16 08:31:32 2013
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.Look at the report:
    oracle:orcl$ cat snuffy.rpt
    TKPROF: Release 11.2.0.1.0 - Development on Thu May 16 08:31:32 2013
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    Trace file: /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snuffy_session.trc
    Sort options: default
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    SQL ID: 938dgt554gu98
    Plan Hash: 0
    insert into mytest           <<<<<<<<<<<<<<<< oh my!  Here is the insert statement
    values
    (sysdate)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          1          5           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          0          1          5           1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 86  (SNUFFY)
    Rows     Row Source Operation
          0  LOAD TABLE CONVENTIONAL  (cr=1 pr=0 pw=0 time=0 us)
    error during execute of EXPLAIN PLAN statement
    ORA-00942: table or view does not exist
    parse error offset: 83
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       1        0.00          0.00
      SQL*Net message from client                     1        3.35          3.35
    SQL ID: 23wm3kz7rps5y
    Plan Hash: 0
    commit
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          1           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          0          0          1           0
    Misses in library cache during parse: 0
    Parsing user id: 86  (SNUFFY)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      SQL*Net message from client                     2        4.72          8.50
      log file sync                                   1        0.00          0.00
    SQL ID: 0kjg1c2g4gdcr
    Plan Hash: 0
    ALTER SESSION SET EVENTS '10046 trace name context off'
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
    Parsing user id: 86  (SNUFFY)
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        3      0.00       0.00          0          0          0           0
    Execute      3      0.00       0.00          0          1          6           1
    Fetch        0      0.00       0.00          0          0          0           0
    total        6      0.00       0.00          0          1          6           1
    Misses in library cache during parse: 0
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       3        0.00          0.00
      SQL*Net message from client                     3        4.72         11.86
      log file sync                                   1        0.00          0.00
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        0      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
        3  user  SQL statements in session.
        0  internal SQL statements in session.
        3  SQL statements in session.
        0  statements EXPLAINed in this session.
    Trace file: /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4086_snuffy_session.trc
    Trace file compatibility: 11.1.0.7
    Sort options: default
           1  session in tracefile.
           3  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           3  SQL statements in trace file.
           3  unique SQL statements in trace file.
          58  lines in trace file.
           8  elapsed seconds in trace file.
    oracle:orcl$

  • Plan hash value is 0 in trace file

    Hi,
    One of the developers has a weird problem while coding in java. His query returns no rows when run from the application. But if he runs the same query from sqlplus, it is ok. I traced his session and that's what I got:
    {code}
    PARSING IN CURSOR #8 len=279 dep=0 uid=1896 oct=3 lid=1896 tim=1385424021598785 hv=3759151842 ad='2dcbe1148' sqlid='3pcuxk7h106r2'
    select NAME1, NAME2, ADDRESS1, ADDRESS2, ADDRESS3, ADDRESS4, CITY, STATE, POSTAL, COUNTRY_DESC, SINCE_DT, EFFDT, EFF_STATUS, CUST_ID, ADDRESS_SEQ_NUM, CNTCT_SEQ_NUM, COUNTRY_HOME, HOME_COUNTRY_FLG, VAT_RGSTRN_ID from PS_MKD_CUST_ASX_VW where CUST_ID = :1 and ADDRESS_SEQ_NUM = :2
    END OF STMT
    PARSE #8:c=5999,e=74768,p=0,cr=4,cu=1,mis=0,r=0,dep=0,og=1,plh=0,tim=1385424021598784
    WAIT #8: nam='SQL*Net message to dblink' ela= 1 driver id=675562835 #bytes=1 p3=0 obj#=-1 tim=1385424021598911
    WAIT #8: nam='SQL*Net message from dblink' ela= 835 driver id=675562835 #bytes=1 p3=0 obj#=-1 tim=1385424021599782
    EXEC #8:c=999,e=1015,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=1385424021599859
    WAIT #8: nam='SQL*Net message to client' ela= 1 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1385424021599914
    WAIT #8: nam='SQL*Net message from client' ela= 782 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1385424021600715
    WAIT #8: nam='SQL*Net message to client' ela= 1 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1385424021600773
    WAIT #8: nam='SQL*Net message from client' ela= 1058 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1385424021601870
    WAIT #8: nam='SQL*Net message to dblink' ela= 1 driver id=675562835 #bytes=1 p3=0 obj#=-1 tim=1385424021602027
    WAIT #8: nam='SQL*Net message from dblink' ela= 665 driver id=675562835 #bytes=1 p3=0 obj#=-1 tim=1385424021602705
    FETCH #8:c=0,e=841,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=1385424021602774{/code}
    Notice two things:
    1. I traced with bind variables, but their values are not shown
    2. The plan hash (plh) in all three phases are zero
    Can someone shed a light on this? What am I missing?
    P.S. how do you change the style to code?!

    It's slightly different here. First I know they are not using NVARCHAR and second, it's not the value that's missing. the whole bind variable section is missing. For example this is the dump from another query just before the one above: As you can see the binds are present and happily showing their values:
    PARSING IN CURSOR #3 len=322 dep=0 uid=1896 oct=3 lid=1896 tim=1385421145197998 hv=3861486324 ad='2d8f7d298' sqlid='bas3ndmm2m6rn'
    select u.MD_USER_ID, FIRST_NAME, LAST_NAME, LOGON_ID from MD_USER u, MD_USER_ROLE ur,ROLE_TYPE rt where rt.ROLE_TYPE_GROUP_CODE IN ('ES','EPA') and rt.ROLE_TYPE_ID = ur.ROLE_TYPE_ID and ur.MD_USER_ID = u.MD_USER_ID and ur.SUBS_PS_CUST_ID = :1 and ur.SUBS_PS_ADDRESS_SEQ_NO = :2 order by UPPER(LAST_NAME), UPPER(FIRST_NAME)
    END OF STMT
    BINDS #3:
    Bind#0
      oacdty=01 mxl=4000(4000) mxlc=00 mal=00 scl=00 pre=00
      oacflg=01 fl2=1000000 frm=01 csi=46 siz=4000 off=0
      kxsbbbfp=2b9abfd9ba00  bln=4000  avl=06  flg=05
      value="222672"
    Bind#1
      oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
      oacflg=01 fl2=1000000 frm=01 csi=46 siz=24 off=0
      kxsbbbfp=2b9abfd9cda0  bln=22  avl=02  flg=05
      value=1
    EXEC #3:c=3000,e=5158,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=4056985626,tim=1385421145203129
    WAIT #3: nam='SQL*Net message to client' ela= 2 driver id=1952673792 #bytes=1 p3=0 obj#=-1 tim=1385421145203353
    FETCH #3:c=0,e=205,p=0,cr=40,cu=0,mis=0,r=10,dep=0,og=1,plh=4056985626,tim=1385421145203393

  • Getting timestamps for SQL session without the trace file enabled

    hi, i have a clarification. Is there a method or way by which i can get the timestamps of an SQL session without the the trace file enabled , and if so please get me the details of this.
    thanks in advance.

    Hi,
    Don't very understand what do you want.
    SQL> set timing on
    SQL> select * from dual;
    D
    X
    Elapsed: 00:00:01.07
    SQL> Is this ?
    Nicolas.

  • Reading trace file on the fly.

    I came across one cool trick mentioned by Tanel Poder, but it doesn't seem to work for me. Could anyone please help in reading trace file on the fly.
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
    With the Partitioning, Real Application Clusters, OLAP, Data Mining
    and Real Application Testing options
    SQL> !uname -a
    Linux abc 2.6.16.60-0.34-smp #1 SMP Fri Jan 16 14:59:01 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux
    SQL> select value ||'/'||(select instance_name from v$instance) ||'_ora_'||
      2             (select spid||case when traceid is not null then '_'||traceid else null end
                     from v$process where addr = (select paddr from v$session
      3    4                                               where sid = (select sid from v$mystat
      5                                                          where rownum = 1
      6                                                     )
      7                                          )
      8             ) || '.trc' tracefile
      9      from v$parameter where name = 'user_dump_dest'
    10     /
    TRACEFILE
    /n01/oraadmin1/diag/rdbms/abc/inst1/trace/inst11_ora_28754.trc
    SQL> host mknod /n01/oraadmin1/diag/rdbms/abc/inst1/trace/inst11_ora_28754.trc p
    SQL> set define off
    SQL> host grep "WAIT" /n01/oraadmin1/diag/rdbms/abc/inst1/trace/inst11_ora_28754.trc &
    SQL> set define on
    SQL> alter session set events '10046 trace name context forever, level 8';
    Session altered.
    SQL> select * from dual;
    D
    X
    SQL>
    SQL> select * from dual;
    D
    X
    {code}
    I dont get any WAIT printed into the pipe file created before tracing.
    Am i doing something wrong here ?
    Edited by: Yasu on Nov 12, 2012 10:14 AM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

    I tried manual method and yes i am able to find WAIT lines in trace file.
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
    With the Partitioning, Real Application Clusters, OLAP, Data Mining
    and Real Application Testing options
    SQL> select value ||'/'||(select instance_name from v$instance) ||'_ora_'||
               (select spid||case when traceid is not null then '_'||traceid else null end
      2    3                   from v$process where addr = (select paddr from v$session
      4                                               where sid = (select sid from v$mystat
      5                                                          where rownum = 1
      6                                                     )
      7                                          )
      8             ) || '.trc' tracefile
      9      from v$parameter where name = 'user_dump_dest'
    10     /
    TRACEFILE
    /n01/oraadmin1/diag/rdbms/proddba/proddba1/trace/proddba1_ora_23021.trc
    SQL> alter session set events '10046 trace name context forever, level 8';
    Session altered.
    SQL> select * from dual;
    D
    X
    SQL> alter session set events '10046 trace name context off';
    Session altered.
    SQL> !ls -lrt /n01/oraadmin1/diag/rdbms/proddba/proddba1/trace/proddba1_ora_23021.trc
    -rw-r----- 1 oracle oinstall 2738 2012-11-12 01:13 /n01/oraadmin1/diag/rdbms/proddba/proddba1/trace/proddba1_ora_23021.trc
    SQL> !grep "WAIT" /n01/oraadmin1/diag/rdbms/proddba/proddba1/trace/proddba1_ora_23021.trc
    WAIT #1: nam='SQL*Net message to client' ela= 6 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1352704368368424
    WAIT #1: nam='SQL*Net message from client' ela= 4057810 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1352704372428142
    WAIT #1: nam='SQL*Net message to client' ela= 6 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1352704372428492
    WAIT #1: nam='SQL*Net message from client' ela= 195 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1352704372428892
    WAIT #1: nam='SQL*Net message to client' ela= 3 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1352704372428939
    WAIT #1: nam='SQL*Net message from client' ela= 46319788 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=1352704418748740Not sure why using mknod fails in my case.
    Edited by: Yasu on Nov 12, 2012 12:48 PM

  • TRACING IN SQL*NET V2

    제품 : SQL*NET
    작성날짜 : 1997-10-10
    Introduction
    ~~~~~~~~~~~~
    For most problems you need to identify the relevant parts of a
    connection to trace. To do this consider which scenario you are
    having problems with and where tracing needs to be enabled.
    Note that tracing produces a lot of output , especially at higher
    trace levels.
    There are 3 main areas of SQL*Net that can produce trace output:
    1 = the SQL*Net 'client'
    2 = the 'listener' process
    3 = the SQL*Net 'server'.
    a) Establishing a connection:
    Client ----> Listener ----> Server
    1 2 3
    b) An established connection:
    Client --------> Server
    1 3
    c) Opening a database link:
    Client ----> Server ----> Listener -----> Server2
    1 3 1 2 3
    Note here that the Oracle server process is also a SQL*Net
    client when it makes an outgoing call to a listener to
    open a database link. Database links are OPENED when first
    used. They should then remain open until closed.
    d) An established database link:
    Client ----> Server -----> Server2
    1 3 1 3
    In each case here there are several potential sampling points. You
    should be able to identify quickly which of these scenarios matches
    your setup. As these scenarios are likely to involve connections
    between different machines you should remember that tracing for any
    process is controlled by the configuration details that the process
    reads WHEN IT IS STARTED. This is especially important when looking
    at MTS connections as the SQL*Net server is the 'dispatcher' process.
    Some dispatchers are started when the database instance is started
    and others may start at a later time (on demand). Each dispatcher will
    read their SQL*Net configuration WHEN THEY START.
    7.2 Client Tracing
    ~~~~~~~~~~~~~~
    For client TOOLS edit or create the file $HOME/.sqlnet.ora and add
    the lines:
    trace_level_client=16
    trace_file_client=cli
    trace_directory_client=/tmp # Or a known directory
    trace_unique_client=true # Add '_pid' to trace filename
    This will turn on FULL tracing for your user account only producing
    output in a file called /tmp/cli_<PID>.trc .
    (For some SQL*Net versions the file will be just /tmp/cli.trc)
    For client 'ORACLE' process (as in the case of database links) put this
    same information into $TNS_ADMIN/sqlnet.ora file.
    On versions up to and including Oracle 7.0.16 client trace may not
    add a process ID to the name of the trace file. This means two
    processes may end up writing to the same trace file unless you
    take care to control which processes write trace output to each file.
    7.3 Listener Tracing
    ~~~~~~~~~~~~~~~~
    Listener tracing can ONLY be configured in the listener.ora file.
    Add the lines below to the listener.ora file:
    trace_level_listener=16
    trace_file_listener=listener
    trace_directory_listener=/tmp # Or a known directory
    This will define FULL listener tracing to the file /tmp/listener.trc.
    You can enable this tracing by either:
    lsnrctl reload
    OR
    lsnrctl stop;
    lsnrctl start;
    TCP/IP
    ~~~~~~
    It is often useful to confirm that a listener is listening on a
    specified address. Most Unix machines include a command called
    'netstat' (Often in /etc or in /usr/etc). The command netstat -a
    should list all TCP/IP end points on which a listener is listening.
    Eg:
    For a listener listening on HOST=... PORT=1580 there should be a
    netstat entry of the form:
    RecvQ SendQ Local Address Foreign Address TCP state
    0 0 *.1580 *.* LISTEN
    Note: Some versions of netstat will only list established connections
    and not listen end points. See the man page on your machine.
    7.4 Server Tracing
    ~~~~~~~~~~~~~~
    Server side trace is not required as often as the other two traces
    mainly because most problems are related to establishing a connection.
    Once a connection has been established the client and server processes
    are communicating. It is sometimes useful to see exactly what SQL
    commands have been received by the server, and what data it has sent
    back out.
    The file $TNS_ADMIN/sqlnet.ora controls the server side tracing. Add
    the lines below to this file:
    trace_level_server=16
    trace_file_server=server
    trace_directory_server=/tmp # Or a known directory
    Output should be sent to the file /tmp/server_<PID>.trc
    Note: Server side tracing acts on the SQL*Net server side.
    For dedicated connections this is the Oracle process on the
    server machine.
    For MTS connections this is the DISPATCHER and NOT the shared
    server. Data is passed between the dispatcher and the shared
    servers via the SGA and this does NOT involve SQL*Net.
    It is also important to note that as a dispatcher handles
    several client processes the dispatcher trace output can be a
    mix of trace from many client processes making it VERY difficult
    to follow. The general advice for such problems is:
    a) See if the problem reproduces WITHOUT using MTS - if
    so the trace is much cleaner
    b) If a problem ONLY reproduces under MTS ensure the machine
    is in a controlled environment so you can be sure that only
    YOUR process is using the dispatcher.
    7.5 Trace Summary
    ~~~~~~~~~~~~~
    1) Identify where you need to trace.
    2) Identify which files on which machines control tracing at these
    points. Tracing is controlled in the following files:
    Client Server Listener
    ~~~~~~ ~~~~~~ ~~~~~~~~
    Files: $HOME/.sqlnet.ora sqlnet.ora listener.ora
    sqlnet.ora
    3) Add in the relevant trace parameters (See Below)
    4) Restart any processes that need to read the new trace values.
    Reload the listener as required.
    5) Reproduce your problem
    6) Save all your trace output immediately
    7) Disable the tracing
    7.6 Main Trace Parameters
    ~~~~~~~~~~~~~~~~~~~~~
    trace_level_listener = off
    trace_file_listener = Filename *1
    trace_directory_listener = Directory *2
    *1 Unquoted (") filenames will be translated into lower case.
    *2 You CANNOT use environment variables in the Filename or Directory
    name.
    7.7 Diagnosing Trace output
    ~~~~~~~~~~~~~~~~~~~~~~~
    Trace output can be very difficult to follow. Before looking at a
    trace file make sure:
    a) You are familiar with the sequence of events in setting up
    a connection. SQL*Net connections follow a sequence of
    events - you will need to determin where in the sequence
    the problem occurs.
    b) Do not be misled by error reports in the trace files. You
    must follow the context of the errors - an error may be
    quite valid at that point in a sequence. Eg: For client
    connections a list of addresses to call is built - if the
    first address yeilds no response the next address is tried.
    This next address may yeild a response and the 'true' error
    occurs at this point in the sequence.
    c) Do not be misled by unusual 'Bequeath' connections in the
    trace. If an error is received over SQL*Net the client
    may use a "Bequeath" operation to spawn an oracle process
    which it then uses to get the TEXT of the error. A very short
    exchange of packets occurs and the bequethed process exits.
    The 'TRUE' problem is likely to be before this bequeath
    operation.
    Useful trace 'tags':
    The following are useful items to follow in trace files - these
    are not guaranteed to be valid across all SQL*Net releases and
    are for guidance only. Entries are assumed to be taken at trace
    level 16 to allow data packets to be seen. This will produce a
    LOT of trace output.
    -<ERROR>-
    Error information follows. Remember the error may be acceptable
    osntns: Calling address
    Shows address list constructed for a call OUT to a listener
    nricall: Making call with following address information: ...
    Shows the ACTUAL address being called from the above list
    nsopen: entry
    We are about to try and open a connection.
    nsopen: transport is open
    nsopen: error exit
    A connection to the called address has been made / failed.
    nsclose: ...
    An established connection is being closed - check nearby
    for errors.
    nscall: redirected
    The client has been redirected to a differenct address.
    The next step should be to call the new address. The address
    should appear in an earlier data packet.
    nspsend / nsprecv
    Outgoung / Incoming data

    This forum is for Oracle Migration Workbench issues, i.e. migration using the workbench from a non Oracle database to an Oracle database.
    Here are some pointers that may be useful, but you may need to get more information elsewhere, for example Oracle Customer Support.
    a Oracle 7.1 client (including your example) will connect to an Oracle 8.1.5 server.
    Is the server correctly configured (can a client connect from another machine)?
    Tracing can be turned on in the client, server and/or listener to get further information.
    Turloch

Maybe you are looking for