Determine the cause of FULL table scan

Hi,
Oracle version : 10.2.0.3
We have performance issue with one of the report.
The report query is as follows.
INSERT INTO TABDATA
SELECT col1,col2,col3,col4,col5
FROM tab1,tab2,tab3
WHERE col6= col7
AND col8= col2
AND col4>= TRUNC(SYSDATE)
AND col5= 'AB'
AND col2= 'VALUE1'
AND col1= 1;
There is a index on tab2 table which included col4 column.
Usually it takes 2 minutes to complete but on some days it is taking 30 minutes to complete.
We have confirmed that it is using full tablescan (plan hash 1142877908 ) when performance was bad and is using index scan (plan hash 900583245) when performance was good. The SQL_ID is same for both the plan_hash.
Date Plan Hash duration (minutes)
14-Jun-2011 900583245 2
15-Jun-2011 900583245 3
19-Jun-2011 900583245 2
20-Jun-2011 900583245 3 <--- Good Performance ( Plan Hash -900583245)
22-Jun-2011 1142877908 29 <--- Bad Performance ( Plan Hash -1142877908 )
23-Jun-2011 1142877908 31
25-Jun-2011 900583245 2
26-Jun-2011 900583245 3
27-Jun-2011 1142877908 25
28-Jun-2011 900583245 3
Is there any way to prove the exact reason for the sudden plan change?
Is there any view from which i can determine whether the statistics were STALE on the table or there is lot of DML occured with dates.
Thanks,
Girish

Hi,
Sorry for the late reply.
The good and bad plans are as follows.
PLAN_TABLE_OUTPUT
SQL_ID dvug76721n3w5
INSERT INTO TWDAILYDATA SELECT ADD_MAE_CODESTAT,ADD_MAE_CODEARTY,ADD_DAILYDATA,ADD_SENTPRICE,ADD_FSOFFSET,ADD_SAOFFSET FROM
TARTICLEDAILYDATA, TMANAGEDARTICLE, TPARAMETER WHERE MAE_MSN_STACODE = ADD_MAE_CODESTAT AND MAE_ARTY_CODE =
ADD_MAE_CODEARTY AND ADD_DAILYDATA >= TRUNC(SYSDATE) AND PAR_CTYCODEISO = 'FR' AND PAR_ITEM = 'PRICE_IN_FUTURE' AND
PAR_NVALUE = 1
Plan hash value: 935962662
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
| 0 | INSERT STATEMENT | | | | 13925 (100)| | | | |
| 1 | PX COORDINATOR | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10002 | 9257 | 587K| 13925 (1)| 00:02:48 | Q1,02 | P->S | QC (RAND) |
| 3 | HASH JOIN | | 9257 | 587K| 13925 (1)| 00:02:48 | Q1,02 | PCWP | |
| 4 | BUFFER SORT | | | | | | Q1,02 | PCWC | |
| 5 | PX RECEIVE | | 9257 | 262K| 13903 (1)| 00:02:47 | Q1,02 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 9257 | 262K| 13903 (1)| 00:02:47 | | S->P | BROADCAST |
| 7 | TABLE ACCESS BY INDEX ROWID | TARTICLEDAILYDATA | 9257 | 262K| 13903 (1)| 00:02:47 | | | |
| 8 | INDEX SKIP SCAN | TADD_PK | 9257 | | 9584 (1)| 00:01:56 | | | |
| 9 | NESTED LOOPS | | 18570 | 652K| 19 (0)| 00:00:01 | Q1,02 | PCWP | |
| 10 | BUFFER SORT | | | | | | Q1,02 | PCWC | |
| 11 | PX RECEIVE | | | | | | Q1,02 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10001 | | | | | | S->P | BROADCAST |
| 13 | TABLE ACCESS BY INDEX ROWID| TPARAMETER | 1 | 23 | 1 (0)| 00:00:01 | | | |
| 14 | INDEX UNIQUE SCAN | TPARAMETER_PK | 1 | | 0 (0)| | | | |
| 15 | PX BLOCK ITERATOR | | 18570 | 235K| 18 (0)| 00:00:01 | Q1,02 | PCWC | |
| 16 | INDEX FAST FULL SCAN | TMAE_PK | 18570 | 235K| 18 (0)| 00:00:01 | Q1,02 | PCWP | |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
7 - SEL$1 / TARTICLEDAILYDATA@SEL$1
8 - SEL$1 / TARTICLEDAILYDATA@SEL$1
13 - SEL$1 / TPARAMETER@SEL$1
14 - SEL$1 / TPARAMETER@SEL$1
16 - SEL$1 / TMANAGEDARTICLE@SEL$1
SQL_ID dvug76721n3w5
INSERT INTO TWDAILYDATA SELECT ADD_MAE_CODESTAT,ADD_MAE_CODEARTY,ADD_DAILYDATA,ADD_SENTPRICE,ADD_FSOFFSET,ADD_SAOFFSET FROM
TARTICLEDAILYDATA, TMANAGEDARTICLE, TPARAMETER WHERE MAE_MSN_STACODE = ADD_MAE_CODESTAT AND MAE_ARTY_CODE = ADD_MAE_CODEARTY
AND ADD_DAILYDATA >= TRUNC(SYSDATE) AND PAR_CTYCODEISO = 'FR' AND PAR_ITEM = 'PRICE_IN_FUTURE' AND PAR_NVALUE = 1
Plan hash value: 1795240408
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
| 0 | INSERT STATEMENT | | | | 145K(100)| | | | |
| 1 | PX COORDINATOR | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 992K| 61M| 145K (2)| 00:29:12 | Q1,03 | P->S | QC (RAND) |
| 3 | HASH JOIN | | 992K| 61M| 145K (2)| 00:29:12 | Q1,03 | PCWP | |
| 4 | PX RECEIVE | | 18576 | 653K| 19 (0)| 00:00:01 | Q1,03 | PCWP | |
| 5 | PX SEND HASH | :TQ10002 | 18576 | 653K| 19 (0)| 00:00:01 | Q1,02 | P->P | HASH |
| 6 | NESTED LOOPS | | 18576 | 653K| 19 (0)| 00:00:01 | Q1,02 | PCWP | |
| 7 | BUFFER SORT | | | | | | Q1,02 | PCWC | |
| 8 | PX RECEIVE | | | | | | Q1,02 | PCWP | |
| 9 | PX SEND BROADCAST | :TQ10000 | | | | | | S->P | BROADCAST |
| 10 | TABLE ACCESS BY INDEX ROWID| TPARAMETER | 1 | 23 | 1 (0)| 00:00:01 | | | |
| 11 | INDEX UNIQUE SCAN | TPARAMETER_PK | 1 | | 0 (0)| | | | |
| 12 | PX BLOCK ITERATOR | | 18576 | 235K| 18 (0)| 00:00:01 | Q1,02 | PCWC | |
| 13 | INDEX FAST FULL SCAN | TMAE_PK | 18576 | 235K| 18 (0)| 00:00:01 | Q1,02 | PCWP | |
| 14 | BUFFER SORT | | | | | | Q1,03 | PCWC | |
| 15 | PX RECEIVE | | 992K| 27M| 145K (2)| 00:29:12 | Q1,03 | PCWP | |
| 16 | PX SEND HASH | :TQ10001 | 992K| 27M| 145K (2)| 00:29:12 | | S->P | HASH |
| 17 | TABLE ACCESS FULL | TARTICLEDAILYDATA | 992K| 27M| 145K (2)| 00:29:12 | | | |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
10 - SEL$1 / TPARAMETER@SEL$1
11 - SEL$1 / TPARAMETER@SEL$1
13 - SEL$1 / TMANAGEDARTICLE@SEL$1
17 - SEL$1 / TARTICLEDAILYDATA@SEL$1
Thanks
Girish

Similar Messages

Finding the Text of SQL Query causing Full Table Scans

Hi,
does anyone have a sql script, that shows the complete sql text of queries that have caused a full table scan?
Please also let me know as to how soon this script needs to be run, in the sense does it work only while the query is running or would it work once it completes (if so is there a valid duration, such as until next restart, etc.)
Your help is appreciated.
Thx,
Mayuran

Finding the Text of SQL Query Causing Full Table Scan

Finding the Text of SQL Query Causing Full Table Scan

Hi,
does anyone have a sql script, that shows the complete sql text of queries that have caused a full table scan?
Please also let me know as to how soon this script needs to be run, in the sense does it work only while the query is running or would it work once it completes (if so is there a valid duration, such as until next restart, etc.)
Your help is appreciated.
Thx,
Mayuran

You might try something like this:
select sql_text,
       object_name
from   v$sql s,
       v$sql_plan p
where s.address = p.address and
       s.hash_value = p.hash_value and
       s.child_number = p.child_number and
       p.operation = 'TABLE ACCESS' and
       p.options = 'FULL' and
       p.object_owner in ('SCOTT')
;Please note that this query is just a snapshot of the SQL statements currently in the cache.

Simple Query in Oracle Linked Table in MS Access causes full table scan.

I am running a very simple query in MS ACCESS to a linked Oracle table as follows:
Select *
From EXPRESS_SERVICE_EVENTS --(the linked table name refers to EXPRESS.SERVICE_EVENTS)
Where performed > MyDate()
or
Select *
From EXPRESS_SERVICE_EVENTS --(the linked table name refers to EXPRESS.SERVICE_EVENTS)
Where performed > [Forms]![MyForm]![Date1]
We have over 50 machines and this query runs fine on over half of these, using an Oracle Index on the "performed" field. Running exactly the same thing on the other machines causes a full table scan, therefore ignoring the Index (all machines access the same Access DB).
Strangely, if we write the query as follows:
Select *
From EXPRESS_SERVICE_EVENTS
Where performed > #09/04/2009 08:00#
it works fast everywhere!
Any help on this 'phenominon' would be appreciated.
Things we've done:
Checked regional settings, ODBC driver settings, MS Access settings (as in Tools->Options), we have the latest XP and Office service packs, and re-linked all Access Tables on both the slow and fast machines independantly).

Primarily, thanks gdarling for your reply. This solved our problem.
Just a small note to those who may be using this thread.
Although this might not be the reason, my PC had Oracle 9iR2 installed with Administratiev Tools, where user machines had the same thing installed but using Runtime Installation. For some reason, my PC did not have 'bind date' etc. as an option in the workarounds, but user machines did have this workaround option. Strangely, although I did not have the option, my (ODBC) query was running as expected, but user queries were not.
When we set the workaround checkbox accordingly, the queries then run as expected (fast).
Once again,
Thanks

Entity Framework Generated SQL for paging or using Linq skip take causes full table scans.

The slq genreated creates queries that cause a full table scan for pagination. Is there any way to fix this?
I am using
ODP.NET ODTwithODAC1120320_32bit
ASP.NET 4.5
EF 5
Oracle 11gR2
This table has 2 million records. The further into the records you page the longer it takes.
LINQ
var cnt = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                    select errorLog).Count();
                var query = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                             orderby errorLog.ERR_LOG_ID
                             select errorLog).Skip(cnt-10).Take(10).ToList();
Here is the query & execution plans.
SELECT *
FROM   (SELECT "Extent1"."ERR_LOG_ID" AS "ERR_LOG_ID",
               "Extent1"."SRV_LOG_ID" AS "SRV_LOG_ID",
               "Extent1"."TS"          AS "TS",
               "Extent1"."MSG"         AS "MSG",
               "Extent1"."STACK_TRACE" AS "STACK_TRACE",
               "Extent1"."MTD_NM"      AS "MTD_NM",
               "Extent1"."PRM"         AS "PRM",
               "Extent1"."INSN_ID"     AS "INSN_ID",
               "Extent1"."TS_1"        AS "TS_1",
               "Extent1"."LOG_ETRY"    AS "LOG_ETRY"
        FROM   (SELECT "Extent1"."ERR_LOG_ID"                                  AS "ERR_LOG_ID",
                       "Extent1"."SRV_LOG_ID"                                  AS "SRV_LOG_ID",
                       "Extent1"."TS"                                          AS "TS",
                       "Extent1"."MSG"                                         AS "MSG",
                       "Extent1"."STACK_TRACE"                                 AS "STACK_TRACE",
                       "Extent1"."MTD_NM"                                      AS "MTD_NM",
                       "Extent1"."PRM"                                         AS "PRM",
                       "Extent1"."INSN_ID"                                     AS "INSN_ID",
                       "Extent1"."TS_1"                                        AS "TS_1",
                       "Extent1"."LOG_ETRY"                                    AS "LOG_ETRY",
                       row_number() OVER (ORDER BY "Extent1"."ERR_LOG_ID" ASC) AS "row_number"
                FROM   (SELECT "ERRORLOGANDSERVICELOG_VIEW"."ERR_LOG_ID" AS "ERR_LOG_ID",
                               "ERRORLOGANDSERVICELOG_VIEW"."SRV_LOG_ID" AS "SRV_LOG_ID",
                               "ERRORLOGANDSERVICELOG_VIEW"."TS"          AS "TS",
                               "ERRORLOGANDSERVICELOG_VIEW"."MSG"         AS "MSG",
                               "ERRORLOGANDSERVICELOG_VIEW"."STACK_TRACE" AS "STACK_TRACE",
                               "ERRORLOGANDSERVICELOG_VIEW"."MTD_NM"      AS "MTD_NM",
                               "ERRORLOGANDSERVICELOG_VIEW"."PRM"         AS "PRM",
                               "ERRORLOGANDSERVICELOG_VIEW"."INSN_ID"     AS "INSN_ID",
                               "ERRORLOGANDSERVICELOG_VIEW"."TS_1"        AS "TS_1",
                               "ERRORLOGANDSERVICELOG_VIEW"."LOG_ETRY"    AS "LOG_ETRY"
                        FROM   "IDS_CORE"."ERRORLOGANDSERVICELOG_VIEW" "ERRORLOGANDSERVICELOG_VIEW") "Extent1") "Extent1"
        WHERE ("Extent1"."row_number" > 1933849)
        ORDER BY "Extent1"."ERR_LOG_ID" ASC)
WHERE (ROWNUM <= (10))
| Id | Operation              | Name                   | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT       |                        |    10 | 31750 |       |   821K (1)| 02:44:15 |
|* 1 | COUNT STOPKEY         |                        |       |       |       |            |          |
|   2 |   VIEW                 |                        | 1561K| 4728M|       |   821K (1)| 02:44:15 |
|* 3 |    VIEW                |                        | 1561K| 4748M|       |   821K (1)| 02:44:15 |
|   4 |     WINDOW SORT        |                        | 1561K| 3154M| 4066M|   821K (1)| 02:44:15 |
|* 5 |      HASH JOIN OUTER   |                        | 1561K| 3154M|       |   130K (1)| 00:26:09 |
|   6 |       TABLE ACCESS FULL| IDS_SERVICES_LOG       | 1047 | 52350 |       |     5   (0)| 00:00:01 |
|   7 |       TABLE ACCESS FULL| IDS_SERVICES_ERROR_LOG | 1561K| 3080M|       |   130K (1)| 00:26:08 |
Predicate Information (identified by operation id):
   1 - filter(ROWNUM<=10)
   3 - filter("Extent1"."row_number">1933849)
   5 - access("T1"."SRV_LOG_ID"(+)="T2"."SRV_LOG_ID")

I did try a sample from stack overflow that would apply it to all string types, but I didn't see any query results differences. Please note, I am having the problem without any order with or where statements. Of course the skip take generates them. Please advise how I would implement the EntityFunctions.AsNonUnicode method with this Linq query.
LINQ
var cnt = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                    select errorLog).Count();
                var query = (from errorLog in ctx.ERRORLOGANDSERVICELOG_VIEW
                             orderby errorLog.ERR_LOG_ID
                             select errorLog).Skip(cnt-10).Take(10).ToList();
This is what I inserted into my model to hopefully fix it. FROM:c# - EF Code First - Globally set varchar mapping over nvarchar - Stack Overflow
/// <summary>
/// Change the "default" of all string properties for a given entity to varchar instead of nvarchar.
/// </summary>
/// <param name="modelBuilder"></param>
/// <param name="entityType"></param>
protected void SetAllStringPropertiesAsNonUnicode(
   DbModelBuilder modelBuilder,
   Type entityType)
   var stringProperties = entityType.GetProperties().Where(
c => c.PropertyType == typeof(string)
   && c.PropertyType.IsPublic
   && c.

Select statement in a function does Full Table Scan

All,
I have been coding a stored procedure that writes 38K rows in less than a minute. If I add another column which requires call to a package and 4 functions within that package, it runs for about 4 hours. I have confirmed that due to problems in one of the functions, the code does full table scans. The package and all of its functions were written by other contractors who have been long gone.
Please note that case_number_in (VARCHAR2) and effective_date_in (DATE) are parameters sent to the problem function and I have verified through TOAD’s debugger that their values are correct.
Table named ps2_benefit_register has over 40 million rows but case_number is an index for that table.
Table named ps1_case_fs has more than 20 million rows but also uses case_number as an index.
Select #1 – causes full table scan runs and writes 38K rows in a couple of hours.
{case}
SELECT max(a2.application_date)
INTO l_app_date
FROM dwfssd.ps2_benefit_register a1, dwfssd.ps2_case_fs a2
WHERE a2.case_number = case_number_in and
a1.case_number = a2.case_number and
a2.application_date <= effective_date_in and
a1.DOCUMENT_TYPE = 'F';
{case}
Select #2 – runs – hard coding values makes the code to write the same 38K rows in a few minutes.
{case}
SELECT max(a2.application_date)
INTO l_app_date
FROM dwfssd.ps2_benefit_register a1, dwfssd.ps2_case_fs a2
WHERE a2.case_number = 'A006438' and
a1.case_number = a2.case_number and
a2.application_date <= '01-Apr-2009' and
a1.DOCUMENT_TYPE = 'F';
{case}
Why using the values in the passed parameter in the first select statement causes full table scan?
Thank you for your help,
Seyed
Edited by: user11117178 on Jul 30, 2009 6:22 AM
Edited by: user11117178 on Jul 30, 2009 6:23 AM
Edited by: user11117178 on Jul 30, 2009 6:24 AM

Hello Dan,
Thank you for your input. The function is not determinsitic, therefore, I am providing you with the explain plan. By version number, if you are refering to the Database version, we are running 10g.
PLAN_TABLE_OUTPUT
Plan hash value: 2132048964
| Id | Operation                     | Name                    | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT              |                         |   324K|    33M| 3138   (5)| 00:00:38 |       |       |
|* 1 | HASH JOIN                    |                         |   324K|    33M| 3138   (5)| 00:00:38 |       |       |
|   2 |   BITMAP CONVERSION TO ROWIDS |                         |     3 |     9 |     1   (0)| 00:00:01 |       |       |
|* 3 |    BITMAP INDEX FAST FULL SCAN| IDX_PS2_ACTION_TYPES    |       |       |            |          |       |       |
|   4 |   PARTITION RANGE ITERATOR    |                         |   866K|    87M| 3121   (4)| 00:00:38 |   154 |   158 |
|   5 |    TABLE ACCESS FULL          | PS2_FS_TRANSACTION_FACT |   866K|    87M| 3121   (4)| 00:00:38 |   154 |   158 |
Predicate Information (identified by operation id):
   1 - access("AL1"."ACTION_TYPE_ID"="AL2"."ACTION_TYPE_ID")
   3 - filter("AL2"."ACTION_TYPE"='1' OR "AL2"."ACTION_TYPE"='2' OR "AL2"."ACTION_TYPE"='S')
Thank you very much,
Seyed

Star Query Full Table Scan

Hi, Folks:
I have a complex SQL statement that runs very slowly.
Following is the statement:
SELECT
T3.POSITION_ID,
T12.PR_POSTN_ID,
T12.PR_TERR_ID,
T12.PR_REP_MANL_FLG,
T9.CREATED,
T10.PR_EMP_ID,
T9.MODIFICATION_NUM,
T12.DEDUP_TOKEN,
T12.LOCATION_LEVEL,
T12.PR_PRTNR_OU_ID,
T12.PR_OU_TYPE_ID,
T12.PAR_DUNS_NUM,
T3.ACCNT_NAME,
T11.ATTRIB_16,
T6.PAR_ROW_ID,
T3.INVSTR_FLG,
T6.ROW_ID,
T12.DUNS_NUM,
T12.BU_ID,
T10.ROW_ID,
T2.LAST_NAME,
T3.SRV_PROVDR_FLG,
T12.X_PR_MERCH_NBR_ID,
T3.ROW_STATUS,
T12.NAME,
T11.PAR_ROW_ID,
T6.LAST_UPD_BY,
T6.MODIFICATION_NUM,
T3.PRIORITY_FLG,
T10.NAME,
T3.ASGN_SYS_FLG,
T9.PROFIT,
T12.PR_BL_ADDR_ID,
T12.PR_REP_ASGN_TYPE,
T9.LAST_UPD_BY,
T3.FACILITY_FLG,
T12.LAST_UPD_BY,
T12.PR_SHIP_ADDR_ID,
T11.MODIFICATION_NUM,
T11.LAST_UPD_BY,
T5.LOGIN,
T3.ASGN_MANL_FLG
FROM
S_ADDR_ORG T1,
S_CONTACT T2,
S_ACCNT_POSTN T3,
S_ORG_INT T4,
S_EMPLOYEE T5,
S_ORG_EXT_FNX T6,
S_ORG_SYN T7,
S_INDUST T8,
S_ORG_EXT_T T9,
S_POSTN T10,
S_ORG_EXT_X T11,
S_ORG_EXT T12
WHERE
T12.BU_ID = T4.ROW_ID (+) AND
T12.PR_CON_ID = T2.ROW_ID (+) AND
T12.ROW_ID = T7.OU_ID AND
T12.ROW_ID = T11.PAR_ROW_ID (+) AND
T12.ROW_ID = T6.PAR_ROW_ID (+) AND
T12.ROW_ID = T9.PAR_ROW_ID (+) AND
T12.PR_INDUST_ID = T8.ROW_ID (+) AND
T12.PR_ADDR_ID = T1.ROW_ID (+) AND
T12.PR_POSTN_ID = T10.ROW_ID AND
T12.PR_POSTN_ID = T3.POSITION_ID AND
T12.ROW_ID = T3.OU_EXT_ID AND
T10.PR_EMP_ID = T5.ROW_ID (+) AND
(T12.X_BMO_CUST_FLG = 'Y') AND
(T7.NAME IS NULL );
***** SQL Statement Execute Time: 31.703 seconds *****
I do a explain plan and found the table S_ORG_EXT (T12)
get a full table scan.
But I found the table S_ORG_EXT did have lots of indexes
build on each column shown in the where statement.
Our database use RULE base optimizer and it should use
index instead of full table scan.
Then, I look at this SQL and realize it is a star query.
One more thing is that the table S_ORG_SYN (T7) defined
the column NAME as NOT NULL. If the query process, it
should return no row.
But I still don't know for what reason the Oracle use
full table scan and ignore the S_ORG_SYN.NAME should be
NOT NULL
If I want to avoid the full table scan, how can I do by
not switching to COST base optimizer mode ?
Thanks,
Ke

Michael:
A nice explanantion. In my experience, in versions up to 8.1.7, the RBO seems to be faster in the large majority of queries than the CBO. In our payroll application (version 8.0.5), removing statistics cut the time for the calculation run from 6.5 hours to under 2.
The CBO seems to be significantly faster in 9i. We only have one application currently running in a 9.0.1 database. In this app, a large stored procedure took about 2 minutes to run when there were no statistics, and about 10 seconds after we analyzed the tables.
As more of our vendors migrate to 9 (we just got the last vendor migrated off 7.3 to 8.0.6 a couple of months ago), I may become a bigger fan of the CBO. John,
I remember having a discussion with you about the CBO in a thread once and am aware of your opinion of the CBO. My opinion has been test which works for you RBO or CBO - in our case we verified that CBO worked better for us. Anyway, I was searching metalink and it looks like you'll be forced to become a "bigger fan" of the CBO after 9i release 2. This is from part of Doc ID 189702.1 on metalink:
The rule-based optimizer (RBO) will be no longer be a valid optimization choice when Oracle9i is de-supported. The release after Oracle9i
(referred to in this article as Oracle10i) will only support the cost-based optimizer (CBO). Hence Oracle9i Release 2 is the last releases to
contain the RBO. Partners and customers should certify their applications with the CBO before that time.
...but of course Oracle has been warning people of the demise of the RBO for some time.
Al

Problem of full table scan on a partitioned table

hi all
There is a table called "si_sync_operation" that have 171040 number of rows.
I partitioned that table into a new table called "si_sync_operation_par" with 7 partitoins.
I issued the following statements
SELECT * FROM si_sync_operation_par.
SELECT * FROM si_sync_operation.
The explain plan show that the cost of the first statement is 1626 and that of the second statments is 1810.
The "cost" of full table scan on partitioned table is lower than the that of non-partitioned table.That's fine.
But the "Bytes" of full table scan on partitioned table is 5761288680 and that of the non-partitioned table is 263743680.
Why full table scan on partitioned table access more bytes than non-partitioned table?
And how could a statment that access more bytes results a lower cost?
Thank u very much

As Hemant metioned bytes reported are approximate number of bytes. As far as Cost is concerned, according to Tom its just a number and we should not compare queries by their cost. (search asktom.oracle.com for more information)
SQL> drop table non_part purge;
Table dropped.
SQL> drop table part purge;
Table dropped.
SQL>
SQL> CREATE TABLE non_part
2        (id NUMBER(5),
3         dt    DATE);
Table created.
SQL>
SQL> CREATE TABLE part
2        (id NUMBER(5),
3         dt    DATE)
4         PARTITION BY RANGE(dt)
5         (
6         PARTITION part1_jan2008 VALUES LESS THAN(TO_DATE('01/02/2008','DD/MM/YYYY')),
7         PARTITION part2_feb2008 VALUES LESS THAN(TO_DATE('01/03/2008','DD/MM/YYYY')),
8         PARTITION part3_mar2008 VALUES LESS THAN(TO_DATE('01/04/2008','DD/MM/YYYY')),
9         PARTITION part4_apr2008 VALUES LESS THAN(TO_DATE('01/05/2008','DD/MM/YYYY')),
10         PARTITION part5_may2008 VALUES LESS THAN(TO_DATE('01/06/2008','DD/MM/YYYY'))
11       );
Table created.
SQL>
SQL>
SQL> insert into non_part select rownum, trunc(sysdate) - rownum from dual connect by level <= 140;
140 rows created.
Execution Plan
Plan hash value: 1731520519
| Id | Operation                     | Name | Rows | Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT              |      |     1 |     2   (0)| 00:00:01 |
|   1 | COUNT                        |      |       |            |          |
|* 2 |   CONNECT BY WITHOUT FILTERING|      |       |            |          |
|   3 |    FAST DUAL                  |      |     1 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(LEVEL<=140)
SQL>
SQL> insert into part select * from non_part;
140 rows created.
Execution Plan
Plan hash value: 1654070669
| Id | Operation         | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT |          |   140 | 3080 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| NON_PART |   140 | 3080 |     3   (0)| 00:00:01 |
Note
   - dynamic sampling used for this statement
SQL>
SQL> commit;
Commit complete.
SQL>
SQL> set line 10000
SQL> set autotrace traceonly exp
SQL> select * from non_part;
Execution Plan
Plan hash value: 1654070669
| Id | Operation         | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |          |   140 | 3080 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| NON_PART |   140 | 3080 |     3   (0)| 00:00:01 |
Note
   - dynamic sampling used for this statement
SQL> select * from part;
Execution Plan
Plan hash value: 3392317243
| Id | Operation           | Name | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT    |      |   140 | 3080 |     9   (0)| 00:00:01 |       |       |
|   1 | PARTITION RANGE ALL|      |   140 | 3080 |     9   (0)| 00:00:01 |     1 |     5 |
|   2 |   TABLE ACCESS FULL | PART |   140 | 3080 |     9   (0)| 00:00:01 |     1 |     5 |
Note
   - dynamic sampling used for this statement
SQL>
SQL> exec dbms_stats.gather_table_stats(user, 'non_part');
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_table_stats(user, 'part');
PL/SQL procedure successfully completed.
SQL>
SQL>
SQL> select * from non_part;
Execution Plan
Plan hash value: 1654070669
| Id | Operation         | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |          |   140 | 1540 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| NON_PART |   140 | 1540 |     3   (0)| 00:00:01 |
SQL> select * from part;
Execution Plan
Plan hash value: 3392317243
| Id | Operation           | Name | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT    |      |   140 | 1540 |     9   (0)| 00:00:01 |       |       |
|   1 | PARTITION RANGE ALL|      |   140 | 1540 |     9   (0)| 00:00:01 |     1 |     5 |
|   2 |   TABLE ACCESS FULL | PART |   140 | 1540 |     9   (0)| 00:00:01 |     1 |     5 |
SQL>After analyzing the tables, notice that the Bytes column has changed value

FASTER THROUGH PUT ON FULL TABLE SCAN

제품 : ORACLE SERVER
작성날짜 : 1995-04-10
Subject: Faster through put on Full table scans
db_file_multiblock_read only affects the performance of full table scans.
Oracle has a maximum I/O size of 64KBytes hence db_blocksize *
db_file_multiblock_read must be less than or equal to 64KBytes.
If your query is really doing an index range scan then the performance
of full scans is irrelevant. In order to improve the performance of this
type of query it is important to reduce the number of blocks that
the 'interesting' part of the index is contained within.
Obviously the db_blocksize has the most impact here.
Historically Informix has not been able to modify their database block size,
and has had a fixed 2KB block.
On most Unix platforms Oracle can use up to 8KBytes.
(Some eg: Sequent allow 16KB).
This means that for the same size of B-Tree index Oracle with
an 8KB blocksize can read it's contents in 1/4 of the time that
Informix with a 2KB block could do.
You should also consider whether the PCTFREE value used for your index is
appropriate. If it is too large then you will be wasting space
in each index block. (It's too large IF you are not going to get any
entry size extension OR you are not going to get any new rows for existing
index values. NB: this is usually only a real consideration for large indexes - 10,000 entries is small.)
db_file_simultaneous_writes has no direct relevance to index re-balancing.
(PS: In the U.K. we benchmarked against Informix, Sybase, Unify and
HP/Allbase for the database server application that HP uses internally to
monitor and control it's Tape drive manufacturing lines. They chose
Oracle because: We outperformed Informix.
                         Sybase was too slow AND too
unreliable.
                         Unify was short on functionality
and SLOW.
                         HP/Allbase couldn't match the
availability
                         requirements and wasn't as
functional.
Informix had problems demonstrating the ability to do hot backups without
severely affecting the system throughput.
HP benchmarked all DB vendors on both 9000/800 and 9000/700 machines with
different disks (ie: HP-IB and SCSI). Oracle came out ahead in all
configurations.
NNB: It's always worth throwing in a simulated system failure whilst the
benchmark is in progress. Informix has a history of not coping gracefully.
That is they usually need some manual intervention to perform the database
recovery.)
I have a perspective client who is running a stripped down souped version of
informix with no catalytic converter. One of their queries boils down to an
Index Range Scan on 10000 records. How can I achieve better throughput
on a single drive single CPU machine (HP/UX) without using raw devices.
I had heard rebuilding the database with a block size factor greater than
the OS block size would yield better performance. Also I tried changing
the db_file_multiblock_read_count to 32 without much improvement.
Adjusting the db_writers to two did not help either.
Also will the adjustment of the db_file_simultaneous_writes help on
the maintenance of a index during rebalancing operations.

2)if cbo, how are the stats collected?
daily(less than millions rows of table) and weekly(all tables)There's no need to collect stats so frequently unless it's absolute necessary like you have massive update on tables daily or weekly.
It will help if you can post your sample explain plan and query.

Locate SQL causes full table scans from Statspack

Hello,
In my statspack reports I see a lot of full tables scans (1,425,297)
How can I locate the query that causes this ?
stats$sql_plan should fit?
Oracle is 9i
Thank you

>
How can I locate the query that causes this ?
It can be hard. One idea is to put comments in queries identifying where they come from, something like
select /* my_package.my_procedure */ *
from dual;
[/code
The comment should remain with the sql text so various reports showing the sql text should also indicate where the query is]

Find out the SQLs which are using a full table scan

Hello all , how can i to find out the queries which are using a full table scan ? Any idea ?

In general, though, why would you want to tune SQL statements that aren't causing problems? Statspack will tell you what the most resource-intensive SQL statements on your system are. A SQL*Net trace of sessions that are performing poorly will indicate which statements are the most resource-intensive for that session. If a statement is incorrectly doing a full-table scan, but it is not causing a problem, why spend time tuning it? If you're not focusing your tuning attention on identifying statements that are causing problems, you'll also miss out on 90% of tuning opportunities which involve rewriting (or eliminating) code to make it more efficient. I can simulate a join on two tables with nested cursor loops, which won't generate a single full table scan, but replacing that code with a real join, while it will cause at least one full table scan, will be orders of magnitude faster.
As an aside, full table scans aren't necessarily a bad thing. If a statement needs to retrieve more than a couple percent of the rows of a table, full table scans are the most efficient way to go.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Full Table Scans on Auto Ship Confirm Report (WSHRDASC) Causing

Severe performance issue with Auto Ship Confirm report WSHRDASC.
From the statspack reports, a single sql statement that iscurrently consuming approximately 50% of all physical disk I/O.
2 full table scans coming from this problem query :-
Rows Row Source Operation
SORT ORDER BY
NESTED LOOPS OUTER
NESTED LOOPS
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS OUTER
NESTED LOOPS OUTER
TABLE ACCESS FULL WSH_NEW_DELIVERIES
TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS
INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U1 (object id 81392)
TABLE ACCESS BY INDEX ROWID HZ_PARTIES
INDEX UNIQUE SCAN HZ_PARTIES_U1 (object id 172682)
TABLE ACCESS BY INDEX ROWID WSH_EXCEPTIONS
INDEX RANGE SCAN WSH_EXCEPTIONS_N9 (object id 133587)
TABLE ACCESS BY INDEX ROWID WSH_DELIVERY_LEGS
INDEX RANGE SCAN WSH_DELIVERY_LEGS_N1 (object id 46224)
TABLE ACCESS BY INDEX ROWID WSH_DOCUMENT_INSTANCES
INDEX RANGE SCAN WSH_DOCUMENT_INSTANCES_N1 (object id 46405)
TABLE ACCESS FULL WSH_PICKING_BATCHES
TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES
INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (object id 34010)
Please help i have applied one patch for this issue Patch 5531283. Then also same issue

Hi;
WHat is your EBS version?
If note Full Table Scans on Auto Ship Confirm Report (WSHRDASC) Causing Performance Issues [ID 393014.1] doesnt help than I suggest rise SR
Regard
Helios

How can i make the optimiser to skip this full table scan ??

Hi,
I am trying to tune the below query, I have checked up all the possibilities to skip the full table scan on vhd_calldesh_archive, But am unable to find the predicate in the where clause, which is letting the optimiser to choose the full table scan on vhd_calldesk_archive table, which is very large one. how can i make the optimiser to skip this full table scan.
Please check the below sql script and explain plan ,
SELECT a.call_id, a.entry_date,
NVL (INITCAP (b.full_name), caller_name) AS caller_name,
c.description AS org_desc, a.env_id, i.env_desc, a.appl_id,
d.appl_desc, a.module_id, e.module_desc, a.call_type_id,
f.call_type_desc, a.priority, a.upduserid,
INITCAP (g.full_name) AS lastupdated_username, a.call_desc, h.mode_desc,
a.received_time,a.assignment_team, a.status,
ROUND (lcc.pkg_com.fn_datediff ('MI',
a.entry_date,
a.status_date
) AS elapsed_time,
ROUND (lcc.pkg_com.fn_datediff ('MI',
a.entry_date,
a.status_date
) AS resolved_min,
CASE
WHEN a.orgid in (1,100,200) THEN a.orgid
ELSE j.regionorgid
END AS region
,(SELECT coalesce(MAX(upddate),a.upddate) FROM lcc.vhd_callstatus stat WHERE stat.call_id = a.call_id
) as stat_upddate
,(SELECT team_desc from lcc.vhd_teams t where t.team_id = a.assignment_team) as team_desc
,a.eta_date
,coalesce(a.caller_contact, b.telephone) AS caller_contact
,coalesce(a.caller_email, b.email) as email
,a.affected_users
,a.outage_time
,a.QA_DONE
,a.LAST_ACTION_TEAM
,a.LAST_ACTION_USER
,INITCAP (k.full_name) AS last_action_username
,a.last_action_date
,l.team_desc as last_action_teamdesc
,a.refid
,INITCAP (lu.full_name) AS logged_name
,a.pmreview
,a.status as main_status
FROM lcc.vhd_calldesk_archive a
LEFT OUTER JOIN lcc.lcc_userinfo_details b ON b.user_name = a.caller_id
INNER JOIN lcc.com_organization c ON c.code = a.orgid
INNER JOIN lcc.vhd_applications d ON d.appl_id = a.appl_id
INNER JOIN lcc.vhd_modules e ON e.appl_id = a.appl_id AND e.module_id = a.module_id
INNER JOIN lcc.vhd_calltypes f ON f.call_type_id = a.call_type_id
INNER JOIN lcc.com_rptorganization j ON j.orgid = a.orgid AND j.tree = 'HLPDK'
LEFT OUTER JOIN lcc.lcc_userinfo_details g ON g.user_name = a.upduserid
LEFT OUTER JOIN lcc.vhd_callmode h ON h.mode_id = a.mode_id
LEFT OUTER JOIN lcc.vhd_environment i ON i.appl_id = a.appl_id AND i.env_id = a.env_id
LEFT OUTER JOIN lcc.lcc_userinfo_details k ON k.user_name = a.last_action_user
LEFT OUTER JOIN lcc.vhd_teams l ON l.team_id = a.last_action_user
LEFT OUTER JOIN (select CALL_ID,upduserid FROM lcc.VHD_CALLDESK_HISTORY P where upddate
in ( select min(upddate) from lcc.VHD_CALLDESK_HISTORY Q WHERE Q.CALL_ID = P.CALL_ID
group by call_id)) ku
ON ku.call_id = a.call_id
LEFT OUTER JOIN lcc.lcc_userinfo_details lu ON NVL(ku.upduserid,A.upduserid) = lu.user_name;
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 2104 | 3667K| 37696 |
| 1 | UNION-ALL | | | | |
| 2 | NESTED LOOPS OUTER | | 2103 | 3665K| 37683 |
| 3 | VIEW | | 2103 | 3616K| 35580 |
| 4 | NESTED LOOPS OUTER | | 2103 | 823K| 35580 |
| 5 | NESTED LOOPS OUTER | | 2103 | 774K| 33477 |
| 6 | NESTED LOOPS OUTER | | 2103 | 685K| 31374 |
| 7 | NESTED LOOPS | | 2103 | 636K| 29271 |
| 8 | NESTED LOOPS | | 2103 | 603K| 27168 |
| 9 | NESTED LOOPS OUTER | | 2103 | 558K| 25065 |
| 10 | NESTED LOOPS OUTER | | 2103 | 515K| 22962 |
| 11 | NESTED LOOPS | | 2103 | 472K| 20859 |
| 12 | NESTED LOOPS | | 2103 | 429K| 18756 |
| 13 | NESTED LOOPS OUTER | | 4826 | 890K| 13930 |
| 14 | NESTED LOOPS OUTER | | 4826 | 848K| 9104 |
| 15 | NESTED LOOPS | | 4826 | 754K| 4278 |
|* 16 | TABLE ACCESS FULL | COM_RPTORGANIZATION | 75 | 1050 | 3 |
| 17 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK | 64 | 9344 | 57 |
|* 18 | INDEX RANGE SCAN | VHD_CALLDSK_ORGID | 2476 | | 7 |
| 19 | VIEW PUSHED PREDICATE | | 1 | 20 | 1 |
|* 20 | FILTER | | | | |
| 21 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK_HISTORY | 1 | 20 | 2 |
|* 22 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
|* 23 | FILTER | | | | |
| 24 | SORT GROUP BY NOSORT | | 1 | 12 | 2 |
| 25 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK_HISTORY | 1 | 12 | 2 |
|* 26 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
| 27 | TABLE ACCESS BY INDEX ROWID | VHD_CALLMODE | 1 | 9 | 1 |
|* 28 | INDEX UNIQUE SCAN | VHD_CALLMOD_MODID_PK | 1 | | |
| 29 | TABLE ACCESS BY INDEX ROWID | VHD_APPLICATIONS | 1 | 20 | 1 |
|* 30 | INDEX UNIQUE SCAN | VHD_APPL_APPLID_PK | 1 | | |
| 31 | TABLE ACCESS BY INDEX ROWID | VHD_CALLTYPES | 1 | 21 | 1 |
|* 32 | INDEX UNIQUE SCAN | VHD_CALLTYP_ID_PK | 1 | | |
| 33 | TABLE ACCESS BY INDEX ROWID | VHD_TEAMS | 1 | 21 | 1 |
|* 34 | INDEX UNIQUE SCAN | VHD_TEAMID_PK | 1 | | |
| 35 | TABLE ACCESS BY INDEX ROWID | VHD_ENVIRONMENT | 1 | 21 | 1 |
|* 36 | INDEX UNIQUE SCAN | VHD_ENV_APLENVID_PK | 1 | | |
| 37 | TABLE ACCESS BY INDEX ROWID | VHD_MODULES | 1 | 22 | 1 |
|* 38 | INDEX UNIQUE SCAN | VHD_MOD_APLMOD_ID_PK | 1 | | |
| 39 | TABLE ACCESS BY INDEX ROWID | COM_ORGANIZATION | 1 | 16 | 1 |
|* 40 | INDEX UNIQUE SCAN | COM_ORG_PK | 1 | | |
| 41 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 |
|* 42 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 43 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 43 |
|* 44 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 45 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
|* 46 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 47 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
|* 48 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 49 | NESTED LOOPS OUTER | | 1 | 1785 | 13 |
| 50 | VIEW | | 1 | 1761 | 12 |
| 51 | NESTED LOOPS OUTER | | 1 | 1656 | 12 |
| 52 | NESTED LOOPS OUTER | | 1 | 1632 | 11 |
| 53 | NESTED LOOPS OUTER | | 1 | 1608 | 10 |
| 54 | NESTED LOOPS | | 1 | 1565 | 9 |
| 55 | NESTED LOOPS | | 1 | 1549 | 9 |
| 56 | NESTED LOOPS | | 1 | 1535 | 9 |
| 57 | NESTED LOOPS OUTER | | 1 | 1513 | 8 |
| 58 | NESTED LOOPS OUTER | | 1 | 1492 | 7 |
| 59 | NESTED LOOPS | | 1 | 1471 | 6 |
| 60 | NESTED LOOPS | | 1 | 1450 | 5 |
| 61 | NESTED LOOPS OUTER | | 1 | 1430 | 4 |
| 62 | NESTED LOOPS OUTER | | 1 | 1421 | 3 |
| 63 | TABLE ACCESS FULL | VHD_CALLDESK_ARCHIVE | 1 | 1401 | 2 |
| 64 | VIEW PUSHED PREDICATE | | 1 | 20 | 1 |
|* 65 | FILTER | | | | |
| 66 | TABLE ACCESS BY INDEX ROWID | VHD_CALLDESK_HISTORY | 1 | 20 | 2 |
|* 67 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
|* 68 | FILTER | | | | |
| 69 | SORT GROUP BY NOSORT | | 1 | 12 | 2 |
| 70 | TABLE ACCESS BY INDEX ROWID| VHD_CALLDESK_HISTORY | 1 | 12 | 2 |
|* 71 | INDEX RANGE SCAN | VHD_CALLDSK_HIST_CALLID_IDX | 1 | | 1 |
| 72 | TABLE ACCESS BY INDEX ROWID | VHD_CALLMODE | 1 | 9 | 1 |
|* 73 | INDEX UNIQUE SCAN | VHD_CALLMOD_MODID_PK | 1 | | |
| 74 | TABLE ACCESS BY INDEX ROWID | VHD_APPLICATIONS | 1 | 20 | 1 |
|* 75 | INDEX UNIQUE SCAN | VHD_APPL_APPLID_PK | 1 | | |
| 76 | TABLE ACCESS BY INDEX ROWID | VHD_CALLTYPES | 1 | 21 | 1 |
|* 77 | INDEX UNIQUE SCAN | VHD_CALLTYP_ID_PK | 1 | | |
| 78 | TABLE ACCESS BY INDEX ROWID | VHD_TEAMS | 1 | 21 | 1 |
|* 79 | INDEX UNIQUE SCAN | VHD_TEAMID_PK | 1 | | |
| 80 | TABLE ACCESS BY INDEX ROWID | VHD_ENVIRONMENT | 1 | 21 | 1 |
|* 81 | INDEX UNIQUE SCAN | VHD_ENV_APLENVID_PK | 1 | | |
| 82 | TABLE ACCESS BY INDEX ROWID | VHD_MODULES | 1 | 22 | 1 |
|* 83 | INDEX UNIQUE SCAN | VHD_MOD_APLMOD_ID_PK | 1 | | |
| 84 | TABLE ACCESS BY INDEX ROWID | COM_RPTORGANIZATION | 1 | 14 | |
|* 85 | INDEX UNIQUE SCAN | COM_RPTORG_PK | 1 | | |
| 86 | TABLE ACCESS BY INDEX ROWID | COM_ORGANIZATION | 1 | 16 | |
|* 87 | INDEX UNIQUE SCAN | COM_ORG_PK | 1 | | |
| 88 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 43 |
|* 89 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 90 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 |
|* 91 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 92 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
|* 93 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
| 94 | TABLE ACCESS BY INDEX ROWID | LCC_USERINFO_DETAILS | 1 | 24 | 1
|* 95 | INDEX UNIQUE SCAN | LCCUSERINFOIND | 1 | | |
Predicate Information (identified by operation id):
16 - filter("J"."TREE"='HLPDK')
18 - access("J"."ORGID"="A"."ORGID")
20 - filter( EXISTS (SELECT /*+ */ 0 FROM "LCC"."VHD_CALLDESK_HISTORY" "Q" WHERE "Q"."CALL_ID"=:B1
"Q"."CALL_ID" HAVING MIN("Q"."UPDDATE")=:B2))
22 - access("SYS_ALIAS_2"."CALL_ID"="A"."CALL_ID")
23 - filter(MIN("Q"."UPDDATE")=:B1)
26 - access("Q"."CALL_ID"=:B1)
28 - access("H"."MODE_ID"(+)="A"."MODE_ID")
30 - access("D"."APPL_ID"="A"."APPL_ID")
32 - access("F"."CALL_TYPE_ID"="A"."CALL_TYPE_ID")
34 - access("L"."TEAM_ID"(+)="A"."LAST_ACTION_TEAM")
36 - access("I"."APPL_ID"(+)="A"."APPL_ID" AND "I"."ENV_ID"(+)="A"."ENV_ID")
38 - access("E"."APPL_ID"="A"."APPL_ID" AND "E"."MODULE_ID"="A"."MODULE_ID")
40 - access("C"."CODE"="A"."ORGID")
42 - access("K"."USER_NAME"(+)="A"."LAST_ACTION_USER")
44 - access("B"."USER_NAME"(+)="A"."CALLER_ID")
46 - access("G"."USER_NAME"(+)="A"."UPDUSERID")
48 - access("LU"."USER_NAME"(+)=NVL("SYS_ALIAS_4"."UPDUSERID_162","SYS_ALIAS_4"."UPDUSERID_25"))
65 - filter( EXISTS (SELECT /*+ */ 0 FROM "LCC"."VHD_CALLDESK_HISTORY" "Q" WHERE "Q"."CALL_ID"=:B1
"Q"."CALL_ID" HAVING MIN("Q"."UPDDATE")=:B2))
67 - access("SYS_ALIAS_2"."CALL_ID"="SYS_ALIAS_1"."CALL_ID")
68 - filter(MIN("Q"."UPDDATE")=:B1)
71 - access("Q"."CALL_ID"=:B1)
73 - access("H"."MODE_ID"(+)="SYS_ALIAS_1"."MODE_ID")
75 - access("D"."APPL_ID"="SYS_ALIAS_1"."APPL_ID")
77 - access("F"."CALL_TYPE_ID"="SYS_ALIAS_1"."CALL_TYPE_ID")
79 - access("L"."TEAM_ID"(+)=TO_NUMBER("SYS_ALIAS_1"."LAST_ACTION_USER"))
81 - access("I"."APPL_ID"(+)="SYS_ALIAS_1"."APPL_ID" AND "I"."ENV_ID"(+)="SYS_ALIAS_1"."ENV_ID")
83 - access("E"."APPL_ID"="SYS_ALIAS_1"."APPL_ID" AND "E"."MODULE_ID"="SYS_ALIAS_1"."MODULE_ID")
85 - access("SYS_ALIAS_1"."ORGID"="J"."ORGID" AND "J"."TREE"='HLPDK')
87 - access("C"."CODE"="SYS_ALIAS_1"."ORGID")
89 - access("B"."USER_NAME"(+)="SYS_ALIAS_1"."CALLER_ID")
91 - access("SYS_ALIAS_1"."UPDUSERID"="G"."USER_NAME"(+))
93 - access("K"."USER_NAME"(+)="SYS_ALIAS_1"."LAST_ACTION_USER")
95 - access("LU"."USER_NAME"(+)=NVL("SYS_ALIAS_3"."UPDUSERID_162","SYS_ALIAS_3"."UPDUSERID_25"))
Note: cpu costing is off

I've tried to look thru your sql and changed it a bit. Of course not testet :-)
Your problem isn't the archive table! I tried to remove the 2 selects from the select-clause. Furthermore you have a lot of nested loops in your explain, which is a performance-killer. Try getting rid of them, perhaps use /*+ USE_HASH(?,?) */.
SELECT a.call_id, a.entry_date,
       NVL (INITCAP (b.full_name), caller_name) AS caller_name, c.description AS org_desc, a.env_id, i.env_desc, a.appl_id,
       d.appl_desc, a.module_id, e.module_desc, a.call_type_id, f.call_type_desc, a.priority, a.upduserid,
       INITCAP (g.full_name) AS lastupdated_username, a.call_desc, h.mode_desc, a.received_time, a.assignment_team, a.status,
       ROUND (lcc.pkg_com.fn_datediff ('MI', a.entry_date, a.status_date)) AS elapsed_time,
       ROUND (lcc.pkg_com.fn_datediff ('MI', a.entry_date, a.status_date)) AS resolved_min,
       CASE
          WHEN a.orgid IN (1, 100, 200)
             THEN a.orgid
          ELSE j.regionorgid
       END AS region,
       COALESCE (stat.upddate, a.upddate) AS stat_upddate,
       t.team_desc, a.eta_date,
       COALESCE (a.caller_contact, b.telephone) AS caller_contact,
       COALESCE (a.caller_email, b.email) AS email, a.affected_users,
       a.outage_time, a.qa_done, a.last_action_team, a.last_action_user,
       INITCAP (k.full_name) AS last_action_username, a.last_action_date,
       l.team_desc AS last_action_teamdesc, a.refid,
       INITCAP (lu.full_name) AS logged_name, a.pmreview,
       a.status AS main_status
FROM lcc.vhd_calldesk_archive a, lcc.lcc_userinfo_details b, lcc.com_organization c,
       lcc.vhd_applications d, lcc.vhd_modules e, lcc.vhd_calltypes f, lcc.com_rptorganization j,
       lcc.lcc_userinfo_details g, lcc.vhd_callmode h, lcc.vhd_environment i, lcc.lcc_userinfo_details k,
       lcc.vhd_teams l,
      (SELECT call_id, upduserid
       FROM lcc.vhd_calldesk_history p
       WHERE upddate IN (SELECT   MIN (upddate)
                         FROM lcc.vhd_calldesk_history q
                         WHERE q.call_id = p.call_id
                         GROUP BY call_id)) ku,
       lcc.lcc_userinfo_details lu,
      (SELECT call_id, MAX (upddate)
       FROM lcc.vhd_callstatus
       GROUP BY call_id) stat,
       lcc.vhd_teams t
WHERE a.caller_id        = b.user_name(+)
    AND a.orgid            = c.code
    AND a.appl_id          = d.appl_id
    AND a.appl_id          = e.appl_id
    AND a.module_id        = e.module_id
    AND a.call_type_id     = f.call_type_id
    AND a.orgid            = j.orgid
    AND j.tree             = 'HLPDK'
    AND a.upduserid        = g.user_name(+)
    AND a.mode_id          = h.mode_id(+)
    AND a.appl_id          = i.appl_id(+)
    AND a.env_id           = i.env_id(+)
    AND a.last_action_user = k.user_name(+)
    AND a.last_action_user = l.team_id(+)
    AND a.call_id          = ku.call_id(+)
    AND NVL (ku.upduserid, a.upduserid) = lu.user_name(+)
    AND a.call_id          = stat.call_id
    AND a.assignment_team = t.team_id;

Taking more time in INDEX RANGE SCAN compare to the full table scan

Hi all ,
Below are the version og my database.
SQL> select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for HPUX: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
I have gather the table statistics and plan change for sql statment.
SELECT P1.COMPANY, P1.PAYGROUP, P1.PAY_END_DT, P1.PAYCHECK_OPTION,
P1.OFF_CYCLE, P1.PAGE_NUM, P1.LINE_NUM, P1.SEPCHK FROM PS_PAY_CHECK P1
WHERE P1.FORM_ID = :1 AND P1.PAYCHECK_NBR = :2 AND
P1.CHECK_DT = :3 AND P1.PAYCHECK_OPTION <> 'R'
Plan before the gather stats.
Plan hash value: 3872726522
| Id | Operation         | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |              |       |       | *14306* (100)|          |
|   1 | *TABLE ACCESS FULL| PS_PAY_CHECK* |     1 |    51 | 14306   (4)| 00:02:52 |
Plan after the gather stats:
Operation     Object Name     Rows     Bytes     Cost
SELECT STATEMENT Optimizer Mode=CHOOSE
          1           4
*TABLE ACCESS BY INDEX ROWID     SYSADM.PS_PAY_CHECK*     1     51     *4*
    *INDEX RANGE SCAN     SYSADM.PS0PAY_CHECK*     1           3After gather stats paln look good . but when i am exeuting the query it take 5 hours. before the gather stats it finishing the within 2 hours. i do not want to restore my old statistics. below are the data for the tables.and when i am obserrving it lot of db files scatter rea
NAME                                 TYPE        VALUE
_optimizer_cost_based_transformation string      OFF
filesystemio_options                 string      asynch
object_cache_optimal_size            integer     102400
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      choose
optimizer_secure_view_merging        boolean     TRUE
plsql_optimize_level                 integer     2
SQL> select count(*) from sysadm.ps_pay_check;
select num_rows,blocks from dba_tables where table_name ='PS_PAY_CHECK';
COUNT(*)
   1270052
SQL> SQL> SQL>
NUM_ROWS     BLOCKS
   1270047      63166
Event                                 Waits    Time (s)   (ms)   Time Wait Class
db file sequential read           1,584,677       6,375      4   36.6   User I/O
db file scattered read            2,366,398       5,689      2   32.7   User I/Oplease let me know why it taking more time in INDEX RANGE SCAN compare to the full table scan?

suresh.ratnaji wrote:
NAME                                 TYPE        VALUE
_optimizer_cost_based_transformation string      OFF
filesystemio_options                 string      asynch
object_cache_optimal_size            integer     102400
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      choose
optimizer_secure_view_merging        boolean     TRUE
plsql_optimize_level                 integer     2
please let me know why it taking more time in INDEX RANGE SCAN compare to the full table scan?Suresh,
Any particular reason why you have a non-default value for a hidden parameter, optimizercost_based_transformation ?
On my 10.2.0.1 database, its default value is "linear". What happens when you reset the value of the hidden parameter to default?

Where columnname like '%somevalue' causing full table scan

hi,
10.2.0.4 database
is it possible to force an index scan over a full table scan if I use a where clause similar to the following:
where col1 like '%somevalue';
There is an index with col1 as the first segment of the index and another column as the second segment of the index.
Thanks
JOhn

I have done it for you
SQL> create index empX on emp(job) ;
Index created.
SQL> explain plan for select * from emp where job like '%ERK' ;
Explained.
SQL> select * from table(dbms_xplan.display) ;
PLAN_TABLE_OUTPUT
Plan hash value: 3956160932
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |    37 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP |     1 |    37 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("JOB" LIKE '%ERK')
13 rows selected.
SQL> explain plan for select * from emp where job like 'C%ERK' ;
Explained.
SQL> select * from table(dbms_xplan.display) ;
PLAN_TABLE_OUTPUT
Plan hash value: 140376749
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |      |     4 |   148 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| EMP |     4 |   148 |     2   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | EMPX |     4 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("JOB" LIKE 'C%ERK')
       filter("JOB" LIKE 'C%ERK')
15 rows selected.
SQL> explain plan for select /*+index (emp,EMPX) */ * from emp where job like '%ERK' ;
Explained.
SQL> select * from table(dbms_xplan.display) ;
PLAN_TABLE_OUTPUT
Plan hash value: 3745534319
| Id | Operation                   | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |      |     1 |    37 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| EMP |     1 |    37 |     2   (0)| 00:00:01 |
|* 2 |   INDEX FULL SCAN           | EMPX |     1 |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter("JOB" LIKE '%ERK')
14 rows selected.SS

Determine the cause of FULL table scan

Similar Messages

Maybe you are looking for