Explain plan result for a long-running query used in data-warehousing. Tuni

I have executed an explain plan for a query that is used in a data-warehousing application.
This sql is taking too long to execute as it is visiting 24 partitions.
Where each partition contains data for 1 month month, so it fetches last 2 year data.
And each partition has a million or so rows.
All this is kept in table prescrip_retail. So this table has 24 partitions.
abc@def>explain plan set statement_id='dwh_query'
2 for
3 SELECT r.pier_account_id,
4 p.presc_num,
5 spm.product_id,
6 p.month,
7 t.best_call_state,
8 sum(p.trx_count)
9 FROM rlup_assigned_account r,
10 temp_presc_num_TEST t,
11 retail.prescrip_retail p,
12 sherlock.sherlock_product_mapping spm
13 WHERE spm.product_id like '056%'
14 and t.CLIENT_ID='934759'
15 and p.month >= add_months(sysdate,-24)
16 and spm.mds6 = p.product_id
17 and t.CLIENT_ID = p.presc_num
18 and r.ndc_pyr_id = p.payer_plan
19 and t.best_call_state = r.ST
20 GROUP BY r.pier_account_id,
21 p.presc_num,
22 spm.product_id,
23 p.month,
24 t.best_call_state;
Explained.
abc@def>ed
Wrote file afiedt.buf
1 select operation,options,optimizer,cost,cardinality,partition_start,partition_stop
2 from plan_table
3* where statement_id='dwh_query'
abc@def>/
OPERATION OPTIONS OPTIMIZER COST CARDINALITY
PARTITION_START
PARTITION_STOP
SELECT STATEMENT CHOOSE 850 1
SORT GROUP BY 850 1
NESTED LOOPS 848 1
HASH JOIN 845 3
HASH JOIN 842 6
TABLE ACCESS FULL ANALYZED 1 6
PARTITION RANGE ITERATOR
KEY
36
TABLE ACCESS BY LOCAL INDEX ROWID ANALYZED 839 166
KEY
36
BITMAP CONVERSION TO ROWIDS
BITMAP INDEX SINGLE VALUE
KEY
36
TABLE ACCESS FULL 2 50
TABLE ACCESS BY INDEX ROWID ANALYZED 1 149501
INDEX UNIQUE SCAN ANALYZED 149501
13 rows selected.

Here is the create statement for PRESCRIP_RETAIL table:
I have observed 2 things:
1. In the query the following joins are present.
13 WHERE spm.product_id like '056%'
14 and t.CLIENT_ID='934759'
15 and p.month >= add_months(sysdate,-24)
16 and spm.mds6 = p.product_id
17 and t.CLIENT_ID = p.presc_num
18 and r.ndc_pyr_id = p.payer_plan
19 and t.best_call_state = r.ST
Index exist for p.product_id,p.presc_num,p.payer_plan as you can see below.
However, the index does not exist for month.
I am also doing search for month.
I feel if I create a "partitioned index" on month, query performance should improve.
Q Can you provide me the syntax for creating a partitioned index on month?
2.The following tables are used in the query:
9 FROM rlup_assigned_account r,
10 temp_presc_num_TEST t,
11 retail.prescrip_retail p,
12 sherlock.sherlock_product_mapping spm
In these tables, apart from sherlock.sherlock_product_mapping table the statistics that exist is old.
I need to analyse on table level as well as column level.
For example:
Table prescrip_retail is analyzed in 2002,
table temp_presc_num_TEST is not analysed at all.
table rlup_assigned_account is analysed in Feb 2007.
sherlock_product_mapping is the only table that has updated statistics, analysed on Oct. 2007
Here is the table creation statement of PRESCRIP_RETAIL and index on it.
Prompt Table PRESCRIP_RETAIL;
-- PRESCRIP_RETAIL (Table)
-- Row count:2806673860
CREATE TABLE RETAIL.PRESCRIP_RETAIL
PRESC_NUM NUMBER,
PIER_NUM CHAR(8),
RELID CHAR(9) NOT NULL,
ME_NUM CHAR(10) NOT NULL,
PRODUCT_ID CHAR(6) NOT NULL,
PRODUCT_FRMSTR CHAR(1) NOT NULL,
PAYER_PLAN CHAR(6) NOT NULL,
MONTH DATE NOT NULL,
PYMT_CODE CHAR(1) NOT NULL,
NRX_COUNT NUMBER(7) NOT NULL,
NRX_QUANTITY NUMBER(9) NOT NULL,
NRX_DOLLARS NUMBER(13,2) NOT NULL,
TRX_COUNT NUMBER(7) NOT NULL,
TRX_QUANTITY NUMBER(9) NOT NULL,
TRX_DOLLARS NUMBER(13,2) NOT NULL
TABLESPACE PRESC_PARTITION_29
NOLOGGING
PARTITION BY RANGE (MONTH)
PARTITION PRESC200406 VALUES LESS THAN (TO_DATE(' 2004-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407 VALUES LESS THAN (TO_DATE(' 2004-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408 VALUES LESS THAN (TO_DATE(' 2004-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409 VALUES LESS THAN (TO_DATE(' 2004-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410 VALUES LESS THAN (TO_DATE(' 2004-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411 VALUES LESS THAN (TO_DATE(' 2004-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412 VALUES LESS THAN (TO_DATE(' 2005-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501 VALUES LESS THAN (TO_DATE(' 2005-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502 VALUES LESS THAN (TO_DATE(' 2005-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503 VALUES LESS THAN (TO_DATE(' 2005-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504 VALUES LESS THAN (TO_DATE(' 2005-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505 VALUES LESS THAN (TO_DATE(' 2005-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506 VALUES LESS THAN (TO_DATE(' 2005-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507 VALUES LESS THAN (TO_DATE(' 2005-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508 VALUES LESS THAN (TO_DATE(' 2005-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509 VALUES LESS THAN (TO_DATE(' 2005-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510 VALUES LESS THAN (TO_DATE(' 2005-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511 VALUES LESS THAN (TO_DATE(' 2005-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512 VALUES LESS THAN (TO_DATE(' 2006-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601 VALUES LESS THAN (TO_DATE(' 2006-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602 VALUES LESS THAN (TO_DATE(' 2006-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603 VALUES LESS THAN (TO_DATE(' 2006-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604 VALUES LESS THAN (TO_DATE(' 2006-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605 VALUES LESS THAN (TO_DATE(' 2006-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606 VALUES LESS THAN (TO_DATE(' 2006-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607 VALUES LESS THAN (TO_DATE(' 2006-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608 VALUES LESS THAN (TO_DATE(' 2006-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609 VALUES LESS THAN (TO_DATE(' 2006-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610 VALUES LESS THAN (TO_DATE(' 2006-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611 VALUES LESS THAN (TO_DATE(' 2006-12-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612 VALUES LESS THAN (TO_DATE(' 2007-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701 VALUES LESS THAN (TO_DATE(' 2007-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702 VALUES LESS THAN (TO_DATE(' 2007-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703 VALUES LESS THAN (TO_DATE(' 2007-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704 VALUES LESS THAN (TO_DATE(' 2007-05-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705 VALUES LESS THAN (TO_DATE(' 2007-06-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
TABLESPACE PRESC_PARTITION_29
NOCACHE
NOPARALLEL;
Prompt Index BX2_PRESC_PAYER;
-- BX2_PRESC_PAYER (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX2_PRESC_PAYER ON RETAIL.PRESCRIP_RETAIL
(PAYER_PLAN)
TABLESPACE PRESC_PARTITION_29
LOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX3_PRESC_PAYERCD;
-- BX3_PRESC_PAYERCD (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX3_PRESC_PAYERCD ON RETAIL.PRESCRIP_RETAIL
(PYMT_CODE)
TABLESPACE PRESC_PARTITION_29
NOLOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX4_PRESC_PRESC;
-- BX4_PRESC_PRESC (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX4_PRESC_PRESC ON RETAIL.PRESCRIP_RETAIL
(PRESC_NUM)
TABLESPACE PRESC_PARTITION_29
NOLOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX5_PRESC_PIER;
-- BX5_PRESC_PIER (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX5_PRESC_PIER ON RETAIL.PRESCRIP_RETAIL
(PIZR_NUM)
TABLESPACE PRESC_PARTITION_29
LOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX6_PRESC_RELID;
-- BX6_PRESC_RELID (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX6_PRESC_RELID ON RETAIL.PRESCRIP_RETAIL
(RELID)
TABLESPACE PRESC_PARTITION_29
LOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX7_PRESC_ME;
-- BX7_PRESC_ME (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX7_PRESC_ME ON RETAIL.PRESCRIP_RETAIL
(ME_NUM)
TABLESPACE PRESC_PARTITION_29
LOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;
Prompt Index BX1_PRESC_PROD;
-- BX1_PRESC_PROD (Index)
-- Dependencies:
-- PRESCRIP_RETAIL (Table)
CREATE BITMAP INDEX RETAIL.BX1_PRESC_PROD ON RETAIL.PRESCRIP_RETAIL
(PRODUCT_ID, PRODUCT_FRMSTR)
TABLESPACE PRESC_PARTITION_29
LOGGING
LOCAL (
PARTITION PRESC200406
NOLOGGING
TABLESPACE PRESC_PARTITION_30,
PARTITION PRESC200407
NOLOGGING
TABLESPACE PRESC_PARTITION_31,
PARTITION PRESC200408
NOLOGGING
TABLESPACE PRESC_PARTITION_32,
PARTITION PRESC200409
NOLOGGING
TABLESPACE PRESC_PARTITION_33,
PARTITION PRESC200410
NOLOGGING
TABLESPACE PRESC_PARTITION_34,
PARTITION PRESC200411
NOLOGGING
TABLESPACE PRESC_PARTITION_35,
PARTITION PRESC200412
NOLOGGING
TABLESPACE PRESC_PARTITION_36,
PARTITION PRESC200501
NOLOGGING
TABLESPACE PRESC_PARTITION_01,
PARTITION PRESC200502
NOLOGGING
TABLESPACE PRESC_PARTITION_02,
PARTITION PRESC200503
NOLOGGING
TABLESPACE PRESC_PARTITION_03,
PARTITION PRESC200504
NOLOGGING
TABLESPACE PRESC_PARTITION_04,
PARTITION PRESC200505
NOLOGGING
TABLESPACE PRESC_PARTITION_05,
PARTITION PRESC200506
NOLOGGING
TABLESPACE PRESC_PARTITION_06,
PARTITION PRESC200507
NOLOGGING
TABLESPACE PRESC_PARTITION_07,
PARTITION PRESC200508
NOLOGGING
TABLESPACE PRESC_PARTITION_08,
PARTITION PRESC200509
NOLOGGING
TABLESPACE PRESC_PARTITION_09,
PARTITION PRESC200510
NOLOGGING
TABLESPACE PRESC_PARTITION_10,
PARTITION PRESC200511
NOLOGGING
TABLESPACE PRESC_PARTITION_11,
PARTITION PRESC200512
NOLOGGING
TABLESPACE PRESC_PARTITION_12,
PARTITION PRESC200601
NOLOGGING
TABLESPACE PRESC_PARTITION_13,
PARTITION PRESC200602
NOLOGGING
TABLESPACE PRESC_PARTITION_14,
PARTITION PRESC200603
NOLOGGING
TABLESPACE PRESC_PARTITION_15,
PARTITION PRESC200604
NOLOGGING
TABLESPACE PRESC_PARTITION_16,
PARTITION PRESC200605
NOLOGGING
TABLESPACE PRESC_PARTITION_17,
PARTITION PRESC200606
NOLOGGING
TABLESPACE PRESC_PARTITION_18,
PARTITION PRESC200607
NOLOGGING
TABLESPACE PRESC_PARTITION_19,
PARTITION PRESC200608
NOLOGGING
TABLESPACE PRESC_PARTITION_20,
PARTITION PRESC200609
NOLOGGING
TABLESPACE PRESC_PARTITION_21,
PARTITION PRESC200610
NOLOGGING
TABLESPACE PRESC_PARTITION_22,
PARTITION PRESC200611
NOLOGGING
TABLESPACE PRESC_PARTITION_23,
PARTITION PRESC200612
NOLOGGING
TABLESPACE PRESC_PARTITION_24,
PARTITION PRESC200701
NOLOGGING
TABLESPACE PRESC_PARTITION_25,
PARTITION PRESC200702
NOLOGGING
TABLESPACE PRESC_PARTITION_26,
PARTITION PRESC200703
NOLOGGING
TABLESPACE PRESC_PARTITION_27,
PARTITION PRESC200704
NOLOGGING
TABLESPACE PRESC_PARTITION_28,
PARTITION PRESC200705
NOLOGGING
TABLESPACE PRESC_PARTITION_29
NOPARALLEL;

Similar Messages

How to avoid a timeout for a long-running query

Hello,
in my application I insert some rows in a temporary table on submit in a PL/SQL block on the page 1. Then I read these rows from the table on the page 2. Unfortunately the insert takes too long time, because I also have to make some other SELECTs etc in that block. That's why the application hits the Apache timeout for mod_plsql and HTTP error between pages 1 and 2.
I have found some threads about this topic in this forum. There are some suggestions with meta refresh tag etc. I understand, that I have to implement some kind of processing page between the pages 1 and 2 to show a waiting message etc. But I could not find any ready "cook book" for such implementation.
Could you please help me?
Thanks in advance
Andrej
P.S. This application don't use AJAX code, so I would prefer a solution without AJAX.

Hello Chris,
I am not sure, how to implement this approach. So I would start on the page 1 a job (dbms_scheduler or dbms_job), which would create a temporary table in the background. The application should branch to the page 3 with a message "Please wait...". I have to poll the results of the job and branch to the page 2, when the job is ready and I can select from the created temporary table. So far I like this way very much.
Could you please give me more details about the page 3 (polling page)? I have the following questions now:
1. I assume I have to set the meta refresh tag on this page. But in which PL/SQL block can I poll for the running job (on load process?).
2. How can I branch from this page to another page? If I only use refresh tag, how can I branch to another page only on the special condition (ready flag)?
Thanks in advance
Andrej

Explain Plan results analysis

I have EXPLAIN PLAN results for some SELECT queries. What is the difference between INDEX UNIQUE SCAN and INDEX RANGE SCAN?

btw it depend not only of your compare operation
but also on index type. See difference for equality between simple index and unique index:
SQL> desc a
Name                                      Null?    Type
A                                                  NUMBER
SQL> create index aidx on a (a);
Index created.
SQL> set autot traceonly explain
SQL> select * from a where a = 1;
Execution Plan
Plan hash value: 3649445643
| Id | Operation        | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |    13 |     1   (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| AIDX |     1 |    13 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("A"=1)
SQL> drop index aidx;
Index dropped.
SQL> create unique index aidx on a (a);
Index created.
SQL> select * from a where a = 1;
Execution Plan
Plan hash value: 2717653437
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |    13 |     0   (0)| 00:00:01 |
|* 1 | INDEX UNIQUE SCAN| AIDX |     1 |    13 |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("A"=1)
SQL> Of course even with unique index >, <, between will have range scan:
SQL> select * from a where a>1;
Execution Plan
Plan hash value: 3649445643
| Id | Operation        | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |    13 |     0   (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| AIDX |     1 |    13 |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("A">1)
SQL> In general index range scan might expect back more than 1 row, while index unique scan usually expect 1 row, however of course in both cases you might get zero rows back.
See my blog entry Where bad performance starts at http://gplivna.blogspot.com/2007/03/where-bad-performance-starts-my.html
it has many links aboput b-tree index internals, I'm quite sure some of them explained these operations more as well.
Gints Plivna
http://www.gplivna.eu

Explain for a very long running query

Dear gurus,
I have an issue with a long running query which takes around 2 hrs to execute. The tables being used here pertains to 11i, so there is no scope of indexing.
SELECT peia.expenditure_item_id, DECODE (peia.system_linkage_function, 'ST', 'TIME', 'EXP' ) AS CATEGORY,
pea.incurred_by_person_id AS employee_id, emp.attribute6 AS q_number, NVL (emp.employee_number, npw_number) AS employee_number, emp.full_name AS employee_name, peia.project_id,
ppa.segment1, ppa.NAME, func_get_proj_attribute (peia.project_id, NULL, 'PROJECT ENTITY NAME' ) AS project_entity,
func_get_proj_attribute (peia.project_id, NULL, 'PROJECT MANAGER') AS project_manager,
DECODE (ppa.distribution_rule, 'WORK/WORK', 'TM', 'WORK/EVENT', 'TM with Milestone' ) AS project_classification,
ppa.project_type AS funding_type, func_get_proj_attribute(peia.project_id, NULL, 'CUSTOMER GROUP' ) AS customer_group,
func_get_proj_attribute(peia.project_id, NULL, 'ACCOUNT MANAGER' ) AS account_manager,
pt.top_task_id, func_get_task_attribute(pt.top_task_id, 'TASK NUMBER' ) AS task_number,
func_get_task_attribute (pt.top_task_id, 'TASK NAME' ) AS task_name, peia.expenditure_item_date, peia.projfunc_raw_revenue AS func_raw_revenue,
peia.accrued_revenue AS func_accrued_revenue, peia.projfunc_currency_code,
DECODE (peia.project_raw_revenue, NULL,
DECODE (peia.system_linkage_function, 'ST', peia.quantity* NVL (peia.bill_rate, func_get_emp_billrate (pea.incurred_by_person_id, peia.project_id, peia.task_id,
peia.expenditure_item_date )
peia.quantity
peia.project_raw_revenue
( peia.accrued_revenue
/ peia.projfunc_raw_revenue
* peia.project_raw_revenue
) AS project_accrued_revenue,
ppa.project_currency_code,
NVL(peia.bill_rate, func_get_emp_billrate (pea.incurred_by_person_id, peia.project_id, peia.task_id, peia.expenditure_item_date)
) AS bill_rate,
peia.rev_dist_rejection_code, SYSDATE AS generated_date
FROM pa_expenditures_all pea
INNER JOIN (SELECT * FROM per_all_people_f WHERE SYSDATE BETWEEN effective_start_date AND effective_end_date) emp ON NVL(pea.incurred_by_person_id, 61) =emp.person_id
INNER JOIN (SELECT * FROM pa_expenditure_items_all WHERE billable_flag = 'Y' AND quantity <> 0) peia ON pea.expenditure_id =peia.expenditure_id
INNER JOIN (SELECT * FROM pa_projects_all WHERE project_status_code = 'APPROVED' AND distribution_rule IN ('WORK/WORK', 'WORK/EVENT')) ppa ON peia.project_id =ppa.project_id
INNER JOIN pa_tasks pt ON peia.task_id = pt.task_id;
The explain plan for this is:
SELECT STATEMENT CHOOSECost: 26,758 Bytes: 53,373,971 Cardinality: 245,963
     9 HASH JOIN Cost: 26,758 Bytes: 53,373,971 Cardinality: 245,963
          1 TABLE ACCESS FULL TABLE HR.PER_ALL_PEOPLE_F Cost: 67 Bytes: 546,900 Cardinality: 9,115
          8 HASH JOIN Cost: 26,581 Bytes: 20,174,029 Cardinality: 128,497
               2 TABLE ACCESS FULL TABLE PA.PA_TASKS Cost: 596 Bytes: 856,370 Cardinality: 85,637
               7 HASH JOIN Cost: 25,691 Bytes: 18,889,059 Cardinality: 128,497
                    3 TABLE ACCESS FULL TABLE PA.PA_EXPENDITURES_ALL Cost: 1,524 Bytes: 5,220,330 Cardinality: 522,033
                    6 HASH JOIN Cost: 23,701 Bytes: 17,604,089 Cardinality: 128,497
                         4 TABLE ACCESS FULL TABLE PA.PA_PROJECTS_ALL Cost: 91 Bytes: 49,059 Cardinality: 621
                         5 TABLE ACCESS FULL TABLE PA.PA_EXPENDITURE_ITEMS_ALL Cost: 23,575 Bytes: 68,913,570 Cardinality: 1,188,165
Can anyone suggests what can be done to improve this query?
Thanks in advance
SA
Edited by: user593719 on Oct 5, 2010 10:29 AM
Edited by: user593719 on Oct 5, 2010 10:30 AM

1) Your inner joins are doing record selections that could be done on the Join's ON clause.
2) Look at your functions to see if you can get performance improvements using parameterized CURSORs & adding DETERMINISTIC to the definition.
3) Consider using WITH to first pull your data & then running your functions.
For example:
with
smiths as (
select *
from hr.per_all_people_f papf
where papf.first_name='Smith'
select *
from smiths
where trunc(sysdate) between effective_start_date and effective_end_date;
In general, pare down your data first. Whatever will restrict your data most, start with selecting that table/view.

Long running query--- included steps given by Randolf

Hi,
I have done my best to follow Randolf instruction word-by-word and hope to get solution for my
problem soon. Sometime back I have posted a thread on this problem then got busy with other
stuff and was not able to follow it. Here I am again with same issue.
here is link for my previous post
long running query in database 10gHere is backgroud of my requriemment.
I am working on Oracle forms 10g which is using package given below. We want to display client information
with order count basd on different status like Pending, Error, back Order, expedited, std shipping.
Output will look something like.
client name   pending    error   backorder   expedited   std shipping
ABC            24         0       674          6789         78900
XYZ            35         673    5700           0           798274
.There are total 40 clients . The long running query are expedited and std shipping.
When i run package from Oracle Form Developer it takes 3 mintues to run but when I run same query in our application using forms
(which uses Oracle Application Server) it takes around 1 hour, which is completly unacceptable.
User wants it be done in less than 1 mintue.
I have tried combining Pending,error and backorder queries together but as far as I know it will not
work in Oracle Form as we need a place holder for each status.
Please dont think it is Forms related question, it is a Performance problem.
PACKAGE BODY ORDER_COUNT_PKG IS
PROCEDURE post_query IS
BEGIN
     BEGIN
          SELECT count(*)
            INTO :ORDER_STATUS.PENDING
            FROM orders o
        WHERE o.status = 'P'
             AND (parent_order_id is null
              OR (order_type='G'
                   AND parent_order_id=original_order_number))
                  AND o.client = :ORDER_STATUS.CLIENT_NUMBER;
     EXCEPTION
       WHEN OTHERS THEN
       NULL;
     END;
       BEGIN
           SELECT count(*)
             INTO :ORDER_STATUS.ERROR
             FROM orders o
            WHERE o.status = 'E'
              AND (parent_order_id is null
               OR (order_type='G'
                     AND parent_order_id=original_order_number))
                   AND o.client = :ORDER_STATUS.CLIENT_NUMBER;
            EXCEPTION
       WHEN OTHERS THEN
       NULL;
        END;
     BEGIN
          SELECT count(*)
            INTO :ORDER_STATUS.BACK_ORDER
            FROM orders o
        WHERE o.status = 'B'
             AND (parent_order_id is null
              OR (order_type='G'
                   AND parent_order_id=original_order_number))
                  AND o.client = :ORDER_STATUS.CLIENT_NUMBER;
      EXCEPTION
       WHEN OTHERS THEN
       NULL;
     END;
     BEGIN
          SELECT count(*)
            INTO :ORDER_STATUS.EXPEDITE
            FROM orders o,shipment_type_methods stm
           WHERE o.status in ('A','U')
         AND (o.parent_order_id is null
          OR (o.order_type = 'G'
         AND o.parent_order_id = o.original_order_number))
         AND o.client = stm.client
         AND o.shipment_class_code = stm.shipment_class_code
         AND (nvl(o.priority,'1') = '2'
          OR stm.surcharge_amount <> 0)
                  AND o.client = :ORDER_STATUS.CLIENT_NUMBER
          GROUP BY o.client;
          EXCEPTION
       WHEN OTHERS THEN
       NULL;
     END;
     BEGIN
          SELECT count(*)
            INTO :ORDER_STATUS.STD_SHIP
            FROM orders o,shipment_type_methods stm
           WHERE o.status in ('A','U')
         AND (o.parent_order_id is null
          OR (o.order_type = 'G'
         AND o.parent_order_id = o.original_order_number))
         AND nvl(o.priority,'1') <> '2'
         AND o.client = stm.client
         AND o.shipment_class_code = stm.shipment_class_code
         AND stm.surcharge_amount = 0
                  AND o.client = :ORDER_STATUS.CLIENT_NUMBER
          GROUP BY o.client;
      EXCEPTION
       WHEN OTHERS THEN
       NULL;
     END;
END post_query;
END ORDER_COUNT_PKG;one of the query which is taking long time is
SELECT count(*)
             FROM orders o,shipment_type_methods stm
           WHERE o.status in ('A','U')
         AND (o.parent_order_id is null
          OR (o.order_type = 'G'
         AND o.parent_order_id = o.original_order_number))
         AND nvl(o.priority,'1') <> '2'
         AND o.client = stm.client
         AND o.shipment_class_code = stm.shipment_class_code
         AND stm.surcharge_amount = 0
           AND o.client = :CLIENT_NUMBER
          GROUP BY o.clientThe version of the database is 10.2.1.0.2
SQL> alter session force parallel dml;These are the parameters relevant to the optimizer:
SQL> show parameter user_dump_dest
NAME                                 TYPE        VALUE
user_dump_dest                       string      /u01/app/oracle/admin/mcgemqa/
                                                 udump
SQL> show parameter optimizer
NAME                                 TYPE        VALUE
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      10.2.0.4
optimizer_index_caching              integer     0
optimizer_index_cost_adj             integer     100
optimizer_mode                       string      ALL_ROWS
optimizer_secure_view_merging        boolean     TRUE
SQL> show parameter db_file_multi
NAME                                 TYPE        VALUE
db_file_multiblock_read_count        integer     16
SQL> show parameter db_block_size
NAME                                 TYPE        VALUE
db_block_size                        integer     8192
SQL> show parameter cursor_sharing
NAME                                 TYPE        VALUE
cursor_sharing                       string      EXACTHere is the output of EXPLAIN PLAN:
SQL> explain plan for
2 SELECT count(*)
3         FROM orders o,shipment_type_methods stm
4       WHERE o.status in ('A','U')
5           AND (o.parent_order_id is null
6            OR (o.order_type = 'G'
7           AND o.parent_order_id = o.original_order_number))
8           AND nvl(o.priority,'1') <> '2'
9           AND o.client = stm.client
10           AND o.shipment_class_code = stm.shipment_class_code
11           AND stm.surcharge_amount = 0
12     AND o.client = :CLIENT_NUMBER
13    GROUP BY o.client
14 /
Explained.
Elapsed: 00:00:00.12
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 559278019
| Id | Operation                      | Name                    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                         |     1 |    35 | 46764   (3)| 00:09:22 |
|   1 | SORT GROUP BY NOSORT          |                         |     1 |    35 | 46764   (3)| 00:09:22 |
|* 2 |   TABLE ACCESS BY INDEX ROWID | ORDERS                  |   175K| 3431K| 25979   (3)| 00:05:12 |
|   3 |    NESTED LOOPS                |                         | 25300 |   864K| 46764   (3)| 00:09:22 |
|* 4 |     TABLE ACCESS BY INDEX ROWID| SHIPMENT_TYPE_METHODS   |     1 |    15 |     2   (0)| 00:00
|* 5 |      INDEX RANGE SCAN          | U_SHIPMENT_TYPE_METHODS |     2 |       |     1   (0)| 00:00:01 |
|* 6 |     INDEX RANGE SCAN           | ORDERS_ORDER_DATE       |   176K|       | 2371   (8)| 00:00:29 |
Predicate Information (identified by operation id):
   2 - filter(("O"."PARENT_ORDER_ID" IS NULL OR "O"."ORDER_TYPE"='G' AND
              "O"."PARENT_ORDER_ID"=TO_NUMBER("O"."ORIGINAL_ORDER_NUMBER")) AND NVL("O"."PRIORITY",'1')<>'2
              AND "O"."SHIPMENT_CLASS_CODE"="STM"."SHIPMENT_CLASS_CODE")
   4 - filter("STM"."SURCHARGE_AMOUNT"=0)
   5 - access("STM"."CLIENT"=:CLIENT_NUMBER)
   6 - access("O"."CLIENT"=:CLIENT_NUMBER)
       filter("O"."STATUS"='A' OR "O"."STATUS"='U')
24 rows selected.
Elapsed: 00:00:00.86
SQL> rollback;
Rollback complete.
Elapsed: 00:00:00.07Here is the output of SQL*Plus AUTOTRACE including the TIMING information:
SQL> SELECT count(*)
2         FROM orders o,shipment_type_methods stm
3       WHERE o.status in ('A','U')
4           AND (o.parent_order_id is null
5            OR (o.order_type = 'G'
6           AND o.parent_order_id = o.original_order_number))
7           AND nvl(o.priority,'1') <> '2'
8           AND o.client = stm.client
9           AND o.shipment_class_code = stm.shipment_class_code
10           AND stm.surcharge_amount = 0
11     AND o.client = :CLIENT_NUMBER
12    GROUP BY o.client
13 /
Elapsed: 00:00:03.09
Execution Plan
Plan hash value: 559278019
| Id | Operation                      | Name                    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                         |     1 |    35 | 46764   (3)| 00:09:22 |
|   1 | SORT GROUP BY NOSORT          |                         |     1 |    35 | 46764   (3)| 00:09:22 |
|* 2 |   TABLE ACCESS BY INDEX ROWID | ORDERS                  |   175K| 3431K| 25979   (3)| 00:05:12 |
|   3 |    NESTED LOOPS                |                         | 25300 |   864K| 46764   (3)| 00:09:22 |
|* 4 |     TABLE ACCESS BY INDEX ROWID| SHIPMENT_TYPE_METHODS   |     1 |    15 |     2   (0)| 00:00
|* 5 |      INDEX RANGE SCAN          | U_SHIPMENT_TYPE_METHODS |     2 |       |     1   (0)| 00:00:01 |
|* 6 |     INDEX RANGE SCAN           | ORDERS_ORDER_DATE       |   176K|       | 2371   (8)| 00:00:29 |
Predicate Information (identified by operation id):
   2 - filter(("O"."PARENT_ORDER_ID" IS NULL OR "O"."ORDER_TYPE"='G' AND
              "O"."PARENT_ORDER_ID"=TO_NUMBER("O"."ORIGINAL_ORDER_NUMBER")) AND NVL("O"."PRIORITY",'1')<>'2
              AND "O"."SHIPMENT_CLASS_CODE"="STM"."SHIPMENT_CLASS_CODE")
   4 - filter("STM"."SURCHARGE_AMOUNT"=0)
   5 - access("STM"."CLIENT"=:CLIENT_NUMBER)
   6 - access("O"."CLIENT"=:CLIENT_NUMBER)
       filter("O"."STATUS"='A' OR "O"."STATUS"='U')
Statistics
         55 recursive calls
          0 db block gets
       7045 consistent gets
          0 physical reads
          0 redo size
        206 bytes sent via SQL*Net to client
        238 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> disconnect
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> The TKPROF output for this statement looks like the following:
SELECT count(*)
       FROM orders o,shipment_type_methods stm
     WHERE o.status in ('A','U')
         AND (o.parent_order_id is null
          OR (o.order_type = 'G'
         AND o.parent_order_id = o.original_order_number))
         AND nvl(o.priority,'1') <> '2'
         AND o.client = stm.client
         AND o.shipment_class_code = stm.shipment_class_code
         AND stm.surcharge_amount = 0
   AND o.client = :CLIENT_NUMBER
GROUP BY o.client
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.04       0.04          0          0          0           0
Fetch        2      2.96       2.91          0       7039          0           1
total        4      3.01       2.95          0       7039          0           1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 95
Rows     Row Source Operation
      1 SORT GROUP BY NOSORT (cr=7039 pr=0 pw=0 time=2913701 us)
     91   TABLE ACCESS BY INDEX ROWID ORDERS (cr=7039 pr=0 pw=0 time=261997906 us)
     93    NESTED LOOPS (cr=6976 pr=0 pw=0 time=20740 us)
      1     TABLE ACCESS BY INDEX ROWID SHIPMENT_TYPE_METHODS (cr=2 pr=0 pw=0 time=208 us)
      3      INDEX RANGE SCAN U_SHIPMENT_TYPE_METHODS (cr=1 pr=0 pw=0 time=88 us)(object id 81957)
     91     INDEX RANGE SCAN ORDERS_ORDER_DATE (cr=6974 pr=0 pw=0 time=70 us)(object id 81547)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       2        0.00          0.00
SQL*Net message from client                     2        0.02          0.02
********************************************************************************The DBMS_XPLAN.DISPLAY_CURSOR output:
SQL> variable CLIENT_NUMBER varchar2(20)
SQL> exec :CLIENT_NUMBER := '14'
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.06
SQL> SELECT /*+ gather_plan_statistics */ count(*)
2         FROM orders o,shipment_type_methods stm
3       WHERE o.status in ('A','U')
4           AND (o.parent_order_id is null
5            OR (o.order_type = 'G'
6           AND o.parent_order_id = o.original_order_number))
7           AND nvl(o.priority,'1') <> '2'
8           AND o.client = stm.client
9           AND o.shipment_class_code = stm.shipment_class_code
10           AND stm.surcharge_amount = 0
11     AND o.client = :CLIENT_NUMBER
12    GROUP BY o.client
13 /
COUNT(*)
        91
Elapsed: 00:00:02.85
SQL> set termout on
SQL> select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID 4nfj368y8w6a3, child number 0
SELECT /*+ gather_plan_statistics */ count(*)        FROM orders o,shipment_type_methods stm      WHERE
o.status in ('A','U')          AND (o.parent_order_id is null           OR (o.order_type = 'G'
AND o.parent_order_id = o.original_order_number))          AND nvl(o.priority,'1') <> '2'          AND
o.client = stm.client          AND o.shipment_class_code = stm.shipment_class_code          AND
stm.surcharge_amount = 0    AND o.client = :CLIENT_NUMBER   GROUP BY o.client
Plan hash value: 559278019
| Id | Operation                      | Name                    | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
|   1 | SORT GROUP BY NOSORT          |                         |      1 |      1 |      1 |00:00:02.63 |    7039 |
|* 2 |   TABLE ACCESS BY INDEX ROWID | ORDERS                  |      1 |    175K|     91 |00:03:56.87 |    7039 |
|   3 |    NESTED LOOPS                |                         |      1 | 25300 |     93 |00:00:00.02 |    6976 |
|* 4 |     TABLE ACCESS BY INDEX ROWID| SHIPMENT_TYPE_METHODS   |      1 |      1 |      1 |00:00:00.01 |       2 |
|* 5 |      INDEX RANGE SCAN          | U_SHIPMENT_TYPE_METHODS |      1 |      2 |      3 |00:00:00.01 |       1 |
|* 6 |     INDEX RANGE SCAN           | ORDERS_ORDER_DATE       |      1 |    176K|     91 |00:00:00.01 |    6974 |
Predicate Information (identified by operation id):
   2 - filter((("O"."PARENT_ORDER_ID" IS NULL OR ("O"."ORDER_TYPE"='G' AND
              "O"."PARENT_ORDER_ID"=TO_NUMBER("O"."ORIGINAL_ORDER_NUMBER"))) AND NVL("O"."PRIORITY",'1')<>'
              "O"."SHIPMENT_CLASS_CODE"="STM"."SHIPMENT_CLASS_CODE"))
   4 - filter("STM"."SURCHARGE_AMOUNT"=0)
   5 - access("STM"."CLIENT"=:CLIENT_NUMBER)
   6 - access("O"."CLIENT"=:CLIENT_NUMBER)
       filter(("O"."STATUS"='A' OR "O"."STATUS"='U'))
32 rows selected.
Elapsed: 00:00:01.30
SQL> I'm looking forward for suggestions how to improve the performance of this statement.
Thanks
Sandy

Please find explain plan for No hint
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 559278019
| Id | Operation                      | Name                    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                         |     1 |    35 | 46764   (3)| 00:09:22 |
|   1 | SORT GROUP BY NOSORT          |                         |     1 |    35 | 46764   (3)| 00:09:22 |
|* 2 |   TABLE ACCESS BY INDEX ROWID | ORDERS                  |   175K| 3431K| 25979   (3)| 00:05:12 |
|   3 |    NESTED LOOPS                |                         | 25300 |   864K| 46764   (3)| 00:09:22 |
|* 4 |     TABLE ACCESS BY INDEX ROWID| SHIPMENT_TYPE_METHODS   |     1 |    15 |     2   (0)| 00:00
|* 5 |      INDEX RANGE SCAN          | U_SHIPMENT_TYPE_METHODS |     2 |       |     1   (0)| 00:00:01 |
|* 6 |     INDEX RANGE SCAN           | ORDERS_ORDER_DATE       |   176K|       | 2371   (8)| 00:00:29 |
Predicate Information (identified by operation id):
   2 - filter(("O"."PARENT_ORDER_ID" IS NULL OR "O"."ORDER_TYPE"='G' AND
              "O"."PARENT_ORDER_ID"=TO_NUMBER("O"."ORIGINAL_ORDER_NUMBER")) AND NVL("O"."PRIORITY",'1')<>'2
              AND "O"."SHIPMENT_CLASS_CODE"="STM"."SHIPMENT_CLASS_CODE")
   4 - filter("STM"."SURCHARGE_AMOUNT"=0)
   5 - access("STM"."CLIENT"=:CLIENT_NUMBER)
   6 - access("O"."CLIENT"=:CLIENT_NUMBER)
       filter("O"."STATUS"='A' OR "O"."STATUS"='U')
24 rows selected.
Elapsed: 00:00:00.86Explain Plan for Parallel Hint
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 559278019
| Id | Operation                      | Name                    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT               |                         |     1 |    35 | 46764   (3)| 00:09:22 |
|   1 | SORT GROUP BY NOSORT          |                         |     1 |    35 | 46764   (3)| 00:09:22 |
|* 2 |   TABLE ACCESS BY INDEX ROWID | ORDERS                  |   175K| 3431K| 25979   (3)| 00:05:12 |
|   3 |    NESTED LOOPS                |                         | 25300 |   864K| 46764   (3)| 00:09:22 |
|* 4 |     TABLE ACCESS BY INDEX ROWID| SHIPMENT_TYPE_METHODS   |     1 |    15 |     2   (0)| 00:00
|* 5 |      INDEX RANGE SCAN          | U_SHIPMENT_TYPE_METHODS |     2 |       |     1   (0)| 00:00:01 |
|* 6 |     INDEX RANGE SCAN           | ORDERS_ORDER_DATE       |   176K|       | 2371   (8)| 00:00:29 |
Predicate Information (identified by operation id):
   2 - filter(("O"."PARENT_ORDER_ID" IS NULL OR "O"."ORDER_TYPE"='G' AND
              "O"."PARENT_ORDER_ID"=TO_NUMBER("O"."ORIGINAL_ORDER_NUMBER")) AND NVL("O"."PRIORITY",'1')<>'2
              AND "O"."SHIPMENT_CLASS_CODE"="STM"."SHIPMENT_CLASS_CODE")
   4 - filter("STM"."SURCHARGE_AMOUNT"=0)
   5 - access("STM"."CLIENT"='14')
   6 - access("O"."CLIENT"='14')
       filter("O"."STATUS"='A' OR "O"."STATUS"='U')
24 rows selected.
Elapsed: 00:00:08.92Explain Plan for USE_Hash hint
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1465232248
| Id | Operation                     | Name                    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |                         |     1 |    35 | 46786   (3)| 00:09:22 |
|   1 | SORT GROUP BY NOSORT         |                         |     1 |    35 | 46786   (3)| 00:09:22 |
|* 2 |   HASH JOIN                   |                         | 25300 |   864K| 46786   (3)| 00:09:22 |
|* 3 |    TABLE ACCESS BY INDEX ROWID| SHIPMENT_TYPE_METHODS   |     1 |    15 |     2   (0)| 00:00:0
|* 4 |     INDEX RANGE SCAN          | U_SHIPMENT_TYPE_METHODS |     2 |       |     1   (0)| 00:00:01 |
|* 5 |    TABLE ACCESS BY INDEX ROWID| ORDERS                  |   175K| 3431K| 46763   (3)| 00:09:22 |
|* 6 |     INDEX RANGE SCAN          | ORDERS_ORDER_DATE       |   176K|       | 4268   (8)| 00:00:52 |
Predicate Information (identified by operation id):
   2 - access("O"."CLIENT"="STM"."CLIENT" AND "O"."SHIPMENT_CLASS_CODE"="STM"."SHIPMENT_CLASS_COD
              E")
   3 - filter("STM"."SURCHARGE_AMOUNT"=0)
   4 - access("STM"."CLIENT"='14')
   5 - filter(("O"."PARENT_ORDER_ID" IS NULL OR "O"."ORDER_TYPE"='G' AND
              "O"."PARENT_ORDER_ID"=TO_NUMBER("O"."ORIGINAL_ORDER_NUMBER")) AND NVL("O"."PRIORITY",'1')<>'2
   6 - access("O"."CLIENT"='14')
       filter("O"."STATUS"='A' OR "O"."STATUS"='U')
25 rows selected.
Elapsed: 00:00:01.09
SQL> Thanks
Sandy

HT1688 when you double tap the home button to go back to your other apps are those apps always running and using cellular data even if I am not currently using them? I thought it froze them and didn't use data other that a select few apps like Facebook,

when you double tap the home button to go back to your other apps are those apps always running and using cellular data even if I am not currently using them? I thought it froze them and didn't use data other that a select few apps like Facebook, email, etc. Also I always select no when I download an app and it wants me to have those push notifications. Because that would mean that I would have to delete my apps after everytime I just them from that bar and that would be very annoying and just stupid. Or maybe apps do use data and it's just a big scheme to make everyone go over on their data plans.

This should help: http://speirs.org/blog/2012/1/2/misconceptions-about-ios-multitasking.html.

Is it possible to implemnt af:query using JavaBean Data Control?

Is it possible to implemnt af:query using JavaBean Data Control?

Fortunately for you and me, Oracle documents this stuff.
http://docs.oracle.com/cd/E17904_01/web.1111/b31974/appendix_datacontrols.htm#BABGECDA

Explain plan different for same query

Hi all,
I have a query, which basically selects some columns from a remote database view. The query is as follows:
select * from tab1@remotedb, tab2@remotedb
where tab1.cash_id = tab2.id
and tab1.date = '01-JAN-2003'
and tab2.country_code = 'GB';
Now, i am working on two environments, one is production and other is development. Production environment has following specification:
1. Remotedb = Oracle9i, Linux OS
2. Database on which query is running = Oracle10g, Linux OS
Development environment has following specification:
1. Remotedb = Oracle10g, Windows OS
2. Database on which query is running = Oracle10g, Linux OS
Both databases in development and production environments are on different machines.
when i execute the above query on production, i see full table scans on both tables in execution plan(TOAD), but when i execute the query in development, i see that both remote database tables are using index.
Why am i getting different execution plans on both databases? is there is any difference of user rights/priviliges or there is a difference of statistics on both databases. I have checked the statistics for both tables on Production and Development databases, they are updated.
This issue is creating a performance disaster in our Production system. Any kind of help or knowledge sharing is appreciated.
Thank you and Best Regards.

We ran into a similar situation yesterday morning, though our implementation was easier than yours. Different plans in development and production though both systems were 10gR2 at the time. Production was doing a Merge Join Cartesian (!) instead of nested loop joins. Our DBA figured out that the production stats had been locked for some tables preventing stat refresh; she unlocked them and re-analyzed so which fixed our problem.
Of some interest was discovering that I got different execution plans from the same UPDATE via EXPLAIN PLAN and SQL*PLUS AUTOTRACE in development. Issue appears to have been bind peeking. Converting bind variables to constants yielded the AUTOTRACE plan, as did turning bind peeking off while using the bind variables. CURSOR_SHARING was set to EXACT too.
Message was edited by:
riedelme

Explain plan changing for the same sql

Hi All,
In a E Business suite application, we have the 10.2.0.4 Database.
One of the program is running a select stmt which is using different explain plan one in a month which is causing issue in the program running for longer time.
Ex : When it uses the index A, it is running fine. When it uses the index B, it is running for longer time.
Can you please advice on the possible reasons for the same sql to choose index B instead of index A some times.
Thanks,
Rakesh

It could be that the SQL is question got aged out of the shared pool and when it came to be reparsed - the values in the bind variables were such that access via index b was more attractive than access via index a.
Could you please send the query and the good and bad plans and all other information that might help diagnose the problem..
Note: we had a similiar case where plans suddenly changed for no apperant reason (on 10.2.0.2) - we found that under certain circumstances the optimizer would not peek into the bind varaibles to derive the execution path.

Explain plan results are different in SQL Developer than SQL Plus

My Environment:
SQL Developer 1.0.0.15.27
Platform where SQL Developer is running: Windows XP 2002 SP2
Oracle Database and Client 9.2.0.7
Optimizer_mode: FIRST_ROWS
I have the following SQL statement:
SELECT a1.comp_id
FROM temp_au_company a0, au_company a1
WHERE :b2 = a0.temp_emp_code
AND a0.comp_id = a1.comp_id
AND a0.sls_terr_code != a1.sls_terr_code
AND a1.last_mdfy_date > :b1
When I run an Explain in SQL Developer I get the following access path (which is the one I really want):
SELECT STATEMENT TABLE ACCESS(BY INDEX ROWID) FEDLINK.AU_COMPANY NESTED LOOPS INDEX(RANGE SCAN)
FEDLINK.UX2_TEMP_AU_COMPANY
INDEX(RANGE SCAN) FEDLINK.PX1_COMPANY
However, when I execute the statement with sql_trace turned on and use tkprof to generate the actual access path, the statement executes as follows (which is WAY more expensive):
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 3.58 6.68 28136 29232 0 0
total 3 3.58 6.69 28136 29232 0 0
Misses in library cache during parse: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 979 (FEDLINK) (recursive depth: 1)
Rows Row Source Operation
0 NESTED LOOPS
0 TABLE ACCESS FULL AU_COMPANY
0 INDEX RANGE SCAN UX2_TEMP_AU_COMPANY (object id 49783)
Notice the FULL access of au_company.
I understand that SQL Developer has nothing to do with why the statement executed the way it did, but why is the Explain in SQL Developer different than the actual execution plan?
Added note....when I run the explain in SQL Plus it is the same as the actual execution. Here is the explain from SQL Plus:
explain plan for SELECT a1.comp_id
FROM temp_au_company a0, au_company a1
WHERE '1' = a0.temp_emp_code
AND a0.comp_id = a1.comp_id
AND a0.sls_terr_code != a1.sls_terr_code
AND a1.last_mdfy_date > '01-MAY-2006';
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2 | 76 | 2597 |
| 1 | NESTED LOOPS | | 2 | 76 | 2597 |
| 2 | TABLE ACCESS FULL | AU_COMPANY | 2 | 42 | 2595 |
| 3 | INDEX RANGE SCAN | UX2_TEMP_AU_COMPANY | 1 | 17 | 2
Thanks,
Brenda

The explain is different (full scan of au_company in SQL Plus / index access in SQL Developer) even when I use variables in SQL Plus. Here is the output for SQL Plus using variables instead of literals:
SQL> variable b1 varchar2
SQL> variable b2 char
SQL> explain plan for SELECT a1.comp_id
2 FROM temp_au_company a0, au_company a1
3 WHERE :b2 = a0.temp_emp_code
4 AND a0.comp_id = a1.comp_id
5 AND a0.sls_terr_code != a1.sls_terr_code
6 AND a1.last_mdfy_date > :b1
7 /
Explained.
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 3184 | 118K| 2995 |
| 1 | HASH JOIN | | 3184 | 118K| 2995 |
| 2 | INDEX RANGE SCAN | UX2_TEMP_AU_COMPANY | 3187 | 54179 | 3 |
| 3 | TABLE ACCESS FULL | AU_COMPANY | 24009 | 492K| 2983 |
Any other ideas? They should be the same.
Brenda

Help speed up a long running query.

I have a connect by query that is taking a long time to run.
The problem seems to lie in it contains a decode on the CONNECT BY
CONNECT BY prior p_mat = DECODE(NVL(p_sa,'M'),'S',p_top,NULL)If i remove this or make it default to p_top rather than checking the value of p_sa its fine.
Any idea how I can achieve the same result of the connect by without the need for the decode?

query
    SELECT mp_irn,
      level - 1 ,
      1,
      mp_irn
    FROM sfmp,
      sfmat
    WHERE MAT_REF_NUM             = MP_REF_MAT
    AND mp_sl                     =db_pkg_pcs.fun_getbomroute(mp_irn)
      CONNECT BY prior mp_ref_mat = DECODE(NVL(mat_sa,'M'),'S',mp_irn,NULL)
      START WITH mp_irn           = 'K9081-400'
UNION
SELECT mp_ref_mat,
    level,
    MP_REF_FREQ,
    mp_irn
FROM sfmp,
    sfmat
WHERE NVL(MAT_SA,'M')         = 'S'
AND MAT_REF_NUM               = MP_REF_MAT
AND mp_sl                     =db_pkg_pcs.fun_getbomroute(mp_irn)
    CONNECT BY prior mp_ref_mat = mp_irn
    START WITH mp_irn           = 'K9081-400'
ORDER BY 2
| Id | Operation                         | Name          | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                  |               |   822 | 37884 |       |   568   (2)| 00:00:07 |
|   1 | SORT UNIQUE                      |               |   822 | 37884 |       |   567   (7)| 00:00:07 |
|   2 |   UNION-ALL                       |               |       |       |       |            |          |
|* 3 |    FILTER                         |               |       |       |       |            |          |
|* 4 |     CONNECT BY WITH FILTERING     |               |       |       |       |            |          |
|   5 |      NESTED LOOPS                 |               |    24 | 1104 |       |    27   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|* 6 |       INDEX RANGE SCAN            | PK_MP         |    24 |   696 |       |     3   (0)| 00:00:01 |
|   7 |       TABLE ACCESS BY INDEX ROWID | SFMAT         |     1 |    17 |       |     1   (0)| 00:00:01 |
|* 8 |        INDEX UNIQUE SCAN          | PK_SFMAT      |     1 |       |       |     0   (0)| 00:00:01 |
|   9 |      NESTED LOOPS                 |               |       |       |       |            |          |
| 10 |       CONNECT BY PUMP             |               |       |       |       |            |          |
|* 11 |       HASH JOIN                   |               |   798 | 36708 | 1080K|   537   (1)| 00:00:07 |
| 12 |        TABLE ACCESS FULL          | SFMAT         | 38018 |   631K|       |   224   (1)| 00:00:03 |
| 13 |        INDEX FAST FULL SCAN       | PK_MP         | 79831 | 2260K|       |   103   (1)| 00:00:02 |
|* 14 |    FILTER                         |               |       |       |       |            |          |
|* 15 |     CONNECT BY WITH FILTERING     |               |       |       |       |            |          |
| 16 |      NESTED LOOPS                 |               |    24 | 1176 |       |    28   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
| 17 |       TABLE ACCESS BY INDEX ROWID | SFMP          |    24 |   768 |       |     4   (0)| 00:00:01 |
|* 18 |        INDEX RANGE SCAN           | SFMP_SFJR_IDX |    24 |       |       |     1   (0)| 00:00:01 |
| 19 |       TABLE ACCESS BY INDEX ROWID | SFMAT         |     1 |    17 |       |     1   (0)| 00:00:01 |
|* 20 |        INDEX UNIQUE SCAN          | PK_SFMAT      |     1 |       |       |     0   (0)| 00:00:01 |
| 21 |      NESTED LOOPS                 |               |    24 | 1176 |       |    28   (0)| 00:00:01 |
| 22 |       NESTED LOOPS                |               |       |       |       |            |          |
| 23 |        CONNECT BY PUMP            |               |       |       |       |            |          |
| 24 |        TABLE ACCESS BY INDEX ROWID| SFMP          |    24 |   768 |       |     4   (0)| 00:00:01 |
|* 25 |         INDEX RANGE SCAN          | SFMP_SFJR_IDX |    24 |       |       |     1   (0)| 00:00:01 |
| 26 |       TABLE ACCESS BY INDEX ROWID | SFMAT         |     1 |    17 |       |     1   (0)| 00:00:01 |
|* 27 |        INDEX UNIQUE SCAN          | PK_SFMAT      |     1 |       |       |     0   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   3 - filter("MP_SL"="DB_PKG_PCS"."FUN_GETBOMROUTE"("MP_IRN"))
   4 - access(DECODE(NVL("MAT_SA",'M'),'S',"MP_IRN",NULL)=PRIOR "MP_REF_MAT")
   6 - access("MP_IRN"='K9081-400')
   8 - access("MP_REF_MAT"="MAT_REF_NUM")
11 - access("MP_REF_MAT"="MAT_REF_NUM")
       filter(DECODE(NVL("MAT_SA",'M'),'S',"MP_IRN",NULL)=PRIOR "MP_REF_MAT")
PLAN_TABLE_OUTPUT
14 - filter(NVL("MAT_SA",'M')='S' AND "MP_SL"="DB_PKG_PCS"."FUN_GETBOMROUTE"("MP_IRN"))
15 - access("MP_IRN"=PRIOR "MP_REF_MAT")
18 - access("MP_IRN"='K9081-400')
20 - access("MAT_REF_NUM"="MP_REF_MAT")
25 - access("MP_IRN"=PRIOR "MP_REF_MAT")
27 - access("MAT_REF_NUM"="MP_REF_MAT")

V$session_longops not displaying a long running query

Hi,
There is a certain query that runs as a part of a stored procedure which when run takes about 1 and half hours to get completed and there is a hint in this query to use certain indexes on few tables.
This time was unacceptable as it was much much longer than what it should have taken so I tried to monitor it through v$session_longops using the following query
select * from v$session_longops where time_remaining > 0
It shows no rows selected but the query is still running.
When I changed the hint in the query to use the full table scan on these tables instead of the indexes it began to show up on the v$session_longops and it took like only 15 mins for the procedure execution to get completed.
My questions are two fold
1) Why did the first time with the Hint on the indexes not show up on v$session_longops with time_remaining > 0 and why did it show up only when i did a full table scan?
2) Secondly is'nt a scan on a table faster using indexes if the index has unique values on the columns we are trying to get data from than the Full Table Scans. And if so then why is it behaving differently in this case.
Thanks a lot in advance for any answers/suggestions

1. v$session_longops only reports long running operations. The CBO assumes that the index scan is a tiny operation (nested loop joins), hence it is not displaying the query, but when you have a full table scan, the CBO assumes this to be a long operation, and hence it is visible in v$session_longops.
2. Allow me to quote from
"http://asktom.oracle.com/pls/ask/f?p=4950:8:17968334624783495563::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:9422487749968"
"full scans are not evil, indexes are not good"
"full scans are not evil, indexes are not good"
"full scans are not evil, indexes are not good"
Click that link for more information. :)
The gist of it is, your CBO is smart, and hence generating a better plan than when you force it to use indexes. Yes, the plan has full table scans, but that is not a crime. What you can do is use optimizer parameters - "optimizer_index_cost_adj" to tune for a better performance, but you should not force an index unless you are sure that the index gives you a lower cost.
You could paste the plan for you queries with and without hints and also paste the optimizer hints - show parameter optimizer.

Long running Query Tuning

Hi all,
We are using Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production on
Linux 2.6.5-7.282-bigsmp #1 SMP box.
The following query is taking aproximately 1 hr to execute.
SELECT item.ap_id, item.ap_version_id, oa.customer_id,CI.CAPTION OFFER_ID, ITEM.BILL_START_DATE , ITEM.CTDB_CRE_DATETIME , oa.order_unit_id
FROM tbap_item item,
tbprice_plan pp,
tborder_action oa,
tborder_action_impl oaimpl,
     TBCATALOG_ITEM CI
WHERE item.entity_type = 'amdocs.oms.sbcproduct.ApPricePlanImpl'
AND item.item_def_id = pp.cid
AND item.item_def_ver = pp.pcversion_id
AND pp.is_promote = '1'
AND item.order_action_id = oa.order_unit_id
AND oa.order_unit_id = oaimpl.order_unit_id
AND oaimpl.bypass_reason_id = 'MI'
AND oa.xml_id IS NOT NULL
AND item.state IN ('AS', 'OR')
AND item.status = 'AC'
AND CI.CID = ITEM.ITEM_DEF_ID
AND CI.PCVERSION_ID = ITEM.ITEM_DEF_VER
AND item.ap_version_id = '0'
AND EXISTS (SELECT 1 FROM TBAP_ITEM TEMP WHERE TEMP.AP_ID = ITEM.AP_ID AND TEMP.END_DATE > SYSDATE AND TEMP.STATE IN ('AS' , 'OR') AND TEMP.STATUS ='AC');
the execution plan before collecting the stats is:
Query Plan
SELECT STATEMENT [CHOOSE] Cost=120002
NESTED LOOPS SEMI Cost=120002 Card=98407 Bytes=18402109
MERGE JOIN Cost=80639 Card=98407 Bytes=16040341
SORT JOIN Cost=80607 Card=98407 Bytes=13481759
MERGE JOIN Cost=78626 Card=98407 Bytes=13481759
SORT JOIN Cost=76699 Card=119937 Bytes=14992125
MERGE JOIN Cost=76699 Card=119937 Bytes=14992125
SORT JOIN Cost=76682 Card=171602 Bytes=19219424
MERGE JOIN Cost=76682 Card=171602 Bytes=19219424
SORT JOIN Cost=74698 Card=990661 Bytes=82224863
TABLE ACCESS FULL TBAP_ITEM [ANALYZED] Cost=62069 Card=990661 Bytes=82224863
SORT JOIN Cost=1985 Card=89365 Bytes=2591585
TABLE ACCESS FULL TBORDER_ACTION [ANALYZED] Cost=1511 Card=89365 Bytes=2591585
SORT JOIN Cost=17 Card=195 Bytes=2535
TABLE ACCESS FULL TBPRICE_PLAN [ANALYZED] Cost=2 Card=195 Bytes=2535
SORT JOIN Cost=1928 Card=73323 Bytes=879876
TABLE ACCESS FULL TBORDER_ACTION_IMPL [ANALYZED] Cost=1698 Card=73323 Bytes=879876
SORT JOIN Cost=33 Card=3017 Bytes=78442
TABLE ACCESS FULL TBCATALOG_ITEM [ANALYZED] Cost=4 Card=3017 Bytes=78442
TABLE ACCESS BY INDEX ROWID TBAP_ITEM [ANALYZED] Cost=1 Card=2037512 Bytes=48900288
INDEX RANGE SCAN TBAP_ITEM_PK [ANALYZED] Cost=2 Card=2 Bytes=
after collecting the stats:
SELECT STATEMENT [CHOOSE] Cost=64972
NESTED LOOPS SEMI Cost=64972 Card=333 Bytes=62937
NESTED LOOPS Cost=64839 Card=333 Bytes=54945
MERGE JOIN Cost=64446 Card=1965 Bytes=300645
SORT JOIN Cost=64414 Card=1965 Bytes=249555
MERGE JOIN Cost=64414 Card=1965 Bytes=249555
SORT JOIN Cost=62429 Card=13393 Bytes=1312514
MERGE JOIN Cost=62429 Card=13393 Bytes=1312514
SORT JOIN Cost=2 Card=140 Bytes=1820
TABLE ACCESS FULL TBPRICE_PLAN [ANALYZED] Cost=2 Card=140 Bytes=1820
SORT JOIN Cost=62428 Card=26785 Bytes=2276725
TABLE ACCESS FULL TBAP_ITEM [ANALYZED] Cost=62072 Card=26785 Bytes=2276725
SORT JOIN Cost=1985 Card=89365 Bytes=2591585
TABLE ACCESS FULL TBORDER_ACTION [ANALYZED] Cost=1511 Card=89365 Bytes=2591585
SORT JOIN Cost=33 Card=3017 Bytes=78442
TABLE ACCESS FULL TBCATALOG_ITEM [ANALYZED] Cost=4 Card=3017 Bytes=78442
TABLE ACCESS BY INDEX ROWID TBORDER_ACTION_IMPL [ANALYZED] Cost=1 Card=1 Bytes=12
INDEX UNIQUE SCAN TBORDER_ACTION_IMPL_PK [ANALYZED] Cost=1 Card=1 Bytes=
TABLE ACCESS BY INDEX ROWID TBAP_ITEM [ANALYZED] Cost=1 Card=2972308 Bytes=71335392
INDEX RANGE SCAN TBAP_ITEM_PK [ANALYZED] Cost=2 Card=2 Bytes=
I am now taking the level 4 trace now.will post it once Its done. I found some "latchfree" timeouts while running it now...
I also find that few cols refered in where clause doesn't have indexes...So I am going to discuss this with the developers. also I want modify the query too..as below.
ELECT item.ap_id, item.ap_version_id, oa.customer_id,CI.CAPTION OFFER_ID, ITEM.BILL_START_DATE , ITEM.CTDB_CRE_DATETIME , oa.order_unit_id
FROM tbap_item item,
tbprice_plan pp,
tborder_action oa,
tborder_action_impl oaimpl,
     TBCATALOG_ITEM CI
WHERE
item.entity_type = 'amdocs.oms.sbcproduct.ApPricePlanImpl'
AND item.status = 'AC'
AND item.state IN ('AS', 'OR')
AND item.ap_version_id = '0'
AND pp.is_promote = '1'
AND oaimpl.bypass_reason_id = 'MI'
AND oa.xml_id IS NOT NULL
AND item.item_def_id = pp.cid
AND item.item_def_ver = pp.pcversion_id
AND item.order_action_id = oa.order_unit_id
AND oa.order_unit_id = oaimpl.order_unit_id
AND CI.CID = ITEM.ITEM_DEF_ID
AND CI.PCVERSION_ID = ITEM.ITEM_DEF_VER
AND EXISTS (SELECT 1 FROM TBAP_ITEM TEMP WHERE
TEMP.STATE IN ('AS' , 'OR') AND TEMP.STATUS ='AC' AND TEMP.AP_ID = ITEM.AP_ID AND TEMP.END_DATE > SYSDATE );
Please suggest. what else I need to check to imporve the performace .
Thanks in advace for your help and suggestions.

here is formatted one:
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.14       0.19          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        8     58.21    4169.28    1663901    1699503         10         103
total       10     58.36    4169.47    1663901    1699503         10         103
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 139
Rows     Row Source Operation
    103 NESTED LOOPS SEMI
    158   NESTED LOOPS
   3613    MERGE JOIN
   3613     SORT JOIN
   3613      MERGE JOIN
110996       SORT JOIN
110996        MERGE JOIN
    195         SORT JOIN
    195          TABLE ACCESS FULL OBJ#(33959)
110996         SORT JOIN
820046          TABLE ACCESS FULL OBJ#(33563)
   3613       SORT JOIN
89365        TABLE ACCESS FULL OBJ#(33538)
   3613     SORT JOIN
   3017      TABLE ACCESS FULL OBJ#(33889)
    158    TABLE ACCESS BY INDEX ROWID OBJ#(33534)
   3613     INDEX UNIQUE SCAN OBJ#(33645) (object id 33645)
    103   TABLE ACCESS BY INDEX ROWID OBJ#(33563)
    275    INDEX RANGE SCAN OBJ#(48320) (object id 48320)
********************************************************************************

"Error determining planning periods for calendar " when running a program

Hi,
When i am running a program with date range say "01/05/2011" to "30/06/2011",the program is executing successfully without any error. When i am executing the same program with date range as a) "01/05/2009" to "30/06/2011" and b)"01/05/2008" to "30/06/2011" the program is failing with error as "Error determining planning periods for calendar". Can anyone suggest me what i should do to avoid the failure of the program with above date ranges also.
Thanks in advance,

Dear,
Error message 61123:"Error determining planning periods for calendar &".The PPC planning calendar specified in the material master MRP 2 view for the material is incorrectly.
The planning calendar periods are insufficiently maintained for the planning calendar used.
Check the period of planning calendar in MD26 and generate the correct period.You can avoid the problem in several ways:
Maintain the planning calendar far enough in the future (at least until beyond the end of the planning horizon).
Also check any demand is lies beyond the validity period of planning calendar.
Reduction of the planning horizon of MRP also can control such issue, as MRP planning horizon lies in an area in which the planning calendar is no longer maintained
Regards,
R.Brahmankar

Explain plan output for a sql in JSP page

Hello all,
I have a requirement to give SQL query as an input and get the output and explain plan in the same JSP page. i could get the SQL result, but i want to get the EXPLAIN Plan.
can any one help me in this.
Thanks
Kiran

Hello all,
I have a requirement to give SQL query as an input and get the output and explain plan in the same JSP page. i could get the SQL result, but i want to get the EXPLAIN Plan.
can any one help me in this.
Thanks
Kiran

Explain plan result for a long-running query used in data-warehousing. Tuni

Similar Messages

Maybe you are looking for