Query to calculate time

hi all,
i have 2 udf field of type 'Time', StartTime and EndTime in order to catch the info of some process time.
again 2 fields of date in order to catch the range of days for the process goes.
like the following
Startdate | Enddate | Starttime | Endtime
15/04/09--| 16/04/09| 9:30- | ---14:00
Now i need a query to calculate the time differences in hrs. like the process runs thro 4 n half hrs a day and totally as per the table value the total run process time is 9 hrs.
How to bring out in query any one plz help...
Thank you so much,

Hi Yatsea, sorry tis time too its not reteiving correct answer, the values i gave over here is jus for example. but in real there may be many different values. So will be useful in case of providing the query taking in the field names plz.
i hav a work around working on . will write here, plz guide me to correct the query to get me correct answer.
in order to find the specific hrs between start and end time for 2 days,
1. can find first total days within start and end date (EndDate-StartDate) + 1 = 2
2. 2nd find the hrs between start and end time (EndTime-StartTime) = 4.30 hrs
3. after tht should multply the 2 values 2 * 4.30 = 8.60 which should round as 9 hrs
Select (datediff(day,enddate,startdate)+1) * (endtime-starttime)
will it help..? its not giving correct answer. may gone wrong wit time format. but this concept will give correct anawer i hope...
PLz...help me getting solution.
Edited by: New  User on Apr 16, 2009 3:52 PM

Similar Messages

  • Query to calculate time frames

    hello,
    id like to write a query that will calculate time frames ;
    my source table looks like this:
    company     category     date
    ORACLE     A     1/01/2012
    ORACLE     A     2/01/2012
    ORACLE     B     3/01/2012
    ORACLE     C     4/01/2012
    IBM     A     1/01/2012
    IBM     A     2/01/2012
    IBM     A     3/01/2012
    IBM     A     4/01/2012my desired result:
    company     category     from     to
    ORACLE     A     1/01/2012     2/01/2012
    ORACLE     B     3/01/2012     3/01/2012
    ORACLE     C     4/01/2012     31/12/2999
    IBM     A     1/01/2012     31/12/2999can you please guide me with use of which functions i can achieve that?
    id appreciate any tips
    thank you
    rgds
    Edited by: UserMB on Jan 11, 2012 5:14 PM

    One way...
    ME_XE?with t as
      2  (
      3    select 'ORACLE' col1, 'A' col2, to_date('1/01/2012', 'dd/mm/yyyy') col3
      4      from dual
      5    union all
      6    select 'ORACLE', 'A', to_date('2/01/2012', 'dd/mm/yyyy')
      7      from dual
      8    union all
      9    select 'ORACLE', 'B', to_date('3/01/2012', 'dd/mm/yyyy')
    10      from dual
    11    union all
    12    select 'ORACLE', 'C', to_date('4/01/2012', 'dd/mm/yyyy')
    13      from dual
    14    union all
    15    select 'IBM', 'A', to_date('1/01/2012', 'dd/mm/yyyy')
    16      from dual
    17    union all
    18    select 'IBM', 'A', to_date('2/01/2012', 'dd/mm/yyyy')
    19      from dual
    20    union all
    21    select 'IBM', 'A', to_date('3/01/2012', 'dd/mm/yyyy')
    22      from dual
    23    union all
    24    select 'IBM', 'A', to_date('4/01/2012', 'dd/mm/yyyy') from dual
    25  )
    26  select
    27    col1, col2, min(col3), case when max(col3) = max_company_date then to_date('31/12/2999','dd/mm/yyyy') else max(col3) end
    28  from
    29  (
    30    select col1, col2, col3, max(col3) over (partition by col1) as max_company_date
    31    from t
    32  )
    33  group by col1, col2, max_company_date;
    COL1               COL MIN(COL3)                  CASEWHENMAX(COL3)=MAX_COMP
    ORACLE             B   03-JAN-2012 12 00:00       03-JAN-2012 12 00:00
    ORACLE             A   01-JAN-2012 12 00:00       02-JAN-2012 12 00:00
    ORACLE             C   04-JAN-2012 12 00:00       31-DEC-2999 12 00:00
    IBM                A   01-JAN-2012 12 00:00       31-DEC-2999 12 00:00
    4 rows selected.
    Elapsed: 00:00:00.01
    ME_XE?

  • Need  the query to calculate the time taken to excute it.

    hi all,
    i need the query to calculate the time taken to excute it.
    for ex:
    select * from emp;
    how much time it will take to give o/p
    Thanks in advance
    satya

    Just to add to what was said - the execution can each time be DIFFERENT as the factors that governs performance are NOT CONSTANT.
    If Oracle has no idea how long the query is going to take before executing it, then how can you and your code know?
    Oracle's CBO estimates the cost (expense) of the query. This is an indication of how expensive a query is - and the more expensive the query, the more resources need to be used, the longer the query will take. The less expensive the query, the fewer resources it need, the faster it will take.
    And that is it. How fast or how slow? Oracle does not know. How much faster a query with a cost of 10,000 versus a query with a cost of 1? Oracle does not know.
    Why? Because the platform is not constant. Just what data is at this exact moment in the db buffer cache? Just how much CPU capacity is available for the new few seconds? Just what will the sustained throughput be of the I/O subsystem and channels for the next minute? Just how many memory pages need to be swapped between cache and memory? Etc. etc.
    All these factors change every single second. So forget about attempting to accurately calculate up-front the time it will take for a query. IT IS NOT POSSIBLE.

  • What will be the peoplesoft query to calculate voluntary termination count and involuntary termination count? I am working on OBIA HR analytics workforce deployment reports and need to validate the reports

    what will be the peoplesoft query to calculate voluntary termination count and involuntary termination count? I am working on OBIA HR analytics workforce deployment reports and need to validate the reports. I also want to know the tables involved

    Hi Andrew,
    Part A:
    I've done some restating of the question, and distributed the calculations among several fields, not all of which need to be included on the visible layout. Other than formatting the Date fields and moving the 'Completed Date' field and its label, I've left this in the default "Layout 1" produced by AppleWorks.
    Field List:
    Priority: Popup menu with six items: 00, J, D, 1, 2, 3  Defaults to 00
    TL (time limit in months): Calculation:  CHOOSE('Priority',0,1,3,4,6,12)
    Received: Date. Option: Automatically insert today's date (ie. Date Record created) (may be edited)
    Target Date: Calculation:
    DATE(YEAR('Received')+INT(MONTH('Received')+'TL')/12,MOD(MONTH('Received')+'TL', 12),DAY('Received'))
    Remaining (Days): Calculation: INT('Target Date'+1-NOW())  (see revision below)
    Completed: Checkbox. Set default value to Unchecked.
    Completed Date: Date: Entered manually
    OnTarget: Calculation: IF('Completed',IF('Completed Date'<'Target Date',"On Target","Over"),IF(INT(NOW())>'Target Date',"Over","On Target"))
    The On Target field shows the current status of the case while still open, and the state on the closing date when it was closed.
    Having done that, I was unhappy with the Remaining field continuing to calculate an ever larger negative number after the case had been closed. Hence this revision below:
    Remaining: Calculation: IF('Completed','Target Date'-'Completed Date',INT('Target Date'+1-NOW()))
    Shows the number of days remaining while the case is open, the days remaining at completion if the case has been marked Completed and the completion date entered.
    Rsults (and some further formatting of the Layout) below.
    Part B:
    You will need Subsummary parts when sorted on Completed and on On Target. Fields can appear on  a Layout only once, so each subsummary part will need a separate Summary type field for each field to be summarized.
    Regards,
    Barry

  • Approach to tune a query in short time

    Hi All,
    Oracle 10g I know this question is asked number of times and there are many good replies to them.
    But I just want to know how to approach a completely new query ( like the task given to me to fine tume a query in 1 day when I dont have even the slightest idea about how to proceed) if the timeline is very stringent and by just looking at the explain plan, you have to take the decision.
    I am just posting my query here and what I am looking for is some lead on how to identify the congetion point which is where this query takes long time ( in my case some 15 mins as reported to me)
    select
                     "LEGAL ENTITY",
                     "Legal Entity Description",
                     "Cluster",
                     "Sub_Cluster",
                     "Account",
                      rownum,
                     "Moody_Rating",
                     "Process_Date",
                     "Merge_Description",
                      rownum,
                     "Merge_Description",
                     "is_id_ic",
                     "is_n",
                     "cusip",
                     "isin",
                     "credit_spread_PV01",
                     "amount",
                     "Market_Value",
                     "Currency",
                     "Sensitivity_Type",
                     "maturity_Date",
                     "Exception_Flag",
                     "Base_Security_Id",
                     DECODE(sign("Market_Value"),-1,DeCode(SigN("Recovery"),-1,"Recovery",('-'||"Recovery")), ABS("Recovery")) as "Recovery"
                     from
                     select
                     le.name "LEGAL ENTITY",
                     le.display_name "Legal Entity Description",
                     mn4.display_name "Cluster",
                     mn3.display_name "Sub_Cluster",
                     bookname.display_name "Account",
                     (SELECT RATING_NAME
                        FROM moody_rating
                       where moody_rating_id = i.moody_rating_id) "Moody_Rating",
                     to_char(to_date(:v_cob_date,'DD-MM-YY'),'YYYYMMDD') "Process_Date",
                     ss.issuer "Merge_Description",
                     PART.MARS_ISSUER "is_id_ic",
                     PART.PARTICIPANT_NAME "is_n",
                     NULL "cusip",
                     NULL "isin",
                     NULL "credit_spread_PV01",
                     NULL "amount",
                     sum(mtmsens.sensitivity_value) "Market_Value",
                     (SELECT distinct cc.CCY
                        FROM legacy_country CC
                       INNER JOIN MARSNODE MN ON CC.countryisocode = MN.NAME
                                             and mn.close_date is null
                       INNER JOIN MARSNODETYPE MNT ON MN.TYPE_ID =
                                                      MNT.NODE_TYPE_ID
                                                  AND MNT.NAME = 'COUNTRY'
                                                  and mnt.close_date is null
                       where MN.NODE_ID = part.country_domicile_id
                         and cc.begin_cob_date <= :v_cob_date
                         and cc.end_cob_date > :v_cob_date
                         and rownum < 2) "Currency",
                     'CREDITSPREADMARKETVALUE' "Sensitivity_Type",
                     NULL "maturity_Date",
                     NULL "Exception_Flag",
                     NULL "Base_Security_Id",
                     sum(ss.sensitivity_value) "Recovery"
                     from staging_position sp
                left JOIN position p on (
                                         p.feed_instance_id = sp.feed_instance_id
                                     AND p.feed_row_id = sp.feed_row_id)
                left JOIN staging_instrument si on (si.feed_instance_id =
                                                   sp.feed_instance_id AND
                                                   si.position_key =
                                                   sp.position_key)
                left join book b on (b.book_id = p.book_id and
                                    b.begin_cob_date <= :v_cob_date and
                                    b.end_cob_date > :v_cob_date)
                left join marsnode bk on (b.book_id = bk.node_id and
                                         bk.close_date is null)
                left join marsnode le on (b.leg_ent_id = le.node_id and
                                         le.close_date is null)
                left join marsnode bookname on (bookname.node_id = p.book_id and
                                               bookname.close_date is null)
                left join marsnodelink mnl on p.book_id = mnl.node_id
                                          and :v_bus_org_hier_id =
                                              mnl.hierarchy_id
                                          and mnl.close_date is null
                                          and :v_cob_date >= mnl.begin_cob_date
                                          and :v_cob_date < mnl.end_cob_date
                left join marsnode mn on mn.node_id = mnl.parent_id
                                     and mn.close_date is null
                left join marsnodelink mnl2 on mn.node_id = mnl2.node_id
                                           and :v_bus_org_hier_id =
                                               mnl2.hierarchy_id
                                           and mnl2.close_date is null
                                           and :v_cob_date >= mnl2.begin_cob_date
                                           and :v_cob_date < mnl2.end_cob_date
                left join marsnode mn2 on mn2.node_id = mnl2.parent_id
                                      and mn2.close_date is null
                left join marsnodelink mnl3 on mn2.node_id = mnl3.node_id
                                           and :v_bus_org_hier_id =
                                               mnl3.hierarchy_id
                                           and mnl3.close_date is null
                                           and :v_cob_date >= mnl3.begin_cob_date
                                           and :v_cob_date < mnl3.end_cob_date
                left join marsnode mn3 on mn3.node_id = mnl3.parent_id
                                      and mn3.close_date is null
                left join marsnodelink mnl4 on mn3.node_id = mnl4.node_id
                                           and :v_bus_org_hier_id =
                                               mnl4.hierarchy_id
                                           and mnl4.close_date is null
                                           and :v_cob_date >= mnl4.begin_cob_date
                                           and :v_cob_date < mnl4.end_cob_date
                left join marsnode mn4 on mn4.node_id = mnl4.parent_id
                                      and mn4.close_date is null
              --sensitivity data
                left JOIN STAGING_SENSITIVITY ss ON (ss.FEED_INSTANCE_ID =
                                                    sp.FEED_INSTANCE_ID AND
                                                    ss.FEED_ROW_ID =
                                                    sp.FEED_ROW_ID)
              --sensitivity data
                left JOIN STAGING_SENSITIVITY mtmsens ON (mtmsens.FEED_INSTANCE_ID =
                                                         sp.FEED_INSTANCE_ID AND
                                                         mtmsens.FEED_ROW_ID =
                                                         sp.FEED_ROW_ID)
                LEFT join xref_domain_value_map XREF on (XREF.Src_Value =
                                                        ss.issuer and
                                                        XREF.close_action_id is null and
                                                        XREF.Begin_Cob_Date <=
                                                        :v_cob_date and
                                                        XREF.End_Cob_Date >
                                                        :v_cob_date AND
                                                        xref.domain_map_id = 601 AND
                                                        xref.source_system_id = 307 AND xref.ISSUE_ID is not null)
                Left join ISSUE i on (i.issue_id = xref.issue_id)
                LEFT join participant PART ON (PART.PARTICIPANT_ID =
                                              XREF.TGT_VALUE and
                                              PART.Close_Action_Id is null and
                                              PART.Begin_Cob_Date <= :v_cob_date and
                                              PART.End_Cob_Date > :v_cob_date)
                left join moody_rating RATING on (rating.moody_rating_id =
                                                  i.MOODY_RATING_ID)
               where sp.feed_instance_id in
                     (select fbi.feed_instance_id
                      from   feed_book_status fbi ,
                             feed_instance fi
                      where  fbi.cob_date = :v_cob_date
                      and    fbi.feed_instance_id = fi.feed_instance_id
                      and    fi.feed_id in (
                                           select feed_id from feed_group_xref where feed_group_id in (
                                               select feed_group_id from feed_group where description like 'CDO Feeds')
                                               and close_action_id is null
                 and sp.Feed_Row_Status_Id = 1
                 and ss.sensitivity_type = 'CREDITSPREADDEFAULT'
                 and mtmsens.sensitivity_type = 'MTMVALUE'
                 and le.name='161'
                 group by le.name,
                        le.display_name,
                        mn3.display_name,
                        mn4.display_name,
                        mn.display_name,
                        i.moody_rating_id,
                        ss.issuer,
                        PART.MARS_ISSUER,
                        PART.PARTICIPANT_NAME,
                        sp.feed_instance_id,
                        part.country_domicile_id,
                        bookname.display_name) And the explain plan
    SELECT STATEMENT, GOAL = CHOOSE               Cost=19365     Cardinality=1     Bytes=731
    TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MOODY_RATING     Cost=1     Cardinality=1     Bytes=9
      INDEX UNIQUE SCAN     Object owner=MARS     Object name=PK_MOODY_RATING     Cost=0     Cardinality=1     
    HASH UNIQUE               Cost=77     Cardinality=1     Bytes=488
      COUNT STOPKEY                         
       HASH JOIN               Cost=76     Cardinality=1     Bytes=488
        NESTED LOOPS               Cost=68     Cardinality=1     Bytes=460
         HASH JOIN               Cost=66     Cardinality=1     Bytes=450
          HASH JOIN               Cost=59     Cardinality=1     Bytes=412
           NESTED LOOPS               Cost=51     Cardinality=1     Bytes=402
            HASH JOIN               Cost=49     Cardinality=1     Bytes=392
             NESTED LOOPS               Cost=42     Cardinality=1     Bytes=359
              NESTED LOOPS               Cost=40     Cardinality=1     Bytes=349
               NESTED LOOPS               Cost=37     Cardinality=1     Bytes=300
                NESTED LOOPS               Cost=34     Cardinality=1     Bytes=251
                 HASH JOIN               Cost=32     Cardinality=1     Bytes=241
                  TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=27
                   NESTED LOOPS               Cost=24     Cardinality=1     Bytes=231
                    NESTED LOOPS               Cost=21     Cardinality=1     Bytes=204
                     NESTED LOOPS               Cost=18     Cardinality=1     Bytes=171
                      NESTED LOOPS               Cost=16     Cardinality=1     Bytes=136
                       NESTED LOOPS               Cost=13     Cardinality=1     Bytes=86
                        NESTED LOOPS               Cost=10     Cardinality=1     Bytes=37
                         VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=10
                          FILTER                         
                           CONNECT BY WITH FILTERING                         
                            TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
                             INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
                              HASH JOIN               Cost=5     Cardinality=1     Bytes=62
                               TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                               TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
                            NESTED LOOPS                         
                             CONNECT BY PUMP                         
                             TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=39
                              INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
                           TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                         TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=27
                          INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                        TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=49
                         INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                       TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=50
                        INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                      TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODETYPE     Cost=2     Cardinality=1     Bytes=35
                       INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODETYPE     Cost=1     Cardinality=1     
                     TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=NODE_ASSOC     Cost=3     Cardinality=1     Bytes=33
                      INDEX RANGE SCAN     Object owner=MARS     Object name=PK_NODE_ASSOC     Cost=1     Cardinality=3     
                    INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                  VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=10
                   FILTER                         
                    CONNECT BY WITH FILTERING                         
                     TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
                      INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
                       HASH JOIN               Cost=5     Cardinality=1     Bytes=62
                        TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                        TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
                     NESTED LOOPS                         
                      CONNECT BY PUMP                         
                      TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=39
                       INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
                    TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                 INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     Bytes=10
                TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=NODE_ASSOC     Cost=3     Cardinality=1     Bytes=49
                 INDEX RANGE SCAN     Object owner=MARS     Object name=PK_NODE_ASSOC     Cost=1     Cardinality=3     
               TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=49
                INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
              INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     Bytes=10
             VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=33
              FILTER                         
               CONNECT BY WITH FILTERING                         
                TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
                 INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
                  HASH JOIN               Cost=5     Cardinality=1     Bytes=62
                   TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                   TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
                NESTED LOOPS                         
                 CONNECT BY PUMP                         
                 TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=39
                  INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
               TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
            INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     Bytes=10
           VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=10
            FILTER                         
             CONNECT BY WITH FILTERING                         
              TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
               INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
                HASH JOIN               Cost=5     Cardinality=1     Bytes=62
                 TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                 TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
              NESTED LOOPS                         
               CONNECT BY PUMP                         
               TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=39
                INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
             TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
          VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=38
           FILTER                         
            CONNECT BY WITH FILTERING                         
             TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
              INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
               HASH JOIN               Cost=5     Cardinality=1     Bytes=62
                TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
                TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
             NESTED LOOPS                         
              CONNECT BY PUMP                         
              TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=57
               INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
            TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=36
         INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     Bytes=10
        VIEW     Object owner=MARS          Cost=7     Cardinality=1     Bytes=28
         FILTER                         
          CONNECT BY WITH FILTERING                         
           TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK               
            INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_PARENT_ID     Cost=3     Cardinality=250     Bytes=2500
             HASH JOIN               Cost=5     Cardinality=1     Bytes=62
              TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
              TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHYROOT     Cost=2     Cardinality=5     Bytes=175
           NESTED LOOPS                         
            CONNECT BY PUMP                         
            TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=7     Cardinality=1     Bytes=57
             INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_MNL_HI_PI_NI     Cost=3     Cardinality=4     
          TABLE ACCESS FULL     Object owner=MARS     Object name=MARSHIERARCHY     Cost=2     Cardinality=1     Bytes=27
    COUNT                         
      VIEW     Object owner=MARS          Cost=19365     Cardinality=1     Bytes=731
       HASH GROUP BY               Cost=19365     Cardinality=1     Bytes=1112
        NESTED LOOPS OUTER               Cost=19364     Cardinality=1     Bytes=1112
         NESTED LOOPS OUTER               Cost=19361     Cardinality=1     Bytes=1040
          NESTED LOOPS OUTER               Cost=19361     Cardinality=1     Bytes=1037
           NESTED LOOPS OUTER               Cost=19360     Cardinality=1     Bytes=1019
            NESTED LOOPS OUTER               Cost=19357     Cardinality=1     Bytes=951
             NESTED LOOPS OUTER               Cost=19354     Cardinality=1     Bytes=914
              NESTED LOOPS OUTER               Cost=19351     Cardinality=1     Bytes=877
               NESTED LOOPS OUTER               Cost=19337     Cardinality=1     Bytes=820
                NESTED LOOPS OUTER               Cost=19334     Cardinality=1     Bytes=783
                 NESTED LOOPS OUTER               Cost=19320     Cardinality=1     Bytes=726
                  NESTED LOOPS OUTER               Cost=19317     Cardinality=1     Bytes=707
                   NESTED LOOPS OUTER               Cost=19303     Cardinality=1     Bytes=650
                    NESTED LOOPS OUTER               Cost=19300     Cardinality=1     Bytes=613
                     NESTED LOOPS               Cost=19285     Cardinality=1     Bytes=556
                      NESTED LOOPS               Cost=19280     Cardinality=1     Bytes=443
                       NESTED LOOPS OUTER               Cost=19275     Cardinality=1     Bytes=330
                        HASH JOIN RIGHT SEMI               Cost=17457     Cardinality=1     Bytes=248
                         VIEW     Object owner=SYS     Object name=VW_NSO_1     Cost=1119     Cardinality=30     Bytes=150
                          HASH JOIN               Cost=1119     Cardinality=30     Bytes=2040
                           TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_GROUP     Cost=2     Cardinality=5     Bytes=120
                           HASH JOIN               Cost=1116     Cardinality=1607     Bytes=70708
                            TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_GROUP_XREF     Cost=13     Cardinality=701     Bytes=14721
                            HASH JOIN               Cost=1102     Cardinality=3602     Bytes=82846
                             INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_FBS_CD_FII_BI     Cost=22     Cardinality=3602     Bytes=46826
                             TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_INSTANCE     Cost=1024     Cardinality=670264     Bytes=6702640
                         NESTED LOOPS               Cost=16337     Cardinality=324     Bytes=78732
                          HASH JOIN               Cost=14324     Cardinality=1977     Bytes=302481
                           NESTED LOOPS OUTER               Cost=11     Cardinality=1     Bytes=114
                            NESTED LOOPS               Cost=8     Cardinality=1     Bytes=95
                             TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=5     Cardinality=1     Bytes=59
                              INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_NODE1     Cost=3     Cardinality=2     
                             TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=BOOK     Cost=3     Cardinality=2     Bytes=72
                              INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_BOOK_LEI_BCD     Cost=2     Cardinality=4     
                            TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=19
                             INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                           PARTITION RANGE ALL               Cost=13995     Cardinality=3854299     Bytes=150317661
                            TABLE ACCESS FULL     Object owner=MARS     Object name=POSITION     Cost=13995     Cardinality=3854299     Bytes=150317661
                          PARTITION RANGE ITERATOR               Cost=2     Cardinality=1     Bytes=90
                           PARTITION HASH ITERATOR               Cost=2     Cardinality=1     Bytes=90
                            TABLE ACCESS BY LOCAL INDEX ROWID     Object owner=MARS     Object name=STAGING_POSITION     Cost=2     Cardinality=1     Bytes=90
                             INDEX UNIQUE SCAN     Object owner=MARS     Object name=PK_STAGINGPOSITON     Cost=1     Cardinality=1     
                        PARTITION HASH ITERATOR               Cost=1819     Cardinality=1     Bytes=82
                         TABLE ACCESS BY LOCAL INDEX ROWID     Object owner=MARS     Object name=STAGING_INSTRUMENT     Cost=1819     Cardinality=1     Bytes=82
                          INDEX RANGE SCAN     Object owner=MARS     Object name=PK_STAGINGINSTRUMENT     Cost=9     Cardinality=2551     
                       PARTITION RANGE ITERATOR               Cost=5     Cardinality=1     Bytes=113
                        PARTITION HASH ITERATOR               Cost=5     Cardinality=1     Bytes=113
                         TABLE ACCESS BY LOCAL INDEX ROWID     Object owner=MARS     Object name=STAGING_SENSITIVITY     Cost=5     Cardinality=1     Bytes=113
                          INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_SENSITIVITY_FEED_ROW_ID     Cost=3     Cardinality=8     
                      PARTITION RANGE ITERATOR               Cost=5     Cardinality=1     Bytes=113
                       PARTITION HASH ITERATOR               Cost=5     Cardinality=1     Bytes=113
                        TABLE ACCESS BY LOCAL INDEX ROWID     Object owner=MARS     Object name=STAGING_SENSITIVITY     Cost=5     Cardinality=1     Bytes=113
                         INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_SENSITIVITY_FEED_ROW_ID     Cost=3     Cardinality=8     
                     TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=14     Cardinality=1     Bytes=57
                      INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_NODE_ID     Cost=2     Cardinality=14     
                    TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=37
                     INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                   TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=14     Cardinality=1     Bytes=57
                    INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_NODE_ID     Cost=2     Cardinality=14     
                  TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=19
                   INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
                 TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=14     Cardinality=1     Bytes=57
                  INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_NODE_ID     Cost=2     Cardinality=14     
                TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=37
                 INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
               TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODELINK     Cost=14     Cardinality=1     Bytes=57
                INDEX RANGE SCAN     Object owner=MARS     Object name=FKI_15632_NODE_ID     Cost=2     Cardinality=14     
              TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=37
               INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
             TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=MARSNODE     Cost=3     Cardinality=1     Bytes=37
              INDEX RANGE SCAN     Object owner=MARS     Object name=PK_MARSNODE     Cost=2     Cardinality=1     
            TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=XREF_DOMAIN_VALUE_MAP     Cost=3     Cardinality=1     Bytes=68
             INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_XDVM_DMI_SV_BCD     Cost=2     Cardinality=1     
           TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=ISSUE     Cost=1     Cardinality=1     Bytes=18
            INDEX UNIQUE SCAN     Object owner=MARS     Object name=PK_ISSUE     Cost=0     Cardinality=1     
          INDEX UNIQUE SCAN     Object owner=MARS     Object name=PK_MOODY_RATING     Cost=0     Cardinality=1     Bytes=3
         TABLE ACCESS BY INDEX ROWID     Object owner=MARS     Object name=PARTICIPANT     Cost=3     Cardinality=1     Bytes=72
          INDEX RANGE SCAN     Object owner=MARS     Object name=PK_PARTICIPANT     Cost=2     Cardinality=1     

    Hi,
    in your explain plan:
    HASH JOIN RIGHT SEMI               Cost=17457     Cardinality=1     Bytes=248
    VIEW     Object owner=SYS     Object name=VW_NSO_1     Cost=1119     Cardinality=30     Bytes=150
    HASH JOIN               Cost=1119     Cardinality=30     Bytes=2040
    TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_GROUP     Cost=2     Cardinality=5     Bytes=120
    HASH JOIN               Cost=1116     Cardinality=1607     Bytes=70708
    TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_GROUP_XREF     Cost=13     Cardinality=701     Bytes=14721
    HASH JOIN               Cost=1102     Cardinality=3602     Bytes=82846
    INDEX RANGE SCAN     Object owner=MARS     Object name=IDX_FBS_CD_FII_BI     Cost=22     Cardinality=3602     Bytes=46826
    TABLE ACCESS FULL     Object owner=MARS     Object name=FEED_INSTANCEThis part has the highest costs (this doesn't always mean it is slow). So this leads me to the WHERE clause where feed_group, feed_group_xref and feed_instance full are used. Maybe this can be improved, although the cardinality is not that high, so a full table can be the best. So the question is can indexes help here?
    Furthermore there is the full table scan on POSITION:
    TABLE ACCESS FULL     Object owner=MARS     Object name=POSITION     Cost=13995     Cardinality=3854299     Bytes=150317661This looks also a large tabel (3 million + records), so is it possible to get this part smaller?
    Herald ten Dam
    http://htendam.wordpress.com

  • While running the query how much time it will taken, I want to see the time

    Hi Folks
    I would like to know ... While running the query how much time it will be taken, I want to see the time? in WEBI XI R2.....
    Plz let me know  the answer.......

    Hi Ravi,
    The time a report runs is estimated based on the last time it was run. So you need to run the report once before you can see how long it will take. Also it depends on several factors... the database server could cache some queries so running it a second time immediately after the first time could be quicker. And there is the chance of changing filters to bring back different sets of data.
    You could also schedule a report and then check the scheduled instance's status properties and view how long a report actually ran.
    Good luck

  • Stopping a Query taking more time to execute in runtime in Oracle Forms.

    Hi,
    In the present application one of the oracle form screen is taking long time to execute a query, user wanted an option to stop the query in between and browse the result (whatever has been fetched before stopping the query).
    We have tried three approach.
    1. set max fetch record in form and block level.
    2. set max fetch time in form and block level.
    in above two method does not provide the appropiate solution for us.
    3. the third approach we applied is setting the interaction mode to "NON BLOCKING" at the form level.
    It seems to be worked, while the query took long time to execute, oracle app server prompts an message to press Esc to cancel the query and it a displaying the results fetched upto that point.
    But the drawback is one pressing esc, its killing the session itself. which is causing the entire application to collapse.
    Please suggest if there is any alternative approach for this or how to overcome this perticular scenario.
    This kind of facility is alreday present in TOAD and PL/SQL developer where we can stop an executing query and browse the results fetched upto that point, is the similar facility is avialable in oracle forms ,please suggest.
    Thanks and Regards,
    Suraj
    Edited by: user10673131 on Jun 25, 2009 4:55 AM

    Hello Friend,
    You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
    1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
    and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
    First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
    Please check the possbility of finding it through other AR tables.
    2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
    For example : For ra_cust_trx_types_all use ra_cust_trx_types.
    This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
    3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
    You can also check the same using
    SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
    If the tables are not analyzed , the CBO will not be able to tune your query.
    4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
    5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
    report.
    Thanks,
    Neeraj Shrivastava
    [email protected]
    Edited by: user9352949 on Oct 1, 2010 8:02 PM
    Edited by: user9352949 on Oct 1, 2010 8:03 PM

  • 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.

  • Select query running long time

    Hi,
    DB version : 10g
    platform : sunos
    My select sql query running long time (more than 20hrs) .Still running .
    Is there any way to find sql query completion time approximately. (Pending time)
    Also is there any possibilities to increase the speed of sql query (already running) like adding hints.
    Please help me on this .
    Thanks

    Hi Sathish thanks for your reply,
    I have already checked in V$SESSION_LONGOPS .But it's showing TIME_REMAINING -->0
    select TOTALWORK,SOFAR,START_TIME,TIME_REMAINING from V$SESSION_LONGOPS where SID='10'
    TOTALWORK      SOFAR START_TIME      TIME_REMAINING
         1099759    1099759 27-JAN-11                    0Any idea ?
    Thanks.

  • Select Query Takes more time

    Hi All,
    I have cloned KSB1 tcode to custom one as required by business.
    Below query takes more time than excepted.
    Here V_DB_TABLE = COVP.
    Values in Where clause are as follows
    OBNJR in ( KSBB010000001224  BT  KSBB012157221571)
    GJAHR in blank
    VERSN in '000'
    WRTTP in '04' and '11'
    all others are blank
    VT_VAR_COND = ( CPUDT BETWEEN '20091201' and '20091208' )
    SELECT (VT_FIELDS) INTO CORRESPONDING FIELDS OF GS_COVP_EXT      
                        FROM (V_DB_TABLE)                             
                        WHERE LEDNR = '00'                            
                        AND   OBJNR IN LR_OBJNR                       
                        AND   GJAHR IN GR_GJAHR                       
                        AND   VERSN IN GR_VERSN                       
                        AND   WRTTP IN GR_WRTTP                       
                        AND   KSTAR IN LR_KSTAR                       
                        AND   PERIO IN GR_PERIO                       
                        AND   BUDAT IN GR_BUDAT                       
                        AND   PAROB IN GR_PAROB                       
                        AND   (VT_VAR_COND).    
    Checked in table for this condition it has only 92 entries.
    But when i execute program takes long time as 3 Hrs.
    Could any one help me on this

    >1.Dont use SELECT/ENDSELECT instead use INTO TABLE addition .
    > 2.Avoid using corresponding addition.create a type and reference it.
    > If the select is going for dump beacause of storage limitations ,then use Cursors.
    you got three large NOs .... all three recommendations are wrong!
    The SE16 test is going in the right direction ... but what was filled. Nobody knows!!!!
    Select options:
    Did you ever try to trace the SE16?  The generic statement has for every field an in-condition!
    Without the information what was actually filled, nobody can say something there
    are at least 2**n  combinations possible!
    Use ST05 for SE16 and check actual statement plus explain!

  • 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;

  • How to set vo query at run time

    Hi,
    Is it possible to bind the where clause of query at run time.
    N :)

    Hi,
    Yes its possible.
    To add new where clause to your query.
    vo.setWhereClause(null);//If you want to remove any existing programmatically added where clause.
    vo.setWhereClause("Your new query");
    To bind varibales (Say there are 2 bind variables),
    First way to achieve this.
    setWhereClauseParam(null); //Always reset it to remove existing bindings)
    setWhereClauseParam(0, "Your first paramter value"); // Second parameter "Your first paramter value" is of type object.
    setWhereClauseParam(1, "Your first paramter value");
    In case you use "?" styly type binding, this count in above method starts with 1 instead of 0.
    Second way is to put all bind variables in an object array and pass to above method.
    Vector params=new Vector(2);
    params.addElement("FirstParameter");
    params.addElement("SecondParameter");
    Now call vo.executeQuery() to fetch the results as per new query.
    Abdul Wahid

  • Using Materilaized view in a query .. query is taking time????

    Hi I have a query :-
    SELECT rownum as id, u.last_name, u.first_name,u.phone phone, u.empid,u.supervisor id
    FROM emp_view u -- using view
    CONNECT BY PRIOR u.empid = u.supervisor_id
    START WITH u.sbcuid = 'ph2755';
    here emp_view is a view .
    ------ The above query is taking 3 sec to execute.
    Then I created Materialuized view emp_mv and the the MV query is same as emp_view view query.
    After this i executed following sql
    SELECT rownum as id, u.last_name, u.first_name,u.phone phone, u.empid,u.supervisor id
    FROM emp_mv u -- using materialized view
    CONNECT BY PRIOR u.empid = u.supervisor_id
    START WITH u.sbcuid = 'ph2755';
    this query is taking 15 sec to execute..... :(
    can anyone please tell me why MV query is taking time????

    Hi,
    In your first case you query a view, meaning that you query the underlying tables. These probably have indexes and stats are updated.
    In you second case you query a materialized view, meaning that you query the underlying base table of that mview.
    This probably do not have the same indexes to support that query.
    But of course, I'm just guessing based on the little information provided.
    If you want to take this further, please search for "When your query takes too long" and "How to post a tuning request".
    These two threads holds valuable information, not only on how to ask this kind of question, but also how to start solving it on your own.
    Regards
    Peter

  • Is index range scan the reason for query running long time

    I would like to know whether index range scan is the reason for the query running long time. Below is the explain plan. If so, how to optimise it? Please help
    Operation     Object     COST     CARDINALITY     BYTES
    SELECT STATEMENT ()          413     1000     265000
    COUNT (STOPKEY)                    
    FILTER ()                    
    TABLE ACCESS (BY INDEX ROWID)     ORDERS     413     58720     15560800
    INDEX (RANGE SCAN)     IDX_SERV_PROV_ID     13     411709     
    TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
    INDEX (UNIQUE SCAN)     SYS_C004605     1     1     
    TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
    INDEX (UNIQUE SCAN)     SYS_C004605     1     1     
    TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
    INDEX (UNIQUE SCAN)     SYS_C004605     1     1

    The index range scan means that the optimiser has determined that it is better to read the index rather than perform a full table scan. So in answer to your question - quite possibly but the alternative might take even longer!
    The best thing to do is to review your query and check that you need every table included in the query and that you are accessing the tables via the best route. For example if you can access a table via primary key index that would be better than using a non-unique index. But the best way of reducing the time the query takes to run is to give it less tables (and indexes) to read.
    John Seaman
    http://www.asktheoracle.net

  • 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

Maybe you are looking for