Location of client trace files sync'ed to the middleware

Hi
In the documentation (link below) it is mentioned that trace files sync'ed from the client to the middleware can be opened with an editor (on the middleware) but where are the files located?
http://help.sap.com/saphelp_nw04/helpdata/en/42/f9943fbaf93268e10000000a1553f6/content.htm
Thanks for any help,
Andre

Hi Andre,
The transaction ME_RTRACE is used to set the trace settings on the MI client instead of the user of the mobile device setting it. This is usually handled by the administrator. Just by setting this on the middleware will not get the trace on the middleware. The process is as follows:
The administrator makes the trace settings on the middleware. This is updated on the client device when that device makes a sync with the middleware. Now if the administrator wants to see the trace file then he has to activate the checkbox - Send with Next sync or the user on the mobile device can select the option - Send trace to server.
This trace can be viewed in CCMS. For this go to transaction RZ11 - Mobile Infrastructure - Logs and traces.
Here you can do a select for the particular device which you are interested in.
Regards,
Nameeta

Similar Messages

J2EE, possible to serve clients jsp files that are outside the war file?

Hi, I was wondering with a J2EE webserver if it was possible to serve clients webpages from jsp files that were outside the client.
For example say you got your war file in the auto deploy directory on the server and also on the server you got a directory full of jsp files that could be accessed by the webserver just like normal jsp files inside the war file?
...I want to do this because I want to be able to add jsp files without rebuilding the war file.
....Or is it possible to make the webserver rebuild itself, eg to add or remove files?
Thanks

If you are using a S1WS6.1, please try to find a line with WEBAPP in server.xml.
You should find a line like this.
<WEBAPP uri="/simple" path="/opt/SUNWwbsvr/https-test/webapps/https-test/simple" enabled="true"/>
The path parameter shows the directory where the S1WS refers to when the webapplication is executed.
You can put a jsp into the directory and modify it accordingly.
Please refer to the following docs. They might help.
http://docs.sun.com/source/817-6251/pwadeply.html#wp25317
http://docs.sun.com/source/817-6251/pwadeply.html#wp25890
thanks,
-Yuji

Default location of control trace file

hi all
when i want to issue :
SQL>alter database backup controlfile to trace;
command execute without error
but when i open "D:\oracle\product\10.2.0\admin\orcl\udump"
there is no any file related to trace control file ,inside this directry .
when i issue :
select c.value || '/' || instance || '_ora_' ||
ltrim(to_char(a.spid,'fm99999')) || '.trc'
from v$process a, v$session b, v$parameter c, v$thread c
where a.addr = b.paddr
and b.audsid = userenv('sessionid')
and c.name = 'user_dump_dest'
output of above query is :
D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP/orcl_ora_2072.trc
but i dont find this file ..........

>
but still i m not able to find related to trace control file
,when i issue "alter database backup controlfile to trace"Check here
http://www.adp-gmbh.ch/ora/sql/alter_database.html (with examples!!!)
I'm guessing that your file is there somewhere, you're just looking in the wrong place - maybe
in the SQL*Plus bin directory or the oracle bin directory? Do a search!
Anyway, just reissue the command using the syntax at the wesite
posted - please tell us how you got on!!
HTH.
Paul...
When asking database related questions, please give other posters
some clues, like OS (with version), version of Oracle being used and DDL.
Other trivia such as CPU, RAM + Disk configuration might also be useful.
The exact text and/or number of error messages is useful (!= "it didn't work!"). Thanks.
Furthermore, as a courtesy to those who spend time analysing and attempting to help,
please do not top post and do try to trim your replies!

Access my flat file, which is located on client machine

Hi all,
I have configure Webutil on ApplicationServer to access flat file contents which is located on client machine also configure all of the required parameter.
file open Dialog box open successfuly but after selecting flat file from client machine ,content of text file is not read
but if flat file exists on application server it is working properly;
code is here
begin
:file_name:= CLIENT_GET_FILE_NAME('c:/', File_Filter=>'Text Files (*.txt)|*.txt|');
get_file_contents(:file_name);
exception when others then
message(sqlerrm);
end;
Edited by: user581546 on Apr 1, 2010 5:02 AM

In webutil.pll there is a function CLIENT_TEXT_IO. By using this function you can read the client text file.
Search on forum by CLIENT_TEXT_IO
-Ammad

Wait Events "log file parallel write" / "log file sync" during CREATE INDEX

Hello guys,
at my current project i am performing some performance tests for oracle data guard. The question is "How does a LGWR SYNC transfer influences the system performance?"
To get some performance values, that i can compare i just built up a normal oracle database in the first step.
Now i am performing different tests like creating "large" indexes, massive parallel inserts/commits, etc. to get the bench mark.
My database is an oracle 10.2.0.4 with multiplexed redo log files on AIX.
I am creating an index on a "normal" table .. i execute "dbms_workload_repository.create_snapshot()" before and after the CREATE INDEX to get an equivalent timeframe for the AWR report.
After the index is built up (round about 9 GB) i perform an awrrpt.sql to get the AWR report.
And now take a look at these values from the AWR
                                                                   Avg
                                             %Time Total Wait    wait     Waits
Event                                 Waits -outs    Time (s)    (ms)      /txn
log file parallel write              10,019     .0         132      13      33.5
log file sync                           293     .7           4      15       1.0
......How can this be possible?
Regarding to the documentation
-> log file sync: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3120
Wait Time: The wait time includes the writing of the log buffer and the post.-> log file parallel write: http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3104
Wait Time: Time it takes for the I/Os to complete. Even though redo records are written in parallel, the parallel write is not complete until the last I/O is on disk.This was also my understanding .. the "log file sync" wait time should be higher than the "log file parallel write" wait time, because of it includes the I/O and the response time to the user session.
I could accept it, if the values are close to each other (maybe round about 1 second in total) .. but the different between 132 seconds and 4 seconds is too noticeable.
Is the behavior of the log file sync/write different when performing a DDL like CREATE INDEX (maybe async .. like you can influence it with the initialization parameter COMMIT_WRITE??)?
Do you have any idea how these values come about?
Any thoughts/ideas are welcome.
Thanks and Regards

Surachart Opun (HunterX) wrote:
Thank you for Nice Idea.
In this case, How can we reduce "log file parallel write" and "log file sync" waited time?
CREATE INDEX with NOLOGGINGA NOLOGGING can help, can't it?Yes - if you create index nologging then you wouldn't be generating that 10GB of redo log, so the waits would disappear.
Two points on nologging, though:
<ul>
it's "only" an index, so you could always rebuild it in the event of media corruption, but if you had lots of indexes created nologging this might cause an unreasonable delay before the system was usable again - so you should decide on a fallback option, such as taking a new backup of the tablespace as soon as all the nologging operatons had completed.
If the database, or that tablespace, is in +"force logging"+ mode, the nologging will not work.
</ul>
Don't get too alarmed by the waits, though. My guess is that the +"log file sync"+ waits are mostly from other sessions, and since there aren't many of them the other sessions are probably not seeing a performance issue. The +"log file parallel write"+ waits are caused by your create index, but they are happeninng to lgwr in the background which is running concurrently with your session - so your session is not (directly) affected by them, so may not be seeing a performance issue.
The other sessions are seeing relatively high sync times because their log file syncs have to wait for one of the large writes that you have triggered to complete, and then the logwriter includes their (little) writes with your next (large) write.
There may be a performance impact, though, from the pure volume of I/O. Apart from the I/O to write the index you have LGWR writting (N copies) of the redo for the index and ARCH is reading and writing the completed log files caused by the index build. So the 9GB of index could easily be responsible for vastly more I/O than the initial 9GB.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

APEX Overhead and trace files

Hey everyone,
We've been asked to "stress" and "load" test our application as it is predicted our user base might grow in the near future (company acquisitions/etc)...
Unfortunately, there is concern about the overhead added by APEX. From everything I've read, I do not personally believe APEX adds much to each page view (as compared to our own self-managed data), however I need to PROVE this to our system admins/etc. Simply referencing things on the internet like "APEX doesn't add much overhead" doesn't exactly make the case.
To accomplish my mission, I've done the following:
1) generated a trace file on a test page by appending the following to the end of the URL:
"&p_trace=YES" (without quotes)
2) found the location of trace files using:
select value from v$parameter where name = 'user_dump_dest';
3) found the exact trace file for my apex page view
grep -l "3853406964369" *.trc (where the number in quotes was the session id taken from my apex url)
4) formatted the trace file using tkprof from the linux command line:
tkprof orcl_ora_24115.trc tkprof_output
Now, I'm in the process of examining the file. It is great that it shows everything involved in generating a page! A couple of quick questions though.
A) is it safe to assume that this trace file (found by using my method above in steps 1-4) only contains records associated with my single apex page view? My fear is that just because a file contains my session id, that does not guarantee that other random stuff from other sessions is also in the same file (sorry i'm new to trace files and especially trace files generated by apex).
B) if i view a second page with the trace=YES, will a second file get generated or does it get combined into 1 file? how can i easily tell which file is for which page view?
C) is there an easy way to differentiate what queries would normally be made by oracle (regardless of the UI) versus queries ran by APEX specifically (which would not occur if we were using PHP for a front end)?
Specifically, I see queries (similar to the following) that do not appear to be APEX specific from what I can tell:
-- example 1 --
select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i.flags,i.property,
i.pctfree$,i.initrans,i.maxtrans,i.blevel,i.leafcnt,i.distkey,i.lblkkey,
i.dblkkey,i.clufac,i.cols,i.analyzetime,i.samplesize,i.dataobj#,
nvl(i.degree,1),nvl(i.instances,1),i.rowcnt,mod(i.pctthres$,256),
i.indmethod#,i.trunccnt,nvl(c.unicols,0),nvl(c.deferrable#+c.valid#,0),
nvl(i.spare1,i.intcols),i.spare4,i.spare2,i.spare6,decode(i.pctthres$,null,
null,mod(trunc(i.pctthres$/256),256)),ist.cachedblk,ist.cachehit,
ist.logicalread
from
ind$ i, ind_stats$ ist, (select enabled, min(cols) unicols,
min(to_number(bitand(defer,1))) deferrable#,min(to_number(bitand(defer,4)))
valid# from cdef$ where obj#=:1 and enabled > 1 group by enabled) c where
i.obj#=c.enabled(+) and i.obj# = ist.obj#(+) and i.bo#=:1 order by i.obj#
-- example 2 --
select intcol#, toid, version#, intcols, intcol#s, flags, synobj#
from
subcoltype$ where obj#=:1 order by intcol# asc
and I see queries that are definitely APEX related (based on the existence of references to wwv objects):
-- example 3 --
SELECT ID, BRANCH_NAME, BRANCH_ACTION, BRANCH_POINT, BRANCH_TYPE,
BRANCH_CONDITION, BRANCH_CONDITION_TEXT, BRANCH_CONDITION_TYPE,
BRANCH_WHEN_BUTTON_ID, NVL(SAVE_STATE_BEFORE_BRANCH_YN,'N'),
SECURITY_SCHEME
FROM
WWV_FLOW_STEP_BRANCHES WHERE FLOW_ID = :B4 AND FLOW_STEP_ID = :B3 AND
BRANCH_POINT = 'BEFORE_HEADER' AND (REQUIRED_PATCH IS NULL OR
(REQUIRED_PATCH > 0 AND (:B2 IS NULL OR INSTR(:B2 ,
':'||TO_CHAR(REQUIRED_PATCH)||':') = 0) ) OR (REQUIRED_PATCH < 0 AND (:B1
IS NULL OR INSTR(:B1 ,':'||TO_CHAR(0-REQUIRED_PATCH)||':') = 0) ) ) ORDER
BY BRANCH_SEQUENCE, ID
and then of course it's easy for me to identify any queries that are based on our code because I recognize the object names we use.
In the mean-time I'm starting to look into how to interpret trace files (outside of the context of apex).
My biggest concern is that I do not want to "ding" or "tax" APEX for queries that it had nothing to do with and that would be ran by oracle regardless of the UI we use to "view a page".
Thanks!

Move older audit files to a different filesystem until you find someone being able to define what files can be deleted.
Regards
Gustavo Restuccia

Fetch phase in a trace file

Oracle version: 11.2.0.3.0 Enterprise Edition
OS - IBM/AIX RISC System/6000
I am trying to generate a trace file from a piece of code executed by java server. What I asked the java developer to do is to place this block immediately after establishing a connection:
BEGIN
EXECUTE IMMEDIATE 'ALTER SESSION SET TRACEFILE_IDENTIFIER = ''M1''';
dbms_monitor.session_trace_enable(waits => FALSE, binds => TRUE);
END;And at the end of the logical java block of code:
BEGIN
dbms_monitor.session_trace_disable;
END;What I want to know is how many rows the java server fetches after executing one particular select statement, because they complain about receiving less in count rows from the select statement than expecting.
For example, if I execute the same sql query in sqlplus session, then I fetch let's say 1000 rows.
When the same query is executed from java side, the fetched rows are less in count, let's say 500.
And because I doubt it, I wanted to trace to see what actually is executed and how.
From the excerpt of the trace file I see exactly the same query which I execute myself in a sqplus session.
There is no fine-grained control on the udnerlying tables in the query.
And my question is, how to interpret the FETCH phase of the cursor (for the select statement)?
For example, if I see one FETCH for this cursor, does this mean that the java server has fetched only one row?
If I see 100 FETCHes, does this mean they fetched 100 rows from the cursor?
Here is a short excerpt from the trace file (please don't crucify me for the query and the obvious denormalized design of the tables, this is not invented by me):
PARSING IN CURSOR #4573587152 len=667 dep=0 uid=737 oct=3 lid=737 tim=17685516462413 hv=954980718 ad='70000006d3e4940' sqlid='69pm96nwfrqbf'
select /* ordered */ o.id, nvl(o.par_id, -1) as par_id, o.NAME_GER, o.NAME_ENG, o.NAME_ESP, o.NAME_ITL,o.NAME_FRA, decode(lo.lflag, 'Y', 'L', 'N') as leaf_or_node, lo.distance + 1 as "LEVEL", to_char(o.beg_date, 'DD.MM.YYYY HH24:MI:SS'), o.mais_id, l.path, nvl(o.non_selectable, 'N') from st_prod o, lprod_new l, lprod lo where o.end_date = to_date('31.12.3999', 'DD.MM.YYYY') and (lo.id, lo.beg_date) in (select id, beg_date from st_prod where par_id is null and end_date = to_date('31.12.3999', 'DD.MM.YYYY')) and lo.lid = o.id and lo.lid_beg_date = o.beg_date and l.st_prod_id = o.id and l.st_prod_beg_date = o.beg_date order by lo.distance, o.name_ger
END OF STMT
PARSE #4573587152:c=31,e=152,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2027551050,tim=17685516462412
EXEC #4573587152:c=80,e=375,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=2027551050,tim=17685516462936
*** 2013-03-11 11:28:09.122
FETCH #4573587152:c=519446,e=892645,p=0,cr=113446,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517355715
FETCH #4573587152:c=37,e=59,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517359109
FETCH #4573587152:c=39,e=63,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517361128
FETCH #4573587152:c=29,e=46,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517362849
FETCH #4573587152:c=31,e=48,p=0,cr=0,cu=0,mis=0,r=10,dep=0,og=1,plh=2027551050,tim=17685517364621
<162 more FETCH-es here>
<STAT phase>
CLOSE #4573587152:c=533,e=849,dep=0,type=1,tim=17685517671878Is it possible based on the trace file (if I have to change something in the way of tracing) to determine how many rows were fetched?

Hi
I read the traces into a table from the client from which I log and then read from the table If you can copy the content of the table column you are reading and paste it into a file say : your_trace_name.trc file then you can use this to generate a TKPROF trace fiile
C:\>tkprof your_trace_file.trc your_trace_file.txt
TKPROF: Release 10.2.0.3.0 - Production on Mon Mar 11 15:28:13 2013
Copyright (c) 1982, 2005, Oracle. All rights reserved.To find the arraysize you are using then use this formula
rows/Fetch = arraysizeFew details about interpreting TKRPOF exist here
http://hourim.wordpress.com/2012/09/14/tuning-by-tkprof-a-case-study/
Best regards
Mohamed Houri

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.

Interpreting Trace File.

Hi i am using 10.2.0.4.0 version of oracle.
I am having trace file info as below, for one of the query. So how should i interpret the trace file? What is the issue in the query, and the scope of improvement in the query? please note that , i have removed the query and its plans from the trace file, i have only posted the wait sections.
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.14       0.13          0          0          1           0
Execute      1      6.63     162.12      33540      72921        383           0
Fetch    17272    178.89    1933.95     274835    3147603         20      259063
total    17274    185.66    2096.21     308375    3220524        404      259063
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 36
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
control file sequential read                    4        0.00          0.00
db file sequential read                    302812        0.62       1913.89
latch: cache buffers chains                     3        0.04          0.04
direct path write temp                        501        0.01          0.30
SQL*Net message to client                   17272        0.00          0.04
db file scattered read                        120        0.02          0.63
direct path read temp                         608        0.14          1.71
SQL*Net message from client                 17272       44.81      31865.74
SQL*Net more data to client                    15        0.00          0.00
latch: object queue header operation            1        0.00          0.00
latch: library cache                            3        0.03          0.04
latch: library cache pin                        1        0.00          0.00
latch: cache buffer handles                     1        0.00          0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.14       0.13          0          0          1           0
Execute      1      6.63     162.12      33540      72921        383           0
Fetch    17272    178.89    1933.95     274835    3147603         20      259063
total    17274    185.66    2096.21     308375    3220524        404      259063
Misses in library cache during parse: 1
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                   17275        0.00          0.04
SQL*Net message from client                 17274       75.57      31941.39
SQL*Net more data from client                   2        0.00          0.01
db file sequential read                    302812        0.62       1913.89
control file sequential read                    4        0.00          0.00
latch: cache buffers chains                     3        0.04          0.04
direct path write temp                        501        0.01          0.30
db file scattered read                        120        0.02          0.63
direct path read temp                         608        0.14          1.71
SQL*Net more data to client                    15        0.00          0.00
latch: object queue header operation            1        0.00          0.00
latch: library cache                            3        0.03          0.04
latch: library cache pin                        1        0.00          0.00
latch: cache buffer handles                     1        0.00          0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       11      0.02       0.01          0          0          0           0
Execute    348      0.20       0.17          0          0          1           0
Fetch      367      0.06       0.37         59       1187          0        3806
total      726      0.28       0.56         59       1187          1        3806
Misses in library cache during parse: 11
Misses in library cache during execute: 10
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                        59        0.01          0.32
    1 user SQL statements in session.
348 internal SQL statements in session.
349 SQL statements in session.
********************************************************************************

below is the estimate and actual results.
| Id | Operation                              | Name                        | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads | Writes | OMem | 1Mem | Us
ed-Mem | Used-Tmp|
|* 1 | COUNT STOPKEY                         |                             | 13475 |        | 13475 |00:01:32.33 |     134K| 11357 |      0 |       |       |
    |         |
|   2 |   NESTED LOOPS                         |                             | 13475 |      2 | 13475 |00:01:31.66 |     134K| 11357 |      0 |       |       |
    |         |
|   3 |    NESTED LOOPS                        |                             | 13475 |      1 | 13475 |00:01:29.22 |   94325 | 11357 |      0 |       |       |
    |         |
|* 4 |     INDEX RANGE SCAN                   |                | 13475 |      1 | 13475 |00:00:26.63 |   40425 |   4014 |      0 |       |       |
    |         |
|   5 |     TABLE ACCESS BY INDEX ROWID        | | 13475 |      1 | 13475 |00:01:02.46 |   53900 |   7343 |      0 |       |       |
    |         |
|* 6 |      INDEX RANGE SCAN                  || 13475 |      1 | 13475 |00:00:16.80 |   40425 |   2056 |      0 |       |       |
    |         |
|* 7 |    TABLE ACCESS FULL                   | | 13475 |      2 | 13475 |00:00:02.26 |   40425 |      0 |      0 |       |       |
    |         |
|   8 | TABLE ACCESS BY INDEX ROWID           || 94399 |      1 | 94399 |00:06:17.09 |     389K| 32207 |      0 |       |       |
    |         |
|* 9 |   INDEX UNIQUE SCAN                    | | 94399 |      1 | 94399 |00:02:59.79 |     294K| 15488 |      0 |       |       |
    |         |
| 10 | TEMP TABLE TRANSFORMATION             |                             |      1 |        |    170K|00:35:11.08 |    1575K|    195K|   6158 |       |       |
    |         |
| 11 |   LOAD AS SELECT                       |                             |      1 |        |      1 |00:04:49.06 |   53704 | 28653 |    264 |   525K|   525K| 5
25K (0)|              |
| 12 |    PARTITION RANGE ALL                 |                             |      1 | 55430 | 16097 |00:06:26.06 |   53433 | 28651 |      0 |       |       |
    |         |
| 13 |     PARTITION HASH ALL                 |                             |     54 | 55430 | 16097 |00:09:20.69 |   53433 | 28651 |      0 |       |       |
    |         |
|* 14 |      TABLE ACCESS BY LOCAL INDEX ROWID | INV                         |    432 | 55430 | 16097 |00:06:11.42 |   53433 | 28651 |      0 |       |       |
    |         |
|* 15 |       INDEX SKIP SCAN                  | |    432 |    125K| 16097 |00:00:39.90 |    4642 |   4508 |      0 |       |       |
    |         |
| 16 |   TABLE ACCESS BY INDEX ROWID          | |      1 |      2 |    170K|00:30:21.66 |    1522K|    166K|   5894 |       |       |
    |         |
| 17 |    NESTED LOOPS                        |                             |      1 |     97 |    276K|34:55:49.92 |    1470K|    150K|   5894 |       |       |
    |         |
| 18 |     NESTED LOOPS                       |                             |      1 |     55 |    105K|00:22:14.57 |    1128K|    134K|   5894 |       |       |
    |         |
| 19 |      NESTED LOOPS OUTER                |                             |      1 |     52 |    105K|00:16:32.91 |     694K|    105K|   5894 |       |       |
    |         |
|* 20 |       HASH JOIN                        |                             |      1 |     52 |    105K|00:16:19.68 |     402K|    102K|   5894 | 9641K| 2205K| 16
27K (1)|        10240 |
| 21 |        VIEW                            |                             |      1 | 65234 |    105K|00:16:16.46 |     402K|    101K|   4655 |       |       |
    |         |
| 22 |         SORT UNIQUE                    |                             |      1 | 65234 |    105K|00:16:16.46 |     402K|    101K|   4655 | 8724K| 1161K| 61
8K (48)|         9216 |
| 23 |          UNION-ALL                     |                             |      1 |        |    105K|00:14:59.93 |     402K| 97342 |    252 |       |       |
    |         |
| 24 |           NESTED LOOPS OUTER           |                             |      1 | 19975 |    105K|00:14:10.24 |     395K| 94655 |      0 |       |       |
    |         |
| 25 |            NESTED LOOPS                |                             |      1 | 19975 |    105K|00:13:58.47 |     140K| 93616 |      0 |       |       |
    |         |
| 26 |             VIEW                       |                             |      1 | 55430 | 16097 |00:00:00.43 |     270 |    531 |      0 |       |       |
    |         |
| 27 |              TABLE ACCESS FULL         | |      1 | 55430 | 16097 |00:00:00.19 |     270 |    531 |      0 |       |       |
    |         |
|* 28 |             TABLE ACCESS BY INDEX ROWID| | 16097 |      1 |    105K|00:13:59.70 |     140K| 93085 |      0 |       |       |
    |         |
|* 29 |              INDEX RANGE SCAN          |     | 16097 |     10 |    145K|00:00:40.42 |   32685 |   8237 |      0 |       |       |
    |         |
| 30 |            TABLE ACCESS BY INDEX ROWID | |    105K|      1 | 84716 |00:00:16.78 |     254K|   1039 |      0 |       |       |
    |         |
|* 31 |             INDEX UNIQUE SCAN          | |    105K|      1 | 84716 |00:00:13.05 |     169K|    982 |      0 |       |       |
    |         |
| 32 |           NESTED LOOPS                 |                             |      1 | 45259 |      0 |00:00:17.19 |    7336 |   2687 |    252 |       |       |
    |         |
|* 33 |            HASH JOIN RIGHT OUTER       |                             |      1 | 45259 |      0 |00:00:17.19 |    7336 |   2687 |    252 |   884K|   884K| 3
09K (0)|              |
| 34 |             TABLE ACCESS FULL          | |      1 |   1673 |   1677 |00:00:00.01 |      24 |      8 |      0 |       |       |
    |         |
|* 35 |             HASH JOIN                  |                             |      1 | 45259 |      0 |00:00:17.13 |    7310 |   2678 |    252 | 3318K| 1235K| 4
47K (1)|         2048 |
|* 36 |              TABLE ACCESS FULL         | |      1 | 45259 | 49043 |00:00:07.41 |    7043 |   2170 |      0 |       |       |
    |         |
| 37 |              VIEW                      |                             |      1 | 55430 | 16097 |00:00:00.14 |     267 |    256 |      0 |       |       |
    |         |
| 38 |               TABLE ACCESS FULL        ||      1 | 55430 | 16097 |00:00:00.12 |     267 |    256 |      0 |       |       |
    |         |
| 39 |            TABLE ACCESS BY INDEX ROWID | |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |      0 |       |       |
    |         |
|* 40 |             INDEX UNIQUE SCAN          | |      0 |      1 |      0 |00:00:00.01 |       0 |      0 |      0 |       |       |
    |         |
| 41 |        VIEW                            |                             |      1 | 55430 | 16097 |00:00:00.02 |     267 |      0 |      0 |       |       |
    |         |
| 42 |         TABLE ACCESS FULL              | |      1 | 55430 | 16097 |00:00:00.01 |     267 |      0 |      0 |       |       |
    |         |
| 43 |       TABLE ACCESS BY INDEX ROWID      | |    105K|      1 | 93385 |00:00:24.90 |     291K|   2104 |      0 |       |       |
    |         |
|* 44 |        INDEX UNIQUE SCAN               | |    105K|      1 | 93385 |00:00:16.45 |     196K|   1405 |      0 |       |       |
    |         |
| 45 |      TABLE ACCESS BY INDEX ROWID       | |    105K|      1 |    105K|00:05:49.82 |     434K| 29495 |      0 |       |       |
    |         |
|* 46 |       INDEX UNIQUE SCAN                ||    105K|      1 |    105K|00:02:54.37 |     328K| 14644 |      0 |       |       |
    |         |
|* 47 |     INDEX RANGE SCAN                   | |    105K|      2 |    170K|00:03:01.14 |     342K| 15690 |      0 |       |       |
    |         |
Predicate Information (identified by operation id):
   1 - filter(1>=ROWNUM)
   4 - access("XS"."SITEPK"=:B1)
   6 - access("XS"."VENDORPK"="XB"."VENDORPK")
   7 - filter(("XB"."BUYERCOMPANYPK"="CC"."PARENTCOMPANYPK" OR "XB"."BUYERCOMPANYPK"="CC"."CHILDCOMPANYPK"))
   9 - access("INVOICEPK"=:B1 AND "LINENUM"=:B2)
14 - filter(("IH"."INVOICEORIGIN"='APP' AND "IH"."PO_PK" IS NULL AND "IH"."ISPOSTED"='Y'))
15 - access("IH"."PAYPK"=3914297352 AND "IH"."POSTDATE">=1338508800000 AND "IH"."POSTDATE"<1341014400000)
       filter(("IH"."POSTDATE">=1338508800000 AND "IH"."PAYPK"=3914297352 AND "IH"."POSTDATE"<1341014400000))
20 - access("NEWVIEW"."PRIMARYKEY"="TAB"."INVOICEPK")
28 - filter(TO_NUMBER("RAT"."AUDITTYPE")<2)
29 - access("INNERTAB1"."INVOICEPK"="RAT"."INVOICEPK")
       filter("RAT"."INVOICEPK" IS NOT NULL)
31 - access("RAT"."USERPK"="UR"."USERPK")
33 - access("RA"."QUEUEPK"="Q"."QUEUEPK")
35 - access("INNERTAB2"."INVOICEPK"="RA"."INVOICEPK")
36 - filter(("RA"."INVOICEPK" IS NOT NULL AND "RA"."RECEIVERPK" IS NOT NULL))
40 - access("RA"."RECEIVERPK"="UR"."USERPK")
44 - access("TAB"."ENTEREDBY"="UR"."USERPK")
46 - access("TAB"."INVOICEPK"="ISUM"."INVOICEPK")
47 - access("IDD"."INVOICEPK"="TAB"."INVOICEPK")
87 rows selected.
Elapsed: 00:00:04.10
SQL>Edited by: 930254 on Aug 7, 2012 9:33 AM

How to create a client jar file???

How do I create a client jar file for the client program? Please see my attached
ejb-jar.xml. I compiled the my EJB and deployed it successfully. However, I couldn't
find the client jar anywhere. I use the weblogic admin console DD editor, I can
see that the edit field has been populated with my client jar file name defined
in the ejb-jar.xml. However, I searched entire system, I could not locate this
jar anywhere.
How do I do that? If someone knows how to do it, please let me know. Thank you
very much.
[ejb-jar.xml]

How do I create a client jar file for the client program? Please see my attached
ejb-jar.xml. I compiled the my EJB and deployed it successfully. However, I couldn't
find the client jar anywhere. I use the weblogic admin console DD editor, I can
see that the edit field has been populated with my client jar file name defined
in the ejb-jar.xml. However, I searched entire system, I could not locate this
jar anywhere.
How do I do that? If someone knows how to do it, please let me know. Thank you
very much.
[ejb-jar.xml]

Start/stop trace between removing trace files

Hi,
I have the following problem.
I put some Oracle session on trace (I use sys.dbms_support.start_trace_in_session). Then I make some test. I close the trace (I use sys.dbms_support.stop_trace_in_session). I analyze the trace files (tkprof) and I make some tuning.
Then I'd like to remove the trace files (*.trc) and start the trace again for checking if the tuning was efficient.
It seems not possible. Event if I start the trace again I can't see and trc files.
In order to solve the problem I must to bounce the application I want to trace (so that the Oracle sessions start again).
Any hint?
Thanks, Max

In that case, you will need to parse the trace file to identify the start and stop of the trace. Below is an example from a 10gR2 trace. Notice the line starting with the *** that contains the date. It comes between the stop of the trace and the start of another trace. You cannot use this line alone to signify the start of a trace as similar lines are emitted in the trace file when there are long delays between writes to the file.
=====================
PARSING IN CURSOR #2 len=55 dep=0 uid=0 oct=42 lid=0 tim=330900979 hv=2217940283 ad='2fdd5ef8'
alter session set events '10046 trace name context off'
END OF STMT
PARSE #2:c=0,e=52,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=330900976
BINDS #2:
EXEC #2:c=0,e=85,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=330901247
*** 2007-02-20 11:55:55.026
=====================
PARSING IN CURSOR #4 len=69 dep=0 uid=0 oct=42 lid=0 tim=386816222 hv=3164292706 ad='2fdd6980'
alter session set events '10046 trace name context forever, level 12'
END OF STMT
EXEC #4:c=0,e=60,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=386816218
WAIT #4: nam='SQL*Net message to client' ela= 2 driver id=1111838976 #bytes=1 p3=0 obj#=258 tim=386816593
WAIT #4: nam='SQL*Net message from client' ela= 105 driver id=1111838976 #bytes=1 p3=0 obj#=258 tim=386816748
=====================

Read the results shown in the trace files

Hi,
I have a question,
In oracle 10g or 11g, How can I interpret the results shown in the trace files?
ok I explain more ... when I enable the trace sql session , a trace file is created under user dump!
What 's the meaning of :
*1- PARSING IN CURSOR*
*2- tim= is it in Microseconds? Timestamp ? How can I convert it in seconds?*
*3- STAT*
*4- CLOSE*
*5- hv=*
*6- tim=*
*7- lid=*
*8-dep=*
PARSING IN CURSOR #2 len=104 dep=0 uid=0 oct=2 lid=0 tim=13651992547 hv=3760112805 ad='284c0e6c' sqlid='6shmgvbh1xj55'
INSERT INTO employee(ID,NAME,department_id, DEPARTMENT_SUB_ID) VALUES(10002, 'employee', 12, 0)
END OF STMT
PARSE #2:c=93750,e=102539,p=24,cr=471,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=13651992547
EXEC #2:c=0,e=0,p=5,cr=1,cu=7,mis=0,r=1,dep=0,og=1,plh=0,tim=13651992547
STAT #2 id=1 cnt=0 pid=0 pos=1 obj=0 op='LOAD TABLE CONVENTIONAL (cr=1 pr=5 pw=0 time=0 us)'
CLOSE #2:c=0,e=0,dep=0,type=0,tim=13652013059Thnak you a lot guys,
Smith

794130 wrote:
Thank you,
Sorry, I am new in Oracle and I want to get things really clear (something that is diifficult I think)
When an end user submit a query, one user process communicates the query to a server process.
The server process analyse the syntax and the symentic of the query, this known as the parse process.
The syntax of the query and the tables, columns are verified against the database buffer cache.
One PGA is allocated to store the query.
The server process read from the datafile and gets the results and store it into the shared pool.
The result is then back to the user process and then to the end user
Is it correct ?
Thank you all,
SSome of the above concepts are close. There is a nice description in the Oracle Database Concepts guide of what happens during the processing of a SQL statement (see the stages listed in the documentation):
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/sqlplsql.htm#sthref3460
It is probably a good idea to distinguish between a hard parse, a soft parse, and a session cursor cache hit:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/glossary.htm#sthref1591
The database buffer cache is not used to verify the validity of SQL statements, but instead as a means to reduce the number of disk accesses that are required to return a query result to a client computer.
One or more pieces of PGA memory may be used simultaneously while processing a SQL statement. I have a couple of blog articles that show multiple PGA memory allocations in use at the same time.
The server process may not need to access a physical data file to return the query results to a client computer, depending of course on the current contents of the buffer cache.
I recommend that you wait a while before trying to work with 10046 trace files. Right now the contents are probably providing too much detail for you, although I definitely recommend that you return to working with 10046 trace files at a later time. A good starting point is either the free Database Concepts Guide:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220.pdf
or Tom Kyte's "Expert Oracle Database Architecture: Oracle Database Programming 9i, 10g, and 11g Techniques and Solutions, Second Edition" book. You can read my review of that book on Amazon's website:
http://www.amazon.com/Expert-Oracle-Database-Architecture-Programming/dp/1430229462/ref=dp_ob_title_bk
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.

Listener trace file: Winsock 54 errors

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

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

Shared server trace file

Hi All,
Our production db is 10.2.0.3 with 2 nodes RAC in MS 2003 window servers. I am wondering what kind of information that Oracle capture in the shared server trace file (file name looks like instance_s001_3333.trc) . When I open some of these files I always see one query always there along with the messages like:
WAIT #8: nam='gc cr block 2-way' ela= 1222 p1=65 p2=49677 p3=1 obj#=69689 tim=4137263779
WAIT #8: nam='gc cr block 2-way' ela= 593 p1=65 p2=50863 p3=1 obj#=69689 tim=4137265531
WAIT #8: nam='gc cr block 2-way' ela= 592 p1=65 p2=50879 p3=1 obj#=69689 tim=4137266700
Should we need to tune this query to make it disappear in the shared server trace files? What are the conditions to trigger Oracle put this query into trace file?
Thank you very much in advance for your support!
Shirley

These trace files are very likely generated by some trace statements originating from client programs connected to shared server processes such as client application processes, SQL*Plus, SQL Developer, OEM, TOAD, etc.
Is your client application instrumented ?
Do some people analyze performance problems on the database side ?
The triggering statements may be some ALTER SESSION statements or package calls like DBMS_MONITOR in 10g or other
(see examples in http://www.oracle.com/technology/oramag/oracle/04-jan/o14tech_perf.html).
You should also check that instances are not configured with instance level tracing:
show parameter sql_traceYou can also check current database sessions sql tracing status with:
select sid, serial, program, sql_trace from v$session where username is not null;

Ora-00604 error while taking tkprof of a trace file

Sorry i am giving the full erro but omitting exact table names
Hi ,
I have an error while taking tkprof of a trace file.
I gave the following command ---
tkprof <source.trc> <file.prc> sys=no sort=exeela,fchela,prsela explain= /
error is --
Error in create table of EXPLAIN PLAN table : unix_session_user.prof$paln_table
ORA-00604: error occurred at recursive SQL level 1
ORA-20001: Step-6:DDL
Event Security. You are not permitted to perform the requested structural
changes to PROF (TABLE)
Event triggered : CREATE
ora_login_user
(session_user) : unix_session_user(dummy)
Search : select count(*) from
tabl(dummy table name) where obj_name like '%\%%' escape '\' and obj_type =
'TABLE' and obj_type = 'USER' and ( event_CREATE = 'Y' or status =
'Override')
ORA-06512: at line 162
ORA-06510: PL/SQL: unhandled
user-defined exception
EXPLAIN PLAN option disabled.
i searched for the error and in oracle forum i found a solution .. http://forums.oracle.com/forums/thread.jspa?threadID=844287&tstart=0
but after giving the table option it is giving the same error
tkprof <source.trc> <file.prc> sys=no sort=exeela,fchela,prsela table=old_schema.plan_table explain= /
it again gave the same error.
In both two cases it gives elapsed time results,library cache missing etc but before giving this it throws ORA-00604 error as stated above
then i again correct the tkprof statement ..
tkprof <source.trc> <file.prc> sys=no sort=exeela,fchela,prsela table=new_schema.plan_table explain= /
say this schema name here i used is dummy schema name.
My question is did this error came as we had not sufficient previlages in the old_schema but that previleges we have in new_schema?
My databse version is 9.2.0.4.0
Thanks in advance
Edited by: bp on Feb 3, 2009 11:36 PM
Edited by: bp on Feb 3, 2009 11:40 PM

Please post here full error message, there should be lines with ORA-00604 and then some other ORA as well.
And are there any trace files generated during this error?
And as You can see from error description, probably You will have to contact with Oracle support in order to solve this case:
oerr ora 00604
00604, 00000, "error occurred at recursive SQL level %s"
// *Cause: An error occurred while processing a recursive SQL statement
// (a statement applying to internal dictionary tables).
// *Action: If the situation described in the next error on the stack
// can be corrected, do so; otherwise contact Oracle Support.

Location of client trace files sync'ed to the middleware

Similar Messages

Maybe you are looking for