Help on tkprof output

Hi Gurus, Could someone shed some light on the following tkprof output. To get 0 record it is aking more than 11 seconds. Also I see huge difference between CPU time and elapsed time even though the system is not so busy(It is a test machine. very low load on it). If you say it is waiting

Re: Help on tkprof output

- Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 7:19 AM Hi Gurus, Could someone shed some light on the following tkprof output. To get 0 record it is aking more than 11 seconds. Also I see huge difference between

RE: Help on tkprof output

- [EMAIL PROTECTED] Sent: Wednesday, 3 December 2003 9:49 To: Multiple recipients of list ORACLE-L Hi Gurus, Could someone shed some light on the following tkprof output. To get 0 record it is aking more than 11 seconds. Also I see huge difference between CPU time and elapsed time even though

Re: Help on tkprof output

I'm not so sure. The query returns no rows and the second to last nested loop already has only 1 row in the resultset. I'd try to determine what the most limiting condition is - or set of conditions - those that eliminate most rows early on and make sure the optimizer starts with that. I could

RE: Help on tkprof output

it to and your disk IO would go down along with your elapsed time. Hth Ian -Original Message- [EMAIL PROTECTED] Sent: Wednesday, 3 December 2003 9:49 To: Multiple recipients of list ORACLE-L Hi Gurus, Could someone shed some light on the following tkprof output. To get 0 record it is aking

RE: Help on tkprof output

: Sent by: Subject: RE: Help on tkprof output [EMAIL PROTECTED

Re: tkprof output

recursive) so this time could simply be the cost of running your application code. Unfortunately the tkprof output doesn't quote the recursive depth of the SQL - however if you identify possible suspects, you can check back in the raw trace file for lines like: PARSING IN CURSOR

Re: tkprof output

recursive, rather than SYS recursive) so this time could simply be the cost of running your application code. Unfortunately the tkprof output doesn't quote the recursive depth of the SQL - however if you identify possible suspects, you can check back in the raw trace file for lines like

Re: tkprof output

could simply be the cost of running your application code. Unfortunately the tkprof output doesn't quote the recursive depth of the SQL - however if you identify possible suspects, you can check back in the raw trace file for lines like: PARSING IN CURSOR #N

RE: tkprof output

within a pl/sql block is recursive SQL (user recursive, rather than SYS recursive) so this time could simply be the cost of running your application code. Unfortunately the tkprof output doesn't quote the recursive depth of the SQL - however if you identify possible suspects, you can

Re: tkprof output

Repeat but changing the 12 to a zero should work. You will find, however, that any cursor that has not closed when you stop tracing will not dump its 'STAT' lines (including execution plan) to the trace file. Regards Jonathan Lewis http://www.jlcomp.demon.co.uk Now available One-day

Re: tkprof output

of list ORACLE-L [EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 2:54 PM Any SQL within a pl/sql block is recursive SQL (user recursive, rather than SYS recursive) so this time could simply be the cost of running your application code. Unfortunately the tkprof output doesn't quote

Re: tkprof output

The examples you have given are SYS-recursive, The call to cdef$ is Oracle looking for some information about constraints (one possibility is that you keep breaking a PK or UK constraint and Oracle has to keep looking up the name of the constraint because it doesn't cache constraint names). The

RE: tkprof output

could simply be the cost of running your application code. Unfortunately the tkprof output doesn't quote the recursive depth of the SQL - however if you identify possible suspects, you can check back in the raw trace file for lines like: PARSING IN CURSOR #N there will be a bit in the line

Re: tkprof output

Thanks Jonathan for the information . Let me go through raw -trace file once more to get info . Everytime I go through it I find something interesting . -ak - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 8:54 AM The

tkprof output

I am running tkprof on event 10046 output and I see at the end . elapsed time of 18 secs in recursive calls thats what surprises me . Do you know what I should look at next and what can be done to reduce these timings Thanks, -ak OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS call count

Re: tkprof output

Run tkprof with SYS = YES option and find recursive calls that contribute to this time. Igor Neyman, OCP DBA [EMAIL PROTECTED] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 2:29 PM I am running tkprof on event 10046

Re: tkprof output

of list ORACLE-L [EMAIL PROTECTED] cc: Subject:tkprof output I am running tkprof on event 10046 output and I see at the end . elapsed time of 18 secs in recursive calls thats what surprises me . Do you know what I should look at next and what can be done to reduce these timings

Re: tkprof output

Any SQL within a pl/sql block is recursive SQL (user recursive, rather than SYS recursive) so this time could simply be the cost of running your application code. Unfortunately the tkprof output doesn't quote the recursive depth of the SQL - however if you identify possible suspects, you can

RE: Interpretation of TKPROF output

Wow! This is a completely new view on the TKPROF. So far, I've been inclined to look upon the TKPROF output as on the holly scripture. Mentioning the tkprof bugs is like discovering Kumran rolls! -Original Message- From: Cary Millsap [mailto:[EMAIL PROTECTED]] Sent: Monday, October

Interpretation of TKPROF output

I am running tkprof on some trace files with the following options: (Oracle 8.1.7) explain=user/password sort=exeqry,fchqry,execu,fchcu Output after each query includes the following two tables: Rows Row Source Operation --- --- 36

RE: Interpretation of TKPROF output

Hello; Somebody knows how to connect to a Oracle DB, In a Solaris 8 Server, and insert data With Visual Basic, through internet? Thank you. Francisco Murillo -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Francisco Murillo Montoya INET: [EMAIL PROTECTED] Fat

Re: Interpretation of TKPROF output

Peter, Row Source Operation is what Oracle actually did, or, at least what was recorded in the trace file. Execution Plan is what TkProf did in response to you specifying explain= option. They can differ if things changed from the time the trace was done to the time the explain was executed.

Re: Interpretation of TKPROF output

: Sent by: Subject: Interpretation of TKPROF output [EMAIL PROTECTED

RE: Interpretation of TKPROF output

Actually two things can cause differences between tkprof output and explain plan output: 1. Schema changes between when the trace output was collected and when the tkprof was executed. 2. tkprof bugs. Tkprof often produces incorrect execution plans from the STAT lines in the trace file. You can

Re: strange tkprof output for SQLs - II

Hello all, Thanks to Bjorn Engsig of MiracleAS.dk Also, Here is the answer from Oracle support. I wanted to share with you: # Begin tkprof substracts the child statistics from parent ones. . the trace file is missing the line for PARSE call of the blsql block - as it's missing it's

Re: strange tkprof output for SQLs - II

Hello Mogens, I saw this problem whether or not shared pool was flushed for PL/SQLs. Here are my observations for SQLs!!! and PL/SQLs: - Enabling sql trace from current session: When a cursor is closed after their child recursive statements, their recursive statistics parsed after the statement

strange tkprof output for SQLs - II

Hello, I did 2 tests for PL/SQL and SQL statements. This is the test for SQL. Here are the steps: SQL alter session flush shared_pool; SQL alter session set sql_trace=true; SQL insert into test select * from test; SQL alter session set sql_trace=false; FROM DICTIONARY: SVRMGR select

strange tkprof output for PL/SQLs

for this parent PL/SQL statement. This is true for both enabling sql_trace from current session or other session. Here are the tkprof output for parent PL/SQL and its child SQL statement. Child recursive statement called from parent PL/SQL statement: INSERT INTO DOUG VALUES ( :b1,:b2 ) call

Re: strange tkprof output for SQLs - II

Danisment - isn't it always alter system flush shard_pool? I thought so... Danisment Gazi Unal (Unal Bilisim) wrote: Hello, I did 2 tests for PL/SQL and SQL statements. This is the test for SQL. Here are the steps: SQL alter session flush shared_pool; SQL alter session set sql_trace=true;

Re: Help with Parsing and TKPROF output

that long. Thanks, Bjørn. On Wednesday 06 March 2002 04:53, you wrote: Hi All, I have an online program that is timing out and when I trace it I get the following at the bottom of my tkprof output. It's easy to see why the transaction is running slow, because of all the parsing. But the program

RE: Help with Parsing and TKPROF output

. On Wednesday 06 March 2002 04:53, you wrote: Hi All, I have an online program that is timing out and when I trace it I get the following at the bottom of my tkprof output. It's easy to see why the transaction is running slow, because of all the parsing. But the program and all called modules

Help with Parsing and TKPROF output

Hi All, I have an online program that is timing out and when I trace it I get the following at the bottom of my tkprof output. Its easy to see why the transaction is running slow, because of all the parsing. But the program and all called modules are compiled with max_opencursors = 75

RE: Help with Parsing and TKPROF output

it I get the following at the bottom of my tkprof output. It's easy to see why the transaction is running slow, because of all the parsing. But the program and all called modules are compiled with max_opencursors = 75 to stop the parsing problem, though it doesn't seem to be helping here

Tkprof output

Hi Listers, I got the following statement in the tkprof output file : update EMP set ENAME=:V001,EMPNO=:V002 where rowid = :V003 I'm just wondering how to get the value of that variables (instead of :V001, :V002 and :V003). Is there a way to do that ? Thanks. Aldi

RE: Tkprof output

Set you 10046 trace at level 4 or 12, and then check the trace file. Paul -Original Message- Sent: Friday, February 22, 2002 3:53 PM To: Multiple recipients of list ORACLE-L Hi Listers, I got the following statement in the tkprof output file : update EMP set ENAME=:V001,EMPNO=:V002

RE: Tkprof output

recipients of list ORACLE-L Hi Listers, I got the following statement in the tkprof output file : update EMP set ENAME=:V001,EMPNO=:V002 where rowid = :V003 I'm just wondering how to get the value of that variables (instead of :V001, :V002 and :V003). Is there a way to do that ? Thanks. Aldi

RE: Tkprof output

ORACLE-L Subject: RE: Tkprof output Paul (or anyone) - Is there a way to set the level within the session as: alter session set sql_trace = true Or do I have to start the session, start a SQLPLUS session, find the session_id and run the procedure to set

RE: Tkprof output

Title: RE: Tkprof output A huge thanks for all those who took the time out to respond to my problem. The query ran to completion yesterday and (as I said to Lisa) I was later told that I was not to worry as it was a one off migration (well that only wasted about 1- 2 hours of my time

Tkprof output

Apologies for the length of the mail. This query is running for a mad amount of time, anyone any ideas. Code and tkprof out put shown below. Huge TIA Lee (who must learn more about such things !!!) DECLARE CURSOR TEMP_CDS ISSELECT ACXIOM_CUSTOMER_KEY, VERSION_NO,

RE: Tkprof output

Title: RE: Tkprof output Lee, This query seems suspect UPDATE VM_LIVE.SINGLE_CUSTOMER_HISTORY SCH SET VISIBLE=1 WHERE ACXIOM_CUSTOMER_KEY = :b1 AND VERSION_NO = :b2 because of this call count cpu elapsed disk query current rows

RE: Tkprof output

Are you on 8i? Then you can use BULK binding which will definitely give you some speed. IF you need example ... let me know. Raj __ Rajendra Jamadagni MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any opinion expressed

RE: Tkprof output

Title: RE: Tkprof output Also note the very high"query" number (i.e. buffers gotten for consistent read). That could account for a lot of the i/o, which is the proximate cause of the lng elapsed time. From the (to use one of Lisa's favorite terms) doco (for 9i): Read Consist

RE: Tkprof output

) 322-5744 Fax: (707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message-From: Robertson Lee - lerobe [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 30, 2001 11:56 AMTo: Multiple recipients of list ORACLE-LSubject: Tkprof output

RE: Full Table Scan and TKPROF Output

Hi Ethan, If selectivity is that low, try using a bitmapped index. HTH, Remco -Oorspronkelijk bericht- Van: Post, Ethan [mailto:[EMAIL PROTECTED]] Verzonden: vrijdag 8 juni 2001 2:26 Aan: Multiple recipients of list ORACLE-L Onderwerp: Full Table Scan and TKPROF Output My theory

Full Table Scan and TKPROF Output

My theory...We are running J.D. Edwards OneWorld. OneWorld allows the CNC (code word for OneWorld admin) to configure a number of job queues that check a table (the F986110) for new jobs that need to be processed. Each of these processes and occasionally a few more update, delete and select from