Update Query is Performing Full table Scan of 1 Millions Records

Hello Everyboby I have one update query ,
UPDATE tablea SET
          task_status = 12
          WHERE tablea.link_id >0
          AND tablea.task_status <> 0
          AND tablea.event_class='eventexception'
          AND Exists(SELECT 1 from tablea ltask where ltask.task_id=tablea.link_id
          AND ltask.task_status = 0)
When I do explain plan it shows following result...
Execution Plan
0 UPDATE STATEMENT Optimizer=CHOOSE
1 0 UPDATE OF 'tablea'
2 1 FILTER
3 2 TABLE ACCESS (FULL) OF 'tablea'
4 2 TABLE ACCESS (BY INDEX ROWID) OF 'tablea'
5 4 INDEX (UNIQUE SCAN) OF 'PK_tablea' (UNIQUE)
NOW tablea may have more than 10 MILLION Records....This would take hell of time even if it has to
update 2 records....please suggest me some optimal solutions.....
Regards
Mahesh

I see your point but my question or logic say i have index on all columns used in where clauses so i find no reason for oracle to do full table scan,,,,
UPDATE tablea SET
task_status = 12
WHERE tablea.link_id >0
AND tablea.task_status <> 0
AND tablea.event_class='eventexception'
AND Exists(SELECT 1 from tablea ltask where ltask.task_id=tablea.link_id
AND ltask.task_status = 0)
I am clearly statis where task_status <> 0 and event_class= something and tablea.link_id >0
so ideal case FOR optimizer should be
Step 1)Select all the rowid having this condition...
Step 2)
For each row in rowid get all the row where task_status=0
and where taskid=linkid of rowid selected above...
Step 3)While looping for each rowid if it find any condition try for rowid obtained from ltask in task 2 update that record....
I want to have this kind of plan,,,,,does anyone know how to make oracle obtained this kind of plan......
It is try FULL TABLE SCAN is harmfull alteast not better than index scan.....

Similar Messages

Query is doing full table scan

Hi All,
The below query is doing full table scan. So many threads from application trigger this query and doing full table scan. Can you please tell me how to improve the performance of this query?
Env is 11.2.0.3 RAC (4 node). Unique index on VZ_ID, LOGGED_IN. The table row count is 2,501,103.
Query is :-
select ccagentsta0_.LOGGED_IN as LOGGED1_404_, ccagentsta0_.VZ_ID as VZ2_404_, ccagentsta0_.ACTIVE as ACTIVE404_, ccagentsta0_.AGENT_STATE as AGENT4_404_,
ccagentsta0_.APPLICATION_CODE as APPLICAT5_404_, ccagentsta0_.CREATED_ON as CREATED6_404_, ccagentsta0_.CURRENT_ORDER as CURRENT7_404_,
ccagentsta0_.CURRENT_TASK as CURRENT8_404_, ccagentsta0_.HELM_ID as HELM9_404_, ccagentsta0_.LAST_UPDATED as LAST10_404_, ccagentsta0_.LOCATION as LOCATION404_,
ccagentsta0_.LOGGED_OUT as LOGGED12_404_, ccagentsta0_.SUPERVISOR_VZID as SUPERVISOR13_404_, ccagentsta0_.VENDOR_NAME as VENDOR14_404_
from AGENT_STATE ccagentsta0_ where ccagentsta0_.VZ_ID='v790531' and ccagentsta0_.ACTIVE='Y';
Table Scan                                                       AGENT_STATE                                                2.366666667
Table Scan                                                       AGENT_STATE                                                0.3666666667
Table Scan                                                       AGENT_STATE                                                1.633333333
Table Scan                                                       AGENT_STATE                                                       0.75
Table Scan                                                       AGENT_STATE                                                1.866666667
Table Scan                                                       AGENT_STATE                                                2.533333333
Table Scan                                                       AGENT_STATE                                                0.5333333333
Table Scan                                                       AGENT_STATE                                                       1.95
Table Scan                                                       AGENT_STATE                                                        0.8
Table Scan                                                       AGENT_STATE                                                0.2833333333
Table Scan                                                       AGENT_STATE                                                1.983333333
Table Scan                                                       AGENT_STATE                                                        2.5
Table Scan                                                       AGENT_STATE                                                1.866666667
Table Scan                                                       AGENT_STATE                                                1.883333333
Table Scan                                                       AGENT_STATE                                                        0.9
Table Scan                                                       AGENT_STATE                                                2.366666667
But the explain plan shows the query is taking the index
Explain plan output:-
PLAN_TABLE_OUTPUT
Plan hash value: 1946142815
| Id | Operation                   | Name            | Rows | Bytes | Cost (%C
PU)| Time     |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT            |                 |     1 |   106 |   244
(0)| 00:00:03 |
|* 1 | TABLE ACCESS BY INDEX ROWID| AGENT_STATE     |     1 |   106 |   244
(0)| 00:00:03 |
|* 2 |   INDEX RANGE SCAN          | AGENT_STATE_IDX |   229 |       |     4
(0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   1 - filter("CCAGENTSTA0_"."ACTIVE"='Y')
   2 - access("CCAGENTSTA0_"."VZ_ID"='v790531')
The values (VZ_ID) i have given are dummy values picked from the table. I dont get the actual values since the query is coming with bind variables. Please let me know your suggestion on this.
Thanks,
Mani

Hi,
But I am not getting what is the issue..its a simple select query and index is there on one of the leading columns (VZ_ID --- PK). Explain plan says its using its using Index and it only select fraction of rows from the table. Then why it is doing FTS. For Optimizer, why its like a query doing FTS.
The rule-based optimizer would have picked the plan with the index. The cost-based optimizer, however, is picking the plan with the lowest cost. Apparently, the lowest cost plan is the one with the full table scan. And the optimizer isn't necessarily wrong about this.
Reading data from a table via index probes is only efficient when selecting a relatively small percentage of rows. For larger percentages, a full table scan is generally better.
Consider a simple example: a query that selects from a table with biographies for all people on the planet. Suppose you are interested in all people from a certain country.
select * from all_people where country='Vatican'
would only return only 800 rows (as Vatican is an extremely small country with population of just 800 people). For this case, obviously, using an index would be very efficient.
Now if we run this query:
select * from all_people where contry = 'India',
we'd be getting over a billion of rows. For this case, a full table scan would be several thousand times faster.
Now consider the third case:
select * from all_people where country = :b1
What plan should the optimizer choose? The value of :b1 bind variable is generally not known during the parse time, it will be passed by the user when the query is already parsed, during run-time.
In this case, one of two scenarios takes place: either the optimizer relies on some built-in default selectivities (basically, it takes a wild guess), or the optimizer postpones taking the final decision until the
first time the query is run, 'peeks' the value of the bind, and optimizes the query for this case.
In means, that if the first time the query is parsed, it was called with :b1 = 'India', a plan with a full table scan will be generated and cached for subsequent usage. And until the cursor is aged out of library cache
or invalidated for some reason, this will be the plan for this query.
If the first time it was called with :b1='Vatican', then an index-based plan will be picked.
Either way, bind peeking only gives good results if the subsequent usage of the query is the same kind as the first usage. I.e. in the first case it will be efficient, if the query would always be run for countries with big popultions.
And in the second case, if it's always run for countries with small populations.
This mechanism is called 'bind peeking' and it's one of the most common causes of performance problems. In 11g, there are more sophisticated mechanisms, such a cardinality feedback, but they don't always work as expected.
This mechanism is the most likely explanation for your issue. However, without proper diagnostic information we cannot be 100% sure.
Best regards,
Nikolay

Why does query do a full table scan?

I have a simple select query that filters on the last 10 or 11 days of data from a table. In the first case it executes in 1 second. In the second case it is taking 15+ minutes and still not done.
I can tell that the second query (11 days) is doing a full table scan.
- Why is this happening? ... I guess some sort of threshold calculation???
- Is there a way to prevent this? ... or encourage Oracle to play nice.
I find it confusing from a front end/query perspective to get vastly different performance.
Jason
Oracle 10g
Quest Toad 10.6
CREATE TABLE delme10 AS
SELECT *
FROM ed_visits
WHERE first_contact_dt >= TRUNC(SYSDATE-10,'D');
Plan hash value: 915912709
| Id | Operation                    | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | CREATE TABLE STATEMENT       |                   | 4799 | 5534K| 4951   (1)| 00:01:00 |
|   1 | LOAD AS SELECT              | DELME10           |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID| ED_VISITS         | 4799 | 5534K| 4796   (1)| 00:00:58 |
|* 3 |    INDEX RANGE SCAN          | NDX_ED_VISITS_020 | 4799 |       |    15   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("FIRST_CONTACT_DT">=TRUNC(SYSDATE@!-10,'fmd'))
CREATE TABLE delme11 AS
SELECT *
FROM ed_visits
WHERE first_contact_dt >= TRUNC(SYSDATE-11,'D');
Plan hash value: 1113251513
| Id | Operation              | Name      | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | CREATE TABLE STATEMENT |           | 25157 |    28M| 14580   (1)| 00:02:55 |        |      |            |
|   1 | LOAD AS SELECT        | DELME11   |       |       |            |          |        |      |            |
|   2 |   PX COORDINATOR       |           |       |       |            |          |        |      |            |
|   3 |    PX SEND QC (RANDOM) | :TQ10000 | 25157 |    28M| 14530   (1)| 00:02:55 | Q1,00 | P->S | QC (RAND) |
|   4 |     PX BLOCK ITERATOR |           | 25157 |    28M| 14530   (1)| 00:02:55 | Q1,00 | PCWC |            |
|* 5 |      TABLE ACCESS FULL | ED_VISITS | 25157 |    28M| 14530   (1)| 00:02:55 | Q1,00 | PCWP |            |
Predicate Information (identified by operation id):
   5 - filter("FIRST_CONTACT_DT">=TRUNC(SYSDATE@!-11,'fmd'))

Hi Jason,
I think you're right with kind of "threshold". You can verify CBO costing with event 10053 enabled. There are many possible ways to change this behaviour. Most straightforward would be probably INDEX hint, but you can also change some index-cost related parameters, check histograms, decrease degree of paralellism on table, create stored outline, etc.
Lukasz

Query to identify full table scans in progress

Does anybody have a query that would help me identify:
1) Full table scans in progress.
2) Long running queries in progress.
Thanks,
Thomas
null

Does anybody have a query that would help me identify:
1) Full table scans in progress.Not sure.
2) Long running queries in progressDon’t have a query readily available, but you can write one based on the following –
Try querying the view V$SESSION_LONGOPS. You will need to join this to V$SQL using SQL_ADDRESS to identify all the SQL’s running for more than ‘x’ minutes.
Current System Time - V$SESSION_LONGOPS.Start_Time should give you the duration.
Shailender Mehta

"db file scattered read" too high and Query going for full table scan-Why ?

Hi,
I had a big table of around 200mb and had a index on it.
In my query I am using the where clause which has to use the
index. I am neither using any not null condition
nor using any function on the index fields.
Still my query is not using the index.
It is going for full table scan.
Also the statspack report is showing the
"db file scattered read" too high.
Can any body help and suggest me why this is happenning.
Also tell me the possible solution for it.
Thanks
Arun Tayal

"db file scattered read" are physical reads/multi block reads. This wait occurs when the session reading data blocks from disk and writing into the memory.
Take the execution plan of the query and see what is wrong and why the index is not being used.
However, FTS are not always bad. By the way, what is your db_block_size and db_file_multiblock_read_count values?
If those values are set to high, Optimizer always favour FTS thinking that reading multiblock is always faster than single reads (index scans).
Dont see oracle not using index, just find out why oracle is not using index. Use the INDEX hint to force optimizer to use index. Take the execution with/witout index and compare the cardinality,cost and of course, logical reads.
Jaffar
Message was edited by:
The Human Fly

Slow query due to large table and full table scan

Hi,
We have a large Oracle database, v 10g. Two of the tables in the database have over one million rows.
We have a few queries which take a lot of time to execute. Not always though, it that seems when load is high the queries tend
to take much longer. Average time may be 1 or 2 seconds, but maxtime can be up to 2 minutes.
We have now used Oracle Grid to help us examine the queries. We have found that some of the queries require two or three full table scans.
Two of the full table scans are of the two large tables mentioned above.
This is an example query:
SELECT table1.column, table2.column, table3.column
FROM table1
JOIN table2 on table1.table2Id = table2.id
LEFT JOIN table3 on table2.table3id = table3.id
WHERE table1.id IN(
SELECT id
FROM (
(SELECT a.*, rownum rnum FROM(
SELECT table1.id
FROM table1,
table2,
table3
WHERE
table1.table2id = table2.id
AND
table2.table3id IS NULL OR table2.table3id = :table3IdParameter
) a
WHERE rownum <= :end))
WHERE rnum >= :start
Table1 and table2 are the large tables in this example. This query starts two full table scans on those tables.
Can we avoid this? We have, what we think are, the correct indexes.
/best regards, Håkan

>
Hi Håkan - welcome to the forum.
We have a large Oracle database, v 10g. Two of the tables in the database have over one million rows.
We have a few queries which take a lot of time to execute. Not always though, it that seems when load is high the queries tend
to take much longer. Average time may be 1 or 2 seconds, but maxtime can be up to 2 minutes.
We have now used Oracle Grid to help us examine the queries. We have found that some of the queries require two or three full table scans.
Two of the full table scans are of the two large tables mentioned above.
This is an example query:Firstly, please read the forum FAQ - top right of page.
Please format your SQL using tags [code /code].
In order to help us to help you.
Please post table structures - relevant (i.e. joined, FK, PK fields only) in the form - note use of code tags - we can just run table create script.
CREATE TABLE table1
Field1 Type1,
Field2 Type2,
FieldN TypeN
);Then give us some table data - not 100's of records - just enough in the form
INSERT INTO Table1 VALUES(Field1, Field2.... FieldN);
..Please post EXPLAIN PLAN - again with tags.
HTH,
Paul...
/best regards, Håkan

Full Table Scans for small tables... in Oracle10g v.2

Hi,
The Query optimizer may select to do a full table scan instead of an index scan when the table is small (it consists of blocks the number of which is less than the the value of db_file_multiblock_read_count).
So , i tried to see it using the dept table......
SQL> select blocks , extents , bytes from USER_segments where segment_name='DEPT';
    BLOCKS    EXTENTS      BYTES
         8          1      65536
SQL> SHOW PARAMETER DB_FILE_MULTIBLOCK_READ_COUNT;
NAME                                 TYPE        VALUE
db_file_multiblock_read_count        integer     16
SQL> explain plan for SELECT * FROM DEPT
2    WHERE DEPTNO=10
3 /
Explained
SQL>
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2852011669
| Id | Operation                   | Name    | Rows | Bytes | Cost (%CPU)| Tim
|   0 | SELECT STATEMENT            |         |     1 |    23 |     1   (0)| 00:
|   1 | TABLE ACCESS BY INDEX ROWID| DEPT    |     1 |    23 |     1   (0)| 00:
|* 2 |   INDEX UNIQUE SCAN         | PK_DEPT |     1 |       |     0   (0)| 00:
Predicate Information (identified by operation id):
   2 - access("DEPTNO"=10)
14 rows selectedSo , according to the above remarks
What may be the reason of not performing full table scan...????
Thanks...
Sim

No i have not generalized.... In the Oracle's extract
i have posted there is the word "might".....
I just want to find an example in which selecting
from a small table... query optimizer does perform a
full scan instead of a type of index scan...Sorry for that... I don't mean to be rude :)
See following...
create table index_test(id int, name varchar2(10));
create index index_test_idx on index_test(id);
insert into index_test values(1, 'name');
commit;
-- No statistics
select * from index_test where id = 1;
SELECT STATEMENT ALL_ROWS-Cost : 3
TABLE ACCESS FULL MAXGAUGE.INDEX_TEST(1) ("ID"=1)
-- If first rows mode?
alter session set optimizer_mode = first_rows;
select * from index_test where id = 1;
SELECT STATEMENT FIRST_ROWS-Cost : 802
TABLE ACCESS BY INDEX ROWID MAXGAUGE.INDEX_TEST(1)
   INDEX RANGE SCAN MAXGAUGE.INDEX_TEST_IDX (ID) ("ID"=1)
-- If statistics is gathered
exec dbms_stats.gather_table_stats(user, 'INDEX_TEST', cascade=>true);
alter session set optimizer_mode = first_rows;
select * from index_test where id = 1;
SELECT STATEMENT ALL_ROWS-Cost : 2
TABLE ACCESS BY INDEX ROWID MAXGAUGE.INDEX_TEST(1)
   INDEX RANGE SCAN MAXGAUGE.INDEX_TEST_IDX (ID) ("ID"=1)
alter session set optimizer_mode = all_rows;
select * from index_test where id = 1;
SELECT STATEMENT ALL_ROWS-Cost : 2
TABLE ACCESS BY INDEX ROWID MAXGAUGE.INDEX_TEST(1)
   INDEX RANGE SCAN MAXGAUGE.INDEX_TEST_IDX (ID) ("ID"=1) See some dramatic changes by the difference of parameters and statistics?
Jonathan Lewis has written a great book on cost mechanism of Oracle optimizer.
It will tell almost everything about your questions...
http://www.amazon.com/Cost-Based-Oracle-Fundamentals-Jonathan-Lewis/dp/1590596366/ref=sr_1_1?ie=UTF8&s=books&qid=1195209336&sr=1-1

URGENT HELP Required: Solution to avoid Full table scan for a PL/SQL query

Hi Everyone,
When I checked the EXPLAIN PLAN for the below SQL query, I saw that Full table scans is going on both the tables TABLE_A and TABLE_B
UPDATE TABLE_A a
SET a.current_commit_date =
(SELECT MAX (b.loading_date)
FROM TABLE_B b
WHERE a.sales_order_id = b.sales_order_id
AND a.sales_order_line_id = b.sales_order_line_id
AND b.confirmed_qty > 0
AND b.data_flag IS NULL
OR b.schedule_line_delivery_date >= '23 NOV 2008')
Though the TABLE_A is a small table having nearly 1 lakh records, the TABLE_B is a huge table, having nearly 2 and a half crore records.
I created an Index on the TABLE_B having all its fields used in the WHERE clause. But, still the explain plan is showing FULL TABLE SCAN only.
When I run the query, it is taking long long time to execute (more than 1 day) and each time I have to kill the session.
Please please help me in optimizing this.
Thanks,
Sudhindra

Check the instruction again, you're leaving out information we need in order to help you, like optimizer information.
- Post your exact database version, that is: the result of select * from v$version;
- Don't use TOAD's execution plan, but use
SQL> explain plan for <your_query>;
SQL> select * from table(dbms_xplan.display);(You can execute that in TOAD as well).
Don't forget you need to use the {noformat}{noformat} tag in order to post formatted code/output/execution plans etc.
It's also explained in the instruction.
When was the last time statistics were gathered for table_a and table_b?
You can find out by issuing the following query:select table_name
, last_analyzed
, num_rows
from user_tables
where table_name in ('TABLE_A', 'TABLE_B');
Can you also post the results of these counts;select count(*)
from table_b
where confirmed_qty > 0;
select count(*)
from table_b
where data_flag is null;
select count(*)
from table_b
where schedule_line_delivery_date >= /* assuming you're using a date, and not a string*/ to_date('23 NOV 2008', 'dd mon yyyy');

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

Why does not a query go by index but FULL TABLE SCAN

I have two tables;
table 1 has 1400 rwos and more than 30 columns , one of them is named as 'site_code' , a index was created on this column;
table 2 has more 150 rows than 20 column , this primary key is 'site_code' also.
the two tables were analysed by dbms_stats.gather_table()...
when I run the explain for the 2 sqls below:
select * from table1 where site_code='XXXXXXXXXX';
select * from table1 where site_code='XXXXXXXXXX';
certainly the oracle explain report show that 'Index scan'
but the problem raised that
I try to explain the sql
select *
from table1,table2
where 1.'site_code'=2.'site_code'
the explain report that :
select .....
FULL Table1 Scan
FULL Table2 Scan
why......

Nikolay Ivankin wrote:
BluShadow wrote:
Nikolay Ivankin wrote:
Try to use hint, but I really doubt it will be faster.No, using hints should only be advised when investigating an issue, not recommended for production code, as it assumes that, as a developer, you know better than the Oracle Optimizer how the data is distributed in the data files, and how the data is going to grow and change over time, and how best to access that data for performance etc.Yes, you are absolutly right. But aren't we performing such an investigation, are we? ;-)The way you wrote it, made it sound that a hint would be the solution, not just something for investigation.
select * from .. always performs full scan, so limit your query.No, select * will not always perform a full scan, that's just selecting all the columns.
A select without a where clause or that has a where clause that has low selectivity will result in full table scans.But this is what I have ment.But not what you said.

Regd: full table scan in sql query

hi friends,
i have one query below.
SELECT wm_concat (d.cp_hrchy_desc) LOCATION
FROM am_tm_chnl_prtnr_hrchy d, am_tl_user_hrchy e
WHERE d.pk_cp_hrchy_id = e.fk_cp_hrchy_id
AND e.fk_ent_mst_customers = 13754
its given me 'Full Table Scan' on table am_tm_chnl_prtnr_hrchy.its just simple query.
want to remove Full Scan.
see below plan of above query.
Plan
SELECT STATEMENT ALL_ROWSCost: 10 Bytes: 18 Cardinality: 1
     4 SORT AGGREGATE Bytes: 18 Cardinality: 1
     3 NESTED LOOPS Cost: 10 Bytes: 1,314 Cardinality: 73
     1 TABLE ACCESS FULL TABLE BTSTARGET.AM_TM_CHNL_PRTNR_HRCHY
Cost: 9 Bytes: 50,831 Cardinality: 4,621
2 INDEX UNIQUE SCAN INDEX (UNIQUE) BTSTARGET.PK_USER_HRCHY_01 Cost: 0 Bytes: 7 Cardinality: 1

Full table scan is not evil. Oracle selects full table scan only when its optimal.
So now tell us how many rows are you selecting from am_tm_chnl_prtnr_hrchy table. Give the percentage of data fetched from this table.
If its high say 90% then a FTS is a good option. Also do you have any index defined on the table am_tm_chnl_prtnr_hrchy. If yes give us the details.
See the below thread they will give you a nice idea of how to post a performance related question.
{thread:id=501834} and {thread:id=863295}.

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.

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

Update doing full table scan and taking long time

Hi All,
I am running an update statement which is doing a full table scan.
UPDATE Database.TABLE AS T
SET COMMENTS = CAST(CAST(COALESCE(T.COMMENTS,0) AS INTEGER) + 1 AS
CHARACTER)
WHERE T.TRACKINGPOINT = 'NDEL'
AND T.REFERENCENUMBER =
SUBSTRING(Root.XML.EE_EAI_MESSAGE.ReferenceNumber || '
' FROM 1 FOR 32);
Any advice.
Regards,
Umair

Mustafa,
No Developer is writing it in his program.
Regards,
Umair

Update Query is Performing Full table Scan of 1 Millions Records

Similar Messages

Maybe you are looking for