Query takes long when using UNION

Hi ,
I habe a query as follows;
SELECT
                    '9999' site_id,
                    m.ghi_prov_num provnum,
                       SUBSTR (l.seq_num, 1, 3)provloc,
                    t.dea_number dea,
                        t.license_number statelicensenumber ,
                        n.npi_num npi,
                        m.prefix prefixname,
                        m.lastname lastname,
                        m.firstname firstname,
                        t.middle_name middleinitial,
                        m.suffix suffixname,
                        null clinicname,
                        l.street1 addressline1,
                        l.street2 addressline2,
                        l.city city,
                        l.state state,
                        l.zip5 zip,
                        l.phone phoneprimary,
                        null ext,
                        null fax,
                        null email,
                        null alt_phone,
                        null alt_phone_ext
                 FROM provider m, LOCATION l, npi n,TEMP_VITAL_CACTUS t,test_provider_pin pin
                  WHERE m.ghi_prov_num=l.ghi_prov_num
                      and m.ghi_prov_num=n.ghi_prov_num(+)
                      and m.ghi_prov_num=t.ghi_prov_num(+)
                      and m.tax_id=pin.tax_id
     UNION
      SELECT   
                    '9999', m.ghi_prov_num ,
                        m.location provloc,
                       null  ,
                       null  ,
                        n.npi_num  ,
                        null ,
                        m.lastname ,
                        m.firstname  ,
                        null,
                        null  ,
                        null  ,
                        m.street1  ,
                        m.street2  ,
                        m.city ,
                        m.state  ,
                        m.zip5 ,
                        m.phone  ,
                        null  ,
                        null  ,
                        null  ,
                        null  ,
                        null
                       FROM dental_provider m, npi n,test_provider_pin pin
                   WHERE m.ghi_prov_num=n.tax_id(+)
                       and m.location=n.location(+)
                        and pin.tax_id=m.ghi_prov_num;The query takes for ever;
But Individual query takes less than a sec to execute.Is there any way can i rewrite the query?
Please help
Hena.

user11253970 wrote:
But Individual query takes less than a sec to execute.Is there any way can i rewrite the query?Have a feeling you are using Toad/SQL Navigator or similar tool which returns data one screen at a time. If so, then it does not "takes less than a sec to execute" but rather to fetch first screen of rows. When you use UNION Oracle has to return distinct rows from both queries. Therefore it must fetch not just first screen but all rows. To verify, issue first query and in yiour GUI tool click on get last screen. Then you'll know how long whole select takes. Do the same for second query. Also, do you need distinct rows or akll rows? IF all rows, change UNION to UNION ALL.
SY.

Similar Messages

  • Why update query takes  long time ?

    Hello everyone;
    My update query takes long time.  In  emp  ( self testing) just  having 2 records.
    when i issue update query , it takes long time;
    SQL> select  *  from  emp;
      EID  ENAME     EQUAL     ESALARY     ECITY    EPERK       ECONTACT_NO
          2   rose              mca                  22000   calacutta                   9999999999
          1   sona             msc                  17280    pune                          9999999999
    Elapsed: 00:00:00.05
    SQL> update emp set esalary=12000 where eid='1';
    update emp set esalary=12000 where eid='1'
    * ERROR at line 1:
    ORA-01013: user requested cancel of current operation
    Elapsed: 00:01:11.72
    SQL> update emp set esalary=15000;
    update emp set esalary=15000
      * ERROR at line 1:
    ORA-01013: user requested cancel of current operation
    Elapsed: 00:02:22.27

    Hi  BCV;
    Thanks for your reply but it doesn't provide output,  please  see   this.
    SQL> update emp set esalary=15000;
    ........... Lock already occured.
    >> trying to trace  >>
    SQL> select HOLDING_SESSION from dba_blockers;
    HOLDING_SESSION
                144
    SQL> select sid , username, event from v$session where username='HR';
    SID USERNAME     EVENT
       144   HR    SQL*Net message from client
       151   HR    enq: TX - row lock contention
       159   HR    SQL*Net message from client
    >> It  does n 't  provide  clear output about  transaction lock >>
    SQL> SELECT username, v$lock.SID, TRUNC (id1 / POWER (2, 16)) rbs,
      2  BITAND (id1, TO_NUMBER ('ffff', 'xxxx')) + 0 slot, id2 seq, lmode,
      3  request
      4  FROM v$lock, v$session
      5  WHERE v$lock.TYPE = 'TX'
      6  AND v$lock.SID = v$session.SID
      7  AND v$session.username = USER;
      no rows selected
    SQL> select MACHINE from v$session where sid = :sid;
    SP2-0552: Bind variable "SID" not declared.

  • Query take long time in fetching when used within a procedure

    The Database is : Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
    Query just takes a second from toad but when used inside a procedure as a cursor it takes takes 3 to 5 minutes.
    Following is the Tkprof information when running from procedure.
    SELECT CHCLP.CLM_PRVDR_TYPE_LKPCD, CHCLP.PRVDR_LCTN_IID, TO_CHAR
    (CHCLP.MODIFIED_DATE, 'MM-dd-yyyy hh24:mi:ss') MODIFIED_DATE,
    CHCLP.PRVDR_LCTN_IDENTIFIER, CHCLP.CLM_HDR_CLM_LN_X_PVDR_LCTN_SID
    FROM
    CLM_HDR_CLM_LN_X_PRVDR_LCTN CHCLP WHERE CHCLP.CLAIM_HEADER_SID = :B1 AND
    CHCLP.CLAIM_LINE_SID IS NULL AND CHCLP.IDNTFR_TYPE_CID = 7
    call count cpu elapsed disk query current rows
    Parse 0 0.00 0.00 0 0 0 0
    Execute 1 0.00 0.00 0 0 0 0
    Fetch 1 110.79 247.79 568931 576111 0 3
    total 2 110.79 247.79 568931 576111 0 3
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 93 (CMSAPP) (recursive depth: 1)
    Rows     Execution Plan
    0 SELECT STATEMENT MODE: ALL_ROWS
    0 PARTITION RANGE (SINGLE) PARTITION:KEYKEY
    0 TABLE ACCESS MODE: ANALYZED (BY LOCAL INDEX ROWID) OF
    'CLM_HDR_CLM_LN_X_PRVDR_LCTN' (TABLE) PARTITION:KEYKEY
    0 INDEX MODE: ANALYZED (RANGE SCAN) OF
    'XAK1CLM_HDR_CLM_LN_X_PRVDR_LCT' (INDEX (UNIQUE))
    PARTITION:KEYKEY
    Execution plan when running just the query from TOAD is: (it comes out in a second)
    Plan
    SELECT STATEMENT ALL_ROWSCost: 6 Bytes: 100 Cardinality: 2                
         3 PARTITION RANGE SINGLE Cost: 6 Bytes: 100 Cardinality: 2 Partition #: 1 Partitions accessed #13          
              2 TABLE ACCESS BY LOCAL INDEX ROWID TABLE CMSAPP.CLM_HDR_CLM_LN_X_PRVDR_LCTN Cost: 6 Bytes: 100 Cardinality: 2 Partition #: 2 Partitions accessed #13     
    Why would fetching take such a long time? Please let me know if you need any other information.
    Thank You.
    Edited by: spur230 on Apr 1, 2009 10:23 AM
    Edited by: spur230 on Apr 1, 2009 10:26 AM
    Edited by: spur230 on Apr 1, 2009 10:28 AM
    Edited by: spur230 on Apr 1, 2009 10:30 AM

    Query just takes a second from toad It's possible that the query starts returning rows in a second, but that's not the time required for the entire query.

  • Cannot export query output when using UNION ALL

    Hi
    I can run a query in SQL Developer 1.5.5 and if it's a SELECT statement it works fine, but if I output the result of several SELECT statements using UNION ALL after some 10,000 records the SQL Developer crashes and it generates a file whose size is 0 kb
    Is there a workaround for this??
    Thanks and Regards!
    Isaac

    Should be fixed in the upcoming 2.1... you can try the RC1 also...
    Regards,
    K.

  • Why NL instead of HJ(query takes long)

    Hi there!
    There are a db(10.2.0.5 RAC), SLES 10 and two schemes.In the first schema query takes very fast:
    SQL> explain plan for
                 select  count(distinct c.unit)
               from quantity_comp_v qc, comps c, noticequant nq, notices_table n,    noticediss nd
                  where
                  c.id = qc.comp
                  and nq.quant = qc.quantity
                  and n.id = nq.note
                  and n.type_id = 2
                       and nq.link = 2
                  and nd.note = n.id
                  and n.trust >=0
                and nd.dis in (select dr.dismbr from disrelflat dr where dr.disgrp = 1080801245);
    Explained.
    Elapsed: 00:00:00.27
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 2567928671
    | Id  | Operation                              | Name                           | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                       |                                |     1 |    91 |       |  2099   (4)| 00:00:07 |
    |   1 |  SORT GROUP BY                         |                                |     1 |    91 |       |            |          |
    |*  2 |   HASH JOIN                            |                                | 55203 |  4905K|       |  2099   (4)| 00:00:07 |
    |*  3 |    INDEX RANGE SCAN                    | DISRELFLAT_UI_DISGRP_DISMBR    | 10618 |   155K|       |    54   (2)| 00:00:01 |
    |*  4 |    HASH JOIN                           |                                | 42398 |  3146K|  2984K|  2043   (4)| 00:00:06 |
    |*  5 |     HASH JOIN                          |                                | 42398 |  2484K|       |  1262   (4)| 00:00:04 |
    |*  6 |      HASH JOIN                         |                                | 24173 |  1109K|       |  1022   (4)| 00:00:03 |
    |*  7 |       HASH JOIN                        |                                | 21471 |   650K|       |   951   (3)| 00:00:03 |
    |*  8 |        VIEW                            | index$_join$_004               | 21471 |   314K|       |   783   (3)| 00:00:03 |
    |*  9 |         HASH JOIN                      |                                |       |       |       |            |          |
    |* 10 |          INDEX RANGE SCAN              | NOTICES_TABLE_I_TYPE_ID_TRUST_ | 21471 |   314K|       |   141   (5)| 00:00:01 |
    |  11 |          INDEX FAST FULL SCAN          | NOTICES_TABLE_PK               | 21471 |   314K|       |   832   (2)| 00:00:03 |
    |  12 |        INDEX FAST FULL SCAN            | NOTICEDISS_UI_NOTE_DIS         |   169K|  2647K|       |   162   (4)| 00:00:01 |
    |* 13 |       TABLE ACCESS FULL                | NOTICEQUANT                    | 38141 |   595K|       |    69   (5)| 00:00:01 |
    |  14 |      VIEW                              |                                | 88786 |  1127K|       |   236   (3)| 00:00:01 |
    |  15 |       SORT UNIQUE                      |                                |       |       |       |            |          |
    |  16 |        UNION-ALL                       |                                |       |       |       |            |          |
    |* 17 |         HASH JOIN                      |                                | 23140 |  1355K|       |   130   (8)| 00:00:01 |
    |  18 |          INDEX FAST FULL SCAN          | QUANTITIES_I_ID_OP             | 50822 |   397K|       |    51   (4)| 00:00:01 |
    |* 19 |          HASH JOIN                     |                                | 23057 |  1170K|       |    76   (7)| 00:00:01 |
    |  20 |           INDEX FAST FULL SCAN         | QOPNC_I_ALL                    | 37964 |   481K|       |    55   (2)| 00:00:01 |
    |  21 |           VIEW                         |                                | 23057 |   878K|       |    18   (6)| 00:00:01 |
    |* 22 |            CONNECT BY WITHOUT FILTERING|                                |       |       |       |            |          |
    |  23 |             TABLE ACCESS FULL          | QOPNQ                          | 23057 |   225K|       |    18   (6)| 00:00:01 |
    |* 24 |         HASH JOIN                      |                                | 38100 |   781K|       |   109   (6)| 00:00:01 |
    |  25 |          INDEX FAST FULL SCAN          | QOPNC_I_ALL                    | 37964 |   481K|       |    55   (2)| 00:00:01 |
    |  26 |          INDEX FAST FULL SCAN          | QUANTITIES_I_ID_OP             | 50822 |   397K|       |    51   (4)| 00:00:01 |
    |  27 |     TABLE ACCESS FULL                  | COMPS                          |   218K|  3406K|       |   282   (4)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("ND"."DIS"="DR"."DISMBR")
       3 - access("DR"."DISGRP"=1080801245)
       4 - access("C"."ID"="COMP")
       5 - access("NQ"."QUANT"="ID")
       6 - access("NQ"."NOTE"="N"."ID")
       7 - access("ND"."NOTE"="N"."ID")
       8 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
       9 - access(ROWID=ROWID)
      10 - access("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
      13 - filter("NQ"."LINK"=2)
      17 - access("ID"="RT")
      19 - access("QOP"="QUANTITY")
      22 - access("QUANTITY"=PRIOR "QOP")
      24 - access("ID"="QUANTITY")
    52 rows selected.
    Elapsed: 00:00:00.06
    SQL> In second schema query takes very long:
    PLAN_TABLE_OUTPUT
    Plan hash value: 543063124
    | Id  | Operation                             | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                      |                             |     1 |    92 |   333   (2)| 00:00:01 |
    |   1 |  SORT GROUP BY                        |                             |     1 |    92 |            |          |
    |   2 |   NESTED LOOPS                        |                             |    91 |  8372 |   333   (2)| 00:00:01 |
    |   3 |    NESTED LOOPS                       |                             |    91 |  6916 |   241   (2)| 00:00:01 |
    |   4 |     NESTED LOOPS                      |                             |    52 |  3276 |   189   (2)| 00:00:01 |
    |   5 |      NESTED LOOPS                     |                             |    47 |  2209 |   123   (3)| 00:00:01 |
    |*  6 |       HASH JOIN                       |                             |    81 |  2592 |    42   (8)| 00:00:01 |
    |*  7 |        INDEX RANGE SCAN               | DISRELFLAT_UI_DISGRP_DISMBR |    18 |   288 |     2   (0)| 00:00:01 |
    |   8 |        INDEX FAST FULL SCAN           | NOTICEDISS_UI_NOTE_DIS      | 38127 |   595K|    38   (3)| 00:00:01 |
    |*  9 |       TABLE ACCESS BY INDEX ROWID     | NOTICES_TABLE               |     1 |    15 |     1   (0)| 00:00:01 |
    |* 10 |        INDEX UNIQUE SCAN              | NOTICES_TABLE_PK            |     1 |       |     0   (0)| 00:00:01 |
    |* 11 |      TABLE ACCESS BY INDEX ROWID      | NOTICEQUANT                 |     1 |    16 |     3   (0)| 00:00:01 |
    |* 12 |       INDEX RANGE SCAN                | NOTICEQUANT_UI_NOTE_QUANT   |     1 |       |     1   (0)| 00:00:01 |
    |  13 |     VIEW                              |                             |     2 |    26 |     1   (0)| 00:00:01 |
    |  14 |      SORT UNIQUE                      |                             |       |       |            |          |
    |  15 |       UNION-ALL PARTITION             |                             |       |       |            |          |
    |  16 |        NESTED LOOPS                   |                             |     1 |    60 |    19   (6)| 00:00:01 |
    |  17 |         NESTED LOOPS                  |                             |     1 |    47 |    18   (6)| 00:00:01 |
    |* 18 |          INDEX RANGE SCAN             | QUANTITIES_UI_ID_OP         |     1 |     8 |     2   (0)| 00:00:01 |
    |* 19 |          VIEW                         |                             |     1 |    39 |    16   (7)| 00:00:01 |
    |* 20 |           CONNECT BY WITHOUT FILTERING|                             |       |       |            |          |
    |  21 |            TABLE ACCESS FULL          | QOPNQ                       | 19811 |   193K|    16   (7)| 00:00:01 |
    |* 22 |         INDEX RANGE SCAN              | QOPNC_UI_QUANTITY_NUM_COMP  |     1 |    13 |     1   (0)| 00:00:01 |
    |  23 |        NESTED LOOPS                   |                             |     1 |    21 |     3   (0)| 00:00:01 |
    |* 24 |         INDEX RANGE SCAN              | QUANTITIES_UI_ID_OP         |     1 |     8 |     2   (0)| 00:00:01 |
    |* 25 |         INDEX RANGE SCAN              | QOPNC_UI_QUANTITY_NUM_COMP  |     1 |    13 |     1   (0)| 00:00:01 |
    |  26 |    TABLE ACCESS BY INDEX ROWID        | COMPS                       |     1 |    16 |     1   (0)| 00:00:01 |
    |* 27 |     INDEX UNIQUE SCAN                 | COMPS_UI_ID                 |     1 |       |     0   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       6 - access("ND"."DIS"="DR"."DISMBR")
       7 - access("DR"."DISGRP"=1080801245)
       9 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
      10 - access("ND"."NOTE"="N"."ID")
      11 - filter("NQ"."LINK"=2)
      12 - access("NQ"."NOTE"="N"."ID")
      18 - access("ID"="NQ"."QUANT")
      19 - filter("ID"="RT" AND "RT"="NQ"."QUANT")
      20 - access("QUANTITY"=PRIOR "QOP")
      22 - access("QOP"="QUANTITY")
      24 - access("ID"="NQ"."QUANT")
      25 - access("QUANTITY"="NQ"."QUANT")
           filter("ID"="QUANTITY")
      27 - access("C"."ID"="COMP")As you can see, plans are different. Why? Statistics is up-to-date in both schemas.
    In tkprof trace for the second schema i see strange thing:
    select count(distinct c.unit)
    from quantity_comp_v qc, comps c, noticequant nq, notices_table n,
    noticediss nd
    where
    c.id = qc.comp
    and nq.quant = qc.quantity
    and n.id = nq.note
    and n.type_id = 2
    and nq.link = 2
    and nd.note = n.id
    and n.trust >=0
    and nd.dis in (select dr.dismbr from disrelflat dr where dr.disgrp = 1080801245)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.02       0.02          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        2    558.36     545.39          1     845921          0           1
    total        4    558.38     545.42          1     845921          0           1
    Misses in library cache during parse: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 156
    Rows     Row Source Operation
          1  SORT GROUP BY (cr=845921 pr=1 pw=0 time=545397464 us)
      13865   NESTED LOOPS  (cr=845921 pr=1 pw=0 time=546471010 us)
      13865    NESTED LOOPS  (cr=818189 pr=1 pw=0 time=546290764 us)
      13308     HASH JOIN  (cr=31053 pr=1 pw=0 time=172231 us)
      13308      NESTED LOOPS  (cr=30863 pr=0 pw=0 time=126100 us)
      15326       HASH JOIN  (cr=209 pr=0 pw=0 time=21640 us)
      11522        INDEX RANGE SCAN DISRELFLAT_UI_DISGRP_DISMBR (cr=68 pr=0 pw=0 time=40 us)(object id 634347)
      37432        INDEX FAST FULL SCAN NOTICEDISS_UI_NOTE_DIS (cr=141 pr=0 pw=0 time=50 us)(object id 638914)
      13308       TABLE ACCESS BY INDEX ROWID NOTICES_TABLE (cr=30654 pr=0 pw=0 time=95620 us)
      15326        INDEX UNIQUE SCAN NOTICES_TABLE_PK (cr=15328 pr=0 pw=0 time=41398 us)(object id 638937)
      34391      TABLE ACCESS FULL NOTICEQUANT (cr=190 pr=1 pw=0 time=53 us)
      13865     VIEW  (cr=787136 pr=0 pw=0 time=544908246 us)
      13865      SORT UNIQUE (cr=787136 pr=0 pw=0 time=544893509 us)
      13950       UNION-ALL PARTITION (cr=787136 pr=0 pw=0 time=539509573 us)
       1223        NESTED LOOPS  (cr=733813 pr=0 pw=0 time=539271493 us)
       1233         NESTED LOOPS  (cr=731971 pr=0 pw=0 time=539245389 us)
      13308          INDEX RANGE SCAN QUANTITIES_UI_ID_OP (cr=26647 pr=0 pw=0 time=120240 us)(object id 634738)
       1233          VIEW  (cr=705324 pr=0 pw=0 time=539109785 us)
    275435676           CONNECT BY WITHOUT FILTERING (cr=705324 pr=0 pw=0 time=493869861 us)
    263644788            TABLE ACCESS FULL QOPNQ (cr=705324 pr=0 pw=0 time=163378 us)
       1223         INDEX RANGE SCAN QOPNC_UI_QUANTITY_NUM_COMP (cr=1842 pr=0 pw=0 time=10296 us)(object id 634729)
      12727        NESTED LOOPS  (cr=53323 pr=0 pw=0 time=216730 us)
      13308         INDEX RANGE SCAN QUANTITIES_UI_ID_OP (cr=26647 pr=0 pw=0 time=111770 us)(object id 634738)
      12727         INDEX RANGE SCAN QOPNC_UI_QUANTITY_NUM_COMP (cr=26676 pr=0 pw=0 time=84638 us)(object id 634729)
      13865    TABLE ACCESS BY INDEX ROWID COMPS (cr=27732 pr=0 pw=0 time=235066 us)
      13865     INDEX UNIQUE SCAN COMPS_UI_ID (cr=13867 pr=0 pw=0 time=128663 us)(object id 634315)
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      SQL*Net message to client                       2        0.00          0.00
      gc current block 3-way                        208        0.00          0.08
      gc current block 2-way                         93        0.00          0.02
      gc cr multi block request                     150        0.00          0.01
      db file sequential read                         1        0.01          0.01
      SQL*Net message from client                     2        0.00          0.00
    ********************************************************************************Cardinality of QOPNQ not real (over 263 millions rows instead of 19 thousands). If i set optimizer_index_cost_adj=400, plan uses HJ and cardinality in tkprof trace is right. Thanks in advance.
    Best regards, Pavel.

    Hi there.
    What I found:
    In schema, where optimizer uses NL:
    SQL> select TABLE_NAME,COLUMN_NAME,NUM_BUCKETS,LAST_ANALYZED from user_tab_col_statistics where table_name in ('DISRELFLAT','NOTICES_TABLE','QOPNQ','COMPS');
    TABLE_NAME           COLUMN_NAME      NUM_BUCKETS LAST_ANALYZED
    COMPS                ID                       254 31-JUL-10
    COMPS                UNIT                     254 31-JUL-10
    COMPS                LOC                       34 31-JUL-10
    COMPS                TIS                      246 31-JUL-10
    COMPS                RTYP                       2 31-JUL-10
    DISRELFLAT           DISGRP                   254 31-JUL-10
    DISRELFLAT           DISMBR                   254 31-JUL-10
    DISRELFLAT           CNT                      174 31-JUL-10
    DISRELFLAT           SPL                       10 31-JUL-10
    DISRELFLAT           DIST                      16 31-JUL-10
    DISRELFLAT           PART                       2 31-JUL-10
    DISRELFLAT           ISA                        2 31-JUL-10
    DISRELFLAT           MIX                        2 31-JUL-10
    DISRELFLAT           CLONAL                     1 31-JUL-10
    NOTICES_TABLE        ID                         1 08-SEP-10
    NOTICES_TABLE        TEXT                       1 08-SEP-10
    NOTICES_TABLE        DESCRIPTION                1 08-SEP-10
    NOTICES_TABLE        TYPE_ID                    4 08-SEP-10
    NOTICES_TABLE        CUSER_ID                   1 08-SEP-10
    NOTICES_TABLE        CDATE                      1 08-SEP-10
    NOTICES_TABLE        TRUST                     10 08-SEP-10
    NOTICES_TABLE        RTYP                       2 08-SEP-10
    NOTICES_TABLE        CHECKEDBY                  1 08-SEP-10
    NOTICES_TABLE        FEATURE_ID                13 08-SEP-10
    QOPNQ                QUANTITY                   1 31-JUL-10
    QOPNQ                NUM                       12 31-JUL-10
    QOPNQ                QOP                        1 31-JUL-10
    27 rows selected.In schema where optimizer uses HJ:
    TABLE_NAME           COLUMN_NAME      NUM_BUCKETS LAST_ANALYZED
    COMPS                ID                       254 28-JUL-10
    COMPS                UNIT                     254 28-JUL-10
    COMPS                LOC                       29 28-JUL-10
    COMPS                TIS                      223 28-JUL-10
    COMPS                RTYP                       2 28-JUL-10
    DISRELFLAT           DISGRP                   254 21-AUG-10
    DISRELFLAT           DISMBR                     1 21-AUG-10
    DISRELFLAT           CNT                      103 21-AUG-10
    DISRELFLAT           SPL                       10 21-AUG-10
    DISRELFLAT           DIST                      11 21-AUG-10
    DISRELFLAT           PART                       2 21-AUG-10
    DISRELFLAT           ISA                        2 21-AUG-10
    DISRELFLAT           MIX                        2 21-AUG-10
    DISRELFLAT           CLONAL                     2 21-AUG-10
    NOTICES_TABLE        ID                         1 09-AUG-10
    NOTICES_TABLE        TEXT                     254 09-AUG-10
    NOTICES_TABLE        DESCRIPTION              254 09-AUG-10
    NOTICES_TABLE        TYPE_ID                    4 09-AUG-10
    NOTICES_TABLE        CUSER_ID                   1 09-AUG-10
    NOTICES_TABLE        CDATE                    254 09-AUG-10
    NOTICES_TABLE        TRUST                      9 09-AUG-10
    NOTICES_TABLE        RTYP                       2 09-AUG-10
    NOTICES_TABLE        CHECKEDBY                  1 09-AUG-10
    NOTICES_TABLE        FEATURE_ID                21 09-AUG-10
    QOPNQ                QUANTITY                   1 28-JUL-10
    QOPNQ                NUM                       10 28-JUL-10
    QOPNQ                QOP                        1 28-JUL-10
    27 rows selected.Then i gathered statistics with estimate_percent=>null,method_opt=>'for all columns size 1'(without histogramms).
    Plan became:
    PLAN_TABLE_OUTPUT
    Plan hash value: 2184582790
    | Id  | Operation                             | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                      |                             |     1 |    91 |   969   (4)| 00:00:03 |
    |   1 |  SORT GROUP BY                        |                             |     1 |    91 |            |          |
    |*  2 |   HASH JOIN                           |                             |   689 | 62699 |   969   (4)| 00:00:03 |
    |*  3 |    HASH JOIN                          |                             |   689 | 51675 |   719   (3)| 00:00:03 |
    |*  4 |     HASH JOIN                         |                             |   392 | 24304 |   549   (2)| 00:00:02 |
    |   5 |      NESTED LOOPS                     |                             |   377 | 17342 |   479   (1)| 00:00:02 |
    |*  6 |       HASH JOIN                       |                             |   435 | 13485 |    43   (7)| 00:00:01 |
    |*  7 |        INDEX RANGE SCAN               | DISRELFLAT_UI_DISGRP_DISMBR |    12 |   180 |     3   (0)| 00:00:01 |
    |   8 |        INDEX FAST FULL SCAN           | NOTICEDISS_UI_NOTE_DIS      | 38127 |   595K|    38   (3)| 00:00:01 |
    |*  9 |       TABLE ACCESS BY INDEX ROWID     | NOTICES_TABLE               |     1 |    15 |     1   (0)| 00:00:01 |
    |* 10 |        INDEX UNIQUE SCAN              | NOTICES_TABLE_PK            |     1 |       |     0   (0)| 00:00:01 |
    |* 11 |      TABLE ACCESS FULL                | NOTICEQUANT                 | 34306 |   536K|    69   (5)| 00:00:01 |
    |  12 |     VIEW                              |                             | 79375 |  1007K|   167   (3)| 00:00:01 |
    |  13 |      SORT UNIQUE                      |                             |       |       |            |          |
    |  14 |       UNION-ALL                       |                             |       |       |            |          |
    |* 15 |        HASH JOIN                      |                             | 19811 |  1160K|    86  (11)| 00:00:01 |
    |  16 |         INDEX FAST FULL SCAN          | QUANTITIES_UI_ID_OP         | 45161 |   352K|    33   (7)| 00:00:01 |
    |* 17 |         HASH JOIN                     |                             | 19811 |  1006K|    51  (10)| 00:00:01 |
    |  18 |          TABLE ACCESS FULL            | QOPNC                       | 34214 |   434K|    33   (7)| 00:00:01 |
    |  19 |          VIEW                         |                             | 19811 |   754K|    16   (7)| 00:00:01 |
    |* 20 |           CONNECT BY WITHOUT FILTERING|                             |       |       |            |          |
    |  21 |            TABLE ACCESS FULL          | QOPNQ                       | 19811 |   193K|    16   (7)| 00:00:01 |
    |* 22 |        HASH JOIN                      |                             | 34214 |   701K|    68   (9)| 00:00:01 |
    |  23 |         TABLE ACCESS FULL             | QOPNC                       | 34214 |   434K|    33   (7)| 00:00:01 |
    |  24 |         INDEX FAST FULL SCAN          | QUANTITIES_UI_ID_OP         | 45161 |   352K|    33   (7)| 00:00:01 |
    |  25 |    TABLE ACCESS FULL                  | COMPS                       |   212K|  3320K|   244   (5)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("C"."ID"="COMP")
       3 - access("NQ"."QUANT"="ID")
       4 - access("NQ"."NOTE"="N"."ID")
       6 - access("ND"."DIS"="DR"."DISMBR")
       7 - access("DR"."DISGRP"=1080801245)
       9 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
      10 - access("ND"."NOTE"="N"."ID")
      11 - filter("NQ"."LINK"=2)
      15 - access("ID"="RT")
      17 - access("QOP"="QUANTITY")
      20 - access("QUANTITY"=PRIOR "QOP")
      22 - access("ID"="QUANTITY")Now,query executes as fast as in first schema.
    Best regards,Pavel.
    Edited by: Pavel E.

  • Query time affected when using dimensions that are at a lower grain

    Hi all,
    I have a product dimension that has one hierarchy and 7 levels: All Product -> Category -> BU -> Class -> Department -> SubDept -> Item. The lowest level has about 8 million members. The Department level has about 1500 members
    Some of my Cubes are actually mapped to fact tables where the grain is at Department level. So I've ensured that in the Cube Mappings Editor, the Department Id of the fact table is mapped to the Department level of the Product Dimension, and I can actually see in the Cube's Aggmap, it is using LOAD_STATUS to limit the Product dimension to the Department level members for the aggregation.
    Querying the Cube using SQL brings back the correct result across different level combination, however the query constantly takes about 2 - 3 mins to complete.
    As a test, I've built another dimension that goes down to the Department level only, and issue the same query against the Cube. The difference is significant as the query takes roughly less than 1 second to complete, and returns exactly the same result.
    Any idea? I am using AWM 11.2.0.1.0A
    Thanks

    The stats you posted are puzzling. Usually the sum of loop and fetch time is close to the total time, but there is a big missing chunk of time in your case. It is clearly related to the calculated measures, since removing them solves the problem.
    The most common problem with calculated measures is that they can cause the cube to loop densely (i.e. all logical member combinations) instead of sparsely (i.e. only the member combinations that have data). But I don't think this is the problem in your case since the difference between rows_read and rows_returned is small
    ROWS_READ 212ROWS_RETURNED 185
    NULLTRACK_SUPPRESSED 27>
    If dense looping has happened then the rows_read is often orders of magnitude greater than rows_returned. You can see the looping strategy by running
    select value || ' : ' || details as loop from cube_operations_log where name = 'LOOP_OPTIMIZED'Here is an example of the output for a good (sparse) loop.
    LOOP
    ON : LOOP AGGMAP(PRICE_COST_CUBE_SOLVE_AGGMAP PRICE_COST_CUBE_PRT_TEMPLATE)Here is the output if I add a year to date calc to the cube.
    LOOP
    ON : LOOP UNION(AGGMAP(PRICE_COST_CUBE_SOLVE_AGGMAP PRICE_COST_CUBE_PRT_TEMPLATE
    ) AGGMAP(DENSE(TIME) PRICE_COST_CUBE_SOLVE_AGGMAP PRICE_COST_CUBE_PRT_TEMPLATE))Note that TIME is now looped densely, but the code is still trying to loop the other dimensions sparsely. Finally, here is the loop if I add a random olap dml calculation to the cube.
    LOOP
    DISABLED :There is now no optimized looping and the cube will be looped densely.
    So it may be worth checking the loop descriptor for your fast and slow cases, but my best guess at the moment is that the performance gap has something to do with your specific calculations. If I were you I would add them back one at a time to see if you can find a particular measure, or type of measure, that is causing the slowdown.

  • Query takes long time - Please help!

    I've a query like below (not actual query)
    update (select eds.title eds_title,edv.title edv_title from mia_data_staging eds, mia_doc_Versions edv where eds.id = edv.id and eds.title != edv.title) set edv_title = eds_title;
    In the above query I've more than 70 columns to select, compare and update (I've shown only one above). The explain plan for the query is below, which does not show any significant time, but the query never returns when executed after a long long time. Any ideas?
    Plan hash value: 2242214163
    | Id | OpMIAtion | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
    | 0 | UPDATE STATEMENT | | 1627K| 1405M| | 18E (1)| |
    | 1 | UPDATE | MIA_DOC_VERSIONS | | | | | |
    |* 2 | HASH JOIN | | 1627K| 1405M| 720M| 18E (1)| |
    | 3 | TABLE ACCESS BY INDEX ROWID | MIA_DOC_VERSIONS | 1627K| 701M| | 18E (1)| |
    | 4 | BITMAP CONVERSION TO ROWIDS| | | | | | |
    | 5 | BITMAP INDEX FULL SCAN | IDX_30 | | | | | |
    PLAN_TABLE_OUTPUT
    | 6 | TABLE ACCESS FULL | MIA_DATA_STAGING | 1628K| 705M| | 7184 (3)| 00:02:29 |
    Predicate Information (identified by operation id):
    ---------------------------------------------------

    user652494 wrote:
    I've a query like below (not actual query)
    |   3 |    TABLE ACCESS BY INDEX ROWID | MIA_DOC_VERSIONS |  1627K|   701M|       |    18E  (1)|          |
    |   4 |     BITMAP CONVERSION TO ROWIDS|                  |       |       |       |            |          |
    |   5 |      BITMAP INDEX FULL SCAN    | IDX_30           |       |       |       |            |          |This part of your execution plan looks very suspicious: It's performing a bitmap index full scan to do then a single row access by rowid apparently for all rows of the table, which seems to be a very inefficient operation. It also shows an unreasonable cost for that operation. The question is why it is not using a "full table scan" to access the MIA_DOC_VERSIONS table?
    You might want to try simply the FULL hint to request a full table scan on the MIA_DOC_VERSIONS table in order to find out how the execution plan then is going to look like:
    update (select /*+ FULL(EDV) */ eds.title eds_title,edv.title edv_title from mia_data_staging eds, mia_doc_Versions edv where eds.id = edv.id and eds.title != edv.title) set edv_title = eds_title;or
    update /*+ FULL(a.EDV) */ (select eds.title eds_title,edv.title edv_title from mia_data_staging eds, mia_doc_Versions edv where eds.id = edv.id and eds.title != edv.title) a set edv_title = eds_title;Looking at the execution plan of the hinted statement one might get a clue why the optimizer favors an index access path instead.
    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/

  • Query Takes Longer time

    SELECT CAL_EMPCALENDAR.START_DATE as main,
    bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' /' ||
    CAL_EMPCALENDAR.EMPLOYEE_ID as secondary,
    TO_DATE('1-4-2006', 'DD-MM-YYYY') as FROM_DATE,
    TO_DATE('30-4-2006', 'DD-MM-YYYY') as TO_DATE,
    bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' / ' ||
    CAL_EMPCALENDAR.EMPLOYEE_ID as name,
    CAL_EMPCALENDAR.START_DATE as sdate,
    CAL_EMPCALENDAR.OVERTIME_REASON as OTReason,
    CAL_EMPCALENDAR.POSTED_ON as POSTED_ON,
    TO_CHAR(CAL_EMPCALENDAR.START_DATE, 'Dy') as dayname,
    TAM_GET_ADJUSTED_IN(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_in,
    TAM_GET_ADJUSTED_OUT(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_out,
    CAL_EMPCALENDAR.SHIFT_ID AS SHIFT_ABBREV,
    CAL_EMPCALENDAR.LATE_IN,
    CAL_EMPCALENDAR.EARLY_OUT,
    CAL_EMPCALENDAR.UNDER_TIME,
    CAL_EMPCALENDAR.OVERTIME,
    TAM_GET_LEAVE_DESC(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'ALL') Leave,
    CAL_EMPCALENDAR.EMPLOYEE_ID as empid,
    HRM_CURR_CAREER_V.DEPARTMENT_CODE as deptcode,
    BIT_CODEDESC(HRM_CURR_CAREER_V.DEPARTMENT_CODE) as deptname,
    (SELECT shift_id
    FROM CAL_GRPWORKDAY
    WHERE CAL_GRPWORKDAY.calgrp_id =
    (SELECT calgrp_id
    FROM CAL_CALASSIGNMENT
    WHERE employee_id = CAL_EMPCALENDAR.employee_id
    AND CAL_CALASSIGNMENT.START_DATE <=
    CAL_EMPCALENDAR.START_DATE
    AND (CAL_CALASSIGNMENT.END_DATE is null or
    CAL_CALASSIGNMENT.END_DATE >=
    CAL_EMPCALENDAR.START_DATE))
    AND CAL_GRPWORKDAY.start_date = CAL_EMPCALENDAR.start_date) AS shift_id,
    (SELECT max(entry_dt)
    FROM , LV_TXN txn, CAL_EMPDAILYEVENT cale
    WHERE status = 'Approved'
    AND LV_APPSTATUSHIST.application_id = txn.application_id
    AND cale.reference_id = txn.txn_id
    AND cale.empcalendar_id = CAL_EMPCALENDAR.empcalendar_id
    ) AS entry_dt,
    (SELECT ENTITLEMENT + ADJUST
    FROM TAM_ALLOWANCE
    WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
    WF_STATUS = 'Verified' OR WF_STATUS is Null OR
    WF_STATUS = 'No Action')
    and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
    AND ITEM_ID = (SELECT ITEM_ID
    FROM TAM_CLAIM_FORMAT
    WHERE SEQUENCE = 1
    and BIZUNIT_ID like 'SG')) F1,
    --TAM_GET_ENT_AND_ADJUSTED(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'SG', 1) F1,                            
    (SELECT ENTITLEMENT + ADJUST
    FROM TAM_ALLOWANCE
    WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
    WF_STATUS = 'Verified' OR WF_STATUS is Null OR
    WF_STATUS = 'No Action')
    and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
    AND ITEM_ID = (SELECT ITEM_ID
    FROM TAM_CLAIM_FORMAT
    WHERE SEQUENCE = 2
    and bizunit_id like 'SG')) F2,
    (SELECT ENTITLEMENT + ADJUST
    FROM TAM_ALLOWANCE
    WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
    WF_STATUS = 'Verified' OR WF_STATUS is Null OR
    WF_STATUS = 'No Action')
    and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
    AND ITEM_ID = (SELECT ITEM_ID
    FROM TAM_CLAIM_FORMAT
    WHERE SEQUENCE = 3
    and bizunit_id like 'SG')) F3,
    (SELECT ENTITLEMENT + ADJUST
    FROM TAM_ALLOWANCE
    WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
    WF_STATUS = 'Verified' OR WF_STATUS is Null OR
    WF_STATUS = 'No Action')
    and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
    AND ITEM_ID = (SELECT ITEM_ID
    FROM TAM_CLAIM_FORMAT
    WHERE SEQUENCE = 4
    and bizunit_id like 'SG')) F4,
    (SELECT ENTITLEMENT + ADJUST
    FROM TAM_ALLOWANCE
    WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
    WF_STATUS = 'Verified' OR WF_STATUS is Null OR
    WF_STATUS = 'No Action')
    and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
    AND ITEM_ID = (SELECT ITEM_ID
    FROM TAM_CLAIM_FORMAT
    WHERE SEQUENCE = 5
    and bizunit_id like 'SG')) F5
    From CAL_EMPCALENDAR, HRM_CURR_CAREER_V, CAL_SHIFT, HRM_EMPLOYEE
    Where CAL_SHIFT.SHIFT_ID(+) = CAL_EMPCALENDAR.ACTUAL_SHIFT_ID
    AND (CAL_EMPCALENDAR.WF_STATUS = 'Approved' Or
    CAL_EMPCALENDAR.WF_STATUS = 'No Action')
    AND CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_EMPLOYEE.EMPLOYEE_ID
    --and CAL_EMPCALENDAR.START_DATE between TO_DATE('1-4-2006','DD-MM-YYYY') AND TO_DATE('31-4-2006','DD-MM-YYYY')
    AND CAL_EMPCALENDAR.START_DATE BETWEEN
    GREATEST(HRM_EMPLOYEE.COMMENCE_DATE,
    TO_DATE('1-4-2006', 'DD-MM-YYYY')) AND
    LEAST(TO_DATE('30-4-2006', 'DD-MM-YYYY'),
    NVL(HRM_EMPLOYEE.CESSATION_DATE,
    TO_DATE('30-4-2006', 'DD-MM-YYYY')))
    And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SG' || '%'
    And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SGTAM001'
    And CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_CURR_CAREER_V.EMPLOYEE_ID
    -- AND HRM_CURR_CAREER_V.DEPARTMENT_CODE like 'DPHR'
    --AND HRM_EMPLOYEE.EMPLOYMENT_TYPE_CODE like '$P!{EmploymentType}'
    --$P!{ExceptionSQL}
    --$P!{iHRFilterClause}
    --order by $P!{OrderBy}
    order by main
    Hi all this query takes a very long time to run.
    On the explain plan the The table in bold letter is using full tablescan rest all go for index scanning.
    Table got Indexe on those CLOMUNS REFERREED
    Oracle version 9.2.0.6
    Message was edited by:
    Maran.E
    Message was edited by:
    Maran.E

    Maran,
    With tags and indentation it should be easiest to analyze at least for you :
    SELECT CAL_EMPCALENDAR.START_DATE as main,
           bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' /' || CAL_EMPCALENDAR.EMPLOYEE_ID as secondary,
           TO_DATE('1-4-2006', 'DD-MM-YYYY') as FROM_DATE,
           TO_DATE('30-4-2006', 'DD-MM-YYYY') as TO_DATE,
           bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' / ' || CAL_EMPCALENDAR.EMPLOYEE_ID as name,
           CAL_EMPCALENDAR.START_DATE as sdate,
           CAL_EMPCALENDAR.OVERTIME_REASON as OTReason,
           CAL_EMPCALENDAR.POSTED_ON as POSTED_ON,
           TO_CHAR(CAL_EMPCALENDAR.START_DATE, 'Dy') as dayname,
           TAM_GET_ADJUSTED_IN(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_in,
           TAM_GET_ADJUSTED_OUT(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_out,
           CAL_EMPCALENDAR.SHIFT_ID AS SHIFT_ABBREV,
           CAL_EMPCALENDAR.LATE_IN,
           CAL_EMPCALENDAR.EARLY_OUT,
           CAL_EMPCALENDAR.UNDER_TIME,
           CAL_EMPCALENDAR.OVERTIME,
           TAM_GET_LEAVE_DESC(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'ALL') Leave,
           CAL_EMPCALENDAR.EMPLOYEE_ID as empid,
           HRM_CURR_CAREER_V.DEPARTMENT_CODE as deptcode,
           BIT_CODEDESC(HRM_CURR_CAREER_V.DEPARTMENT_CODE) as deptname,
           (SELECT shift_id
            FROM   CAL_GRPWORKDAY
            WHERE  CAL_GRPWORKDAY.calgrp_id = (SELECT calgrp_id
                                               FROM   CAL_CALASSIGNMENT
                                               WHERE employee_id = CAL_EMPCALENDAR.employee_id
                                               AND CAL_CALASSIGNMENT.START_DATE <= CAL_EMPCALENDAR.START_DATE
                                               AND (   CAL_CALASSIGNMENT.END_DATE is null
                                                    or CAL_CALASSIGNMENT.END_DATE >= CAL_EMPCALENDAR.START_DATE))
            AND CAL_GRPWORKDAY.start_date = CAL_EMPCALENDAR.start_date) AS shift_id,
           (SELECT max(entry_dt)
            FROM   LV_TXN txn, CAL_EMPDAILYEVENT cale
            WHERE status = 'Approved'
            AND LV_APPSTATUSHIST.application_id = txn.application_id
            AND cale.reference_id = txn.txn_id
            AND cale.empcalendar_id = CAL_EMPCALENDAR.empcalendar_id) AS entry_dt,
           (SELECT ENTITLEMENT + ADJUST
            FROM TAM_ALLOWANCE
            WHERE (   WF_STATUS = 'Pending'
                   OR WF_STATUS = 'Approved'
                   OR WF_STATUS = 'Verified'
                   OR WF_STATUS is Null
                   OR WF_STATUS = 'No Action')
            and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
            AND ITEM_ID = (SELECT ITEM_ID
                           FROM   TAM_CLAIM_FORMAT
                           WHERE  SEQUENCE = 1
                           and BIZUNIT_ID like 'SG')) F1,
           --TAM_GET_ENT_AND_ADJUSTED(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'SG', 1) F1,
           (SELECT ENTITLEMENT + ADJUST
            FROM TAM_ALLOWANCE
            WHERE (   WF_STATUS = 'Pending'
                   OR WF_STATUS = 'Approved'
                   OR WF_STATUS = 'Verified'
                   OR WF_STATUS is Null
                   OR WF_STATUS = 'No Action')
            and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
            AND ITEM_ID = (SELECT ITEM_ID
                           FROM   TAM_CLAIM_FORMAT
                           WHERE  SEQUENCE = 2
                           and    bizunit_id like 'SG')) F2,
           (SELECT ENTITLEMENT + ADJUST
            FROM   TAM_ALLOWANCE
            WHERE (   WF_STATUS = 'Pending'
                   OR WF_STATUS = 'Approved'
                   OR WF_STATUS = 'Verified'
                   OR WF_STATUS is Null
                   OR WF_STATUS = 'No Action')
            and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
            AND ITEM_ID = (SELECT ITEM_ID
                           FROM   TAM_CLAIM_FORMAT
                           WHERE SEQUENCE = 3
                           and   bizunit_id like 'SG')) F3,
           (SELECT ENTITLEMENT + ADJUST
            FROM TAM_ALLOWANCE
            WHERE (   WF_STATUS = 'Pending'
                   OR WF_STATUS = 'Approved'
                   OR WF_STATUS = 'Verified'
                   OR WF_STATUS is Null
                   OR WF_STATUS = 'No Action')
            and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
            AND ITEM_ID = (SELECT ITEM_ID
                           FROM TAM_CLAIM_FORMAT
                           WHERE SEQUENCE = 4
                           and bizunit_id like 'SG')) F4,
           (SELECT ENTITLEMENT + ADJUST
            FROM TAM_ALLOWANCE
            WHERE (   WF_STATUS = 'Pending'
                   OR WF_STATUS = 'Approved'
                   OR WF_STATUS = 'Verified'
                   OR WF_STATUS is Null
                   OR WF_STATUS = 'No Action')
            and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
            AND ITEM_ID = (SELECT ITEM_ID
                           FROM TAM_CLAIM_FORMAT
                           WHERE SEQUENCE = 5
                           and bizunit_id like 'SG')) F5
    From CAL_EMPCALENDAR,
         HRM_CURR_CAREER_V,
         CAL_SHIFT,
         HRM_EMPLOYEE
    Where CAL_SHIFT.SHIFT_ID(+) = CAL_EMPCALENDAR.ACTUAL_SHIFT_ID
    AND   (   CAL_EMPCALENDAR.WF_STATUS = 'Approved'
           Or CAL_EMPCALENDAR.WF_STATUS = 'No Action')
    AND   CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_EMPLOYEE.EMPLOYEE_ID
    --and CAL_EMPCALENDAR.START_DATE between TO_DATE('1-4-2006','DD-MM-YYYY') AND TO_DATE('31-4-2006','DD-MM-YYYY')
    AND   CAL_EMPCALENDAR.START_DATE BETWEEN GREATEST(HRM_EMPLOYEE.COMMENCE_DATE, TO_DATE('1-4-2006', 'DD-MM-YYYY'))
                                         AND LEAST(TO_DATE('30-4-2006', 'DD-MM-YYYY'), NVL(HRM_EMPLOYEE.CESSATION_DATE, TO_DATE('30-4-2006', 'DD-MM-YYYY')))
    And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SG' || '%'
    And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SGTAM001'
    And CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_CURR_CAREER_V.EMPLOYEE_ID
    -- AND HRM_CURR_CAREER_V.DEPARTMENT_CODE like 'DPHR'
    --AND HRM_EMPLOYEE.EMPLOYMENT_TYPE_CODE like '$P!{EmploymentType}'
    --$P!{ExceptionSQL}
    --$P!{iHRFilterClause}
    --order by $P!{OrderBy}
    order by mainNicolas.

  • My query take long time..

    The output of tkprof of my trace file is :
    SELECT ENEXT.NUM_PRSN_EMPLY ,ENEXT.COD_BUSUN ,ENEXT.DAT_CALDE ,ENEXT.COD_SHFT
    FROM
    AAC_EMPLOYEE_ENTRY_EXITS5_VIW ENEXT ,PDS.PDS_EMPLOYEES EMPL ,
    PDS.PDS_EMPLOYMENT_TYPES EMPTYP ,PDS.PDS_PAY_CONDITIONS PAYCON WHERE
    ENEXT.DAT_CALDE BETWEEN :B6 AND :B5 AND ENEXT.NUM_PRSN_EMPLY IN (SELECT
    ATT21 FROM APPS.GLOBAL_TEMPS WHERE ATT1 = 'PRSN') AND ENEXT.NUM_PRSN_EMPLY =
    EMPL.NUM_PRSN_EMPLY AND EMPL.EMTYP_COD_EMTYP = EMPTYP.COD_EMTYP AND
    EMPTYP.LKP_COD_STA_PAY_EMTYP <> 3 AND
    NVL(EMPL.LKP_MNTLY_WITHOUT_ENEXT_EMPLY,2) <> 1 AND EMPL.PCOND_COD_STA_PCOND
    = PAYCON.COD_STA_PCOND AND NVL(EMPL.LKP_MNTLY_WITHOUT_ENEXT_EMPLY,2) <> 1
    AND PAYCON.LKP_FLG_STA_PAY_PCOND = 1 AND ENEXT.DAT_CALDE >=
    EMPL.DAT_EMPLT_EMPLY AND ENEXT.DAT_CALDE <= NVL(EMPL.DAT_DSMSL_EMPLY,
    TO_DATE('15001229','YYYYMMDD')) AND 1 = (CASE WHEN
    ENEXT.LKP_STA_HOLIDAY_CALNR = 2 AND ENEXT.LKP_CAT_SHFT_SHTAB = 1 AND
    ENEXT.TYP_DAY BETWEEN 4 AND 6 THEN 0 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 2
    AND ENEXT.LKP_CAT_SHFT_SHTAB = 1 AND ENEXT.TYP_DAY NOT BETWEEN 4 AND 6 THEN
    1 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 2 AND ENEXT.LKP_CAT_SHFT_SHTAB = 2
    THEN 0 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 1 AND ENEXT.LKP_CAT_SHFT_SHTAB =
    1 THEN 1 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 1 AND ENEXT.LKP_CAT_SHFT_SHTAB =
    2 THEN 0 END) AND ENEXT.LKP_COD_DPUT_BUSUN = NVL(:B4 ,
    ENEXT.LKP_COD_DPUT_BUSUN) AND ENEXT.LKP_COD_MANAG_BUSUN = NVL(:B3 ,
    ENEXT.LKP_COD_MANAG_BUSUN) AND ENEXT.COD_BUSUN = NVL(:B2 , ENEXT.COD_BUSUN)
    AND ENEXT.COD_CAL = NVL(COD_CAL, ENEXT.COD_CAL) AND ENEXT.NUM_PRSN_EMPLY =
    NVL(:B1 , ENEXT.NUM_PRSN_EMPLY) AND ENEXT.COD_SHFT IN (SELECT
    SHFTBL.COD_SHTAB FROM AAC_SHIFT_TABLES SHFTBL WHERE
    SHFTBL.LKP_CAT_SHFT_SHTAB = 1) AND ENEXT.DAT_CALDE NOT IN (SELECT ABN.DAT
    FROM APPS.AAC_EMPL_EN_EX_ABNORMAL_VIW ABN WHERE ABN.PRSN =
    ENEXT.NUM_PRSN_EMPLY AND ABN.DAT BETWEEN :B6 AND :B5 ) AND ENEXT.DAT_CALDE
    IN (SELECT EMPENEXT.DAT_STR_SHFT_ENEXT FROM AAC.AAC_EMPLOYEE_ENTRY_EXITS
    EMPENEXT WHERE EMPENEXT.EMPLY_NUM_PRSN_EMPLY = EMPL.NUM_PRSN_EMPLY AND
    EMPENEXT.DAT_STR_SHFT_ENEXT BETWEEN :B6 AND :B5 AND
    EMPENEXT.LKP_FLG_STA_ENEXT <> 3) ORDER BY ENEXT.NUM_PRSN_EMPLY,
    ENEXT.DAT_CALDE
    call count cpu elapsed disk query current rows
    Parse 2 0.00 0.00 0 0 0 0
    Execute 2 0.00 0.00 0 0 0 0
    Fetch 2 40.45 40.30 306 17107740 0 24
    total 6 40.45 40.30 306 17107740 0 24
    what is wrong in my query?
    why it take long time?

    user13344656 wrote:
    what is wrong in my query?
    why it take long time?See PL/SQL forum FAQ
    https://forums.oracle.com/forums/ann.jspa?annID=1535
    *3. How to improve the performance of my query? / My query is running slow.*
    SQL and PL/SQL FAQ
    For instructions on what information to post an how to format it.

  • NewElementInHierarchy() - Adding New Elements, progressively takes longer when adding multiple siblings

    With my ESTK script, users select model numbers from a list and then the script inserts an element with a model number entered into an attribute, one element for each model selected.
    When adding a large number of elements, each additional sibling element takes a little longer to add then the previous element. Adding 250 elements can take upwards of 3-1/2 minutes or more. While adding 20, 50, or 75 elements happens quickly, without any noticeable duration. It’s somewhere above 110 is where it starts to be noticeable.
    I even used $.hiresTimer and wrote the value to the console for each time a model was added. Since the timer is reset back to zero (0) each time it's called, it was easier to notice that the amount it incremented from one element to the next got progressively larger.
    Any thoughts as to why it’s taking so long or thoughts on what I could do to speed it up?
    The structure looks like this:
    <PartModels>
          <NoteText>Text</NoteText>
          <Model ModelNumber=”ABC01”/>
          <Model ModelNumber=”ABC02”/>
          <Model ModelNumber=”DEF03”/>
          <Model ModelNumber=”DEF04”/>
          <Model ModelNumber=”XYZ01-A”/>
          <Model ModelNumber=”XYZ*B”/>
          <Model ModelNumber=”XYZ500”/>
    </PartModels>
    The script is somewhat straight forward: cycle through an array of the model numbers selected, add a new element for each model number and set it's attribute value to the model number. This is the short version:
    Function InsertModelElements (modelsToIns, insElemLoc, GVdoc) {
         var newEleId;
         var newElemLoc = insElemLoc;
         var elemDef = GVdoc.GetNamedElementDef(“Model”);
         for(var i = 0; i < modelsToIns.length; i++){ // modelsToIns is the array of models selected
              newEleId = elemDef.NewElementInHierarchy(newElemLoc); //ElementLoc based on NoteText first, last, or not present
              SetAttribute(newEleId, "ModelNumber", null, modelsToIns[i]); //more robust function to set attribute
              /*Which also works for setting attribute*/
              //var vattributes = newEleId.GetAttributes();
              //vattributes[0].values[0] = modelsToIns[i];
              //newEleId.Attributes = vattributes;
              /*At one point I tried using a new element location from the last inserted element, no change*/
              //var newElemRange = setElementSelection(GV_doc, EleId); //function that returns range
              //newElemLoc = newNewElemRange.end;
    Any help is appreciated.
    Sincerely,
    Trent

    Thanks Russ,
    I seriously considered trying copy/paste and started to modify the code to do so. But I couldn't let it go, the answer had to be right there in front of me, just it's been too long since I've worked with this stuff, I'm not able to see it. Then it dawned on me what is happening.
    In an earlier test, I placed a timer on each action that is looped through. For example, I start with an container element that has 200 children elements, each with a specific/unique model number attribute. All 200 existing elements are deleted and then replaced with 250 new elements with a different value for the model number attribute. The timer was placed after the Element.Delete() method and ElementDef.NewElementInHierarchy() method. What I noticed with the timer is that each element deleted was deleted faster than the previous element (so it progressively took less and less time to delete an element). And of course the opposite was noticed for inserting elements, each element inserted took longer than the previous element inserted.
    These elements can be inserted in two areas of the structure, one of the areas has fewer format rules that impact the formatting and is actually a little quicker. This led me to the cause being the EDD format rules. The area that takes longer has quite a few extensive format rules that apply. Every time an element is inserted or deleted, FrameMaker runs through those rules to format the content of the elements. Since the rules apply to parent, first, last, next, previous, etc., FrameMaker has to apply format rules to all the elements in the structure that the rules apply to (which are extremely complex because of the various elements, attribute values, and combinations that can be inserted).
    Removing or thinning down the FormatRules in the EDD, it does get quicker. But each of the FormatRules are needed. So using app.ApplyFormatRules = false; right before the elements are deleted and inserted works great. But the key is to set ApplyFormatRules back to true before deleting the last element to be deleted and before inserting the last element to be inserted, so it will cycle through all the format rules of the EDD for all the elements in the hierarchy those format rules apply to. Setting ApplyFormatRules to true and assigning the ElementDef to the last element also works [EleId.ElementDef = GV_doc.GetNamedElementDef(insElemType);], but only before any other functions are performed or different elements are added.
    doc.Reformat() isn't going to reformat the content correctly after the fact because the element was created without the format rules, so it just reformats the content of the elements without the format rules.
    The FDK version that was created 10 years ago had the same problem of running slow when a large number of elements were being inserted, but was still an improvement over having to manually insert each element and type in the attribute value, so it was lived with.
    It's now working amazingly fast. I hope my explanation of what I think is happening, including the cause/solution, is understandable.
    Sincerely,
    Trent Schwartz

  • Query takes long time to return results.

    I am on Oracle database 10g Enterprise Edition Release 10.2.0.4.0 – 64 bit
    This query takes about 58 seconds to return 180 rows...
             SELECT order_num,
                    order_date,
                    company_num,
                    customer_num,
                    address_type,
                    create_date as address_create_date,
                    contact_name,
                    first_name,
                    middle_init,
                    last_name,
                    company_name,
                    street_address_1,
                    customer_class,
                    city,
                    state,
                    zip_code,
                    country_code,
                    MAX(decode(media_type,
                               'PHH',
                               phone_area_code || '''' || phone_number,
                               NULL)) home_phone,
                    MAX(decode(media_type,
                               'PHW',
                               phone_area_code || '''' || phone_number,
                               NULL)) work_phone,
                    address_seq_num,
                    street_address_2
               FROM (SELECT oh.order_num order_num,
                            oh.order_datetime order_date,
                            oh.company_num company_num,
                            oh.customer_num customer_num,
                            ad.address_type address_type,
                            c.create_date create_date,
                            con.first_name || '''' || con.last_name contact_name,
                            con.first_name first_name,
                            con.middle_init middle_init,
                            con.last_name last_name,
                            ad.company_name company_name,
                            ad.street_address_1 street_address_1,
                            c.customer_class customer_class,
                            ad.city city,
                            ad.state state,
                            ad.zip_code zip_code,
                            ad.country_code,
                            cph.media_type media_type,
                            cph.phone_area_code phone_area_code,
                            cph.phone_number phone_number,
                            ad.address_seq_num address_seq_num,
                            ad.street_address_2 street_address_2
                       FROM reporting_base.gt_gaft_orders gt,
                            doms.us_ordhdr   oh,
                            doms.us_address  ad,
                            doms.us_customer c,
                            doms.us_contact  con,
                            doms.us_contph   cph
                      WHERE oh.customer_num = c.customer_num(+)
                        AND oh.customer_num = ad.customer_num(+)
                        AND (
                               ad.customer_num = c.customer_num
                        AND
                               ad.address_type = 'B'
                         OR   (
                                ad.customer_num = c.customer_num
                        AND
                                ad.address_type = 'S'
                        AND
                            ad.address_seq_num = oh.ship_to_seq_num
                        AND ad.customer_num = con.customer_num(+)
                        AND ad.address_type = con.address_type(+)
                        AND ad.address_seq_num = con.address_seq_num(+)
                        AND con.customer_num = cph.customer_num(+)
                        AND con.contact_id = cph.contact_id(+)
                        AND oh.order_num = gt.order_num
                        AND oh.business_unit_id = gt.business_unit_id)
              GROUP BY order_num,
                       order_date,
                       company_num,
                       customer_num,
                       address_type,
                       create_date,
                       contact_name,
                       first_name,
                       middle_init,
                       last_name,
                       company_name,
                       street_address_1,
                       customer_class,
                       city,
                       state,
                       zip_code,
                       country_code,
                       address_seq_num,
                       street_address_2;This is the explain plan for the query:
    Plan
    SELECT STATEMENT FIRST_ROWS Cost: 21 Bytes: 207 Cardinality: 1
         18 HASH GROUP BY Cost: 21 Bytes: 207 Cardinality: 1
               17 NESTED LOOPS OUTER Cost: 20 Bytes: 207 Cardinality: 1
                     14 NESTED LOOPS OUTER Cost: 16 Bytes: 183 Cardinality: 1
                           11 FILTER
                                 10 NESTED LOOPS OUTER Cost: 12 Bytes: 152 Cardinality: 1
                                       7 NESTED LOOPS OUTER Cost: 8 Bytes: 74 Cardinality: 1
                                             4 NESTED LOOPS OUTER Cost: 5 Bytes: 56 Cardinality: 1
                                                   1 TABLE ACCESS FULL TABLE (TEMP) REPORTING_BASE.GT_GAFT_ORDERS Cost: 2 Bytes: 26 Cardinality: 1
                                                   3 TABLE ACCESS BY INDEX ROWID TABLE DOMS.US_ORDHDR Cost: 3 Bytes: 30 Cardinality: 1
                                                         2 INDEX UNIQUE SCAN INDEX (UNIQUE) DOMS.USORDHDR_IXUPK_ORDNUMBUID Cost: 2 Cardinality: 1
                                             6 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CUSTOMER Cost: 3 Bytes: 18 Cardinality: 1 Partition #: 11
                                                   5 INDEX UNIQUE SCAN INDEX (UNIQUE) DOMS.USCUSTOMER_IXUPK_CUSTNUM Cost: 2 Cardinality: 1
                                       9 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_ADDRESS Cost: 4 Bytes: 156 Cardinality: 2 Partition #: 13
                                             8 INDEX RANGE SCAN INDEX (UNIQUE) DOMS.USADDR_IXUPK_CUSTATYPASEQ Cost: 3 Cardinality: 2
                           13 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CONTACT Cost: 4 Bytes: 31 Cardinality: 1 Partition #: 15
                                 12 INDEX RANGE SCAN INDEX DOMS.USCONT_IX_CNATAS Cost: 3 Cardinality: 1
                     16 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CONTPH Cost: 4 Bytes: 24 Cardinality: 1 Partition #: 17
                           15 INDEX RANGE SCAN INDEX (UNIQUE) DOMS.USCONTPH_IXUPK_CUSTCONTMEDSEQ Cost: 3 Cardinality: 1 Cost is good. All indexes are used. However the time to return the data is very high.
    Any ideas to make the query faster?.
    Thanks

    Hi, here is the tkprof output as requested by Rob..
    TKPROF: Release 10.2.0.4.0 - Production on Mon Jul 13 09:07:09 2009
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    Trace file: axispr1_ora_15293.trc
    Sort options: default
    count    = number of times OCI procedure was executed
    cpu      = cpu time in seconds executing
    elapsed  = elapsed time in seconds executing
    disk     = number of physical reads of buffers from disk
    query    = number of buffers gotten for consistent read
    current  = number of buffers gotten in current mode (usually for update)
    rows     = number of rows processed by the fetch or execute call
    SELECT ORDER_NUM, ORDER_DATE, COMPANY_NUM, CUSTOMER_NUM, ADDRESS_TYPE,
      CREATE_DATE AS ADDRESS_CREATE_DATE, CONTACT_NAME, FIRST_NAME, MIDDLE_INIT,
      LAST_NAME, COMPANY_NAME, STREET_ADDRESS_1, CUSTOMER_CLASS, CITY, STATE,
      ZIP_CODE, COUNTRY_CODE, MAX(DECODE(MEDIA_TYPE, 'PHH', PHONE_AREA_CODE ||
      '''' || PHONE_NUMBER, NULL)) HOME_PHONE, MAX(DECODE(MEDIA_TYPE, 'PHW',
      PHONE_AREA_CODE || '''' || PHONE_NUMBER, NULL)) WORK_PHONE, ADDRESS_SEQ_NUM,
       STREET_ADDRESS_2
    FROM
    (SELECT OH.ORDER_NUM ORDER_NUM, OH.ORDER_DATETIME ORDER_DATE, OH.COMPANY_NUM
      COMPANY_NUM, OH.CUSTOMER_NUM CUSTOMER_NUM, AD.ADDRESS_TYPE ADDRESS_TYPE,
      C.CREATE_DATE CREATE_DATE, CON.FIRST_NAME || '''' || CON.LAST_NAME
      CONTACT_NAME, CON.FIRST_NAME FIRST_NAME, CON.MIDDLE_INIT MIDDLE_INIT,
      CON.LAST_NAME LAST_NAME, AD.COMPANY_NAME COMPANY_NAME, AD.STREET_ADDRESS_1
      STREET_ADDRESS_1, C.CUSTOMER_CLASS CUSTOMER_CLASS, AD.CITY CITY, AD.STATE
      STATE, AD.ZIP_CODE ZIP_CODE, AD.COUNTRY_CODE, CPH.MEDIA_TYPE MEDIA_TYPE,
      CPH.PHONE_AREA_CODE PHONE_AREA_CODE, CPH.PHONE_NUMBER PHONE_NUMBER,
      AD.ADDRESS_SEQ_NUM ADDRESS_SEQ_NUM, AD.STREET_ADDRESS_2 STREET_ADDRESS_2
      FROM REPORTING_BASE.GT_GAFT_ORDERS GT, DOMS.US_ORDHDR OH, DOMS.US_ADDRESS
      AD, DOMS.US_CUSTOMER C, DOMS.US_CONTACT CON, DOMS.US_CONTPH CPH WHERE
      OH.ORDER_NUM = GT.ORDER_NUM AND OH.BUSINESS_UNIT_ID = GT.BUSINESS_UNIT_ID
      AND OH.CUSTOMER_NUM = C.CUSTOMER_NUM(+) AND OH.CUSTOMER_NUM =
      AD.CUSTOMER_NUM(+) AND AD.CUSTOMER_NUM = C.CUSTOMER_NUM AND (
      AD.ADDRESS_TYPE = 'B' OR ( AD.ADDRESS_TYPE = 'S' AND AD.ADDRESS_SEQ_NUM =
      OH.SHIP_TO_SEQ_NUM ) ) AND AD.CUSTOMER_NUM = CON.CUSTOMER_NUM(+) AND
      AD.ADDRESS_TYPE = CON.ADDRESS_TYPE(+) AND AD.ADDRESS_SEQ_NUM =
      CON.ADDRESS_SEQ_NUM(+) AND CON.CUSTOMER_NUM = CPH.CUSTOMER_NUM(+) AND
      CON.CONTACT_ID = CPH.CONTACT_ID(+) ) GROUP BY ORDER_NUM, ORDER_DATE,
      COMPANY_NUM, CUSTOMER_NUM, ADDRESS_TYPE, CREATE_DATE, CONTACT_NAME,
      FIRST_NAME, MIDDLE_INIT, LAST_NAME, COMPANY_NAME, STREET_ADDRESS_1,
      CUSTOMER_CLASS, CITY, STATE, ZIP_CODE, COUNTRY_CODE, ADDRESS_SEQ_NUM,
      STREET_ADDRESS_2
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch      257      0.04       0.05         45          0          0        6421
    total      257      0.04       0.05         45          0          0        6421
    Misses in library cache during parse: 0
    Parsing user id: 126
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch      257      0.04       0.05         45          0          0        6421
    total      257      0.04       0.05         45          0          0        6421
    Misses in library cache during parse: 0
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        0      0.00       0.00          0          0          0           0
    Execute      0      0.00       0.00          0          0          0           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        0      0.00       0.00          0          0          0           0
    Misses in library cache during parse: 0
        1  user  SQL statements in session.
        0  internal SQL statements in session.
        1  SQL statements in session.
    Trace file: axispr1_ora_15293.trc
    Trace file compatibility: 10.01.00
    Sort options: default
           1  session in tracefile.
           1  user  SQL statements in trace file.
           0  internal SQL statements in trace file.
           1  SQL statements in trace file.
           1  unique SQL statements in trace file.
         289  lines in trace file.
          83  elapsed seconds in trace file.Thanks in advance!

  • How to do sum when using union

    hi,
    i am getting following example data from a query
    which uses UNION which is mandatory.
    is there a way to do sum of Units column to get a single
    row ?
    hire date units
    01.08.2003 1,00
    01.08.2003 12,50
    like to see as a single row
    01.08.2003 13,50
    rgds,
    Karna

    SELECT hire_date, SUM(units) units
    FROM (SELECT hire_date, units
          FROM table1
          UNION ALL
          SELECT hire_date, units
          FROM table2)
    GROUP BY hire_dateTTFN
    John

  • Need sql query to remove duplicates using UNION ALL clause

    Hi,
    I have a sql query which has UNION clause.But the UNION clause is causing some performance issues.
    To overcome that I have used UNION ALL to improve performance but its returning duplicates.
    Kindly anyone send a sample SQL query where my primary objective is used to use UNION ALL clause and to consider unique rows (elimating duplicate
    ones)
    Any help will be needful for me
    Thanks and Regards

    why not UNION? :(
    another way also use MINUS
    SQL>
    SQL> with t as
      2  (
      3  select 1 if from dual union all
      4  select 2 if from dual union all
      5  select 1 if from dual union all
      6  select 3 if from dual union all
      7  select 3 if from dual
      8  )
      9  ,t2 as
    10  (
    11  select 1 if from dual union all
    12  select 2 if from dual union all
    13  select 3 if from dual union all
    14  select 4 if from dual union all
    15  select 5 if from dual
    16  )
    17  (select if from t
    18  union all
    19  select if from t2)
    20  /
            IF
             1
             2
             1
             3
             3
             1
             2
             3
             4
             5
    10 rows selected
    SQL> so
    SQL>
    SQL> with t as
      2  (
      3  select 1 if from dual union all
      4  select 2 if from dual union all
      5  select 1 if from dual union all
      6  select 3 if from dual union all
      7  select 3 if from dual
      8  )
      9  ,t2 as
    10  (
    11  select 1 if from dual union all
    12  select 2 if from dual union all
    13  select 3 if from dual union all
    14  select 4 if from dual union all
    15  select 5 if from dual
    16  )
    17  (select if from t
    18  union all
    19  select if from t2)
    20  minus
    21  select -99 from dual
    22  /
            IF
             1
             2
             3
             4
             5
    SQL>

  • Query Designer crashes when using 0CALWEK

    Hi all
    I have come accross an error when using the query designer in BI 7.0.  If i try to restrict on 0CALWEEK the Query Designer first tells me there are errors but none show, then tells me there are no values for 0CALWEEK and finally crashes saying
    "An unhandled exception has occurred in your application."
    "Object reference not set to an instance of an object."
    After this the desiger freezes and must be exited.
    On occasions an RFC error shows on the botton of the design view suggesting a check of the RFC logs, however nothing appears in the RFC log.
    Any assistance would be very much appreciated.
    With Thanks
    Gareth

    Anil
    Generating in RSRT does not fix the problem.
    Checking the query designer shows no errors, however once we get the crash after attempting to restrict on 0CALWEEK it is not possible to use the check button (since the whole of query designer freezes).
    This is happenning on our development system (the only one on which we are currently creating queries) and on all PCs.
    The note, unfortunately, refers to an issue when using gui 7.X, however we are using 640 so it should not be a .net framework issue however i am asking my BASIS team to do some testing on that.
    Many thanks for your suggestion though.
    Any other ideas?
    Regards
    Gareth

  • Drill down problem when using union all combination

    Hi All,
    I have a simple report with a drill down. The report has three columns Region, Sales, Flag... which will drill down to detail level of sales. The Flag column has Y, N values and we added 'All' Value in flag so that the user can select Y, N and All from the table prompt in the report . We have used union all in the report using combination to add the ' All ' Value in the flag. The problem is that now the main report is not passing the Flag values to the detail report. Flag is prompted in the filter in detail report.
    If I remove the 'All' value from Analysis with only Y N selection criteria the drill down works.
    Is there any work around? I have to use table prompt and All value selection in flag for drill down.
    Thanks,
    Virat

    The problem is without union all when doing combination of analysis drill down works, when I use combination drill down does not work because it does not pass the parameters for flag . I have used union all to add All value in flag.

Maybe you are looking for