Need help in Performance tuning

Hi All,
        I am facing some performance issues in my program. The program taking a hell lot of time to execute and some times timing out without giving the out put. This is a report program with ALV output. It is handling mainly Sales related data.
       The program is fetching a huge volume of data from different tables and processing this bulk data inside the loops several times. In most of the queries I am unable to supply all key fields, because my requirement is like that only. I have many places in my program i am using inner loop and function modules inside loop etc.
        Any pointers on this will be a great help.
Regards,
Jijeesh P G

1) Make sure that any READ or LOOP inside an outer LOOP accesses the inner table with an appropriate key (either using BINARY search when reading a standard table or using sorted/hashed tables for inner tables only). This helps in most cases.
2) If the tables witdh is more than aprox. 30 bytes LOOP ASSIGNING <wa> may help a bit. Declare <wa> for each table separately using the tables line type (otherway type casting would cost some additional time).
3) You may use FM SAPGUI_PROGRESS_INDICATOR in the outer loops to inform the user while he is waiting.
4) A COMMIT from time to time will reset the measured time for timeout ( and therefore avoids timeouts - do NOT use without checking step 1) ).
4) The programm may use virtual memory if a huge amount of data is selected ( I have seen dumps in due to the fact that nor more disk space was available). So - if STEPS 1)-3) failed - look a the process for rollling in/out).

Similar Messages

Need help in Performance tuning for function...

Hi all,
I am using the below algorithm for calculating the Luhn Alogorithm to calculate the 15th luhn digit for an IMEI (Phone Sim Card).
But the below function is taking about 6 min for 5 million records. I had 170 million records in a table want to calculate the luhn digit for all of them which might take up to 4-5 hours.Please help me performance tuning (better way or better logic for luhn calculation) to the below function.
A wikipedia link is provided for the luhn algorithm below
Create or Replace FUNCTION AddLuhnToIMEI (LuhnPrimitive VARCHAR2)
      RETURN VARCHAR2
   AS
      Index_no     NUMBER (2) := LENGTH (LuhnPrimitive);
      Multiplier   NUMBER (1) := 2;
      Total_Sum    NUMBER (4) := 0;
      Plus         NUMBER (2);
      ReturnLuhn   VARCHAR2 (25);
   BEGIN
      WHILE Index_no >= 1
      LOOP
         Plus       := Multiplier * (TO_NUMBER (SUBSTR (LuhnPrimitive, Index_no, 1)));
         Multiplier := (3 - Multiplier);
         Total_Sum := Total_Sum + TO_NUMBER (TRUNC ( (Plus / 10))) + MOD (Plus, 10);
         Index_no   := Index_no - 1;
      END LOOP;
      ReturnLuhn := LuhnPrimitive || CASE
                                         WHEN MOD (Total_Sum, 10) = 0 THEN '0'
                                         ELSE TO_CHAR (10 - MOD (Total_Sum, 10))
                                     END;
      RETURN ReturnLuhn;
   EXCEPTION
      WHEN OTHERS
      THEN
         RETURN (LuhnPrimitive);
   END AddLuhnToIMEI;
http://en.wikipedia.org/wiki/Luhn_algorithmAny sort of help is much appreciated....
Thanks
Rede

There is a not needed to_number function in it. TRUNC will already return a number.
Also the MOD function can be avoided at some steps. Since multiplying by 2 will never be higher then 18 you can speed up the calculation with this.
create or replace
FUNCTION AddLuhnToIMEI_fast (LuhnPrimitive VARCHAR2)
      RETURN VARCHAR2
   AS
      Index_no     pls_Integer;
      Multiplier   pls_Integer := 2;
      Total_Sum    pls_Integer := 0;
      Plus         pls_Integer;
      rest         pls_integer;
      ReturnLuhn   VARCHAR2 (25);
   BEGIN
      for Index_no in reverse 1..LENGTH (LuhnPrimitive) LOOP
         Plus       := Multiplier * TO_NUMBER (SUBSTR (LuhnPrimitive, Index_no, 1));
         Multiplier := 3 - Multiplier;
         if Plus < 10 then
            Total_Sum := Total_Sum + Plus ;
         else
            Total_Sum := Total_Sum + Plus - 9;
         end if;
      END LOOP;
      rest := MOD (Total_Sum, 10);
      ReturnLuhn := LuhnPrimitive || CASE WHEN rest = 0 THEN '0' ELSE TO_CHAR (10 - rest) END;
      RETURN ReturnLuhn;
   END AddLuhnToIMEI_fast;
/My tests gave an improvement for about 40%.
The next step to try could be to use native complilation on this function. This can give an additional big boost.
Edited by: Sven W. on Mar 9, 2011 8:11 PM

Need help with Performance Tuning

Following query takes 8 secs. Any help will be appreciated
SELECT SUM(FuturesMarketVal) FuturesMarketVal
FROM (SELECT CASE WHEN null IS NULL THEN FuturesMarketVal
ELSE DECODE(FUTURES_NAME, null, FuturesMarketVal, 0)
END FuturesMarketVal
FROM (SELECT SUM( (a.FUTURES_ALLOC * (NVL(b.Futures_EOD_Price,0)/100 - NVL(c.Futures_EOD_Price,0)/100) * a.CONTRACT_SIZE) / DECODE(a.CONTRACT_SIZE,100000,1,1000000,4,3000000,12,1) ) FuturesMarketVal,
a.FUTURES_NAME
FROM cms_futures_trans a,
cms_futures_price b,
cms_futures_price c
Where c.history_date (+) = TO_DATE(fas_pas_pkg.get_weekday(to_date('12/30/2005') - 1),'mm/dd/yyyy')
and a.FUTURES_NAME = b.FUTURES_NAME (+)
AND a.trade_date < TO_DATE('12/30/2005','mm/dd/yyyy')
AND b.history_date (+) = TO_DATE('12/30/2005','mm/dd/yyyy')
AND a.FUTURES_NAME = c.FUTURES_NAME (+)
GROUP BY a.FUTURES_NAME
/

Eric:
But there are only 5 records in cms_futures_price and 10 in cms_futures_trans :-)
OP:
I'm not usre what you are trying to fo here, but a couple of comments.
Since NULL IS NULL will always be true, you don;t really need the CASE statement. as it stands, your query will always return FuturesMarketVal. If the results are correct, then you can do without the DECODE as well.
Why are you calling fas_pas_pkg.get_weekday with a constant value? Can you not just use whatever it returns as a constant instead of calling the function?
Are you sure you need all those outer joins? They almost guarantee full scans of the outer joined tables.
Perhaps if you post some representative data from the two tables and an explanation of what you are trying to accomplish someone may have a better idea.
John

Need help in performance

hallow
i doing this select and it take more then 10 minutes and i don't now way because
object_key have just 60 entries ?
how i can slve this problem?
Regards
SELECT * FROM covp APPENDING TABLE *covp
          FOR ALL ENTRIES IN object_key
           WHERE kokrs EQ '1000'
           AND   objnr EQ object_key-objnr
           AND   budat IN so_budat
           AND   stflg EQ space .

Ways of Performance Tuning
1.     Selection Criteria
2.     Select Statements
     Select Queries
     SQL Interface
     Aggregate Functions
     For all Entries
Select Over more than one internal table
Selection Criteria
1.     Restrict the data to the selection criteria itself, rather than filtering it out using the ABAP code using CHECK statement.
2.     Select with selection list.
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
         SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
              SBOOK_WA-CONNID = '0400'.
Select Statements   Select Queries
1.     Avoid nested selects
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
      WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
    FROM EKKO AS P INNER JOIN EKAN AS F
      ON PEBELN = FEBELN.
Note: A simple SELECT loop is a single database access whose result is passed to the ABAP program line by line. Nested SELECT loops mean that the number of accesses in the inner loop is multiplied by the number of accesses in the outer loop. One should therefore use nested SELECT loops only if the selection in the outer loop contains very few lines or the outer loop is a SELECT SINGLE statement.
2.     Select all the records in a single shot using into table clause of select statement rather than to use Append statements.
SELECT * FROM SBOOK INTO SBOOK_WA.
CHECK: SBOOK_WA-CARRID = 'LH' AND
         SBOOK_WA-CONNID = '0400'.
ENDSELECT.
The above code can be much more optimized by the code written below which avoids CHECK, selects with selection list and puts the data in one shot using into table
SELECT CARRID CONNID FLDATE BOOKID FROM SBOOK INTO TABLE T_SBOOK
WHERE SBOOK_WA-CARRID = 'LH' AND
              SBOOK_WA-CONNID = '0400'.
3.     When a base table has multiple indices, the where clause should be in the order of the index, either a primary or a secondary index.
To choose an index, the optimizer checks the field names specified in the where clause and then uses an index that has the same order of the fields. In certain scenarios, it is advisable to check whether a new index can speed up the performance of a program. This will come handy in programs that access data from the finance tables.
4.     For testing existence, use Select.. Up to 1 rows statement instead of a Select-Endselect-loop with an Exit.
SELECT * FROM SBOOK INTO SBOOK_WA
UP TO 1 ROWS
WHERE CARRID = 'LH'.
ENDSELECT.
The above code is more optimized as compared to the code mentioned below for testing existence of a record.
SELECT * FROM SBOOK INTO SBOOK_WA
    WHERE CARRID = 'LH'.
EXIT.
ENDSELECT.
5.     Use Select Single if all primary key fields are supplied in the Where condition .
If all primary key fields are supplied in the Where conditions you can even use Select Single.
Select Single requires one communication with the database system, whereas Select-Endselect needs two.
Select Statements SQL Interface
1.     Use column updates instead of single-row updates
to update your database tables.
SELECT * FROM SFLIGHT INTO SFLIGHT_WA.
SFLIGHT_WA-SEATSOCC =
    SFLIGHT_WA-SEATSOCC - 1.
UPDATE SFLIGHT FROM SFLIGHT_WA.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
UPDATE SFLIGHT
       SET SEATSOCC = SEATSOCC - 1.
2.     For all frequently used Select statements, try to use an index.
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE CARRID = 'LH'
    AND CONNID = '0400'.
ENDSELECT.
The above mentioned code can be more optimized by using the following code
SELECT * FROM SBOOK CLIENT SPECIFIED INTO SBOOK_WA
WHERE MANDT IN ( SELECT MANDT FROM T000 )
    AND CARRID = 'LH'
    AND CONNID = '0400'.
ENDSELECT.
3.     Using buffered tables improves the performance considerably.
Bypassing the buffer increases the network considerably
SELECT SINGLE * FROM T100 INTO T100_WA
BYPASSING BUFFER
WHERE     SPRSL = 'D'
        AND ARBGB = '00'
        AND MSGNR = '999'.
The above mentioned code can be more optimized by using the following code
SELECT SINGLE * FROM T100 INTO T100_WA
WHERE     SPRSL = 'D'
        AND ARBGB = '00'
        AND MSGNR = '999'.
Select Statements Aggregate Functions
     If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.
Some of the Aggregate functions allowed in SAP are MAX, MIN, AVG, SUM, COUNT, COUNT( * )
Consider the following extract.
            Maxno = 0.
            Select * from zflight where airln = LF and cntry = IN.
             Check zflight-fligh > maxno.
             Maxno = zflight-fligh.
            Endselect.
The above mentioned code can be much more optimized by using the following code.
Select max( fligh ) from zflight into maxno where airln = LF and cntry = IN.
Select Statements For All Entries
     The for all entries creates a where clause, where all the entries in the driver table are combined with OR. If the number of entries in the driver table is larger than rsdb/max_blocking_factor, several similar SQL statements are executed to limit the length of the WHERE clause.
     The plus
     Large amount of data
     Mixing processing and reading of data
     Fast internal reprocessing of data
     Fast
     The Minus
     Difficult to program/understand
     Memory could be critical (use FREE or PACKAGE size)
Points to be must considered FOR ALL ENTRIES
     Check that data is present in the driver table
     Sorting the driver table
     Removing duplicates from the driver table
Consider the following piece of extract
          Loop at int_cntry.
Select single * from zfligh into int_fligh
where cntry = int_cntry-cntry.
Append int_fligh.
                      Endloop.
The above mentioned can be more optimized by using the following code.
Sort int_cntry by cntry.
Delete adjacent duplicates from int_cntry.
If NOT int_cntry[] is INITIAL.
            Select * from zfligh appending table int_fligh
            For all entries in int_cntry
            Where cntry = int_cntry-cntry.
Endif.
Select Statements Select Over more than one Internal table
1.     Its better to use a views instead of nested Select statements.
SELECT * FROM DD01L INTO DD01L_WA
WHERE DOMNAME LIKE 'CHAR%'
        AND AS4LOCAL = 'A'.
SELECT SINGLE * FROM DD01T INTO DD01T_WA
    WHERE   DOMNAME    = DD01L_WA-DOMNAME
        AND AS4LOCAL   = 'A'
        AND AS4VERS    = DD01L_WA-AS4VERS
        AND DDLANGUAGE = SY-LANGU.
ENDSELECT.
The above code can be more optimized by extracting all the data from view DD01V_WA
SELECT * FROM DD01V INTO DD01V_WA
WHERE DOMNAME LIKE 'CHAR%'
        AND DDLANGUAGE = SY-LANGU.
ENDSELECT
2.     To read data from several logically connected tables use a join instead of nested Select statements. Joins are preferred only if all the primary key are available in WHERE clause for the tables that are joined. If the primary keys are not provided in join the Joining of tables itself takes time.
SELECT * FROM EKKO INTO EKKO_WA.
SELECT * FROM EKAN INTO EKAN_WA
      WHERE EBELN = EKKO_WA-EBELN.
ENDSELECT.
ENDSELECT.
The above code can be much more optimized by the code written below.
SELECT PF1 PF2 FF3 FF4 INTO TABLE ITAB
    FROM EKKO AS P INNER JOIN EKAN AS F
      ON PEBELN = FEBELN.
3.     Instead of using nested Select loops it is often better to use subqueries.
SELECT * FROM SPFLI
INTO TABLE T_SPFLI
WHERE CITYFROM = 'FRANKFURT'
    AND CITYTO = 'NEW YORK'.
SELECT * FROM SFLIGHT AS F
    INTO SFLIGHT_WA
    FOR ALL ENTRIES IN T_SPFLI
    WHERE SEATSOCC < F~SEATSMAX
      AND CARRID = T_SPFLI-CARRID
      AND CONNID = T_SPFLI-CONNID
      AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
The above mentioned code can be even more optimized by using subqueries instead of for all entries.
SELECT * FROM SFLIGHT AS F INTO SFLIGHT_WA
    WHERE SEATSOCC < F~SEATSMAX
      AND EXISTS ( SELECT * FROM SPFLI
                     WHERE CARRID = F~CARRID
                       AND CONNID = F~CONNID
                       AND CITYFROM = 'FRANKFURT'
                       AND CITYTO = 'NEW YORK' )
      AND FLDATE BETWEEN '19990101' AND '19990331'.
ENDSELECT.
1.     Table operations should be done using explicit work areas rather than via header lines.
READ TABLE ITAB INTO WA WITH KEY K = 'X BINARY SEARCH.
IS MUCH FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY K = 'X'.
If TAB has n entries, linear search runs in O( n ) time, whereas binary search takes only O( log2( n ) ).
2.     Always try to use binary search instead of linear search. But dont forget to sort your internal table before that.
READ TABLE ITAB INTO WA WITH KEY K = 'X'. IS FASTER THAN USING
READ TABLE ITAB INTO WA WITH KEY (NAME) = 'X'.
3.     A dynamic key access is slower than a static one, since the key specification must be evaluated at runtime.
4.     A binary search using secondary index takes considerably less time.
5.     LOOP ... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified condition internally.
LOOP AT ITAB INTO WA WHERE K = 'X'.
ENDLOOP.
The above code is much faster than using
LOOP AT ITAB INTO WA.
CHECK WA-K = 'X'.
ENDLOOP.
6.     Modifying selected components using MODIFY itab TRANSPORTING f1 f2.. accelerates the task of updating a line of an internal table.
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1 TRANSPORTING DATE.
The above code is more optimized as compared to
WA-DATE = SY-DATUM.
MODIFY ITAB FROM WA INDEX 1.
7.     Accessing the table entries directly in a "LOOP ... ASSIGNING ..." accelerates the task of updating a set of lines of an internal table considerably
Modifying selected components only makes the program faster as compared to Modifying all lines completely.
e.g,
LOOP AT ITAB ASSIGNING <WA>.
I = SY-TABIX MOD 2.
IF I = 0.
    <WA>-FLAG = 'X'.
ENDIF.
ENDLOOP.
The above code works faster as compared to
LOOP AT ITAB INTO WA.
I = SY-TABIX MOD 2.
IF I = 0.
    WA-FLAG = 'X'.
    MODIFY ITAB FROM WA.
ENDIF.
ENDLOOP.
8.    If collect semantics is required, it is always better to use to COLLECT rather than READ BINARY and then ADD.
LOOP AT ITAB1 INTO WA1.
READ TABLE ITAB2 INTO WA2 WITH KEY K = WA1-K BINARY SEARCH.
IF SY-SUBRC = 0.
    ADD: WA1-VAL1 TO WA2-VAL1,
         WA1-VAL2 TO WA2-VAL2.
    MODIFY ITAB2 FROM WA2 INDEX SY-TABIX TRANSPORTING VAL1 VAL2.
ELSE.
    INSERT WA1 INTO ITAB2 INDEX SY-TABIX.
ENDIF.
ENDLOOP.
The above code uses BINARY SEARCH for collect semantics. READ BINARY runs in O( log2(n) ) time. The above piece of code can be more optimized by
LOOP AT ITAB1 INTO WA.
COLLECT WA INTO ITAB2.
ENDLOOP.
SORT ITAB2 BY K.
COLLECT, however, uses a hash algorithm and is therefore independent
of the number of entries (i.e. O(1)) .
9.    "APPEND LINES OF itab1 TO itab2" accelerates the task of appending a table to another table considerably as compared to LOOP-APPEND-ENDLOOP.
APPEND LINES OF ITAB1 TO ITAB2.
This is more optimized as compared to
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
10.   DELETE ADJACENT DUPLICATES accelerates the task of deleting duplicate entries considerably as compared to READ-LOOP-DELETE-ENDLOOP.
DELETE ADJACENT DUPLICATES FROM ITAB COMPARING K.
This is much more optimized as compared to
READ TABLE ITAB INDEX 1 INTO PREV_LINE.
LOOP AT ITAB FROM 2 INTO WA.
IF WA = PREV_LINE.
    DELETE ITAB.
ELSE.
    PREV_LINE = WA.
ENDIF.
ENDLOOP.
11.   "DELETE itab FROM ... TO ..." accelerates the task of deleting a sequence of lines considerably as compared to DO -DELETE-ENDDO.
DELETE ITAB FROM 450 TO 550.
This is much more optimized as compared to
DO 101 TIMES.
DELETE ITAB INDEX 450.
ENDDO.
12.   Copying internal tables by using ITAB2[ ] = ITAB1[ ] as compared to LOOP-APPEND-ENDLOOP.
ITAB2[] = ITAB1[].
This is much more optimized as compared to
REFRESH ITAB2.
LOOP AT ITAB1 INTO WA.
APPEND WA TO ITAB2.
ENDLOOP.
13.   Specify the sort key as restrictively as possible to run the program faster.
SORT ITAB BY K. makes the program runs faster as compared to SORT ITAB.
Internal Tables         contd
Hashed and Sorted tables
1.     For single read access hashed tables are more optimized as compared to sorted tables.
2.      For partial sequential access sorted tables are more optimized as compared to hashed tables
Hashed And Sorted Tables
Point # 1
Consider the following example where HTAB is a hashed table and STAB is a sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE HTAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
This runs faster for single read access as compared to the following same code for sorted table
DO 250 TIMES.
N = 4 * SY-INDEX.
READ TABLE STAB INTO WA WITH TABLE KEY K = N.
IF SY-SUBRC = 0.
ENDIF.
ENDDO.
Point # 2
Similarly for Partial Sequential access the STAB runs faster as compared to HTAB
LOOP AT STAB INTO WA WHERE K = SUBKEY.
ENDLOOP.
This runs faster as compared to
LOOP AT HTAB INTO WA WHERE K = SUBKEY.
ENDLOOP.

Need help in query tuning

Hi All,
In my application I have 3 tables. Event(1.2 L records), KeyWord(1K records) and Event_KeyWord_Mapping(1.4 L records) table.
In my query i need to sort the Events table by 3 columns -( 1 Date column and 2 String column) and i am interested only in top 40 records.
Below is the example query.
select
    from
        (    select
                  a.*,
            ROWNUM
        from
            (    select
                distinct event_id
            from
                (     select
                    (this_.EVENT_ID),
                    this_.EVENT_GMT_DATE ,
                    this_.PRIORITY
                from
                    EVENTS this_,
                    event_keyword_mapping ekp
                where
                    this_.EVENT_ID = ekp.event_id
                    AND ekp.keyword_id IN (
                        1643,2278,24,1090,2422,401 )
                    AND (
                            EVENT_CODE = 'IEP'
                            AND (
                                IS_SCALL = 'Y'
                                AND COUNTRY_DISPLAY IN (
                                    'US','CA','UK','BE','FR','DE','IT','JP','AU','CH','EU'
                    OR (
                            EVENT_CODE = 'ICC'
                            AND IS_GTINDEX = 'Y'
                    AND FX_EVENT = 'N'
                    AND EVENT_GMT_DATE BETWEEN to_date('12/27/2011 05:14:00','mm/dd/yyyy HH24:MI:SS')and
to_date('03/27/2012 10:28:44','mm/dd/yyyy HH24:MI:SS')
                ORDER BY
                    EVENT_GMT_DATE ASC ,
                    PRIORITY ASC ,
                    EVENT_ID ASC )) a
            where
                ROWNUM<=41)(1643,2278,24,1090,2422,401) keywords have 90K+ mappings.
Below is the explain plan for the above query.
| Id | Operation                               | Name                           | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                        |                                |    41 | 1066 |       |   629K (85)| 02:05:51 |
|   1 | VIEW                                   |                                |    41 | 1066 |       |   629K (85)| 02:05:51 |
|* 2 |   COUNT STOPKEY                         |                                |       |       |       |            |          |
|   3 |    VIEW                                 |                                | 25738 |   326K|       |   629K (85)| 02:05:51 |
|* 4 |     SORT GROUP BY STOPKEY               |                                | 25738 |   955K| 6929M|   629K (2)| 02:05:51 |
|   5 |      CONCATENATION                      |                                |       |       |       |            |          |
|   6 |       MERGE JOIN CARTESIAN              |                                |   150M| 5463M|       | 96245   (2)| 00:19:15 |
|   7 |        TABLE ACCESS BY INDEX ROWID      | EVENTS                         | 1132 | 32828 |       | 1618   (1)| 00:00:20 |
|   8 |         BITMAP CONVERSION TO ROWIDS     |                                |       |       |       |            |          |
|   9 |          BITMAP AND                     |                                |       |       |       |            |          |
| 10 |           BITMAP CONVERSION FROM ROWIDS |                                |       |       |       |            |          |
| 11 |            SORT ORDER BY                |                                |       |       |       |            |          |
|* 12 |             INDEX RANGE SCAN            | EVT_PRIORITY_GMT_DATE_ID_INDEX | 30402 |       |       |    68   (0)| 00:00:01 |
| 13 |           BITMAP CONVERSION FROM ROWIDS |                                |       |       |       |            |          |
|* 14 |            INDEX RANGE SCAN             | EVENT_CODE_INDEX               | 30402 |       |       |    79   (0)| 00:00:01 |
| 15 |           BITMAP CONVERSION FROM ROWIDS |                                |       |       |       |            |          |
|* 16 |            INDEX RANGE SCAN             | FX_EVENT_INDEX                 | 30402 |       |       |   102   (1)| 00:00:02 |
| 17 |           BITMAP CONVERSION FROM ROWIDS |                                |       |       |       |            |          |
|* 18 |            INDEX RANGE SCAN             | IS_GTINDEX_INDEX               | 30402 |       |       |   102   (1)| 00:00:02 |
| 19 |        BUFFER SORT                      |                                |   133K| 1170K|       | 94627   (2)| 00:18:56 |
| 20 |         TABLE ACCESS FULL               | EVENT_KEYWORD_MAPPING          |   133K| 1170K|       |    84   (3)| 00:00:02 |
|* 21 |       HASH JOIN                         |                                | 6691 |   248K|       | 2489   (1)| 00:00:30 |
|* 22 |        TABLE ACCESS BY INDEX ROWID      | EVENTS                         | 1937 | 56173 |       | 2401   (1)| 00:00:29 |
| 23 |         BITMAP CONVERSION TO ROWIDS     |                                |       |       |       |            |          |
| 24 |          BITMAP AND                     |                                |       |       |       |            |          |
| 25 |           BITMAP OR                     |                                |       |       |       |            |          |
| 26 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 27 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 28 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 29 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 30 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 31 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 32 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 33 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 34 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 35 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 36 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 37 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 38 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 39 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 40 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 41 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 42 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 43 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 44 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 45 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 46 |            BITMAP CONVERSION FROM ROWIDS|                                |       |       |       |            |          |
|* 47 |             INDEX RANGE SCAN            | COUNTRY_DISPLAY_INDEX          | 30402 |       |       |     3   (0)| 00:00:01 |
| 48 |           BITMAP CONVERSION FROM ROWIDS |                                |       |       |       |            |          |
|* 49 |            INDEX RANGE SCAN             | EVENT_CODE_INDEX               | 30402 |       |       |    79   (0)| 00:00:01 |
| 50 |           BITMAP CONVERSION FROM ROWIDS |                                |       |       |       |            |          |
|* 51 |            INDEX RANGE SCAN             | IS_SCALL_INDEX                 | 30402 |       |       |   100   (1)| 00:00:02 |
|* 52 |        TABLE ACCESS FULL                | EVENT_KEYWORD_MAPPING          | 88609 |   778K|       |    87   (4)| 00:00:02 |
Predicate Information (identified by operation id):
   2 - filter(ROWNUM<=41)
   4 - filter(ROWNUM<=41)
12 - access("EVENT_GMT_DATE">=TO_DATE(' 2011-12-27 05:14:00', 'syyyy-mm-dd hh24:mi:ss') AND "EVENT_GMT_DATE"<=TO_DATE('
              2012-03-27 10:28:44', 'syyyy-mm-dd hh24:mi:ss'))
       filter("EVENT_GMT_DATE"<=TO_DATE(' 2012-03-27 10:28:44', 'syyyy-mm-dd hh24:mi:ss') AND "EVENT_GMT_DATE">=TO_DATE('
              2011-12-27 05:14:00', 'syyyy-mm-dd hh24:mi:ss'))
14 - access("EVENT_CODE"='ICC')
16 - access("FX_EVENT"='N')
18 - access("IS_GTINDEX"='Y')
21 - access("THIS_"."EVENT_ID"="EKP"."EVENT_ID")
22 - filter(LNNVL("EVENT_CODE"='ICC') OR LNNVL("IS_GTINDEX"='Y') OR LNNVL("FX_EVENT"='N') OR
              LNNVL("EVENT_GMT_DATE">=TO_DATE(' 2011-12-27 05:14:00', 'syyyy-mm-dd hh24:mi:ss')) OR LNNVL("EVENT_GMT_DATE"<=TO_DATE('
              2012-03-27 10:28:44', 'syyyy-mm-dd hh24:mi:ss')))
27 - access("COUNTRY_DISPLAY"='AU')
29 - access("COUNTRY_DISPLAY"='BE')
31 - access("COUNTRY_DISPLAY"='CA')
33 - access("COUNTRY_DISPLAY"='CH')
35 - access("COUNTRY_DISPLAY"='DE')
37 - access("COUNTRY_DISPLAY"='EU')
39 - access("COUNTRY_DISPLAY"='FR')
41 - access("COUNTRY_DISPLAY"='IT')
43 - access("COUNTRY_DISPLAY"='JP')
45 - access("COUNTRY_DISPLAY"='UK')
47 - access("COUNTRY_DISPLAY"='US')
49 - access("EVENT_CODE"='IEP')
51 - access("IS_SCALL"='Y')
52 - filter("EKP"."KEYWORD_ID"=24 OR "EKP"."KEYWORD_ID"=401 OR "EKP"."KEYWORD_ID"=1090 OR "EKP"."KEYWORD_ID"=1643 OR
              "EKP"."KEYWORD_ID"=2278 OR "EKP"."KEYWORD_ID"=2422)                                                                                                                                                                                                                                           When the above query is executed its taking around 10 seconds to return the data.
I am using- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit
I need help in bringing down the query execution time.
Thanks,
Girish G

A few questions:
1. Are any indexes available on the Event_KeyWord_Mapping table?
2. What does '1.4 L records' mean? Not familiar with 'L'.
3. Are the statistics up to date for the tables and indexes involved?
4. Are EVENT_ID and KEYWORD_ID the only columns accessed from the Event_KeyWord_Mapping table?
Assuming the above then DarkStargate's suggestion is on point.
But you should add the KEYWORD_ID column to the index as well since that is what the index records are filtered on.
AND ekp.keyword_id IN (
                        1643,2278,24,1090,2422,401 )Be sure that index statistics are collected; they will provide Oracle with data about the distribution of KEYWORD_ID values.
This will allow Oracle to get the required information from the index without accessing the Event_KeyWord_Mapping table itself.

Need help with performance & memory tuning in a data warehousing environment

Dear All,
Good Day.
We had successfully migrated from a 4 node half-rack V2 Exadata to a 2 node quarter rack X4-2 Exadata. However, we are facing some issues with performance only for few loads while others have in fact shown good improvement.
1. The total memory on the OS is 250GB for each node (two compute nodes for a quarter rack).
2. Would be grateful if someone could help me with the best equation to calculate the SGA and PGA ( and also in allocation of shared_pool, large_pool etc) or whether Automatic Memory Management is advisable?
3. We had run exachk report which suggested us to configure huge pages.
4. When we tried to increase the SGA to more than 30GB the system doesn't allow us to do so. We had however set the PGA to 85GB.
5. Also, we had observed that some of the queries involving joins and indexes are taking longer time.
Any advise would be greatly appreciated.
Warm Regards,
Vikram.

Hi Vikram,
There is no formula about SGA and PGA, but the best practices for OLTP environments is for a give ammount of memory (which cannot be up to 80% of total RAM from server) you should make 80% to SGA and 20% to PGA. For Data Warehouse envs, the values are like 60% SGA and 40% PGA or it can be up to 50%-50%. Also, some docs disencourage you to keep the database in Automatic Memory Management when you are using a big SGA (> 10G).
As you are using a RAC environment, you should configure Huge Pages. And if the systems are not allowing you to increase memory, just take a look at the semaphore parameters, probably they are set lower values. And for the poor performance queries, we need to see explain plans, table structure and you would also analyze if smart scan is playing the game.
Regards.

Need Help in sql tuning in EXADATA environment

I am uploadin the sql with its current explain plan, this sql in Prd database is executing in 6-10 mins and we need to improve this sql perf to 1-2 mins as the requirement from business team.
I am giving some backgroud about this sql tuning requirement, this sql is newly developed in and currently is in UAT phase, we don't have much option for tuning code here since the sql is tool generated through COGNOS DataMart tool, options are there to look into from DBA end with plan level or creating indexes on suitible columns to reduce i/o in minimizing the rows traversing by the sql.
Is anybody can help me out here?
WITH "WCRS_CLAIM_DETAIL_VW5"
AS (SELECT "WCRS_CLAIM_DETAIL_VW"."CLAIM_DETAIL_PK_ID"
"CLAIM_DETAIL_PK_ID",
"WCRS_CLAIM_DETAIL_VW"."CLAIM_ID" "CLAIM_ID",
"WCRS_CLAIM_DETAIL_VW"."CURRENT_SNAPSHOT_IND"
"CURRENT_SNAPSHOT_IND",
"WCRS_CLAIM_DETAIL_VW"."LOSS_DT" "LOSS_DT",
"WCRS_CLAIM_DETAIL_VW"."REGULATORY_STATE_CD"
"REGULATORY_STATE_CD"
FROM "CDW_DLV_IDS"."WCRS_CLAIM_DETAIL_VW" "WCRS_CLAIM_DETAIL_VW"
WHERE "WCRS_CLAIM_DETAIL_VW"."CURRENT_SNAPSHOT_IND" = 'Y'),
"WCRS_POLICY_DETAIL_VW7"
AS (SELECT "WCRS_POLICY_DETAIL_VW"."CLAIM_NBR" "CLAIM_NBR",
"WCRS_POLICY_DETAIL_VW"."CLAIM_SYMBOL_CD" "CLAIM_SYMBOL_CD",
"WCRS_POLICY_DETAIL_VW"."CURRENT_SNAPSHOT_IND"
"CURRENT_SNAPSHOT_IND",
"WCRS_POLICY_DETAIL_VW"."KEY_OFFICE_CD" "KEY_OFFICE_CD",
"WCRS_POLICY_DETAIL_VW"."POLICY_NBR" "POLICY_NBR"
FROM "CDW_DLV_IDS"."WCRS_POLICY_DETAIL_VW" "WCRS_POLICY_DETAIL_VW"
WHERE "WCRS_POLICY_DETAIL_VW"."CURRENT_SNAPSHOT_IND" = 'Y')
SELECT /*+ gather_plan_statistics monitor bind_aware */
/* ^^unique_id */
"T0"."C0" "Account_Name",
"T0"."C1" "Accident_State_Cd",
"T0"."C2" "c3",
"T0"."C3" "PPO_Name",
"T0"."C4" "Invc_Classification_Type_Desc",
FIRST_VALUE (
"T0"."C5")
OVER (
PARTITION BY "T0"."C0",
"T0"."C1",
"T0"."C2",
"T0"."C3",
"T0"."C4",
"T0"."C6")
"Claim_Cnt___Distinct",
"T0"."C7" "Invc_Control_Number",
"T0"."C8" "Invc_Allowance_Amt",
"T0"."C9" "Invc_Charge_Amt",
"T0"."C10" "c10",
"T0"."C11" "PPO_Reduction_Amt",
"T0"."C12" "Dup_Ln_Save_Amt",
"T0"."C13" "c13",
"T0"."C14" "Sub_Total",
"T0"."C15" "c15",
"T0"."C6" "c16"
FROM (SELECT "T1"."C0" "C0",
"T1"."C1" "C1",
"T1"."C2" "C2",
"T1"."C3" "C3",
"T1"."C4" "C4",
"T1"."C6" "C5",
"T1"."C5" "C6",
"T0"."C0" "C7",
"T1"."C7" "C8",
"T1"."C8" "C9",
"T1"."C9" "C10",
"T1"."C10" "C11",
"T1"."C11" "C12",
"T1"."C12" "C13",
"T1"."C13" "C14",
"T1"."C14" "C15"
FROM (SELECT COUNT (DISTINCT "INVC_DIM_VW"."INVC_ID") "C0"
FROM "CDW_DLV_IDS"."WCRS_POLICY_GROUPING_VW" "WCRS_POLICY_GROUPING_VW",
"WCRS_CLAIM_DETAIL_VW5",
"EDW_DM"."INVC_DIM_VW" "INVC_DIM_VW",
"EDW_DM"."PROVIDER_NETWORK_DIM_VW" "PROVIDER_NETWORK_DIM_VW",
"EDW_DM"."INVC_ACTY_SNPSHT_FACT_VW" "INVC_ACTY_SNPSHT_FACT_VW6",
"EDW_DM"."CURRENT_MED_INVC_RPT_DT_VW" "CURRENT_MED_INVC_RPT_DT_VW",
"EDW_DM"."ALL_INVC_SNPSHT_FACT_VW" "ALL_INVC_SNPSHT_FACT_VW",
"CDW_DLV_IDS"."WCRS_CURRENT_CLAIM_RPT_DT_VW" "WCRS_CURRENT_CLAIM_RPT_DT_VW",
"CDW_DLV_IDS"."WCRS_CLAIM_FACT_VW" "WCRS_CLAIM_FACT_VW",
"WCRS_POLICY_DETAIL_VW7",
"EDW_DM"."INVC_CLAIM_DTL_BRDG_FACT_VW" "INVC_CLAIM_DTL_BRDG_FACT_VW"
WHERE "INVC_DIM_VW"."INVC_DELETION_IND" <> 'Y'
AND "INVC_DIM_VW"."INVC_CONSIDRTN_TYPE_DESC" =
'Original'
AND "CURRENT_MED_INVC_RPT_DT_VW"."CURRENT_MONTH_RPT_DT" =
"ALL_INVC_SNPSHT_FACT_VW"."AS_OF_MONTH_END_DT_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
AND "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" =
CAST ('1ST TEAM STAFFING SERVICES, INC.' AS VARCHAR (50 CHAR))
AND "WCRS_POLICY_DETAIL_VW7"."POLICY_NBR" =
"WCRS_POLICY_GROUPING_VW"."POLICY_IDENTIFIER"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_NBR" =
"WCRS_CLAIM_FACT_VW"."CLAIM_NBR"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_SYMBOL_CD" =
"WCRS_CLAIM_FACT_VW"."CLAIM_SYMBOL_CD"
AND "WCRS_POLICY_DETAIL_VW7"."KEY_OFFICE_CD" =
"WCRS_CLAIM_FACT_VW"."KEY_OFFICE_CD"
AND "WCRS_POLICY_DETAIL_VW7"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_DETAIL_PK_ID" =
"WCRS_CLAIM_DETAIL_VW5"."CLAIM_DETAIL_PK_ID"
AND "WCRS_CLAIM_DETAIL_VW5"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_GID" =
"INVC_CLAIM_DTL_BRDG_FACT_VW"."CLM_GID"
AND "INVC_CLAIM_DTL_BRDG_FACT_VW"."INVC_GID" =
"INVC_DIM_VW"."INVC_GID"
AND "INVC_DIM_VW"."INVC_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."MONTH_END_DT_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."MONTH_END_DT_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."INVC_GID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_GID"
AND "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."PPO_PROVIDER_NETWORK_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT") "T0",
( SELECT "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" "C0",
"WCRS_CLAIM_DETAIL_VW5"."REGULATORY_STATE_CD" "C1",
CASE
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'Y'
THEN
'In - Network'
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'N'
THEN
'Out - Network'
ELSE
'Others'
END
"C2",
"PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_NM" "C3",
"INVC_DIM_VW"."INVC_CLASS_TYPE_DESC" "C4",
CASE
WHEN (EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
OR (EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
THEN
NULL
ELSE
( EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
|| EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT")))
END
"C5",
COUNT (DISTINCT "WCRS_CLAIM_DETAIL_VW5"."CLAIM_ID")
"C6",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_ALWC_AMT") "C7",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CHRGS_AMT")
"C8",
SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."TOT_INVC_REVIEW_RULE_ALWC_AMT")
"C9",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PPO_REDUC_AMT")
"C10",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_DUP_REDUC_AMT")
"C11",
SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_OSR_REDUC_AMT")
"C12",
( SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CHRGS_AMT")
- SUM ("INVC_ACTY_SNPSHT_FACT_VW6"."INVC_ALWC_AMT"))
- SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_DUP_REDUC_AMT")
"C13",
SUM (
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_CLNT_SPEC_REDUC_AMT")
"C14"
FROM "CDW_DLV_IDS"."WCRS_POLICY_GROUPING_VW" "WCRS_POLICY_GROUPING_VW",
"WCRS_CLAIM_DETAIL_VW5",
"EDW_DM"."INVC_DIM_VW" "INVC_DIM_VW",
"EDW_DM"."PROVIDER_NETWORK_DIM_VW" "PROVIDER_NETWORK_DIM_VW",
"EDW_DM"."INVC_ACTY_SNPSHT_FACT_VW" "INVC_ACTY_SNPSHT_FACT_VW6",
"EDW_DM"."CURRENT_MED_INVC_RPT_DT_VW" "CURRENT_MED_INVC_RPT_DT_VW",
"EDW_DM"."ALL_INVC_SNPSHT_FACT_VW" "ALL_INVC_SNPSHT_FACT_VW",
"CDW_DLV_IDS"."WCRS_CURRENT_CLAIM_RPT_DT_VW" "WCRS_CURRENT_CLAIM_RPT_DT_VW",
"CDW_DLV_IDS"."WCRS_CLAIM_FACT_VW" "WCRS_CLAIM_FACT_VW",
"WCRS_POLICY_DETAIL_VW7",
"EDW_DM"."INVC_CLAIM_DTL_BRDG_FACT_VW" "INVC_CLAIM_DTL_BRDG_FACT_VW"
WHERE "INVC_DIM_VW"."INVC_DELETION_IND" <> 'Y'
AND "INVC_DIM_VW"."INVC_CONSIDRTN_TYPE_DESC" =
'Original'
AND "CURRENT_MED_INVC_RPT_DT_VW"."CURRENT_MONTH_RPT_DT" =
"ALL_INVC_SNPSHT_FACT_VW"."AS_OF_MONTH_END_DT_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
AND "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM" =
CAST ('1ST TEAM STAFFING SERVICES, INC.' AS VARCHAR (50 CHAR))
AND "WCRS_POLICY_DETAIL_VW7"."POLICY_NBR" =
"WCRS_POLICY_GROUPING_VW"."POLICY_IDENTIFIER"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_NBR" =
"WCRS_CLAIM_FACT_VW"."CLAIM_NBR"
AND "WCRS_POLICY_DETAIL_VW7"."CLAIM_SYMBOL_CD" =
"WCRS_CLAIM_FACT_VW"."CLAIM_SYMBOL_CD"
AND "WCRS_POLICY_DETAIL_VW7"."KEY_OFFICE_CD" =
"WCRS_CLAIM_FACT_VW"."KEY_OFFICE_CD"
AND "WCRS_POLICY_DETAIL_VW7"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_DETAIL_PK_ID" =
"WCRS_CLAIM_DETAIL_VW5"."CLAIM_DETAIL_PK_ID"
AND "WCRS_CLAIM_DETAIL_VW5"."CURRENT_SNAPSHOT_IND" =
'Y'
AND "WCRS_CLAIM_FACT_VW"."CLAIM_GID" =
"INVC_CLAIM_DTL_BRDG_FACT_VW"."CLM_GID"
AND "INVC_CLAIM_DTL_BRDG_FACT_VW"."INVC_GID" =
"INVC_DIM_VW"."INVC_GID"
AND "INVC_DIM_VW"."INVC_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."MONTH_END_DT_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."MONTH_END_DT_PK_ID"
AND "ALL_INVC_SNPSHT_FACT_VW"."INVC_GID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."INVC_GID"
AND "PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_PK_ID" =
"INVC_ACTY_SNPSHT_FACT_VW6"."PPO_PROVIDER_NETWORK_PK_ID"
AND "WCRS_CURRENT_CLAIM_RPT_DT_VW"."CURRENT_CLAIM_RPT_DT" =
"WCRS_CLAIM_FACT_VW"."CLAIM_REPORTING_DT"
GROUP BY "WCRS_POLICY_GROUPING_VW"."ACCOUNT_NM",
"WCRS_CLAIM_DETAIL_VW5"."REGULATORY_STATE_CD",
CASE
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'Y'
THEN
'In - Network'
WHEN "INVC_DIM_VW"."INVC_IN_OUT_OF_NETWORK_IND" =
'N'
THEN
'Out - Network'
ELSE
'Others'
END,
"PROVIDER_NETWORK_DIM_VW"."PROVIDER_NETWORK_NM",
"INVC_DIM_VW"."INVC_CLASS_TYPE_DESC",
CASE
WHEN (EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
OR (EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
IS NULL)
THEN
NULL
ELSE
( EXTRACT (
YEAR FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT"))
|| EXTRACT (
MONTH FROM ("WCRS_CLAIM_DETAIL_VW5"."LOSS_DT")))
END) "T1") "T0"
ORDER BY "Account_Name" ASC NULLS LAST,
"Accident_State_Cd" ASC NULLS LAST,
"c3" ASC NULLS LAST,
"PPO_Name" ASC NULLS LAST,
"Invc_Classification_Type_Desc" ASC NULLS LAST

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 838 | 1079K (1)| 00:00:34 | | |
| 1 | TEMP TABLE TRANSFORMATION | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 10M| 317M| 848K (1)| 00:00:27 | | |
| 4 | LOAD AS SELECT | SYS_TEMP_0FD9D677A_286AAA2E | | | | | | |
| 5 | PX BLOCK ITERATOR | | 10M| 317M| 848K (1)| 00:00:27 | | |
|* 6 | TABLE ACCESS STORAGE FULL | WCRS_CLAIM_DETAIL | 10M| 317M| 848K (1)| 00:00:27 | | |
| 7 | PX COORDINATOR | | | | | | | |
| 8 | PX SEND QC (RANDOM) | :TQ20000 | 10M| 268M| 44875 (1)| 00:00:02 | | |
| 9 | LOAD AS SELECT | SYS_TEMP_0FD9D677B_286AAA2E | | | | | | |
| 10 | PX BLOCK ITERATOR | | 10M| 268M| 44875 (1)| 00:00:02 | | |
|* 11 | TABLE ACCESS STORAGE FULL | WCRS_POLICY_DETAIL | 10M| 268M| 44875 (1)| 00:00:02 | | |
| 12 | PX COORDINATOR | | | | | | | |
| 13 | PX SEND QC (ORDER) | :TQ40017 | 1 | 838 | 186K (2)| 00:00:06 | | |
| 14 | WINDOW SORT | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 15 | PX RECEIVE | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 16 | PX SEND RANGE | :TQ40016 | 1 | 838 | 186K (2)| 00:00:06 | | |
| 17 | NESTED LOOPS | | 1 | 838 | 186K (2)| 00:00:06 | | |
| 18 | BUFFER SORT | | | | | | | |
| 19 | PX RECEIVE | | | | | | | |
| 20 | PX SEND BROADCAST | :TQ40001 | | | | | | |
| 21 | VIEW | | 1 | 13 | 93216 (2)| 00:00:03 | | |
| 22 | SORT GROUP BY | | 1 | 393 | | | | |
| 23 | PX COORDINATOR | | | | | | | |
| 24 | PX SEND QC (RANDOM) | :TQ30015 | 1 | 393 | | | | |
| 25 | SORT GROUP BY | | 1 | 393 | | | | |
| 26 | PX RECEIVE | | 1 | 393 | | | | |
| 27 | PX SEND HASH | :TQ30014 | 1 | 393 | | | | |
| 28 | SORT GROUP BY | | 1 | 393 | | | | |
|* 29 | HASH JOIN ANTI | | 1 | 393 | 93216 (2)| 00:00:03 | | |
| 30 | PX RECEIVE | | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 31 | PX SEND HASH | :TQ30012 | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 32 | BUFFER SORT | | 1 | 838 | | | | |
| 33 | NESTED LOOPS | | 1 | 376 | 85197 (2)| 00:00:03 | | |
| 34 | NESTED LOOPS | | 1 | 358 | 85197 (2)| 00:00:03 | | |
| 35 | NESTED LOOPS | | 1 | 348 | 85197 (2)| 00:00:03 | | |
|* 36 | HASH JOIN ANTI | | 1 | 316 | 85179 (2)| 00:00:03 | | |
| 37 | PX RECEIVE | | 4 | 1156 | 77161 (2)| 00:00:03 | | |
| 38 | PX SEND HASH | :TQ30010 | 4 | 1156 | 77161 (2)| 00:00:03 | | |
|* 39 | HASH JOIN ANTI BUFFERED | | 4 | 1156 | 77161 (2)| 00:00:03 | | |
| 40 | PX RECEIVE | | 371 | 94605 | 69142 (2)| 00:00:03 | | |
| 41 | PX SEND HASH | :TQ30008 | 371 | 94605 | 69142 (2)| 00:00:03 | | |
|* 42 | HASH JOIN | | 371 | 94605 | 69142 (2)| 00:00:03 | | |
| 43 | PX RECEIVE | | 350 | 77000 | 36642 (1)| 00:00:02 | | |
| 44 | PX SEND BROADCAST | :TQ30007 | 350 | 77000 | 36642 (1)| 00:00:02 | | |
|* 45 | HASH JOIN | | 350 | 77000 | 36642 (1)| 00:00:02 | | |
| 46 | PX RECEIVE | | 140 | 25200 | 28624 (1)| 00:00:01 | | |
| 47 | PX SEND BROADCAST | :TQ30006 | 140 | 25200 | 28624 (1)| 00:00:01 | | |
|* 48 | HASH JOIN | | 140 | 25200 | 28624 (1)| 00:00:01 | | |
| 49 | PX RECEIVE | | 140 | 22820 | 25169 (1)| 00:00:01 | | |
| 50 | PX SEND BROADCAST | :TQ30005 | 140 | 22820 | 25169 (1)| 00:00:01 | | |
|* 51 | HASH JOIN BUFFERED | | 140 | 22820 | 25169 (1)| 00:00:01 | | |
| 52 | BUFFER SORT | | | | | | | |
| 53 | PX RECEIVE | | 9 | 306 | 5 (0)| 00:00:01 | | |
| 54 | T PX SEND BROADCAS | :TQ30000 | 9 | 306 | 5 (0)| 00:00:01 | | |
| 55 | INDEX ROWID TABLE ACCESS BY | WCRS_POLICY_GROUPING | 9 | 306 | 5 (0)| 00:00:01 | | |
|* 56 | AN INDEX RANGE SC | SUK3 | 9 | | 1 (0)| 00:00:01 | | |
|* 57 | HASH JOIN | | 9699K| 1193M| 25149 (1)| 00:00:01 | | |
| 58 | PX RECEIVE | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 59 | PX SEND HASH | :TQ30003 | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 60 | NESTED LOOPS | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 61 | BUFFER SORT | | | | | | | |
| 62 | PX RECEIVE | | | | | | | |
| 63 | DCAST PX SEND BROA | :TQ30002 | | | | | | |
| 64 | CARTESIAN MERGE JOIN | | 1 | 14 | 13 (0)| 00:00:01 | | |
| 65 | TERATOR PX BLOCK I | | 1 | 8 | 10 (0)| 00:00:01 | | |
| 66 | ESS STORAGE FULL TABLE ACC | CURRENT_MED_INVC_RPT_DT | 1 | 8 | 10 (0)| 00:00:01 | | |
| 67 | T BUFFER SOR | | 1 | 6 | 3 (0)| 00:00:01 | | |
| 68 | E PX RECEIV | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 69 | BROADCAST PX SEND | :TQ30001 | 1 | 6 | 2 (0)| 00:00:01 | | |
| 70 | K ITERATOR PX BLOC | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 71 | ACCESS STORAGE FULL TABLE | WCRS_CURRENT_CLAIM_RPT_DT | 1 | 6 | 2 (0)| 00:00:01 | | |
| 72 | TOR PX BLOCK ITERA | | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|* 73 | STORAGE FULL TABLE ACCESS | WCRS_CURRENT_CLAIM_FACT | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
| 74 | PX RECEIVE | | 10M| 785M| 2907 (2)| 00:00:01 | | |
| 75 | PX SEND HASH | :TQ30004 | 10M| 785M| 2907 (2)| 00:00:01 | | |
|* 76 | VIEW | | 10M| 785M| 2907 (2)| 00:00:01 | | |
| 77 | TOR PX BLOCK ITERA | | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 78 | STORAGE FULL TABLE ACCESS | SYS_TEMP_0FD9D677B_286AAA2E | 10M| 268M| 2907 (2)| 00:00:01 | | |
|* 79 | VIEW | | 10M| 168M| 3439 (2)| 00:00:01 | | |
| 80 | PX BLOCK ITERATOR | | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 81 | E FULL TABLE ACCESS STORAG | SYS_TEMP_0FD9D677A_286AAA2E | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 82 | PX BLOCK ITERATOR | | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 83 | LL TABLE ACCESS STORAGE FU | INVC_CLAIM_DTL_BRDG_FACT | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 84 | PX BLOCK ITERATOR | | 15M| 521M| 32477 (2)| 00:00:02 | | |
|* 85 | TABLE ACCESS STORAGE FULL | INVC_DIM | 15M| 521M| 32477 (2)| 00:00:02 | | |
| 86 | PX RECEIVE | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 87 | PX SEND HASH | :TQ30009 | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 88 | PX BLOCK ITERATOR | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 89 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 90 | PX RECEIVE | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 91 | PX SEND HASH | :TQ30011 | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 92 | PX BLOCK ITERATOR | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 93 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 94 | TABLE ACCESS BY INDEX ROWID | INVC_ACTY_SNPSHT_FACT | 1 | 32 | 18 (0)| 00:00:01 | | |
|* 95 | INDEX RANGE SCAN | IFK_XPKINVOICE_ACTIVITY_SNAPSH | 1 | | 1 (0)| 00:00:01 | | |
|* 96 | INDEX UNIQUE SCAN | IFK_XPKPROVIDER_NETWORK_DIM | 1 | 10 | 0 (0)| 00:00:01 | | |
|* 97 | INDEX RANGE SCAN | IFK_XPKALL_INVC_SNPSHT_FACT | 1 | 18 | 1 (0)| 00:00:01 | | |
| 98 | PX RECEIVE | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 99 | PX SEND HASH | :TQ30013 | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 100 | PX BLOCK ITERATOR | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 101 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 102 | VIEW | | 1 | 825 | | | | |
| 103 | SORT GROUP BY | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 104 | BUFFER SORT | | | | | | | |
| 105 | PX RECEIVE | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 106 | PX SEND HASH | :TQ40015 | 1 | 430 | 93216 (2)| 00:00:03 | | |
|*107 | HASH JOIN ANTI BUFFERED | | 1 | 430 | 93216 (2)| 00:00:03 | | |
| 108 | PX RECEIVE | | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 109 | PX SEND HASH | :TQ40013 | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 110 | BUFFER SORT | | 1 | 838 | | | | |
| 111 | NESTED LOOPS | | 1 | 413 | 85198 (2)| 00:00:03 | | |
| 112 | NESTED LOOPS | | 1 | 395 | 85197 (2)| 00:00:03 | | |
| 113 | NESTED LOOPS | | 1 | 369 | 85197 (2)| 00:00:03 | | |
|*114 | HASH JOIN ANTI | | 1 | 311 | 85179 (2)| 00:00:03 | | |
| 115 | PX RECEIVE | | 4 | 1136 | 77161 (2)| 00:00:03 | | |
| 116 | PX SEND HASH | :TQ40011 | 4 | 1136 | 77161 (2)| 00:00:03 | | |
|*117 | HASH JOIN ANTI BUFFERED | | 4 | 1136 | 77161 (2)| 00:00:03 | | |
| 118 | PX RECEIVE | | 371 | 92750 | 69143 (2)| 00:00:03 | | |
| 119 | PX SEND HASH | :TQ40009 | 371 | 92750 | 69143 (2)| 00:00:03 | | |
|*120 | HASH JOIN | | 371 | 92750 | 69143 (2)| 00:00:03 | | |
| 121 | PX RECEIVE | | 350 | 72450 | 36642 (1)| 00:00:02 | | |
| 122 | PX SEND BROADCAST | :TQ40008 | 350 | 72450 | 36642 (1)| 00:00:02 | | |
|*123 | HASH JOIN | | 350 | 72450 | 36642 (1)| 00:00:02 | | |
| 124 | PX RECEIVE | | 140 | 23380 | 28624 (1)| 00:00:01 | | |
| 125 | PX SEND BROADCAST | :TQ40007 | 140 | 23380 | 28624 (1)| 00:00:01 | | |
|*126 | HASH JOIN | | 140 | 23380 | 28624 (1)| 00:00:01 | | |
| 127 | PX RECEIVE | | 140 | 15540 | 25169 (1)| 00:00:01 | | |
| 128 | PX SEND BROADCAST | :TQ40006 | 140 | 15540 | 25169 (1)| 00:00:01 | | |
|*129 | HASH JOIN BUFFERED | | 140 | 15540 | 25169 (1)| 00:00:01 | | |
| 130 | BUFFER SORT | | | | | | | |
| 131 | PX RECEIVE | | 9 | 306 | 5 (0)| 00:00:01 | | |
| 132 | PX SEND BROADCAST | :TQ40000 | 9 | 306 | 5 (0)| 00:00:01 | | |
| 133 | ROWID TABLE ACCESS BY INDEX | WCRS_POLICY_GROUPING | 9 | 306 | 5 (0)| 00:00:01 | | |
|*134 | INDEX RANGE SCAN | SUK3 | 9 | | 1 (0)| 00:00:01 | | |
|*135 | HASH JOIN | | 9699K| 712M| 25149 (1)| 00:00:01 | | |
| 136 | PX RECEIVE | | 10M| 287M| 2907 (2)| 00:00:01 | | |
| 137 | PX SEND HASH | :TQ40004 | 10M| 287M| 2907 (2)| 00:00:01 | | |
|*138 | VIEW | | 10M| 287M| 2907 (2)| 00:00:01 | | |
| 139 | PX BLOCK ITERATOR | | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 140 | E FULL TABLE ACCESS STORAG | SYS_TEMP_0FD9D677B_286AAA2E | 10M| 268M| 2907 (2)| 00:00:01 | | |
| 141 | PX RECEIVE | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 142 | PX SEND HASH | :TQ40005 | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 143 | NESTED LOOPS | | 9699K| 434M| 22205 (1)| 00:00:01 | | |
| 144 | BUFFER SORT | | | | | | | |
| 145 | PX RECEIVE | | | | | | | |
| 146 | PX SEND BROADCAST | :TQ40003 | | | | | | |
| 147 | IAN MERGE JOIN CARTES | | 1 | 14 | 13 (0)| 00:00:01 | | |
| 148 | R PX BLOCK ITERATO | | 1 | 8 | 10 (0)| 00:00:01 | | |
| 149 | ORAGE FULL TABLE ACCESS ST | CURRENT_MED_INVC_RPT_DT | 1 | 8 | 10 (0)| 00:00:01 | | |
| 150 | BUFFER SORT | | 1 | 6 | 3 (0)| 00:00:01 | | |
| 151 | PX RECEIVE | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 152 | AST PX SEND BROADC | :TQ40002 | 1 | 6 | 2 (0)| 00:00:01 | | |
| 153 | ATOR PX BLOCK ITER | | 1 | 6 | 2 (0)| 00:00:01 | | |
| 154 | STORAGE FULL TABLE ACCESS | WCRS_CURRENT_CLAIM_RPT_DT | 1 | 6 | 2 (0)| 00:00:01 | | |
| 155 | PX BLOCK ITERATOR | | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|*156 | E FULL TABLE ACCESS STORAG | WCRS_CURRENT_CLAIM_FACT | 9699K| 305M| 22192 (1)| 00:00:01 | KEY | KEY |
|*157 | VIEW | | 10M| 555M| 3439 (2)| 00:00:01 | | |
| 158 | PX BLOCK ITERATOR | | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 159 | TABLE ACCESS STORAGE FULL | SYS_TEMP_0FD9D677A_286AAA2E | 10M| 317M| 3439 (2)| 00:00:01 | | |
| 160 | PX BLOCK ITERATOR | | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 161 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 599M| 7994 (1)| 00:00:01 | | |
| 162 | PX BLOCK ITERATOR | | 15M| 641M| 32477 (2)| 00:00:02 | | |
|*163 | TABLE ACCESS STORAGE FULL | INVC_DIM | 15M| 641M| 32477 (2)| 00:00:02 | | |
| 164 | PX RECEIVE | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 165 | PX SEND HASH | :TQ40010 | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 166 | PX BLOCK ITERATOR | | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 167 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 509M| 7994 (1)| 00:00:01 | | |
| 168 | PX RECEIVE | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 169 | PX SEND HASH | :TQ40012 | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 170 | PX BLOCK ITERATOR | | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 171 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 404M| 7994 (1)| 00:00:01 | | |
| 172 | TABLE ACCESS BY INDEX ROWID | INVC_ACTY_SNPSHT_FACT | 1 | 58 | 18 (0)| 00:00:01 | | |
|*173 | INDEX RANGE SCAN | IFK_XPKINVOICE_ACTIVITY_SNAPSH | 1 | | 1 (0)| 00:00:01 | | |
| 174 | TABLE ACCESS BY INDEX ROWID | PROVIDER_NETWORK_DIM | 1 | 26 | 0 (0)| 00:00:01 | | |
|*175 | INDEX UNIQUE SCAN | IFK_XPKPROVIDER_NETWORK_DIM | 1 | | 0 (0)| 00:00:01 | | |
|*176 | INDEX RANGE SCAN | IFK_XPKALL_INVC_SNPSHT_FACT | 1 | 18 | 1 (0)| 00:00:01 | | |
| 177 | PX RECEIVE | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 178 | PX SEND HASH | :TQ40014 | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 179 | PX BLOCK ITERATOR | | 15M| 254M| 7994 (1)| 00:00:01 | | |
| 180 | TABLE ACCESS STORAGE FULL | INVC_CLAIM_DTL_BRDG_FACT | 15M| 254M| 7994 (1)| 00:00:01 | | |
---------------------------------------------------------------------------------------------------------------------------------------------------------------

Need help writing Performance Management Report

Hi Experts
I need some help retrieving specific Performance Management data for a report.
I have the employee pernr.
1. From this I need to determine which teams the employee belonged to for the period 1 Oct - 31 Sept.
2. What was the total performance score for the TEAM for that same period.
Can someone please help me out. The table data seems to be quite complex.
Thannks in advance
Anton Kruse
Moderator Message: Specs-dumping is not allowed. Please get back if you have a specific question
Edited by: kishan P on Mar 7, 2012 5:10 PM

Hi Arnold,
I think the solution provided by Vadim is the only way and it's working.
Shrikant

Need help in performance tunning

Hi , i have one update statement , where it is keep on running for hours and the volume of the data is 2.2 million
version:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
below is the code :
DECLARE
Cursor C11
Is
Select Account_Num,Outlet_Num,Product_Number,Ln_Of_Biz,Generateguid('DELIVERED_PRODUCT') As Dp_Guid From (
Select Account_Num,Outlet_Num,Product_Number,Ln_Of_Biz
From transformation_flat
Group By Account_Num, Outlet_Num,Ln_Of_Biz,Product_Number
Having Count(*)> 1);
Type Actno Is Table Of Varchar2(13) Index By Binary_Integer;
Type Outlet Is Table Of NUMBER Index By Binary_Integer;
Type Pno Is Table Of VARCHAR2(255) INDEX BY BINARY_INTEGER;
Type Tn Is Table Of VARCHAR2(10) Index By Binary_Integer;
Type Vdpguid Is Table Of VARCHAR2(20) Index By Binary_Integer;
Type Vcnt Is Table Of Number Index By Binary_Integer;
Type Lob1 Is Table Of Varchar2(255) Index By Binary_Integer;
Type Offer_No Is Table Of Varchar2(255) Index By Binary_Integer;
V_Actno Actno;
V_Outlet Outlet;
V_Pno Pno;
V_Tn Tn;
V_DPGUID VDPGUID;
Vguid Varchar2(20);
V_Cnt Vcnt;
V_Lob Lob1;
V_Offer_No Offer_No;
BEGIN
Open c11;
Loop
Fetch C11 Bulk Collect Into V_Actno,V_Outlet,V_Pno,V_Lob,V_Dpguid;
Exit When C11%Notfound;
End Loop;
close c11;
Forall I In 1..V_Actno.count
Update transformation_flat Set Product_Guid=V_Dpguid(I) Where
Account_Num=V_Actno(I) And
Outlet_Num=V_Outlet(I) And
Product_Number=V_Pno(I) And
ln_of_biz=v_lob(I);
Commit;
END;
for above i do have index on that table on (account_num,outlet_num,product_number,ln_of_biz).
when i checked the memory contents for this sqlid in v$sql , below are the values :
Disk_Read:21640650
Buffer_Gets:22466856
Concurrency_Wait_Time:16923
Cluster_Wait_Time:36313694
user_io_wait_time:3594365433
I need some inputs in which area i can tune the above code..
Thanks

835589 wrote:
hi i am also face same performance issue pls reply me ASApDon't use the word ASAP, it is rude and a violation of forum terms and conditions.
http://www.oracle.com/html/terms.html
>
4. Use of Community Services
Community Services are provided as a convenience to users and Oracle is not obligated to provide any technical support for, or participate in, Community Services. While Community Services may include information regarding Oracle products and services, including information from Oracle employees, they are not an official customer support channel for Oracle.
You may use Community Services subject to the following: (a) Community Services may be used solely for your personal, informational, noncommercial purposes; (b) Content provided on or through Community Services may not be redistributed; and (c) personal data about other users may not be stored or collected except where expressly authorized by Oracle
>
These people are for ASAP requests.
http://www.google.com/search?q=oracle+consultant
where i need to tune the queery.
pls i am eagarly waiting for that
Read and understand the links posted above
RPuttagunta wrote:
HOW TO: Post a SQL statement tuning request - template posting
When your query takes too long ...

Need help in Fine Tuning this query

Hello Gurus,
The below sql's are from Application engine . It runs more than 5 hours to complete . I have fewer knowledge on sql tuning and request to repharse the sql's to perform and complete the program within One hour.
PS_GE_GAPS_INV is going thru Range Scan and TAO table is going for Full Table Scan.
I have indexes on PS_GE_GAPS_INV which is the main table. Iam joining TAO(Temporary table) and Main Table with common keys defined thru Application designer.
Appreciate all your help.
First Sql :
UPDATE PS_GE_GAPS_INV
SET LAST_DTTM_UPDATE = TO_DATE(SYSDATE,'DD-MM-YY-HH24.MI.SS."000000"')
WHERE
(BUSINESS_UNIT,RECONCILE_DT,GE_INVENTORY_SOURC,TAG_NUMBER,ASSET_ID,SERIAL_ID_TR,S
ERIAL_ID,GE_CUSTODIAN_PHY,CUSTODIAN,DEPTID_P,DEPTID,CHARTFIELD2,CHARTFIELD3,GE_GA
P_RULE,SEQUENCENO) IN (
SELECT DISTINCT B.BUSINESS_UNIT
,B.RECONCILE_DT
,B.GE_INVENTORY_SOURC
,B.TAG_NUMBER
,B.ASSET_ID
,B.SERIAL_ID_TR
,B.SERIAL_ID
,B.GE_CUSTODIAN_PHY
,B.CUSTODIAN
,B.DEPTID_P
,B.DEPTID
,B.CHARTFIELD2
,B.CHARTFIELD3
,B.GE_GAP_RULE
,B.SEQUENCENO
FROM PS_GE_GAPS_TAO A
, PS_GE_GAPS_INV B
WHERE A.BUSINESS_UNIT = B.BUSINESS_UNIT
AND (A.RECONCILE_DT = B.RECONCILE_DT
OR (A.RECONCILE_DT IS NULL
AND B.RECONCILE_DT IS NULL))
AND A.GE_GAP_RULE = B.GE_GAP_RULE
AND A.SEQUENCENO = B.SEQUENCENO
AND A.GE_INVENTORY_SOURC = B.GE_INVENTORY_SOURC
AND A.TAG_NUMBER = B.TAG_NUMBER
AND A.ASSET_ID = B.ASSET_ID
AND A.SERIAL_ID_TR = B.SERIAL_ID_TR
AND A.SERIAL_ID = B.SERIAL_ID
AND A.GE_CUSTODIAN_PHY = B.GE_CUSTODIAN_PHY
AND A.CUSTODIAN = B.CUSTODIAN
AND A.DEPTID_P = B.DEPTID_P
AND A.DEPTID = B.DEPTID
AND A.CHARTFIELD2 = B.CHARTFIELD2
AND A.CHARTFIELD3 = B.CHARTFIELD3
AND A.BUSINESS_UNIT = %Bind(BUSINESS_UNIT)
AND A.RECONCILE_DT = %Bind(RECONCILE_DT)
AND A.PROCESS_INSTANCE =%ProcessInstance)
Second Sql :
INSERT INTO PS_GE_GAPS_INV (BUSINESS_UNIT
, RECONCILE_DT
, GE_GAP_RULE
, SEQUENCENO
, GE_INVENTORY_SOURC
, TAG_NUMBER
, ASSET_ID
, SERIAL_ID_TR
, SERIAL_ID
, GE_CUSTODIAN_PHY
, CUSTODIAN
, VENDOR_ID
, DEPTID_P
, DEPTID
, CHARTFIELD2
, CHARTFIELD3
, GE_GAP_STATUS
, CERTMESSAGE
, LAST_DTTM_UPDATE
, COMMENT1
, ASSET_STATUS
, DESCR1
, DESCR
, NAME1_AC
, NAME1
, CATEGORY_DESCR
, CATEGORY
, OPERATING_UNIT_TO
, OPERATING_UNIT
, PROJECT_ID_P
, PROJECT_ID
, PRODUCT_TO
, PRODUCT
, INV_ITEM_ID
, ITEM_FIELD_C30_B
, ITEM_FIELD_C30_C)
SELECT DISTINCT B.BUSINESS_UNIT
, B.RECONCILE_DT
, B.GE_GAP_RULE
, B.SEQUENCENO
, B.GE_INVENTORY_SOURC
, B.TAG_NUMBER
, B.ASSET_ID
, B.SERIAL_ID_TR
, B.SERIAL_ID
, B.GE_CUSTODIAN_PHY
, B.CUSTODIAN
, B.VENDOR_ID
, B.DEPTID_P
, B.DEPTID
, B.CHARTFIELD2
, B.CHARTFIELD3
, B.GE_GAP_STATUS
, B.CERTMESSAGE
, B.LAST_DTTM_UPDATE
, B.COMMENT1
, B.ASSET_STATUS
, B.DESCR1
, B.DESCR
, B.NAME1_AC
, B.NAME1
, B.CATEGORY_DESCR
, B.CATEGORY
, B.OPERATING_UNIT_TO
, B.OPERATING_UNIT
, B.PROJECT_ID_P
, B.PROJECT_ID
, B.PRODUCT_TO
, B.PRODUCT
, B.INV_ITEM_ID
, B.ITEM_FIELD_C30_B
, B.ITEM_FIELD_C30_C
FROM PS_GE_GAPS_TAO B
WHERE B.BUSINESS_UNIT = %Bind(BUSINESS_UNIT)
AND B.RECONCILE_DT =%Bind(RECONCILE_DT)
AND NOT EXISTS (
SELECT 'X'
FROM PS_GE_GAPS_INV A
WHERE B.BUSINESS_UNIT = A.BUSINESS_UNIT
AND (B.RECONCILE_DT = A.RECONCILE_DT
OR (B.RECONCILE_DT IS NULL
AND A.RECONCILE_DT IS NULL))
AND B.GE_GAP_RULE = A.GE_GAP_RULE
AND B.SEQUENCENO = A.SEQUENCENO
AND B.GE_INVENTORY_SOURC = A.GE_INVENTORY_SOURC
AND B.TAG_NUMBER = A.TAG_NUMBER
AND B.ASSET_ID = A.ASSET_ID
AND B.SERIAL_ID_TR = A.SERIAL_ID_TR
AND B.SERIAL_ID = A.SERIAL_ID
AND B.GE_CUSTODIAN_PHY = A.GE_CUSTODIAN_PHY
AND B.CUSTODIAN = A.CUSTODIAN
AND B.DEPTID_P = A.DEPTID_P
AND B.DEPTID = A.DEPTID
AND B.CHARTFIELD2 = A.CHARTFIELD2
AND B.CHARTFIELD3 = A.CHARTFIELD3)
Third Sql :
INSERT INTO PS_GE_GAPST_TAO (BUSINESS_UNIT
, RECONCILE_DT
, GE_GAP_RULE
, SEQUENCENO
, GE_INVENTORY_SOURC
, TAG_NUMBER
, ASSET_ID
, SERIAL_ID_TR
, GE_CUSTODIAN_PHY
, SERIAL_ID
, CUSTODIAN
, DEPTID_P
, DEPTID
, CHARTFIELD2
, CHARTFIELD3
, PROCESS_INSTANCE
, GE_GAP_STATUS
, CERTMESSAGE
, LAST_DTTM_UPDATE
, COMMENT1
, ASSET_STATUS
, DESCR1
, DESCR
, VENDOR_ID
, NAME1_AC
, NAME1
, CATEGORY_DESCR
, CATEGORY
, OPERATING_UNIT_TO
, OPERATING_UNIT
, PROJECT_ID_P
, PROJECT_ID
, PRODUCT_TO
, PRODUCT
, INV_ITEM_ID
, ITEM_FIELD_C30_B
, ITEM_FIELD_C30_C)
SELECT DISTINCT BUSINESS_UNIT
, RECONCILE_DT
, GE_GAP_RULE
, SEQUENCENO
, GE_INVENTORY_SOURC
, TAG_NUMBER
, ASSET_ID
, SERIAL_ID_TR
, GE_CUSTODIAN_PHY
, SERIAL_ID
, CUSTODIAN
, DEPTID_P
, DEPTID
, CHARTFIELD2
, CHARTFIELD3
, %ProcessInstance
, GE_GAP_STATUS
, CERTMESSAGE
, LAST_DTTM_UPDATE
, COMMENT1
, ASSET_STATUS
, DESCR1
, DESCR
, VENDOR_ID
, NAME1_AC
, NAME1
, CATEGORY_DESCR
, CATEGORY
, OPERATING_UNIT_TO
, OPERATING_UNIT
, PROJECT_ID_P
, PROJECT_ID
, PRODUCT_TO
, PRODUCT
, INV_ITEM_ID
, ITEM_FIELD_C30_B
, ITEM_FIELD_C30_C
FROM ps_ge_gaps_inv B
WHERE b.business_unit = %Bind(BUSINESS_UNIT)
AND b.reconcile_dt =%Bind(RECONCILE_DT)
AND NOT EXISTS (
SELECT 'X'
FROM ps_ge_gaps_tao a
WHERE A.BUSINESS_UNIT = B.BUSINESS_UNIT
AND (A.RECONCILE_DT = B.RECONCILE_DT
OR (A.RECONCILE_DT IS NULL
AND B.RECONCILE_DT IS NULL))
AND A.GE_GAP_RULE = B.GE_GAP_RULE
AND A.SEQUENCENO = B.SEQUENCENO
AND A.GE_INVENTORY_SOURC = B.GE_INVENTORY_SOURC
AND A.TAG_NUMBER = B.TAG_NUMBER
AND A.ASSET_ID = B.ASSET_ID
AND A.SERIAL_ID_TR = B.SERIAL_ID_TR
AND A.SERIAL_ID = B.SERIAL_ID
AND A.GE_CUSTODIAN_PHY = B.GE_CUSTODIAN_PHY
AND A.CUSTODIAN = B.CUSTODIAN
AND A.DEPTID_P = B.DEPTID_P
AND A.DEPTID = B.DEPTID
AND A.CHARTFIELD2 = B.CHARTFIELD2
AND A.CHARTFIELD3 = B.CHARTFIELD3 )
Best Regards,
Bala

Are the statistics on your temp table up to date?. Either add an %UpdateStats SQL step after loading the temp table, or check the following notes if your database is Oracle and is a relatively current version:
pscbo_stats - Improving Statistics in Oracle RDBMS for PeopleSoft Enterprise [ID 1322888.1]
E-ORA PeopleSoft Enterprise Performance on Oracle 11g Database [ID 1460735.1]
Regards,
Bob

Need help on performance of this sql

Hi,
I have 2million records in my table, now i need to add one new column and have to update records into this column using sequence.
Ex. update table_name
set new_column = sequ_name.nextval
where col1 = batch_id;
My question is, if i update like this for the batch_id(same id for 1.5million records), will it affect the performace. or is it any other best way to achieve this...
kindly help..
Regards,
Nag

We had a similar project and in test it took several hours to run. When I upped the sequence cache to 5000 it completed in less than a 10th of the time. Worth trialling different values for the sequence cache, as I suspect there are diminishing returns as it gets larger (setting the cache size to 1.5 million would probably not be a good idea).

Need suggestion on Performance tuning

Hi,
We have a container with the single document which is of size 3 MB around. This document contains some master data, it will be used across the application.
we have implemented transactions for the whole application recently,so that we could avoid the db locks now. But, it resulted in some performance overhead especially for this single document container.
For example, we have a scenario to display all the records from the document on the screen at a time. That time it is taking too much time when compared to earlier to the transactions implementations.And we will be using (read operation) this container data very freequently (most of the pages) as it is master data.
Please let me know, is there any approach/solution for the above case particularly to boost the performance on the container?
Thanks,
Balakrishna.

Thank you for the response.
Here 'display all records' mean read operation on the document. We perform read operations very frequently.
We do have write operations to update the document in between read operations.
Also the index has been done for frequently used nodes in the document.
Hope the above information gives you more details. Please let me know if you need any information.
Thanks,
Balakrishna.

Need help for performance tunning

Hello,
I have 16K records return by query, it takes long time to proceed for 7K it takes 7.5 sec.
Note: I used all seeded tables only.
If possible please help me to tune it.
SELECT       msi.inventory_item_id,msi.segment1,msi.rimary_uom_code , msi.primary_unit_of_measure
FROM mtl_system_items_b msi, qp_list_lines qpll,qp_pricing_attributes qppr,
          mtl_category_sets_tl mcs,mtl_category_sets_b mcsb,
          mtl_categories_b mc, mtl_item_categories mcb
WHERE     msi.enabled_flag = 'Y'
     AND qpll.list_line_id = qppr.list_line_id
     AND qppr.product_attr_value = TO_CHAR (msi.inventory_item_id(+))
     AND qppr.product_uom_code = msi.primary_uom_code
     AND mc.category_id = mcb.category_id
     AND msi.inventory_item_id = mcb.inventory_item_id
     AND msi.organization_id = mcb.organization_id
     AND TRUNC (SYSDATE) BETWEEN NVL (qpll.start_date_active,TRUNC (SYSDATE)) AND NVL (qpll.end_date_active,TRUNC (SYSDATE))
     AND mcs.category_set_name = 'LSS SALES CATEGORY'
     AND mcs.language = 'US'
     AND mcs.category_set_id = mcsb.category_set_id
     AND mcsb.structure_id = mc.structure_id
     AND msi.organization_id = :p_organization_id
     AND qpll.list_header_id = :p_price_list_id
     AND mcb.category_id = :p_category_id;
Thanks and regards
Akil.

Thanks Helios ,
here is answers
Databse version
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit
PL/SQL Release 11.1.0.7.0
explain plan
| Id | Operation                       | Name                     | Rows | Bytes | Cost (%CPU)|
|
0 | SELECT STATEMENT
|                          |
1 |   149 | 9439
(1)|
|
1 | NESTED LOOPS                   |                          |     1 |
149 | 9439   (1)|
|*
2 |   HASH JOIN OUTER               |                          |     1 |
135 | 9437   (1)|
|*
3 |    HASH JOIN                    |                          |     1 |
71 | 9432   (1)|
|
4 |     NESTED LOOPS                |                          |     2 |
76 |    53   (0)|
|*
5 |      TABLE ACCESS BY INDEX
ROWID| QP_LIST_LINES            |     2 |
44 |    49   (0)|
|*
6 |       INDEX SKIP SCAN           | QP_LIST_LINES_N2         |
702 |       |    20
(0)|
|*
7 |      INDEX RANGE SCAN           | QP_PRICING_ATTRIBUTES_N3 |     1 |
16 |     2   (0)|
|*
8 |     TABLE ACCESS BY INDEX
ROWID | MTL_SYSTEM_ITEMS_B       | 46254
| 1490K|
9378   (1)|
|*
9 |      INDEX RANGE SCAN           | MTL_SYSTEM_ITEMS_B_N9    | 46254 |       |
174   (1)|
|
10 |    TABLE ACCESS FULL            | XX_WEB_ITEM_IMAGE_TBL    |
277 | 17728 |     5   (0)|
|* 11 |   INDEX RANGE SCAN              | MTL_ITEM_CATEGORIES_U1   |
1 |    14 |     2
(0)|
Predicate Information (identified
by operation id):
2 -
access("XWIIT"."IMAGE_CODE"(+)="MSI"."SEGMENT1")
3 -
access("QPPR"."PRODUCT_ATTR_VALUE"=TO_CHAR("MSI"."INVENTORY_ITEM_ID")
AND
"QPPR"."PRODUCT_UOM_CODE"="MSI"."PRIMARY_UOM_CODE")
5 - filter(NVL("QPLL"."START_DATE_ACTIVE",TRUNC(SYSDATE@!))<=TRUNC(SYSDATE@!)
AND
NVL("QPLL"."END_DATE_ACTIVE",TRUNC(SYSDATE@!))>=TRUNC(SYSDATE@!))
6 -
access("QPLL"."LIST_HEADER_ID"=TO_NUMBER(:P_PRICE_LIST_ID))
filter("QPLL"."LIST_HEADER_ID"=TO_NUMBER(:P_PRICE_LIST_ID))
7 -
access("QPLL"."LIST_LINE_ID"="QPPR"."LIST_LINE_ID")
filter("QPPR"."PRODUCT_UOM_CODE" IS NOT NULL)
8 - filter("MSI"."ENABLED_FLAG"='Y')
9 - access("MSI"."ORGANIZATION_ID"=TO_NUMBER(:P_ORGANIZATION_ID))
11 -
access("MCB"."ORGANIZATION_ID"=TO_NUMBER(:P_ORGANIZATION_ID)
AND
"MSI"."INVENTORY_ITEM_ID"="MCB"."INVENTORY_ITEM_ID"
AND
"MCB"."CATEGORY_ID"=TO_NUMBER(:P_CATEGORY_ID))
       filter("MCB"."CATEGORY_ID"=TO_NUMBER(:P_CATEGORY_ID))
Note
- 'PLAN_TABLE' is old version
TKprof Plan
TKPROF: Release 11.1.0.7.0 - Production on Fri Nov 15 06:12:26 2013
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: LSSD_ora_19760.trc
Sort options: default
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
SELECT msi.inventory_item_id,
       msi.segment1,
       primary_uom_code,
       primary_unit_of_measure,
       xwiit.image_url
FROM mtl_system_items_b msi,
       qp_list_lines qpll,
       qp_pricing_attributes qppr,
       mtl_item_categories mcb,
       xx_web_item_image_tbl xwiit
WHERE     msi.enabled_flag = 'Y'
       AND qpll.list_line_id = qppr.list_line_id
       AND qppr.product_attr_value = TO_CHAR (msi.inventory_item_id)
       AND qppr.product_uom_code = msi.primary_uom_code
       AND msi.inventory_item_id = mcb.inventory_item_id
       AND msi.organization_id = mcb.organization_id
       AND TRUNC (SYSDATE) BETWEEN NVL (qpll.start_date_active,
                                        TRUNC (SYSDATE))
                               AND NVL (qpll.end_date_active,
                                        TRUNC (SYSDATE))
       AND xwiit.image_code(+) = msi.segment1
       AND msi.organization_id = :p_organization_id
       AND qpll.list_header_id = :p_price_list_id
       AND mcb.category_id = :p_category_id
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute      2      0.00       0.00          0          0          0           0
Fetch        2      3.84       3.85          0     432560          0        1002
total        6      3.84       3.85          0     432560          0        1002
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 173
Rows     Row Source Operation
    501 NESTED LOOPS (cr=216280 pr=0 pw=0 time=115 us cost=9439 size=149 card=1)
   2616   HASH JOIN OUTER (cr=211012 pr=0 pw=0 time=39 us cost=9437 size=135 card=1)
78568    HASH JOIN (cr=210997 pr=0 pw=0 time=3786 us cost=9432 size=71 card=1)
78571     NESTED LOOPS (cr=29229 pr=0 pw=0 time=35533 us cost=53 size=76 card=2)
78571      TABLE ACCESS BY INDEX ROWID QP_LIST_LINES (cr=9943 pr=0 pw=0 time=27533 us cost=49 size=44 card=2)
226733       INDEX SKIP SCAN QP_LIST_LINES_N2 (cr=865 pr=0 pw=0 time=4122 us cost=20 size=0 card=702)(object id 99730)
78571      INDEX RANGE SCAN QP_PRICING_ATTRIBUTES_N3 (cr=19286 pr=0 pw=0 time=0 us cost=2 size=16 card=1)(object id 99733)
128857     TABLE ACCESS BY INDEX ROWID MTL_SYSTEM_ITEMS_B (cr=181768 pr=0 pw=0 time=9580 us cost=9378 size=1526382 card=46254)
128857      INDEX RANGE SCAN MTL_SYSTEM_ITEMS_B_N9 (cr=450 pr=0 pw=0 time=1657 us cost=174 size=0 card=46254)(object id 199728)
    277    TABLE ACCESS FULL XX_WEB_ITEM_IMAGE_TBL (cr=15 pr=0 pw=0 time=22 us cost=5 size=17728 card=277)
    501   INDEX RANGE SCAN MTL_ITEM_CATEGORIES_U1 (cr=5268 pr=0 pw=0 time=0 us cost=2 size=14 card=1)(object id 99557)
Note: I modified query and it gives good result, now it takes 3 to 4 sec for 16000 records.
If possible can you plz explain what we have to take care while doing performance tunning
I am a fresher so don't have that much idea.
and also Thanks Hussein for your replay

Very urgent-----help in performance tuning

hai all,
I had used inner join for getting data from 5 tables.
performance is very low in this case.
now i want to increase the performance. how can i do this.
coding for the select statement is ......
SELECT agpnr bname1 bname2 bpstlz bort01 bstras b~street2
           bname1_maco bname2_maco baliasname bispadrbsnd
    INTO CORRESPONDING FIELDS OF TABLE it_tab
    FROM jgtgpnr AS a
    INNER JOIN jgtsadr AS b ON
    aadrnr = badrnr
    INNER JOIN jjtvm AS c ON
    agpnr = ckunnr
    INNER JOIN kna1 AS k ON
    agpnr = kkunnr
    INNER JOIN knvv AS v ON
    agpnr = vkunnr
    WHERE ( ajktokd = 'MADV' OR ajktokd = 'MADO' )
    AND c~vkorg = pr_vkorg
    AND v~vkorg = pr_vkorg
    AND gpnr IN so_gpnr
    AND k~aufsd IN so_block
    AND v~aufsd IN so_blck
please give me a good suggesstion for this.
thanks in advance.

Hi
Try to use for all entries
Eg
if u have itab1 and itab2.
      select vbeln netwr from vbak into table itab1.
      if not itab1[] is initial
      select vbeln matnr matkl from vbap into table itab2
      for all entries in itab1 where vbeln = itab1-vbeln.
      endif.
Hope this will help u.
regards
P.Thangaraj

Pls help in performance tuning SQL

Hi All,
Can someone please help me to tune this quesry. Rt now it is takin 20 mins tro retuns 80,000 rows and its using dblink
SELECT COUNT(*) FROM
(SELECT /*+driving_site(main)*/CORP_ACTG_PRD_YEAR,
CORP_ACTG_PRD_NBR,
FCN_CODE,
LOCAL_CRNC_CODE,
GL_LOCAL_AMT,
CORP_ID,
PGRD_COST_CTR_ID,
MAJOR_CODE,
EXP_MINOR_CODE,
PGRD_EXP_CODE,
PGRD_EXP_DESC,
DIV_CODE,
MKT_CODE,
PROD_CODE,
PGRD_PROJECT_CODE,
PGRD_PROJ_SHORT_DESC
FROM --#GifDBLink# main,
[email protected] main,
select actg_prd_year, actg_prd_nbr from DM_GIF_ESSBASE_CTRL
where cur_prd_ind='Y' and src_id=84
union
select decode(actg_prd_nbr,1,actg_prd_year-1,actg_prd_year) actg_prd_year,
decode(actg_prd_nbr,1,12,actg_prd_nbr-1) actg_prd_nbr
from DM_GIF_ESSBASE_CTRL
where cur_prd_ind='Y' and src_id=84
union
select decode(actg_prd_nbr,12,actg_prd_year+1,actg_prd_year) actg_prd_year,
decode(actg_prd_nbr,12,1,actg_prd_nbr+1) actg_prd_nbr
from DM_GIF_ESSBASE_CTRL
where cur_prd_ind='Y' and src_id=84 ) minor
where main.CORP_ACTG_PRD_YEAR = minor.actg_prd_year
and main.CORP_ACTG_PRD_NBR = minor.actg_prd_nbr) T;

user13365939 wrote:
anyone?Incorrect.
You are only one who can provide the information that was requested in this thread.
Please see the FAQ, read the instructions and provide the necessary information.
Re: 3. How to improve the performance of my query? / My query is running slow.

Need help in Performance tuning

Similar Messages

Maybe you are looking for