Query executes faster 2nd time

Hi,
So, the result% parameters are as follows, on a specific instance:
AME                                                                                   TYPE VALUE
result_cache_mode                                                                         2 MANUAL
result_cache_max_size                                                                     6 20971520
result_cache_max_result                                                                   3 5
result_cache_remote_expiration                                                            3 0
Executed in 0,156 secondsWell, if i run first time a large query, which takes much time (WITHOUT result_cache hint), this executes in 10 minutes. Then, some of my collegue said me second time i run the query i obtain the results faster than the first time, but i told him caching is not enabled, so why we got faster the results? The query execution plan is the same.
So, are any buffers, or something, from which the database retrieves the results when executing again that query? Or any explanation why it executes faster on subsequent invocations?
Thanks

Roger22 wrote:
So even if the result caching is not used, the data can be retrieved from the buffers.? okA fundamental concept for all databases and all modern file systems. A read-write memory cache that sits between the s/w and spinning rust.
Also the basic reason why measuring performance for comparison using elapsed time is flawed - as the very SAME query with the SAME execution plan on the SAME data can show DIFFERENT elapsed times. Amount of I/O is constant, but the type of I/O (logical/fast versus physical/slow) is not.

Similar Messages

  • Sql query executes faster 2. time despite clearing buffer cache/shared pool

    Hi All,
    I want to test query performance, so i clear cache in following way before each execution:
    alter system flush buffer_cache;
    alter system flush shared_pool;
    But, first execution takes more time than second and consequent executions. For example first execution takes 30 seconds, consequent executions take 3 seconds.
    Before each execution I clear the cache.
    What can be the reason? I use TOAD for query execution. Does TOAD caches something after first execution?
    And last question. Is there a dynamic query that query execution duration is stored?
    Any help will be appreciated.
    Thanks.

    >
    So there shouldn't be problem from the parameter, can you post result from V$SGA_DYNAMIC_COMPONENTS and v$SGAINFO ?
    V$SGA_DYNAMIC_COMPONENTS
    COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPECIFIED_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE
    shared pool 436207616 402653184 0 0 125 GROW IMMEDIATE 02-JUL-09 16777216
    large pool 201326592 117440512 0 83886080 12 SHRINK DEFERRED 02-JUL-09 16777216
    java pool 16777216 16777216 0 0 0 STATIC 16777216
    streams pool 16777216 16777216 0 0 0 STATIC 16777216
    DEFAULT buffer cache 1895825408 1711276032 0 16777216 137 GROW DEFERRED 02-JUL-09 16777216
    KEEP buffer cache 0 0 0 0 0 STATIC 16777216
    RECYCLE buffer cache 0 0 0 0 0 STATIC 16777216
    DEFAULT 2K buffer cache 0 0 0 0 0 STATIC 16777216
    DEFAULT 4K buffer cache 0 0 0 0 0 STATIC 16777216
    DEFAULT 8K buffer cache 0 0 0 0 0 STATIC 16777216
    DEFAULT 16K buffer cache 0 0 0 0 0 STATIC 16777216
    DEFAULT 32K buffer cache 0 0 0 0 0 STATIC 16777216
    ASM Buffer Cache 0 0 0 16777216 0 STATIC 16777216
    V$SGA_INFO
    NAME BYTES RESIZEABL
    Fixed SGA Size 2086392 No
    Redo Buffers 14688256 No
    Buffer Cache Size 1895825408 Yes
    Shared Pool Size 436207616 Yes
    Large Pool Size 201326592 Yes
    Java Pool Size 16777216 Yes
    Streams Pool Size 16777216 Yes
    Granule Size 16777216 No
    Maximum SGA Size 2634022912 No
    Startup overhead in Shared Pool 218103808 No
    Free SGA Memory Available 50331648

  • Query executation taking somuch time

    Hi
    I have created query on Inventory Cube(Copied from 0IC_C03).
    In cube maintainance i have changed the 'maintain non cumulative values' from calday and plant to only calday,
    because to get the correct data on day basis
    The query is based on material and vendor.
    it is taking so much time like 50 min to execute.
    I am thinking this is because of changing the 'maintain non cumulative values' in cube maintainance.
    But if i don't do that i can't get the correct values.
    Hope i explained the pbm very clearly.
    can anybody help me on this issue.
    I appreciate if anybody help me.
    Thanks
    Madhu

    HI,
    Have you tried other performance tuning activites, like creating aggregates, checked indices on the cube, etc.
    Also, did you give any filter criteria when running the query in the selection screens. If not do that as well.
    Suggest you run tcode ST03 in expert mode to check and see where the time is being taken and if needed run the query in debug mode using RSRT to see how best you can tune it further.
    Cheers,
    Kedar
    Cheers,
    Kedar

  • Query executing faster after restart

    Hi,
    I have a query which used to take around 60 seconds to execute. The query is mainly made up of joins and has an order by condition. The query was showing a service time of 125ms when accessing the temp datafile.
    When I restarted the server (windows) and database and I ran the query the execution time was 1 sec!! The query no longer seems to be accessing the temp file.
    Any suggestions on what could have triggered this change?
    Thanks
    Keith

    Because when you restart, the segments of the temp datafiles are deallocated. This means that you have space to do sort on disk if the sort of the query not have the sufficient space on SORT_AREA_SIZE
    < src = http://www.csee.umbc.edu/help/oracle8/server.815/a67775/ch24_pex.htm#43319 >
    SORT_AREA_SIZE
    The recommended values for this parameter fall in the range from 256KB to 4MB.
    This parameter specifies the amount of memory to allocate per query server process for sort operations. If you have a lot of system memory, you can benefit from setting SORT_AREA_SIZE to a large value. This can dramatically increase the performance of sort operations because the entire process is more likely to be performed in memory. However, if memory is a concern for your system, you may want to limit the amount of memory allocated for sort and hash operations.
    If the sort area is too small, an excessive amount of I/O is required to merge a large number of sort runs. If the sort area size is smaller than the amount of data to sort, then the sort will move to disk, creating sort runs. These must then be merged again using the sort area. If the sort area size is very small, there will be many runs to merge and multiple passes may be necessary. The amount of I/O increases as SORT_AREA_SIZE decreases.
    If the sort area is too large, the operating system paging rate will be excessive. The cumulative sort area adds up quickly because each query server process can allocate this amount of memory for each sort. For such situations, monitor the operating system paging rate to see if too much memory is being requested.
    < >

  • Query executing multiple times

    All,
    This question has been come up quite often in the OTN forum and i have not managed to get the answer. The issue is when i enable the logs i can see query getting fired multiple times :
    <TracingViewObjectSqlQueryExecution> <logQueryStatementAndBindParameters> ----[Exec query for VO=Kpi, RS=<Default>]----
    <TracingViewObjectSqlQueryExecution> <logQueryStatementAndBindParameters> ----[Exec COUNT query for VO=Kpi]----
    <TracingViewObjectSqlQueryExecution> <logQueryStatementAndBindParameters> VODef =com.xxx.model.uiView.KpiVO
    <TracingViewObjectSqlQueryExecution> <logQueryStatementAndBindParameters> SELECT
    kpi.kpi,
    kpi.kpi_desc,
    kpi.target,
    kpi_pkg.get_kpi_main (kpi.kpi, kpi.sale_type, :bSelectedSalesExecutiveId, :bSelectedBranchId ,:bOperatingUnitId, :bUserRole, :bPersonId, :bKpiRefresh) achieved,
    kpi.percentage,
    kpi.sale_type
    FROM    tableName kpi   
    WHERE  kpi.sale_type = NVL (:bSaleType, kpi.sale_type)
    ORDER BY tag
    <TracingViewObjectSqlQueryExecution> <logQueryStatementAndBindParameters> BindVars:(bUserRole=SE,bOperatingUnitId=81,bPersonId=31458,bSaleType=RETAIL,bSelectedBranchId=224,bSelectedSalesExecutiveId=31458,bKpiRefresh=Y)
    <TracingViewObjectSqlQueryExecution> <getQueryHitCount> ***** Query Hit Count = 6 *****
    <TracingViewObjectSqlQueryExecution> <logQueryStatementAndBindParameters> VODef =com.xxx.model.uiView.KpiVO
    <TracingViewObjectSqlQueryExecution> <logQueryStatementAndBindParameters> SELECT
    kpi.kpi,
    kpi.kpi_desc,
    kpi.target,
    kpi_pkg.get_kpi_main (kpi.kpi, kpi.sale_type, :bSelectedSalesExecutiveId, :bSelectedBranchId ,:bOperatingUnitId, :bUserRole, :bPersonId, :bKpiRefresh) achieved,
    kpi.percentage,
    kpi.sale_type
    FROM    tableName kpi   
    WHERE  kpi.sale_type = NVL (:bSaleType, kpi.sale_type)
    ORDER BY tag
    <TracingViewObjectSqlQueryExecution> <logQueryStatementAndBindParameters> BindVars:(bUserRole=SE,bOperatingUnitId=81,bPersonId=31458,bSaleType=RETAIL,bSelectedBranchId=224,bSelectedSalesExecutiveId=31458,bKpiRefresh=Y)This is one such case. These repetitive nature of the queries getting executed is making my application slow. On the logs i can see the first time query getting executed then waiting for it to finish then the same for the second time. Can any one give some inputs on this ?
    thnks
    Jdev 11.1.1.5

    thnks Frank for your reply.
    Ideally this query is supposed to run when the page is loaded however it has a complex calculation which takes 28 secs to complete. In order to load the page fast we dragged and dropped the collection as a table and added a button which executes the query. So the query gets executed on page load with a condition set as false so that no data is fetched - to speed the page load. However when we press the Refresh button the query gets re executed but as you can see 2 times. I can see the same effect on a nos of tables.

  • Query takes lots of time to execute how to minizie

    Hi ALL,
    I have a query like this which takes atleat 3 mins to execute how to optimiized the code from the below query
    how to minimize the time
    SELECT
    PRO.PROJECT_NAME "Project Name",
    POBJ.NAME "Object Name",
    X."Major" "Internal_Major",
    X."Minor" "Internal_Minor",
    X."Normalized" "Internal_Normalized",
    TRUNC(X."IDR",2) "Internal Defect Rate",
    Y."Major" "External_Major",
    Y."Minor" "External_Minor",
    Y."Normalized" "External_Normalized",
    TRUNC(Y."EDR",2) "External_Defect_Rate",
    PRO.ID "PRO_ID",
    POBJ.ID "POBJ_ID"
    FROM
    PROJECTS PRO, PROJECT_OBJECTS POBJ,
    (SELECT
    MN."PRO_ID",
    MN."POBJ_ID",
    MN."Major",
    MN."Minor",
    MN."Normalized",
    DR."IDR_PRO_ID",
    DR."IDR_POBJ_ID",
    DR."IDR"
    FROM IDR_TEST DR FULL OUTER JOIN MAJOR_MINOR_NORMALIZED MN
    ON
    MN."PRO_ID" = DR."IDR_PRO_ID" AND
    MN."POBJ_ID" = DR."IDR_POBJ_ID") X,
    (SELECT
    EE."PRO_ID" E_PRO_ID,
    EN."PRO_ID" EN_PRO_ID,
    EE."POBJ_ID" E_POBJ_ID,
    EN."POBJ_ID" EN_POBJ_ID,
    EN."Major",
    EN."Minor",
    EN."Normalized",
    EN."Normalized" / DECODE(EE."External_Effort",0,NULL,EE."External_Effort") "EDR"
    FROM
    EXTR_MAJOR_MINOR_NORMALIZED EN FULL OUTER JOIN EXTERNAL_EFFORT EE
    ON
    EE."PRO_ID" = EN."PRO_ID" AND
    EE."POBJ_ID" = EN."POBJ_ID") Y
    WHERE
    PRO.ID = :P1_PROJECTS AND
    PRO.ID = POBJ.PRO_ID AND
    :P1_PROJECTS = DECODE(X.PRO_ID,NULL,:P1_PROJECTS,X.PRO_ID) AND
    :P1_PROJECTS = DECODE(X.IDR_PRO_ID,NULL,:P1_PROJECTS,X.IDR_PRO_ID) AND
    POBJ.ID = DECODE(X.POBJ_ID,NULL,POBJ.ID,X.POBJ_ID) AND
    POBJ.ID = DECODE(X.IDR_POBJ_ID,NULL,POBJ.ID,X.IDR_POBJ_ID)
    AND
    :P1_PROJECTS = DECODE(Y.E_PRO_ID(+),NULL,:P1_PROJECTS,Y.E_PRO_ID(+)) AND
    :P1_PROJECTS = DECODE(Y.EN_PRO_ID(+),NULL,:P1_PROJECTS,Y.EN_PRO_ID(+)) AND
    POBJ.ID = DECODE(Y.E_POBJ_ID(+),NULL,POBJ.ID,Y.E_POBJ_ID(+)) AND
    POBJ.ID = DECODE(Y.EN_POBJ_ID(+),NULL,POBJ.ID,Y.EN_POBJ_ID(+))
    Problem is with the two full outer joins wht i am using
    there only i find the query taking too much time
    Thanks
    Sudhir
    Message was edited by:
    Sudhir_N
    Message was edited by:
    Sudhir_N

    You'll have to get an exection plan and manually tune the query.
    That aside, inline views can really slow queries down because once the data is stored in a temporary table you can't do fast indexed lookups on their result sets. They also make queries be more complicated. Also, outer joins tend to slow queries down a lot in general.

  • Urgen!! Query takes lots of time to execute and the production is in effect

    Hi,
    We have some data loading script. This scripts takes lots of time to execute. As Iam new to tunning please do let me know what is the wrong with the query !!
    Thanks In advance
    Query:
    =========
    INSERT /*+ PARALLEL */ INTO ris.ris_pi_profile
    (ID,COUNTRY_OF_CITIZENSHIP,IMMIGRATION_STATUS,SSN,DOB,GENDER,
    ETHNICITY,RACE,DEPARTMENT,DIVISION,INSTITUTION_ID,INST_EMAIL,EFFECT_DATE,ACADEMIC_TITLE,ACADEMIC_POSITION,
    OTH_PER_DATA,PCT_RESEARCH,PCT_TEACHING,PCT_CLINICAL,PCT_ADMIN,PCT_OTHER,PCT_TRAINING)
    SELECT
    ap.id,
    p.citizen_cd,
    decode(p.visa_cd,'CV',0,'F1',1,'H1',2,'H1B',3,'H2',4,'J1',5,'J2',6,'O1',7,'PR',8,'PRP',9,'TC',10,'TN',11,'TNN',12),
    (select n.soc_sec_num from sa.name n where n.name_id = p.name_id),
    (select n.birth_date from sa.name n where n.name_id = p.name_id),
    (select decode(n.gender_cd,'F',1,'M',2,0) from sa.name n where n.name_id = p.name_id),
    (select decode(n.ethnic_cd,'H',1) from sa.name n where n.name_id = p.name_id),
    (select decode(n.ethnic_cd,'A',2,'B',3,'I',1,'P',4,'W',5) from sa.name n where n.name_id = p.name_id),
    a.dept_name,
    a.div_name,
    a.inst_id,
    (select n.email from sa.name n where n.name_id = p.name_id),
    a.eff_date,
    ac.acad_pos_desc,
    p.acad_pos_cd,
    0,
    p.research_pct,
    p.teach_pct,
    p.patient_pct,
    p.admin_pct,
    p.other_pct,
    p.course_pct
    FROM
    appl1 ap,
    sa.personal_data p,
    sa.address a,
    sa.academic_pos_cd ac,
    profile_pi f
    WHERE
    p.project_role_cd='PI'
    and ap.appl_id=f.appl_id
    and p.appl_id=f.appl_id
    and p.name_id=f.name_id
    and a.addr_id=f.addr_id
    and p.acad_pos_cd=ac.acad_pos_cd
    AND EXISTS (select 1 from ris.ris_institution i WHERE i.id = a.inst_id)
    AND EXISTS (select 1 from sa.academic_pos_cd acp WHERE acp.acad_pos_cd = p.acad_pos_cd);
    In the execution PLan I see lots of Nested loop, Hash Join
    Index( Unique scan)
    Table Access by ( Index rowid)
    This query is fast in Test DB but ver very slow in prod DB. Need your help Urgent.
    Minaz

    When your query takes too long...
    When your query takes too long ...

  • Query is taking more time to execute

    Hi,
    Query is taking more time to execute.
    But when i execute same query in other server then it is giving immediate output.
    What is the reason of it.
    thanks in advance.

    'My car doesn't start, please help me to start my car'
    Do you think we are clairvoyant?
    Or is your salary subtracted for every letter you type here?
    Please be aware this is not a chatroom, and we can not see your webcam.
    Sybrand Bakker
    Senior Oracle DBA

  • Query is taking more time to execute in PROD

    Hi All,
    Can anyone tell me why this query is taking more time when I am using for single trx_number record it is working fine but when I am trying to use all the records it is not fatching any records and it is keep on running.
    SELECT DISTINCT OOH.HEADER_ID
    ,OOH.ORG_ID
    ,ct.CUSTOMER_TRX_ID
    ,ool.ship_from_org_id
    ,ct.trx_number IDP_SHIPMENT_ID
    ,ctt.type STATUS_CODE
    ,SYSDATE STATUS_DATE
    ,ooh.attribute16 IDP_ORDER_NBR --Change based on testing on 21-JUL-2010 in UAT
    ,lpad(rac_bill.account_number,6,0) IDP_BILL_TO_CUSTOMER_NBR
    ,rac_bill.orig_system_reference
    ,rac_ship_party.party_name SHIP_TO_NAME
    ,raa_ship_loc.address1 SHIP_TO_ADDR1
    ,raa_ship_loc.address2 SHIP_TO_ADDR2
    ,raa_ship_loc.address3 SHIP_TO_ADDR3
    ,raa_ship_loc.address4 SHIP_TO_ADDR4
    ,raa_ship_loc.city SHIP_TO_CITY
    ,NVL(raa_ship_loc.state,raa_ship_loc.province) SHIP_TO_STATE
    ,raa_ship_loc.country SHIP_TO_COUNTRY_NAME
    ,raa_ship_loc.postal_code SHIP_TO_ZIP
    ,ooh.CUST_PO_NUMBER CUSTOMER_ORDER_NBR
    ,ooh.creation_date CUSTOMER_ORDER_DATE
    ,ool.actual_shipment_date DATE_SHIPPED
    ,DECODE(mp.organization_code,'CHP', 'CHESAPEAKE'
    ,'CSB', 'CHESAPEAKE'
    ,'DEP', 'CHESAPEAKE'
    ,'CHESAPEAKE') SHIPPED_FROM_LOCATION --'MEMPHIS' --'HOUSTON'
    ,ooh.freight_carrier_code FREIGHT_CARRIER
    ,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)
    + NVL(XX_FSG_NA_FASTRAQ_IFACE.get_line_fr_amt ('FREIGHT',ct.customer_trx_id,ct.org_id),0)FREIGHT_CHARGE
    ,ooh.freight_terms_code FREIGHT_TERMS
    ,'' IDP_BILL_OF_LADING
    ,(SELECT WAYBILL
    FROM WSH_DELIVERY_DETAILS_OE_V
    WHERE -1=-1
    AND SOURCE_HEADER_ID = ooh.header_id
    AND SOURCE_LINE_ID = ool.line_id
    AND ROWNUM =1) WAYBILL_CARRIER
    ,'' CONTAINERS
    ,ct.trx_number INVOICE_NBR
    ,ct.trx_date INVOICE_DATE
    ,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('LINE',ct.customer_trx_id,ct.org_id),0) +
    NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) +
    NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('FREIGHT',ct.customer_trx_id,ct.org_id),0)INVOICE_AMOUNT
    ,NULL IDP_TAX_IDENTIFICATION_NBR
    ,NVL(XX_FSG_NA_FASTRAQ_IFACE.get_invoice_amount ('TAX',ct.customer_trx_id,ct.org_id),0) TAX_AMOUNT_1
    ,NULL TAX_DESC_1
    ,NULL TAX_AMOUNT_2
    ,NULL TAX_DESC_2
    ,rt.name PAYMENT_TERMS
    ,NULL RELATED_INVOICE_NBR
    ,'Y' INVOICE_PRINT_FLAG
    FROM ra_customer_trx_all ct
    ,ra_cust_trx_types_all ctt
    ,hz_cust_accounts rac_ship
    ,hz_cust_accounts rac_bill
    ,hz_parties rac_ship_party
    ,hz_locations raa_ship_loc
    ,hz_party_sites raa_ship_ps
    ,hz_cust_acct_sites_all raa_ship
    ,hz_cust_site_uses_all su_ship
    ,ra_customer_trx_lines_all rctl
    ,oe_order_lines_all ool
    ,oe_order_headers_all ooh
    ,mtl_parameters mp
    ,ra_terms rt
    ,OE_ORDER_SOURCES oos
    ,XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V
    WHERE ct.cust_trx_type_id = ctt.cust_trx_type_id
    AND ctt.TYPE <> 'BR'
    AND ct.org_id = ctt.org_id
    AND ct.ship_to_customer_id = rac_ship.cust_account_id
    AND ct.bill_to_customer_id = rac_bill.cust_account_id
    AND rac_ship.party_id = rac_ship_party.party_id
    AND su_ship.cust_acct_site_id = raa_ship.cust_acct_site_id
    AND raa_ship.party_site_id = raa_ship_ps.party_site_id
    AND raa_ship_loc.location_id = raa_ship_ps.location_id
    AND ct.ship_to_site_use_id = su_ship.site_use_id
    AND su_ship.org_id = ct.org_id
    AND raa_ship.org_id = ct.org_id
    AND ct.customer_trx_id = rctl.customer_trx_id
    AND ct.org_id = rctl.org_id
    AND rctl.interface_line_attribute6 = to_char(ool.line_id)
    AND rctl.org_id = ool.org_id
    AND ool.header_id = ooh.header_id
    AND ool.org_id = ooh.org_id
    AND mp.organization_id = ool.ship_from_org_id
    AND ooh.payment_term_id = rt.term_id
    AND xla_ael_sl_v.last_update_date >= NVL(p_last_update_date,xla_ael_sl_v.last_update_date)
    AND ooh.order_source_id = oos.order_source_id --Change based on testing on 19-May-2010
    AND oos.name = 'FASTRAQ' --Change based on testing on 19-May-2010
    AND ooh.org_id = g_org_id --Change based on testing on 19-May-2010
    AND ool.flow_status_code = 'CLOSED'
    AND xla_ael_sl_v.trx_hdr_id = ct.customer_trx_id
    AND trx_hdr_table = 'CT'
    AND xla_ael_sl_v.gl_transfer_status = 'Y'
    AND xla_ael_sl_v.accounted_dr IS NOT NULL
    AND xla_ael_sl_v.org_id = ct.org_id;
    -- AND ct.trx_number = '2000080';
    }

    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

  • SQL Query Executing longer time

    Hi , The below SQL query executing longer time . Please help to Improve the query performance. The query continuously running for more than 24 hours and failing with roolback segment error. Not getting the final output. Most of the tables are having milions of records.
    Select distinct
    IBS.ADSL_ACCESS_INFO,
    IBS.LIJ ,
    regexp_substr(OBVS.REFERENTIE_A,'[[:digit:]]+') as O_NUMBER,
    DBS.CKR_NUMMER_CONTRACTANT,
    DBS.DNUMBER
    FROM CD.IBS,
    CD.OIBL,
    CD.IH,
    CD.ODL,
    CD.OH,
    CD.DBS,
    CD.OBVS
    Where IBS.END_DT = To_Date('31129999', 'ddmmyyyy')
    AND OIBL.END_DT = to_date('31129999', 'ddmmyyyy')
    AND DBS.END_DT = to_date('31129999', 'ddmmyyyy')
    AND OBVS.END_DT = to_date('31129999', 'ddmmyyyy')
    AND OBVS.REFERENTIE_A LIKE 'OFM%'
    AND OIBL.INFRA_KEY = IH.INFRA_KEY
    AND OIBL.ORDERS_KEY = OH.ORDERS_KEY
    AND IBS.INFH_ID = IH.INFH_ID
    AND ODL.ORDH_ID = OH.ORDH_ID
    AND DBS.DEBH_ID = ODL.DEBH_ID
    AND OBVS.ORDH_ID = ODL.ORDH_ID
    Order By IBS.LIJ
    All the columns which are present in the where condition are having either Index/key (Primary/unique) except END_DT column.
    Please Advise

    Predicate pushing can help when it greatlly restricts the number of rows - you must experiment - might not work with all predicates pushed (as shown here)
    select distinct
           ibs.adsl_access_info,
           ibs.lij,
           obvs.o_number,
           dbs.ckr_nummer_contractant,
           dbs.dnumber
      from (select infh_id,adsl_access_info,lij
              from cd.ibs
             where end_dt = to_date('31129999','ddmmyyyy')
           ) ibs,
           (select infra_key,orders_key
              from cd.oibl
             where end_dt = to_date('31129999','ddmmyyyy')
           ) oibl,
           (select ordh_id,regexp_substr(obvs.referentie_a,'[[:digit:]]+') as o_number
              from cd.obvs
             where end_dt = to_date('31129999','ddmmyyyy')
               and referentie_a like 'OFM%'
           ) obvs,
           (select debh_id,ckr_nummer_contractant,dnumber
              from cd.dbs
             where end_dt = to_date('31129999','ddmmyyyy')
           ) dbs,
           cd.ih,
           cd.odl,
           cd.oh
    where oibl.infra_key = ih.infra_key
       and oibl.orders_key = oh.orders_key
       and ibs.infh_id = ih.infh_id
       and odl.ordh_id = oh.ordh_id
       and dbs.debh_id = odl.debh_id
       and obvs.ordh_id = odl.ordh_id
    order by ibs.lijRegards
    Etbin

  • IDM 7.1.1 objchange query executing against DB 66K times an hour?!

    Howdy folks,
    We just upgraded from 7.0 to 7.1.1. One of my co-workers mentioned that they though it was running a little slower. We spoke to a DB about when stats were getting calculated etc on the database, and she started to look at what was running. Turns out we have a statement executing 66,000 times an hour.... Any idea why? It seems like there should be no reason to execute this frequently, and it is biting in to our database cpu cycles....
    Here is the SQL if you are curious:
    SELECT timestamp, id, version, changeType FROM objchange WHERE timestamp > :1 AND type=:2 ORDER BY timestamp;

    Basil,
    Thanks for taking the time to answer all of the questions! It saves a lot of back/forth. The bad news is that no specific thing comes to mind. The sort of degradation you see could be caused by one or more of:
    o memory leaks (presumably not, because you're not running out)
    o memory fragmentation -- possible, but hard to measure
    o something odd going on in the DB cache -- nothing is obvious yet, but it's still being looked at.
    You are using MVCC, which may help diagnose things. Have you ever run without MVCC? I assume you are not using snaphot transactions for updates (if so, you should not be doing that).
    Have you tried looking at system/process information using tools like vmstat or top to detect anomalous VM and/or paging activity?
    If you come up with any additional information, please post it.
    Regards,
    George

  • What are the ways to make Query run fast?

    Hi Experts,
    When a query runs slow, we generally go for creating an aggregate. My doubt is - what other things can be done to make a query run faster before creating an aggregate? What is the thumb rule to be carried out for creating an aggregate?
    Regards,
    Shreeem

    Hi Shreem,
    If you keep Query simple not complicate it with runtime calculations , it would be smooth. However as per business requirements we will have to go for it anyways mostly.
    regarding aggregates:
    Please do not use the standard proposal , it will give you hundreds based on std. rules , which consumes lots of space and adds up to load times. If you have users already using the Query and you are planning to tune it  then go for the statistics tables:
    1.RSDDSTAT_OLAP    find the query with long runtimes  get the Stepuid
    2. RSDDSTAT_DM
    3. RSDDSTATAGGRDEF  - use the stepuid above to see which aggregate is necessary for which cube.
    Another way to check ; check the users as in 1 to find the highest runtime users and find the last used bookmarks by user thru RSZWBOOKMARK for this query and check if the time matches and create the aggregates as in 3 above.
    You can also Use Transaction RSRT > execute & debug  (display stats ) - to create generic aggregates to support navigations for New queries and later refine as above.
    Hope it helps .
    Thnks
    Ram

  • Query Database: reduce execution time

    Hi to all,
    I have Oracle 11g R2.
    I want reduce to max the execution time of this my select:
    SELECT a.ID, a.FULLNAME, a.L_AXON, a.R_AXON, a.L_LAXON, a.R_LAXON, a.L_F_F_ADD, a.R_F_F_ADD, a.L_T_F_ADD, a.R_T_F_ADD, a.L_PC, a.R_PC FROM ITALIA_GC a WHERE SDO_WITHIN_DISTANCE(a.GEOMETRY, MDSYS.SDO_GEOMETRY(2001, 8307, MDSYS.SDO_POINT_TYPE(13.8268523, 41.491619, NULL) ,NULL, NULL), 'DISTANCE=100 UNIT=M') = 'TRUE' AND ROWNUM=1;
    This query returns the name, city, postal code and address of a street of Italy. These datas are in ITALIA_GC table.
    I already created an spatial index on GEOMETRY field of this table:
    CREATE INDEX ITALIA_GC_IDX ON ITALIA_GC(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
    How can I see the execution time (i need to know the execution time in milliseconds) of this query and how can I reduce to max it?
    thank you very much in advance.
    Crystal

    Thank you.
    I used explain plan and SQL*Trace/tkprof method.
    What I would like to know is if the execution time are misured in seconds or milliseconds (I wish to know misure in millisecond).
    The result of SQL*Trace/tkprof method is:
    TKPROF: Release 11.2.0.1.0 - Development on Tue Jul 27 15:33:28 2010
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    Trace file: dbuir_ora_29053.trc
    Sort options: prsela  exeela  fchela 
    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
    SQL ID: 1bf1x0q79c1rm
    Plan Hash: 2374671442
    SELECT a.ID, a.FULLNAME, a.L_AXON, a.R_AXON, a.L_LAXON, a.R_LAXON,
      a.L_F_F_ADD, a.R_F_F_ADD, a.L_T_F_ADD, a.R_T_F_ADD, a.L_PC, a.R_PC
    FROM
    ITALIA_GC a WHERE SDO_WITHIN_DISTANCE(a.GEOMETRY, MDSYS.SDO_GEOMETRY(2001,
      8307, MDSYS.SDO_POINT_TYPE(13.8268523, 41.491619, NULL) ,NULL, NULL),
      'DISTANCE=100 UNIT=M') = 'TRUE' AND ROWNUM=1
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.02          0         30          2           0
    Fetch        2      0.00       0.00          0         14          0           1
    total        4      0.00       0.02          0         44          2           1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 85 
    Rows     Row Source Operation
          1  COUNT STOPKEY (cr=110 pr=0 pw=0 time=0 us)
          1   TABLE ACCESS BY INDEX ROWID ITALIA_GC (cr=110 pr=0 pw=0 time=0 us cost=0 size=4142 card=1)
          1    DOMAIN INDEX  ITALIA_GC_IDX (cr=109 pr=0 pw=0 time=0 us cost=0 size=0 card=0)
    SQL ID: 20y2xs9zmrbc5
    Plan Hash: 4105568395
    SELECT a."GEOMETRY"
    FROM
    "SPATIAL".ITALIA_GC a where a.rowid=:rid
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute     20      0.00       0.00          0          0          0           0
    Fetch       20      0.00       0.00          0         20          0          20
    total       41      0.00       0.00          0         20          0          20
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 85     (recursive depth: 1)
    Rows     Row Source Operation
          1  TABLE ACCESS BY USER ROWID ITALIA_GC (cr=1 pr=0 pw=0 time=0 us cost=1 size=3831 card=1)
    SQL ID: 9pxc8jgf3tj20
    Plan Hash: 1946957531
    SELECT diminfo, nvl(srid,-1)
    FROM
      ALL_SDO_GEOM_METADATA WHERE OWNER = :own AND TABLE_NAME = NLS_UPPER(:tab)
      AND '"'||COLUMN_NAME||'"' = :col
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1      0.00       0.00          0          0          0           0
    Fetch        1      0.00       0.00          0          9          0           1
    total        3      0.00       0.00          0          9          0           1
    Misses in library cache during parse: 0
    Optimizer mode: ALL_ROWS
    Parsing user id: 85     (recursive depth: 1)
    Rows     Row Source Operation
          1  VIEW  ALL_SDO_GEOM_METADATA (cr=9 pr=0 pw=0 time=0 us cost=25 size=654 card=2)
          1   UNION-ALL  (cr=9 pr=0 pw=0 time=0 us)
          1    MERGE JOIN CARTESIAN (cr=9 pr=0 pw=0 time=0 us cost=6 size=81 card=1)
          1     VIEW  ALL_OBJECTS (cr=7 pr=0 pw=0 time=0 us cost=5 size=45 card=1)
          1      FILTER  (cr=7 pr=0 pw=0 time=0 us)
          1       FILTER  (cr=7 pr=0 pw=0 time=0 us)
          1        NESTED LOOPS  (cr=7 pr=0 pw=0 time=0 us cost=5 size=124 card=1)
          1         NESTED LOOPS  (cr=6 pr=0 pw=0 time=0 us cost=4 size=102 card=1)
          1          TABLE ACCESS BY INDEX ROWID USER$ (cr=2 pr=0 pw=0 time=0 us cost=1 size=18 card=1)
          1           INDEX UNIQUE SCAN I_USER1 (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 46)
          1          TABLE ACCESS BY INDEX ROWID OBJ$ (cr=4 pr=0 pw=0 time=0 us cost=3 size=84 card=1)
          1           INDEX RANGE SCAN I_OBJ5 (cr=3 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 40)
          1         INDEX RANGE SCAN I_USER2 (cr=1 pr=0 pw=0 time=0 us cost=1 size=22 card=1)(object id 47)
          0       TABLE ACCESS BY INDEX ROWID IND$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)
          0        INDEX UNIQUE SCAN I_IND1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 41)
          0       HASH JOIN  (cr=0 pr=0 pw=0 time=0 us cost=3 size=24 card=1)
          0        INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=11 card=1)(object id 62)
          0        FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=2 size=48 card=2)
          0        INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=11 card=1)(object id 62)
          0        FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=2)
          0       HASH JOIN  (cr=0 pr=0 pw=0 time=0 us cost=3 size=24 card=1)
          0        INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=11 card=1)(object id 62)
          0        FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us)
          0        NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=7 size=78 card=1)
          0         NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=5 size=68 card=1)
          0          NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=4 size=57 card=1)
          0           MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=3 size=53 card=1)
          0            INDEX RANGE SCAN I_OBJ5 (cr=0 pr=0 pw=0 time=0 us cost=3 size=40 card=1)(object id 40)
          0            BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
          0             FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
          0           INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
          0          INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)(object id 62)
          0         INDEX RANGE SCAN I_DEPENDENCY1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=3)(object id 106)
          0        TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=10 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=2 size=72 card=2)
          0        NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=2 size=23 card=1)
          0         TABLE ACCESS BY INDEX ROWID TRIGGER$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=12 card=1)
          0          INDEX UNIQUE SCAN I_TRIGGER2 (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 162)
          0         INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)(object id 62)
          0        FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=2)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us)
          0        NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=7 size=78 card=1)
          0         NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=5 size=68 card=1)
          0          NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=4 size=57 card=1)
          0           MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=3 size=53 card=1)
          0            INDEX RANGE SCAN I_OBJ5 (cr=0 pr=0 pw=0 time=0 us cost=3 size=40 card=1)(object id 40)
          0            BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
          0             FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
          0           INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
          0          INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)(object id 62)
          0         INDEX RANGE SCAN I_DEPENDENCY1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=3)(object id 106)
          0        TABLE ACCESS BY INDEX ROWID DEPENDENCY$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=10 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       VIEW  (cr=0 pr=0 pw=0 time=0 us cost=2 size=13 card=1)
          0        FAST DUAL  (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=2 size=21 card=1)
          0        INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)(object id 62)
          0        FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=2 size=21 card=1)
          0        INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)(object id 62)
          0        FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
          0       FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
          0       VIEW  (cr=0 pr=0 pw=0 time=0 us cost=1 size=16 card=1)
          0        SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=1 size=86 card=1)
          0         NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=1 size=86 card=1)
          0          MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=0 size=78 card=1)
          0           NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=0 size=65 card=1)
          0            INDEX UNIQUE SCAN I_OLAP_CUBES$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 940)
          0            TABLE ACCESS BY INDEX ROWID OLAP_DIMENSIONALITY$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=52 card=1)
          0             INDEX RANGE SCAN I_OLAP_DIMENSIONALITY$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 944)
          0           BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
          0            INDEX FULL SCAN I_OLAP_CUBE_DIMENSIONS$ (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 928)
          0          INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=8 card=1)(object id 36)
          0       NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=2 size=29 card=1)
          0        INDEX FULL SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)(object id 47)
          0        INDEX RANGE SCAN I_OBJ4 (cr=0 pr=0 pw=0 time=0 us cost=1 size=9 card=1)(object id 39)
          1     BUFFER SORT (cr=2 pr=0 pw=0 time=0 us cost=6 size=36 card=1)
          1      TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE (cr=2 pr=0 pw=0 time=0 us cost=1 size=36 card=1)
          1       INDEX RANGE SCAN SDO_GEOM_IDX (cr=1 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 62259)
          0    FILTER  (cr=0 pr=0 pw=0 time=0 us)
          0     HASH JOIN  (cr=0 pr=0 pw=0 time=0 us cost=19 size=293 card=1)
          0      MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=18 size=238 card=1)
          0       NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=18 size=225 card=1)
          0        NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=17 size=221 card=1)
          0         NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=16 size=213 card=1)
          0          NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=15 size=209 card=1)
          0           NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=14 size=201 card=1)
          0            NESTED LOOPS OUTER (cr=0 pr=0 pw=0 time=0 us cost=13 size=196 card=1)
          0             NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=12 size=185 card=1)
          0              NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=11 size=181 card=1)
          0               NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=9 size=172 card=1)
          0                NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=8 size=144 card=1)
          0                 NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=7 size=123 card=1)
          0                  NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=6 size=120 card=1)
          0                   NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=5 size=90 card=1)
          0                    NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=2 size=54 card=1)
          0                     TABLE ACCESS BY INDEX ROWID USER$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=18 card=1)
          0                      INDEX UNIQUE SCAN I_USER1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 46)
          0                     TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE (cr=0 pr=0 pw=0 time=0 us cost=1 size=36 card=1)
          0                      INDEX RANGE SCAN SDO_GEOM_IDX (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 62259)
          0                    TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us cost=3 size=36 card=1)
          0                     INDEX RANGE SCAN I_OBJ2 (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 37)
          0                   TABLE ACCESS CLUSTER TAB$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=30 card=1)
          0                    INDEX UNIQUE SCAN I_OBJ# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 3)
          0                  TABLE ACCESS CLUSTER TS$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=3 card=1)
          0                   INDEX UNIQUE SCAN I_TS# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 7)
          0                 TABLE ACCESS CLUSTER COL$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=21 card=1)
          0                TABLE ACCESS CLUSTER COLTYPE$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=28 card=1)
          0               TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us cost=2 size=9 card=1)
          0                INDEX RANGE SCAN I_OBJ3 (cr=0 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 38)
          0              INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
          0             TABLE ACCESS CLUSTER SEG$ (cr=0 pr=0 pw=0 time=0 us cost=1 size=11 card=1)
          0              INDEX UNIQUE SCAN I_FILE#_BLOCK# (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=1)(object id 9)
          0            INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=5 card=1)(object id 36)
          0           INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=8 card=1)(object id 36)
          0          INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
          0         INDEX RANGE SCAN I_OBJ1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=8 card=1)(object id 36)
          0        INDEX RANGE SCAN I_USER2 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)(object id 47)
          0       BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=17 size=1300 card=100)
          0        FIXED TABLE FULL X$KSPPCV (cr=0 pr=0 pw=0 time=0 us cost=0 size=1300 card=100)
          0      FIXED TABLE FULL X$KSPPI (cr=0 pr=0 pw=0 time=0 us cost=0 size=55 card=1)
          0     NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=2 size=21 card=1)
          0      INDEX RANGE SCAN I_OBJAUTH1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=8 card=1)(object id 62)
          0      FIXED TABLE FULL X$KZSRO (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)
          0     FIXED TABLE FULL X$KZSPR (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)
    ********************************************************************************The result of Explain plan method is:
    PLAN_TABLE_OUTPUT
    Plan hash value: 2374671442
    | Id  | Operation                    | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
    PLAN_TABLE_OUTPUT
    |   0 | SELECT STATEMENT             |               |     1 |  4142 |     0   (0)                | 00:00:01 |
    |*  1 |  COUNT STOPKEY               |               |       |       |         |          |
    |   2 |   TABLE ACCESS BY INDEX ROWID| ITALIA_GC     | 49989 |   197M|     0   (0)| 00:00:01 |
    |*  3 |    DOMAIN INDEX              | ITALIA_GC_IDX |       |       |     0   (0)               | 00:00:01 |
    PLAN_TABLE_OUTPUT
    Predicate Information (identified by operation id):
       1 - filter(ROWNUM=1)
       3 - access("MDSYS"."SDO_WITHIN_DISTANCE"("A"."GEOMETRY","MDSYS"."SDO_GEOMETRY"(2001
    PLAN_TABLE_OUTPUT
                  ,8307,"MDSYS"."SDO_POINT_TYPE"(13.8268523,41.491619,NULL),NULL,NULL),'DISTANCE=100 UNIT=M')='TRUE')
    Note
       - dynamic sampling used for this statement (level=2)
    22 rows selected.thank you very much.

  • Query takes a long time on EBAN table

    Hi,
    I am trying to execute a simple select statement on EBAN table. This query takes unexpectionally longer time to execute.
    Query is :
    SELECT banfn bnfpo ernam badat ebeln ebelp
          INTO TABLE gt_eban
          FROM eban FOR ALL ENTRIES IN gt_ekko_ekpo
          WHERE
          banfn IN s_banfn AND
          ernam IN s_ernam
          and ebeln = gt_ekko_ekpo-ebeln AND
          ebelp = gt_ekko_ekpo-ebelp.
    Structure of gt_ekko_ekpo
    TYPES : BEGIN OF ty_ekko_ekpo,
            ebeln TYPE ekko-ebeln,
            ebelp TYPE ekpo-ebelp,
            bukrs TYPE ekko-bukrs,
            aedat TYPE ekko-aedat,
            lifnr TYPE ekko-lifnr,
            ekorg TYPE ekko-ekorg,
            ekgrp TYPE ekko-ekgrp,
            waers TYPE ekko-waers,
            bedat TYPE ekko-bedat,
            otb_value TYPE ekko-otb_value,
            otb_res_value TYPE ekko-otb_res_value,
            matnr TYPE ekpo-matnr,
            werks TYPE ekpo-werks,
            matkl TYPE ekpo-matkl,
            elikz TYPE ekpo-elikz,
            wepos TYPE ekpo-wepos,
            emlif TYPE ekpo-emlif,
      END OF ty_ekko_ekpo.
    Structure of GT_EBAN
    TYPES : BEGIN OF ty_eban,
      banfn TYPE eban-banfn,
      bnfpo TYPE eban-bnfpo,
      ernam TYPE eban-ernam,
      badat TYPE eban-badat,
      ebeln TYPE eban-ebeln,
      ebelp TYPE eban-ebelp,
      END OF ty_eban.
    Query seems to be OK to me. But still am not able to figure out the reason for this performance issue.
    Please provide your inputs.
    Thanks.
    Richa

    Hi Richa,
    Maybe you are executing the query with S_BANFN empty. Still based on the note 191492 you should change your query on like the following
    1st Suggestion:
    if gt_ekko_ekpo[] is not initial.
    SELECT banfn banfpo       INTO TABLE gt_eket
          FROM eket FOR ALL ENTRIES IN gt_ekko_ekpo
          WHERE
         ebeln = gt_ekko_ekpo-ebeln AND
          ebelp = gt_ekko_ekpo-ebelp.
    if sy-subrc = 0.
    delete gt_eket where banfn not in s_banfn.
    if gt_eket[] is not initial
    SELECT banfn bnfpo ernam badat ebeln ebelp
          INTO TABLE gt_eban
          FROM eban FOR ALL ENTRIES IN gt_eket
          WHERE
          banfn = gt_eket-banfn
         and  banfpo = gt_eket-banfpo.
    if sy-subrc = 0.
      delete gt_eban where ernam not in s_ernam.
    endif.
    endif.
    endif.
    endif.
    2nd Suggestion:
    if gt_ekko_ekpo[] is not initial.
    SELECT banfn banfpo       INTO TABLE gt_eket
          FROM eket FOR ALL ENTRIES IN gt_ekko_ekpo
          WHERE
         ebeln = gt_ekko_ekpo-ebeln AND
          ebelp = gt_ekko_ekpo-ebelp.
    if sy-subrc = 0.
    delete gt_eket where banfn not in s_banfn.
    if gt_eket[] is not initial
    SELECT banfn bnfpo ernam badat ebeln ebelp
          INTO TABLE gt_eban
          FROM eban FOR ALL ENTRIES IN gt_eket
          WHERE
          banfn = gt_eket-banfn
         and  banfpo = gt_eket-banfpo
         and ernam in s_ernam.
    endif.
    endif.
    endif.
    Hope this helps.
    Regards,
    R

  • Faster response time of queries

    I have a query which joins a few tables with seveeral thousand rows each. This query normaly returns tens of thousands and the response time is almost 10 minutes and it's not acceptable for web application.
    To speed it up I just want Oracle to return the first let's say 1000 rows.
    Changing the max rows returned parameter(APEX) to 1000 doesn't help at all. It seems like query executes in full and then only the first 1000 rows of the resultset are sent.
    So my question is: is there way to instruct Oracle to stop execution of the query once first n rows are retrieved?
    I tried the SELECT /* FIRST_ROWS(1000) */ .... but this doesn't help. and I wonder how could it when it seems that TOAD determines this as a comment and doesn't change the optimizer mode - still ALL_ROWS.
    What am I doing wrong here, this is the first time I am trying to use FIRST_ROWS hint , - is there another - better way to speed up my query?

    Hi Bob, thanks for the response. rownum < n was the first thing I tried. One would think that if a query takes 5 minutes to execute and returns 50 000 rows then after adding rownum < 5000 it shuldn't take more than a minute - well it takes pretty much the same time as w/out rownum < n. It seems like rownum is determined for the whole resultset and then the where codition is applied.
    The tables actually have much more than a few thousand rows. one is with close to 250 000 and couple other tables with over a million and I don't see much that I can optimize. I think being able to only return certain first n rows fast for web applications must be fairly common situation when dealing with large tables/views.

Maybe you are looking for

  • How can I print the top and bottom halves of 11x17 PDF on 8.5x11?

    I have a multi-page 11x17 PDF of quiz cards designed to be printed double-sided so that a question appears on one side and the answer on the other side. (Page 1 has the questions; page 2 has the answers.)  My printer is 8.5x11 so I would like to prin

  • Windows 7 On Lenovo X200. Please Help!

    Hi, I need help getting Windows 7 to work properly on my Lenovo X200 laptop. My X200 is dual-booted with Vista and has the Intel X4500. Here's what I need help with, I'll list them in order of importance to me. 1) Windows are messed up! (See the scre

  • Adobe PDF as a print option

    What do I need to do so that Adobe PDF is a print option? In other words, when I go to print something, instead of selecting a printer, I can select 'Print to Adobe PDF' and save the item on my hard drive as a pdf

  • SCCM 2012 How to gerenrate reports Microsoft Office 2003, 2007, 2010

    I need an sql query to generate a report that includes Microsoft Office 2010, 2007 and 2003 only.

  • OpenGL isn't updating- already at version Mac OS X 10.5.8

    Right now I have version 1.2 of OpenGL, but I need at least version 1.3 to access the application DAZ Studio (an application that I want to use). I am already in version 10.5.8, after just recently updating my software- but my OpenGL STILL remains at