Performance issue with insert query !
Hi ,
I am using dbxml-2.4.16, my node-storage container is loaded with a large document ( 54MB xml ).
My document basically contains around 65k records in the same table ( 65k child nodes for one parent node ). I need to insert more records in to my DB, my insert XQuery is consuming a lot of time ( ~23 sec ) to insert one entry through command-line and around 50sec through code.
My container is indexed with "node-attribute-equality-string". The insert query I used:
insert nodes <NS:sampleEntry mySSIAddress='70011' modifier = 'create'><NS:sampleIPZone1Address>AABBCCDD</NS:sampleIPZone1Address><NS:myICMPFlag>1</NS:myICMPFlag><NS:myIngressFilter>1</NS:myIngressFilter><NS:myReadyTimer>4</NS:myReadyTimer><NS:myAPNNetworkID>ggsntest</NS:myAPNNetworkID><NS:myVPLMNFlag>2</NS:myVPLMNFlag><NS:myDAC>100</NS:myDAC><NS:myBcastLLIFlag>2</NS:myBcastLLIFlag><NS:sampleIPZone2Address>00000000</NS:sampleIPZone2Address><NS:sampleIPZone3Address>00000000</NS:sampleIPZone3Address><NS:sampleIPZone4Address>00000000</NS:sampleIPZone4Address><NS:sampleIPZone5Address>00000000</NS:sampleIPZone5Address><NS:sampleIPZone6Address>00000000</NS:sampleIPZone6Address><NS:sampleIPZone7Address>00000000</NS:sampleIPZone7Address></NS:sampleEntry> into doc('dbxml:/n_b_i_f_c_a_z.dbxml/doc_Running-SAMPLE')//NS:NS//NS:sampleTable)
If I modify my query with
into doc('dbxml:/n_b_i_f_c_a_z.dbxml/doc_Running-SAMPLE')//NS:sampleTable/NS:sampleEntry[@mySSIAddress='1']
insted of
into doc('dbxml:/n_b_i_f_c_a_z.dbxml/doc_Running-SAMPLE')//NS:NS//NS:sampleTable)
Time taken reduces only by 8 secs.
I have also tried to use insert "after", "before", "as first", "as last" , but there is no difference in performance.
Is anything wrong with my query, what should be the expected time to insert one record in a DB of 65k records.
Has anybody got any idea regarding this performance issue.
Kindly help me out.
Thanks,
Kapil.
Hi George,
Thanks for your reply.
Here is the info you requested,
dbxml> listIndexes
Index: unique-node-metadata-equality-string for node {http://www.sleepycat.com/2002/dbxml}:name
Index: node-attribute-equality-string for node {}:mySSIAddress
2 indexes found.
dbxml> info
Version: Oracle: Berkeley DB XML 2.4.16: (October 21, 2008)
Berkeley DB 4.6.21: (September 27, 2007)
Default container name: n_b_i_f_c_a_z.dbxml
Type of default container: NodeContainer
Index Nodes: on
Shell and XmlManager state:
Not transactional
Verbose: on
Query context state: LiveValues,Eager
The insery query with update takes ~32 sec ( shown below )
time query "declare namespace foo='MY-SAMPLE';declare namespace NS='NS';insert nodes <NS:sampleEntry mySSIAddress='70000' modifier = 'create' ><NS:sampleIPZone1Address>AABBCCDD</NS:sampleIPZone1Address><NS:myICMPFlag>1</NS:myICMPFlag><NS:myIngressFilter>1</NS:myIngressFilter><NS:myReadyTimer>4</NS:myReadyTimer><NS:myAPNNetworkID>ggsntest</NS:myAPNNetworkID><NS:myVPLMNFlag>2</NS:myVPLMNFlag><NS:myDAC>100</NS:myDAC><NS:myBcastLLIFlag>2</NS:myBcastLLIFlag><NS:sampleIPZone2Address>00000000</NS:sampleIPZone2Address><NS:sampleIPZone3Address>00000000</NS:sampleIPZone3Address><NS:sampleIPZone4Address>00000000</NS:sampleIPZone4Address><NS:sampleIPZone5Address>00000000</NS:sampleIPZone5Address><NS:sampleIPZone6Address>00000000</NS:sampleIPZone6Address><NS:sampleIPZone7Address>00000000</NS:sampleIPZone7Address></NS:sampleEntry> into doc('dbxml:/n_b_i_f_c_a_z.dbxml/doc_Running-SAMPLE')//NS:NS//NS:sampleTable"
Time in seconds for command 'query': 32.5002
and the query without the updation part takes ~14 sec ( shown below )
time query "declare namespace foo='MY-SAMPLE';declare namespace NS='NS'; doc('dbxml:/n_b_i_f_c_a_z.dbxml/doc_Running-SAMPLE')//NS:NS//NS:sampleTable"
Time in seconds for command 'query': 13.7289
The query :
time query "declare namespace foo='MY-SAMPLE';declare namespace NS='NS'; doc('dbxml:/n_b_i_f_c_a_z.dbxml/doc_Running-SAMPLE')//PMB:sampleTable/PMB:sampleEntry[@mySSIAddress='1000']"
Time in seconds for command 'query': 0.005375
is very fast.
The Updation of the document seems to consume much of the time.
Regards,
Kapil.
Similar Messages
-
Performance Issue with sql query
Hi,
My db is 10.2.0.5 with RAC on ASM, Cluster ware version 10.2.0.5.
With bsoa table as
SQL> desc bsoa;
Name Null? Type
ID NOT NULL NUMBER
LOGIN_TIME DATE
LOGOUT_TIME DATE
SUCCESSFUL_IND VARCHAR2(1)
WORK_STATION_NAME VARCHAR2(80)
OS_USER VARCHAR2(30)
USER_NAME NOT NULL VARCHAR2(30)
FORM_ID NUMBER
AUDIT_TRAIL_NO NUMBER
CREATED_BY VARCHAR2(30)
CREATION_DATE DATE
LAST_UPDATED_BY VARCHAR2(30)
LAST_UPDATE_DATE DATE
SITE_NO NUMBER
SESSION_ID NUMBER(8)
The query
UPDATE BSOA SET LOGOUT_TIME =SYSDATE WHERE SYS_CONTEXT('USERENV', 'SESSIONID') = SESSION_ID
Is taking a lot of time to execute and in AWR reports also it is on top in
1. SQL Order by elapsed time
2. SQL order by reads
3. SQL order by gets
So i am trying a way to solve the performance issue as the application is slow specially during login and logout time.
I understand that the function in the where condition cause to do FTS, but i can not think what other parts to look at.
Also:
SQL> SELECT COUNT(1) FROM BSOA;
COUNT(1)
7800373
The explain plan for "UPDATE BSOA SET LOGOUT_TIME =SYSDATE WHERE SYS_CONTEXT('USERENV', 'SESSIONID') = SESSION_ID" is
{code}
PLAN_TABLE_OUTPUT
Plan hash value: 1184960901
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | 1 | 26 | 18748 (3)| 00:03:45 |
| 1 | UPDATE | BSOA | | | | |
|* 2 | TABLE ACCESS FULL| BSOA | 1 | 26 | 18748 (3)| 00:03:45 |
Predicate Information (identified by operation id):
2 - filter("SESSION_ID"=TO_NUMBER(SYS_CONTEXT('USERENV','SESSIONID')))
{code}Hi,
There are also triggers before update and AUDITS on this table.
CREATE OR REPLACE TRIGGER B2.TRIGGER1
BEFORE UPDATE
ON B2.BSOA REFERENCING OLD AS OLD NEW AS NEW
FOR EACH ROW
:NEW.LAST_UPDATED_BY := USER ;
:NEW.LAST_UPDATE_DATE := SYSDATE ;
END;
CREATE OR REPLACE TRIGGER B2.TRIGGER2
BEFORE INSERT
ON B2.BSOA REFERENCING OLD AS OLD NEW AS NEW
FOR EACH ROW
:NEW.CREATED_BY := USER ;
:NEW.CREATION_DATE := SYSDATE ;
:NEW.LAST_UPDATED_BY := USER ;
:NEW.LAST_UPDATE_DATE := SYSDATE ;
END;
And also there is an audit on this table
AUDIT UPDATE ON B2.BSOA BY ACCESS WHENEVER SUCCESSFUL;
AUDIT UPDATE ON B2.BSOA BY ACCESS WHENEVER NOT SUCCESSFUL;
And the sessionid column in BSOA has height balanced histogram.
When i create an index i get the following error. As i am on 10g I can't use DDL_LOCK_TIMEOUT . I may have to wait for next down time.
SQL> CREATE INDEX B2.BSOA_SESSID_I ON B2.BSOA(SESSION_ID) TABLESPACE B2 COMPUTE STATISTICS;
CREATE INDEX B2.BSOA_SESSID_I ON B2.BSOA(SESSION_ID) TABLESPACE B2 COMPUTE STATISTICS
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
Thanks -
Performance issue with select query
Hi friends ,
This is my select query which is taking so much time to retrive the records.CAn Any one help me in solving this performance issue.
*- Get the Goods receipts mainly selected per period (=> MKPF secondary
SELECT msegebeln msegebelp mseg~werks
ekkobukrs ekkolifnr ekkozterm ekkoekorg ekko~ekgrp
ekkoinco1 ekkoexnum
lfa1name1 lfa1land1 lfa1ktokk lfa1stceg
mkpfmblnr mkpfmjahr msegzeile mkpfbldat mkpf~budat
mseg~bwart
*Start of changes for CIP 6203752 by PGOX02
mseg~smbln
*End of changes for CIP 6203752 by PGOX02
ekpomatnr ekpotxz01 ekpomenge ekpomeins
ekbemenge ekbedmbtr ekbewrbtr ekbewaers
ekpolgort ekpomatkl ekpowebaz ekpokonnr ekpo~ktpnr
ekpoplifz ekpobstae
INTO TABLE it_temp
FROM mkpf JOIN mseg ON msegmblnr EQ mkpfmblnr
AND msegmjahr EQ mkpfmjahr
JOIN ekbe ON ekbeebeln EQ msegebeln
AND ekbeebelp EQ msegebelp
AND ekbe~zekkn EQ '00'
AND ekbe~vgabe EQ '1'
AND ekbegjahr EQ msegmjahr
AND ekbebelnr EQ msegmblnr
AND ekbebuzei EQ msegzeile
JOIN ekpo ON ekpoebeln EQ ekbeebeln
AND ekpoebelp EQ ekbeebelp
JOIN ekko ON ekkoebeln EQ ekpoebeln
JOIN lfa1 ON lfa1lifnr EQ ekkolifnr
WHERE mkpf~budat IN so_budat
AND mkpf~bldat IN so_bldat
AND mkpf~vgart EQ 'WE'
AND mseg~bwart IN so_bwart
AND mseg~matnr IN so_matnr
AND mseg~werks IN so_werks
AND mseg~lifnr IN so_lifnr
AND mseg~ebeln IN so_ebeln
AND ekko~ekgrp IN so_ekgrp
AND ekko~bukrs IN so_bukrs
AND ekpo~matkl IN so_matkl
AND ekko~bstyp IN so_bstyp
AND ekpo~loekz EQ space
AND ekpo~plifz IN so_plifz.
Thanks & Regards,
Manoj Kumar .Thatha
Moderator message - Please see Please Read before Posting in the Performance and Tuning Forum before posting and please use code tags when posting code - post locked
Edited by: Rob Burbank on Feb 4, 2010 9:03 AMHi friends ,
This is my select query which is taking so much time to retrive the records.CAn Any one help me in solving this performance issue.
*- Get the Goods receipts mainly selected per period (=> MKPF secondary
SELECT msegebeln msegebelp mseg~werks
ekkobukrs ekkolifnr ekkozterm ekkoekorg ekko~ekgrp
ekkoinco1 ekkoexnum
lfa1name1 lfa1land1 lfa1ktokk lfa1stceg
mkpfmblnr mkpfmjahr msegzeile mkpfbldat mkpf~budat
mseg~bwart
*Start of changes for CIP 6203752 by PGOX02
mseg~smbln
*End of changes for CIP 6203752 by PGOX02
ekpomatnr ekpotxz01 ekpomenge ekpomeins
ekbemenge ekbedmbtr ekbewrbtr ekbewaers
ekpolgort ekpomatkl ekpowebaz ekpokonnr ekpo~ktpnr
ekpoplifz ekpobstae
INTO TABLE it_temp
FROM mkpf JOIN mseg ON msegmblnr EQ mkpfmblnr
AND msegmjahr EQ mkpfmjahr
JOIN ekbe ON ekbeebeln EQ msegebeln
AND ekbeebelp EQ msegebelp
AND ekbe~zekkn EQ '00'
AND ekbe~vgabe EQ '1'
AND ekbegjahr EQ msegmjahr
AND ekbebelnr EQ msegmblnr
AND ekbebuzei EQ msegzeile
JOIN ekpo ON ekpoebeln EQ ekbeebeln
AND ekpoebelp EQ ekbeebelp
JOIN ekko ON ekkoebeln EQ ekpoebeln
JOIN lfa1 ON lfa1lifnr EQ ekkolifnr
WHERE mkpf~budat IN so_budat
AND mkpf~bldat IN so_bldat
AND mkpf~vgart EQ 'WE'
AND mseg~bwart IN so_bwart
AND mseg~matnr IN so_matnr
AND mseg~werks IN so_werks
AND mseg~lifnr IN so_lifnr
AND mseg~ebeln IN so_ebeln
AND ekko~ekgrp IN so_ekgrp
AND ekko~bukrs IN so_bukrs
AND ekpo~matkl IN so_matkl
AND ekko~bstyp IN so_bstyp
AND ekpo~loekz EQ space
AND ekpo~plifz IN so_plifz.
Thanks & Regards,
Manoj Kumar .Thatha
Moderator message - Please see Please Read before Posting in the Performance and Tuning Forum before posting and please use code tags when posting code - post locked
Edited by: Rob Burbank on Feb 4, 2010 9:03 AM -
Performance issue with select query and for all entries.
hi,
i have a report to be performance tuned.
the database table has around 20 million entries and 25 fields.
so, the report fetches the distinct values of two fields using one select query.
so, the first select query fetches around 150 entries from the table for 2 fields.
then it applies some logic and eliminates some entries and makes entries around 80-90...
and then it again applies the select query on the same table using for all entries applied on the internal table with 80-90 entries...
in short,
it accesses the same database table twice.
so, i tried to get the database table in internal table and apply the logic on internal table and delete the unwanted entries.. but it gave me memory dump, and it wont take that huge amount of data into abap memory...
is around 80-90 entries too much for using "for all entries"?
the logic that is applied to eliminate the entries from internal table is too long, and hence cannot be converted into where clause to convert it into single select..
i really cant find the way out...
please help.chinmay kulkarni wrote:Chinmay,
Even though you tried to ask the question with detailed explanation, unfortunately it is still not clear.
It is perfectly fine to access the same database twice. If that is working for you, I don't think there is any need to change the logic. As Rob mentioned, 80 or 8000 records is not a problem in "for all entries" clause.
>
> so, i tried to get the database table in internal table and apply the logic on internal table and delete the unwanted entries.. but it gave me memory dump, and it wont take that huge amount of data into abap memory...
>
It is not clear what you tried to do here. Did you try to bring all 20 million records into an internal table? That will certainly cause the program to short dump with memory shortage.
> the logic that is applied to eliminate the entries from internal table is too long, and hence cannot be converted into where clause to convert it into single select..
>
That is fine. Actually, it is better (performance wise) to do much of the work in ABAP than writing a complex WHERE clause that might bog down the database. -
Performance issue with infoset query
Dear Experts,
when i trying to run a query based on infoset. the execution time of the query is very high. when i try to see the query designer i have got the following warning...
Warning Message :
Diagnosis
InfoProvider XXXX does not contain characteristic 0CALYEAR. The exception aggregation for key figure XXXX can therefore not be applied.
System Response
The key figure will therefore be aggregated using all characteristics of XXXXX with the generic aggregation SUM.
could anyone can guide me how to check at the infoset level to resolve this issue....
Thanks,
Mannu!Hi Mannu.
Go to change mode in your InfoSet and identify the Char 0CALYEAR. Check whether it is selected (click the box beside 0CALYEAR).
This needs to be done, because the exception aggregation can occur only for the fields available in the BEx Query!
Since its not available, it is trying to aggregate based on all available fields selected in Infoset. This may be the reasong to your performace issue.
Make this setting and I hope your issue will get resolved. Do post the outcome.
Cheers,
VA
Edited by: Vishwa Anand on Sep 6, 2010 5:15 PM -
Performance issue with this query.
Hi Experts,
This query is fetching 500 records.
SELECT
RECIPIENT_ID ,FAX_STATUS
FROM
FAX_STAGE WHERE LOWER(FAX_STATUS) like 'moved to%'
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 159K| 10M| 2170 (1)|
| 1 | TABLE ACCESS BY INDEX ROWID| FAX_STAGE | 159K| 10M| 2170 (1)|
| 2 | INDEX RANGE SCAN | INDX_FAX_STATUS_RAM | 28786 | | 123 (0)|
Note
- 'PLAN_TABLE' is old version
Statistics
1 recursive calls
0 db block gets
21 consistent gets
0 physical reads
0 redo size
937 bytes sent via SQL*Net to client
375 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
19 rows processed
Total number of records in the table.
SELECT COUNT(*) FROM FAX_STAGE--3679418
Distinct reccords are low for this column.
SELECT DISTINCT FAX_STATUS FROM FAX_STAGE;
Completed
BROKEN
Broken - New
moved to - America
MOVED to - Australia
Moved to Canada and australia
Functional based indexe on FAX_STAGE(LOWER(FAX_STATUS))
stats are upto date.
Still the cost is high
How to improve the performance of this query.
Please help me.
Thanks in advance.With no heavy activity on your fax_stage table a bitmap index might do better - see CREATE INDEX
I would try FTS (Full Table Scan) first as 6 vs. 3679418 is low cardinality for sure so using an index is not very helpful in this case (maybe too much Exadata oriented)
There's a lot of web pages where you can read: full table scans are not always evil and indexes are not always good or vice versa Ask Tom &quot;How to avoid the full table scan&quot;
Regards
Etbin -
Performance Issue with the query
Hi Experts,
While working on peoplesoft, today I was stuck with a problem when one of the Query is performing really bad. With all the statistics updates, query is not performing good. On one of the table, query is spending time doing lot of IO. (db file sequential read wait). And if I delete the stats for the table and let dynamic sampling to take place, query just works good and there is no IO wait on the table.
Here is the query
SELECT A.BUSINESS_UNIT_PC, A.PROJECT_ID, E.DESCR, A.EMPLID, D.NAME, C.DESCR, A.TRC,
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD'), 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 1, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 2, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 3, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 4, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 5, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 6, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 7, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 8, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 9, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 10, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 11, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 12, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 13, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 14, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 15, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 16, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 17, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 18, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 19, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 20, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 21, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 22, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 23, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 24, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 25, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 26, 'DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 6, 5), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 27, 'MM-DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 6, 5), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 28, 'MM-DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 6, 5), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 29, 'MM-DD'), A.TL_QUANTITY, 0)),
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 6, 5), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 30, 'MM-DD'), A.TL_QUANTITY, 0)),
SUM( A.EST_GROSS),
DECODE( A.TRC, 'ROVA1', 0, 'ROVA2', 0, ( SUM( A.EST_GROSS)/100) * 9.75),
'2012-07-01',
'2012-07-31',
SUM( DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD'), 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 1, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 2, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 3, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 4, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 5, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 6, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 7, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 8, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 9, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 10, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 11, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 12, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 13, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 14, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 15, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 16, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 17, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 18, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 19, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 20, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 21, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 22, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 23, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 24, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 25, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 9, 2), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 26, 'DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 6, 5), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 27, 'MM-DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 6, 5), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 28, 'MM-DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 6, 5), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 29, 'MM-DD'), A.TL_QUANTITY, 0) +
DECODE(SUBSTR( TO_CHAR(A.DUR,'YYYY-MM-DD'), 6, 5), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD') + 30, 'MM-DD'), A.TL_QUANTITY, 0)
DECODE( A.CURRENCY_CD, 'USD', '$', 'GBP', '£', 'EUR', '€', 'AED', 'D', 'NGN', 'N', ' '),
DECODE(SUBSTR( F.GP_PAYGROUP, 1, 2), 'NG', 'NG', F.PER_ORG),
DECODE(TO_CHAR(to_date('2012-07-31', 'YYYY-MM-DD'), 'MM'),
TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD'), 'MM'),
TO_CHAR(to_date('2012-07-31', 'YYYY-MM-DD'), 'Mon ')
|| TO_CHAR(to_date('2012-07-31', 'YYYY-MM-DD'), 'YYYY'), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD'), 'Mon ')
|| TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD'), 'YYYY') || ' / ' || TO_CHAR(to_date('2012-07-31', 'YYYY-MM-DD'), 'Mon ')
|| TO_CHAR(to_date('2012-07-31', 'YYYY-MM-DD'), 'YYYY')),
C.TRC, TO_CHAR(C.EFFDT,'YYYY-MM-DD'),
E.BUSINESS_UNIT,
E.PROJECT_ID
FROM
PS_TL_PAYABLE_TIME A,
PS_TL_TRC_TBL C,
PS_PROJECT E,
PS_PERSONAL_DATA D,
PS_PERALL_SEC_QRY D1,
PS_JOB F,
PS_EMPLMT_SRCH_QRY F1
WHERE
D.EMPLID = D1.EMPLID
AND D1.OPRID = 'TMANI'
AND F.EMPLID = F1.EMPLID
AND F.EMPL_RCD = F1.EMPL_RCD
AND F1.OPRID = 'TMANI'
AND A.DUR BETWEEN TO_DATE('2012-07-01','YYYY-MM-DD') AND TO_DATE('2012-07-31','YYYY-MM-DD')
AND C.TRC = A.TRC
AND C.EFFDT = (SELECT
MAX(C_ED.EFFDT)
FROM
PS_TL_TRC_TBL C_ED
WHERE
C.TRC = C_ED.TRC
AND C_ED.EFFDT <= SYSDATE
AND E.BUSINESS_UNIT = A.BUSINESS_UNIT_PC
AND E.PROJECT_ID = A.PROJECT_ID
AND A.EMPLID = D.EMPLID
AND A.EMPLID = F.EMPLID
AND A.EMPL_RCD = F.EMPL_RCD
AND F.EFFDT = (SELECT
MAX(F_ED.EFFDT)
FROM
PS_JOB F_ED
WHERE
F.EMPLID = F_ED.EMPLID
AND F.EMPL_RCD = F_ED.EMPL_RCD
AND F_ED.EFFDT <= SYSDATE
AND F.EFFSEQ = (SELECT
MAX(F_ES.EFFSEQ)
FROM
PS_JOB F_ES
WHERE
F.EMPLID = F_ES.EMPLID
AND F.EMPL_RCD = F_ES.EMPL_RCD
AND F.EFFDT = F_ES.EFFDT
AND F.GP_PAYGROUP = DECODE(' ', ' ', F.GP_PAYGROUP, ' ')
AND A.CURRENCY_CD = DECODE(' ', ' ', A.CURRENCY_CD, ' ')
AND DECODE(SUBSTR( F.GP_PAYGROUP, 1, 2), 'NG', 'L', DECODE( F.PER_ORG, 'CWR', 'L', 'E')) = DECODE(' ', ' ', DECODE(SUBSTR( F.GP_PAYGROUP, 1, 2), 'NG', 'L', DECODE( F.PER_ORG, 'CWR', 'L', 'E')), 'L', 'L', 'E', 'E', 'A', DECODE(SUBSTR( F.GP_PAYGROUP, 1, 2), 'NG', 'L', DECODE( F.PER_ORG, 'CWR', 'L', 'E')))
AND ( A.EMPLID, A.EMPL_RCD) IN (SELECT
B.EMPLID,
B.EMPL_RCD
FROM
PS_TL_GROUP_DTL B
WHERE
B.TL_GROUP_ID = DECODE('ER012', ' ', B.TL_GROUP_ID, 'ER012')
AND E.PROJECT_USER1 = DECODE(' ', ' ', E.PROJECT_USER1, ' ')
AND A.PROJECT_ID = DECODE(' ', ' ', A.PROJECT_ID, ' ')
AND A.PAYABLE_STATUS <>
CASE
WHEN to_number(TO_CHAR(sysdate, 'DD')) < 15
THEN
CASE
WHEN A.DUR > last_day(add_months(sysdate, -2))
THEN ' '
ELSE 'NA'
END
ELSE
CASE
WHEN A.DUR > last_day(add_months(sysdate, -1))
THEN ' '
ELSE 'NA'
END
END
AND A.EMPLID = DECODE(' ', ' ', A.EMPLID, ' ')
GROUP BY A.BUSINESS_UNIT_PC,
A.PROJECT_ID,
E.DESCR,
A.EMPLID,
D.NAME,
C.DESCR,
A.TRC,
'2012-07-01',
'2012-07-31',
DECODE( A.CURRENCY_CD, 'USD', '$', 'GBP', '£', 'EUR', '€', 'AED', 'D', 'NGN', 'N', ' '),
DECODE(SUBSTR( F.GP_PAYGROUP, 1, 2), 'NG', 'NG', F.PER_ORG),
DECODE(TO_CHAR(to_date('2012-07-31', 'YYYY-MM-DD'), 'MM'), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD'), 'MM'), TO_CHAR(to_date('2012-07-31', 'YYYY-MM-DD'), 'Mon ')
|| TO_CHAR(to_date('2012-07-31', 'YYYY-MM-DD'), 'YYYY'), TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD'), 'Mon ')
|| TO_CHAR(to_date('2012-07-01', 'YYYY-MM-DD'), 'YYYY') || ' / '
|| TO_CHAR(to_date('2012-07-31', 'YYYY-MM-DD'), 'Mon ') || TO_CHAR(to_date('2012-07-31', 'YYYY-MM-DD'), 'YYYY')),
C.TRC, TO_CHAR(C.EFFDT,'YYYY-MM-DD'),
E.BUSINESS_UNIT, E.PROJECT_ID
HAVING SUM( A.EST_GROSS) <> 0
ORDER BY 1,
2,
5,
6 ;Here is the screenshot for IO wait
[https://lh4.googleusercontent.com/-6PFW2FSK3yE/UCrwUbZ0pvI/AAAAAAAAAPA/eHM48AOC0Uo]
Edited by: Oceaner on Aug 14, 2012 5:38 PMHere is the execution plan with all the statistics present
PLAN_TABLE_OUTPUT
Plan hash value: 1575300420
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 237 | 2703 (1)| 00:00:33 |
|* 1 | FILTER | | | | | |
| 2 | SORT GROUP BY | | 1 | 237 | | |
| 3 | CONCATENATION | | | | | |
|* 4 | FILTER | | | | | |
|* 5 | FILTER | | | | | |
|* 6 | HASH JOIN | | 1 | 237 | 1695 (1)| 00:00:21 |
|* 7 | HASH JOIN | | 1 | 204 | 1689 (1)| 00:00:21 |
|* 8 | HASH JOIN SEMI | | 1 | 193 | 1352 (1)| 00:00:17 |
| 9 | NESTED LOOPS | | | | | |
| 10 | NESTED LOOPS | | 1 | 175 | 1305 (1)| 00:00:16 |
|* 11 | HASH JOIN | | 1 | 148 | 1304 (1)| 00:00:16 |
| 12 | JOIN FILTER CREATE | :BF0000 | | | | |
| 13 | NESTED LOOPS | | | | | |
| 14 | NESTED LOOPS | | 1 | 134 | 967 (1)| 00:00:12 |
| 15 | NESTED LOOPS | | 1 | 103 | 964 (1)| 00:00:12 |
|* 16 | TABLE ACCESS FULL | PS_PROJECT | 197 | 9062 | 278 (1)| 00:00:04 |
|* 17 | TABLE ACCESS BY INDEX ROWID | PS_TL_PAYABLE_TIME | 1 | 57 | 7 (0)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | IDX$$_C44D0007 | 16 | | 3 (0)| 00:00:01 |
|* 19 | INDEX RANGE SCAN | IDX$$_3F450003 | 1 | | 2 (0)| 00:00:01 |
|* 20 | TABLE ACCESS BY INDEX ROWID | PS_JOB | 1 | 31 | 3 (0)| 00:00:01 |
| 21 | VIEW | PS_EMPLMT_SRCH_QRY | 5428 | 75992 | 336 (2)| 00:00:05 |
PLAN_TABLE_OUTPUT
| 22 | SORT UNIQUE | | 5428 | 275K| 336 (2)| 00:00:05 |
|* 23 | FILTER | | | | | |
| 24 | JOIN FILTER USE | :BF0000 | 55671 | 2827K| 335 (1)| 00:00:05 |
| 25 | NESTED LOOPS | | 55671 | 2827K| 335 (1)| 00:00:05 |
| 26 | TABLE ACCESS BY INDEX ROWID| PSOPRDEFN | 1 | 20 | 2 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | PS_PSOPRDEFN | 1 | | 1 (0)| 00:00:01 |
|* 28 | TABLE ACCESS FULL | PS_SJT_PERSON | 55671 | 1739K| 333 (1)| 00:00:04 |
| 29 | CONCATENATION | | | | | |
| 30 | NESTED LOOPS | | 1 | 63 | 2 (0)| 00:00:01 |
|* 31 | INDEX FAST FULL SCAN | PSASJT_OPR_CLS | 1 | 24 | 2 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 63 | 1 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 36 | NESTED LOOPS | | 1 | 63 | 1 (0)| 00:00:01 |
|* 37 | INDEX UNIQUE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
|* 39 | INDEX UNIQUE SCAN | PS_PERSONAL_DATA | 1 | | 0 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | PS_PERSONAL_DATA | 1 | 27 | 1 (0)| 00:00:01 |
|* 41 | INDEX FAST FULL SCAN | PS_TL_GROUP_DTL | 323 | 5814 | 47 (3)| 00:00:01 |
| 42 | VIEW | PS_PERALL_SEC_QRY | 7940 | 87340 | 336 (2)| 00:00:05 |
| 43 | SORT UNIQUE | | 7940 | 379K| 336 (2)| 00:00:05 |
|* 44 | FILTER | | | | | |
|* 45 | FILTER | | | | | |
| 46 | NESTED LOOPS | | 55671 | 2663K| 335 (1)| 00:00:05 |
| 47 | TABLE ACCESS BY INDEX ROWID | PSOPRDEFN | 1 | 20 | 2 (0)| 00:00:01 |
|* 48 | INDEX UNIQUE SCAN | PS_PSOPRDEFN | 1 | | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|* 49 | TABLE ACCESS FULL | PS_SJT_PERSON | 55671 | 1576K| 333 (1)| 00:00:04 |
| 50 | CONCATENATION | | | | | |
| 51 | NESTED LOOPS | | 1 | 63 | 2 (0)| 00:00:01 |
|* 52 | INDEX FAST FULL SCAN | PSASJT_OPR_CLS | 1 | 24 | 2 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 54 | NESTED LOOPS | | 1 | 63 | 1 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 57 | CONCATENATION | | | | | |
| 58 | NESTED LOOPS | | 1 | 63 | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
|* 60 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 61 | NESTED LOOPS | | 1 | 63 | 1 (0)| 00:00:01 |
|* 62 | INDEX UNIQUE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 64 | NESTED LOOPS | | 1 | 63 | 3 (0)| 00:00:01 |
| 65 | INLIST ITERATOR | | | | | |
|* 66 | INDEX RANGE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 2 (0)| 00:00:01 |
|* 67 | INDEX RANGE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
| 68 | TABLE ACCESS FULL | PS_TL_TRC_TBL | 922 | 30426 | 6 (0)| 00:00:01 |
| 69 | SORT AGGREGATE | | 1 | 20 | | |
|* 70 | INDEX RANGE SCAN | PSAJOB | 1 | 20 | 3 (0)| 00:00:01 |
| 71 | SORT AGGREGATE | | 1 | 14 | | |
|* 72 | INDEX RANGE SCAN | PS_TL_TRC_TBL | 2 | 28 | 2 (0)| 00:00:01 |
| 73 | SORT AGGREGATE | | 1 | 23 | | |
|* 74 | INDEX RANGE SCAN | PSAJOB | 1 | 23 | 3 (0)| 00:00:01 |
|* 75 | FILTER | | | | | |
PLAN_TABLE_OUTPUT
|* 76 | FILTER | | | | | |
|* 77 | HASH JOIN | | 1 | 237 | 974 (2)| 00:00:12 |
|* 78 | HASH JOIN | | 1 | 226 | 637 (1)| 00:00:08 |
|* 79 | HASH JOIN | | 1 | 193 | 631 (1)| 00:00:08 |
| 80 | NESTED LOOPS | | | | | |
| 81 | NESTED LOOPS | | 1 | 179 | 294 (1)| 00:00:04 |
| 82 | NESTED LOOPS | | 1 | 152 | 293 (1)| 00:00:04 |
| 83 | NESTED LOOPS | | 1 | 121 | 290 (1)| 00:00:04 |
|* 84 | HASH JOIN SEMI | | 1 | 75 | 289 (1)| 00:00:04 |
|* 85 | TABLE ACCESS BY INDEX ROWID | PS_TL_PAYABLE_TIME | 1 | 57 | 242 (0)| 00:00:03 |
|* 86 | INDEX SKIP SCAN | IDX$$_C44D0007 | 587 | | 110 (0)| 00:00:02 |
|* 87 | INDEX FAST FULL SCAN | PS_TL_GROUP_DTL | 323 | 5814 | 47 (3)| 00:00:01 |
|* 88 | TABLE ACCESS BY INDEX ROWID | PS_PROJECT | 1 | 46 | 1 (0)| 00:00:01 |
|* 89 | INDEX UNIQUE SCAN | PS_PROJECT | 1 | | 0 (0)| 00:00:01 |
|* 90 | TABLE ACCESS BY INDEX ROWID | PS_JOB | 1 | 31 | 3 (0)| 00:00:01 |
|* 91 | INDEX RANGE SCAN | IDX$$_3F450003 | 1 | | 2 (0)| 00:00:01 |
|* 92 | INDEX UNIQUE SCAN | PS_PERSONAL_DATA | 1 | | 0 (0)| 00:00:01 |
| 93 | TABLE ACCESS BY INDEX ROWID | PS_PERSONAL_DATA | 1 | 27 | 1 (0)| 00:00:01 |
| 94 | VIEW | PS_EMPLMT_SRCH_QRY | 5428 | 75992 | 336 (2)| 00:00:05 |
| 95 | SORT UNIQUE | | 5428 | 275K| 336 (2)| 00:00:05 |
|* 96 | FILTER | | | | | |
| 97 | NESTED LOOPS | | 55671 | 2827K| 335 (1)| 00:00:05 |
| 98 | TABLE ACCESS BY INDEX ROWID | PSOPRDEFN | 1 | 20 | 2 (0)| 00:00:01 |
|* 99 | INDEX UNIQUE SCAN | PS_PSOPRDEFN | 1 | | 1 (0)| 00:00:01 |
|*100 | TABLE ACCESS FULL | PS_SJT_PERSON | 55671 | 1739K| 333 (1)| 00:00:04 |
| 101 | CONCATENATION | | | | | |
| 102 | NESTED LOOPS | | 1 | 63 | 2 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|*103 | INDEX FAST FULL SCAN | PSASJT_OPR_CLS | 1 | 24 | 2 (0)| 00:00:01 |
|*104 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 105 | NESTED LOOPS | | 1 | 63 | 1 (0)| 00:00:01 |
|*106 | INDEX UNIQUE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
|*107 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 108 | NESTED LOOPS | | 1 | 63 | 1 (0)| 00:00:01 |
|*109 | INDEX UNIQUE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
|*110 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 111 | TABLE ACCESS FULL | PS_TL_TRC_TBL | 922 | 30426 | 6 (0)| 00:00:01 |
| 112 | VIEW | PS_PERALL_SEC_QRY | 7940 | 87340 | 336 (2)| 00:00:05 |
| 113 | SORT UNIQUE | | 7940 | 379K| 336 (2)| 00:00:05 |
|*114 | FILTER | | | | | |
|*115 | FILTER | | | | | |
| 116 | NESTED LOOPS | | 55671 | 2663K| 335 (1)| 00:00:05 |
| 117 | TABLE ACCESS BY INDEX ROWID | PSOPRDEFN | 1 | 20 | 2 (0)| 00:00:01 |
|*118 | INDEX UNIQUE SCAN | PS_PSOPRDEFN | 1 | | 1 (0)| 00:00:01 |
|*119 | TABLE ACCESS FULL | PS_SJT_PERSON | 55671 | 1576K| 333 (1)| 00:00:04 |
| 120 | CONCATENATION | | | | | |
| 121 | NESTED LOOPS | | 1 | 63 | 2 (0)| 00:00:01 |
|*122 | INDEX FAST FULL SCAN | PSASJT_OPR_CLS | 1 | 24 | 2 (0)| 00:00:01 |
|*123 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 124 | NESTED LOOPS | | 1 | 63 | 1 (0)| 00:00:01 |
|*125 | INDEX UNIQUE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
|*126 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 127 | CONCATENATION | | | | | |
| 128 | NESTED LOOPS | | 1 | 63 | 1 (0)| 00:00:01 |
|*129 | INDEX UNIQUE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|*130 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 131 | NESTED LOOPS | | 1 | 63 | 1 (0)| 00:00:01 |
|*132 | INDEX UNIQUE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
|*133 | INDEX UNIQUE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 0 (0)| 00:00:01 |
| 134 | NESTED LOOPS | | 1 | 63 | 3 (0)| 00:00:01 |
| 135 | INLIST ITERATOR | | | | | |
|*136 | INDEX RANGE SCAN | PSASJT_CLASS_ALL | 1 | 39 | 2 (0)| 00:00:01 |
|*137 | INDEX RANGE SCAN | PSASJT_OPR_CLS | 1 | 24 | 1 (0)| 00:00:01 |
| 138 | SORT AGGREGATE | | 1 | 20 | | |
|*139 | INDEX RANGE SCAN | PSAJOB | 1 | 20 | 3 (0)| 00:00:01 |
| 140 | SORT AGGREGATE | | 1 | 14 | | |
|*141 | INDEX RANGE SCAN | PS_TL_TRC_TBL | 2 | 28 | 2 (0)| 00:00:01 |
| 142 | SORT AGGREGATE | | 1 | 23 | | |
|*143 | INDEX RANGE SCAN | PSAJOB | 1 | 23 | 3 (0)| 00:00:01 |
| 144 | SORT AGGREGATE | | 1 | 14 | | |
|*145 | INDEX RANGE SCAN | PS_TL_TRC_TBL | 2 | 28 | 2 (0)| 00:00:01 |
| 146 | SORT AGGREGATE | | 1 | 20 | | |
|*147 | INDEX RANGE SCAN | PSAJOB | 1 | 20 | 3 (0)| 00:00:01 |
| 148 | SORT AGGREGATE | | 1 | 23 | | |
|*149 | INDEX RANGE SCAN | PSAJOB | 1 | 23 | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------------------Most of the IO wait occur at step 17. Though exlain plan simply doesnot show this thing..But when we run this query from Peoplesoft application (online page), this is visible through Grid control SQL Monitoring
Second part of the Question continues.... -
Performance issue with Spatial query
Need inputs to optimize a spatial query that takes 9 seconds to return 34410 rows. All tables have been analyzed. Plan shows indexes columns. Details below :
SELECT count(*) FROM (select ANT_DIR_GEOLOC , decode(D_UL_SQE_LOW,0,0,D_UL_SQE_LOW/D_UL_SQE_CHECK) as D_UL_SQE_BAD_SECTORS
from dae_admin.VIEW_D_UL_SQE_BAD_SECTOR G , SECTORS S Where G.SECTOR_ID = S.SECTOR_ID and WEEK_NUMBER=32 and
WEEK_NUMBER_YEAR=2007 and WEEKEND = 'N')
WHERE MDSYS.SDO_FILTER(ANT_DIR_GEOLOC, MDSYS.SDO_GEOMETRY(2003, 99900001,NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003,
3),MDSYS.SDO_ORDINATE_ARRAY(-1.06449263071068E7,3111428.11503326,-8140237.76425813,5605276.61542001)), 'querytype=WINDOW') ='TRUE'
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 146 | | 26699 (1)| 00:05:21 |
| 1 | SORT AGGREGATE | | 1 | 146 | | | |
|* 2 | HASH JOIN | | 1123 | 160K| | 26699 (1)| 00:05:21 |
| 3 | PARTITION RANGE ALL | | 1123 | 152K| | 603 (1)| 00:00:08 |
| 4 | TABLE ACCESS BY LOCAL INDEX ROWID | SECTORS | 1123 | 152K| | 603 (1)| 00:00:
|* 5 | DOMAIN INDEX | SECTORS_ANTDIR_SX | | | | | |
| 6 | VIEW | VIEW_D_UL_SQE_BAD_SECTOR | 20510 | 140K| | 26095 (1)| 00:05:14 |
| 7 | HASH GROUP BY | | 20510 | 901K| | 26095 (1)| 00:05:14 |
| 8 | VIEW | VIEW_D_UL_SQE_BAD_CARRIER | 984K| 42M| | 26095 (1)| 00:05:14 |
| 9 | HASH GROUP BY | | 984K| 73M| 180M| 26095 (1)| 00:05:14 |
| 10 | TABLE ACCESS BY LOCAL INDEX ROWID| FACT_DAILY_CHANNEL_STATS | 395K| 12M| | 603
| 11 | NESTED LOOPS | | 984K| 73M| | 8179 (1)| 00:01:39 |
| 12 | MERGE JOIN CARTESIAN | | 2 | 90 | | 4 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | NETWORK_PARAMETERS | 1 | 19 | | 2 (0)| 00:00
|* 14 | INDEX RANGE SCAN | NP_NAME_IDX | 1 | | | 1 (0)| 00:00:01 |
| 15 | BUFFER SORT | | 5 | 130 | | 2 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID | DIM_TIME | 5 | 130 | | 2 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | DIM_TIME_WEEK_3_IX | 5 | | | 1 (0)| 00:00:01 |
| 18 | PARTITION RANGE ITERATOR | | 395K| | | 2139 (1)| 00:00:26 |
|* 19 | INDEX RANGE SCAN | FA_DCC_EVENT_DATE_NP_ID | 395K| | | 2139 (1)| 00:00:26 |
CREATE OR REPLACE VIEW VIEW_D_UL_SQE_BAD_SECTOR
(SECTOR_ID, WEEK_NUMBER_YEAR, WEEK_NUMBER, WEEKEND, D_UL_SQE_LOW,
D_UL_SQE_CHECK)
AS
SELECT sector_id,
week_number_year,
week_number,
weekend,
SUM(d_ul_sqe_low) d_ul_sqe_low,
SUM(d_ul_sqe_check) d_ul_sqe_check
FROM view_d_ul_sqe_bad_carrier
GROUP BY sector_id, week_number_year, week_number, weekend
view_d_ul_sqe_bad_carrier:
SELECT /*+ index(f) */
f.sector_id,
f.channel,
f.br_id,
t.week_number_year,
t.week_number,
t.weekend,
SUM(f.np_value_numerator) d_ul_sqe_low,
SUM(f.np_value_denominator) d_ul_sqe_check
FROM fact_daily_channel_stats f, network_parameters p, dim_time t
WHERE f.np_id = p.np_id
AND f.event_date = t.event_date
AND p.name = 'DL_UL_SQE_LOW_RATE'
GROUP BY f.sector_id, f.channel, f.br_id, t.week_number_year, t.week_number, t.weekend
fact_daily_channel_stats is a table that isPartitioned on event date.Ivan - Yes, all the columns in the filter are indexed.
Row Count:
==========
fact_daily_channel_stats - 101263303
network_parameters - 168
SECTORS - 105216
dim_time - 7306
Any tip/ clue on re-writing the query would be of great help.
Rich - Below is the response from our Spatial Team :
1. Projection:
We are working in Mercator projection. Since Oracle has out of the box Mercator with datum NAD 27 (SRID=49155), and we needed Mercator with NAD 83, we defined our own projection with SRID = 99900001, which you are seeing in our query. Projection is defined as:
insert into sdo_coord_ref_system
SELECT 99900001, a.coord_ref_sys_name, a.coord_ref_sys_kind,
a.coord_sys_id, a.datum_id, 10076,
2000023, a.projection_conv_id, a.cmpd_horiz_srid,
a.cmpd_vert_srid, a.information_source, a.data_source,
a.is_legacy, a.legacy_code, 'PROJCS["Mercator", GEOGCS [ "NAD 83", DATUM ["NAD 83", SPHEROID ["GRS 80", 6378137, 298.257222101]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]], PROJECTION ["Mercator"], UNIT ["Meter", 1.000000000000]]', a.legacy_cs_bounds, a.is_valid, a.supports_sdo_geometry
FROM mdsys.sdo_coord_ref_sys a where srid=49155;
2. Metadata for SECTORS table is:
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES('SECTORS', 'GEOLOC',SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -20037566, 20037566, 1),
SDO_DIM_ELEMENT('Y', -71957574, 71957574, 1)),99900001);
which means tolerance is 1 meter.
3. Precision - I don't think we need to supply to MDSYS.SDO_FILTER coordinates with such great precision. Maybe rounding them (by dropping fractional part at all, 1 meter should be enough) would help. If not - then maybe we need to round coordinates we generate when converting from longitude/latitude to Mercator and store in SECTORS table. But on the other hand SECTORS table defines tolerance of 1 meter in metadata, and spatial index should use that tolerance. -
Performance issue with sql query. Please explain
I have a sql query
A.column1 and B.column1 are indexed.
Query1: select A.column1,A.column3, B.column2 from tableA , tableB where A.column1=B.column1;
query2: select A.column1,A.column3,B.column2,B.column4 from tableA , tableB where A.column1=B.column1;
1. Does both query takes same time? If not why?.
As they both go for same row with different number of columns. And Since the complete datablock is loaded in Database buffer cache. so there should not be extra time taken upto this time.
Please tell me if I am wrong.For me apart from required excessive bytes sent via SQL*Net to client as well bytes received via SQL*Net from client will cause to chatty network which will degrade the performance.
SQL> COLUMN plan_plus_exp FORMAT A100
SQL> SET LINESIZE 1000
SQL> SET AUTOTRACE TRACEONLY
SQL> SELECT *
2 FROM emp
3 /
14 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=14 Bytes=616)
1 0 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=3 Card=14 Bytes=616)
Statistics
1 recursive calls
0 db block gets
8 consistent gets
0 physical reads
0 redo size
1631 bytes sent via SQL*Net to client
423 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
14 rows processed
SQL> SELECT ename
2 FROM emp
3 /
14 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=14 Bytes=154)
1 0 TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=3 Card=14 Bytes=154)
Statistics
1 recursive calls
0 db block gets
8 consistent gets
0 physical reads
0 redo size
456 bytes sent via SQL*Net to client
423 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
14 rows processed Khurram -
Performance Issue with the Query urgent
is there any way to get the data for the material Rejected with Movement type 122 & 123 except MSEG table, as my report is very slow...
my query is as below : -
SELECT SUM( a~dmbtr )INTO value1
FROM mseg AS a INNER JOIN mkpf AS b
ON amblnr = bmblnr
AND amjahr = bmjahr
WHERE a~lifnr = p_lifnr
AND a~bwart IN ('122')
AND b~budat IN s_budat
GROUP BY lifnr.
ENDSELECT.
abhishek suppalHi Abhi,
Try like this ....
SELECT SUM( a~dmbtr )INTO value1
FROM mseg AS a INNER JOIN mkpf AS b
ON amblnr = bmblnr
AND amjahr = bmjahr
WHERE a~lifnr = p_lifnr
AND a~bwart IN ('122'<b>,'123'</b>)
AND b~budat IN s_budat
GROUP BY lifnr.
ENDSELECT.
or ...
define ranges...like
ranges: r_bwart for XXXX-bwart.
r_bwart-sign = 'I'.
r_bwart-option = 'EQ'.
r_bwart-low = 122.
append r_bwart.
r_bwart-low = 123.
append r_bwart.
now...
in select statement u just add
AND a~bwart IN r_bwart
Thanks
Eswar -
Performance issues with pipelined table functions
I am testing pipelined table functions to be able to re-use the <font face="courier">base_query</font> function. Contrary to my understanding, the <font face="courier">with_pipeline</font> procedure runs 6 time slower than the legacy <font face="courier">no_pipeline</font> procedure. Am I missing something? The <font face="courier">processor</font> function is from [url http://www.oracle-developer.net/display.php?id=429]improving performance with pipelined table functions .
Edit: The underlying query returns 500,000 rows in about 3 minutes. So there are are no performance issues with the query itself.
Many thanks in advance.
CREATE OR REPLACE PACKAGE pipeline_example
IS
TYPE resultset_typ IS REF CURSOR;
TYPE row_typ IS RECORD (colC VARCHAR2(200), colD VARCHAR2(200), colE VARCHAR2(200));
TYPE table_typ IS TABLE OF row_typ;
FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
RETURN resultset_typ;
c_default_limit CONSTANT PLS_INTEGER := 100;
FUNCTION processor (
p_source_data IN resultset_typ,
p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
RETURN table_typ
PIPELINED
PARALLEL_ENABLE(PARTITION p_source_data BY ANY);
PROCEDURE with_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ);
PROCEDURE no_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ);
END pipeline_example;
CREATE OR REPLACE PACKAGE BODY pipeline_example
IS
FUNCTION base_query (argA IN VARCHAR2, argB IN VARCHAR2)
RETURN resultset_typ
IS
o_resultset resultset_typ;
BEGIN
OPEN o_resultset FOR
SELECT colC, colD, colE
FROM some_table
WHERE colA = ArgA AND colB = argB;
RETURN o_resultset;
END base_query;
FUNCTION processor (
p_source_data IN resultset_typ,
p_limit_size IN PLS_INTEGER DEFAULT c_default_limit)
RETURN table_typ
PIPELINED
PARALLEL_ENABLE(PARTITION p_source_data BY ANY)
IS
aa_source_data table_typ;-- := table_typ ();
BEGIN
LOOP
FETCH p_source_data
BULK COLLECT INTO aa_source_data
LIMIT p_limit_size;
EXIT WHEN aa_source_data.COUNT = 0;
/* Process the batch of (p_limit_size) records... */
FOR i IN 1 .. aa_source_data.COUNT
LOOP
PIPE ROW (aa_source_data (i));
END LOOP;
END LOOP;
CLOSE p_source_data;
RETURN;
END processor;
PROCEDURE with_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ)
IS
BEGIN
OPEN o_resultset FOR
SELECT /*+ PARALLEL(t, 5) */ colC,
SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
SUM (CASE WHEN colD = colE AND colD != '0' THEN '1' END) de_one,
SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
FROM TABLE (processor (base_query (argA, argB),100)) t
GROUP BY colC
ORDER BY colC
END with_pipeline;
PROCEDURE no_pipeline (argA IN VARCHAR2,
argB IN VARCHAR2,
o_resultset OUT resultset_typ)
IS
BEGIN
OPEN o_resultset FOR
SELECT colC,
SUM (CASE WHEN colD > colE AND colE != '0' THEN colD / ColE END)de,
SUM (CASE WHEN colE > colD AND colD != '0' THEN colE / ColD END)ed,
SUM (CASE WHEN colD = colE AND colD != '0' THEN 1 END) de_one,
SUM (CASE WHEN colD = '0' OR colE = '0' THEN '0' END) de_zero
FROM (SELECT colC, colD, colE
FROM some_table
WHERE colA = ArgA AND colB = argB)
GROUP BY colC
ORDER BY colC;
END no_pipeline;
END pipeline_example;
ALTER PACKAGE pipeline_example COMPILE;Edited by: Earthlink on Nov 14, 2010 9:47 AM
Edited by: Earthlink on Nov 14, 2010 11:31 AM
Edited by: Earthlink on Nov 14, 2010 11:32 AM
Edited by: Earthlink on Nov 20, 2010 12:04 PM
Edited by: Earthlink on Nov 20, 2010 12:54 PMEarthlink wrote:
Contrary to my understanding, the <font face="courier">with_pipeline</font> procedure runs 6 time slower than the legacy <font face="courier">no_pipeline</font> procedure. Am I missing something? Well, we're missing a lot here.
Like:
- a database version
- how did you test
- what data do you have, how is it distributed, indexed
and so on.
If you want to find out what's going on then use a TRACE with wait events.
All nessecary steps are explained in these threads:
HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
Another nice one is RUNSTATS:
http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701 -
Performance Issues with large XML (1-1.5MB) files
Hi,
I'm using an XML Schema based Object relational storage for my XML documents which are typically 1-1.5 MB in size and having serious performance issues with XPath Query.
When I do XPath query against an element of SQLType varchar2, I get a good performance. But when I do a similar XPath query against an element of SQLType Collection (Varray of varchar2), I get a very ordinary performance.
I have also created indexes on extract() and analyzed my XMLType table and indexes, but I have no performance gain. Also, I have tried all sorts of storage options available for Collections ie. Varray's, Nested Tables, IOT's, LOB's, Inline, etc... and all these gave me same bad performance.
I even tried creating XMLType views based on XPath queries but the performance didn't improve much.
I guess I'm running out of options and patience as well.;)
I would appreciate any ideas/suggestions, please help.....
Thanks;
Ramakrishna ChintaAre you having similar symptoms as I am? http://discussions.apple.com/thread.jspa?threadID=2234792&tstart=0
-
Performance issues with respect scheme registration,select & insert query
I am facing performance issues with respect to schema registration,Select & insert query towards 10.2.0.3 version.It is taking around 45 minutes to register schema and it is taking around 5 min to insert a single document into xml db where as it was taking less than min to insert a single document into xml db of 9.2.0.6 version.Would like to know the issue and solution to resolve this issue.Please help me out on this as it is very urgent for me
Since it appears that this is an XML DB specific question, you're probably better off posting in the XML DB. The folks over there have much more experience with the ins and outs of that particular product.
Justin -
Performance issues with FDK in large XML documents
In my current project with FrameMaker 8 I'm experiencing severe performance issues with some FDK API calls.
The documents are about 3-8 MBytes in size. Fortmatted they cover 150-250 pages.
When importing such an XML document I do some extensive "post-processing" using FDK. This processing happens in Sr_EventHandler() during the SR_EVT_END_READER event. I noticed that some FDK functions calls which modify the document's structure, like F_ApiSetAttribute() or F_ApiNewElementInHierarchy(), take several seconds, for the larger documents even minutes, to complete one single function call. I tried to move some of these calls to earlier events, mostly to SR_EVT_END_ELEM. There the calls work without a delay. Unfortunately I can't rewrite the FDK client to move all the calls that are lagging to earlier events.
Does anybody have a clue why such delays happen, and possibly can make a suggestion, how to solve this issue? Thank you in advance.
PS: I already thought of splitting such a document in smaller pieces by using the FrameMaker book function. But I don't think, the structure of the documents will permit such an automatic split, and it definitely isn't an option to change the document structure (the project is about migrating documents from Interleaf to XML with the constraint of keeping the document layout identical).FP_ApplyFormatRules sounds really good--I'll give it a try on Monday. Wonder how I could miss it, as I already tried FP_Reformatting and FP_Displaying at no avail?! By the way, what is actually meant with FP_Reformatting (when I used it I assumed it would do exactly what FP_ApplyFormatRules sounds to do), or is that one another of Lynne's well-kept secrets?
Thank's for all the helpful suggestions, guys. On Friday I already had my first improvements in a test version of my client: I did some (not all necessary) structural changes using XSLT pre-processing, and processing went down from 8 hours(!) to 1 hour--Yeappie! I was also playing with the idea of writing a wrapper to F_ApiNewElementInHierarchy() which actually pastes an appropriate element created in a small flow on the reference pages at the intended insertion location. But now, with FP_ApplyFormatRules on the horizon, I'm quite confident to get even the complicated stuff under control, which cannot be handled by the XSLT pre-processing, as it is based on the actual formatting of the document at run-time and cannot be anticipated in pre-processing.
--Franz -
Performance problem with report query
Hi,
I am encountering a performance issue with a page returning a report.
I have a page that has a region which joins 2 tables. One table has about 220,00 rows, while the other contains roughly 60,000 rows. In the region source of the report region, the query includes join condition with local variables. For example, the page is page 70, and some join conditions are:
and a.id=:P70_ID
and a.name like :P70_NAME
I run the query that returns a large number of rows from sqlplus, and it takes less than 30 sec to complete.
When I run the page, the report took about 3 minutes to return.
In this case, :P70_NAME is initialized to '%' on the page.
I then tried to substitute variable value directly in the query:
and a.id=1000
and a.name like '%'
this time the report returned in about 30 sec.
I then tried another thing which specified the region as "PL/SQL Function returning sql query", and modified the region as follows:
l_sql := '.......';
l_sql := l_sql || 'and a.id=' || v('P70_ID')
and similar substituting :P70_NAME to v('P70_NAME') and append its value to the l_sql string.
The report query page also returned in 30 sec.
Is there any known performance issue with using the bind variable (:PXX_XXX) in the report region?If you are able.. flush the shared_pool, run your
report then query the v$sql_area or v$sql_text tables.
Or do a google query and look up Cary Milsap's piece on enabling extended trace .. there is your sure fire way of finding the problem sql. I am still learning htmldb but is there a way to alter session enable trace in some pre-query block?
Maybe you are looking for
-
Undelete a line item from Sales Order
Hi, Is it possible to un-delete an item from the sales order? If yes, how can we do this? please advice. Thanks
-
Have FIOS Quantum router up and running - but now can't connect to Tivo or my Aria scale -help!
Getting my router set up was quick and easy, but now I have a problem that has me stumped. I am not a router expert, so need help. Neither my Tivos nor my Aria scale can connect to my router. Tivo sent me this page: http://support.tivo.com/app/answer
-
Adobe Story Script Suddenly lost the update?
Hello, I've been working on a script in Adobe Story (in my browser) for a few days and I went back to work on it today after working on it last night, and it went from 16 pages, to 6. Someone PLEASE help me! Thanks!
-
ORA-01005 error when running app on standalone server
Hello All: When I run an application on stand alone weblogic 10.3 server, I am getting error: ORA-01005: null password given; logon denied. In IDE it is running well and password field is filled checkboxes Save Password, Deploy Password checked in Da
-
Error updating to iOS 5.1
Help! I can't download iOS 5.1! I tried everything from restoring to changing the DNS. Tried on iPod and over wifi and Ethernet on iTunes. On my iPod it says error occurred while trying to update. In iTunes in say network connection could not be esta