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,
VinodhVinodh 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 AMRan 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
NMHi 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 AMCould 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
GregGHave 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. -
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?
NosorogAs 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
Satnamspliffer 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
Andreauser585511 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 AMI 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 -
제품 : 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 dataThis 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
-
The method 'commit' cant be called when a global transaction is active.
Hello, I've installed the SOAdemo a couple of times on local machines, and it works fine. Now I've deployed the SOADemo on a separate server and a strange error occurs in BPEL when testing the SOADemo. The SOAOrderBooking BPEL process runs into an er
-
I have recently received a pdf file that, although previously opened, now shows totally blacked out? What can I do to correct this?
-
I'm trying to determine if I am dealing with an RFC connection issue or just an error resulting from the RFC itself. The error says "Processing of change number...cancelled (raised by...ECCHostXYZ)". I thought this was a problem with my RFC config be
-
firefox 15.0.1 windows xp * Shockwave Flash 11.4 r402 * Adobe PDF Plug-In For Firefox and Netscape 10.1.4 * DRM Netscape Network Object * DRM Store Netscape Plugin * Npdsplay dll
-
Phone jack nowhere near where I want to place the gateway
I recently received a wireless gateway to replace my modem and router. I have the triple play. I do not have a phone jack anywhere near where I want to place the wireless gateway for Internet access. I currently have the modem for the phone in the