Repository Size / RPCLEAN elapsed time

I'm curious about people's repository size and their corresponding
rpclean elapsed time. Without other sizes and times to compare to,
there's no way of me knowing if our current environment is as
efficient as it can be.
If you don't mind, please send me your repository size and elapsed
time of your rpclean. (also send the number number of objects in the
rpclean stats if you can). At this point, I'm not interested in the
quick clean, just a full clean. Also include your platform that
you're running on. Please send information for all repositories that
you have.
Thanks.

Randy Wilkinson wrote:
>
I'm curious about people's repository size and their corresponding
rpclean elapsed time. Without other sizes and times to compare to,
there's no way of me knowing if our current environment is as
efficient as it can be.The best way to keep your environment efficient, is to do cleans frequently.
If you have heavy development in your repos, do a quick clean every night and
a full clean on the weekend.
In addition, you should create a new repos from time to time. We use gemstone
and we have been told the repos degrade over time even when you keep it clean.
We always get great performance out of a new repos with plenty of code in it. I can
tell when our repos has degraded and it is time for a new one. It will get slow.
You can use rpcopy or create a new repos and import your code.
You really need to be pro-active with repository maintenance. You can work yourself
into a corner if your not cleaning or the cleans are failing (you have to check to make
sure the cleans are successful).
Another way to get better repos performance is with parallel disk I/O. Keep you
repositories on different drives (do not access them across NFS). You can create
symbolic links to the files.
Robert Crisafulli
AMISYS
301-838-7540
>
If you don't mind, please send me your repository size and elapsed
time of your rpclean. (also send the number number of objects in the
rpclean stats if you can). At this point, I'm not interested in the
quick clean, just a full clean. Also include your platform that
you're running on. Please send information for all repositories that
you have.
Thanks.

Similar Messages

Again..What elapse time you are expecting for this query..

Hi Again want to confirm with you Oracle gurus ...
Does following plsql code really takes time in mins
I do not used to deal with clob data so can not say why there is so delay..
-> TableA has 3000 rows with text_data clob column holding large clob data...
-> TableB has some thing which i wnat to append in text_data column..
-> Trying to minimize elapse time..
declare
cursor c1 is select object_id from TableA where object_type = 'STDTEXT' and rownum < 1000;
TYPE v_object_id_t is table of TableA.object_id%type index by binary_integer;
v_object_id v_object_id_t;
cursor c2(p_object_id TableA.object_id%type) is
select to_clob('<IMG "MFI_7579(@CONTROL=' || ref_id || ',REF_ID=' || ref_id || ').@UDV">' || substr('abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwx',1, round(to_char(systimestamp,'FF2')/2)-1)) temp_data
from TableB where object_id = p_object_id;
TYPE v_text_data_t is table of TableA.text_data%type index by binary_integer;
v_text_data v_text_data_t;
v_temp clob ;
r2 c2%rowtype;
begin
open c1;
loop
FETCH c1 BULK COLLECT INTO v_object_id ;
for i in 1..v_object_id.count loop
dbms_lob.createtemporary(v_temp,TRUE);
open c2(v_object_id(i));
loop
fetch c2 into r2;
exit when c2%NOTFOUND;
dbms_lob.append(v_temp,r2.temp_data);
end loop;
close c2;
v_text_data(i) := '';
v_text_data(i) := v_temp;
-- DBMS_OUTPUT.PUT_LINE (length(v_text_data(i)));
dbms_lob.freetemporary(v_temp);
end loop;
forall counter in 1..v_text_data.count
update TableA
set text_data = concat(text_data,v_text_data(counter))
where object_id = v_object_id(counter);
DBMS_OUTPUT.PUT_LINE ('Update performed!');
commit;
EXIT WHEN c1%NOTFOUND;
end loop;
close c1;
exception
when others then
DBMS_OUTPUT.PUT_LINE ('Update not performed!');
end;
-- Last elapse time 333 sec for 8k text_data data if i use 16k block size
-- Last elapse time 1503 sec for 2k text_data data if i use 8k block size
->> Am I going rigth way???
Please Help...
Cheers :)
Rushang Kansara
Message was edited by:
Rushang Kansara
Message was edited by:
Rushang Kansara

Here is an example that shows SQL and PL/SQL methods. Note that the DBMS_LOB.WriteAppend() call is the wrong call to use (as I did above. The correct call to use (for appending CLOB to a CLOB) is DBMS_LOB.Append() (as shown below).
SQL> create table my_docs
2 (
3 doc_id number,
4 doc CLOB
5 )
6 /
Table created.
SQL>
SQL> create sequence id
2 start with 1
3 increment by 1
4 nomaxvalue
5 /
Sequence created.
SQL>
SQL>
SQL> create or replace procedure AddXML( rowCount number DEFAULT 1000 ) is
2 cursor curXML is
3 select
4 XMLElement( "ORA_OBJECT",
5 XMLForest(
6 object_id as "ID",
7 owner as "OWNER",
8 object_type as "TYPE",
9 object_name as "NAME"
10 )
11 ) as "XML_DATA"
12 from all_objects
13 where rownum <= rowCount;
14
15 tmpClob CLOB;
16 xml XMLType;
17 lineCount number := 0;
18 docID number;
19 begin
20 DBMS_LOB.CreateTemporary( tmpClob, TRUE );
21
22 open curXML;
23 loop
24 fetch curXML into xml;
25 exit when curXML%NOTFOUND;
26
27 lineCount := lineCount + 1;
28
29 DBMS_LOB.Append(
30 tmpClob,
31 xml.GetCLOBVal() -- add the XML CLOB to our temp CLOB
32 );
33 end loop;
34 close curXML;
35
36 insert
37 into my_docs
38 ( doc_id, doc )
39 values
40 ( id.NextVal, tmpClob )
41 returning doc_id into docID;
42
43 commit;
44
45 DBMS_LOB.FreeTemporary( tmpClob );
46 DBMS_OUTPUT.put_line( lineCount||' XML object(s) were appended to document '||docID );
47 end;
48 /
Procedure created.
SQL> show errors
No errors.
SQL>
SQL> -- add 3 CLOBs of varying sizes
SQL> exec AddXML
1000 XML object(s) were appended to document 1
PL/SQL procedure successfully completed.
SQL> exec AddXML(100)
100 XML object(s) were appended to document 2
PL/SQL procedure successfully completed.
SQL> exec AddXML(500)
500 XML object(s) were appended to document 3
PL/SQL procedure successfully completed.
SQL>
SQL> -- what are the sizes of the CLOBs and the total size?
SQL> select
2 doc_id,
3 SUM( ROUND( LENGTH(doc)/1024 ) ) as "KB_SIZE"
4 from my_docs
5 group by
6 ROLLUP(doc_id)
7 /
DOC_ID KB_SIZE
1 98
2 9
3 47
154
SQL>
SQL> -- add an empty CLOB
SQL> insert into my_docs values( 0, NULL );
1 row created.
SQL> commit;
Commit complete.
SQL>
SQL> -- note that the new CLOB is zero KB in size
SQL> select
2 doc_id,
3 ROUND( LENGTH(doc)/1024 ) as "KB_SIZE"
4 from my_docs
5 /
DOC_ID KB_SIZE
1 98
2 9
3 47
0
SQL>
SQL> -- we add document 1 to 3 to document 0 using SQL
SQL> update my_docs
2 set doc = doc || (select t.doc from my_docs t where t.doc_id = 1 )
3 where doc_id = 0;
1 row updated.
SQL>
SQL> update my_docs
2 set doc = doc || (select t.doc from my_docs t where t.doc_id = 2 )
3 where doc_id = 0;
1 row updated.
SQL>
SQL>
SQL> update my_docs
2 set doc = doc || (select t.doc from my_docs t where t.doc_id = 3 )
3 where doc_id = 0;
1 row updated.
SQL>
SQL> commit;
Commit complete.
SQL>
SQL> -- what are the sizes now?
SQL> select
2 doc_id,
3 ROUND( LENGTH(doc)/1024 ) as "KB_SIZE"
4 from my_docs
5 /
DOC_ID KB_SIZE
1 98
2 9
3 47
0 154
SQL>
SQL>
SQL> -- we do the adds again, but time time using a PL/SQL procedure to do it
SQL> declare
2 cursor c is
3 select doc from my_docs where doc_id in (1,2,3);
4
5 updateClob CLOB;
6 appendClob CLOB;
7 begin
8 -- we must lock the row for update and then we can write directly
9 -- to that row's CLOB locator (without using the UPDATE SQL statement)
10 select
11 doc into updateClob
12 from my_docs
13 where doc_id = 0
14 for update;
15
16
17 open c;
18 loop
19 fetch c into appendClob;
20 exit when c%NOTFOUND;
21
22 -- we append the CLOBs to document 0
23 DBMS_LOB.Append( updateClob, appendClob );
24 end loop;
25
26 -- .. and commit the changes to document 0's CLOB locator
27 commit;
28 end;
29 /
PL/SQL procedure successfully completed.
SQL>
SQL>
SQL> -- what are the sizes now?
SQL> select
2 doc_id,
3 ROUND( LENGTH(doc)/1024 ) as "KB_SIZE"
4 from my_docs
5 /
DOC_ID KB_SIZE
1 98
2 9
3 47
0 308
SQL>

Error While Creating Repository Content at the time of Installation

Hi Guys,
When i'm trying to create repository content at the time of informatica installation i'm getting error "Cannot create repository content or restore".
I'hve attached the log file below
ONE')
INSERT INTO REP_CARD_TYPE VALUES (4, 'MANY TO MANY')
CREATE TABLE REP_TARG_TYPE
TARGET_TYPE integer,
TYPE_NAME varchar(20)
INSERT INTO REP_TARG_TYPE VALUES (0, 'NONE')
INSERT INTO REP_TARG_TYPE VALUES (1, 'DIMENSION')
INSERT INTO REP_TARG_TYPE VALUES (2, 'FACT')
CREATE VIEW REP_DATABASE_DEFS AS SELECT
DISTINCT
DBDNAM DATABASE_NAME,
SRCNAM DEF_SOURCE,
SUBJ_NAME SUBJECT_AREA,
NULL VERSION_ID,
OPB_DBD.VERSION_NUMBER DATABASE_VERSION_NUMBER
FROM OPB_DBD, OPB_SUBJECT, OPB_SRC
WHERE OPB_DBD.SUBJ_ID = OPB_SUBJECT.SUBJ_ID AND
OPB_SRC.DBDID = OPB_DBD.DBDID AND
OPB_SRC.VERSION_NUMBER = OPB_DBD.VERSION_NUMBER AND
OPB_SRC.IS_VISIBLE = 1
ORA-01031: insufficient privileges
Database driver error...
Function Name : executeDirect
SQL Stmt : CREATE VIEW REP_DATABASE_DEFS AS SELECT
DISTINCT
DBDNAM DATABASE_NAME,
SRCNAM DEF_SOURCE,
SUBJ_NAME SUBJECT_AREA,
NULL VERSION_ID,
OPB_DBD.VERSION_NUMBER DATABASE_VERSION_NUMBER
FROM OPB_DBD, OPB_SUBJECT, OPB_SRC
WHERE OPB_DBD.SUBJ_ID = OPB_SUBJECT.SUBJ_ID AND
OPB_SRC.DBDID = OPB_DBD.DBDID AND
OPB_SRC.VERSION_NUMBER = OPB_DBD.VERSION_NUMBER AND
OPB_SRC.IS_VISIBLE = 1
Oracle Fatal Error
Database driver error...
Function Name : ExecuteDirect
Oracle Fatal Error
Error occurred while creating the repository
An error has occurred while creating contents. Dropping repository tables...
Create Contents operation on repository [Oracle_BI_DW_Base] ended at 08/10/2009 11:50:49. Elapsed time is 0:00:10.
[[REP_57106] Repository operation error. See repository service log for detailed information.]
Failed to execute create.
Completed at Mon Aug 10 11:50:49 2009
Error:
ExitCode: 1
Installation Complete
======================

Hi Rama,
You don't need to give your etl_ram user a dba role.
Please refer to the Oracle® Business Intelligence Applications - Installation Guide for Informatica PowerCenter Users, especially to chapter +4.4.1 Create Databases for Oracle BI Applications and Informatica PowerCenter Components+
Quoting:
Make sure that the Oracle Business Analytics Warehouse instance is granted the SSE_ROLE. For more information, see Section 4.4.1.1, "How to Create the SSE Role."
This role would typically get more privileges than just CONNECT and RESOURCE.
Hope it helps,
Michal

File adapter - Write - Elapsed Time based batching not working.

We are creating an asynchronous BPEL process that creates a file every 2 mins with the messages the BPEL process received in the last 2 minutes. We are using a file adapter with only "elapsed time" set to 2 minutes (Number of Messages and File size disabled) . If we deploy this into BPEL console and use bpel console's stress test feature, it doesnt create any file at all. If we use a file adapter based on Number of messages, it works fine. Can any one of you suggest what could be the problem ?

Unfortunately, this is documented bahaviour (solution/workaround anyone?!):
Elapsed Time Exceeds:
Specify a time which, when exceeded, causes a new outgoing file to be created.
Note:
The Elapsed Time Exceeds batching criteria is evaluated and a new outgoing file is created, only when an invocation happens.
For example, if you specify that elapsed time exceeds 15 seconds, then the first message that is received is not written out, even after 15 seconds, as batching conditions are not valid. If a second message is received, then batching conditions become valid for the first one, and an output file is created when the elapsed time exceeds 15 seconds.

Query Execution/Elapsed Time and Oracle Data Blocks

Hi,
I have created 3 tables with one column only. As an example Table 1 below:
SQL> create table T1 ( x char(2000));
So 3 tables are created in this way i.e. T1,T2 and T3.
T1 = in the default database tablespace of 8k (11g v11.1.0.6.0 - Production) (O.S=Windows).
T2 = I created in a Tablespace with Blocksize 16k.
T3 = I created in a Tablespace with Blocksize 4k. In the same Instance.
Each table has approx. 500 rows (So, table sizes are same in all the cases to test Query execution time ). As these 3 tables are created under different data block sizes so the ALLOCATED no. of data blocks are different in all cases.
T1 = 8k = 256 Blocks = 00:00:04.76 (query execution time/elapsed time)
T2 = 16k=121 Blocks = 00:00:04.64
T3 = 4k = 490 Blocks = 00:00:04.91
Table Access is FULL i.e. I have used select * from table_name; in all 3 cases. No Index nothing.
My Question is why query execution time is nearly the same in all 3 cases because Oracle has to read all the data blocks in each case to fetch the records and there is a much difference in the allocated no. of blocks ???
In 4k block size example, Oracle has to read just 121 blocks and it's taking nearly the same time as it's taking to read 490 blocks???
This is just 1 example of different data blocks. I have around 40 tables in each block size tablespace and the result are nearly the same. It's very strange for me because there is a much difference in the no. of allocated blocks but execution time is almost the same, only difference in milliseconds.
I'll highly appreciate the expert opinions.
Bundle of thanks in advance.
Best Regards,

Hi Chris,
No I'm not using separate databases, it's 8k database with non-standard blocksizes of 16k and 4k.
Actually I wanted to test the Elapsed time of these 3 tables, so for that I tried to create the same size
tables.
And how I equalize these is like I have created one column table with char(2000).
555 MB is the figure I wanted to use for these 3 tables ( no special figure, just to make it bigger than the
RAM used for my db at the db startup to be sure of not retrieving the records from cache).
so row size with overhead is 2006 * 290,000 rows = 581740000(bytes) / 1024 = 568105KB / 1024 = 555MB.
Through this math calculation I thought It will be the total table size. So I Created the same no. of rows in 3 blocksizes.
If it's wrong then what a mes because I was calculating tables sizes in the same way from the last few months.
Can you please explain a little how you found out the tables sizes in different block sizes.Though I understood how you
calculated size in MB from these 3 block sizes
T8K =97177 BLOCKS=759MB *( 97177*8 = 777416KB / 1024 = 759MB )*
T16K=41639 BLOCKS=650MB
BT4K=293656 BLOCKS=1147MB
For me it's new to calculate the size of a table. Can you please tell me then how many rows I can create in each of
these 3 tables to make them equal in MB to test for elapsed time.
Then I'll again run my test and put the results here. Because If I've wrongly calculated table sizes then there is no need to talk about elapsed time. First I must equalize the table sizes properly.
SQL> select sum(bytes)/1024/1024 "Size in MB" from dba_segments> 2 where segment_name = 'T16K';
Size in MB
655
Is above SQL is correct to calculate the size or is it the correct alternative way to your method of calculating the size??
I created the same table again with everything same and the result is :
SQL> select num_rows,blocks from user_tables where table_name = 'T16K';NUM_ROWS BLOCKS
290000 41703
64 more blocks are allocated this time so may be that's y it's showing total size of 655 instead of 650.
Thanks alot for your help.
Best Regards,
KAm
Edited by: kam555 on Nov 20, 2009 5:57 PM

Data Blocks and the Elapsed Time

Hi,
I have created 3 tables with one column only. As an example Table 1 below:
SQL> create table T8k( x char(2000));
So 3 tables are created in this way i.e. T8k,T16K and T4K
T8 = in the default database tablespace of 8k (11g v11.1.0.6.0 - Production) (O.S=Windows).
T16 = I created in a Tablespace with Blocksize 16k.
T4K = I created in a Tablespace with Blocksize 4k. In the same Instance.
Each table has 290,000 rows and all the 3 tables have equal size of 555MB (2006(rowsize with overhead) * 290,000/1024/1024 = 555MB) to test Elapsed Time (set timing on).
As these 3 tables are created under different block sizes so the allocated no. of data blocks are different as below:
T8K = 97177 BLOCKS= 00:41:20.21 (Elapsed Time)
T16K=41639 BLOCKS= 00:44:11.59
BT4K=293656 BLOCKS=00:37:29.06
Please note the difference. First table i.e. 8k block size, allocated blocks are 97177 and taking around 41 mins. Third table i.e. BT4K (in a 4k block size tablespace), allocated blocks(293656 ) are almost 3 times bigger, taking around 37 mins to execute the query. I mean the difference is only 4 mins hardly and blocks difference is 3 times.
In case of any doubt, I've created these tables bigger than the memory used for my db(memory_max_size 408M) i.e. 555 MB that If Blocks are already in cache then reading the blocks and counting the rows will nearly be the same regardless of the block sizes or the number of blocks.
Need solid suggestions and if possilble, links also which has some serious discussions regarding my issue.
Bundle of thanks.
Best Regards,

Because I was not completely satisfied with the things last time. It doesn't seem so simple to me as people said
I thought may some guru have a look today, not just to point out that i have created it again.
And I have compact my question to avoid confusion.

Oracle Performance 11g - Warning: log write elapsed time

Hello ,
We are facing quite bad performance with our SAP cluster running Oracle 11g .
In the ora alert file we are having constant message for "
Thread 1 cannot allocate new log, sequence xxxxxx
Private strand flush not complete"
However , this seems to be quite old as we have recently started facing the performace issue.
Moreover , in the sid_lgwr_788.trc file we are getting warning for log write elapsed time as follow.
*** 2013-07-25 08:43:07.098
Warning: log write elapsed time 722ms, size 4KB
*** 2013-07-25 08:44:07.069
Warning: log write elapsed time 741ms, size 32KB
*** 2013-07-25 08:44:11.134
Warning: log write elapsed time 1130ms, size 23KB
*** 2013-07-25 08:44:15.508
Warning: log write elapsed time 1161ms, size 25KB
*** 2013-07-25 08:44:19.790
Warning: log write elapsed time 1210ms, size 10KB
*** 2013-07-25 08:44:20.748
Warning: log write elapsed time 544ms, size 3KB
*** 2013-07-25 08:44:24.396
Warning: log write elapsed time 1104ms, size 14KB
*** 2013-07-25 08:44:28.955
Warning: log write elapsed time 1032ms, size 37KB
*** 2013-07-25 08:45:13.115
Warning: log write elapsed time 1096ms, size 3KB
*** 2013-07-25 08:45:46.995
Warning: log write elapsed time 539ms, size 938KB
*** 2013-07-25 08:47:55.424
Warning: log write elapsed time 867ms, size 566KB
*** 2013-07-25 08:48:00.288
Warning: log write elapsed time 871ms, size 392KB
*** 2013-07-25 08:48:04.514
Warning: log write elapsed time 672ms, size 2KB
*** 2013-07-25 08:48:08.788
Warning: log write elapsed time 745ms, size 466KB
Please advice to further understand the issue.
Regards

Hi,
Seem the I/O issue, Check the metalink id
Intermittent Long 'log file sync' Waits, LGWR Posting Long Write Times, I/O Portion of Wait Minimal (Doc ID 1278149.1)

CPU time and ELAPSED time in tkprof question

Hi,
I have a statment that is running more than 3 HR.
I run 10046 event and found that the CPU time and the ELAPSED time is almost the same:
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 3 0 1
Fetch 97 10175.76 10094.81 11216 56387604 0 1441
total 101 10175.76 10094.82 11216 56387607 0 1442
Is that can indicate of a problem in the machine ?
The TOP activity also shows 99% cpu usage.
CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND
6 ? 24700 oracle 232 20 5448M 13184K run 195:34 99.18 99.00 oraclepcr
Thanks

Hi,
Thank you for your replay.
Its version 10204 on HP-UX with 24GB and 8 CPUs.
No i dont have any MERGE JOIN CARTESIAN.
The reason that i didnt upload the plan is because its too long...far too long ....
call count cpu elapsed disk query current rows
Parse 1 42.20 41.38 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 5 444.12 447.27 1153 2486187 0 61
total 7 486.32 488.65 1153 2486187 0 61
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 65 (PSSYS)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 UNION-ALL
0 CONCATENATION
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS (OUTER)
0 HASH JOIN (OUTER)
0 HASH JOIN (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
(OUTER)
0 NESTED LOOPS
(OUTER)
0 NESTED LOOPS
(OUTER)
0 NESTED LOOPS
(OUTER)
0 NESTED
LOOPS (OUTER)
0 FILTER
0 HASH
JOIN (OUTER)
0
TABLE ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'PS_RD_COMPANY'
(TABLE)
0
NESTED LOOPS
0
NESTED LOOPS (OUTER)
0
NESTED LOOPS
0
NESTED LOOPS
0
HASH JOIN
0
TABLE ACCESS MODE:
ANALYZED (FULL) OF 'PS_PROD
_ITEM' (TABLE)
0
TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID)
OF 'PS_RO_LINE' (TABLE)
0
NESTED LOOPS
0
HASH JOIN
0
INDEX MOD
E: ANALYZED (FULL SCAN)
OF 'PS0RO_DEFN_HDSTAT'
(INDEX)
0
TABLE ACCES
S MODE: ANALYZED (BY
INDEX ROWID) OF 'PS_RO_H
EADER' (TABLE)
0
INDEX
MODE: ANALYZED (RANGE
SCAN) OF 'PSERO_HEADER'
(INDEX)
0
INDEX MODE:
ANALYZED (RANGE SCAN) OF
'PSARO_LINE' (INDEX (UNIQ
UE))
0
TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'PS_RO_BOID' (TABLE)
0
INDEX MODE: ANALYZ
ED (UNIQUE SCAN) OF 'PS_RO_
BOID' (INDEX (UNIQUE))
0
TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'PS_RF_INST_PROD' (TABLE)
0
INDEX MODE: ANALYZED
(RANGE SCAN) OF 'PS_RF_INST_
PROD' (INDEX (UNIQUE))
0
TABLE ACCESS MODE: ANALYZED
(BY INDEX ROWID) OF 'PS_RD_PER
SON' (TABLE)
0
INDEX MODE: ANALYZED
(UNIQUE SCAN) OF 'PS_RD_PERSO
N' (INDEX (UNIQUE))
0
INDEX MODE: ANALYZED (RANGE
SCAN) OF 'PS0RD_COMPANY' (INDEX)
0 VIEW
OF 'XLATTABLE_VW' (VIEW)
0
NESTED LOOPS
0
TABLE ACCESS MODE: ANALYZED
(FULL) OF 'PSXLATITEM' (TABLE)
0
INDEX MODE: ANALYZED (UNIQUE
SCAN) OF 'PS_PSXLATDEFN' (INDEX
(UNIQUE))
0 TABLE
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'PS_RSF_INDUSTRY' (TABLE)
0 INDEX
MODE: ANALYZED (RANGE SCAN) OF
'PS3RSF_INDUSTRY' (INDEX)
0 TABLE
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'NAP_CATALOG_NUM' (TABLE)
0 INDEX
MODE: ANALYZED (UNIQUE SCAN) OF
'PS_NAP_CATALOG_NUM' (INDEX (UNIQUE)
0 MAT_VIEW
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX
MODE: ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX
MODE: ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW ACCESS
MODE: ANALYZED (BY INDEX ROWID) OF
'IP_CONNECTION_TYPES' (MAT_VIEW)
0 INDEX MODE:
ANALYZED (RANGE SCAN) OF
'IP_CONNECTION_TYPES_X1' (INDEX)
0 TABLE ACCESS
MODE: ANALYZED (BY INDEX ROWID) OF
'NAP_INTERNET' (TABLE)
0 INDEX MODE:
ANALYZED (UNIQUE SCAN) OF
'PS_NAP_INTERNET' (INDEX (UNIQUE))
0 TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'PS_RF_INST_PROD' (TABLE)
0 INDEX MODE:
ANALYZED (RANGE SCAN) OF
'PS_RF_INST_PROD' (INDEX (UNIQUE))
0 MAT_VIEW ACCESS
MODE: ANALYZED (BY INDEX ROWID) OF
'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX MODE:
ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'NAP_CATALOG_NUM' (TABLE)
0 INDEX MODE: ANALYZED
(UNIQUE SCAN) OF 'PS_NAP_CATALOG_NUM'
(INDEX (UNIQUE))
0 MAT_VIEW ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF 'BB_CODE_TABLE'
(MAT_VIEW)
0 INDEX MODE: ANALYZED
(RANGE SCAN) OF 'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF 'BB_CODE_TABLE'
(MAT_VIEW)
0 INDEX MODE: ANALYZED
(RANGE SCAN) OF 'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'IP_CONNECTION_TYPES' (MAT_VIEW)
0 INDEX MODE: ANALYZED
(RANGE SCAN) OF 'IP_CONNECTION_TYPES_X1'
(INDEX)
0 MAT_VIEW ACCESS MODE: ANALYZED
(FULL) OF 'IP_PIRSUM_CODE' (MAT_VIEW)
0 MAT_VIEW ACCESS MODE: ANALYZED
(FULL) OF 'IP_PIRSUM_CODE' (MAT_VIEW)
0 TABLE ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'PS_BO_NAME' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN)
OF 'PS_BO_NAME' (INDEX (UNIQUE))
0 TABLE ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'PS_BO_CM' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN)
OF 'PS_BO_CM' (INDEX (UNIQUE))
0 TABLE ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'PS_BO_CM_USE' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PS_BO_CM_USE' (INDEX (UNIQUE))
0 TABLE ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'PS_CM' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'PS_CM' (INDEX (UNIQUE))
0 MAT_VIEW ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 INDEX MODE: ANALYZED (FULL SCAN) OF
'PSHBO_NAME' (INDEX)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PS1RD_PERSON' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RB_WORKER' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'PS_RB_WORKER' (INDEX (UNIQUE))
0 INDEX MODE: ANALYZED (FULL SCAN) OF 'PSHBO_NAME'
(INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RD_PERSON' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PS1RD_PERSON' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RF_GRP_MEMBER' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PSARF_GRP_MEMBER' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RF_PROVIDER_GRP' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'PS_RF_PROVIDER_GRP' (INDEX (UNIQUE))
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS (OUTER)
0 HASH JOIN (OUTER)
0 HASH JOIN (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS
(OUTER)
0 NESTED LOOPS
(OUTER)
0 NESTED LOOPS
(OUTER)
0 NESTED LOOPS
(OUTER)
0 NESTED
LOOPS (OUTER)
0 FILTER
0 HASH
JOIN (OUTER)
0
TABLE ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'PS_RD_COMPANY'
(TABLE)
0
NESTED LOOPS
0
NESTED LOOPS
0
NESTED LOOPS (OUTER)
0
NESTED LOOPS
0
HASH JOIN
0
TABLE ACCESS MODE:
ANALYZED (FULL) OF 'PS_PROD
_ITEM' (TABLE)
0
TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID)
OF 'PS_RO_LINE' (TABLE)
0
NESTED LOOPS
0
HASH JOIN
0
INDEX MOD
E: ANALYZED (FULL SCAN)
OF 'PS0RO_DEFN_HDSTAT'
(INDEX)
0
TABLE ACCES
S MODE: ANALYZED (BY
INDEX ROWID) OF 'PS_RO_H
EADER' (TABLE)
0
INDEX
MODE: ANALYZED (RANGE
SCAN) OF 'PSERO_HEADER'
(INDEX)
0
INDEX MODE:
ANALYZED (RANGE SCAN) OF
'PSARO_LINE' (INDEX (UNIQ
UE))
0
TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'PS_RO_BOID' (TABLE)
0
INDEX MODE: ANALYZ
ED (UNIQUE SCAN) OF 'PS_RO_
BOID' (INDEX (UNIQUE))
0
TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'PS_RD_PERSON' (TABLE)
0
INDEX MODE: ANALYZED
(UNIQUE SCAN) OF 'PS_RD_PERS
ON' (INDEX (UNIQUE))
0
TABLE ACCESS MODE: ANALYZED
(BY INDEX ROWID) OF 'PS_RF_INS
T_PROD' (TABLE)
0
INDEX MODE: ANALYZED
(RANGE SCAN) OF 'PS_RF_INST_P
ROD' (INDEX (UNIQUE))
0
INDEX MODE: ANALYZED (RANGE
SCAN) OF 'PS0RD_COMPANY' (INDEX)
0 VIEW
OF 'XLATTABLE_VW' (VIEW)
0
NESTED LOOPS
0
TABLE ACCESS MODE: ANALYZED
(FULL) OF 'PSXLATITEM' (TABLE)
0
INDEX MODE: ANALYZED (UNIQUE
SCAN) OF 'PS_PSXLATDEFN' (INDEX
(UNIQUE))
0 TABLE
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'PS_RSF_INDUSTRY' (TABLE)
0 INDEX
MODE: ANALYZED (RANGE SCAN) OF
'PS3RSF_INDUSTRY' (INDEX)
0 TABLE
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'NAP_CATALOG_NUM' (TABLE)
0 INDEX
MODE: ANALYZED (UNIQUE SCAN) OF
'PS_NAP_CATALOG_NUM' (INDEX (UNIQUE)
0 MAT_VIEW
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX
MODE: ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX
MODE: ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW ACCESS
MODE: ANALYZED (BY INDEX ROWID) OF
'IP_CONNECTION_TYPES' (MAT_VIEW)
0 INDEX MODE:
ANALYZED (RANGE SCAN) OF
'IP_CONNECTION_TYPES_X1' (INDEX)
0 TABLE ACCESS
MODE: ANALYZED (BY INDEX ROWID) OF
'NAP_INTERNET' (TABLE)
0 INDEX MODE:
ANALYZED (UNIQUE SCAN) OF
'PS_NAP_INTERNET' (INDEX (UNIQUE))
0 TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'PS_RF_INST_PROD' (TABLE)
0 INDEX MODE:
ANALYZED (RANGE SCAN) OF
'PS_RF_INST_PROD' (INDEX (UNIQUE))
0 MAT_VIEW ACCESS
MODE: ANALYZED (BY INDEX ROWID) OF
'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX MODE:
ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'NAP_CATALOG_NUM' (TABLE)
0 INDEX MODE: ANALYZED
(UNIQUE SCAN) OF 'PS_NAP_CATALOG_NUM'
(INDEX (UNIQUE))
0 MAT_VIEW ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF 'BB_CODE_TABLE'
(MAT_VIEW)
0 INDEX MODE: ANALYZED
(RANGE SCAN) OF 'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF 'BB_CODE_TABLE'
(MAT_VIEW)
0 INDEX MODE: ANALYZED
(RANGE SCAN) OF 'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'IP_CONNECTION_TYPES' (MAT_VIEW)
0 INDEX MODE: ANALYZED
(RANGE SCAN) OF 'IP_CONNECTION_TYPES_X1'
(INDEX)
0 MAT_VIEW ACCESS MODE: ANALYZED
(FULL) OF 'IP_PIRSUM_CODE' (MAT_VIEW)
0 MAT_VIEW ACCESS MODE: ANALYZED
(FULL) OF 'IP_PIRSUM_CODE' (MAT_VIEW)
0 TABLE ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'PS_BO_NAME' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN)
OF 'PS_BO_NAME' (INDEX (UNIQUE))
0 TABLE ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'PS_BO_CM' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN)
OF 'PS_BO_CM' (INDEX (UNIQUE))
0 TABLE ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'PS_BO_CM_USE' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PS_BO_CM_USE' (INDEX (UNIQUE))
0 TABLE ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'PS_CM' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'PS_CM' (INDEX (UNIQUE))
0 MAT_VIEW ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 INDEX MODE: ANALYZED (FULL SCAN) OF
'PSHBO_NAME' (INDEX)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PS1RD_PERSON' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RB_WORKER' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'PS_RB_WORKER' (INDEX (UNIQUE))
0 INDEX MODE: ANALYZED (FULL SCAN) OF 'PSHBO_NAME'
(INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RD_PERSON' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PS1RD_PERSON' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RF_GRP_MEMBER' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PSARF_GRP_MEMBER' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RF_PROVIDER_GRP' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'PS_RF_PROVIDER_GRP' (INDEX (UNIQUE))
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 HASH JOIN (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
0 NESTED LOOPS
0 NESTED LOOPS (OUTER)
0 FILTER
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
0 NESTED LOOPS (OUTER)
0 NESTED LOOPS
(OUTER)
0 NESTED LOOPS
0 NESTED LOOPS
(OUTER)
0 NESTED LOOPS
(OUTER)
0 NESTED
LOOPS (OUTER)
0 NESTED
LOOPS
0 NESTED
LOOPS (OUTER)
0
NESTED LOOPS
0
HASH JOIN
0
TABLE ACCESS MODE: ANALYZED
(FULL) OF 'PS_PROD_ITEM' (TABLE)
0
TABLE ACCESS MODE: ANALYZED
(BY INDEX ROWID) OF 'PS_RO_LINE
' (TABLE)
0
NESTED LOOPS
0
HASH JOIN
0
INDEX MODE: ANALYZED
(FULL SCAN) OF 'PS0RO_DEFN_H
DSTAT' (INDEX)
0
TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'PS_RO_HEADER' (TABLE)
0
INDEX MODE: ANALYZ
ED (RANGE SCAN) OF 'PSERO_H
EADER' (INDEX)
0
INDEX MODE: ANALYZED
(RANGE SCAN) OF 'PSARO_LINE'
(INDEX (UNIQUE))
0
TABLE ACCESS MODE: ANALYZED
(BY INDEX ROWID) OF 'PS_RO_BOID'
(TABLE)
0
INDEX MODE: ANALYZED (UNIQUE
SCAN) OF 'PS_RO_BOID' (INDEX
(UNIQUE))
0
TABLE ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'PS_RD_PERSON'
(TABLE)
0
INDEX MODE: ANALYZED (UNIQUE
SCAN) OF 'PS_RD_PERSON' (INDEX
(UNIQUE))
0 TABLE
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'PS_RF_INST_PROD' (TABLE)
0
INDEX MODE: ANALYZED (RANGE
SCAN) OF 'PS_RF_INST_PROD' (INDEX
(UNIQUE))
0 TABLE
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'PS_BO_NAME' (TABLE)
0 INDEX
MODE: ANALYZED (RANGE SCAN) OF
'PS_BO_NAME' (INDEX (UNIQUE))
0 TABLE
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'NAP_CATALOG_NUM' (TABLE)
0 INDEX
MODE: ANALYZED (UNIQUE SCAN) OF
'PS_NAP_CATALOG_NUM' (INDEX (UNIQUE)
0 MAT_VIEW
ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'IP_CONNECTION_TYPES'
(MAT_VIEW)
0 INDEX
MODE: ANALYZED (RANGE SCAN) OF
'IP_CONNECTION_TYPES_X1' (INDEX)
0 INDEX MODE:
ANALYZED (RANGE SCAN) OF
'PS_NAP_IP_DEBIT' (INDEX (UNIQUE))
0 SORT
(AGGREGATE)
0 INDEX
MODE: ANALYZED (RANGE SCAN) OF
'PS_NAP_IP_DEBIT' (INDEX (UNIQUE))
0 TABLE ACCESS
MODE: ANALYZED (BY INDEX ROWID) OF
'NAP_CATALOG_NUM' (TABLE)
0 INDEX MODE:
ANALYZED (UNIQUE SCAN) OF
'PS_NAP_CATALOG_NUM' (INDEX (UNIQUE))
0 MAT_VIEW ACCESS
MODE: ANALYZED (BY INDEX ROWID) OF
'IP_CONNECTION_TYPES' (MAT_VIEW)
0 INDEX MODE:
ANALYZED (RANGE SCAN) OF
'IP_CONNECTION_TYPES_X1' (INDEX)
0 TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'PS_RD_COMPANY' (TABLE)
0 INDEX MODE:
ANALYZED (RANGE SCAN) OF 'PS0RD_COMPANY'
(INDEX)
0 VIEW PUSHED PREDICATE
OF 'XLATTABLE_VW' (VIEW)
0 NESTED LOOPS
0 TABLE ACCESS
MODE: ANALYZED (BY INDEX ROWID) OF
'PSXLATITEM' (TABLE)
0 INDEX MODE:
ANALYZED (RANGE SCAN) OF
'PSBPSXLATITEM' (INDEX)
0 INDEX MODE:
ANALYZED (UNIQUE SCAN) OF
'PS_PSXLATDEFN' (INDEX (UNIQUE))
0 TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF
'PS_RSF_INDUSTRY' (TABLE)
0 INDEX MODE: ANALYZED
(RANGE SCAN) OF 'PS3RSF_INDUSTRY' (INDEX)
0 TABLE ACCESS MODE:
ANALYZED (BY INDEX ROWID) OF 'PS_BO_CM'
(TABLE)
0 INDEX MODE: ANALYZED
(RANGE SCAN) OF 'PS_BO_CM' (INDEX (UNIQUE))
0 TABLE ACCESS MODE: ANALYZED
(BY INDEX ROWID) OF 'PS_BO_CM_USE' (TABLE)
0 INDEX MODE: ANALYZED
(RANGE SCAN) OF 'PS_BO_CM_USE' (INDEX (UNIQUE)
0 TABLE ACCESS MODE: ANALYZED
(BY INDEX ROWID) OF 'PS_CM' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE
SCAN) OF 'PS_CM' (INDEX (UNIQUE))
0 TABLE ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'NAP_INTERNET' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE
SCAN) OF 'PS_NAP_INTERNET' (INDEX (UNIQUE))
0 MAT_VIEW ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX MODE: ANALYZED (RANGE SCAN)
OF 'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX MODE: ANALYZED (RANGE SCAN)
OF 'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW ACCESS MODE: ANALYZED (BY
INDEX ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW ACCESS MODE: ANALYZED (FULL) OF
'IP_PIRSUM_CODE' (MAT_VIEW)
0 MAT_VIEW ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 MAT_VIEW ACCESS MODE: ANALYZED (BY INDEX
ROWID) OF 'BB_CODE_TABLE' (MAT_VIEW)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'BB_CODE_TABLE_I' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID)
OF 'PS_BO_NAME' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PS_BO_NAME_IDX1' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RD_PERSON' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PS1RD_PERSON' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RF_GRP_MEMBER' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PSARF_GRP_MEMBER' (INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RF_PROVIDER_GRP' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF
'PS_RF_PROVIDER_GRP' (INDEX (UNIQUE))
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_BO_NAME' (TABLE)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'PS_BO_NAME_IDX1' (INDEX)
0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'PS1RD_PERSON'
(INDEX)
0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF
'PS_RB_WORKER' (TABLE)
0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'PS_RB_WORKER'
(INDEX (UNIQUE))

Diffrence between cpu and elapse time in tkprof

Hi All
i found huge diffrence between cpu and elapsed time in tkprof. can you please advice me on this issue.
>call count cpu elapsed disk query current rows
==================================================
Parse 1 0.12 1.36 2 11 0 0
Execute 1 14.30 720.20 46548 190520 205 100
Fetch 0 0.00 0.00 0 0 0 0
======================================================
total 2 14.42 721.56 46550 190531 205 100
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 173 (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on Times waited Max. Wait Total Waited
===========================================
db file sequential read 46544 0.49 632.12
db file scattered read 1 0.00 0.00
my select statement
SELECT cst.customer_id> ,DECODE(COUNT(cr.deposit_date), 0, 0, ROUND(SUM(cr.deposit_date - ps.trx_date) / COUNT(cr.deposit_date))) avgdays
> ,DECODE(COUNT(cr.deposit_date), 0, 0, ROUND(SUM(cr.deposit_date - ps.due_date) / COUNT(cr.deposit_date))) avgdayslate
> ,NVL(SUM(DECODE(SIGN(cr.deposit_date - ps.due_date),1, 1, 0)), 0) newlate
> ,NVL(SUM( DECODE(SIGN(cr.deposit_date - ps.due_date),1, 0, 1)), 0) newontime
>
> FROM ar_receivable_applications_all ra
> ,ar_cash_receipts_all cr
> ,ar_payment_schedules_all ps
> ,zz_ar_customer_summary_all cst
> WHERE ra.cash_receipt_id = cr.cash_receipt_id
> AND ra.apply_date BETWEEN ADD_MONTHS(SYSDATE, -12) AND SYSDATE
> AND ra.status = 'APP'
> AND ra.display = 'Y'
> AND ra.applied_payment_schedule_id = ps.payment_schedule_id
> AND ps.customer_id = cst.customer_id
> AND NVL(ps.receipt_confirmed_flag,'Y') = 'Y'
> group by cst.customer_id ;
Thanks,
Anu

user653066 wrote:
Hi All
i found huge diffrence between cpu and elapsed time in tkprof. can you please advice me on this issue.
call     count       cpu    elapsed       disk      query    current        rows
================================================================================
Parse        1      0.12       1.36          2         11          0           0
Execute      1     14.30     720.20      46548     190520        205         100
Fetch        0      0.00       0.00          0          0          0           0
================================================================================
total        2     14.42     721.56      46550     190531        205         100
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 173     (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on                      Times waited   Max. Wait Total Waited
===========================================================================
db file sequential read                     46544        0.49        632.12
db file scattered read                          1        0.00          0.00
SELECT cst.customer_id
         ,DECODE(COUNT(cr.deposit_date), 0, 0, ROUND(SUM(cr.deposit_date - ps.trx_date) / COUNT(cr.deposit_date))) avgdays
         ,DECODE(COUNT(cr.deposit_date), 0, 0, ROUND(SUM(cr.deposit_date - ps.due_date) / COUNT(cr.deposit_date))) avgdayslate
         ,NVL(SUM(DECODE(SIGN(cr.deposit_date - ps.due_date),1, 1, 0)), 0) newlate
         ,NVL(SUM( DECODE(SIGN(cr.deposit_date - ps.due_date),1, 0, 1)), 0) newontime
          FROM ar_receivable_applications_all ra
              ,ar_cash_receipts_all           cr
              ,ar_payment_schedules_all       ps
              ,zz_ar_customer_summary_all cst
          WHERE ra.cash_receipt_id                 = cr.cash_receipt_id
          AND   ra.apply_date                BETWEEN ADD_MONTHS(SYSDATE, -12) AND SYSDATE
          AND   ra.status                          = 'APP'
          AND   ra.display                         = 'Y'
          AND   ra.applied_payment_schedule_id     = ps.payment_schedule_id
          AND   ps.customer_id                     = cst.customer_id
          AND   NVL(ps.receipt_confirmed_flag,'Y') = 'Y'
          group by cst.customer_id    ;           Toon Koppelaars seems to have pinpointed the problem. Where are the 74 seconds unaccounted for seconds (I might have calculated it incorrectly, but I arrived at 88.08 seconds of unaccounted for time: 721.56 total - 1.36 parse - 632.12 db file sequential reads)?
It is interesting that the maximum wait for a single block read reported by TKPROF is 0.49 seconds - this might be an indication of excessive competition for the server's CPU - processes are waiting in the CPU run queue, and therefore not on the CPU. As Toon indicated, 632.12 of the 721.56 seconds were spent waiting for single block reads to complete with 46,544 blocks read. Note also that the query executed at dep=1, and TKPROF may be providing misleading information about what actually happened during those executions. An example of misleading information:
CREATE TABLE T11 (
C1 NUMBER,
C2 VARCHAR2(30));
CREATE TABLE T12 (
C1 NUMBER,
C2 VARCHAR2(30));
CREATE TABLE T13 (
C1 NUMBER,
C2 VARCHAR2(30));
CREATE TABLE T14 (
C1 NUMBER,
C2 VARCHAR2(30));
CREATE OR REPLACE TRIGGER HPM_T11 AFTER
INSERT OR DELETE OR UPDATE OF C1 ON T11
REFERENCING OLD AS OLDDATA NEW AS NEWDATA FOR EACH ROW
BEGIN
IF INSERTING THEN
    INSERT INTO T12
    SELECT
      ROWNUM,
      DBMS_RANDOM.STRING('A',25)
    FROM
      DUAL
    CONNECT BY
      LEVEL <= 100;
END IF;
END;
CREATE OR REPLACE TRIGGER HPM_T12 AFTER
INSERT OR DELETE OR UPDATE OF C1 ON T12
REFERENCING OLD AS OLDDATA NEW AS NEWDATA FOR EACH ROW
BEGIN
IF INSERTING THEN
    INSERT INTO T13
    SELECT
      ROWNUM,
      DBMS_RANDOM.STRING('A',25)
    FROM
      DUAL
    CONNECT BY
      LEVEL <= 100;
END IF;
END;
CREATE OR REPLACE TRIGGER HPM_T13 AFTER
INSERT OR DELETE OR UPDATE OF C1 ON T13
REFERENCING OLD AS OLDDATA NEW AS NEWDATA FOR EACH ROW
BEGIN
IF INSERTING THEN
    INSERT INTO T14
    SELECT
      ROWNUM,
      DBMS_RANDOM.STRING('A',25)
    FROM
      DUAL
    CONNECT BY
      LEVEL <= 100;
END IF;
END;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'MY_TEST_FIND_ME2';
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8';
SET TIMING ON
INSERT INTO T11 VALUES (1,'MY LITTLE TEST CASE');
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';The partial TKPROF output:
INSERT INTO T11
VALUES
(1,'MY LITTLE TEST CASE')
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          8          0           0
Execute      1      0.00       0.00          0       9788         29           1
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0       9796         29           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=9788 pr=7 pw=0 time=0 us)
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 : 6asaf110fgaqg
INSERT INTO T12 SELECT ROWNUM, DBMS_RANDOM.STRING('A',25) FROM DUAL CONNECT
BY LEVEL <= 100
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.04       0.09          0          2        130         100
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.04       0.09          0          2        130         100
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56     (recursive depth: 1)
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=9754 pr=7 pw=0 time=0 us)
    100   COUNT (cr=0 pr=0 pw=0 time=0 us)
    100    CONNECT BY WITHOUT FILTERING (cr=0 pr=0 pw=0 time=0 us)
      1     FAST DUAL (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)
SQL ID : db46bkvy509w4
INSERT INTO T13 SELECT ROWNUM, DBMS_RANDOM.STRING('A',25) FROM DUAL CONNECT
BY LEVEL <= 100
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute    100      1.31       1.27          0         93      10634       10000
Fetch        0      0.00       0.00          0          0          0           0
total      101      1.31       1.27          0         93      10634       10000
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56     (recursive depth: 2)
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=164 pr=0 pw=0 time=0 us)
    100   COUNT (cr=0 pr=0 pw=0 time=0 us)
    100    CONNECT BY WITHOUT FILTERING (cr=0 pr=0 pw=0 time=0 us)
      1     FAST DUAL (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)
SQL ID : 6542yyk084rpu
INSERT INTO T14 SELECT ROWNUM, DBMS_RANDOM.STRING('A',25) FROM DUAL CONNECT
BY LEVEL <= 100
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute 10001     41.60      41.84          0       8961      52859     1000000
Fetch        0      0.00       0.00          0          0          0           0
total    10003     41.60      41.84          0       8961      52859     1000000
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56     (recursive depth: 3)
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=2 pr=0 pw=0 time=0 us)
    100   COUNT (cr=0 pr=0 pw=0 time=0 us)
    100    CONNECT BY WITHOUT FILTERING (cr=0 pr=0 pw=0 time=0 us)
      1     FAST DUAL (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
log file switch completion                      2        0.07          0.07
********************************************************************************In the above note that the "INSERT INTO T11" is reported as completing in 0 seconds, but it actually required roughly 42 seconds - and that would be visible by manually reviewing the resulting trace file. Also note that the log file switch completion wait was not reported for the "INSERT INTO T11" even though it impacted the execution time.
Back to the possibility of CPU starvation causing lost time. Another test with an otherwise idle server, followed by a second test with the same server having 240 other processes fighting for CPU resources (a simulated load).
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'MY_TEST_QUERY_NO_LOAD';
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8';
SET TIMING ON
SELECT
COUNT(*)
FROM
T14;
SELECT
SYSDATE
FROM
DUAL;
SQL> SELECT
2    COUNT(*)
3 FROM
4    T14;
COUNT(*)
   1000000
Elapsed: 00:00:01.37With no load the COUNT(*) completed in 1.37 seconds. The TKPROF output looks like this:
SQL ID : gy8nw9xzyg3bj
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),
NVL(SUM(C2),:"SYS_B_1")
FROM
(SELECT /*+ NO_PARALLEL("T14") FULL("T14") NO_PARALLEL_INDEX("T14") */
:"SYS_B_2" AS C1, :"SYS_B_3" AS C2 FROM "T14" SAMPLE BLOCK (:"SYS_B_4" ,
:"SYS_B_5") SEED (:"SYS_B_6") "T14") SAMPLESUB
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.01       0.84        523        172          1           1
total        3      0.01       0.84        523        172          1           1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56     (recursive depth: 1)
Rows     Row Source Operation
      1 SORT AGGREGATE (cr=172 pr=523 pw=0 time=0 us)
   8733   TABLE ACCESS SAMPLE T14 (cr=172 pr=523 pw=0 time=0 us cost=2 size=12 card=1)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         3        0.02          0.04
db file parallel read                           1        0.31          0.31
db file scattered read                         52        0.03          0.47
SQL ID : 96g93hntrzjtr
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#,
sample_size, minimum, maximum, distcnt, lowval, hival, density, col#,
spare1, spare2, avgcln
from
hist_head$ where obj#=:1 and intcol#=:2
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.06          2          2          0           0
total        3      0.00       0.06          2          2          0           0
Misses in library cache during parse: 0
Optimizer mode: RULE
Parsing user id: SYS   (recursive depth: 2)
Rows     Row Source Operation
      0 TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=2 pr=2 pw=0 time=0 us)
      0   INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=2 pr=2 pw=0 time=0 us)(object id 413)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         2        0.02          0.04
SELECT
COUNT(*)
FROM
T14
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          1          1          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.03       0.43       6558       6983          0           1
total        4      0.03       0.44       6559       6984          0           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56
Rows     Row Source Operation
      1 SORT AGGREGATE (cr=6983 pr=6558 pw=0 time=0 us)
1000000   TABLE ACCESS FULL T14 (cr=6983 pr=6558 pw=0 time=0 us cost=1916 size=0 card=976987)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         1        0.02          0.02
SQL*Net message to client                       2        0.00          0.00
db file scattered read                        111        0.02          0.38
SQL*Net message from client                     2        0.00          0.00Note that TKPROF reported that it only required 0.44 seconds for the query to execute while the SQL*Plus timing indicate that it required 1.37 seconds for the SQL statement to execute. The SQL optimization (parse) with dynamic sampling query accounted for the remaining time, yet TKPROF provided no indication that this was the case.
Now the query with 240 other processes competing for CPU time:
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'MY_TEST_QUERY_WITH_LOAD';
SELECT COUNT(*) FROM T14;
SELECT
SYSDATE
FROM
DUAL;
SQL> SELECT COUNT(*) FROM T14;
COUNT(*)
   1000000
Elapsed: 00:00:59.03The query this time required just over 59 seconds. The TKPROF output:
SQL ID : gy8nw9xzyg3bj
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),
NVL(SUM(C2),:"SYS_B_1")
FROM
(SELECT /*+ NO_PARALLEL("T14") FULL("T14") NO_PARALLEL_INDEX("T14") */
:"SYS_B_2" AS C1, :"SYS_B_3" AS C2 FROM "T14" SAMPLE BLOCK (:"SYS_B_4" ,
:"SYS_B_5") SEED (:"SYS_B_6") "T14") SAMPLESUB
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.28        423         69          0           1
total        3      0.00       0.28        423         69          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 56     (recursive depth: 1)
Rows     Row Source Operation
      1 SORT AGGREGATE (cr=69 pr=423 pw=0 time=0 us)
   8733   TABLE ACCESS SAMPLE T14 (cr=69 pr=423 pw=0 time=0 us cost=2 size=12 card=1)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file scattered read                         54        0.01          0.27
db file sequential read                         2        0.00          0.00
SQL ID : 7h04kxpa13w1x
SELECT COUNT(*)
FROM
T14
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.03          1          1          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.06      58.71       6551       6983          0           1
total        4      0.06      58.74       6552       6984          0           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56
Rows     Row Source Operation
      1 SORT AGGREGATE (cr=6983 pr=6551 pw=0 time=0 us)
1000000   TABLE ACCESS FULL T14 (cr=6983 pr=6551 pw=0 time=0 us cost=1916 size=0 card=976987)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         1        0.02          0.02
SQL*Net message to client                       2        0.00          0.00
db file scattered read                        110        1.54         58.59
SQL*Net message from client                     1        0.00          0.00Note in the above that the max wait for the db file scattered read is 1.54 seconds due to the extra CPU competition - about 3 times longer than your max wait for a single block read. On your database platform with single block reads, it might be possible that the time in the CPU run queue is not always counted in the db file sequential read wait time or the CPU wait time - what if your operating system is slow at returning timing information to the database instance due to CPU saturation - this might explain the 74 (or 88) lost seconds.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.
Edited by: Charles Hooper on Aug 28, 2009 10:26 AM
Fixing formatting problems

VDbench : Session doesn't end after "elapsed" time elapsed

With the fallowing config file :
fsd=fsd1,anchor=/mnt/machine/fs11/vdbench,depth=2,width=2,files=2,size=2200g,openflags=directio
fsd=fsd2,anchor=/mnt/machine/fs12/vdbench,depth=1,width=3,files=13,size=240g,openflags=directio
fsd=fsd3,anchor=/mnt/machine/fs13/vdbench,depth=2,width=4,files=4,size=2600g,openflags=directio
fsd=fsd4,anchor=/mnt/machine/fs14/vdbench,depth=3,width=2,files=5,size=280g,openflags=directio
fsd=fsd5,anchor=/mnt/machine/fs15/vdbench,depth=2,width=1,files=16,size=300g,openflags=directio
fsd=fsd6,anchor=/mnt/machine/fs16/vdbench,depth=8,width=1,files=7,size=3200g,openflags=directio
fsd=fsd7,anchor=/mnt/machine/fs17/vdbench,depth=1,width=14,files=4,size=340g,openflags=directio
fsd=fsd8,anchor=/mnt/machine/fs18/vdbench,depth=2,width=6,files=9,size=360g,openflags=directio
fsd=fsd9,anchor=/mnt/machine/fs19/vdbench,depth=2,width=2,files=27,size=380g,openflags=directio
fwd=fwd1,fsd=fsd*,operation=write,xfersize=1024k,fileio=sequential,
fileselect=random,threads=88
rd=rd1,fwd=fwd*,fwdrate=max,format=yes,elapsed=3600,interval=15
Instead of every 3600s making a summary and starting over , vdbench simply continued going until it was manually stopped.
Any ideas ?

I bet you that the 'format' is still running?
You are asking 398TB worth of files to be created, at a (very high) 1gb/second that would take about 110 hours; at 100mb/sec that would take 46 days.
Be careful with specifying Vdbench parameters, just last week I saw a parameter file with a total elapsed time of 9 years!
Henk.

Elapsed Time in my V$SQL

Hi,
Can someone answer this please?. I'm bit perplexed by the elapsed time in my v$sql
UPDATE ods_router_tables SET last_data_received = :b1, last_data_received_dst = :b3 WHERE
table_name = :b2 AND NVL(last_data_received,TO_DATE('01-JAN-1980','DD-MON-YYYY')) < :b1
Executions: 2786327
Disk reads: 0
Buffer gets: 6023381
Rows processed: 423713
Optimizer cost: 1
Sorts: 0
CPU Time: 898500000
Elapsed Time: 1.84467440681166E19
This table is quite small, only 44 records and if i run the statement in Sql plus, it runs in a
flash. But why this enormous Elapsed time in V$SQL. Is my conversion of this time to
seconds/execution correct?
Elapsed time in seconds/execution: 1.84467440681166E19/1000000/2786327=6620451 seconds!
I guess there is something seriously wrong here. I'm running on a 4 CPU server. DB version is 9.2.
I see similar figures in some of the innocent looking Insert statements as well.
thanks in advance,
Sunil

ELAPSED_TIME in v$sql also includes all wait times for that sql. Is it possible that update is waiting for locks some time? See the following case.
SQL> create table test2 as select * from dual;
Table created.
SQL> update test2 set dummy='A';
1 row updated.From another session try to update the same row.
SQL> update test2 set dummy='B';Wait for some time. Then rollback the first session.
SQL> rollback;
Rollback complete.Now look at v$sql.
SQL> select sql_text,executions,elapsed_time from v$sql where sql_text like 'update%test2%';
SQL_TEXT
EXECUTIONS ELAPSED_TIME
update test2 set dummy='B'
1 29413712
update test2 set dummy='A'
1 2506The first update's elapsed time is very small. The second update's elapsed time is high because of the wait for the lock.

ORA-1555 ORA-3136 errors:: elapsed time vs Query Duration

Dear all,
- My Database version is 11.2.0.2, Solaris.
- We have been having a problem in the production database where the front end nodes start going up and down for couple of hours sometimes. ; When node flapping is going on we get connection timed out alerts.
WARNING: inbound connection timed out (ORA-3136) opiodr aborting
process unknown ospid (4342) as a result of ORA-609 opiodr aborting
process unknown ospid (4532) as a result of ORA-609 opiodr aborting
process unknown ospid (4534) as a result of ORA-609 opiodr aborting....
Since this week node flapping is happening every day. Since past 2 days after or during node flapping we are getting ORA-1555 error.
Extract from alert log error:
ORA-01555 caused by SQL statement below (SQL ID: g8804k5pkmtyt, Query Duration=19443 sec, SCN: 0x0001.07bd90ed):
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.parentDeviceId, d.created, d.lastModified AS devLastMod, d.customerId, d.userKey1, d.userKey2, d.userKey4, d
.userKey5, d.firmwareFamily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.userKey6, d.provisioningId, d.status, d.classification, d.population, d.name, d.ipRe
solver, d.ipExpirationTime, d.geoLocationId,contact.firstContactTime, ifaces.id, ifaces.type AS ifaceType, ifaces.lastModified AS ifaceLastMod, ifaces.timeoutname, ifac
es.username1, ifaces.password1, ifaces.username2, ifaces.password2, ifaces.connReqUrl, ifaces.connReqScheme, ifaces.srvNonce, ifaces.deviceNonce, ifaces.phoneNumber,ifa
ces.bootstrapSecMethod, ifaces.srvAuthentication, ifaces.deviceAuthentication, ifaces.userPIN, ifaces.networkID, ifaces.omaSessionID, ifaces.portNum, ifaces.mgtIp, ifac
es.cmtsIp, ifaces.mgtReadCommunity, ifaces.mgtWriteCommunity, ifaces.cmtsReadCommunity, ifaces.cmtsWriteCommunity, devto.name AS devtoName, devto.rebootTimeout, devto.sessionInitiationI run Statspack report from the whole day duration, and looking into the elapsed time in seconds no more than 3739.61 sec (too lower than run duration in the alert log file of 19443 sec); So I would like to know if there is any co-relations between the ORA-3136 errors and the ORA-1555 errors?
   CPU                  CPU per             Elapsd                     Old
Time (s)   Executions Exec (s) %Total   Time (s)    Buffer Gets Hash Value
tTime <= :3 ) AND (endTime IS NULL OR endTime >= :4 )
   2773.77    7,787,914       0.00    3.4    3739.61     112,671,645 1909376826
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.user
SQL> show parameter UNDO_MANAGEMENT
NAME                                 TYPE        VALUE
undo_management                      string      AUTO
SQL> show parameter UNDO_RETENTION
NAME                                 TYPE        VALUE
undo_retention                       integer     10800BR,
Diego

Thank you. Please let me know if it is enough or you need more information;
SQL ordered by Gets DB/Inst: DB01/db01 Snaps: 14835-14846
-> End Buffer Gets Threshold:    100000 Total Buffer Gets:     677,689,568
-> Captured SQL accounts for   73.6% of Total Buffer Gets
-> SQL reported below exceeded 1.0% of Total Buffer Gets
                                                     CPU      Elapsd     Old
Buffer Gets    Executions Gets per Exec %Total Time (s) Time (s) Hash Value
     21,286,248    2,632,793            8.1    3.4   666.73    666.76 3610154549
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.user
     17,029,561    1,176,849           14.5    2.7   417.32    416.73 1909376826
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.user
     17,006,795           37      459,643.1    2.7   367.61    368.95 4045552861
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.userAnother Statspack report for the whole day shows;
SQL ordered by CPU DB/Inst: DB01/db01 Snaps: 14822-14847
-> Total DB CPU (s):          82,134
-> Captured SQL accounts for   40.9% of Total DB CPU
-> SQL reported below exceeded 1.0% of Total DB CPU
    CPU                  CPU per             Elapsd                     Old
Time (s)   Executions Exec (s) %Total   Time (s)    Buffer Gets Hash Value
tTime <= :3 ) AND (endTime IS NULL OR endTime >= :4 )
   2773.77    7,787,914       0.00    3.4    3739.61     112,671,645 1909376826
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.user
SQL ordered by Gets DB/Inst: DB01/db01 Snaps: 14822-14847
-> End Buffer Gets Threshold:    100000 Total Buffer Gets:   1,416,456,340
-> Captured SQL accounts for   55.8% of Total Buffer Gets
-> SQL reported below exceeded 1.0% of Total Buffer Gets
                                                     CPU      Elapsd     Old
Buffer Gets    Executions Gets per Exec %Total Time (s) Time (s) Hash Value
     86,354,963    7,834,326           11.0    6.3 2557.34   2604.08 906944860
Module: JDBC Thin Client
SELECT d.devId, d.vendor, d.model, d.productClass, d.oui, d.pare
ntDeviceId, d.created, d.lastModified AS devLastMod, d.customerI
d, d.userKey1, d.userKey2, d.userKey4, d.userKey5, d.firmwareFam
ily, d.softwareVer, d.serialNum, d.ip, d.mac, d.userKey3, d.user
.....BR,
Diego
Edited by: 899660 on 27-ene-2012 7:43
Edited by: 899660 on 27-ene-2012 7:45

How can I display the elapsed time of the course using Advanced Actions in Captivate?

I have a Captivate course which is approximately 35 minutes in length. On each slide I would like to display to the user, the current elapsed time.
EXAMPLE:
25/35 minutes complete
The 35 would remain static, so I have been working with the elapsed time system variable in CP: elapsed:$$cpInfoElapsedTimeMS$$
I can't seem to get the variable to properly display the elapsed time in minutes, rather than miliseconds. Attached is a screen shot of my advanced action.
Can anyone provide guidence regarding how I should structure this differntly?

I talked about that Timer widget in that blog post and pointed to another one:
http://blog.lilybiri.com/timer-widget-to-stress-your-learners
If you are on CP7, you'll have this widget also as an interaction, which means it is compatible with HTML5 output. Amd there is also an hourglass interaction, with similar functionality but... did not blog about that one
PS: Check Gallery\Widgets to find all widgets. Default path is set to Interactions

How can I get the elapse time for execution of a Query for a session

Hi ,
How can I get the elapse time for execution of a Query for a session?
Example - I have a report based on the procedure ,when the user execute that it takes say 3 min. to return rows.
Is there any possible way to capture this session info. for this particular execution of query along with it's execution elapse time?
Thanks in advance.

Hi
You can use the dbms_utility.get_time tool (gives binary_integer type value).
1/ Initialize you time and date of beginning :
v_beginTime := dbms_utility.get_time ;
2/ Run you procedure...
3/ Get end-time with :
v_endTime := dbms_utility.get_time ;
4/ Thus, calculate elapsed time by difference :
v_elapsTime := v_endTime - v_beginTime ;
This will give you time elapsed in of 100th of seconds...
Then you can format you result to give correct print time.
Hope it will help you.
AL

How to use elapsed time function with state machine in Lab VIEW

Hello
I've been trying to use state machine with elapsed time function in order to sequentially start and stop my code. The arrangement is to start the code for 1 minute then stop for 5 minutes. I've attached the code, the problem is when I place the elapsed time function out of the while loop it doesn't work, on the other hand when I place it inside the loop it does work but it doesn't give the true signal to move to the next state.
Could you please have a look to my code and help me to solve this issue.
Regards
Rajab
Solved!
Go to Solution.
Attachments:
daq assistance thermocouple(sate machine raj).vi ‏436 KB

Rajab84 wrote:
Thanks apok for your help
even with pressing start it keeps running on wait case
could you please explain the code for me, the use of Boolean crossing, increment , and equal functions
Best Regards
Rajab
OK..I modded the example to stop after 2 cycles. Also recommend taking the free online LabVIEW tutorials.
run vi. case statement goes to "initialize", shift registers are initialized to their constants. goto "wait"
"start"= false, stay in current state. If true, transition to "1 min" case
reset elapsed timer with True from shift register(counter starts at zero)."time has elapsed"=false, stay in current state(1 min). If true, goto "5min" case
reset elapsed timer with True from shift register of previous case(counter starts at zero)."time has elapsed"=false, stay in current state(5 min). If true, goto "1min" case. Also, bool crossing is looking for "true-false" from "5 min" compare function to add cycle count.
Once cycle count reaches 2, stop while loop....
Attachments:
Untitled%202[1].vi ‏42 KB

Repository Size / RPCLEAN elapsed time

Similar Messages

Maybe you are looking for