Performance issue with query when generated from an ODS

I am generating a query from an ODS. The run time is very high. How do I improve the performance of the query ?

Hi Baruah,
Steps:
1. Build the Secondary Index.
2. divide the data in to 2 ODS where Historical and Present data ODS's and then build a Multiprovider and build the query on multiprovider.
3. Build the Indexing on the Table level (ODS table level).
We cannot make much faster performance for the ODS's that too with huge data...
The above are very few of them...
Hope you understood ..
Regards,
Ravi Kanth

Similar Messages

Performance issues with query input variable selection in ODS

Hi everyone
We've upgraded from BW 3.0B to NW04s BI using SP12.
There is a problem encountered with input variable selection. This happens regardless of using BEx (new or old 3.x) or using RSRT. When using the F4 search help (or "Select from list" in BEx context) to list possible values, this takes forever for large ODS (containing millions of records).
Using ST01 and SM50 to trace the code in the same query, we see a difference here:
NW04s BI SQL command
SELECT
"P0000"."COMP_CODE" AS "0000000032" ,"T0000"."TXTMD" AS "0000000032_TXTMD"
FROM
( "/BI0/PCOMP_CODE" "P0000" ) LEFT OUTER JOIN "/BI0/TCOMP_CODE" "T0000" ON "P0000"."COMP_CODE" = "T0000
"."COMP_CODE"
WHERE
"P0000"."OBJVERS" = 'A' AND "P0000"."COMP_CODE" IN ( SELECT "O"."COMP_CODE" AS "KEY" FROM
"/BI0/APY_PP_C100" "O" )
ORDER BY
"P0000"."COMP_CODE" ASC#
BW 3.0B SQL command:
SELECT ROWNUM < 500 ....
In 3.0B, rownum is limited to 500 and this results in a speedy, though limited query. In the new NW04s BI, this renders the selection screen unusable as ABAP dumps for timing out will occur first due to the large data volume searched using sequential read.
It will not be feasible to create indexes for every single query selection parameter (issues with oerformance when loading, space required etc.). Is there a reason why SAP seems have fallen back on a less effective code for this?
I have tried to change the number of selected rows to <500 in BEx settings but one must reach a responsive screen in order to get to that setting and it is not always possible or saved for the next run.
Anyone with similar experience or can provide help on this?

here is a reason why the F4 help on ODS was faster in BW 3.x.
In BW 3.x the ODS did not support the read mode "Only values in
InfoProvider". So If I compare the different SQL statements I propose
to change the F4 mode in the InfoProvider specific properties to
"About master data". This is the fastest F4 mode.
As an alternative you can define indexes on your ODS to speed up F4.
So would need a non-unique index on InfoObject 0COMP_CODE in your ODS
Check below for insights
https://forums.sdn.sap.com/click.jspa?searchID=6224682&messageID=2841493
Hope it Helps
Chetan
@CP..

Performance issue with Query

11g
Hi there experts,
I have an issue with performance with a simple SQL which I thought cannot be tuned but just wanted to check with the experts here. We are running a query to get a persons ID based on his logged in email address from a Parties table which is huge (Millions of records). The query takes about 30 seconds to return a value. Was wondering is there a way to optimize this
The query is
{code}
select par.party_id
from parties party, users users
where
lower(party.email_address) = lower(:USER_EMAIL)
and party.system_reference = to_char(users.person_id)
and users.active_flag ='Yes';
{code}
The emails are stored in upper and lower, hence the lower functions
IS creating a function based index the only way?
Thanks,
Ryan

Hi Everyone.
Thanks and apologies, first post on tuning as such. Here is the explain plan generated through SQL DEVELOPER. IT showed the output in XML
By the way, looks like the {code} tag does not work?
{code}
SELECT STATEMENT
84903
     HASH JOIN
84903
     Access Predicates
     PARTY.ORIG_SYSTEM_REFERENCE=TO_CHAR(PERSON_ID)
     TABLE ACCESS
     PER_USERS
STORAGE FULL
1059
     Access Predicates
     AND
     ACTIVE_FLAG='Y'
     OR
     OR
     BUSINESS_GROUP_ID=0
     BUSINESS_GROUP_ID=1
     BUSINESS_GROUP_ID=DECODE(SYS_CONTEXT('FND_VPD_CTX','FND_ENTERPRISE_ID'),NULL,BUSINESS_GROUP_ID,TO_NUMBER(SYS_CONTEXT('FND_VPD_CTX','FND_ENTERPRISE_ID')))
     Filter Predicates
     AND
     ACTIVE_FLAG='Y'
     OR
     OR
     BUSINESS_GROUP_ID=0
     BUSINESS_GROUP_ID=1
     BUSINESS_GROUP_ID=DECODE(SYS_CONTEXT('FND_VPD_CTX','FND_ENTERPRISE_ID'),NULL,BUSINESS_GROUP_ID,TO_NUMBER(SYS_CONTEXT('FND_VPD_CTX','FND_ENTERPRISE_ID')))
     TABLE ACCESS
     HZ_PARTIES
STORAGE FULL
83843
     Access Predicates
     LOWER(PARTY.EMAIL_ADDRESS)='[email protected]'
     Filter Predicates
     LOWER(PARTY.EMAIL_ADDRESS)='[email protected]'
{code}
Purvesh, around 50% are 'Yes'
Thanks!

Performance issue with FDM when importing data

In the FDM Web console, a performance issue has been detected when importing data (.txt)
In less than 10 seconds the ".txt" and the ".log" files are created the INBOX folder (the ".txt" file) and in the OUTBOX\Logs (the ".log" file).
At that moment, system shows the message "Processing, please wait” during 10 minutes. Eventually the information is displayed, however if we want to see the second page, we have to wait more than 20 seconds.
It seems a performance issue when system tries to show the imported data in the web page.
It has been also noted that when a user tries to import a txt file directly clicking on the tab "Select File From Inbox", the user has to also wait other 10 minutes before the information is displayed on the web page.
Thx in advance!
Cheers
Matteo

Hi Matteo
How much data is being imported / displayed when users are interacting with the system.
There is a report that may help you to analyse this but unfortunately I cannot remember what it is called and don't have access to a system to check. I do remember that it breaks down the import process into stages showing how long it takes to process each mapping step and the overall time.
I suspect that what you are seeing is normal behaviour but that isn't to say that performance improvements are not possible.
The copying of files is the first part of the import process before FDM then starts the import so that will be quick. The processing is then the time taken to import the records, process the mapping and write to the tables. If users are clicking 'Select file from Inbox' then they are re-importing so it will take just as long as it would for you to import it, they are not just asking to retrieve previously imported data.
Hope this helps
Stuart

Performance issue with Crystal when upgrading Oracle to 11g

Dear,
I am facing performance issue in crystal report and oracle 11g as below:
In ther report server, I have created a ODBC for connect to another Oracle 11g server. also in report server I have created and published a folder to content all of my crystal report. These report can connect to oracle 11g server via ODBC.
and I have a tomcat server to run my application in my application I refer to report folder in report server.
This way can work with SQL server and oracle 9 or 10g but it facing performance issue in oracle 11g.
please let me know the root cause.
Notes: report server, tomcate server are win 32bit, but oracle is in win 64bit, and i have upgraded DataDirect connect ODBC version 6.1 but the issue can not resolve.
Please help me to solve it.
Thanks so much,
Anh

Hi Anh,
Use a third party ODBC test tool now. SQL Plus will be using the Native Oracle client so you can't compare performance.
Download our old tool called SQLCON: https://smpdl.sap-ag.de/~sapidp/012002523100006252882008E/sqlcon32.zip
Connect and then click on the SQL tab and paste in the SQL from the report and time that test.
I believe the issue is because the Oracle client is 64 bit, you should install the 32 bit Oracle Client. If using the 64 bit client then the client must thunk ( convert 64 bit data to 32 bit data format ) which is going to take more time.
If you can use OLE DB or using the Oracle Server driver ( native driver ) should be faster. ODBC puts another layer on top of the Oracle client so it too takes time to communicate between the layers.
Thank you
Don

Performance Issues with crystal reports 11 - Critical

Post Author: DJ Gaba
CA Forum: Exporting
I have migrated from crystal reports version 8 to version 11.
I am experiencing some performance issues with reports when displayed in version 11
Reports that was taking 2 seconds in version 8 is now taking 4-5 seconds in versino 11
I am using vb6 to export my report file into pdf
Thanks

Post Author: synapsevampire
CA Forum: Exporting
Pleae don't multiple forums on the site with the same question.
I responded to your other post.
-k

Performance Issue with SXMB_MONI

Hi All,
I have a typical performance issue with SXMB_MONI, when I trigger this T.code it is taking around 20-24 hrs to execute.
Here I have found some tables which actually stores these processed xml messages,
SXMSPFADDRESS
SXMSPFRAWH
RSXMB_REMOTE_SERVICE
SXMSPFAGG
SXMSCONFVL
SXMSPMAST
SXMSPEMAS, SXMSPERROR, SXMSPMAST & SXMSPVERS.
SXMSPMAST, SXMSPMAST2, SXMSCLUR, SXMSCLUR2,
SXMSCLUP, SMXSLUP2, SXMSPFRAWH,
Here I want to increase the performance of sxmb_moni, firstly I want to know from which tables does the sxmb_moni fetches data and more over is it a single table or multiple table.
And please suggest any technique which can decrease the latency time in executing sxmb_moni.
Regards,
Vijay N

Hi,
Periodically you need to archive the XI messages, that allows you to maintain sufficient performance level.
Create archive jobs in SXMB_ADM to archive data which is 15 days old from XI related growing tables like SXMSCLUR, SXMSPEMAS, SXMSPHIST, SXMSPMAST, SXMSPVERS, SXMSPFRAW ,SWWWIHEAD. This archive job created archive files at the OS Level
For XI tables refer
/people/gourav.khare2/blog/2007/12/12/interesting-abap-tables-in-xi-150-part-i
SXMSPMAST, SXMSCLUP, SXMSPCLUR
the last two are cluster tables
and you won't get XML messages directly from them
have a look inside them
The classes that reads this information in SXMB_MONI are abap classes,
(can be seen at SE24) it is quite difficult to use them,
you might debug SXMB_MONI or use SE30 and see all the classes
that have been used.
You can use value mapping if you are not looking at picking up values from application system.It is just like SM30 transcation.You can get the info under SAP XI->Design and Configuration->Configuration->Value Mapping.
Also see the
these tables,
/SAPDMC/LSOMAP Field Mapping
/SAPTRX/SCAOTMAP
/SAPTRX/SCCNDMAP /SAPTRX/SCEVTMAP
/SAPTRX/SCFUNMAP /SAPTRX/SCSOMAP
/people/udo.martens/blog/2006/02/16/own-logging-of-xi-messages
message-mappings: stored in which database-table?
sxmb_moni, table sxmspmast, Messages with ICON_LED_RED, report RSXMB_SELECT
http://help.sap.com/saphelp_nw04s/helpdata/en/44/a1b46c4c686341e10000000a114a6b/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/ef/45393c3eb3036be10000000a11402f/frameset.htm
Thanks
Swarup

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 issue with view selection after migration from oracle to MaxDb

Hello,
After the migration from oracle to MaxDb we have serious performance issues with a lot of our tableview selections.
Does anybody know about this problem and how to solve it ??
Best regards !!!
Gert-Jan

Hello Gert-Jan,
most probably you need additional indexes to get better performance.
Using the command monitor you can identify the long running SQL statements and check the optimizer access strategy. Then you can decide which indexes might help.
If this is about an SAP system, you can find additional information about performance analysis in SAP notes 725489 and 819641.
SAP Hosting provides the so-called service 'MaxDB Migration Support' to help you in such cases. The service description can be found here:
http://www.saphosting.de/mediacenter/pdfs/solutionbriefs/MaxDB_de.pdf
http://www.saphosting.com/mediacenter/pdfs/solutionbriefs/maxDB-migration-support_en.pdf.
Best regards,
Melanie Handreck

Performance issue with using MAX function in pl/sql

Hello All,
We are having a performance issue with the below logic wherein MAX is being used in order to get the latest instance/record for a given input variable ( p_in_header_id).. the item_key is having the format as :
p_in_header_id - <number generated from a sequence>
This query to fetch even 1 record takes around 1 minutes 30 sec..could someone please help if there is a better way to form this logic & to improve performance in this case.
We want to get the latest record for the item_key ( this we are getting using MAX (begin_date)) for a given p_in_header_id value.
Query 1 :
SELECT item_key FROM wf_items WHERE item_type = 'xxxxzzzz'
AND SUBSTR (item_key, 1, INSTR (item_key, '-') - 1) =p_in_header_id
AND root_activity ='START_REQUESTS'
AND begin_date =
(SELECT MAX (begin_date) FROM wf_items WHERE item_type = 'xxxxzzzz'
AND root_activity ='START_REQUESTS'
AND SUBSTR (item_key, 1, INSTR (item_key, '-') - 1) =p_in_header_id);
Could someone please help us with this performance issue..we are really stuck because of this
regards

First of all Thanks to all gentlemen who replied ..many thanks ...
Tried the ROW_NUMBER() option but still it is taking time...have given output for the query and tkprof results as well. Even when it doesn't fetch any record ( this is a valid cased because the input header id doesn't have any workflow request submitted & hence no entry in the wf_items table)..then also see the time it has taken.
Looked at the RANK & DENSE_RANK options which were suggested..but it is still taking time..
Any further suggestions or ideas as to how this could be resolved..
SELECT 'Y', 'Y', ITEM_KEY
FROM
( SELECT ITEM_KEY, ROW_NUMBER() OVER(ORDER BY BEGIN_DATE DESC) RN FROM
WF_ITEMS WHERE ITEM_TYPE = 'xxxxzzzz' AND ROOT_ACTIVITY = 'START_REQUESTS'
AND SUBSTR(ITEM_KEY,1,INSTR(ITEM_KEY,'-') - 1) = :B1
) T WHERE RN <= 1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 1.57 0 0 0 0
Fetch 1 8700.00 544968.73 8180 8185 0 0
total 2 8700.00 544970.30 8180 8185 0 0
many thanks

Performance issues with pipelined table functions

I am testing pipelined table functions to be able to re-use the base_query function. Contrary to my understanding, the with_pipeline procedure runs 6 time slower than the legacy no_pipeline procedure. Am I missing something? The processor 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 PM

Earthlink wrote:
Contrary to my understanding, the with_pipeline procedure runs 6 time slower than the legacy no_pipeline 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 Homesharing?

I have a Time Capsule as the base station for my wireless network, then 2 Airport Express setup to extend the network around the house, an iMac i7 as the main iTunes Library and couple of iPads, and a couple of Apple TVs. Everything has the latest software, but I have several performance issues with Home sharing. I've done several tests making sure nothing is taking additional bandwidth, so here are the list of issues:
1) With nothing else running, trying playing a movie via home sharing in an iPad 2 which is located on my iMac, it stops and I have to keep pressing the play button over and over again. I typically see that the iPad tries to download part of the movie first and then starts playing so that it deals with the bandwidth, but in many cases it doesn't.
2) When trying to play any iTunes content (movies, music, photos, etc) from my Apple TV I can see my computer library, but when I go in on any of the menus, it says there's no content. I have to reboot the Apple TV and then problem fixed. I's just annoying that I have to reboot.
3) When watching a Netflix movie on my iPad and with Airplay I send the sound to some speakers via Airplay through an Airport Express. At time I lose the connection to the speakers.
I've complained about Wifi's instability, but here I tried to keep everything with Apples products to avoid any compatibility issues and stay within N wireless technology, which I understood it was much more stable.
Has anyone some suggestions?

Hi,
you should analyze the db after you have loaded the tables.
Do you use sequences to generate PKs? Do you have a lot of indexex and/or triggers on the tables?
If yes:
make sure your sequence caches (alter sequence s cache 10000)
Drop all unneeded indexes while loading and disable trigger if possible.
How big is your Redo Log Buffer? When loading a large amount of data it may be an option to enlarge this buffer.
Do you have more then one DBWR Process? Writing parallel can speed up things when a checkpoint is needed.
Is it possible using a direct load? Or do you already direct load?
Dim

Performance Issue with VL06O report

Hi,
We are having performance issue with VL06O report, when run with forwarding agent. It is taking about an hour with forwarding agent. The issue is with VBPA table and we found one OSS note, but it is for old versions. ours is ECC 5.0. Can anybody know the solution? If you guys need more information, please ask me.
Thanks,
Surya

Sreedhar,
Thanks for you quick response. Indexes were not created for VBPA table. basis people tested by creating indexes and gave a report that it is taking more time with indexes than regular query optimizer. this is happening in the funtion forward_ag_selection.
select vbeln lifnr from vbpa
     appending corresponding fields of table lt_select
     where     vbeln in ct_vbeln
     and     posnr eq posnr_initial
     and     parvw eq 'SP'
     and     lifnr in it_spdnr.
I don't see any issue with this query. I give more info later

Performance issue with two unbanalnced hierarchies in a single report

Hi All
We are facing the performance issue with one of the report which houses two unbalanced hierarchies (having 18 levels) - skipped & ragged. Basically its a part of OBIAPPS financila analytics .
The query is below :
Could anyone let me know how to improve the performane. Any parameter that should be looked at while using unbalanced hierarchies.
WITH SAWITH0
AS ( SELECT SUM (T91707.OTHER_LOC_AMT) AS c1,
MAX (T314768.HIER2_CODE) AS c2,
MAX (T314768.HIER3_CODE) AS c3,
MAX (T314768.HIER4_CODE) AS c4,
MAX (T314768.HIER5_CODE) AS c5,
MAX (T314768.HIER6_CODE) AS c6,
MAX (T314768.HIER7_CODE) AS c7,
MAX (T314768.HIER8_CODE) AS c8,
MAX (T314768.HIER9_CODE) AS c9,
MAX (T314768.HIER10_CODE) AS c10,
MAX (T314768.HIER11_CODE) AS c11,
MAX (T314768.HIER12_CODE) AS c12,
MAX (T314768.HIER13_CODE) AS c13,
MAX (T314768.HIER14_CODE) AS c14,
MAX (T314768.HIER15_CODE) AS c15,
MAX (T314768.HIER16_CODE) AS c16,
MAX (T314768.HIER17_CODE) AS c17,
MAX (T314768.HIER18_CODE) AS c18,
MAX (T314768.HIER19_CODE) AS c19,
MAX (T314768.HIER20_CODE) AS c20,
T314768.HIER1_NAME AS c21,
T314768.HIER1_CODE AS c22,
T314914.HIER1_NAME AS c24,
T314914.HIER10_NAME AS c25,
T314914.HIER11_NAME AS c26,
T314914.HIER12_NAME AS c27,
T314914.HIER13_NAME AS c28,
T314914.HIER14_NAME AS c29,
T314914.HIER15_NAME AS c30,
T314914.HIER16_NAME AS c31,
T314914.HIER17_NAME AS c32,
T314914.HIER18_NAME AS c33,
T314914.HIER19_NAME AS c34,
T314914.HIER2_NAME AS c35,
T314914.HIER20_NAME AS c36,
T314914.HIER3_NAME AS c37,
T314914.HIER4_NAME AS c38,
T314914.HIER5_NAME AS c39,
T314914.HIER6_NAME AS c40,
T314914.HIER7_NAME AS c41,
T314914.HIER8_NAME AS c42,
T314914.HIER9_NAME AS c43,
T314914.HIER20_CODE AS c44,
T314914.HIER1_CODE AS c45,
T314914.HIER10_CODE AS c46,
T314914.HIER11_CODE AS c47,
T314914.HIER12_CODE AS c48,
T314914.HIER13_CODE AS c49,
T314914.HIER14_CODE AS c50,
T314914.HIER15_CODE AS c51,
T314914.HIER16_CODE AS c52,
T314914.HIER17_CODE AS c53,
T314914.HIER18_CODE AS c54,
T314914.HIER19_CODE AS c55,
T314914.HIER2_CODE AS c56,
T314914.HIER3_CODE AS c57,
T314914.HIER4_CODE AS c58,
T314914.HIER5_CODE AS c59,
T314914.HIER6_CODE AS c60,
T314914.HIER7_CODE AS c61,
T314914.HIER8_CODE AS c62,
T314914.HIER9_CODE AS c63
FROM W_HIERARCHY_D T314768 /* Dim_W_HIERARCHY_D_Segment11 */
W_GL_SEGMENT_D T315677 /* Dim_W_GL_SEGMENT_D_Segment11 */
W_HIERARCHY_D T314914 /* Dim_W_HIERARCHY_D_Segment13 */
W_GL_SEGMENT_D T315731 /* Dim_W_GL_SEGMENT_D_Segment13 */
W_GL_ACCOUNT_D T91397 /* Dim_W_GL_ACCOUNT_D */
W_GL_OTHER_F T91707 /* Fact_W_GL_OTHER_F */
WHERE ( T91397.ROW_WID = T91707.GL_ACCOUNT_WID
AND T91397.ACCOUNT_SEG11_CODE = T315677.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG13_CODE = T315731.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG11_ATTRIB = T315677.SEGMENT_LOV_ID
AND T91397.ACCOUNT_SEG13_ATTRIB = T315731.SEGMENT_LOV_ID
AND T314768.HIER_CODE = T315677.SEGMENT_LOV_ID
AND T314768.HIER_NAME = T315677.SEGMENT_LOV_NAME
AND T314768.HIERARCHY_ID = T315677.SEGMENT_VAL_CODE
AND T314914.HIER_CODE = T315731.SEGMENT_LOV_ID
AND T314914.HIER_NAME = T315731.SEGMENT_LOV_NAME
AND T314914.HIERARCHY_ID = T315731.SEGMENT_VAL_CODE
AND T315677.SEGMENT_LOV_NAME =
'Responsibility_Centre_Functional'
AND T315677.SEGMENT_LOV_ID = 1000163
AND T315731.SEGMENT_LOV_NAME = 'Account_Master'
AND T315731.SEGMENT_LOV_ID = 1000165
AND ( T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER11_CODE IS NULL)
AND (T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER12_CODE IS NULL)
AND ( T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER8_CODE IS NULL)
AND ( T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER9_CODE IS NULL)
AND ( T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER10_CODE IS NULL)
AND ( T314914.HIER1_CODE IN ('ALL_LI')
OR T314914.HIER2_CODE IN ('S000000001')
OR T314914.HIER3_CODE IN ('S000005150')
OR T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022'))
AND ( T314914.HIER2_CODE IN ('S000000001')
OR T314914.HIER3_CODE IN ('S000005150')
OR T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER2_CODE IS NULL)
AND ( T314914.HIER3_CODE IN ('S000005150')
OR T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER3_CODE IS NULL)
AND ( T314914.HIER4_CODE IN ('S000005151')
OR T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER4_CODE IS NULL)
AND ( T314914.HIER5_CODE IN ('S000005153')
OR T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER5_CODE IS NULL)
AND ( T314914.HIER6_CODE IN ('S000005154')
OR T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER6_CODE IS NULL)
AND ( T314914.HIER7_CODE IN ('S000005062')
OR T314914.HIER8_CODE IN ('S000005160')
OR T314914.HIER9_CODE IN ('S000000187')
OR T314914.HIER10_CODE IN ('S526003000')
OR T314914.HIER11_CODE IN ('S526002012')
OR T314914.HIER12_CODE IN ('S000001022')
OR T314914.HIER7_CODE IS NULL)
AND T314768.HIER1_CODE IS NOT NULL
AND T314914.HIER20_CODE IS NOT NULL
AND T314914.HIER13_CODE IS NULL
AND T314914.HIER14_CODE IS NULL
AND T314914.HIER15_CODE IS NULL
AND T314914.HIER16_CODE IS NULL
AND T314914.HIER17_CODE IS NULL
AND T314914.HIER18_CODE IS NULL
AND T314914.HIER19_CODE IS NULL)
GROUP BY T314768.HIER1_CODE,
T314768.HIER1_NAME,
T314914.HIER1_CODE,
T314914.HIER1_NAME,
T314914.HIER2_CODE,
T314914.HIER2_NAME,
T314914.HIER3_CODE,
T314914.HIER3_NAME,
T314914.HIER4_CODE,
T314914.HIER4_NAME,
T314914.HIER5_CODE,
T314914.HIER5_NAME,
T314914.HIER6_CODE,
T314914.HIER6_NAME,
T314914.HIER7_CODE,
T314914.HIER7_NAME,
T314914.HIER8_CODE,
T314914.HIER8_NAME,
T314914.HIER9_CODE,
T314914.HIER9_NAME,
T314914.HIER10_CODE,
T314914.HIER10_NAME,
T314914.HIER11_CODE,
T314914.HIER11_NAME,
T314914.HIER12_CODE,
T314914.HIER12_NAME,
T314914.HIER13_CODE,
T314914.HIER13_NAME,
T314914.HIER14_CODE,
T314914.HIER14_NAME,
T314914.HIER15_CODE,
T314914.HIER15_NAME,
T314914.HIER16_CODE,
T314914.HIER16_NAME,
T314914.HIER17_CODE,
T314914.HIER17_NAME,
T314914.HIER18_CODE,
T314914.HIER18_NAME,
T314914.HIER19_CODE,
T314914.HIER19_NAME,
T314914.HIER20_CODE,
T314914.HIER20_NAME),
SAWITH1
AS (SELECT SUM (D1.c1) OVER () AS c1,
MAX (D1.c2) OVER (PARTITION BY D1.c22) AS c2,
MAX (D1.c3) OVER (PARTITION BY D1.c22) AS c3,
MAX (D1.c4) OVER (PARTITION BY D1.c22) AS c4,
MAX (D1.c5) OVER (PARTITION BY D1.c22) AS c5,
MAX (D1.c6) OVER (PARTITION BY D1.c22) AS c6,
MAX (D1.c7) OVER (PARTITION BY D1.c22) AS c7,
MAX (D1.c8) OVER (PARTITION BY D1.c22) AS c8,
MAX (D1.c9) OVER (PARTITION BY D1.c22) AS c9,
MAX (D1.c10) OVER (PARTITION BY D1.c22) AS c10,
MAX (D1.c11) OVER (PARTITION BY D1.c22) AS c11,
MAX (D1.c12) OVER (PARTITION BY D1.c22) AS c12,
MAX (D1.c13) OVER (PARTITION BY D1.c22) AS c13,
MAX (D1.c14) OVER (PARTITION BY D1.c22) AS c14,
MAX (D1.c15) OVER (PARTITION BY D1.c22) AS c15,
MAX (D1.c16) OVER (PARTITION BY D1.c22) AS c16,
MAX (D1.c17) OVER (PARTITION BY D1.c22) AS c17,
MAX (D1.c18) OVER (PARTITION BY D1.c22) AS c18,
MAX (D1.c19) OVER (PARTITION BY D1.c22) AS c19,
MAX (D1.c20) OVER (PARTITION BY D1.c22) AS c20,
D1.c21 AS c21,
D1.c22 AS c22,
SUM (
D1.c1)
OVER (
PARTITION BY D1.c46,
D1.c47,
D1.c48,
D1.c49,
D1.c50,
D1.c51,
D1.c52,
D1.c53,
D1.c54,
D1.c55,
D1.c45,
D1.c44,
D1.c56,
D1.c57,
D1.c58,
D1.c59,
D1.c60,
D1.c61,
D1.c62,
D1.c63,
D1.c22)
AS c23,
D1.c24 AS c24,
D1.c25 AS c25,
D1.c26 AS c26,
D1.c27 AS c27,
D1.c28 AS c28,
D1.c29 AS c29,
D1.c30 AS c30,
D1.c31 AS c31,
D1.c32 AS c32,
D1.c33 AS c33,
D1.c34 AS c34,
D1.c35 AS c35,
D1.c36 AS c36,
D1.c37 AS c37,
D1.c38 AS c38,
D1.c39 AS c39,
D1.c40 AS c40,
D1.c41 AS c41,
D1.c42 AS c42,
D1.c43 AS c43,
D1.c44 AS c44,
D1.c45 AS c45,
D1.c46 AS c46,
D1.c47 AS c47,
D1.c48 AS c48,
D1.c49 AS c49,
D1.c50 AS c50,
D1.c51 AS c51,
D1.c52 AS c52,
D1.c53 AS c53,
D1.c54 AS c54,
D1.c55 AS c55,
D1.c56 AS c56,
D1.c57 AS c57,
D1.c58 AS c58,
D1.c59 AS c59,
D1.c60 AS c60,
D1.c61 AS c61,
D1.c62 AS c62,
D1.c63 AS c63
FROM SAWITH0 D1)
SELECT DISTINCT
38 AS c1,
D1.c24 AS c2,
D1.c25 AS c3,
D1.c26 AS c4,
D1.c27 AS c5,
D1.c28 AS c6,
D1.c29 AS c7,
D1.c30 AS c8,
D1.c31 AS c9,
D1.c32 AS c10,
D1.c33 AS c11,
D1.c34 AS c12,
D1.c35 AS c13,
D1.c36 AS c14,
D1.c37 AS c15,
D1.c38 AS c16,
D1.c39 AS c17,
D1.c40 AS c18,
D1.c41 AS c19,
D1.c42 AS c20,
D1.c43 AS c21,
D1.c21 AS c22,
NULL AS c23,
NULL AS c24,
NULL AS c25,
NULL AS c26,
NULL AS c27,
NULL AS c28,
NULL AS c29,
NULL AS c30,
NULL AS c31,
NULL AS c32,
NULL AS c33,
NULL AS c34,
NULL AS c35,
NULL AS c36,
NULL AS c37,
NULL AS c38,
NULL AS c39,
NULL AS c40,
NULL AS c41,
D1.c44 AS c42,
D1.c45 AS c43,
D1.c46 AS c44,
D1.c47 AS c45,
D1.c48 AS c46,
D1.c49 AS c47,
D1.c50 AS c48,
D1.c51 AS c49,
D1.c52 AS c50,
D1.c53 AS c51,
D1.c54 AS c52,
D1.c55 AS c53,
D1.c56 AS c54,
D1.c57 AS c55,
D1.c58 AS c56,
D1.c59 AS c57,
D1.c60 AS c58,
D1.c61 AS c59,
D1.c62 AS c60,
D1.c63 AS c61,
NULL AS c62,
D1.c22 AS c63,
NULL AS c64,
NULL AS c65,
NULL AS c66,
NULL AS c67,
NULL AS c68,
NULL AS c69,
NULL AS c70,
NULL AS c71,
NULL AS c72,
NULL AS c73,
NULL AS c74,
NULL AS c75,
NULL AS c76,
NULL AS c77,
NULL AS c78,
NULL AS c79,
NULL AS c80,
NULL AS c81,
D1.c23 AS c82,
CASE WHEN 1 = 1 THEN 1 ELSE 0 END AS c83,
CASE
WHEN D1.c2 IS NULL
AND D1.c3 IS NULL
AND D1.c4 IS NULL
AND D1.c5 IS NULL
AND D1.c6 IS NULL
AND D1.c7 IS NULL
AND D1.c8 IS NULL
AND D1.c9 IS NULL
AND D1.c10 IS NULL
AND D1.c11 IS NULL
AND D1.c12 IS NULL
AND D1.c13 IS NULL
AND D1.c14 IS NULL
AND D1.c15 IS NULL
AND D1.c16 IS NULL
AND D1.c17 IS NULL
AND D1.c18 IS NULL
AND D1.c19 IS NULL
AND D1.c20 IS NULL
THEN
1
ELSE
0
END
AS c84
FROM SAWITH1 D1
WHERE ( D1.c44 IS NOT NULL
AND D1.c50 IS NULL
AND D1.c49 IS NULL
AND D1.c22 IS NOT NULL
AND D1.c51 IS NULL
AND D1.c52 IS NULL
AND D1.c53 IS NULL
AND D1.c54 IS NULL
AND D1.c55 IS NULL)
/* Formatted on 12/17/2012 7:49:44 PM (QP5 v5.139.911.3011) */
WITH OBICOMMON0
AS (SELECT T156337.ROW_WID AS c2,
T156337.MCAL_PERIOD_WID AS c3,
ROW_NUMBER ()
OVER (PARTITION BY T156337.MCAL_PERIOD_WID
ORDER BY T156337.MCAL_PERIOD_WID DESC)
AS c4,
T156337.MCAL_PERIOD_NAME AS c5,
T156337.MCAL_PER_NAME_YEAR AS c6
FROM W_MCAL_DAY_D T156337 /* Dim_W_MCAL_DAY_D_Fiscal_Day */
WHERE (T156337.MCAL_CAL_NAME = 'Accounting')),
SAWITH0
AS (SELECT CASE
WHEN CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END
IS NOT NULL
THEN
RANK ()
OVER (
ORDER BY
CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END ASC NULLS LAST)
END
AS c1,
D1.c2 AS c2,
D1.c3 AS c3
FROM OBICOMMON0 D1),
SAWITH1
AS (SELECT DISTINCT
MIN (D1.c1) OVER (PARTITION BY D1.c3) AS c1, D1.c2 AS c2
FROM SAWITH0 D1),
SAWITH2
AS (SELECT CASE
WHEN CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END
IS NOT NULL
THEN
RANK ()
OVER (
ORDER BY
CASE D1.c4 WHEN 1 THEN D1.c2 ELSE NULL END ASC NULLS LAST)
END
AS c1,
D1.c3 AS c2,
D1.c5 AS c3,
D1.c6 AS c4
FROM OBICOMMON0 D1),
SAWITH3 AS (SELECT DISTINCT MIN (D1.c1) OVER (PARTITION BY D1.c2) AS c1,
D1.c2 AS c2,
D1.c3 AS c3,
D1.c4 AS c4
FROM SAWITH2 D1),
SAWITH4
AS ( SELECT SUM (T91707.TD_OTHER_REP_AMT) AS c1,
T314914.HIER1_NAME AS c2,
D2.c3 AS c3,
T314914.HIER1_CODE AS c4,
D2.c2 AS c5
FROM W_HIERARCHY_D T314914 /* Dim_W_HIERARCHY_D_Segment13 */
W_GL_SEGMENT_D T315731 /* Dim_W_GL_SEGMENT_D_Segment13 */
W_GL_ACCOUNT_D T91397 /* Dim_W_GL_ACCOUNT_D */
W_GL_OTHER_F T91707 /* Fact_W_GL_OTHER_F */
SAWITH1 D4,
SAWITH3 D2
WHERE ( T314914.HIER_CODE = T315731.SEGMENT_LOV_ID
AND T314914.HIER_NAME = T315731.SEGMENT_LOV_NAME
AND T91397.ROW_WID = T91707.GL_ACCOUNT_WID
AND T91707.ACCT_PERIOD_END_DT_WID = D4.c2
AND T314914.HIERARCHY_ID = T315731.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG13_CODE = T315731.SEGMENT_VAL_CODE
AND T91397.ACCOUNT_SEG13_ATTRIB = T315731.SEGMENT_LOV_ID
AND T315731.SEGMENT_LOV_NAME =
'Account_Retail_Distribution'
AND T315731.SEGMENT_LOV_ID = 1000165
AND D2.c1 = D4.c1
AND (D2.c4 IN ('2011', '2012')))
GROUP BY T314914.HIER1_CODE,
T314914.HIER1_NAME,
D2.c2,
D2.c3)
SELECT D1.c1 AS c1,
D1.c2 AS c2,
D1.c3 AS c3,
D1.c4 AS c4,
D1.c5 AS c5,
D1.c6 AS c6
FROM ( SELECT DISTINCT 0 AS c1,
D1.c2 AS c2,
D1.c3 AS c3,
D1.c4 AS c4,
D1.c1 AS c5,
D1.c5 AS c6
FROM SAWITH4 D1
ORDER BY c2 NULLS FIRST, c4 NULLS FIRST, c3) D1
WHERE ROWNUM <= 65001

Hello Gurus, Experts
Any help/tips here ...

Performance issue with a Custom view

Hi ,
I am pretty new to performance tuning and facing a performance issue with a custom view.
Execution time for view query is good but as soon as I append a where caluse to view query ,the execution time increases.
Below is the view query:
CREATE OR REPLACE XXX_INFO_VIEW AS
SELECT csb.system_id license_id,
cst.name license_number ,
csb.system_type_code license_type ,
csb.attribute3 lac , -- license authorization code
csb.attribute6 lat , -- license admin token
csb.attribute12 ols_reg, -- OLS Registration allowed flag
l.attribute4 license_biz_type ,
NVL (( SELECT 'Y' l_supp_flag
FROM csi_item_instances cii,
okc_k_lines_b a,
okc_k_items c
WHERE c.cle_id = a.id
AND a.lse_id = 9
AND c.jtot_object1_code = 'OKX_CUSTPROD'
AND c.object1_id1 = cii.instance_id||''
AND cii.instance_status_id IN (3, 510)
AND cii.system_id = csb.system_id
AND a.sts_code IN ('SIGNED', 'ACTIVE')
AND NVL (a.date_terminated, a.end_date) > SYSDATE
AND ROWNUM < 2), 'N') active_supp_flag,
hp.party_name "Customer_Name" , -- Customer Name
hca.attribute12 FGE_FLAG,
(SELECT /*+INDEX (oklt OKC_K_LINES_TL_U1) */
nvl(max((decode(name, 'eSupport','2','Enterprise','1','Standard','1','TERM RTU','0','TERM RTS','0','Notfound'))),0) covName --TERM RTU and TERM RTS added as per Vijaya's suggestion APR302013
FROM OKC_K_LINES_B oklb1,
OKC_K_LINES_TL oklt,
OKC_K_LINES_B oklb2,
OKC_K_ITEMS oki,
CSI_item_instances cii
WHERE
OKI.JTOT_OBJECT1_CODE = 'OKX_CUSTPROD'
AND oklb1.id=oklt.id
AND OKI.OBJECT1_ID1 =cii.instance_id||''
AND Oklb1.lse_id=2
AND oklb1.dnz_chr_id=oklb2.dnz_chr_id
AND oklb2.lse_id=9
AND oki.CLE_ID=oklb2.id
AND cii.system_id=csb.system_id
AND oklt.LANGUAGE=USERENV ('LANG')) COVERAGE_TYPE
FROM csi_systems_b csb ,
csi_systems_tl cst ,
hz_cust_accounts hca,
hz_parties hp,
fnd_lookup_values l
WHERE csb.system_type_code = l.lookup_code (+)
AND csb.system_id = cst.system_id
AND hca.cust_account_id =csb.customer_id
AND hca.party_id= hp.party_id
AND cst.language = USERENV ('LANG')
AND l.lookup_type (+) = 'CSI_SYSTEM_TYPE'
AND l.language (+) = USERENV ('LANG')
AND NVL (csb.end_date_active, SYSDATE+1) > SYSDATE)
I have forced an index to avoid Full table scan on OKC_K_LINES_TL and suppressed an index on CSI_item_instances.instance id to make the view query fast.
So when i do select * from XXX_INFO_VIEWit executes in a decent time,But when I try to do
select * from XXX_INFO_VIEW where active_supp_flag='Y' and coverage_type='1'
it takes lot of time.
Execution plan is same for both queries in terms of cost but with WHERE clause Number of bytes increases.
Below are the execution plans:
View query:
SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
 10 COUNT STOPKEY
 9 NESTED LOOPS
 7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1
 5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299
 2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155
 1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
 4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
 3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
 6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
 8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
 12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1
 11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
 28 SORT AGGREGATE Bytes: 169 Cardinality: 1
 27 NESTED LOOPS
 25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768
 23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757
 20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578
 17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606
 14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315
 13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
 16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
 15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
 19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
 18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
 22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10
 21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9
 24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1
 26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1
 43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
 41 NESTED LOOPS
 39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196
 37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196
 32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196
 30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17
 29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
 31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196
 36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887
 35 HASH JOIN
 33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
 34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
 38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
 40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1
 42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918
Execution plan for view query with WHERE clause:
SELECT STATEMENT ALL_ROWS Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211
 10 COUNT STOPKEY
 9 NESTED LOOPS
 7 NESTED LOOPS Cost: 1,085 Bytes: 101 Cardinality: 1
 5 NESTED LOOPS Cost: 487 Bytes: 17,043 Cardinality: 299
 2 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 2,325 Cardinality: 155
 1 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
 4 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
 3 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
 6 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
 8 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
 12 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 2 Bytes: 7 Cardinality: 1
 11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
 28 SORT AGGREGATE Bytes: 169 Cardinality: 1
 27 NESTED LOOPS
 25 NESTED LOOPS Cost: 16,549 Bytes: 974,792 Cardinality: 5,768
 23 NESTED LOOPS Cost: 5,070 Bytes: 811,737 Cardinality: 5,757
 20 NESTED LOOPS Cost: 2,180 Bytes: 56,066 Cardinality: 578
 17 NESTED LOOPS Cost: 967 Bytes: 32,118 Cardinality: 606
 14 TABLE ACCESS BY INDEX ROWID TABLE CSI.CSI_ITEM_INSTANCES Cost: 22 Bytes: 3,465 Cardinality: 315
 13 INDEX RANGE SCAN INDEX CSI.CSI_ITEM_INSTANCES_N07 Cost: 3 Cardinality: 315
 16 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_ITEMS Cost: 3 Bytes: 84 Cardinality: 2
 15 INDEX RANGE SCAN INDEX OKC.OKC_K_ITEMS_N2 Cost: 2 Cardinality: 2
 19 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 2 Bytes: 44 Cardinality: 1
 18 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_B_U1 Cost: 1 Cardinality: 1
 22 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_B Cost: 5 Bytes: 440 Cardinality: 10
 21 INDEX RANGE SCAN INDEX OKC.OKC_K_LINES_B_N2 Cost: 2 Cardinality: 9
 24 INDEX UNIQUE SCAN INDEX (UNIQUE) OKC.OKC_K_LINES_TL_U1 Cost: 1 Cardinality: 1
 26 TABLE ACCESS BY INDEX ROWID TABLE OKC.OKC_K_LINES_TL Cost: 2 Bytes: 28 Cardinality: 1
 44 VIEW VIEW APPS.WRS_LICENSE_INFO_V Cost: 7,212 Bytes: 2,462,837 Cardinality: 3,211
 43 HASH JOIN Cost: 7,212 Bytes: 536,237 Cardinality: 3,211
 41 NESTED LOOPS
 39 NESTED LOOPS Cost: 7,070 Bytes: 485,792 Cardinality: 3,196
 37 HASH JOIN Cost: 676 Bytes: 341,972 Cardinality: 3,196
 32 HASH JOIN RIGHT OUTER Cost: 488 Bytes: 310,012 Cardinality: 3,196
 30 TABLE ACCESS BY INDEX ROWID TABLE APPLSYS.FND_LOOKUP_VALUES Cost: 7 Bytes: 544 Cardinality: 17
 29 INDEX RANGE SCAN INDEX (UNIQUE) APPLSYS.FND_LOOKUP_VALUES_U1 Cost: 3 Cardinality: 17
 31 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_B Cost: 481 Bytes: 207,740 Cardinality: 3,196
 36 VIEW VIEW AR.index$_join$_013 Cost: 187 Bytes: 408,870 Cardinality: 40,887
 35 HASH JOIN
 33 INDEX FAST FULL SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 112 Bytes: 408,870 Cardinality: 40,887
 34 INDEX FAST FULL SCAN INDEX AR.HZ_CUST_ACCOUNTS_N2 Cost: 122 Bytes: 408,870 Cardinality: 40,887
 38 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
 40 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 2 Bytes: 45 Cardinality: 1
 42 TABLE ACCESS FULL TABLE CSI.CSI_SYSTEMS_TL Cost: 142 Bytes: 958,770 Cardinality: 63,918

Hi,
You should always try using primary index fields, if not possible then secondary index fields.
Even if you cannot do anything from either of the two then try this,
Use Less distinct fields on the top.
In your case , you can use bukrs ,gjahr ,werks on the top in the where condition..then followed by less distinct values..
Even when you use secondary index if you have 4 fields in your sec index and you are using only two fields from the top then the index is useful only upto that two fields provided they are in sequence.

Performance issue with query when generated from an ODS

Similar Messages

Maybe you are looking for