Selecting with rownum=1 taking time

Hi, I am using below script in one of my PL/SQL program. The strange thing is that this is taking time to execute. But If we gather stats on user_scheduler_job_run_details, it executes quickly. Looks like it is doing a full table scan in the 1st case. Any idea about why this is happening. SELECT * FROM user_scheduler_job_run_details where ROWNUM = 1 Thanks.

Hi,
1) USER_SCHEDULER_JOB_RUN_DETAILS is a view. How do you collect optimizer stats on a view?!
2) "the strange thing is that this is taking time to execute" -- there is nothing strange about that. Everything takes time. How much time does the query take exactly?
3) "looks like it is doing a full table scan" -- post appropriate diagnostic information for this query, e.g. SQL real-time monitor output, dbms_xplan.display_cursor output or tkprof'ed trace file.
Best regards,
Nikolay

Similar Messages

Select with no conditions taking long time, too many blocks, pctused?

select * from at_journal;is taking 15 seconds, which is absurd. I have similar situations with other log tables in this system.
(selecting with rownum < 5 and with first_rows hint still takes 15 seconds)
Suspicious parameters:
PCT_FREE 1
PCT_USED 99
(Some other log tables have PCT_FREE 5, PCTUSED 90)
The tables have frequent inserts, once every day all records older than 90 days get deleted.
After computing statistics:
Blocks: 42,304 (seems absurdly high)
Size: 663 Mb
NUM_ROWS: 505,966
After copying data without compression to new table:
Blocks: 3,785
Size: 60 Mb
NUM_ROWS: 505,966
The select on the new table is instantaneous.
On a side note, in general is compression for a table with frequent deletes OK? It seems OK to me.
Storage parameters of table creation script:
PCTUSED    99
PCTFREE    1
INITRANS   1
MAXTRANS   255
STORAGE    (
            INITIAL          64K
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            FREELISTS        1
            FREELIST GROUPS 1
            BUFFER_POOL      DEFAULT
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
NOMONITORING;I imagine that most blocks for the table are empty. In my mind pctused of 99 means most of the block space should be full. I have read several explanations of PCTUSED/pctfree including oracle documentation and it seems pctused of 99 means the block should be 99% full.
Much thanks,
goo

goo wrote:
I imagine that most blocks for the table are empty. In my mind pctused of 99 means most of the block space should be full. I have read several explanations of PCTUSED/pctfree including oracle documentation and it seems pctused of 99 means the block should be 99% full.Hello, you don't give your database version, but if you were using Automatic Segment Space Management you would not need to worry about the PCTUSED setting, and it could be that you already are:
1 select tablespace_name, segment_space_management
2 from dba_TABLESPACES
TABLESPACE_NAME                SEGMEN
SYSTEM                         MANUAL
SYSAUX                         AUTO
UNDOTBS1                       MANUAL
TEMP                           MANUAL
USERS                          AUTO
EXAMPLE                        AUTOAnd if you are already using ASSM, then the PCTUSED is not an issue (PCTFREE still applies, but it's not an issue in your case).
goo wrote:
On a side note, in general is compression for a table with frequent deletes OK? It seems OK to me.Frequent DELETEs could be an issue because they will not reset the High Watermark, though there will not be a performance penalty because of the compression for DELETEs (the record only needs to be located for a DELETE, not decompressed). Your PCTUSED, however, is high enough so that any newly deleted record slots should be quickly reused, but... it depends on how those new records are being INSERTed. If, as Daniel says, the HWM is being effectively bypassed (Direct Path INSERTs, etc.), then the table will grow in size every day, but the volume of records effectively stays just about the same.
Have a look at how the new records are being added to that table, if it's a:
INSERT /*+ APPEND */ INTO tableA
SELECT...Then the HWM is being advanced, and the newly vacated slots from the DELETEd records are not being reused. So the table will continually grow, for roughly the same amount of data, and there'll be a proportionately longer data retrieval time.

Af:table range navigation and select with rownum

I'm trying to use af:table to display some data (long list), but the value attribute always returns the entire list. (Basic example)
I'd like to use the range navigation so the application only select a sublist from the database (using rownum between x and y) and also display the navigation pane with all the pages, but I was only able to get the specific page with no navigation pane.
Does anyone have a good example on how to use the range navigation with selects/rownum?

Assuming I have an untitled1.jspx page with an Untitled1.java backing bean and an <af:table> on my page whose whose binding attribute is set to the EL expression #{Untitled1.table} to expose the table UI component in the backing bean, and a rangeChangeListener set to the EL expression #{Untitled1.onRangeChanged}, then with the following backing bean class, I seem to have been able to disable the user's picking the "Show all" option. It still appears in the list, but visually picking it stays on the current range of rows.
package test.backing;
import oracle.adf.view.faces.component.core.data.CoreTable;
import oracle.adf.view.faces.event.RangeChangeEvent;
public class Untitled1 {
private CoreTable table;
public Untitled1() {
public void onRangeChanged(RangeChangeEvent rangeChangeEvent) {
    int newStart = rangeChangeEvent.getNewStart();
    int newEnd = rangeChangeEvent.getNewEnd();
    if (newEnd - newStart > getTable().getRows()) {
      int oldEnd = rangeChangeEvent.getOldEnd();
      int oldStart = rangeChangeEvent.getOldStart();
      queueRangeChangeEventForTable(newStart, newEnd, oldStart, oldEnd);
private void queueRangeChangeEventForTable(int oldStart, int oldEnd,
                                             int newStart, int newEnd) {
    RangeChangeEvent rce =
      new RangeChangeEvent(getTable(), oldStart, oldEnd, newStart, newEnd);
    getTable().queueEvent(rce);
public void setTable(CoreTable table) {
    this.table = table;
public CoreTable getTable() {
    return table;
}

Select query taking time

THe following query is taking time. Is there anyway better to write this query.
SELECT PROGRAM_NAME_ID ,PROGRAM_NAME,sum(balance)"Unpaid Balance"
    FROM (
SELECT DISTINCT
PROGRAM_NAME_ID ,PROGRAM_NAME,
t.billing_key billing_key,
(TUFF_GENERIC_PKG.GET_TOTAL(t.billing_key,t.program_key)+
nvl(PENALTY_INTEREST(t.billing_key,t.program_key,b.company_id,b.report_period ),0))
-PAYMENT_AMOUNT(B.COMPANY_ID,T.PROGRAM_KEY,B.REPORT_PERIOD) Balance,
Report_period,company_id
FROM BILLING B,
PROG_SURCH T ,
mv_program_dict P
WHERE
B.BILLING_KEY=T.BILLING_KEY
AND p.program_key= t.program_key(+)
and company_id=:p3_hide_comp
and b.SUBMIT_STATUS='S'
union
SELECT DISTINCT
PROGRAM_NAME_ID ,PROGRAM_NAME,
t.billing_key billing_key,
(TUFF_GENERIC_PKG.GET_TOTAL(t.billing_key,t.program_key)+
nvl(PENALTY_INTEREST(t.billing_key,t.program_key,b.company_id,b.report_period ),0))
-PAYMENT_AMOUNT(B.COMPANY_ID,T.PROGRAM_KEY,B.REPORT_PERIOD) Balance,
Report_period,company_id
FROM MV_BILLING B,
MV_PROG_SURCH T ,
mv_program_dict P
WHERE
B.BILLING_KEY=T.BILLING_KEY
AND p.program_key= t.program_key(+)
and company_id=:p3_hide_comp
order by report_period,program_name_id )
where balance>=0
GROUP BY PROGRAM_NAME_ID,PROGRAM_NAME
ORDER BY PROGRAM_NAME_ID

Hi,
This is totally right.
>
Being one such call. The price for calling pl/sql functions in SQL can be quite high. I'd highly recommend you find a way to incorporate the pl/sql code into the SQL query.
>
but, try with this query. I hope would help you and return the rows you want.
SELECT   program_name_id, program_name,
           SUM ( tuff_generic_pkg.get_total (billing_key, program_key)
                + NVL (penalty_interest (billing_key,
                                         program_key,
                                         company_id,
                                         report_period
                       0
         - payment_amount (company_id, program_key, report_period) balance
    FROM (SELECT program_name_id, program_name, t.billing_key, t.program_key,
                 b.company_id, b.report_period
            FROM billing b, prog_surch t, mv_program_dict p
           WHERE b.billing_key = t.billing_key
             AND p.program_key = t.program_key(+)
             AND company_id = :p3_hide_comp
             AND b.submit_status = 'S'
          UNION
          SELECT program_name_id, program_name, t.billing_key, t.program_key,
                 b.company_id, b.report_period report_period, company_id
            FROM mv_billing b, mv_prog_surch t, mv_program_dict p
           WHERE b.billing_key = t.billing_key
             AND p.program_key = t.program_key(+)
             AND company_id = :p3_hide_comp) sub
   WHERE   ( tuff_generic_pkg.get_total (billing_key, program_key)
            + NVL (penalty_interest (billing_key,
                                     program_key,
                                     company_id,
                                     report_period
                   0
         - payment_amount (company_id, program_key, report_period) >= 0
GROUP BY program_name_id, program_nameObviosly I cannot testing.
HTH -- johnxjean --

LOV is slow after selecting a value its taking much time to default

Hi,
I have a dependent LOV. Master LOV is executing fine and its populatin into the field fastly. But Child LOV is very slow after selecting a value its taking much time to default.
Can any one please help me if there is any way to default the value fast after selecting a value?
Thanks,
Mahesh

Hi Gyan,
Same issues in TST and PROD instances.
In my search criteria if i get 1 record, even after selecting that value its taking much time to default that value into the field.
Please advice. Thanks for your quick resp.
Thanks,
Mahesh

How to use airport time capsule on a dell portable pc with windows 7 taking in consideration that Time machine doesn't run with Windows ?

how to use airport time capsule on a dell portable pc with windows 7 taking in consideration that time machine doesn't run with Windows ?

TM does not work like that.
If you want files to use later.. do not use TM.
Or do not use TM to the same location. Plug a USB drive into the computer and use that as the target for the permanent backup.
Read some details of how TM works so you understand what it will do.
http://pondini.org/TM/Works.html
Use a clone or different software for a permanent backup.
http://pondini.org/TM/Clones.html
How to use TC
http://pondini.org/TM/Time_Capsule.html
This is helpful.. particularly Q3.
Why you don't want to use TM.
Q20 here. http://pondini.org/TM/FAQ.html

My iphoto library database was corrupted with one file taking over all images i purchased aperture, selected no for importing duplicates and yet it is still importing duplicates what can i do??????

my iphoto library database was corrupted with one image taking over every other image on the database
i purchased aperture and am in the process of copying my i photo library , i ticked no to importing duplicate images and yet it is still importing many duplicates including the photo which took over my old iphoto library
help how can i stop it from importing the duplicates?

my iphoto library database was corrupted with one image taking over every other image on the database
What exactly do you mean by that? Do you mean one thumbnail only was visible in the iPhoto Window? What? This is the sort of thing that's fixed easily by an iPhoto rebuild. Gives us some more information and we may be able to help with that - iPhoto version and a description of exactly what's happening will help.
i ticked no to importing duplicate images and yet it is still importing many duplicates including the photo which took over my old iphoto library
A couple of thoughts here: If the iPhoto Library is corrupted and Aperture is importing from this damaged Library well you can't expect that it will all go easily, can you?
The iPhoto Library contains two versions of edited photos. Are you sure that you're not seeing the second version?
Regards
TD

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

Gl posting is taking time

Hi All,
Everyday we run a gl process. Gl posting is taking more 1 hr. Same way 4 gl posting run during gl process which is causing
performance delay.
I see in the the log file that below stage is taking time.
glpibr.concurrency() 02-MAR-2013 08:13:03
glpibr.concurrency() 02-MAR-2013 08:13:03
glpidb() 02-MAR-2013 08:46:41
glpidb() 02-MAR-2013 08:49:59
glpibr() 02-MAR-2013 08:49:59
This process itself takes more than 30 hours. It varies everyday. Sometime it takes 1 hr also.
insert into gl_balances
( set_of_books_id, code_combination_id, currency_code, period_name,
actual_flag, budget_version_id, encumbrance_type_id, last_update_date,
last_updated_by, period_type, period_year, period_num, period_net_dr, period_net_cr,
period_to_date_adb, quarter_to_date_dr, quarter_to_date_cr, quarter_to_date_adb, year_to_date_adb,
project_to_date_dr, project_to_date_cr, project_to_date_adb, begin_balance_dr, begin_balance_cr,
period_net_dr_beq, period_net_cr_beq, begin_balance_dr_beq, begin_balance_cr_beq, template_id, translated_flag )
select pi.set_of_books_id, pi.code_combination_id, pi.currency_code, pi.period_name, pi.actual_flag, pi.budget_version_id, pi.encumbrance_type_id, sysdate, :fnd_user_id, pi.period_type, pi.period_year, pi.period_num, 0, 0, NULL, 0, 0, NULL, NULL,
0, 0, NULL, 0, 0, NULL, NULL, NULL, NULL, pi.template_id, pi.translated_flag from gl_posting_interim_50130 pi where not exists ( select 'X' from gl_balances b where b.set_of_books_id = pi.set_of_books_id and b.code_combination_id = pi.code_combination_id and b.currency_code = pi.currency_code and
b.period_name = pi.period_name and b.actual_flag = pi.actual_flag and
nvl(b.encumbrance_type_id, -1) = nvl(pi.encumbrance_type_id, -1) and
nvl(b.budget_version_id, -1) = nvl(pi.budget_version_id, -1) and decode(b.translated_flag, '', '-1', 'Y', '0', 'N', '0', 'R', '1', b.translated_flag) = decode(pi.translated_flag, '', '-1', 'Y', '0', 'N', '0', 'R', '1', pi.translated_flag) )Above query is taking more than 30 mins as i can see in awrreport . As per metalink note id - 1096873.1 it is due to gl_posting_interim tables which is locking the another gl_interim_posting tables. I dont see any lock but i can see lots of gl_posting_interim present in the database. As per my knowledge this table must be dropped after posting got over.
Env details -
Apps version - 11.5.10.2
DB version - 11.2.0.1
OS - IBM AIX 6.1
Please suggest.
Thanks

Please see these docs.
R11i GLTTRN Translation Performance Issue In INSERT INTO GL_BALANCES [ID 761898.1]
Information Center: Optimizing Performance for Oracle General Ledger [ID 1489537.2]
Performance Issue With Translation Program After Upgrading To 10G Database [ID 742025.1]
Deleting Summary Accounts Has Poor Performance [ID 1088585.1]
GL Posting Performance Issue at glpip2() [ID 280641.1]
GLPPOS Performance Issue After 9i To 10g Upgrade in gluddl.lpc [ID 1262020.1]
Thanks,
Hussein

Insert statement taking time on oracle 10g

Hi,
My procedure taking time in following statement while database upgrading from oracle 9i to oracle 10g.
I m using oracle version 10.2.0.4.0.
cust_item is matiralize view in procedure and it is refreshing in the procedure
Index is dropping before inserting data into cust_item_tbl TABLE and after inserting data index is created.
There are almost 6 lac records into MV which are going to insert into TABLE.
In 9i below insert statement is taking 1 hr time to insert while in 10g it is taking 2.30 hrs.
EXECUTE IMMEDIATE 'ALTER SESSION ENABLE PARALLEL QUERY';
EXECUTE IMMEDIATE 'ALTER SESSION ENABLE PARALLEL DML';
INSERT INTO /*+ APPEND PARALLEL */ cust_item_tbl NOLOGGING
         (SELECT /*+ PARALLEL */
                 ctry_code, co_code, srce_loc_nbr, srce_loc_type_code,
                 cust_nbr, item_nbr, lu_eff_dt,
                 0, 0, 0, lu_end_dt,
                 bus_seg_code, 0, rt_nbr, 0, '', 0, '', SYSDATE, '', SYSDATE,
                 '', 0, ' ',
                               case
                             when cust_nbr in (select distinct cust_nbr from aml.log_t where CTRY_CODE = p_country_code and co_code = p_company_code)
                             THEN
                                     case
                                        when trunc(sysdate) NOT BETWEEN trunc(lu_eff_dt) AND trunc(lu_end_dt)
                                        then NVL((select cases_per_pallet from cust_item c where c.ctry_code = a.ctry_code and c.co_code = a.co_code
                                                      and c.cust_nbr = a.cust_nbr and c.GTIN_CO_PREFX = a.GTIN_CO_PREFX and c.GTIN_ITEM_REF_NBR = a.GTIN_ITEM_REF_NBR
                                                      and c.GTIN_CK_DIGIT = a.GTIN_CK_DIGIT and trunc(sysdate) BETWEEN trunc(c.lu_eff_dt) AND trunc(c.lu_end_dt) and rownum = 1),
                                                      a.cases_per_pallet)
                                  else cases_per_pallet
                              end
                      else cases_per_pallet
                 END cases_per_pallet,
                 cases_per_layer
            FROM cust_item a
           WHERE a.ctry_code = p_country_code ----varible passing by procedure
             AND a.co_code = p_company_code   ----varible passing by procedure
             AND a.ROWID =
                    (SELECT MAX (b.ROWID)
                       FROM cust_item b
                      WHERE b.ctry_code = a.ctry_code
                        AND b.co_code = a.co_code
                        AND b.ctry_code = p_country_code ----varible passing by procedure
                        AND b.co_code = p_company_code   ----varible passing by procedure
                        AND b.srce_loc_nbr = a.srce_loc_nbr
                        AND b.srce_loc_type_code = a.srce_loc_type_code
                        AND b.cust_nbr = a.cust_nbr
                        AND b.item_nbr = a.item_nbr
                        AND b.lu_eff_dt = a.lu_eff_dt));explain plan of oracle 10g
Plan
INSERT STATEMENT CHOOSECost: 133,310 Bytes: 248 Cardinality: 1
     5 FILTER
          4 HASH GROUP BY Cost: 133,310 Bytes: 248 Cardinality: 1
               3 HASH JOIN Cost: 132,424 Bytes: 1,273,090,640 Cardinality: 5,133,430
                    1 INDEX FAST FULL SCAN INDEX MFIPROCESS.INDX_TEMP_CUST_AUTH_PERF_MV Cost: 10,026 Bytes: 554,410,440 Cardinality: 5,133,430
                    2 MAT_VIEW ACCESS FULL MAT_VIEW MFIPROCESS.TEMP_CUST_AUTH_PERF_MV Cost: 24,570 Bytes: 718,680,200 Cardinality: 5,133,430 can you please look into the issue?
Thanks.

According to the execution plan you posted parallelism is not taking place - no parallel operations listed
Check the hint syntax. In particular, "PARALLEL" does not look right.
Running queries in parallel can either help performance, hurt performance, or do nothing for performance. In your case a parallel index scan on MFIPROCESS.INDX_TEMP_CUST_AUTH_PERF_MV using the PARALLEL_INDEX hint and the PARALLEL hint specifying the table for MAT_VIEW MFIPROCESS.TEMP_CUST_AUTH_PERF_MV Cost might help, something like (untested)
select /*+ PARALLEL_INDEX(INDX_TEMP_CST_AUTH_PERF_MV) PARALLEL(TEMP_CUST_AUTHPERF_MV) */Is query rewrite causing the MVs to be read? If so hinting the query will be tricky

How to use filter operator with ROWNUM

I would like to add filter operator in my mapping with ROWNUM to reduce the ETL loading time during testing to ensure mapping is working, but I don't know how, please help provide me some guideline. Thank you.

what is your owb version?
Starting with Oracle Warehouse Builder 10.2.0.3, you can use the pseudocolumns ROWID and ROWNUM in mappings. The ROWNUM pseudocolumn returns a number indicating the order in which a row was selected from a table. The ROWID pseudocolumn returns the rowid (binary address) of a row in a database table.
You can use the ROWID and ROWNUM pseudocolumns in Table, View, and Materialized View operators in a mapping. These operators contain an additional column called COLUMN USAGE that is used to identify attributes used as ROWID or ROWNUM. For normal attributes, this column defaults to TABLE USAGE. To use an attribute for ROWID or ROWNUM values, set the COLUMN USAGE to ROWID or ROWNUM respectively.
You can map a ROWID column to any attribute of data type ROWID, UROWID, or VARCHAR2. You can map ROWNUM column to an attribute of data type NUMBER or to any other data type that allows implicit conversion from NUMBER.
Note that ROWID and ROWNUM pseudocolumns are not displayed in the Data Object Editor since they are not real columns.
Edited by: Darthvader-647181 on Oct 29, 2008 9:18 AM

Create View taking time

Hi,
We are creating a view jusing the following query which is taking time. The query is as below,
SELECT
A.ICD_CODE AS ICD_CODE,
A.ICD_DESC AS ICD_DESC,
B.COMPL_ICD_CODE AS COMPL_ICD_CODE,
B.COMPL_GRP_TXT AS COMPL_GRP_TXT,
C.PROC_TYPE AS PROC_TYPE ,
C.I_O_IND AS I_O_IND,
C.DISC_MON AS QUARTER ,
B.PAT_KEY AS PAT_KEY ,
D.COMPL_TYPE_TXT AS COMPL_TYPE_TXT ,
C.PROV_ID AS PROV_ID ,
A.SPECIALTY AS SPECIALTY
FROM
EES_ICD_9_CODE A ,
EES_CLINICAL_COMPL_DATA B,
EES_CLINICAL_DATA C ,
EES_CLINCL_COMPL_ICD D
WHERE A.ICD_CODE=     B.ICD_CODE
                AND A. ICD_CODE= C.ICD_CODE
                AND B.ICD_CODE=D.ICD_9_CD
                AND B.COMPL_GRP_TXT=D.COMPL_GRP_TXT
                AND B.COMPL_ICD_CODE<>B.ICD_CODE
                AND C.PROC_TYPE <>'L'
                AND B.COMPL_GRP_TXT<>'Reoperations'
                AND D.COMPL_TYPE_TXT<>'Intra-operative Misadventure'
                UNION
                SELECT
A.ICD_CODE AS ICD_CODE,
A.ICD_DESC AS ICD_DESC,
B.COMPL_ICD_CODE AS COMPL_ICD_CODE,
B.COMPL_GRP_TXT AS COMPL_GRP_TXT,
C.PROC_TYPE AS PROC_TYPE ,
C.I_O_IND AS I_O_IND,
C.DISC_MON AS QUARTER ,
B.PAT_KEY AS PAT_KEY ,
D.COMPL_TYPE_TXT AS COMPL_TYPE_TXT ,
C.PROV_ID AS PROV_ID ,
A.SPECIALTY AS SPECIALTY
FROM
EES_ICD_9_CODE A ,
EES_CLINICAL_COMPL_DATA B,
EES_CLINICAL_DATA C ,
EES_CLINCL_COMPL_ICD D
WHERE A.ICD_CODE=     B.ICD_CODE
                AND A. ICD_CODE= C.ICD_CODE
                AND B.ICD_CODE=D.ICD_9_CD
                AND B.COMPL_GRP_TXT=D.COMPL_GRP_TXT
                AND B.COMPL_ICD_CODE<>B.ICD_CODE
                AND C.PROC_TYPE <>'L'
                AND D.COMPL_TYPE_TXT = 'Intra-operative Misadventure'
                AND B.PROC_DAY=C.PROC_DAY
UNION
                SELECT
A.ICD_CODE AS ICD_CODE,
A.ICD_DESC AS ICD_DESC,
B.COMPL_ICD_CODE AS COMPL_ICD_CODE,
B.COMPL_GRP_TXT AS COMPL_GRP_TXT,
C.PROC_TYPE AS PROC_TYPE ,
C.I_O_IND AS I_O_IND,
C.DISC_MON AS QUARTER ,
B.PAT_KEY AS PAT_KEY ,
D.COMPL_TYPE_TXT AS COMPL_TYPE_TXT ,
C.PROV_ID AS PROV_ID ,
A.SPECIALTY AS SPECIALTY
FROM
EES_ICD_9_CODE A ,
EES_CLINICAL_COMPL_DATA B,
EES_CLINICAL_DATA C ,
EES_CLINCL_COMPL_ICD D
WHERE A.ICD_CODE=     B.ICD_CODE
                AND A. ICD_CODE= C.ICD_CODE
                AND B.ICD_CODE=D.ICD_9_CD
                AND B.COMPL_GRP_TXT=D.COMPL_GRP_TXT
                AND B.COMPL_ICD_CODE<>B.ICD_CODE
                AND C.PROC_TYPE <>'L'
                AND B.COMPL_GRP_TXT='Reoperations'
                AND B.PROC_DAY>C.PROC_DAY
                AND (B.COMPL_ICD_CODE LIKE '45.%' OR   B.COMPL_ICD_CODE LIKE '46.%'           OR          B.COMPL_ICD_CODE LIKE '48.%' OR B.COMPL_ICD_CODE LIKE '49.%')
                )Here is the explain plan
PLAN_TABLE_OUTPUT
| Id | Operation                         | Name                    | Rows | Bytes |TempSpc| Cost |
|   0 | SELECT STATEMENT                  |                          | 5443M|   710G|       | 1687M|
|   1 | SORT UNIQUE                      |                          | 5443M|   710G| 1598G| 1687M|
|   2 |   UNION-ALL                       |                          |       |       |       |       |
|* 3 |    HASH JOIN                      |                          | 5371M|   700G|    34M| 11709 |
|* 4 |     HASH JOIN                     |                          |   281K|    31M| 4568K| 4679 |
|   5 |      MERGE JOIN CARTESIAN         |                          | 50225 | 3972K|       |   248 |
|   6 |       TABLE ACCESS FULL           | EES_ICD_9_CODE           |   123 | 5289 |       |     2 |
|   7 |       BUFFER SORT                 |                          |   408 | 15504 |       |   246 |
|* 8 |        TABLE ACCESS FULL          | EES_CLINCL_COMPL_ICD     |   408 | 15504 |       |     2 |
|* 9 |      TABLE ACCESS FULL            | EES_CLINICAL_COMPL_DATA | 2088K|    71M|       | 1860 |
|* 10 |     TABLE ACCESS FULL             | EES_CLINICAL_DATA        | 1911K|    41M|       | 2855 |
|* 11 |    HASH JOIN                      |                          | 5973K|   831M| 7216K| 9081 |
| 12 |     TABLE ACCESS BY INDEX ROWID   | EES_ICD_9_CODE           |     1 |    43 |       |     1 |
| 13 |      NESTED LOOPS                 |                          | 55969 | 6558K|       | 4265 |
| 14 |       NESTED LOOPS                |                          | 55970 | 4208K|       | 3146 |
|* 15 |        TABLE ACCESS FULL          | EES_CLINCL_COMPL_ICD     |    36 | 1368 |       |     2 |
|* 16 |        TABLE ACCESS BY INDEX ROWID| EES_CLINICAL_COMPL_DATA | 1555 | 60645 |       |    88 |
|* 17 |         INDEX RANGE SCAN          | COMPL_IND_ICD_CODE       | 56875 |       |       |   248 |
|* 18 |       INDEX RANGE SCAN            | ICD_CODE_INDEX_1         |     1 |       |       |     1 |
|* 19 |     TABLE ACCESS FULL             | EES_CLINICAL_DATA        | 1911K|    47M|       | 2855 |
|* 20 |    HASH JOIN                      |                          |    65M| 9142M| 8864K| 8943 |
|* 21 |     HASH JOIN                     |                          | 68740 | 8055K| 5432K| 2781 |
| 22 |      MERGE JOIN CARTESIAN         |                          | 59762 | 4727K|       |   248 |
| 23 |       TABLE ACCESS FULL           | EES_ICD_9_CODE           |   123 | 5289 |       |     2 |
| 24 |       BUFFER SORT                 |                          |   486 | 18468 |       |   246 |
|* 25 |        TABLE ACCESS FULL          | EES_CLINCL_COMPL_ICD     |   486 | 18468 |       |     2 |
|* 26 |      TABLE ACCESS FULL            | EES_CLINICAL_COMPL_DATA |   429K|    15M|       | 1860 |
|* 27 |     TABLE ACCESS FULL             | EES_CLINICAL_DATA        | 1911K|    47M|       | 2855 |
Predicate Information (identified by operation id):
   3 - access("A"."ICD_CODE"="C"."ICD_CODE")
   4 - access("A"."ICD_CODE"="B"."ICD_CODE" AND "B"."ICD_CODE"="D"."ICD_9_CD" AND
              "B"."COMPL_GRP_TXT"="D"."COMPL_GRP_TXT")
   8 - filter("D"."COMPL_TYPE_TXT"<>'Intra-operative Misadventure' AND
              "D"."COMPL_GRP_TXT"<>'Reoperations')
   9 - filter("B"."COMPL_ICD_CODE"<>"B"."ICD_CODE" AND "B"."COMPL_GRP_TXT"<>'Reoperations')
10 - filter("C"."PROC_TYPE"<>'L')
11 - access("A"."ICD_CODE"="C"."ICD_CODE" AND "B"."PROC_DAY"="C"."PROC_DAY")
15 - filter("D"."COMPL_TYPE_TXT"='Intra-operative Misadventure')
16 - filter("B"."COMPL_GRP_TXT"="D"."COMPL_GRP_TXT" AND "B"."COMPL_ICD_CODE"<>"B"."ICD_CODE")
17 - access("B"."ICD_CODE"="D"."ICD_9_CD")
18 - access("A"."ICD_CODE"="B"."ICD_CODE")
19 - filter("C"."PROC_TYPE"<>'L')
20 - access("A"."ICD_CODE"="C"."ICD_CODE")
       filter("B"."PROC_DAY">"C"."PROC_DAY")
21 - access("A"."ICD_CODE"="B"."ICD_CODE" AND "B"."ICD_CODE"="D"."ICD_9_CD" AND
              "B"."COMPL_GRP_TXT"="D"."COMPL_GRP_TXT")
25 - filter("D"."COMPL_GRP_TXT"='Reoperations')
26 - filter("B"."COMPL_ICD_CODE"<>"B"."ICD_CODE" AND "B"."COMPL_GRP_TXT"='Reoperations' AND
              ("B"."COMPL_ICD_CODE" LIKE '45.%' OR "B"."COMPL_ICD_CODE" LIKE '46.%' OR "B"."COMPL_ICD_CODE"
              '48.%' OR "B"."COMPL_ICD_CODE" LIKE '49.%'))
27 - filter("C"."PROC_TYPE"<>'L')
Note: cpu costing is off
61 rows selected.Please suggest any change for the query and where are the bottlenecks ?

Same question as above:
But how are you using the view?
You're presumably not planning to just do a select * from view with no additional views or predicates are you?Views that are that big and resource intensive would rarely be used in just a select * from view.
Presuambly that explain plan is from just the entire view source query or from the view actually being used in a SQL statement with further joins or predicates?
Those statements are what you need to get execution plans from to check that you're getting a predicate pushdown, etc
Otherwise, if the stats are accurate and the estimates are accurate and you are just doing a select * from view, where's the performance surprise?

Query with order by taking 1 hr

Hi,
Query with order by taking 1 hr, without order by taking 9 seconds,
pls tell me ,wat will be the reason and how to tune.
Query:
SELECT
T17.CONFLICT_ID,
T17.LAST_UPD,
T17.CREATED,
T17.LAST_UPD_BY,
T17.CREATED_BY,
T17.MODIFICATION_NUM,
T17.ROW_ID,
T1.ACCNT_TYPE_CD,
T36.X_BRIDGESTATION,
T36.X_CTI_PIN,
T36.X_FLOOR,
T36.X_SEGMENT2,
T36.X_SEGMENT3,
T36.X_CONTACT_STATUS,
T36.X_DEALING_CODE,
T36.X_DELETE,
T36.X_DEPARTMENT,
T36.X_DIRECT_MKT,
T36.X_FASS_LAST_CONTACT_DATE,
T36.X_SEGMENT1,
T36.X_LAST_TRAINED_DATE,
T36.X_LEGAL_CONSENT,
T36.X_LOCAL_FST_NAME,
T36.X_LOCAL_LAST_NAME,
T36.X_PREF_LANG,
T36.X_PROD_BLEND,
T36.X_SALUTATION,
T36.X_BSC_SIDE,
T36.X_END_USR_ACT,
T36.X_PRIM_ASSET_CLASS,
T36.X_SEC_ASSET_CLASS,
T36.X_STATUS,
T36.X_LANGUAGE,
T36.X_SUPPRESS_SMS_FLG,
T36.X_TRAINING_ADDRESS,
T36.X_UPD_TYPE,
T36.X_XTRA_UPD,
T36.X_XTRA_ID,
T36.X_ESERVICE_USER,
T36.X_SALES_COMMENTS,
T36.PR_DEPT_OU_ID,
T1.INTEGRATION_ID,
T1.PRTNR_FLG,
T36.BIRTH_DT,
T36.CELL_PH_NUM,
T9.ATTRIB_07,
T5.LAST_UPD,
T36.EMAIL_ADDR,
T36.EMP_FLG,
T36.FAX_PH_NUM,
T36.FST_NAME,
T36.HOME_PH_NUM,
T36.JOB_TITLE,
T36.LAST_NAME,
T36.SEX_MF,
T36.PER_TITLE,
T36.MID_NAME,
T36.OWNER_PER_ID,
T17.NAME,
T36.PERSON_UID,
T36.PRIV_FLG,
T1.NAME,
T29.PR_ADDR_ID,
T36.PR_REP_DNRM_FLG,
T36.PR_REP_MANL_FLG,
T36.PR_REP_SYS_FLG,
T36.PR_MKT_SEG_ID,
T36.PR_GRP_OU_ID,
T36.PR_OPTY_ID,
T36.PR_PER_ADDR_ID,
T36.PR_PER_PAY_PRFL_ID,
T36.PR_POSTN_ID,
T36.PR_RESP_ID,
T19.OWN_INST_ID,
T19.INTEGRATION_ID,
T36.SOC_SECURITY_NUM,
T29.STATUS,
T36.SUPPRESS_CALL_FLG,
T36.SUPPRESS_MAIL_FLG,
T36.WORK_PH_NUM,
T36.BU_ID,
T36.PR_ALT_PH_NUM_ID,
T36.PR_EMAIL_ADDR_ID,
T36.PR_SYNC_USER_ID,
T18.SHARE_HOME_PH_FLG,
T36.PR_REGION_ID,
T36.NATIONALITY,
T36.CITIZENSHIP_CD,
T36.AGENT_FLG,
T36.MEMBER_FLG,
T13.PR_EMP_ID,
T36.PR_OU_ADDR_ID,
T33.PR_EMP_ID,
T13.PR_EMP_ID,
T21.LOGIN,
T26.LOGIN,
T25.PR_FAX_NUM_ID,
T36.PR_INDUST_ID,
T36.PR_NOTE_ID,
T1.PR_POSTN_ID,
T36.PR_PROD_LN_ID,
T25.PR_SMS_NUM_ID,
T36.PR_SECURITY_ID,
T6.NAME,
T36.MED_SPEC_ID,
T36.PR_STATE_LIC_ID,
T36.PR_TERR_ID,
T36.PROVIDER_FLG,
T36.CUST_SINCE_DT,
T34.ADDR,
T34.CITY,
T34.COUNTRY,
T34.ZIPCODE,
T34.STATE,
T4.NAME,
T36.CURR_PRI_LST_ID,
T27.ROW_STATUS,
T22.LOGIN,
T2.CITY,
T2.COUNTRY,
T2.ZIPCODE,
T2.COUNTY,
T2.ADDR,
T20.X_ACC_CLASS,
T20.X_FS_INLIMITS,
T20.X_PRIORITY,
T20.X_DC_LOC,
T20.X_SERV_PROV_ID,
T20.X_FS_LOC,
T20.X_LOCAL_ACCOUNT_NAME,
T20.NAME,
T20.LOC,
T20.PR_BL_ADDR_ID,
T20.PR_BL_PER_ID,
T20.PR_SHIP_ADDR_ID,
T20.PR_SHIP_PER_ID,
T20.OU_NUM,
T16.ROW_ID,
T20.PR_SRV_AGREE_ID,
T16.ROW_ID,
T15.PRIM_MARKET_CD,
T16.ROW_ID,
T14.CITY,
T14.COUNTRY,
T14.ZIPCODE,
T14.STATE,
T14.ADDR,
T35.NAME,
T32.NAME,
T8.CHRCTR_ID,
T32.PRIV_FLG,
T3.LOGIN,
T31.LOGIN,
T36.ROW_ID,
T36.MODIFICATION_NUM,
T36.CREATED_BY,
T36.LAST_UPD_BY,
T36.CREATED,
T36.LAST_UPD,
T36.CONFLICT_ID,
T36.PAR_ROW_ID,
T25.ROW_ID,
T25.MODIFICATION_NUM,
T25.CREATED_BY,
T25.LAST_UPD_BY,
T25.CREATED,
T25.LAST_UPD,
T25.CONFLICT_ID,
T25.PAR_ROW_ID,
T18.ROW_ID,
T18.MODIFICATION_NUM,
T18.CREATED_BY,
T18.LAST_UPD_BY,
T18.CREATED,
T18.LAST_UPD,
T18.CONFLICT_ID,
T18.PAR_ROW_ID,
T9.ROW_ID,
T9.MODIFICATION_NUM,
T9.CREATED_BY,
T9.LAST_UPD_BY,
T9.CREATED,
T9.LAST_UPD,
T9.CONFLICT_ID,
T9.PAR_ROW_ID,
T19.ROW_ID,
T19.MODIFICATION_NUM,
T19.CREATED_BY,
T19.LAST_UPD_BY,
T19.CREATED,
T19.LAST_UPD,
T19.CONFLICT_ID,
T19.PAR_ROW_ID,
T27.ROW_ID,
T24.ROW_ID,
T23.ROW_ID,
T2.ROW_ID,
T28.ROW_ID,
T16.ROW_ID,
T11.ROW_ID,
T14.ROW_ID,
T35.ROW_ID,
T8.ROW_ID,
T30.ROW_ID,
T7.ROW_ID
FROM
SIEBEL.S_ORG_EXT T1,
SIEBEL.S_ADDR_PER T2,
SIEBEL.S_USER T3,
SIEBEL.S_PRI_LST T4,
SIEBEL.S_PER_DEDUP_KEY T5,
SIEBEL.S_MED_SPEC T6,
SIEBEL.S_PARTY T7,
SIEBEL.S_CON_CHRCTR T8,
SIEBEL.S_CONTACT_X T9,
SIEBEL.S_POSTN T10,
SIEBEL.S_CON_ADDR T11,
SIEBEL.S_POSTN T12,
SIEBEL.S_POSTN T13,
SIEBEL.S_ADDR_PER T14,
SIEBEL.S_ORG_EXT_FNX T15,
SIEBEL.S_PARTY T16,
SIEBEL.S_PARTY T17,
SIEBEL.S_EMP_PER T18,
SIEBEL.S_CONTACT_SS T19,
SIEBEL.S_ORG_EXT T20,
SIEBEL.S_USER T21,
SIEBEL.S_USER T22,
SIEBEL.S_CON_ADDR T23,
SIEBEL.S_PARTY T24,
SIEBEL.S_CONTACT_LOYX T25,
SIEBEL.S_USER T26,
SIEBEL.S_POSTN_CON T27,
SIEBEL.S_PARTY_PER T28,
SIEBEL.S_POSTN_CON T29,
SIEBEL.S_PARTY T30,
SIEBEL.S_USER T31,
SIEBEL.S_CHRCTR T32,
SIEBEL.S_POSTN T33,
SIEBEL.S_ADDR_PER T34,
SIEBEL.S_CONTACT_XM T35,
SIEBEL.S_CONTACT T36
WHERE
T36.PR_DEPT_OU_ID = T1.PAR_ROW_ID (+) AND
T1.PR_POSTN_ID = T33.PAR_ROW_ID (+) AND
T36.PR_POSTN_ID = T13.PAR_ROW_ID (+) AND
T17.ROW_ID = T29.CON_ID (+) AND T29.POSTN_ID (+) = '1-ERPTObjMgrSqlLog' AND
T33.PR_EMP_ID = T21.PAR_ROW_ID (+) AND
T13.PR_EMP_ID = T26.PAR_ROW_ID (+) AND
T36.PR_PER_ADDR_ID = T34.ROW_ID (+) AND
T36.MED_SPEC_ID = T6.ROW_ID (+) AND
T36.CURR_PRI_LST_ID = T4.ROW_ID (+) AND
T17.ROW_ID = T5.PERSON_ID (+) AND
T17.ROW_ID = T36.PAR_ROW_ID AND
T17.ROW_ID = T25.PAR_ROW_ID (+) AND
T17.ROW_ID = T18.PAR_ROW_ID (+) AND
T17.ROW_ID = T9.PAR_ROW_ID AND
T17.ROW_ID = T19.PAR_ROW_ID (+) AND
T36.PR_POSTN_ID = T27.POSTN_ID AND T36.ROW_ID = T27.CON_ID AND
T27.POSTN_ID = T24.ROW_ID AND
T27.POSTN_ID = T12.PAR_ROW_ID (+) AND
T12.PR_EMP_ID = T22.PAR_ROW_ID (+) AND
T36.PR_OU_ADDR_ID = T23.ADDR_PER_ID (+) AND T36.PR_DEPT_OU_ID = T23.ACCNT_ID (+) AND
T36.PR_OU_ADDR_ID = T2.ROW_ID (+) AND
T36.PR_DEPT_OU_ID = T28.PARTY_ID (+) AND T36.ROW_ID = T28.PERSON_ID (+) AND
T36.PR_DEPT_OU_ID = T16.ROW_ID (+) AND
T36.PR_DEPT_OU_ID = T20.PAR_ROW_ID (+) AND
T36.PR_DEPT_OU_ID = T15.PAR_ROW_ID (+) AND
T29.PR_ADDR_ID = T11.ADDR_PER_ID (+) AND T29.CON_ID = T11.CONTACT_ID (+) AND
T29.PR_ADDR_ID = T14.ROW_ID (+) AND
T36.X_SEGMENT1 = T35.ROW_ID (+) AND
T36.PR_MKT_SEG_ID = T8.ROW_ID (+) AND
T8.CHRCTR_ID = T32.ROW_ID (+) AND
T1.PR_POSTN_ID = T30.ROW_ID (+) AND
T1.PR_POSTN_ID = T10.PAR_ROW_ID (+) AND
T10.PR_EMP_ID = T3.PAR_ROW_ID (+) AND
T36.PR_SYNC_USER_ID = T7.ROW_ID (+) AND
T36.PR_SYNC_USER_ID = T31.PAR_ROW_ID (+) AND
((T36.X_DELETE = 'N') AND
(T36.PRIV_FLG = 'N' AND T17.PARTY_TYPE_CD != 'Suspect')) AND
(T9.ATTRIB_10 = 'NObjMgrSqlLog')
ORDER BY
T36.LAST_NAME, T36.FST_NAME

@afalty, the story you are telling about the order of the tables being important, from smallest to largest, et cetera, is only partially true and only when dealing with the rule based optimizer. Nowadays, almost everybody is using the cost based optimizer, so these remarks can very likely be ignored.
@original poster:
I think you are "measuring" the elapsed time by using TOAD, am I right? And you are probably writing 9 seconds, because it took TOAD 9 seconds before it could display the first records. If you would scroll down to the last record, it is likely taking much more time. A sort operation costs resources and time, but very unlikely this much.
When you want your rows sorted, all rows must have been visited before you know for sure which one is the smallest. That's why it takes longer to display the first row. Without an order by, the query can begin popping out rows much faster.
Regards,
Rob.

Database selection with invalid cursor !

hi experts,
When execute SAP BW processchar, it occur some system error: (sm21)
Database selection with invalid cursor
The database interface was called by a cursor (in a FETCH or CLOSE
cursor operation) that is not flagged as opened. This can occur if a
COMMIT or ROLLBACK was executed within a SELECT loop (which closes all
opened cursors), followed by another attempt to access the cursor (for
example, the next time the loop is executed).
this error occur when apply bw support package 19.
sap notes 1118584 Solution is: Import Support Package 17 . but my support package is 19.
how can i solve this error?
thanks,
xwu.

I am only assuming things, but it might be worth to look closely if you were experiencing an ORA- error during the execution. This could have caused a rollback and thus closed the cursor. Please check the job log, the workprocess trace (dev_wX file) and the system log SM21 and ST22 as well.
Besides that check the oracle alertlog and the usertrace destination.
Best regards, Michael

Database selection with invalid cursor with MaxDB database

Hi Experts,
I encountered the this error:
"Database selection with invalid cursor
The database interface was called by a cursor (in a FETCH or CLOSE
cursor operation) that is not flagged as opened. This can occur if a
COMMIT or ROLLBACK was executed within a SELECT loop (which closes all
opened cursors), followed by another attempt to access the cursor (for
example, the next time the loop is executed)."
We are using bw support package 19 early this month. Previously is working fine but this problem occured from the last 2 days.
We are using MaxDB database.
Really appreciate any speedy responds.

Hi,
We finally resolved the issue.
The solution:
We check the RFC connection test in SM59. There are connection error.
There is an error that related J2EE_ADMIN user.
SO we reset the J2EE_ADMIN id in SU01.
The problem goes away.
Many thanks

Selecting with rownum=1 taking time

Similar Messages

Maybe you are looking for