CDHDR table query taking long time

Hi all,
Select query from CDHDR table is taking long time,in where condition i am giving OBJECTCLASS = 'MAT_FULL' udate = sy-datum and langu = 'EN'.
any suggestion to improve the performance.i want to select all the article which got changed on current date
regards
shibu

This will always be slow for large data volumes, since CDHDR is designed for quick access by object ID (in this case material number), not by date.
I'm afraid you would need to introduce a secondary index on OBJECTCLAS and UDATE, if that query is crucial enough to warrant the additional disk space and processing time taken by the new index.
Greetings
Thomas

Similar Messages

  • COEP table query taking longer time

    Hi ABAP guru's,
    I have a problem with the performance of a Select query on table COEP(91 million records in QA),
    i want to tune the program for better performance.
    Presenlty it took nearly 6 hrs to execute the program in Background, if in foreground givig dump with
    message for maximum time exceed.
    the code which exists in the program is
    SELECT WOGBTR OBJNR KSTAR OWAER PERIO FROM COEP
       INTO  TABLE T_COEP
          WHERE KOKRS = P_KOKRS AND
           OBJNR IN R_COSTCENTER  AND   
           KSTAR IN R_COSTELEMENT AND   
           PERIO LE P_PERIO       AND   
          GJAHR EQ G_YEAR.
    I am in a support project and i need to fix this issue ASAP plz help me out in tuning the program.
    I have seen some other posts in the forum for similar issues, the outcome of that is to use LEDNR = '00'.
    I am not sure if this works for me or not.
    I cant take chance of trail and error , as it has to move to QA untill i know the status of the change and it takes a minimum of week time.
    Regards
    Sunil kumar

    Hi Experts,
    I got a similiar issue, though I follow code specified above still the performance is slow. Please suggest what need to be done.
    select dintinct objnr
                         uspob
                INTO TABLE lt_srcc
                FROM coep
                WHERE kokrs  EQ 'ESAM'
                AND perio EQ p_period
                AND lednr = gc_00
    *          AND objnr  LIKE 'KSESAM%'
                AND gjahr EQ p_fisyr
                AND kstar  LIKE '0000901%'
                AND vrgng  EQ 'RKIU'
                AND uspob LIKE 'KSESAM%'
                %_HINTS ORACLE 'INDEX("COEP" "COEP~1")'.
    Thanks
    Chandramouli

  • Query taking long time for EXTRACTING the data more than 24 hours

    Hi ,
    Query taking long time for EXTRACTING the data more than 24 hours please find the query and explain plan details below even indexes avilable on table's goe's to FULL TABLE SCAN. please suggest me.......
    SQL> explain plan for select a.account_id,round(a.account_balance,2) account_balance,
    2 nvl(ah.invoice_id,ah.adjustment_id) transaction_id,
    to_char(ah.effective_start_date,'DD-MON-YYYY') transaction_date,
    to_char(nvl(i.payment_due_date,
    to_date('30-12-9999','dd-mm-yyyy')),'DD-MON-YYYY')
    due_date, ah.current_balance-ah.previous_balance amount,
    decode(ah.invoice_id,null,'A','I') transaction_type
    3 4 5 6 7 8 from account a,account_history ah,invoice i_+
    where a.account_id=ah.account_id
    and a.account_type_id=1000002
    and round(a.account_balance,2) > 0
    and (ah.invoice_id is not null or ah.adjustment_id is not null)
    and ah.CURRENT_BALANCE > ah.previous_balance
    and ah.invoice_id=i.invoice_id(+)
    AND a.account_balance > 0
    order by a.account_id,ah.effective_start_date desc; 9 10 11 12 13 14 15 16
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)|
    | 0 | SELECT STATEMENT | | 544K| 30M| | 693K (20)|
    | 1 | SORT ORDER BY | | 544K| 30M| 75M| 693K (20)|
    |* 2 | HASH JOIN | | 544K| 30M| | 689K (20)|
    |* 3 | TABLE ACCESS FULL | ACCOUNT | 20080 | 294K| | 6220 (18)|
    |* 4 | HASH JOIN OUTER | | 131M| 5532M| 5155M| 678K (20)|
    |* 5 | TABLE ACCESS FULL| ACCOUNT_HISTORY | 131M| 3646M| | 197K (25)|
    | 6 | TABLE ACCESS FULL| INVOICE | 262M| 3758M| | 306K (18)|
    Predicate Information (identified by operation id):
    2 - access("A"."ACCOUNT_ID"="AH"."ACCOUNT_ID")
    3 - filter("A"."ACCOUNT_TYPE_ID"=1000002 AND "A"."ACCOUNT_BALANCE">0 AND
    ROUND("A"."ACCOUNT_BALANCE",2)>0)
    4 - access("AH"."INVOICE_ID"="I"."INVOICE_ID"(+))
    5 - filter("AH"."CURRENT_BALANCE">"AH"."PREVIOUS_BALANCE" AND ("AH"."INVOICE_ID"
    IS NOT NULL OR "AH"."ADJUSTMENT_ID" IS NOT NULL))
    22 rows selected.
    Index Details:+_
    SQL> select INDEX_OWNER,INDEX_NAME,COLUMN_NAME,TABLE_NAME from dba_ind_columns where
    2 table_name in ('INVOICE','ACCOUNT','ACCOUNT_HISTORY') order by 4;
    INDEX_OWNER INDEX_NAME COLUMN_NAME TABLE_NAME
    OPS$SVM_SRV4 P_ACCOUNT ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME ACCOUNT_NAME ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT CUSTOMER_NODE_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT ACCOUNT_TYPE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_ACCOUNT_TYPE ACCOUNT_TYPE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_INVOICE INVOICE_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_PREVIOUS_INVOICE PREVIOUS_INVOICE_ID ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME_ID ACCOUNT_NAME ACCOUNT
    OPS$SVM_SRV4 U_ACCOUNT_NAME_ID ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 I_LAST_MODIFIED_ACCOUNT LAST_MODIFIED ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_INVOICE_ACCOUNT INVOICE_ACCOUNT_ID ACCOUNT
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ACCOUNT ACCOUNT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ACCOUNT SEQNR ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_INVOICE INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADINV INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA CURRENT_BALANCE ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA INVOICE_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_CIA ACCOUNT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_LMOD LAST_MODIFIED ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADINV ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_PAYMENT PAYMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_ADJUSTMENT ADJUSTMENT_ID ACCOUNT_HISTORY
    OPS$SVM_SRV4 I_ACCOUNT_HISTORY_APPLIED_DT APPLIED_DATE ACCOUNT_HISTORY
    OPS$SVM_SRV4 P_INVOICE INVOICE_ID INVOICE
    OPS$SVM_SRV4 U_INVOICE CUSTOMER_INVOICE_STR INVOICE
    OPS$SVM_SRV4 I_LAST_MODIFIED_INVOICE LAST_MODIFIED INVOICE
    OPS$SVM_SRV4 U_INVOICE_ACCOUNT ACCOUNT_ID INVOICE
    OPS$SVM_SRV4 U_INVOICE_ACCOUNT BILL_RUN_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_BILL_RUN BILL_RUN_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_INVOICE_TYPE INVOICE_TYPE_ID INVOICE
    OPS$SVM_SRV4 I_INVOICE_CUSTOMER_NODE CUSTOMER_NODE_ID INVOICE
    32 rows selected.
    Regards,
    Bathula
    Oracle-DBA

    I have some suggestions. But first, you realize that you have some redundant indexes, right? You have an index on account(account_name) and also account(account_name, account_id), and also account_history(invoice_id) and account_history(invoice_id, adjustment_id). No matter, I will suggest some new composite indexes.
    Also, you do not need two lines for these conditions:
    and round(a.account_balance, 2) > 0
    AND a.account_balance > 0
    You can just use: and a.account_balance >= 0.005
    So the formatted query isselect a.account_id,
           round(a.account_balance, 2) account_balance,
           nvl(ah.invoice_id, ah.adjustment_id) transaction_id,
           to_char(ah.effective_start_date, 'DD-MON-YYYY') transaction_date,
           to_char(nvl(i.payment_due_date, to_date('30-12-9999', 'dd-mm-yyyy')),
                   'DD-MON-YYYY') due_date,
           ah.current_balance - ah.previous_balance amount,
           decode(ah.invoice_id, null, 'A', 'I') transaction_type
      from account a, account_history ah, invoice i
    where a.account_id = ah.account_id
       and a.account_type_id = 1000002
       and (ah.invoice_id is not null or ah.adjustment_id is not null)
       and ah.CURRENT_BALANCE > ah.previous_balance
       and ah.invoice_id = i.invoice_id(+)
       AND a.account_balance >= .005
    order by a.account_id, ah.effective_start_date desc;You will probably want to select:
    1. From ACCOUNT first (your smaller table), for which you supply a literal on account_type_id. That should limit the accounts retrieved from ACCOUNT_HISTORY
    2. From ACCOUNT_HISTORY. We want to limit the records as much as possible on this table because of the outer join.
    3. INVOICE we want to access last because it seems to be least restricted, it is the biggest, and it has the outer join condition so it will manufacture rows to match as many rows as come back from account_history.
    Try the query above after creating the following composite indexes. The order of the columns is important:create index account_composite_i on account(account_type_id, account_balance, account_id);
    create index acct_history_comp_i on account_history(account_id, invoice_id, adjustment_id, current_balance, previous_balance, effective_start_date);
    create index invoice_composite_i on invoice(invoice_id, payment_due_date);All the columns used in the where clause will be indexed, in a logical order suited to the needs of the query. Plus each selected column is indexed as well so that we should not need to touch the tables at all to satisfy the query.
    Try the query after creating these indexes.
    A final suggestion is to try larger sort and hash area sizes and a manual workarea policy.alter session set workarea_size_policy = manual;
    alter session set sort_area_size = 2147483647;
    alter session set hash_area_size = 2147483647;

  • Table valueset taking long time to open the LOV

    Hi,
    We added a table valueset to a concurrent program. The table vaueset showsTransaction number from ra_interface_lines_all table. It is having long list. So we added the partial string entering message before open a long list.But still it is taking long time.
    Please any help on this highly appreciated.
    Thanks,
    Samba

    Hi
    Try to modify the query or creating an index will speed up the process.
    Thanks & regards
    Rajan

  • Query taking long time to run.

    The following query is taking long time to run, is there anything can be done to make it run faster by changing the sql etc.
    select distinct
    A.DEPTID,
    A.POSITION_NBR,
    A.EMPLID,
    A.EMPL_RCD_NBR,
    A.EFFDT,
    B.NAME,
    A.EMPL_STATUS,
    A.JOBCODE,
    A.ANNUAL_RT,
    A.STD_HOURS,
    A.PRIMARY_JOB,
    C.POSN_STATUS,
    case when A.POSITION_NBR = ' ' then 0 else C.STD_HOURS end,
    case when A.POSITION_NBR = ' ' then ' ' else C.DEPTID end
    from PS_JOB A,
    PS_PERSONAL_DATA B,
    PS_POSITION_DATA C
    where A.EMPLID = B.EMPLID
    and
    ((A.POSITION_NBR = C.POSITION_NBR
    and A.EFFSEQ = (select max(D.EFFSEQ)
    from PS_JOB D
    where D.EMPLID = A.EMPLID
    and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
    and D.EFFDT = A.EFFDT)
    and C.POSN_STATUS <> 'G'
    and C.EFFDT = (select max(E.EFFDT)
    from PS_POSITION_DATA E
    where E.POSITION_NBR = A.POSITION_NBR
    and E.EFFDT <= A.EFFDT)
    and C.EFFSEQ = (select max(F.EFFSEQ)
    from PS_POSITION_DATA F
    where F.POSITION_NBR = A.POSITION_NBR
    and F.EFFDT = C.EFFDT))
    or
    (A.POSITION_NBR = C.POSITION_NBR
    and A.EFFDT = (select max(D.EFFDT)
    from PS_JOB D
    where D.EMPLID = A.EMPLID
    and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
    and D.EFFDT <= C.EFFDT)
    and A.EFFSEQ = (select max(E.EFFSEQ)
    from PS_JOB E
    where E.EMPLID = A.EMPLID
    and E.EMPL_RCD_NBR = A.EMPL_RCD_NBR
    and E.EFFDT = A.EFFDT)
    and C.POSN_STATUS <> 'G'
    and C.EFFSEQ = (select max(F.EFFSEQ)
    from PS_POSITION_DATA F
    where F.POSITION_NBR = A.POSITION_NBR
    and F.EFFDT = C.EFFDT)))
    or
    (A.POSITION_NBR = ' '
    and A.EFFSEQ = (select max(E.EFFSEQ)
    from PS_JOB D
    where D.EMPLID = A.EMPLID
    and E.EMPL_RCD_NBR = A.EMPL_RCD_NBR
    and D.EFFDT = A.EFFDT)))

    Using distributive law A and (B or C) = (A and B) or (A and C) from right to left we can have:
    select distinct A.DEPTID,A.POSITION_NBR,A.EMPLID,A.EMPL_RCD_NBR,A.EFFDT,B.NAME,A.EMPL_STATUS,
                    A.JOBCODE,A.ANNUAL_RT,A.STD_HOURS,A.PRIMARY_JOB,C.POSN_STATUS,
                    case when A.POSITION_NBR = ' ' then 0 else C.STD_HOURS end,
                    case when A.POSITION_NBR = ' ' then ' ' else C.DEPTID end
      from PS_JOB A,PS_PERSONAL_DATA B,PS_POSITION_DATA C
    where A.EMPLID = B.EMPLID
       and (
             A.POSITION_NBR = C.POSITION_NBR
         and A.EFFSEQ = (select max(D.EFFSEQ)
                           from PS_JOB D
                          where D.EMPLID = A.EMPLID
                            and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
                            and D.EFFDT = A.EFFDT
         and C.EFFSEQ = (select max(F.EFFSEQ)
                           from PS_POSITION_DATA E
                          where E.POSITION_NBR = A.POSITION_NBR
                            and E.EFFDT = C.EFFDT
         and C.POSN_STATUS != 'G'
         and (
               C.EFFDT = (select max(E.EFFDT) 
                            from PS_POSITION_DATA E
                           where E.POSITION_NBR = A.POSITION_NBR
                             and E.EFFDT <= A.EFFDT
           or
               A.EFFDT = (select max(D.EFFDT) 
                            from PS_JOB D
                           where D.EMPLID = A.EMPLID
                             and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
                             and D.EFFDT <= C.EFFDT
         or
             A.POSITION_NBR = ' '
               and A.EFFSEQ = (select max(E.EFFSEQ)
                                 from PS_JOB D
                                where D.EMPLID = A.EMPLID
                                  and E.EMPL_RCD_NBR = A.EMPL_RCD_NBR
                                  and D.EFFDT = A.EFFDT
           )may not help much as the optimizer might have guessed it already
    Regards
    Etbin

  • Sap bi--query taking long time to exexute

    Hi
    When i try  run the bex query ,its taking long time,please suggest
    Thanks
    sreedhar

    Hi
    When i try  run the bex query ,its taking long time,please suggest
    Thanks
    sreedhar

  • Sql query taking long time

    the below query is taking very long time.
    select /*+ PARALLEL(a,8) PARALLEL(b,8) */ a.personid,a.winning_id, b.questionid from
    winning_id_cleanup a , rm_personquestion b
    where a.personid = b.personid and (a.winning_id,b.questionid) not in
    (select /*+ PARALLEL(c,8) */ c.personid,c.questionid from rm_personquestion c where c.personid=a.winning_id);
    where the rm_personquestion table is having 45 million rows and winning_id_cleanup is having 1 million rows.
    please tell me how to tune this query?

    Please post u'r query at PL/SQL
    It's not for SQL and PL/SQL

  • SQL Query taking longer time as seen from Trace file

    Below Query Execution timings:
    Any help will be benefitial as its affecting business needs.
    SELECT MATERIAL_DETAIL_ID
    FROM
    GME_MATERIAL_DETAILS WHERE BATCH_ID = :B1 FOR UPDATE OF ACTUAL_QTY NOWAIT
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.70 0 0 0 0
    Execute 2256 8100.00 24033.51 627 12298 31739 0
    Fetch 2256 900.00 949.82 0 12187 0 30547
    total 4513 9000.00 24984.03 627 24485 31739 30547
    Thanks and Regards

    Thanks Buddy.
    Data Collected from Trace file:
    SELECT STEP_CLOSE_DATE
    FROM
    GME_BATCH_STEPS WHERE BATCH_ID
    IN (SELECT
    DISTINCT BATCH_ID FROM
    GME_MATERIAL_DETAILS START WITH BATCH_ID = :B2 CONNECT BY PRIOR PHANTOM_ID=BATCH_ID)
    AND NVL(STEP_CLOSE_DATE, :B1) > :B1
    call count cpu elapsed disk query current rows
    Parse 1 0.00 0.54 0 0 0 0
    Execute 2256 800.00 1120.32 0 0 0 0
    Fetch 2256 9100.00 13551.45 396 77718 0 0
    total 4513 9900.00 14672.31 396 77718 0 0
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 66 (recursive depth: 1)
    Rows Row Source Operation
    0 TABLE ACCESS BY INDEX ROWID GME_BATCH_STEPS
    13160 NESTED LOOPS
    6518 VIEW
    6518 SORT UNIQUE
    53736 CONNECT BY WITH FILTERING
    30547 NESTED LOOPS
    30547 INDEX RANGE SCAN GME_MATERIAL_DETAILS_U1 (object id 146151)
    30547 TABLE ACCESS BY USER ROWID GME_MATERIAL_DETAILS
    23189 NESTED LOOPS
    53736 BUFFER SORT
    53736 CONNECT BY PUMP
    23189 TABLE ACCESS BY INDEX ROWID GME_MATERIAL_DETAILS
    23189 INDEX RANGE SCAN GME_MATERIAL_DETAILS_U1 (object id 146151)
    4386 INDEX RANGE SCAN GME_BATCH_STEPS_U1 (object id 146144)
    In the Package there are lots of SQL Statements using CONNECT BY CLAUSE.
    Does the use of CONNECT BY Clause degrades performance?
    As you can see the Rows Section is 0 but the Query and elapsed time is taking longer
    Regards

  • Query taking long time

    Hi
    I have a query in which, its a 3 table join but takes a long time to execute. I had checked with plan table.. it shows one of the table is FULL ACCESS.
    I have 2 clarifications.
    1. Will the status checking as NULL - (it shouldn't use index)
    2. Is the case statements are recommended for queries.
    Query
    Select .........
    FROM CLIENT LEFT OUTER JOIN INTERNET_LOGIN ON INTERNET_LOGIN.NUM_CLIENT_ID=CLIENT.NUM_CLIENT_ID,
    POLI_MOT.
    WHERE
    POLI_MOT.NUM_CLIENT_ID=CLIENT.NUM_CLIENT_ID
    AND
    (POLI_MOT.CHR_CANCEL_STATUS='N'
    OR
    POLI_MOT.CHR_CANCEL_STATUS IS NULL)
    AND
    CLIENT.NUM_CONTACT_TYPE_ID IN (1,3)
    AND
    (NVL(POLI_MOT.VCH_NEW_IC_NO,'A') =
    CASE WHEN (NVL(null,NULL) IS NULL) THEN
    NVL(POLI_MOT.VCH_NEW_IC_NO,'A')
    ELSE
    NVL(null,NULL)
    END
    OR
    POLI_MOT.VCH_OLD_IC_NO =
    CASE WHEN nvl(null,null) IS NULL THEN
    POLI_MOT.VCH_OLD_IC_NO
    ELSE
    NVL(null,NULL)
    END )
    AND POLI_MOT.VCH_POLICY_NO =
    CASE WHEN UPPER(nvl(NULL,null)) IS NULL THEN
    POLI_MOT.VCH_POLICY_NO
    ELSE
    NVL(NULL,NULL)
    END
    AND POLI_MOT.VCH_VEHICLE_NO =
    CASE WHEN UPPER(NVL('123',NULL)) IS NULL THEN
    POLI_MOT.VCH_VEHICLE_NO
    ELSE
    NVL('123',NULL)
    END

    Hi,
    There is nothing wrong in having a full table access. When you do the explain plan please check for which table costs you the maximun. try to work on that table.
    To tune the performance of your query you can try either indexing or parallel access.
    the syntax for parallel index is
    /*+ PARALLEL("TBL_NM",100) */(any number)...
    for index please use the index name of the table you want to index..
    regards
    Bharath

  • Query taking long time To Fectch the Results

    Hi!
    when I run the query,it takes too long time for fetching the resultsets.
    Please find the query below for the same.
    SELECT
    A.BUSINESS_UNIT,
    A.JOURNAL_ID,
    TO_CHAR(A.JOURNAL_DATE,'YYYY-MM-DD'),
    A.UNPOST_SEQ,
    A.FISCAL_YEAR,
    A.ACCOUNTING_PERIOD,
    A.JRNL_HDR_STATUS,
    C.INVOICE,
    C.ACCT_ENTRY_TYPE,
    C.LINE_DST_SEQ_NUM,
    C.TAX_AUTHORITY_CD,
    C.ACCOUNT,
    C.MONETARY_AMOUNT,
    D.BILL_SOURCE_ID,
    D.IDENTIFIER,
    D.VAT_AMT_BSE,
    D.VAT_TRANS_AMT_BSE,
    D.VAT_TXN_TYPE_CD,
    D.TAX_CD_VAT,
    D.TAX_CD_VAT_PCT,
    D.VAT_APPLICABILITY,
    E.BILL_TO_CUST_ID,
    E.BILL_STATUS,
    E.BILL_CYCLE_ID,
    TO_CHAR(E.INVOICE_DT,'YYYY-MM-DD'),
    TO_CHAR(E.ACCOUNTING_DT,'YYYY-MM-DD'),
    TO_CHAR(E.DT_INVOICED,'YYYY-MM-DD'),
    E.ENTRY_TYPE,
    E.ENTRY_REASON,
    E.AR_LVL,
    E.AR_DST_OPT,
    E.AR_ENTRY_CREATED,
    E.GEN_AR_ITEM_FLG,
    E.GL_LVL, E.GL_ENTRY_CREATED,
    (Case when c.account in ('30120000','30180050','30190000','30290000','30490000',
    '30690000','30900040','30990000','35100000','35120000','35150000','35160000',
    '39100050','90100000')
    and D.TAX_CD_VAT_PCT <> 0 then 'Ej_Momskonto_med_moms'
    When c.account not in ('30120000','30180050','30190000','30290000',
    '30490000','30690000','30900040','30990000','35100000','35120000','35150000',
    '35160000','39100050','90100000')
    and D.TAX_CD_VAT_PCT <> 25 then 'Momskonto_utan_moms' end)
    FROM
    sysadm.PS_JRNL_HEADER A,
    sysadm.PS_JRNL_LN B,
    sysadm.PS_BI_ACCT_ENTRY C,
    sysadm.PS_BI_LINE D,
    sysadm.PS_BI_HDR E
    WHERE A.BUSINESS_UNIT = '&BU'
    AND A.JOURNAL_DATE BETWEEN TO_DATE('&From_date','YYYY-MM-DD')
    AND TO_DATE('&To_date','YYYY-MM-DD')
    AND A.SOURCE      = 'BI'
    AND A.BUSINESS_UNIT = B.BUSINESS_UNIT
    AND A.JOURNAL_ID      = B.JOURNAL_ID
    AND A.JOURNAL_DATE = B.JOURNAL_DATE
    AND A.UNPOST_SEQ      = B.UNPOST_SEQ
    AND B.BUSINESS_UNIT = C.BUSINESS_UNIT
    AND B.JOURNAL_ID = C.JOURNAL_ID
    AND B.JOURNAL_DATE = C.JOURNAL_DATE
    AND B.JOURNAL_LINE = C.JOURNAL_LINE
    AND C.ACCT_ENTRY_TYPE = 'RR'
    AND C.BUSINESS_UNIT = '&BU'
    AND C.BUSINESS_UNIT = D.BUSINESS_UNIT
    AND C.INVOICE = D.INVOICE
    AND C.LINE_SEQ_NUM = D.LINE_SEQ_NUM
    AND D.BUSINESS_UNIT = '&BU'
    AND D.BUSINESS_UNIT = E.BUSINESS_UNIT
    AND D.INVOICE = E.INVOICE
    AND E.BUSINESS_UNIT = '&BU'
    AND
    ((c.account in ('30120000','30180050','30190000','30290000','30490000',
    '30690000','30900040','30990000','35100000','35120000','35150000','35160000',
    '39100050','90100000')
    and D.TAX_CD_VAT_PCT <> 0)
    OR
    (c.account not in ('30120000','30180050','30190000','30290000','30490000',
    '30690000','30900040','30990000','35100000','35120000','35150000','35160000',
    '39100050','z')
    and D.TAX_CD_VAT_PCT <> 25)
    GROUP BY
    A.BUSINESS_UNIT,
    A.JOURNAL_ID,
    TO_CHAR(A.JOURNAL_DATE,'YYYY-MM-DD'),
    A.UNPOST_SEQ, A.FISCAL_YEAR,
    A.ACCOUNTING_PERIOD,
    A.JRNL_HDR_STATUS,
    C.INVOICE,
    C.ACCT_ENTRY_TYPE,
    C.LINE_DST_SEQ_NUM,
    C.TAX_AUTHORITY_CD,
    C.ACCOUNT,
    D.BILL_SOURCE_ID,
    D.IDENTIFIER,
    D.VAT_TXN_TYPE_CD,
    D.TAX_CD_VAT,
    D.TAX_CD_VAT_PCT,
    D.VAT_APPLICABILITY,
    E.BILL_TO_CUST_ID,
    E.BILL_STATUS,
    E.BILL_CYCLE_ID,
    TO_CHAR(E.INVOICE_DT,'YYYY-MM-DD'),
    TO_CHAR(E.ACCOUNTING_DT,'YYYY-MM-DD'),
    TO_CHAR(E.DT_INVOICED,'YYYY-MM-DD'),
    E.ENTRY_TYPE, E.ENTRY_REASON,
    E.AR_LVL, E.AR_DST_OPT,
    E.AR_ENTRY_CREATED,
    E.GEN_AR_ITEM_FLG,
    E.GL_LVL,
    E.GL_ENTRY_CREATED,
    C.MONETARY_AMOUNT,
    D.VAT_AMT_BSE,
    D.VAT_TRANS_AMT_BSE
    having
    (Case when c.account in ('30120000','30180050','30190000','30290000',
    '30490000','30690000','30900040','30990000','35100000','35120000','35150000',
    '35160000','39100050','90100000')
    and D.TAX_CD_VAT_PCT <> 0 then 'Ej_Momskonto_med_moms'
    When c.account not in ('30120000','30180050','30190000','30290000','30490000',
    '30690000','30900040','30990000','35100000','35120000','35150000','35160000',
    '39100050','90100000')
    and D.TAX_CD_VAT_PCT <> 25 then 'Momskonto_utan_moms' end) is not null
    So Could you provide the solution to fix this issue?
    Thanks
    senthil

    [url http://forums.oracle.com/forums/thread.jspa?threadID=501834&tstart=0]When your query takes too long ...
    Regards,
    Rob.

  • LINQ query taking long time

    Following query i write it returns me 1400 records. and below line taking much time.
    1.5 second taken by
        count = quer != null ? quer.Count() : 0;
    and 2 sec taken by
        candidateList = quer.Skip((pageIndex - 1) * pageSize).Take(pageSize).ToList();
    Please suggest.

    Hi Jon,
    In SharePoint, I suggest you use CAML Query. If you use Linq, the performance won't be gurantteed.
    For the first query, you can use SPQury.Count to achieve it, for the second query, you can build a proper CAML to filter the data.
    Here are some detailed articles for your reference:
    SPList.GetItems method (SPQuery)
    SPQuery.Query Property
    Zhengyu Guo
    TechNet Community Support

  • Calculations in query taking long time and to load target table

    Hi,
    I am pulling approx 45 Million records using the below query in a ssis package which pulls from one DB on one server and loading the results to another target table on the another server. In the select query I have a calculation for 6 columns. The target
    table is trunctaed and loaded every day. Also most of the columns in the source which I used for the calculations is having 0 and it took approximately 1 hour 45 min to load the target table. Is there any way to reduce the load time? Also can I do the calcultions
    after once all the 47 M records loaded during query running and then calculate for the non zero records alone?
    SELECT T1.Col1,
    T1.Col2,
    T1.Col3,
    T2.Col1,
    T2.Col2,
    T3.Col1,
    convert( numeric(8,5), (convert( numeric,T3.COl2) / 1000000)) AS Colu2,
    convert( numeric(8,5), (convert( numeric,T3.COl3) / 1000000)) AS Colu3,
    convert( numeric(8,5), (convert( numeric,T3.COl4) / 1000000)) AS Colu4,
    convert( numeric(8,5),(convert( numeric, T3.COl5) / 1000000)) AS Colu5,
    convert( numeric(8,5), (convert( numeric,T3.COl6) / 1000000)) AS Colu6,
    convert( numeric(8,5), (convert( numeric,T3.COl7) / 1000000)) AS Colu7,
    FROM Tab1 T1 
    JOIN Tab2 T2
    ON (T1.Col1 = T2.Col1)
    JOIN Tab3 T3
    ON (Tab3.Col9 =Tab3.Col9)
    Anand

    So 45 or 47? Nevertheless ...
    This is hardly a heavy calculation, the savings will be dismal. Also anything numeric is very easy on CPU in general.
    But
    convert( numeric(8,5), (convert( numeric,T3.COl7) / 1000000))
    is not optimal.
    CONVERT( NUMERIC(8,5),300 / 1000000.00000 )
    Is
    Now it boils to how to make load faster: do it in parallel. Find how many sockets the machine have and split the table into as many chunks. Also profile to find out where it spends most of the time. I saw sometimes the network is not letting me thru so you
    may want to play with buffers, and packet sizes, for example if OLEDB used increase the packet size two times see if works faster, then x2 more and so forth.
    To help you further you need to tell more e.g. what is this source, destination, how you configured the load.
    Please understand that there is no Silver Bullet anywhere, or a blanket solution, and you need to tell me your desired load time. E.g. if you tell me it needs to load in 5 min I will give your ask a pass.
    Arthur
    MyBlog
    Twitter

  • QUERY taking longer time than usual

    Hello Gurus,
    The query below used to take 5-10 minutes depending on the resource availability, but this time it is taking 4-5 hrs to complete this transaction.
    INSERT /*+ APPEND */ INTO TAG_STAGING
    SELECT /*+ INDEX(A,ALL_tags_INDX1) */
    DISTINCT TRIM (serial) serial_num,
    TRIM (COMPANY_numBER) COMPANY_NUM,
    TRIM (PERSON_id) PERSON_id
    FROM ALL_tags@DWDB_link a
    WHERE serviceS IN (SELECT /*+ INDEX(B,service_CODES_INDX2) */
    services
    FROM service_CODES b
    WHERE srvc_cd = 'R')
    AND (ORDERDATE_date BETWEEN TO_DATE ('01-JAN-2007','dd-mon-yyyy')
    AND TO_DATE ('31-DEC-2007','dd-mon-yyyy'))
    AND ( (TRIM (status_1) IS NULL)
    OR (TRIM (status_1) = 'R')
    AND (TRIM (status_2) = 'R' OR TRIM (status_2) IS NULL)
    TAG_STAGING table is empty with primary key on the three given columns
    ALL_tags@DWDB_link table has about 100M rows
    Ideally the query should fetch about 4M rows.
    Could any one please give me an idea as to how to proceed to quicken the process.
    Thanks in advance
    Thanks,
    TT

    First I'd check the explain plan to make sure that it makes sense. Perhaps an index was dropped or perhaps the stats are wrong for some reason.
    If the explain plan looks good then I'd trace it and see where the time is being spent.

  • SELECT query taking long time

    Hi All,
    I am trying to run one SELECT statement which uses 6 tables. That query generally take 25-30 minutes to generate output.
    Today it is running from more than 2 hours. I have checked there are no locks on those tables and no other process is using them.
    What else I should check in order to figure out why my SELECT statement is taking time?
    Any help will be much appreciated.
    Thanks!

    Please let me know if you still want me to provide all the information mentioned in the link.Yes, please.
    Before you can even start optimizing, it should be clear what parts of the query are running slow.
    The links contains the steps to take regarding how to identify the things that make the query run slow.
    Ideally you post a trace/tkprof report with wait events, it'll show on what time is being spent, give an execution plan and a database version all in once...
    Today it is running from more than 2 hours. I have checked there are no locks on those tables and no other process is using them.Well, something must have changed.
    And you must indentify what exactly has changed, but it's a broad range you have to check:
    - it could be outdated table statistics
    - it could be data growth or skewness that makes Optimizer choose a wrong plan all of a sudden
    - it could be a table that got modified with some bad index
    - it could be ...
    So, by posting the information in the link, you'll leave less room for guesses from us, so you'll get an explanation that makes sense faster or, while investigating by following the steps in the link, you'll get the explanation yourself.

  • Alter table query taking more time

    Hi,
    My table T1 contains lots of data and when I am trying to run the below query its taking around 1 hour to update and some times its hanging.
    "ALTER TABLE T1 ADD COLUMN C1 INTEGER DEFAULT 1 NOT NULL;"
    How we can resolve this? Any help
    Thanks,
    Sankar

    My table T1 contains lots of data and when I am
    trying to run the below query its taking around 1
    hour to updateYes, it's normal, if it's a big table.Oracle has to update every record in your table.
    and some times its hanging.How Do you know that it hangs?

Maybe you are looking for