Performance Issue with Crosstab Reports Using Disco Viewer 10.1.2.48.18

We're experiencing Performance Issue (retrieving 40000 rows) with Crosstab Reports Using Disco Viewer 10.1.2.48.18 ( > 01 Minute , executing "Building Page Axis" or executing a Refresh).
Are there parameters to tun (in pref.txt file) , in order to reduce "Building Page Axis" execution ?
Note : We've got the same performance problem , using Discoverer Desktop 10.1.2.48.18.
Thank's in advance for your Help.

Hi
Well if the same issue occurs in both Desktop and Viewer then you have your answer. It's not the way that Discoverer is running the workbook its the way the workbook has been constructed.
For a start, 40000 rows for a Crosstab is way over the top and WILL cause performance issues. This is because Discoverer has to create a bucket for every data point for every combination of items on the page, side and top axes. The more rows, page items and column headings that you have, the more buckets you have and therefore the longer it will take for Discoverer to work out the contents of every bucket.
Also, whenever you use page items or crosstabs, Discoverer has to retrieve all of the rows for the entire query, not just the first x rows as with a table. This is because it cannot possibly know how many buckets to create until it has all the rows.
You therefore to:
a) apply sufficient filters to reduce the amount of data being returned to something manageable
b) reduce the number of page items, if used
c) reduce the number of items on the side or top axis of a crosstab
d) reduce the number of complex calculations, especially calculations that would generate a new bucket
If you have a lot of complex calculations, you should consider the use of a materialized view / summary folder to pre-calculate the values.
Does this help?
Best wishes
Michael Armstrong-Smith
URL: http://learndiscoverer.com
Blog: http://learndiscoverer.blogspot.com

Similar Messages

Performance issue with Crosstab report in BIP

Hi,
I have a report to display in cross tab format....
I followed the steps given in the BIP user guide to develop the report.
The functionality is working fine and report is in intended format.
But the issue is with the performance. The column logic in the X-axis(here - f: Sum(Balance) end) is taking huge time to process and render the data onto the report.
Could anyone please provide an alternative to this logic so that the performance can be improved?
Report Details
rtf looks like this............
Account Number.....Account Name.....Sub Account Number.....Sub Account Name..... Affiliate Code.....Product Total.....for: PRODUCT end
FOR:ACC .....ACCDESC .....SUBACC .....SUBACCDESC .....ICP_CODE .....PROD_TOT .....f: Sum(Balance) endend
for: - <?for-each-group@column: G_BALANCE;PROD?>
end - <?end for-each-group?>
FOR: - <?for-each-group@section:G_BALANCE;UIN?> <?variable@incontext:ACC;UIN?>
f: - <?for-each-group@cell://G_BALANCE;PROD?>
Sum(Balance) - <?if:count(current-group()[UIN=$ACC])?> <?sum(current-group()[UIN=$ACC]/BAL)?> <?end if?>
end - <?end for-each-group?>
end - <?end for-each-group?>
and others are just place holder columns........
The xml data is generated in the below format:
- <G_BALANCE>
<UIN>ACC_INVEST_INC_G</UIN>
<ACC>ACC_INVEST_INC_G</ACC>
<ACC_N>Accrued investment income</ACC_N>
<S_ACC_N />
<S_ACC_NA />
<I_CO />
<PROD>Corporate Product Code</PROD>
<BAL>51439533.16</BAL>
<A_L>0</A_L>
<P_ACC />
<S_F>Y</S_F>
<R_ID>1</R_ID>
- <G_PROD_TOTAL>
<P_T>51439533.16</P_T>
</G_PROD_TOTAL>
</G_BALANCE>
- <G_BALANCE>
<UIN>14000000000000</UIN>
<ACC>140000</ACC>
<ACC_N>Acc Invest Inc - Government Long-Term Bonds</ACC_N>
<S_ACC_N>00000</S_ACC_N>
<S_ACC_NA>Default - Sub Account</S_ACC_NA>
<I_CO>000</I_CO>
<PROD>Corporate Product Code</PROD>
<BAL>379914.46</BAL>
<A_L>1</A_L>
<P_ACC>ACC_INVEST_INC_G</P_ACC>
<S_F>N</S_F>
<R_ID>2</R_ID>
- <G_PROD_TOTAL>
<P_T>379914.46</P_T>
</G_PROD_TOTAL>
</G_BALANCE>
- <G_BALANCE>
<UIN>14001000000000</UIN>
<ACC>140010</ACC>
<ACC_N>Acc Invest Inc - Long-Term Bonds</ACC_N>
<S_ACC_N>00000</S_ACC_N>
<S_ACC_NA>Default - Sub Account</S_ACC_NA>
<I_CO>000</I_CO>
<PROD>Corporate Product Code</PROD>
<BAL>46806502.11</BAL>
<A_L>1</A_L>
<P_ACC>ACC_INVEST_INC_G</P_ACC>
<S_F>N</S_F>
<R_ID>3</R_ID>
- <G_PROD_TOTAL>
<P_T>46806502.11</P_T>
</G_PROD_TOTAL>
</G_BALANCE>
- <G_BALANCE>
<UIN>14010000000000</UIN>
<ACC>140100</ACC>
<ACC_N>Acc Invest Inc - Mortgage Loans</ACC_N>
<S_ACC_N>00000</S_ACC_N>
<S_ACC_NA>Default - Sub Account</S_ACC_NA>
<I_CO>000</I_CO>
<PROD>Corporate Product Code</PROD>
<BAL>1182324.99</BAL>
<A_L>1</A_L>
<P_ACC>ACC_INVEST_INC_G</P_ACC>
<S_F>N</S_F>
<R_ID>4</R_ID>
- <G_PROD_TOTAL>
<P_T>1182324.99</P_T>
</G_PROD_TOTAL>
</G_BALANCE>
- <G_BALANCE>
<UIN>14022000000000</UIN>
<ACC>140220</ACC>
<ACC_N>Acc Invest Inc - Certificate of Deposit</ACC_N>
<S_ACC_N>00000</S_ACC_N>
<S_ACC_NA>Default - Sub Account</S_ACC_NA>
<I_CO>000</I_CO>
<PROD>Corporate Product Code</PROD>
<BAL>38.22</BAL>
<A_L>1</A_L>
<P_ACC>ACC_INVEST_INC_G</P_ACC>
<S_F>N</S_F>
<R_ID>5</R_ID>
- <G_PROD_TOTAL>
<P_T>38.22</P_T>
</G_PROD_TOTAL>
</G_BALANCE>
- <G_BALANCE>
<UIN>14030000000000</UIN>
<ACC>140300</ACC>
<ACC_N>Acc Invest Inc - Policy Loans</ACC_N>
<S_ACC_N>00000</S_ACC_N>
<S_ACC_NA>Default - Sub Account</S_ACC_NA>
<I_CO>000</I_CO>
<PROD>Corporate Product Code</PROD>
<BAL>3070753.13</BAL>
<A_L>1</A_L>
<P_ACC>ACC_INVEST_INC_G</P_ACC>
<S_F>N</S_F>
<R_ID>6</R_ID>
- <G_PROD_TOTAL>
<P_T>3070753.13</P_T>
</G_PROD_TOTAL>
</G_BALANCE>
- <G_BALANCE>
<UIN>14054000000000</UIN>
<ACC>140540</ACC>
<ACC_N>Acc Invest Inc - OIA</ACC_N>
<S_ACC_N>00000</S_ACC_N>
<S_ACC_NA>Default - Sub Account</S_ACC_NA>
<I_CO>000</I_CO>
<PROD>Corporate Product Code</PROD>
<BAL>.25</BAL>
<A_L>1</A_L>
<P_ACC>ACC_INVEST_INC_G</P_ACC>
<S_F>N</S_F>
<R_ID>7</R_ID>
- <G_PROD_TOTAL>
<P_T>.25</P_T>
</G_PROD_TOTAL>
</G_BALANCE>
Thanks.

Hi,
Please find the sample data and the desired result below:
Sample Table data:
ACCOUNT...........SUB ACCOUNT NUM...........AFFILIATE...........PRODUCT......................BALANCE
PREMIUMS....................................................................CV Ind NQ NP CLIC.............-10057.12
PREMIUMS....................................................................CV Ind Q NP CLIC................0
PREMIUMS....................................................................CV Ind Q Par CLIC...............0
PREMIUMS....................................................................CV Ind NQ Par CLIC..............-6725.39
410210...............00000..............................000...............CV Ind NQ Par CLIC..............-6725.39
410220...............00000..............................000...............CV Ind NQ NP CLIC..............-10057.12
Desired Result:
ACCOUNT...........SUB ACCOUNT NUM............AFFILIATE.................CV Ind NQ NP CLIC..............CV Ind Q NP CLIC.........CV Ind Q Par CLIC...............CV Ind NQ Par CLIC
PREMIUMS................................................................................. -10057.12......................... 0........................ 0........................................... -6725.39
410210........................00000.....................000........................................................................................................................................... -6725.39
410220........................00000.....................000............................ -10057.12
Thanks.

Performance Issue with Webi report uses SAP BI Query as the data source

Hello.
I have created a Webi ad-hoc report which connects to a SAP BI query through BO OLAP universe.
The layout of Webi is the exactly the same as the BI query. There are filters in the Webi to restrict the number of data extraction, but even with data result of 5000 rows, it took about 30 seconds.
If I execute the BI query with the same filter restriction, it tooks less than 10 seconds.
It seems that large percentage of time is consumed at the MDX part.
Is there any tuning method that could speed up the process time of MDX?
Thank you.
Justine
Edited by: Justine Liu on Mar 18, 2009 6:59 AM

Hi,
please take a look here:
[https://service.sap.com/sap/support/notes/1142664] (Look under related notes)
It includes references to various performance improvements of the MDX interface. From what I saw there it is advisable to upgrade your SAP BI (7.0) up to at least Support Package 21 (you are currently on SP 15).
This may also be interesting for you: There is a new Fix Pack 1.4 coming out for BOBJ XI 3.1. Combined with the related SAP Enh.Pack (not sure about the version of this one) should also improve WebI performance. This fix pack is not yet officially released though but it should not take look.
I recommend that you try the upgrade to Support Package 21 first.
BTW it is also advisable to take a look in the results of your MDX query (e.g using the MDXTEST transaction). You should make sure that your query is indeed restricted as expected. Sometimes the results you see in SAP native reporting tools (e.g. BEx Analyzer) differ from those returned from the MDX component, depending on the way variables/restrictions where defined in the query designer. It is all about making sure that there is no apples/oranges comparison here.
Regards,
Stratos

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 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 BW Reports for concurrent users

All:
I notice that one BW report that runs in few seconds will take upto 3.5 minutes when multiple users run it at the same time.
We are in BW 3.5 and we run reports for portal.
Does anyone have any suggestion about how to handle performance issue with concurrent users?
Thanks,
Pranab

Hi,
use the OLAP-cache and/or aggregates and consider using load balancing to distribute the users to several servers.
Kind regards
/martin

Performance issue with HRALXSYNC report..

HI,
I'm facing performance issue with the HRALXSYNC report. As this is Standard report, Can any body suggest me how to optimize the standard report..
Thanks in advance.
Saleem Javed
Moderator message: Please Read before Posting in the Performance and Tuning Forum, also look for existing SAP notes and/or send a support message to SAP.
Edited by: Thomas Zloch on Aug 23, 2011 4:17 PM

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

SAP DS 1.3: Performance issues with crosstab planning (IE only)

Hi everyone,
because im currently developing a custom component for DS 1.3, I got in touch with the planning feature of design studio. Planning currently only works in a crosstab.
Here I recognized a significant performance issue with the internet explorer:
If you simply type in a new value into a cell in a crosstab, it takes ~10s to confirm it (not constant! Sometimes it takes 2s, sometimes 15s). During this 10s, it seems like the IE crashed - no response at all. Sometimes there is also a warning message on bottom ('... script is slowing down the application ...').
Tested the same scenario with Chrome and FF - takes less than 1s to confirm.
Whats going on here ...? Anyone experienced the same issues?
My testing environment:
Windows 8.1
IE 11 (also tested emulated Ie 10 and IE 9 - same problem)
DS 1.3.0.3.201405141058
Local mode
Application only contained a simple crosstab, data source based on BW 7.3 query
Of course I deactivated all custom components while testing...
Kind regards
Wladimir

Hi Tammy,
Thanks for your reply. Of course, my IE is updated to latest version (11.0.9600.17207).
Hopefully SP1 will fix this bug...
Kind regards
Wladimir

Performance Issue with RHBAUS00 Report

Hello All,
In our current project we have scheduled RHBAUS02 and RHBAUS00 reports in Prod, and it runs all fine.
But when we try to execute RHBAUS00 report in quality environment through SA38, it takes much time, infact it goes endless.
Could you please suggest how to decrease the response time of RHBAUS00, currently it just goes on running wihout producing any results.
Thanks
Aditi

Hi Aditi,
Do you run RHBAUS02 with default threshold value 1000? Try increasing that to reduce number of entries in T77UU table. Then run RHBAUS01 to cleanup INDX table. It is good practice to schedule this to happen after RHBAUS02 run to keep the INDX table clean. Then try RHBAU00 again.
I would try above in short term but in long term I think structural profiles should be evaluated again. I have seen many cases where there is massive overkill of restricting course catalogue, qualifications etc. Also using exclude option is good if someone should have all but not one branch of particular structure. Sometimes evaluation paths used bring also lot of extra objects which are not necessary so custom evaluation path may reduce the size of structural profile significally.
Regards,
Saku

Performance issue with the table use vrkpa

Hi.
here is the selection criteria that i am using and the table use vrkpa i only used to map the table kna1 and vbrk.vbrk and kna1 doesnot have the direct primary key relationship.
please check and let me know wht this vrkpa is taking time and how can i improve the performance as from kna1,i am fetching data very easily while fetching nothing from vrkpa and fetching fkdat from vbrk.
the idea behind using these tables is just for one kunnr (from kna1)getting the relevant entries based on the fkdat(selection screen input field),please suggest.
    SELECT kunnr
           name1
           land1
           regio
           ktokd
           FROM kna1
           INTO TABLE it_kna1
           FOR ALL ENTRIES IN it_knb1
           WHERE kunnr = it_knb1-kunnr
           AND ktokd = '0003'.
    IF sy-subrc = 0.
      SORT it_kna1 BY kunnr.
      DELETE ADJACENT DUPLICATES FROM it_kna1 COMPARING kunnr.
    ENDIF.
ENDIF.
IF NOT it_kna1[] IS INITIAL.
    SELECT kunnr
           vbeln
           FROM vrkpa
           INTO TABLE it_vrkpa
           FOR ALL ENTRIES IN it_kna1
           WHERE kunnr = it_kna1-kunnr.
    IF sy-subrc = 0.
      SORT it_vrkpa BY kunnr vbeln.
    ENDIF.
ENDIF.
IF NOT it_vrkpa[] IS INITIAL.
    SELECT vbeln
           kunrg
           fkdat
          kkber
           bukrs
           FROM vbrk
           INTO TABLE it_vbrk
           FOR ALL ENTRIES IN it_vrkpa
           WHERE vbeln = it_vrkpa-vbeln.
    IF sy-subrc = 0.
      DELETE it_vbrk WHERE fkdat NOT IN s_indate.
      DELETE it_vbrk WHERE fkdat NOT IN s_chdate.
      DELETE it_vbrk WHERE bukrs NOT IN s_ccode.
      SORT it_vbrk DESCENDING BY vbeln fkdat.
    ENDIF.
ENDIF.

Hi,
Transaction SE11
Table VRKPA => Display (not Change)
Click on "Indexes"
Click on "Create" (if your system is Basis 7.00, then click on the "Create" drop-down icon and choose "Create extension index")
Choose a name (up to 3 characterss, start with Z)
Enter a description for the index
Enter the field names of the index
Choose "Save" (prompts for transport request)
Choose "Activate"
If after "Activate' the status shows "Index exists in database system <...>", then you have nothing more to dotable is very large the activation will not create the index in the database and the status remains "Index does nor exist". In that case:
- Transaction SE14
- Table VRKPA -> Edit
- Choose "Indexes" and select your new index
- Choose "Create database index"; mark the option "Background"
- Wait until the job is finished and check in SE11 that the index now exists in the DB
You don't have to do anyhting to your program because Oracle should choose the new index automatically. Run a SQL Trace to make sure.
Rgds,
Mark

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.

Issue with complete refresh on materialized view when using rownum

Hi all,
I had an issue with rownum when using complete refresh
I am using rownum when creating materialized view and it is generation correctly.But the issue was when i am refreshing the same ,rownum was not getting sorted in ascending order.
anyone had come across this scenario

rownum is determined as the row is output, so "order by rownum" does literally nothing.
http://docs.oracle.com/cd/B19306_01/server.102/b14200/pseudocolumns009.htm

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 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 Crosstab Reports Using Disco Viewer 10.1.2.48.18

Similar Messages

Maybe you are looking for