Help needed to tune the Query:Statistics added

Can someone DBA please help me to tune this query:
SELECT DISTINCT K.ATTRIBUTE_VALUE AGENCY_ID,B.PROFILE_NM ,NVL(G.OFFICE_DESC,'--') OFFICE_DESC,f.OFFICE_ID,B.PROFILE_ID,'%' ROLE,'%' LAYOUT,
CASE
WHEN 'flagB' = '%' THEN
NVL(J.ISS_GRP_DESC,'BILLING')
WHEN 'flagO' = '%' THEN
NVL(J.ISS_GRP_DESC,'ORDERING')
WHEN 'flag' = '%' THEN
NVL(J.ISS_GRP_DESC,'BILLING/ORDERING')
ELSE
NVL(J.ISS_GRP_DESC,' ')
END ISS_GRP_DESC,
DECODE(NVL(H.USERID,' ') ,' ','--','<a sbcuid_in=' || H.USERID || ' target=NEW >'||H.FIRSTNAME || ' ' || H.LASTNAME || '( ' || H.USERID || ' )</a>' ) USER_NAME
FROM
PROFILE_PORTAL B ,
TBL_BDA_AGENCY_RESP_REP C ,
TBL_BDA_AGENCY_OFFICE F,
TBL_BDA_OFFICE G,
USERS_PORTAL H,
TBL_BDA_USR_ISS_GRP I ,
TBL_BDA_ISS_GROUP J,
ATTRIBUTE_VALUES_PORTAL K,
PROFILE_TYPE_PORTAL L
WHERE
B.PROFILE_ID = F.AGENCY_ID (+)
AND B.PROFILE_ID = C.AGENCY_ID (+)
AND G.OFFICE_ID (+)= F.OFFICE_ID
AND H.USERID (+)= C.RESP_USR_ID
AND C.ISS_GRP_ID = I.ISS_GRP_ID (+)
AND I.ISS_GRP_ID = J.ISS_GRP_ID(+)
AND 'PROFILE.'||B.PROFILE_ID = K.ENTITY_ID(+)
AND K.ATTRIBUTE_VALUE IS NOT NULL
AND L.PROFILE_TYPE_ID = B.PROFILE_TYPE_ID
AND L.APPLICATION_CD='BDA'
AND NOT EXISTS (SELECT agency_id
FROM TBL_BDA_AGENCY_RESP_REP t
WHERE t.ISS_GRP_ID IN ('%')
AND t.AGENCY_ID = C.AGENCY_ID)
AND K.ATTRIBUTE_VALUE LIKE '%'
AND UPPER(B.PROFILE_NM) LIKE UPPER('%')
AND (to_char(NVL(B.PROFILE_ID,0)) LIKE '%' OR NVL(B.PROFILE_ID,0) IN ('a'))
AND NVL(G.OFFICE_ID,0) IN ('%')
AND (to_char(NVL(C.RESP_USR_ID,'0')) LIKE '%' OR NVL(C.RESP_USR_ID,'0') IN ('k'))
ORDER BY PROFILE_NM
The number of rows in these tables are as follows:
PROFILE_PORTAL -- 2392
TBL_BDA_AGENCY_RESP_REP 3508
TBL_BDA_AGENCY_OFFICE 2151
TBL_BDA_OFFICE 3
USERS_PORTAL 270500
TBL_BDA_USR_ISS_GRP 234
TBL_BDA_ISS_GROUP 2
ATTRIBUTE_VALUES_PORTAL 2790
PROFILE_TYPE_PORTAL 3
The Explain pal nhas given this o/p to me:
SQL> select * from table(dbms_xplan.display) dual;
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
| 0 | SELECT STATEMENT | | 807 | 102K| | 2533 |
| 1 | SORT UNIQUE | | 807 | 102K| 232K| 82 |
|* 2 | FILTER | | | | | |
|* 3 | HASH JOIN OUTER | | 807 | 102K| | 52 |
|* 4 | HASH JOIN OUTER | | 807 | 95226 | | 40 |
|* 5 | TABLE ACCESS BY INDEX ROWID | ATTRIBUTE_VALUES | 1 | 23 | | 2 |
| 6 | NESTED LOOPS | | 7 | 805 | | 37 |
| 7 | NESTED LOOPS OUTER | | 6 | 552 | | 25 |
|* 8 | FILTER | | | | | |
| 9 | NESTED LOOPS OUTER | | | | | |
|* 10 | FILTER | | | | | |
| 11 | NESTED LOOPS OUTER | | | | | |
| 12 | NESTED LOOPS OUTER | | 3 | 141 | | 10 |
|* 13 | HASH JOIN | | 3 | 120 | | 7 |
|* 14 | TABLE ACCESS FULL | PROFILE | 6 | 198 | | 4 |
|* 15 | TABLE ACCESS FULL | PROFILE_TYPE | 1 | 7 | | 2 |
|* 16 | INDEX RANGE SCAN | SYS_C0019777 | 1 | 7 | | 1 |
| 17 | TABLE ACCESS BY INDEX ROWID| TBL_BDA_OFFICE | 1 | 10 | | 1 |
|* 18 | INDEX UNIQUE SCAN | SYS_C0019800 | 1 | | | |
| 19 | TABLE ACCESS BY INDEX ROWID | TBL_BDA_AGENCY_RESP_REP | 2 | 26 | | 2 |
|* 20 | INDEX RANGE SCAN | IDX_AGECYRESP_AGNCYID | 2 | | | 1 |
| 21 | TABLE ACCESS BY INDEX ROWID | USER_ | 1 | 22 | | 1 |
|* 22 | INDEX UNIQUE SCAN | USER_PK | 1 | | | |
|* 23 | INDEX RANGE SCAN | IDX_ATTVAL_ENTATTID | 1 | | | 1 |
| 24 | TABLE ACCESS FULL | TBL_BDA_USR_ISS_GRP | 234 | 702 | | 2 |
| 25 | TABLE ACCESS FULL | TBL_BDA_ISS_GROUP | 2 | 24 | | 2 |
|* 26 | TABLE ACCESS BY INDEX ROWID | TBL_BDA_AGENCY_RESP_REP | 1 | 7 | | 3 |
|* 27 | INDEX RANGE SCAN | IDX_AGECYRESP_AGNCYID | 2 | | | 1 |
Predicate Information (identified by operation id):
2 - filter( NOT EXISTS (SELECT /*+ */ 0 FROM "TBL_BDA_AGENCY_RESP_REP" "T" WHERE "T"."AGENCY_ID"=:B1
AND "T"."ISS_GRP_ID"=TO_NUMBER('%')))
3 - access("I"."ISS_GRP_ID"="J"."ISS_GRP_ID"(+))
4 - access("SYS_ALIAS_1"."ISS_GRP_ID"="I"."ISS_GRP_ID"(+))
5 - filter("K"."ATTRIBUTE_VALUE" IS NOT NULL AND "K"."ATTRIBUTE_VALUE" LIKE '%')
8 - filter(NVL("SYS_ALIAS_1"."RESP_USR_ID",'0') LIKE '%' OR NVL("SYS_ALIAS_1"."RESP_USR_ID",'0')='k')
10 - filter(NVL("G"."OFFICE_ID",0)=TO_NUMBER('%'))
13 - access("L"."PROFILE_TYPE_ID"="B"."PROFILE_TYPE_ID")
14 - filter(UPPER("B"."PROFILE_NM") LIKE '%' AND (TO_CHAR(NVL("B"."PROFILE_ID",0)) LIKE '%' OR
NVL("B"."PROFILE_ID",0)=TO_NUMBER('a')))
15 - filter("L"."APPLICATION_CD"='BDA')
16 - access("B"."PROFILE_ID"="F"."AGENCY_ID"(+))
18 - access("G"."OFFICE_ID"(+)="F"."OFFICE_ID")
20 - access("B"."PROFILE_ID"="SYS_ALIAS_1"."AGENCY_ID"(+))
22 - access("H"."USERID"(+)="SYS_ALIAS_1"."RESP_USR_ID")
23 - access("K"."ENTITY_ID"='PROFILE.'||TO_CHAR("B"."PROFILE_ID"))
26 - filter("T"."ISS_GRP_ID"=TO_NUMBER('%'))
27 - access("T"."AGENCY_ID"=:B1)
Note: cpu costing is off
57 rows selected.
Elapsed: 00:00:01.08
Please help me.
Aashish S.

Hello Eric,
Here is the code:
SELECT DISTINCT
K.ATTRIBUTE_VALUE AGENCY_ID,
B.PROFILE_NM ,
NVL(G.OFFICE_DESC,'--') OFFICE_DESC,
f.OFFICE_ID,
B.PROFILE_ID,
'%' ROLE,
'%' LAYOUT,
case
WHEN 'flagB' = '%' THEN
NVL(J.ISS_GRP_DESC,'BILLING')
WHEN 'flagO' = '%' THEN
NVL(J.ISS_GRP_DESC,'ORDERING')
WHEN 'flag' = '%' THEN
NVL(J.ISS_GRP_DESC,'BILLING/ORDERING')
else
NVL(J.ISS_GRP_DESC,' ')
END ISS_GRP_DESC,
DECODE(NVL(H.USERID,' ') ,' ','--','&lt;a sbcuid_in=' || H.USERID || ' target=NEW &gt;'||H.FIRSTNAME || ' ' || H.LASTNAME ||
'( ' || H.USERID || ' )&lt;/a&gt;' ) USER_NAME
from
PROFILE_PORTAL B ,
TBL_BDA_AGENCY_RESP_REP C ,
TBL_BDA_AGENCY_OFFICE F,
TBL_BDA_OFFICE G,
USERS_PORTAL H,
TBL_BDA_USR_ISS_GRP I ,
TBL_BDA_ISS_GROUP J,
ATTRIBUTE_VALUES_PORTAL K,
PROFILE_TYPE_PORTAL L
WHERE
B.PROFILE_ID = F.AGENCY_ID (+)
AND B.PROFILE_ID = C.AGENCY_ID (+)
AND G.OFFICE_ID (+)= F.OFFICE_ID
AND H.USERID (+)= C.RESP_USR_ID
AND C.ISS_GRP_ID = I.ISS_GRP_ID (+)
AND I.ISS_GRP_ID = J.ISS_GRP_ID(+)
AND 'PROFILE.'||B.PROFILE_ID = K.ENTITY_ID(+)
AND K.ATTRIBUTE_VALUE IS NOT NULL
AND L.PROFILE_TYPE_ID = B.PROFILE_TYPE_ID
AND L.APPLICATION_CD='BDA'
AND NOT EXISTS
(SELECT agency_id
FROM TBL_BDA_AGENCY_RESP_REP t
WHERE t.ISS_GRP_ID IN (1)
AND t.AGENCY_ID = C.AGENCY_ID)
AND K.ATTRIBUTE_VALUE LIKE '%'
AND UPPER(B.PROFILE_NM) LIKE UPPER('%')
AND (to_char(NVL(B.PROFILE_ID,0))
LIKE '%'
OR NVL(B.PROFILE_ID,0) IN (1))
AND NVL(G.OFFICE_ID,0) IN (1)
AND (to_char(NVL(C.RESP_USR_ID,'0'))
LIKE '%'
OR NVL(C.RESP_USR_ID,'0') IN ('%'))
ORDER BY PROFILE_NM
This is the Query and the query takes some mins. to run in prod environment.
From the Query plan ,I am not able to get any idea for optimization.
Now,Can you tell me which steps I need to follow to run it faster and which all modifications should be made?
Thanks.
Aashish S.

Similar Messages

  • Help needed to optimize the query

    Help needed to optimize the query:
    The requirement is to select the record with max eff_date from HIST_TBL and that max eff_date should be > = '01-Jan-2007'.
    This is having high cost and taking around 15mins to execute.
    Can anyone help to fine-tune this??
       SELECT c.H_SEC,
                    c.S_PAID,
                    c.H_PAID,
                    table_c.EFF_DATE
       FROM    MTCH_TBL c
                    LEFT OUTER JOIN
                       (SELECT b.SEC_ALIAS,
                               b.EFF_DATE,
                               b.INSTANCE
                          FROM HIST_TBL b
                         WHERE b.EFF_DATE =
                                  (SELECT MAX (b2.EFF_DATE)
                                     FROM HIST_TBL b2
                                    WHERE b.SEC_ALIAS = b2.SEC_ALIAS
                                          AND b.INSTANCE =
                                                 b2.INSTANCE
                                          AND b2.EFF_DATE >= '01-Jan-2007')
                               OR b.EFF_DATE IS NULL) table_c
                    ON  table_c.SEC_ALIAS=c.H_SEC
                       AND table_c.INSTANCE = 100;

    To start with, I would avoid scanning HIST_TBL twice.
    Try this
    select c.h_sec
         , c.s_paid
         , c.h_paid
         , table_c.eff_date
      from mtch_tbl c
      left
      join (
              select sec_alias
                   , eff_date
                   , instance
                from (
                        select sec_alias
                             , eff_date
                             , instance
                             , max(eff_date) over(partition by sec_alias, instance) max_eff_date
                          from hist_tbl b
                         where eff_date >= to_date('01-jan-2007', 'dd-mon-yyyy')
                            or eff_date is null
               where eff_date = max_eff_date
                  or eff_date is null
           ) table_c
        on table_c.sec_alias = c.h_sec
       and table_c.instance  = 100;

  • Needs to tune the query

    Hi ,
    I have a Query that needs to be tuned.
    The query joins two views with some filter condition.
    While running the individual view query with the filter condition i can able to get the results quickly within a seconds.
    But while joining the views conditions of the same criteria which i have used for the individual query takes more than 30 minute.
    i am struggling to tuning this query which was written using the views.
    Note :
    My problem is while checking the explain plan unique sort is taking more cost.
    is that i can reduce the time by giving some optimizer hints to reduce the unique sort cost for query using views?
    Thanks & regards,
    Senthur pandi M

    Hi,
    BluShadow wrote:
    957595 wrote:
    Hi ,
    I have a Query that needs to be tuned.
    The query joins two views with some filter condition.
    While running the individual view query with the filter condition i can able to get the results quickly within a seconds.
    But while joining the views conditions of the same criteria which i have used for the individual query takes more than 30 minute.
    i am struggling to tuning this query which was written using the views.
    Note :
    My problem is while checking the explain plan unique sort is taking more cost.Cost in not necessarily a good comparison to use. The cost is a figure determined on a per-query basis,The problem with cost is that it's a prediction made by the optimizer, rather than the actual measure of query performance. Optimizer often makes mistakes about expected query performance. Ironically, people normally look at query cost when it needs tuning, i.e. when the chance that optimizer made a mistake is especially high.
    In many internet forums one can see claims that cost estimates are meaningless across different queries. Such claims are unfounded. When calculated correctly, cost is quite meaningful, and in such cases there is nothing wrong about comparing cost not only for different queries, but also for different databases (if they have same optimizer settings and system stats).
    is that i can reduce the time by giving some optimizer hints to reduce the unique sort cost for query using views?Hints are not the way to improve performance. That's an overstatement. The sad truth is that in many cases there is no viable alternative to using hints. Rather than always avoid hints no matter what cost, it's better to understand how hints affect optimizer behavior, and when it's safe to use them.
    They are great for identifying where the cause of a performance issue is, but shouldn't be used in production code, as it would be like saying that you know better than Oracle how to retrieve the data, not just now, but in the future as more
    data is added and as data is deleted and replaced with new data etc. By adding hints you are effectively forcing the optimizer to execute the query in a particular way, which may be fast now, but in the future may be worse than what the optimizer can determine itself.Hints that force the optimizer to use a specific access path or a specific join method are dangerous -- because the only lock-in one part of the plan, but not the entire plan (e.g. INDEX hint only ensures that an index is used if possible, but it cannot ensure INDEX UNIQUE/RANGE SCAN, so you may end up in a situation when the optimizer is doing an expensive and meaningless INDEX FULL SCAN because of the hint that was indended to force a different, more selective, access method).
    Hints that don't do that, but rather prevent the optimizer from trying to be smart when it's better to keep things simple, are relatively safe.
    So, use the hints to identify where there are issues in the SQL or in the database design, and fix those issues, rather than leave hints in production code.As a general rule, sure. Here, however, the problem seems to be obvious -- if views are fast separately, and slow when joined, that suggests that the optimizer doesn't merge them correctly.
    Best regards,
    Nikolay

  • Help needed in generating the query

    Hi All,
    While fetching the required columns from the table, i also have to display the seq no starting with some no. ( which will vary based on the functionality, so it ll be a sep variable.) and will get incremented with a offset value.
    Current code:
    select col1, col2, col3 from table1 where col1 = valid_condition; Expected code / Or approach:
    select start_val+offset_val , col1, col2, col3 from table1 where col1 = valid_condition; This select query is part of a view and the values for start_val, offset_val will be set as global params.
    Is there any easier way of implementing this in the query, other than creating a seq no.
    thanks in advance.

    Hi,
    This sounds like a job for ROWNUM or ROW_NUMBER.
    The ROWNUM pseudo-column is easy to use, but the numbers aren't necessarily assigned in the order you'd like:
    SELECT       ename
    ,       1000 + ROWNUM          AS seq_no
    FROM       scott.emp
    WHERE       deptno     = 30
    ORDER BY  ename
    ;Output:
    ENAME          SEQ_NO
    ALLEN            1001
    BLAKE            1004
    JAMES            1006
    MARTIN           1003
    TURNER           1005
    WARD             1002To assign the numbers in order, you could select ROWNUM from an ordered sub-query (or view), but if you're going to that much trouble, you might as well use the analytic ROW_NUMBER function:
    SELECT       ename
    ,       1000 + ROW_NUMBER () OVER (ORDER BY ename)          AS seq_no
    FROM       scott.emp
    WHERE       deptno     = 30
    ORDER BY  ename
    ;Output:
    ENAME          SEQ_NO
    ALLEN            1001
    BLAKE            1002
    JAMES            1003
    MARTIN           1004
    TURNER           1005
    WARD             1006Edited by: Frank Kulash on Nov 25, 2009 1:32 PM

  • Help required regarding tunning the query mentioned

    HI all ,
    Query mentioned below takes around 1 hr to complete . It's being used by the autoconfig kindly me in tunning it ..
    QUery :
    UPDATE WF_ITEM_ATTRIBUTE_VALUES WIAV SET WIAV.TEXT_VALUE = REPLACE(WIAV.TEXT_VALUE,:B1,:B2)
    WHERE (WIAV.ITEM_TYPE, WIAV.NAME) = (SELECT WIA.ITEM_TYPE, WIA.NAME
    FROM WF_ITEM_ATTRIBUTES WIA WHERE WIA.TYPE = 'URL'
    AND WIA.ITEM_TYPE = WIAV.ITEM_TYPE
    AND WIA.NAME = WIAV.NAME)
    AND WIAV.TEXT_VALUE IS NOT NULL
    AND INSTR(WIAV.TEXT_VALUE
    , :B1) > 0
    Plan :*
    <pre>
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | UPDATE STATEMENT | | 453 | 14496 | 284K|
    | 1 | UPDATE | WF_ITEM_ATTRIBUTE_VALUES | | | |
    |* 2 | FILTER | | | | |
    |* 3 | TABLE ACCESS FULL | WF_ITEM_ATTRIBUTE_VALUES | 453 | 14496 | 282K|
    |* 4 | TABLE ACCESS BY INDEX ROWID| WF_ITEM_ATTRIBUTES | 1 | 33 | 2 |
    |* 5 | INDEX UNIQUE SCAN | WF_ITEM_ATTRIBUTES_PK | 1 | | 1 |
    Predicate Information (identified by operation id):
    2 - filter(("SYS_ALIAS_2"."ITEM_TYPE","SYS_ALIAS_2"."NAME")= (SELECT /*+ */
    "WIA"."ITEM_TYPE","WIA"."NAME" FROM "APPLSYS"."WF_ITEM_ATTRIBUTES" "WIA" WHERE
    "WIA"."NAME"=:B1 AND "WIA"."ITEM_TYPE"=:B2 AND "WIA"."TYPE"='URL'))
    3 - filter("SYS_ALIAS_2"."TEXT_VALUE" IS NOT NULL AND
    INSTR("SYS_ALIAS_2"."TEXT_VALUE",:Z)>0)
    4 - filter("WIA"."TYPE"='URL')
    5 - access("WIA"."ITEM_TYPE"=:B1 AND "WIA"."NAME"=:B2)
    </pre>
    Index :*
    <pre>
    INDEX_NAME COLUMN_NAME
    APPLSYS WF_ITEM_ATTRIBUTE_VALUES_PK 1 ITEM_TYPE
    2 ITEM_KEY
    3 NAME
    </pre>
    regds
    Rahul
    Edited by: RahulG on Jan 2, 2009 10:47 PM
    Edited by: RahulG on Jan 2, 2009 10:48 PM

    RahulG wrote:
    HI all ,
    Query mentioned below takes around 1 hr to complete . It's being used by the autoconfig kindly me in tunning it ..
    A few notes:
    1. Your query is using bind variables. If you're already on 9i or later (probably 9iR2 according to plan output), this statement will be subject to bind variable peeking and therefore the output of EXPLAIN PLAN is only of limited use, since the actual execution plan might be different and/or might be based on different cardinality estimates based on the actual bind values peeked at hard parse time. You can use the V$SQL_PLAN view to get the actual execution plan(s) if the statement is still cached in the shared pool, from 10g on DBMS_XPLAN.DISPLAY_CURSOR is available for that purpose.
    2. The execution plan posted suggests that only 453 rows will correspond to the filter criteria (but, as mentioned in 1. is based on an unknown bind variable value when using EXPLAIN PLAN), and probably therefore the optimizer didn't unnest the subquery but runs this as recursive FILTER query potentially for each row passing the filter criteria on the driving table WF_ITEM_ATTRIBUTE_VALUES. Depending on the actual number of rows this might be inefficient, and unnesting the subquery and turning it into a join might be more appropriate. This might accomplished e.g. by providing more representative statistics to the optimizer (are the statistics up-to-date?).
    Although you can't change the SQL you could try this manually by using the UNNEST hint to see if it makes any difference in the execution plan (and run time):
    WHERE (WIAV.ITEM_TYPE, WIAV.NAME) = (SELECT /*+ UNNEST */ WIA.ITEM_TYPE, WIA.NAME
    ...3. The composite index WF_ITEM_ATTRIBUTE_VALUES_PK can only be used on the first column ITEM_TYPE for effective index access, the NAME column would have to be used as filter on all index leaf blocks that would be found using a range scan on ITEM_TYPE. This might be quite inefficient, and/or might lead to a lot of rows/blocks that need to be visited in the table using this index access path.
    4. You could try to trace the execution by enabling extended SQL trace, e.g. using the (undocumented) DBMS_SUPPORT package in 9i. Running the "tkprof" utility on the generated trace file tells you the actual row source cardinalities (which can then be compared to the estimates of the optimizer) and - if the "waits" have been enabled - what your statement has waited for most.
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • Do I need to tune the base query of my materialized view ?

    Hi gurus,
    We implement materialized view (FAST REFRESH ON COMMIT) on base table used in OLTP system. In fact the MV itself is also queried by the OLTP system itself, interactively.
    Currently user complain that after they input transaction, they see that the MV is not refresh as soon as they commit the transaction.
    (it takes 5 to 10 minutes before they see the update on the MV)
    The query of the MV is attached below, it consists of union all of two queries but actually the real query has 13 queries on a UNION ALL.
    The question is :
    Do I need to tune the query that forms the MV ?
    Does it impact the refresh time of the MV ?
    Thank you for your help,
    xtanto
    SELECT GRNH.DOC_CODE ||' '|| GRNH.GRN_NO, GRNH.GRN_DATE, GRNH.REGS_CODE,
    F_Convert_Qty_K(GRND.PRODUCT, GRND.QTY, GRND.UOM) QTY_IN, 0 QTY_OUT, 0 QTY_ADJ, 'N/A'.....
    FROM GRN_LOCAL_D GRND
              JOIN GRN_LOCAL_H GRNH ON GRNH.GRNH_ID = GRND.GRNH_ID
              WHERE GRND.PRODUCT IS NOT NULL AND GRNH.WH_CODE IS NOT NULL
    UNION ALL
    SELECT GRNH.DOC_CODE ||' '|| GRNH.GRN_NO, GRNH.GRN_DATE, GRNH.REGS_CODE,
    F_Convert_Qty_K(GRND.PRODUCT_B, GRND.QTY_B, GRND.UOM_B) QTY_IN, 0 QTY_OUT, 0 QTY_ADJ, 'N/A'...
    FROM GRN_LOCAL_D GRND
    JOIN GRN_LOCAL_H GRNH ON GRNH.GRNH_ID = GRND.GRNH_ID
    WHERE GRND.PRODUCT_B IS NOT NULL AND GRNH.WH_CODE IS NOT NULL
    UNION ALL
         ......

    Hi Justin & APC,
    Are they seeing a 5-10 minute delay in being able to commit their transaction?NO, the commit itself is completed normally, but after that when they go to the page (this is webbased app) that display data from the MV, the newly committed transactionis not there yet. Only after 5-10 minutes we can see the new data.
    What does the F_Convert_Qty_K() function do?It is a function that convert the quantity from whatever Unit Of Measurement (UOM) into the smallest UOM. Below is the code.
    So the question remains:
    why intermittently theere is delay before the new data visible in the MV ?
    Thanks you,
    xtanto
    CREATE OR REPLACE FUNCTION F_Convert_Qty (pProduct VARCHAR2, pQty NUMBER, pUOM VARCHAR2)
    RETURN NUMBER
    IS
    vQtyBase NUMBER(13,5);
    BEGIN
    SELECT CASE WHEN pUOM = ( SELECT UOM_BASE FROM PRODUCTS WHERE PRODUCT = pProduct)
              THEN pQty
         ELSE
                   SELECT ROUND(pQty * Coefficient / Divisor, 5)
                   FROM (
                             SELECT Coefficient, Divisor FROM CONVERT_UOM
                             WHERE PRODUCT = pProduct AND UOM_CONVERT = pUOM
                             ) tmp
              END INTO vQtyBase FROM DUAL;
    --RETURN (vQtyBase) ;
    RETURN ( NVL(vQtyBase,0) ) ;
    END F_Convert_Qty;
    /

  • Need to tune the sql query

    Hi,
    PLease help me to tune the query
    select primary_rep,
    rep_ssn,
    nvl(product_type_desc, 'UNKNOWN') as productName,
    ROUND(sum(contributions)) as contribution,
    ROUND(sum(withdrawls)) as withdrawls,
    ROUND(sum(netflow)) as netflow
    from dev.NETFLOW_VIEW_TSS_P
    where bd = 'TSS'
    and actvtydate between '01-Jan-2011' and '30-Sep-2011'     
    and rep_ssn IN (select tax_id from broker_view where broker_id = '600468')
    group by primary_rep, rep_ssn, nvl(product_type_desc, 'UNKNOWN');
    explain plan details below
    | Id  | Operation                                     | Name                        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT                              |                             |    79 |   158K|       | 74348   (1)| 00:14:53 |       |       |
    |   1 |  HASH GROUP BY                                |                             |    79 |   158K|       | 74348   (1)| 00:14:53 |       |       |
    |*  2 |   HASH JOIN                                   |                             |    79 |   158K|       | 74347   (1)| 00:14:53 |       |       |
    |   3 |    VIEW                                       | VW_NSO_1                    |     1 |     6 |       |    18  (17)| 00:00:01 |       |       |
    |   4 |     HASH UNIQUE                               |                             |     1 |   100 |       |    18  (17)| 00:00:01 |       |       |
    |   5 |      NESTED LOOPS OUTER                       |                             |     1 |   100 |       |    17  (12)| 00:00:01 |       |       |
    |   6 |       MERGE JOIN CARTESIAN                    |                             |     1 |    92 |       |    17  (12)| 00:00:01 |       |       |
    |   7 |        NESTED LOOPS OUTER                     |                             |     1 |    71 |       |    15  (14)| 00:00:01 |       |       |
    |   8 |         NESTED LOOPS OUTER                    |                             |     1 |    67 |       |    12  (17)| 00:00:01 |       |       |
    |*  9 |          HASH JOIN OUTER                      |                             |     1 |    63 |       |    10  (20)| 00:00:01 |       |       |
    |  10 |           NESTED LOOPS OUTER                  |                             |     1 |    56 |       |     6   (0)| 00:00:01 |       |       |
    |  11 |            NESTED LOOPS OUTER                 |                             |     1 |    52 |       |     4   (0)| 00:00:01 |       |       |
    |  12 |             TABLE ACCESS BY INDEX ROWID       | AFFILIATE                   |     1 |    45 |       |     2   (0)| 00:00:01 |       |       |
    |* 13 |              INDEX UNIQUE SCAN                | AFFILIATE_PK                |     1 |       |       |     1   (0)| 00:00:01 |       |       |
    |* 14 |             TABLE ACCESS FULL                 | PORTAL_BROKER               |     1 |     7 |       |     2   (0)| 00:00:01 |       |       |
    |  15 |            VIEW PUSHED PREDICATE              |                             |     1 |     4 |       |     2   (0)| 00:00:01 |       |       |
    |  16 |             NESTED LOOPS                      |                             |     1 |    28 |       |     2   (0)| 00:00:01 |       |       |
    |  17 |              NESTED LOOPS                     |                             |     1 |    21 |       |     2   (0)| 00:00:01 |       |       |
    |* 18 |               TABLE ACCESS BY INDEX ROWID     | LOCATION_GROUP_TYPE_DESC    |     1 |     5 |       |     1   (0)| 00:00:01 |       |       |
    |* 19 |                INDEX UNIQUE SCAN              | LOCATION_GROUP_TYPE_DESC_PK |     1 |       |       |     0   (0)| 00:00:01 |       |       |
    |* 20 |               INDEX RANGE SCAN                | LOCATION_GROUP_UK           |     1 |    16 |       |     1   (0)| 00:00:01 |       |       |
    |* 21 |              INDEX UNIQUE SCAN                | CONTACT_METHOD_PK           |     1 |     7 |       |     0   (0)| 00:00:01 |       |       |
    |  22 |           VIEW                                |                             |     1 |     7 |       |     3  (34)| 00:00:01 |       |       |
    |  23 |            HASH UNIQUE                        |                             |     1 |    11 |       |     3  (34)| 00:00:01 |       |       |
    |* 24 |             INDEX RANGE SCAN                  | AFFILIATE_TYPE_PK           |     1 |    11 |       |     2   (0)| 00:00:01 |       |       |
    |  25 |          VIEW PUSHED PREDICATE                |                             |     1 |     4 |       |     2   (0)| 00:00:01 |       |       |
    |  26 |           NESTED LOOPS                        |                             |     1 |    28 |       |     2   (0)| 00:00:01 |       |       |
    |  27 |            NESTED LOOPS                       |                             |     1 |    21 |       |     2   (0)| 00:00:01 |       |       |
    |* 28 |             TABLE ACCESS BY INDEX ROWID       | LOCATION_GROUP_TYPE_DESC    |     1 |     5 |       |     1   (0)| 00:00:01 |       |       |
    |* 29 |              INDEX UNIQUE SCAN                | LOCATION_GROUP_TYPE_DESC_PK |     1 |       |       |     0   (0)| 00:00:01 |       |       |
    |* 30 |             INDEX RANGE SCAN                  | LOCATION_GROUP_UK           |     1 |    16 |       |     1   (0)| 00:00:01 |       |       |
    |* 31 |            INDEX UNIQUE SCAN                  | CONTACT_METHOD_PK           |     1 |     7 |       |     0   (0)| 00:00:01 |       |       |
    |  32 |         VIEW PUSHED PREDICATE                 |                             |     1 |     4 |       |     3   (0)| 00:00:01 |       |       |
    |  33 |          NESTED LOOPS OUTER                   |                             |     1 |    35 |       |     3   (0)| 00:00:01 |       |       |
    |  34 |           NESTED LOOPS                        |                             |     1 |    32 |       |     3   (0)| 00:00:01 |       |       |
    |  35 |            NESTED LOOPS                       |                             |     1 |    22 |       |     2   (0)| 00:00:01 |       |       |
    |* 36 |             TABLE ACCESS BY INDEX ROWID       | LOCATION_GROUP_TYPE_DESC    |     1 |     5 |       |     1   (0)| 00:00:01 |       |       |
    |* 37 |              INDEX UNIQUE SCAN                | LOCATION_GROUP_TYPE_DESC_PK |     1 |       |       |     0   (0)| 00:00:01 |       |       |
    |* 38 |             INDEX RANGE SCAN                  | LOCATION_GROUP_UK           |     1 |    17 |       |     1   (0)| 00:00:01 |       |       |
    |  39 |            TABLE ACCESS BY INDEX ROWID        | ADDRESS                     |     1 |    10 |       |     1   (0)| 00:00:01 |       |       |
    |* 40 |             INDEX UNIQUE SCAN                 | ADDRESS_PK                  |     1 |       |       |     0   (0)| 00:00:01 |       |       |
    |* 41 |           INDEX UNIQUE SCAN                   | PROV_STDSC_PK               |     1 |     3 |       |     0   (0)| 00:00:01 |       |       |
    |  42 |        BUFFER SORT                            |                             |     1 |    21 |       |    14  (15)| 00:00:01 |       |       |
    |* 43 |         INDEX RANGE SCAN                      | I_BROKER_BKBRCMB            |     1 |    21 |       |     2   (0)| 00:00:01 |       |       |
    |* 44 |       INDEX UNIQUE SCAN                       | BROKER_BRANCH_PK            |     1 |     8 |       |     0   (0)| 00:00:01 |       |       |
    |  45 |    VIEW                                       | NETFLOW_VIEW_TSS_P          |   391K|   766M|       | 74325   (1)| 00:14:52 |       |       |
    |  46 |     UNION-ALL                                 |                             |       |       |       |            |          |       |       |
    |* 47 |      HASH JOIN RIGHT OUTER                    |                             | 11645 |  1671K|       | 49023   (1)| 00:09:49 |       |       |
    |  48 |       VIEW                                    |                             |     1 |    38 |       | 13602   (1)| 00:02:44 |       |       |
    |* 49 |        FILTER                                 |                             |       |       |       |            |          |       |       |
    |  50 |         TABLE ACCESS FULL                     | SALES_REPORT_REP_MAPPING    |  9023 |   326K|       |    58   (2)| 00:00:01 |       |       |
    |* 51 |         FILTER                                |                             |       |       |       |            |          |       |       |
    |  52 |          SORT GROUP BY NOSORT                 |                             |     1 |    11 |       |     3   (0)| 00:00:01 |       |       |
    |  53 |           TABLE ACCESS BY INDEX ROWID         | SALES_REPORT_REP_MAPPING    |     1 |    11 |       |     3   (0)| 00:00:01 |       |       |
    |* 54 |            INDEX RANGE SCAN                   | I_SAL_REP_MAP_REPID         |     1 |       |       |     2   (0)| 00:00:01 |       |       |
    |  55 |       NESTED LOOPS                            |                             | 11645 |  1239K|       | 35420   (1)| 00:07:06 |       |       |
    |* 56 |        HASH JOIN RIGHT OUTER                  |                             | 11645 |   898K|       | 12112   (1)| 00:02:26 |       |       |
    |  57 |         INDEX FAST FULL SCAN                  | I_VENDORS_ACCTLOC           |   986 |  3944 |       |     2   (0)| 00:00:01 |       |       |
    |* 58 |         HASH JOIN RIGHT OUTER                 |                             | 11645 |   852K|       | 12109   (1)| 00:02:26 |       |       |
    |* 59 |          MAT_VIEW ACCESS FULL                 | SECS_DESC                   | 26777 |   418K|       |  3082   (1)| 00:00:37 |       |       |
    |* 60 |          FILTER                               |                             |       |       |       |            |          |       |       |
    |* 61 |           HASH JOIN RIGHT OUTER               |                             | 11645 |   670K|       |  9026   (1)| 00:01:49 |       |       |
    |  62 |            MAT_VIEW ACCESS FULL               | ENTRYCODES                  |  1640 | 11480 |       |     8   (0)| 00:00:01 |       |       |
    |* 63 |            HASH JOIN                          |                             | 34936 |  1774K|       |  9017   (1)| 00:01:49 |       |       |
    |* 64 |             INDEX FULL SCAN                   | I_CODE                      |    30 |   420 |       |     1   (0)| 00:00:01 |       |       |
    |  65 |             PARTITION RANGE ALL               |                             |   342K|    12M|       |  9013   (1)| 00:01:49 |     1 |    20 |
    |  66 |              TABLE ACCESS BY LOCAL INDEX ROWID| BKPG                        |   342K|    12M|       |  9013   (1)| 00:01:49 |     1 |    20 |
    |* 67 |               INDEX RANGE SCAN                | I_BKPG_ACT_REC_IDX          |   342K|       |       |  1412   (1)| 00:00:17 |     1 |    20 |
    |  68 |        TABLE ACCESS BY INDEX ROWID            | ACCT_CUBE                   |     1 |    30 |       |     2   (0)| 00:00:01 |       |       |
    |* 69 |         INDEX UNIQUE SCAN                     | ACCT_CUBE_PK                |     1 |       |       |     1   (0)| 00:00:01 |       |       |
    |* 70 |      HASH JOIN RIGHT OUTER                    |                             |   379K|    52M|       | 25303   (1)| 00:05:04 |       |       |
    |  71 |       VIEW                                    |                             |     1 |    38 |       | 13602   (1)| 00:02:44 |       |       |
    |* 72 |        FILTER                                 |                             |       |       |       |            |          |       |       |
    |  73 |         TABLE ACCESS FULL                     | SALES_REPORT_REP_MAPPING    |  9023 |   326K|       |    58   (2)| 00:00:01 |       |       |
    |* 74 |         FILTER                                |                             |       |       |       |            |          |       |       |
    |  75 |          SORT GROUP BY NOSORT                 |                             |     1 |    11 |       |     3   (0)| 00:00:01 |       |       |
    |  76 |           TABLE ACCESS BY INDEX ROWID         | SALES_REPORT_REP_MAPPING    |     1 |    11 |       |     3   (0)| 00:00:01 |       |       |
    |* 77 |            INDEX RANGE SCAN                   | I_SAL_REP_MAP_REPID         |     1 |       |       |     2   (0)| 00:00:01 |       |       |
    |* 78 |       HASH JOIN                               |                             |   379K|    39M|    33M| 11696   (2)| 00:02:21 |       |       |
    |* 79 |        HASH JOIN                              |                             |   379K|    28M|       |  3210   (2)| 00:00:39 |       |       |
    |* 80 |         INDEX FAST FULL SCAN                  | I_VENDORS_ACCTLOC           |   986 |  3944 |       |     2   (0)| 00:00:01 |       |       |
    |* 81 |         HASH JOIN                             |                             |   379K|    27M|    14M|  3204   (2)| 00:00:39 |       |       |
    |  82 |          INDEX FAST FULL SCAN                 | SECS_DESC_PK                |   744K|  6545K|       |   457   (3)| 00:00:06 |       |       |
    |* 83 |          FILTER                               |                             |       |       |       |            |          |       |       |
    |* 84 |           HASH JOIN RIGHT OUTER               |                             |   379K|    24M|       |   569   (3)| 00:00:07 |       |       |
    |  85 |            MAT_VIEW ACCESS FULL               | MFENTRYCODES                |  6853 | 61677 |       |    15   (0)| 00:00:01 |       |       |
    |  86 |            PARTITION RANGE ALL                |                             |  1138K|    62M|       |   542   (1)| 00:00:07 |     1 |    15 |
    |* 87 |             TABLE ACCESS BY LOCAL INDEX ROWID | MFBKPG                      |  1138K|    62M|       |   542   (1)| 00:00:07 |     1 |    15 |
    |* 88 |              INDEX RANGE SCAN                 | I_MFBKPGP_ACTDT_ACCT_TST    |   904 |       |       |   107   (0)| 00:00:02 |     1 |    15 |
    |  89 |        INDEX FAST FULL SCAN                   | I_ACCT_CUBE_REPID_MKT       |  1952K|    52M|       |  3096   (2)| 00:00:38 |       |       |
    Predicate Information (identified by operation id):
       2 - access("REP_SSN"="$nso_col_1")
       9 - access("A"."AFFILIATE_ID"="MGR"."AFFILIATE_ID"(+))
      13 - access("A"."AFFILIATE_ID"='600468')
      14 - filter("PORTAL_BROKER"."BROKER_ID"(+)='600468')
      18 - filter("LT"."ADDRESS_CONTACT_IND"='C')
      19 - access("LT"."LOCATION_GROUP_TYPE_CODE"='WF')
      20 - access("L"."LOCATION_GROUP_TYPE_CODE"='WF' AND "L"."AFFILIATE_ID"="A"."AFFILIATE_ID")
           filter("L"."CONTACT_METHOD_ID" IS NOT NULL)
      21 - access("L"."CONTACT_METHOD_ID"="B"."CONTACT_METHOD_ID")
      24 - access("AFFILIATE_ID"='600468')
           filter("AFFILIATE_TYPE"='BBE' OR "AFFILIATE_TYPE"='BRM' OR "AFFILIATE_TYPE"='ISP')
      28 - filter("LT"."ADDRESS_CONTACT_IND"='C')
      29 - access("LT"."LOCATION_GROUP_TYPE_CODE"='WT')
      30 - access("L"."LOCATION_GROUP_TYPE_CODE"='WT' AND "L"."AFFILIATE_ID"="A"."AFFILIATE_ID")
           filter("L"."CONTACT_METHOD_ID" IS NOT NULL)
      31 - access("L"."CONTACT_METHOD_ID"="B"."CONTACT_METHOD_ID")
      36 - filter("LT"."ADDRESS_CONTACT_IND"='A')
      37 - access("LT"."LOCATION_GROUP_TYPE_CODE"='WM')
      38 - access("L"."LOCATION_GROUP_TYPE_CODE"='WM' AND "L"."AFFILIATE_ID"="A"."AFFILIATE_ID")
           filter("L"."ADDRESS_ID" IS NOT NULL)
      40 - access("L"."ADDRESS_ID"="A"."ADDRESS_ID")
      41 - access("A"."PROVINCE_STATE_CODE"="S"."PROVINCE_STATE_CODE"(+))
      43 - access("B"."BROKER_ID"='600468')
      44 - access("B"."BRANCH_ID"="BR"."BRANCH_ID"(+))
      47 - access("B"."REPID"="K"."REPID"(+))
      49 - filter( EXISTS (SELECT 0 FROM DEV."SALES_REPORT_REP_MAPPING" "SALES_REPORT_REP_MAPPING" WHERE "REPID"=:B1 GROUP BY "REPID" HAVING
                  SUM(NVL("PCT",100))=100))
      51 - filter(SUM(NVL("PCT",100))=100)
      54 - access("REPID"=:B1)
      56 - access(NVL("V"."VENDOR_CD"(+),'xxx')=NVL("VENDOR_CD",'yyy'))
      58 - access("CUSIP"(+)="A"."CUSIP")
      59 - filter("COMM_SECTYPE"(+)='MF')
      60 - filter(NVL("Z"."PERF_INCLUDE_PORTFOLIO",'xx')='Y')
      61 - access("A"."ENTRYCODE"="Z"."ENTRYCODE"(+))
      63 - access("CODE_IN"=SUBSTR("A"."ACCT",1,3))
      64 - access("CODE_TYPE"='NETFLOW')
           filter("CODE_TYPE"='NETFLOW')
      67 - access("A"."ACTVTYDATE">=TO_DATE(' 2011-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "A"."ACTVTYDATE"<=TO_DATE(' 2011-09-30
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
      69 - access("B"."ACCOUNTKEY"='11,,,'||"A"."ACCT")
      70 - access("A"."REPID"="K"."REPID"(+))
      72 - filter( EXISTS (SELECT 0 FROM DEV."SALES_REPORT_REP_MAPPING" "SALES_REPORT_REP_MAPPING" WHERE "REPID"=:B1 GROUP BY "REPID" HAVING
                  SUM(NVL("PCT",100))=100))
      74 - filter(SUM(NVL("PCT",100))=100)
      77 - access("REPID"=:B1)
      78 - access("A"."ACCOUNTKEY"='20,'||"B"."VENDOR_CD"||','||"B"."FUNDNO"||','||"B"."ACCT")
      79 - access("V"."VENDOR_CD"="B"."VENDOR_CD")
      80 - filter("V"."VENDOR_CD"<>'HNR' AND "V"."VENDOR_CD"<>'CNL' AND "V"."VENDOR_CD"<>'IRE' AND "V"."VENDOR_CD"<>'WLR' AND
                  "V"."VENDOR_CD"<>'WLP' AND "V"."VENDOR_CD"<>'PER' AND "V"."VENDOR_CD"<>'BHV')
      81 - access("SD"."CUSIP"="B"."CUSIP")
      83 - filter(NVL("E"."PERF_INCLUDE_PORTFOLIO",'xx')='Y')
      84 - access("B"."ENTRYCODE"="E"."ENTRYCODE"(+))
      87 - filter("B"."VENDOR_CD"<>'HNR' AND "B"."VENDOR_CD"<>'CNL' AND "B"."VENDOR_CD"<>'IRE' AND "B"."VENDOR_CD"<>'WLR' AND
                  "B"."VENDOR_CD"<>'WLP' AND "B"."VENDOR_CD"<>'PER' AND "B"."VENDOR_CD"<>'BHV')
      88 - access(SYS_OP_DESCEND("ACTVTYDATE")>=HEXTORAW('8790F6E1FEF8FEFAFF')  AND SYS_OP_DESCEND("ACTVTYDATE")<=HEXTORAW('8790FEF8FEF8FEFAFF')
           filter(SYS_OP_UNDESCEND(SYS_OP_DESCEND("ACTVTYDATE"))>=TO_DATE(' 2011-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  SYS_OP_UNDESCEND(SYS_OP_DESCEND("ACTVTYDATE"))<=TO_DATE(' 2011-09-30 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
    158 rows selected.Thanks

    So this is a VIEW with I think 18 tables (I may have missed one or two), some of which are referenced more than one. Some of these tables have tens of miilions of rows. What exactly are you expecting from us?
    I guess this is a data warehouse or BI query. Sometimes such queries just take an age to run and there's nothing which can be done except result caching. Other times the queries can be tuned, but iit requires way more context and domain knowledge than you have provided.
    Please start by reading [url https://forums.oracle.com/forums/thread.jspa?threadID=2174552#9360003]this FAQ. .
    Cheers, APC

  • Guide me to tune the query

    Hi All,
    I need to tune the query which is taking more than 1 hour to execute over 8 Lakhs of record.
    SQL> explain plan for SELECT C.aci_cust_code      cust_code,
    2 C.aci_cust_name cust_name,
    3      R.NAME ruledefination,
    4 B.RULECODE ALERTS,
    5 A.custom1 tran_id,
    6 TD_get_value('AMLTRANTYPE', RTRIM(A.custom17)) trantype,
    7 A.CUSTOM18 tran_nature,
    8 A.custom25 tran_date,
    9 A.messageno messageno,
    10 TD_get_value('AMLTRANSTATUS', A.status) msgstatus,
    11 D.acai_acct_type acct_type,
    12 A.custom19 acct_number,
    13 A.CURRENCY CURRENCY,
    14 A.priorityamount amount,
    15 A.operator USERNAME,
    16 A.msgdb_id msgdb_id,
    17 A.msg_mode_in msg_mode_in
    18 FROM MSGDB A,
    19 MSGALERTS B,
    20 AML_CUST_INFO C,
    21      AML_CUST_ACC_INFO D,
    22 RULETBL2 R,
    23           (SELECT tdkey FROM tabledetails WHERE tdidcode = 'AML-INCLUDEQ' ) amlqueues
    24 WHERE A.msgdb_id = B.msgdb_id AND
    25 A.queueid = amlqueues.tdkey AND
    26           A.MSG_MODE_IN = 'AML-TRANS' AND
    27 A.custom15 = C.aci_cust_code AND
    28 A.CUSTOM19=D.ACAI_ACCT_NUMBER(+) AND
    29 TO_CHAR(A.custom25,'YYYYMMDD') BETWEEN
    30      TO_CHAR(TO_DATE('2011/01/01','YYYY/MM/DD'),'YYYYMMDD')
    31 AND TO_CHAR(TO_DATE('2011/01/31','YYYY/MM/DD'),'YYYYMMDD')
    32 AND B.RULECODE = R.RULECODE
    33 ORDER BY A.custom25, msgdb_id,B.rulecode;
    Explained.
    PLAN_TABLE_OUTPUT
    Plan hash value: 1081661146
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 173K| 30M| | 12697 (2)| 00:02:33 |
    | 1 | SORT ORDER BY | | 173K| 30M| 66M| 12697 (2)| 00:02:33 |
    |* 2 | HASH JOIN | | 173K| 30M| | 5580 (4)| 00:01:07 |
    | 3 | VIEW | index$_join$_005 | 3395 | 81480 | | 42 (3)| 00:00:01 |
    |* 4 | HASH JOIN | | | | | | |
    | 5 | INDEX FAST FULL SCAN | IDX_RCODE | 3395 | 81480 | | 10 (0)| 00:00:01 |
    | 6 | INDEX FAST FULL SCAN | SYS_C0040836 | 3395 | 81480 | | 31 (0)| 00:00:01 |
    |* 7 | HASH JOIN | | 1737 | 276K| | 5534 (4)| 00:01:07 |
    |* 8 | HASH JOIN | | 559 | 86645 | | 4575 (3)| 00:00:55 |
    |* 9 | HASH JOIN OUTER | | 448 | 56000 | | 4463 (3)| 00:00:54 |
    | 10 | NESTED LOOPS | | 448 | 47040 | | 4404 (3)| 00:00:53 |
    |* 11 | TABLE ACCESS BY INDEX ROWID| MSGDB | 451 | 35178 | | 4403 (3)| 00:00:53 |
    |* 12 | INDEX RANGE SCAN | I_MODEDATE | 2292 | | | 4323 (3)| 00:00:52 |
    |* 13 | INDEX UNIQUE SCAN | PK_TABLEDETAIL | 1 | 27 | | 0 (0)| 00:00:01 |
    | 14 | INDEX FAST FULL SCAN | ACC_NUMBER_TYPE | 58947 | 1151K| | 58 (4)| 00:00:01 |
    | 15 | TABLE ACCESS FULL | AML_CUST_INFO | 18340 | 537K| | 111 (1)| 00:00:02 |
    | 16 | TABLE ACCESS FULL | MSGALERTS | 868K| 6782K| | 944 (4)| 00:00:12 |
    There is no index on RULECODE of MSGALERTS and RULETBL2 table.
    Could yu guys guide me how to tune this query with or without creating any new index.
    Thanks,

    To emphasise what hoek has said regarding dates, NEVER compare dates with dates by converting them to strings (or numbers). By doing so, you remove vital information from the optimizer.
    For example, what is the difference between "31st Dec 2010" and "1st Jan 2011"? Easy, they're dates, that's 1 day.
    But what's the difference between "20101231" and "20110101"? Easy: 20110101 - 20101231 = 8870.
    That makes the difference between the optimizer guessing 1 row or 8870 rows... a fairly big difference, I think you'll agree, which could well impact on the plan the optimizer chooses.
    One other point - leaving the clause as dates gives:
    AND    a.custom25 BETWEEN TO_DATE('2011/01/01', 'YYYY/MM/DD')
                          AND TO_DATE('2011/01/31', 'YYYY/MM/DD') which excludes any dates on 31st Jan 2011 except midnight, eg. 10am on 31st Jan 2011 won't be returned by your query.
    If you're after rows for a given month, then you could do:
    AND    trunc(a.custom25, 'mm') = TO_DATE('01/01/2011', 'dd/mm/yyyy')

  • Do i need to tune the redolog?

    10g R2 on AIX 5.3L
    this is a typical alert file about the redo log file switching of the day.
    Mon May 28 01:26:33 2007
    Thread 1 advanced to log sequence 24017
    Current log# 4 seq# 24017 mem# 0: /u020/apps/oracle/oradata/BAAN/redo04.log
    Mon May 28 08:04:13 2007
    Thread 1 advanced to log sequence 24018
    Current log# 5 seq# 24018 mem# 0: /u020/apps/oracle/oradata/BAAN/redo05.log
    Mon May 28 08:05:56 2007
    Thread 1 advanced to log sequence 24019
    Current log# 3 seq# 24019 mem# 0: /u020/apps/oracle/oradata/BAAN/redo03.log
    Mon May 28 08:07:29 2007
    Thread 1 advanced to log sequence 24020
    Current log# 2 seq# 24020 mem# 0: /u020/apps/oracle/oradata/BAAN/redo02.log
    Mon May 28 08:08:55 2007
    Thread 1 advanced to log sequence 24021
    Current log# 1 seq# 24021 mem# 0: /u020/apps/oracle/oradata/BAAN/redo01.log
    Mon May 28[b] 08:10:26 2007
    Thread 1 advanced to log sequence 24022
    Current log# 4 seq# 24022 mem# 0: /u020/apps/oracle/oradata/BAAN/redo04.log
    Mon May 28 08:12:05 2007
    Thread 1 advanced to log sequence 24023
    Current log# 5 seq# 24023 mem# 0: /u020/apps/oracle/oradata/BAAN/redo05.log
    Mon May 28 08:13:55 2007
    Thread 1 advanced to log sequence 24024
    Current log# 3 seq# 24024 mem# 0: /u020/apps/oracle/oradata/BAAN/redo03.log
    Mon May 28 11:31:05 2007
    Thread 1 advanced to log sequence 24025
    Current log# 2 seq# 24025 mem# 0: /u020/apps/oracle/oradata/BAAN/redo02.log
    Mon May 28 14:36:13 2007
    Thread 1 advanced to log sequence 24026
    Current log# 1 seq# 24026 mem# 0: /u020/apps/oracle/oradata/BAAN/redo01.log
    Do I need to tune the redo log? Each of redo log file is 50MB. It switched more frequent when there are not many users than real busy hours.
    null

    Select may or may not generate redo. Delayed block cleanout is one of the reasons for a query to produce redo: https://metalink.oracle.com/metalink/plsql/f?p=130:14:2631437878498686237::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,40689.1,1,1,1,helvetica#aref1
    Another reason is locking the rows with "for update":
    SQL> create table t1 as select * from all_objects;
    Table created.
    SQL> set autot trace stat
    SQL> select * from t1;
    39310 rows selected.
    Statistics
              0  recursive calls
              0  db block gets
           3117  consistent gets
            538  physical reads
              0  redo size
        2524195  bytes sent via SQL*Net to client
          18612  bytes received via SQL*Net from client
           2622  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
          39310  rows processed
    SQL> select * from t1 for update;
    39310 rows selected.
    Statistics
             24  recursive calls
          40020  db block gets
          43446  consistent gets
            625  physical reads
        7754052  redo size
        3501635  bytes sent via SQL*Net to client
          18612  bytes received via SQL*Net from client
           2622  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
          39310  rows processed

  • Need to tune insert query

    Hi,
    I'm using below query inside the procedure.I need to tune this query as it is taking more time for execution.Could you some help on this
    *version.*
    10.2.0
    Query
    INSERT INTO  TEMP_TEST_STAT(
                SELECT S.STUDENT_ID_PK, A.RESPONSE_KEY GENDER, B.RESPONSE_KEY ETHNICITY, T.SCORE SCALE_SCORE ,D.TEST_NAME
                FROM TEST_SESSION_DETAIL T, TEST_SESSION S, STUDENT U, TEST_DETAIL D,
                SELECT I.ITEM_ID, I.UIN, BG.BG_SESSION_DETAIL_ID, BG.RESPONSE_KEY , B.TEST_SESSION_ID, C.STUDENT_ID_PK
                FROM BG_QUESTION_USER_RESPONSE BG, ITEM I, BG_SESSION_DETAIL B, TEST_SESSION C
                WHERE
                BG.ITEM_ID = I.ITEM_ID AND I.UIN = 'SBG002' AND
                BG.BG_SESSION_DETAIL_ID = B.BG_SESSION_DETAIL_ID
                AND B.TEST_SESSION_ID = C.TEST_SESSION_ID ) A,
                SELECT I.ITEM_ID, I.UIN, BG.BG_SESSION_DETAIL_ID, BG.RESPONSE_KEY , B.TEST_SESSION_ID, C.STUDENT_ID_PK
                FROM BG_QUESTION_USER_RESPONSE BG, ITEM I, BG_SESSION_DETAIL B, TEST_SESSION C
                WHERE
                BG.ITEM_ID = I.ITEM_ID AND I.UIN = 'SBG001' AND
                BG.BG_SESSION_DETAIL_ID = B.BG_SESSION_DETAIL_ID
                AND B.TEST_SESSION_ID = C.TEST_SESSION_ID ) B
                ,INSTITUTION E
                WHERE
                D.TEST_NAME = 'Reading Comprehension' AND
                T.TEST_SESSION_STATUS_ID = 3
                AND TRUNC(T.TEST_END_DATE) BETWEEN TO_DATE('01-09-09','DD-MON-YY') AND TO_DATE('30-09-09','DD-MON-YY')
                AND T.TEST_DETAIL_ID = D.TEST_DETAIL_ID
                AND S.STUDENT_ID_PK = U.STUDENT_ID_PK
                AND S.TEST_SESSION_ID = T.TEST_SESSION_ID
                AND A.TEST_SESSION_ID = T.TEST_SESSION_ID
                AND A.STUDENT_ID_PK = S.STUDENT_ID_PK
                AND B.TEST_SESSION_ID = T.TEST_SESSION_ID
                AND B.STUDENT_ID_PK = S.STUDENT_ID_PK
                AND S.INSTITUTION_ID=E.INSTITUTION_ID
                AND SUBSTR(E.INSTITUTION_ID_DISPLAY,8,3) <> '000');
    Explain plan
    PLAN_TABLE_OUTPUT
    Plan hash value: 790379856
    | Id  | Operation                                      | Name                         | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | INSERT STATEMENT                               |                              |     1 |   204 |  1567   (1)| 00:00:19 |       |       |
    |*  1 |  FILTER                                        |                              |       |       |            |          |       |       |
    |   2 |   NESTED LOOPS                                 |                              |     1 |   204 |  1567   (1)| 00:00:19 |       |       |
    |   3 |    NESTED LOOPS                                |                              |     1 |   189 |  1566   (1)| 00:00:19 |       |       |
    |   4 |     NESTED LOOPS                               |                              |     1 |   167 |  1561   (1)| 00:00:19 |       |       |
    |   5 |      NESTED LOOPS                              |                              |     1 |   155 |  1560   (1)| 00:00:19 |       |       |
    |   6 |       NESTED LOOPS                             |                              |     1 |   143 |  1556   (1)| 00:00:19 |       |       |
    |   7 |        NESTED LOOPS                            |                              |     1 |   128 |  1555   (1)| 00:00:19 |       |       |
    |   8 |         NESTED LOOPS                           |                              |     1 |   106 |  1550   (1)| 00:00:19 |       |       |
    |   9 |          NESTED LOOPS                          |                              |   186 | 17484 |  1364   (1)| 00:00:17 |       |       |
    |* 10 |           HASH JOIN                            |                              |    86 |  7052 |  1020   (1)| 00:00:13 |       |       |
    |  11 |            NESTED LOOPS                        |                              |    86 |  5848 |  1002   (1)| 00:00:13 |       |       |
    |* 12 |             HASH JOIN                          |                              |    86 |  4472 |   916   (1)| 00:00:11 |       |       |
    |* 13 |              INDEX RANGE SCAN                  | TEST_DETAIL_AK_1             |     1 |    21 |     2   (0)| 00:00:01 |       |       |
    |* 14 |              TABLE ACCESS BY GLOBAL INDEX ROWID| TEST_SESSION_DETAIL          |  8549 |   258K|   914   (1)| 00:00:11 | ROWID | ROWID |
    |* 15 |               INDEX RANGE SCAN                 | TEST_END_DATE_IDX            | 15672 |       |    53   (0)| 00:00:01 |       |       |
    |  16 |             PARTITION HASH ITERATOR            |                              |     1 |    16 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |  17 |              TABLE ACCESS BY LOCAL INDEX ROWID | TEST_SESSION                 |     1 |    16 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |* 18 |               INDEX UNIQUE SCAN                | PK_TEST_SESSION              |     1 |       |     0   (0)| 00:00:01 |   KEY |   KEY |
    |* 19 |            INDEX FAST FULL SCAN                | INSTI_ID_NAME_COUN_DISP_IDX  |  5930 | 83020 |    17   (0)| 00:00:01 |       |       |
    |  20 |           TABLE ACCESS BY GLOBAL INDEX ROWID   | BG_SESSION_DETAIL            |     2 |    24 |     4   (0)| 00:00:01 | ROWID | ROWID |
    |* 21 |            INDEX RANGE SCAN                    | BG_SESS_DETAIL_TEST_SE_FK1_I |     2 |       |     2   (0)| 00:00:01 |       |       |
    |  22 |          PARTITION HASH ITERATOR               |                              |     1 |    12 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |* 23 |           TABLE ACCESS BY LOCAL INDEX ROWID    | TEST_SESSION                 |     1 |    12 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |* 24 |            INDEX UNIQUE SCAN                   | PK_TEST_SESSION              |     1 |       |     0   (0)| 00:00:01 |   KEY |   KEY |
    |  25 |         TABLE ACCESS BY GLOBAL INDEX ROWID     | BG_QUESTION_USER_RESPONSE    |     4 |    88 |     5   (0)| 00:00:01 | ROWID | ROWID |
    |* 26 |          INDEX RANGE SCAN                      | BG_QUESTION_USER_RESP_IDX1   |     4 |       |     2   (0)| 00:00:01 |       |       |
    |  27 |        PARTITION HASH ITERATOR                 |                              |     1 |    15 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |* 28 |         TABLE ACCESS BY LOCAL INDEX ROWID      | ITEM                         |     1 |    15 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |* 29 |          INDEX UNIQUE SCAN                     | PK_ITEM                      |     1 |       |     0   (0)| 00:00:01 |   KEY |   KEY |
    |  30 |       TABLE ACCESS BY GLOBAL INDEX ROWID       | BG_SESSION_DETAIL            |     2 |    24 |     4   (0)| 00:00:01 | ROWID | ROWID |
    |* 31 |        INDEX RANGE SCAN                        | BG_SESS_DETAIL_TEST_SE_FK1_I |     2 |       |     2   (0)| 00:00:01 |       |       |
    |  32 |      PARTITION HASH ITERATOR                   |                              |     1 |    12 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |* 33 |       TABLE ACCESS BY LOCAL INDEX ROWID        | TEST_SESSION                 |     1 |    12 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |* 34 |        INDEX UNIQUE SCAN                       | PK_TEST_SESSION              |     1 |       |     0   (0)| 00:00:01 |   KEY |   KEY |
    |  35 |     TABLE ACCESS BY GLOBAL INDEX ROWID         | BG_QUESTION_USER_RESPONSE    |     4 |    88 |     5   (0)| 00:00:01 | ROWID | ROWID |
    |* 36 |      INDEX RANGE SCAN                          | BG_QUESTION_USER_RESP_IDX1   |     4 |       |     2   (0)| 00:00:01 |       |       |
    |  37 |    PARTITION HASH ITERATOR                     |                              |     1 |    15 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |* 38 |     TABLE ACCESS BY LOCAL INDEX ROWID          | ITEM                         |     1 |    15 |     1   (0)| 00:00:01 |   KEY |   KEY |
    |* 39 |      INDEX UNIQUE SCAN                         | PK_ITEM                      |     1 |       |     0   (0)| 00:00:01 |   KEY |   KEY |
    Predicate Information (identified by operation id):
       1 - filter(TO_DATE('01-09-09','DD-MON-YY')<=TO_DATE('30-09-09','DD-MON-YY'))
      10 - access("S"."INSTITUTION_ID"="E"."INSTITUTION_ID")
      12 - access("T"."TEST_DETAIL_ID"="D"."TEST_DETAIL_ID")
      13 - access("D"."TEST_NAME"='Reading Comprehension')
      14 - filter("T"."TEST_SESSION_STATUS_ID"=3)
      15 - access(TRUNC(INTERNAL_FUNCTION("TEST_END_DATE"))>=TO_DATE('01-09-09','DD-MON-YY') AND
                  TRUNC(INTERNAL_FUNCTION("TEST_END_DATE"))<=TO_DATE('30-09-09','DD-MON-YY'))
      18 - access("S"."TEST_SESSION_ID"="T"."TEST_SESSION_ID")
      19 - filter(SUBSTR("E"."INSTITUTION_ID_DISPLAY",8,3)<>'000')
      21 - access("B"."TEST_SESSION_ID"="T"."TEST_SESSION_ID")
      23 - filter("C"."STUDENT_ID_PK"="S"."STUDENT_ID_PK")
      24 - access("B"."TEST_SESSION_ID"="C"."TEST_SESSION_ID")
      26 - access("BG"."BG_SESSION_DETAIL_ID"="B"."BG_SESSION_DETAIL_ID")
      28 - filter("I"."UIN"='SBG001')
      29 - access("BG"."ITEM_ID"="I"."ITEM_ID")
      31 - access("B"."TEST_SESSION_ID"="T"."TEST_SESSION_ID")
      33 - filter("C"."STUDENT_ID_PK"="S"."STUDENT_ID_PK")
      34 - access("B"."TEST_SESSION_ID"="C"."TEST_SESSION_ID")
      36 - access("BG"."BG_SESSION_DETAIL_ID"="B"."BG_SESSION_DETAIL_ID")
      38 - filter("I"."UIN"='SBG002')
      39 - access("BG"."ITEM_ID"="I"."ITEM_ID")

    Rob,
    How i can my insert statement here.
    I tried like..but error.
    select /*+ gather_plan_statistics */  INSERT INTO  TEMP_TEST_STAT(
                SELECT S.STUDENT_ID_PK, A.RESPONSE_KEY GENDER, B.RESPONSE_KEY ETHNICITY, T.SCORE SCALE_SCORE ,D.TEST_NAME
                FROM TEST_SESSION_DETAIL T, TEST_SESSION S, STUDENT U, TEST_DETAIL D,
                SELECT I.ITEM_ID, I.UIN, BG.BG_SESSION_DETAIL_ID, BG.RESPONSE_KEY , B.TEST_SESSION_ID, C.STUDENT_ID_PK
                FROM BG_QUESTION_USER_RESPONSE BG, ITEM I, BG_SESSION_DETAIL B, TEST_SESSION C
                WHERE
                BG.ITEM_ID = I.ITEM_ID AND I.UIN = 'SBG002' AND
                BG.BG_SESSION_DETAIL_ID = B.BG_SESSION_DETAIL_ID
                AND B.TEST_SESSION_ID = C.TEST_SESSION_ID ) A,
                SELECT I.ITEM_ID, I.UIN, BG.BG_SESSION_DETAIL_ID, BG.RESPONSE_KEY , B.TEST_SESSION_ID, C.STUDENT_ID_PK
                FROM BG_QUESTION_USER_RESPONSE BG, ITEM I, BG_SESSION_DETAIL B, TEST_SESSION C
                WHERE
                BG.ITEM_ID = I.ITEM_ID AND I.UIN = 'SBG001' AND
                BG.BG_SESSION_DETAIL_ID = B.BG_SESSION_DETAIL_ID
                AND B.TEST_SESSION_ID = C.TEST_SESSION_ID ) B
                ,INSTITUTION E
                WHERE
                D.TEST_NAME = 'Reading Comprehension' AND
                T.TEST_SESSION_STATUS_ID = 3
                AND TRUNC(T.TEST_END_DATE) BETWEEN TO_DATE('01-09-09','DD-MON-YY') AND TO_DATE('30-09-09','DD-MON-YY')
                AND T.TEST_DETAIL_ID = D.TEST_DETAIL_ID
                AND S.STUDENT_ID_PK = U.STUDENT_ID_PK
                AND S.TEST_SESSION_ID = T.TEST_SESSION_ID
                AND A.TEST_SESSION_ID = T.TEST_SESSION_ID
                AND A.STUDENT_ID_PK = S.STUDENT_ID_PK
                AND B.TEST_SESSION_ID = T.TEST_SESSION_ID
                AND B.STUDENT_ID_PK = S.STUDENT_ID_PK
                AND S.INSTITUTION_ID=E.INSTITUTION_ID
                AND SUBSTR(E.INSTITUTION_ID_DISPLAY,8,3)  '000') from dual;please advice

  • How to tune the query and difference between CBO AND RBO.. Which is good

    Hello Friends,
    Here are some questions I have pls reply back with complete description and url if any ..
    1)How Did you tune Query,
    2)What approach you take to tune query? Do you use Hints?
    3)Where did you tune the query and what are the issue with query?
    4)What is difference between RBO and CBO? where u use RBO and CBO.
    5)Give some information about hash join?
    6) Using explain plan how do u know where the bottle neck in query .. how u will identify where the bottle neck is from explain plan .
    thanks/Kumar

    Hi,
    kumar73 wrote:
    Hello Friends,
    Here are some questions I have pls reply back with complete description and url if any ..
    1)How Did you tune Query, Use EXPLAIN PLAN to see exactly where it is spending its time, and address those areas.
    See the forum FAQ
    SQL and PL/SQL FAQ
    "3. How to improve the performance of my query?"
    2)What approach you take to tune query? Do you use Hints?Hints can help.
    Even more helpful is writing the SQL efficiently (avoiding multiple scans of the same table, filtering early, using built-in rather than user-defined functions, ...), creating and using indexes, and, for large tables, partitioning.
    Table design can have a big impact on performace.
    Look for ways to do part of what you need before the query. This includes denormalizing (when appropriate), the kind of pre-digesting that often takes place in data warehouses, function-based indexes, and, starting in Oracle 11, virtual columns.
    3)Where did you tune the query and what are the issue with query?Either this question is a vague summary of the entire thread, or I don't understand it. Can you re-phrase this part?
    4)What is difference between RBO and CBO? where u use RBO and CBO.Basically, use RBO if you have Oracle 7 or earlier.

  • How to tune the query...?

    Hi all,
    I am having a table with millions of records and the query is taking hours
    time. How to tune the query apart from doing the following things.
    1. Creating or Deleting indexes.
    2. Using Bind variables.
    3. Using Hints.
    4. Updating the Statitics regurarly.
    Actually, i have asked this question in interview how to tune the query.
    I told him the above 4 things. Then he told, these are not working, then
    how you will tune this query.
    Thanks in advance,
    Pal

    user546710 wrote:
    Actually, i have asked this question in interview how to tune the query.
    I told him the above 4 things. Then he told, these are not working, then
    how you will tune this query.It actually depends on the scenario/problem given.
    You may want to read this first.
    When your query takes too long ...
    When your query takes too long ...
    HOW TO: Post a SQL statement tuning request - template posting
    HOW TO: Post a SQL statement tuning request - template posting

  • Need to save the query under the correct role

    Hi Experts,
    I need to save the query under the specific role. So is there anyway to find the query location by role??
    Thanks
    Regards,
    Arpan

    Hi,
    RSZCOMPDIR --> RSRREPDIR -->AGR_HIER
    From RSZCOMPDIR get all the entries of queries.
    compid is query name, take compuID and pass to RSRREPDIR.
    get genuniid and pass to AGR_HIER's sap_guid.
    AGR_NAME in AGR_HIER is role name.
    please check this.
    -Sriram
    Message was edited by: Sriramvijay R
    Message was edited by: Sriramvijay R

  • Undo_tablespace and undo_retetion or tune the query  which one to increase

    hi all,
    In my logs file s
    ORA-01555 caused by SQL statement below (SQL ID: 9nc0n06yryhbk, Query Duration=165122 sec, SCN: 0x05ff.062f3363):
    Tue Feb 5 02:26:39 2008
    SELECT /*+ FIRST_ROWS */ /*+ ORDERED */ B.GID ,K.ELEMENT_TYPE ,K.DATA_SOURCE_GID ,K.PROD_ID ,K.OPTION_CD ,K.MCC ,K.SPN ,K.REGION_CD ,K.WW_CD ,K.COUNTRY_CD ,K.ERROR ,B.GBATCH_ID
    ,B.PERIOD_SEQ_NUM ,B.ACTION ,B.ERROR B_ERROR ,B.COST ,B.INPUT_FILE_ROW_NUM ,B.ACTION_STATUS ,B.ACTION_TIMESTAMP FROM T_INPUT_BUCKET B, T_COS_INPUT_KEY K WHERE B.ACTION_STATUS =
    'initial' AND B.GINPUT_KEY_ID = K.GID AND B.GBATCH_ID = :B1 AND ROWNUM < 8001
    Tue Feb 5 02:35:21 2008
    Thread 2 advanced to log sequence 42907
    Mon Feb 4 09:10:55 2008
    ORA-01555 caused by SQL statement below (SQL ID: 9nc0n06yryhbk, Query Duration=104081 sec, SCN: 0x05ff.05ebc008):
    Mon Feb 4 09:10:55 2008
    SELECT /*+ FIRST_ROWS */ /*+ ORDERED */ B.GID ,K.ELEMENT_TYPE ,K.DATA_SOURCE_GID ,K.PROD_ID ,K.OPTION_CD ,K.MCC ,K.SPN ,K.REGION_CD ,K.WW_CD ,K.COUNTRY_CD ,K.ERROR ,B.GBATCH_ID
    ,B.PERIOD_SEQ_NUM ,B.ACTION ,B.ERROR B_ERROR ,B.COST ,B.INPUT_FILE_ROW_NUM ,B.ACTION_STATUS ,B.ACTION_TIMESTAMP FROM T_INPUT_BUCKET B, T_COS_INPUT_KEY K WHERE B.ACTION_STATUS =
    'initial' AND B.GINPUT_KEY_ID = K.GID AND B.GBATCH_ID = :B1 AND ROWNUM < 8001
    Mon Feb 4 09:14:08 2008
    ===============================================
    and my undo_retention
    Current usage:
    UNDO_01 96736 11596 12 88
    UNDO_02 96736 9357 10 90
    NAME TYPE VALUE
    undo_management string AUTO
    undo_retention integer 36000
    can anyone please guide me which one is best to increase undo_retention or undo_tablespace
    or tune the query?
    my database version is
    Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bi
    PL/SQL Release 10.2.0.2.0 - Production
    "CORE     10.2.0.2.0     Production"
    TNS for HPUX: Version 10.2.0.2.0 - Production
    NLSRTL Version 10.2.0.2.0 - Production
    thanks in advance

    IMO best is to
    1) tune the query to minimize time and resource use;
    2) set the undo_retention to size the undo tablespace for the required 'consistent read' rebuild requirements;
    3) set the retention guarantee appropriately
    4) size the undo tablespace based on the required size, probably dictated by 2)
    Why is this an 'either one or other' question? When driving a car and looking for best fuel efficiency, you tune up the car, drive properly AND use the right fuel. You don't just pick one and leave it at that.

  • How to tune the query for duplicate records while joining the two tables

    hi,i am executing the query which has retrieving multiple tables,in which one of them has duplicate record,how to get single record

    Not enough info...subject says "tune" the query, message says "write" the query...and where is actual query that you had tried ?

Maybe you are looking for

  • Alv report in tree format

    hi experts i have a report which displays out put in alv grid display with 17 fields. my requirement is i have to change the alvgrid display output into ALV Tree with    9 levels with fields and their descriptions. i should mantain back option in alv

  • OIM 10.1.4.3 patcher error connecting to 11gr2 DB

    I am trying to install FRP 11g and am almost to the actual FRP install.... I have the latest version of 11g database as my repository DB. I installed OIM 10.1.4.0.1 for the SSO and DAS into the 11g IM repo successfully. However when trying to run the

  • How to import PDF image into Pages manuscript that is larger than the text bed margins

    How do I import a PDF image into a Pages book manuscript, whose dimensions are larger than the global text bed margins? Any imported PDF image is automatically shrunk to fit within the text bed. I know I can set up a single page with wider margins an

  • Diashow will loose vector-quality

    Hi, my problem is, that I´ve created a vector in Illustrator and imported it into InDesign. All is perfect, but if I create a diashow with this vector from illustrator it will (probably) converted into an image and loose the quality (if I zoom into t

  • CS4 AE Crashes Every Time I Quit

    I know about the Crash Reporter and the Apple Crash report which I have sent many times. Just looking for a couple suggestions on how to try to troubleshoot this or what to look for in the Crash Report that may help me. I will not post the report her