How to avoid the full table scan?

Hello

I'm new to sql tuning. When I run the following query. Full table scan that happens and it does not use the index.

SELECT / * + FIRST_ROWS (2) * / a0.t$ ttyp, a0.t$ amnt FROM forest112 WHERE a0.t$ amnt <>: 1 AND a0.t$ dapr =: 2 AND a0.t$ tapr =: 3;

When I searched on the net, I found by changing the operator '<>' with 'NOT IN' we can make the query to use the index, but that will change the result. Is this true? What are the other changes that can be made to this query?

I think that create under index may solve your problem, because in this case, it will not hit the table and get all desired data to index itself

create index ind_1 on forest112 (tapr$ t, t$ WTSA, dapr$ t, t$ ttyp) compute statistics;

Thank you

Harman

Tags: Database

Similar Questions

best way to avoid the full table scan for clause "column is zero.
I have a query with is control null, and because of that it performs a total scan of table (in millions of rows in the table)

SELECT id, x,
LAG (id) OVER (PARTITION BY userid ORDER BY has had place, id) as p_id,.
FROM MyTable
WHERE X is ZERO

What is the best way for me to avoid the full table scan. I have indexes for the X column and other columns.

Thank you
Hi Vasif

NULL values are indexed if the indexed entry also includes a value non-zero.

If you create an index such as:

CREATE INDEX mytable_x_idx ON mytable (x, ' ');

ensure all null values for the column X are indexed and will therefore potentially use the index to search for null values, assuming of course the result set is small enough to justify the use of the index in your query.

I have spoken previously on my blog:

http://richardfoote.WordPress.com/2008/01/23/indexing-nulls-empty-spaces/

See you soon

Richard Foote
http://richardfoote.WordPress.com/

Index on non unique values in order to avoid the full table scan
I have a table with > 100 k records. The table is updated only during the race every night. All columns except one have non - unique values and I am querying the table with this request.

COL3 - non - unique values - only 40 distinct values
unique values - no - COL4 - 1000 distinct values
last_column - 100 k unique values

Select last_column in the table_name where in (...) col3 or col4 (...)

I tried to create a Bitmap index individually on col3 and col4 and also combined. However, in both cases, it performs a full table scan.

Please, help me optimize this query as it is used in the term altogether the system and the cost of the query is very high around 650.

I don't have much experience with popular indexes then all tracks.

Thank you
Sensey

Published by: user13312817 on November 7, 2011 11:32
An alternative might be to use a union instead and the 2 index:

create index my_index1 on my_table (col3, last_column) compress 1;
create index my_index2 on my_table (col4, last_column) compress 1;

Select last_column from my_table
where col3 in (...)
Union
Select last_column from my_table
where col4 (...)

In other words, if the UNION would apply here whereas in double values for last_column will be deleted.

causing trunc of the full Table Scans

I have a situtaion here where my query is this.

SQL > select count (1) in the HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5 = 'HD' and CUST_STATUS in ('UP', "UUP") and trunc (FIRST_ACTVN_DATE) = trunc (sysdate);

COUNT (1)
----------
6

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 3951750498

---------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |
---------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 1. 10. 13904 (1) | 00:02:47 |
| 1. GLOBAL TRI | 1. 10 | | | | |
| 2. SIMPLE LIST OF PARTITION. 1. 10. 13904 (1) | 00:02:47 | 12. 12.
|* 3 | TABLE ACCESS FULL | HBSM_SM_ACCOUNT_INFO | 1. 10. 13904 (1) | 00:02:47 | 12. 12.
---------------------------------------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):
---------------------------------------------------

3 filter (("CUST_STATUS" = "UP" OU "CUST_STATUS" = 'UUP') AND)
TO_DATE (INTERNAL_FUNCTION ("FIRST_ACTVN_DATE")) = TO_DATE (TO_CHAR(SYSDATE@!)))

16 selected lines.

If I remove the trunc clause in the query performance improves significantly the results are false.

SQL > select count (1) in the HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5 = 'HD' and CUST_STATUS in ('UP', "UUP") and FIRST_ACTVN_DATE = trunc (sysdate);

COUNT (1)
----------
0

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 454529511

---------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |
---------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 1. 40. 47 (0) | 00:00:01 |
|* 1 | TABLE ACCESS BY INDEX ROWID | HBSM_SM_ACCOUNT_INFO | 1. 40. 47 (0) | 00:00:01 | 12. 12.
|* 2 | INDEX RANGE SCAN | IND_FIRST_ACTVN_DATE | 51. 4 (0) | 00:00:01 |
---------------------------------------------------------------------------------------------------------------------------

Can anyone please help me by which I can get the right data, and I can also prevent such full table scans.

Unless you use a functional index, apply any function to an indexed column prevents the use of the index.

The way around it in your case is to realize that

select count(1) from HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5='MH' and CUST_STATUS in ('UP','UUP') and trunc(FIRST_ACTVN_DATE) = trunc(sysdate)

Really asking that the FIRST_ACTVN_DATE are sometimes today. You can rewrite so as

select count(1) from HBSM_SM_ACCOUNT_INFO where OPTIONAL_PARM5='MH' and CUST_STATUS in ('UP','UUP')
and FIRST_ACTVN_DATE >= trunc(sysdate)
and FIRST_ACTVN_DATE < trunc(sysdate) + 1

Note that this may not always use the index according to the number of lines are the date of the day compared to how many are outside today's date.

Also, when you post, don't forget to put your code between

 tags and to post create table scripts and sample data inserts.

Full table scan when using Array and struct.
Guys,
Sometimes I use the table to another table in primary key. The problem is that I have to use force index to avoid the full table scan. I don't think it's a good idea. Could someone help me? Code example follows.

CREATE TYPE department_type () AS OBJECT
DNO NUMBER (10),
NAME VARCHAR2 (50).
LOCATION VARCHAR2 (50)
);

CREATE TYPE dept_array AS TABLE OF department_type;

Explain plan for
SELECT *.
OF ORD_HEADER H
where there are
(select 1 from table (dept_array (department_type (3535,-DNO))))
"NAME", NAME
'RENT', - LOCATION
t))) WHERE H.BUID = T.BUID
and H.ORDER_NUM = T.ORDER_NUM);
Select * from table (DBMS_XPLAN.display);
And it's because the Oracle conjecture for the number of rows in the collection is probably out path. In my view, that the optimizer guess that there will be approximately 8000 items in the table. If it is 100 k rows in the table, she believes she's going to have to go back to 8% of the lines, if she opts for the full table scan. If there is 1 M rows in the table, she believes that she will have to return only 0.8% of the lines, so he chooses to use the index. If you provide a hint of CARDINALITY which gives Oracle a better estimate of the number of elements in the array, assuming you have the elements significantly less than 8000 on average, you are much more likely to have access to the index.

There is a wire askTom on [the cardinality hint when you use collections of PL/SQL in SQL | http://asktom.oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:3779680732446 #15740265481549] it is quite worth reading.

Justin

How to improve the only table has full table scan with a lot of data and without PK
Hello world...

I have YOUR table...
CREATE YOUR TABLE
(
EMPLOYEE_NUMBER VARCHAR2 (30 BYTE) NOT NULL,
ATT_DATE DATE NOT NULL,
DATE OF DATE_TIME_IN,
DATE OF DATE_TIME_OUT,
NUMBER OF DELAY_MINUTES
NUMBER OF EARLY_EXIT_MINUTES
STATUS VARCHAR2 (20 BYTE)
)

This table contains a primary key and no clue on this subject. and coontain around 600 000 recoed.

query this table take about 5 mintes with full table scan

Select * from your.

I create indexes on Employee_No and atta_date, although there is a constarin for bith of them is not zero, but they have a duplciate value...

But even thogh the table always do full table scan...

BR
Thanks for the stats...
Well, your statistics on that table are updated.
The volume taken by the table is consistent with the number of lines you have and the average space taken by each activity.

what I propose (this is not a 'query' problem since you decide to read the ENTIRE contents of the table and you are not satisfied with the performance):
-Try this query in parallel (maybe your server will not parallelize it):
```
 select /*+ PARALLEL(x) */ * from ta x
```
- or check what are the events of theses/wait (probably the disk IO rate or the network)

REM: As SY compression could be an option to go in his direction, I repeat:
"change the type data number EMPLOYEE_NUMBER" instead of varchar2 (rebuild the table) in a way you will earn enough space (bytes/line) VS the actual duration of each lines.
Another way to reduce the space and If you insert / select in this table is finally reduce the PCTFREE, but beware the danger of this is that you will lose all the benefit if this table is updated or deleted. (it may not be the case today, but it could be in the future!)

Published by: user11268895 on July 18, 2010 16:15

How do full table scan

Hi all
I have a table which is accesed by application every 5 seconds. Now, this table has several delete insert updates current. The table size is aprox 200 MB (high tide) and there is say 5 ranks, which will be a sentence of 20 to 30 KB. My CMS is say 2 GB. So now the stats are not met and there is no index in this table. Now I see full table scan as his wait event. Now, I want to know.
How a scan full of tabel happens Oracle load the entire 200MB of data in the SGA and then do a table scan or should just the actual size used by the table IE 20 to 30 KB.
Thank you
A

Hello

high waters is precisely the limit up to which Oracle must read to be sure that all the data has been seen, so if you have only about 30 KB of data in the table, even if the data is in the first a few blocks from the table, a complete analysis must read the 200 MB (which is not so good but takes more time to read a few blocks). (the reason is that it was once the data written in this block and it triggered the HWM),

You can reorganize the table (alter table mytable move or use DBMS_REDEFINITION so that you can do this, the application uses the table) to reset the HWM. ("If the current small" size used"is transient and if you expect the table to increase again to use 200 MB or more, don't need to reorg; do it if you are confident that the table will remain very weak)

Best regards

Brno Vroman.

The query makes a full table scan?

I have a simple select query that filters on the last 10 or 11 days of data in a table. In the first case, it runs in 1 second. In the second case it takes 15 minutes and still not done.

I can say that the second query (11 days) makes a full table scan.
-Why is this happening? ... I guess some kind of threshold?
-Are there a way to avoid this? ... or encourage Oracle to play nice.

I find confusing from the point of view before end/query to get very different performances.

Jason
Oracle 10g
Toad quest 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'))

This seems to change the plan to explain it...

alter session set optimizer_index_cost_adj=10;

Full Table Scan: logical reads are the same as the number of blocks

Hi people,
Please see the following execution plan:
Hash value of plan: 1148783227
---------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name                          | Begins | E - lines. A - lines.   A - time | Pads | Bed | OMem | 1Mem | Used Mem.
---------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                               |      1.        |      0 | 00:01:20.23 |     481K |    481K |       |       |          |
|* 1 | HASH JOIN |                               |      1. 50351 |      0 | 00:01:20.23 |     481K |    481K | 7902K | 2074K | 7997K (0) |
|* 2 |   HASH JOIN |                               |      1. 50351 | 31333 | 00:00:01.45 |    3138.   3134 |    17 M | 2295K |   18 M (0).
|* 3 |    TABLE ACCESS FULL | INS_DCT_BUSINESS_FOLDER |      1. 50351 |    122K | 00:00:00.82 |    2262 |   2260 |       |       |          |
|   4.    TABLE ACCESS FULL | INS_DCT_CLAIM_DECEASED_FOLDER |      1. 73533 | 76656 | 00:00:00.34 |     876.    874.       |       |          |
|* 5 |   TABLE ACCESS FULL | INS_COMMON_PARTY |      1.    616K |      0 | 00:01:18.71 |     478K |    478K |       |       |          |
---------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access("THIS_".") PARTY_PK "= 'PARTY1_'." PK")
2 - access("THIS_".") FOLDER_ID '= 'THIS_1_'.' FOLDER_ID")
3 filter (("THIS_1_". "STATUS" <>"10" AND "THIS_1_" "." " STATUS' <>' 07 "AND"THIS_1_". ((' ' STATUS ' <>' 08'))
5 filter (("PARTY1_". "CUSTOMER_ID" LIKE "%#CHAMP290501C #00000 ' AND 'PARTY1_'." CUSTOMER_ID' IS NOT NULL))
The full table on INS_COMMON_PARTY scan generated 478 K physical IO.
But the table contains 479K
SQL > select dba_segments blocks where nom_segment = 'INS_COMMON_PARTY ';
BLOCKS
----------
479488
The 10046 trace file shows that each IO get back most of the time 16 blocks:
WAITING #11529215045786738576: nam = "direct path read" ela = file number 5619 = 27 dba first 1695088 block cnt = 16 obj = #= 19115 tim = 4076488005225
WAITING #11529215045786738576: nam = "direct path read" ela = 33322 file number = 26 dba first 758658 block cnt = 14 obj = #= 19115 tim = 4076488044875
WAITING #11529215045786738576: nam = "direct path read" ela = 2140 file number = 26 dba first 758672 block cnt = 16 obj = #= tim 19115 = 4076488053342
WAITING #11529215045786738576: nam = "direct path read" ela = 205 file number = 26 dba first 758688 block cnt = 16 obj = #= 19115 tim = 4076488054012
WAITING #11529215045786738576: nam = "direct path read" ela = 2057 file number = 26 dba first 758704 block cnt = 16 obj = #= 19115 tim = 4076488056622
WAITING #11529215045786738576: nam = "direct path read" ela = 22034 folder = 26 dba first 758720 block cnt = 16 obj = #= tim 19115 = 4076488079117
WAITING #11529215045786738576: nam = "direct path read" ela = 5516 file number = 26 dba first 758736 block cnt = 16 obj = #= 19115 tim = 4076488085001
WAITING #11529215045786738576: nam = "direct path read" ela = file number 4914 = 26 dba first 758752 block cnt = 16 obj = #= 19115 tim = 4076488090434
WAITING #11529215045786738576: nam = "direct path read" ela = file number 7748 = 26 dba first 758768 block cnt = 16 obj = #= tim 19115 = 4076488098836
WAITING #11529215045786738576: nam = "direct path read" ela = 1046 file number = 9 first dba = 1411 block cnt = 5 obj #= 19076 tim = 4076488101527
WAITING #11529215045786738576: nam = "direct path read" ela = file number 3882 = 9 first dba = 1424 block cnt = 8 obj #= 19076 tim = 4076488105439
WAITING #11529215045786738576: nam = "direct path read" ela = 1736 file number = 9 first dba = 1433 block cnt = 15 obj #= 19076 tim = 4076488107310
WAITING #11529215045786738576: nam = "direct path read" ela = 123 file number = 9 first dba = 1449 block cnt = 15 obj #= 19076 tim = 4076488107616
WAITING #11529215045786738576: nam = "direct path read" ela = 876 of file = 9 first dba = 1465 block cnt = 15 obj #= 19076 tim = 4076488108814
WAITING #11529215045786738576: nam = "direct path read" ela = file number 11326 = 9 first dba = 1481 block cnt = 15 obj #= 19076 tim = 4076488120464
WAITING #11529215045786738576: nam = "direct path read" ela = file number 2497 = 9 first dba = 1497 block cnt = 15 obj #= 19076 tim = 4076488123305
WAITING #11529215045786738576: nam = "direct path read" ela = 1382 file number = 9 first dba = 1513 block cnt = 15 obj #= 19076 tim = 4076488125037
WAITING #11529215045786738576: nam = "direct path read" ela = 799 file = 9 first dba = 1529 block cnt = 7 obj #= 19076 tim = 4076488126162
WAITING #11529215045786738576: nam = "direct path read" ela = 45 file number = 17 dba first = 1920 block cnt = 8 obj #= 19076 tim = 4076488126533
WAITING #11529215045786738576: nam = "direct path read" ela = 2593 file number = 18 dba first 1794 block cnt = 14 obj = #= 19076 tim = 4076488129290
WAITING #11529215045786738576: nam = "direct path read" ela = 1727 file number = 18 dba first = 1808 block cnt = 16 obj #= 19076 tim = 4076488131202
WAITING #11529215045786738576: nam = "direct path read" ela = 7308 file number 18 dba first = 1824 block cnt = 16 obj = #= 19076 tim = 4076488138872
WAITING #11529215045786738576: nam = "direct path read" ela = file number 514 = 18 dba first = 1840 block cnt = 16 obj #= 19076 tim = 4076488139735
WAITING #11529215045786738576: nam = "direct path read" ela = 110 file number = 18 dba first 1856 block cnt = 16 obj = #= 19076 tim = 4076488140232
WAITING #11529215045786738576: nam = "direct path read" ela = 114 file number = 18 dba first = 1872 block cnt = 16 obj #= 19076 tim = 4076488140689
WAITING #11529215045786738576: nam = "direct path read" ela = 114 file number = 18 dba first 1888 block cnt = 16 obj = #= 19076 tim = 4076488141146
WAITING #11529215045786738576: nam = "direct path read" ela = 113 file number = 18 dba first = 1904 block cnt = 16 obj #= 19076 tim = 4076488141603
WAITING #11529215045786738576: nam = "direct path read" ela = 695 of file = 19 dba first 1794 block cnt = 14 obj = #= 19076 tim = 4076488142645
WAITING #11529215045786738576: nam = "direct path read" ela = 549 of file = 19 dba first = 1808 block cnt = 16 obj #= 19076 tim = 4076488143540
WAITING #11529215045786738576: nam = "direct path read" ela = 1742 file number = 19 dba first 1824 block cnt = 16 obj = #= 19076 tim = 4076488145588
WAITING #11529215045786738576: nam = "direct path read" ela = file number 1834 = 19 dba first = 1840 block cnt = 16 obj #= 19076 tim = 4076488147769
................................
WAITING #11529215045786738576: nam = "direct path read" ela = file number 113966 = 19 dba first 52960 block cnt = 16 obj = #= 19076 tim = 4076492053842
WAITING #11529215045786738576: nam = "direct path read" ela = file number 3173 = 19 dba first 52976 block cnt = 16 obj = #= 19076 tim = 4076492057550
WAITING #11529215045786738576: nam = "direct path read" ela = file number 3486 = 19 dba first 52992 block cnt = 16 obj = #= 19076 tim = 4076492061390
WAITING #11529215045786738576: nam = "direct path read" ela = 2288 file number = 19 dba first 53008 block cnt = 16 obj = #= 19076 tim = 4076492064029
WAITING #11529215045786738576: nam = "direct path read" ela = file number 4692 = 19 dba first 53024 block cnt = 16 obj = #= 19076 tim = 4076492069069
WAITING #11529215045786738576: nam = "direct path read" ela = 1239 file number = 19 dba first 53040 block cnt = 16 obj = #= 19076 tim = 4076492070657
WAITING #11529215045786738576: nam = "direct path read" ela = file number 2365 = 19 dba first 53056 block cnt = 16 obj = #= 19076 tim = 4076492073373
WAITING #11529215045786738576: nam = "direct path read" ela = 227 file number = 19 dba first 53072 block cnt = 16 obj = #= 19076 tim = 4076492073970
WAITING #11529215045786738576: nam = "direct path read" ela = 215 file number = 19 dba first 53088 block cnt = 16 obj = #= 19076 tim = 4076492074531
WAITING #11529215045786738576: nam = "direct path read" ela = 204 of file = 19 dba first 53104 block cnt = 16 obj = #= 19076 tim = 4076492075082
WAITING #11529215045786738576: nam = "direct path read" ela = 198 file number = 19 dba first = 53120 block cnt = 16 obj #= 19076 tim = 4076492075626
WAITING #11529215045786738576: nam = "direct path read" ela = 217 file number = 19 dba first 53136 block cnt = 16 obj = #= 19076 tim = 4076492076191
WAITING #11529215045786738576: nam = "direct path read" ela = 216 number of file = 19 dba first 53152 block cnt = 16 obj = #= 19076 tim = 4076492076755
WAITING #11529215045786738576: nam = "direct path read" ela = 1199 file number = 19 dba first 53168 block cnt = 16 obj = #= 19076 tim = 4076492078302
.......................................................
STAT #11529215045786738576 id = 5 cnt = 0 pid = 1 pos = obj 2 = 19076 op ='TABLE ACCESS FULL INS_COMMON_PARTY (cr = 478541 pr = 478534 pw = time 0 = US 98541439 cost = size 141729 = map 132638015 = 616921)'
To me that the number of e/s is about 479488/16 = 29968 e / s
Why is the number of e/s so close to the number of blocks?
Am I missing something here?
Thanks for your help

The column entitled "bed" is the number of blocks read, not the number of read requests.

Concerning

Jonathan Lewis

FULL TABLE SCAN even with the index, but why?
Could someone please explain why I'd get FULL TABLE SCAN explain plan results when joining 2 tables on columns that already have clues about them? For example,.
consider this fictional scenario:

employee table with columns:
employee # (primary key column)
name

address table with columns:
employee # (foreign key to employee.employee #)
subscription_type
address

Select Employee.Name since it is, address.address_type, address.address
where employee.employee # = address.employee #.

This query shows a full table scan in terms of the explain command.
Full scan of the table is not necessarily slow and index access is not necessarily fast.

You will recover, no doubt, most if not all the ranks on both sides. The fastest way to retrieve each row in a table is to do a table scan. Using an index, and a single block of reading for each row in a table is much less effective than to do a table scan.

Justin

Full table scan without sweeping particular column (CLOB data type column)
I want to select the online_bank table. This table with a column of type CLOB data. I want to select all the columns in the table, except the column type of clob data. but oracle full table, including the column analysis server type CLOB data when the query is run. It took a long time to complete the table. Please give me a solution of full table scan without analysis the CLOB data type column. How to avoid the time scanning CLOB data type column... ?
878728 wrote:
I want to select the online_bank table. This table with a column of type CLOB data. I want to select all the columns in the table, except the column type of clob data. but oracle full table, including the column analysis server type CLOB data when the query is run. It took a long time to complete the table. Please give me a solution of full table scan without analysis the CLOB data type column. How to avoid the time scanning CLOB data type column... ?

We do not have your table.
We do not have your data.
Therefore, we have no answer to your apparent mystery.

Queries - full table scan
Hello

If I use the name like '% abc %' I still have full table scan. Is it possible to avoid it?

I read on the full-text index:

CTXCAT for the name fields
context of the clob fields

(1) is that correct or is at - it an easier option?

2) is this correct that these indices should be rebuild when the data changes?

Our database is 10.2.0.4, the above information is 11g docs

Kind regards

Nico

Published by: S11 on May 5, 2011 14:55
Histograms would be useless with a like '% something' value.

Function of material you can complete analysis that a Gigabyte table in 30 seconds then how a problem is a complete analysis for a partial value. How many times is this going to be done.

If the answer is high then you should probably use the Oracle text features.

HTH - Mark D Powell.

Confusion of full Table Scan
Hello experts,

I am on 11g R2 RHEL5, I have a general question here, oracle said complete random for table scan reads are slower sequential reading, as far as my knowledge a sequential read is a monobloc read into the buffer cache, and read a straggling is a multiblock read that can occur for a full restricted index scan or a full table scan. My question is what is a shuffle? and how it is different from the sequential reading? on the technical side... Please put some light on these technical terms, so that I can work on the setting. There is also a warrant RANDOM i/o.
In a very brief way, the scan would be something like, you ask for the first time for employees starting with the name 'Aman' (wasn't there a lot with this name) to access using an index be a better choice (perhaps not a good example of a column containing names in real time. Example is just for the sake of discussion) then asking with the name of 'John '.

Aman...

How to cut the large table into pieces

I'm trying to derive some of generic logic that would be cut into pieces of defined size a large table. The goal is to perform the update into pieces and avoid questions too small restoration. The full table on the update scan is inevitable, given that the update target each row of the table.

The BIGTABLE has 63 million lines. The purpose of the bellow SQL to give ID all 2 million rows. So I use the rownum 'auto line numering field' and run a test to see I could. I expected the piece of fist to have 2 million rows, but in fact, it is not the case:

Here is the +(NOTE I had many problems with quotes, so some ROWID appears without their enclosing quotes or they disappear from current output here) code +:

select rn, mod, frow, rownum from (
    select rowid rn ,  rownum frow, mod(rownum, 2000000) mod  
  from bigtable order by rn) where mod = 0
/

SQL> /

RN                        MOD       FROW     ROWNUM
------------------ ---------- ---------- ----------
AAATCjAA0AAAKAVAAd          0    4000000          1
AAATCjAA0AAAPUEAAv          0   10000000          2
AAATCjAA0AAAbULAAx          0    6000000          3
AAATCjAA0AAAsIeAAC          0   14000000          4
AAATCjAA0AAAzhSAAp          0    8000000          5
AAATCjAA0AABOtGAAa          0   26000000          6
AAATCjAA0AABe24AAE          0   16000000          7
AAATCjAA0AABjVgAAQ          0   30000000          8
AAATCjAA0AABn4LAA3          0   32000000          9
AAATCjAA0AAB3pdAAh          0   20000000         10
AAATCjAA0AAB5dmAAT          0   22000000         11
AAATCjAA0AACrFuAAW          0   36000000         12
AAATCjAA6AAAXpOAAq          0    2000000         13
AAATCjAA6AAA8CZAAO          0   18000000         14
AAATCjAA6AABLAYAAj          0   12000000         15
AAATCjAA6AABlwbAAg          0   52000000         16
AAATCjAA6AACBEoAAM          0   38000000         17
AAATCjAA6AACCYGAA1          0   24000000         18
AAATCjAA6AACKfBABI          0   28000000         19
AAATCjAA6AACe0cAAS          0   34000000         20
AAATCjAA6AAFmytAAf          0   62000000         21
AAATCjAA6AAFp+bAA6          0   60000000         22
AAATCjAA6AAF6RAAAQ          0   44000000         23
AAATCjAA6AAHJjDAAV          0   40000000         24
AAATCjAA6AAIR+jAAL          0   42000000         25
AAATCjAA6AAKomNAAE          0   48000000         26
AAATCjAA6AALdcMAA3          0   46000000         27
AAATCjAA9AAACuuAAl          0   50000000         28
AAATCjAA9AABgD6AAD          0   54000000         29
AAATCjAA9AADiA2AAC          0   56000000         30
AAATCjAA9AAEQMPAAT          0   58000000         31

31 rows selected.

SQL> select count(*) from BIGTABLE where rowid < AAATCjAA0AAAKAVAAd ;

  COUNT(*)
----------
    518712             <-- expected around 2 000 000

SQL> select count(*) from BIGTABLE where rowid < AAATCjAA0AAAPUEAAv ;

  COUNT(*)
----------
   1218270     <-- expected around 4 000 000

SQL> select count(*) from BIGTABLE where rowid < AAATCjAA0AAAbULAAx ;

  COUNT(*)
----------
   2685289    <-- expected around 6 000 000

Amzingly, this code works perfectly for small tables, but fails for large tables. Does anyone has an explanation and possibly a solution to this?

Here's the complete SQL code that is suppposed to generate all the predicates, I need to add update statements in order to cut into pieces:

select line  from (
   with v as (select rn, mod, rownum frank from (
       select rowid rn ,  mod(rownum, 2000000) mod
           from BIGTABLE order by rn ) where mod = 0),
      v1 as (
              select rn , frank, lag(rn) over (order by frank) lag_rn  from v ),
      v0 as (
              select count(*) cpt from v)
    select 1, case
                when frank = 1 then ' and rowid  <  ''' ||  rn  || ''''
                when frank = cpt then ' and rowid >= ''' || lag_rn ||''' and rowid < ''' ||rn || ''''
                else ' and rowid >= ''' || lag_rn ||''' and rowid <'''||rn||''''
             end line
from v1, v0
union
select 2, case
           when frank =  cpt then   ' and rowid >= ''' || rn  || ''''
          end line
    from v1, v0 order by 1)
/

 and rowid  <  AAATCjAA0AAAKAVAAd
 and rowid >= 'AAATCjAA0AAAKAVAAd' and rowid < 'AAATCjAA0AAAPUEAAv''
 and rowid >= 'AAATCjAA0AAAPUEAAv' and rowid < 'AAATCjAA0AAAbULAAx''
 and rowid >= 'AAATCjAA0AAAbULAAx' and rowid < 'AAATCjAA0AAAsIeAAC''
 and rowid >= 'AAATCjAA0AAAsIeAAC' and rowid < 'AAATCjAA0AAAzhSAAp''
 and rowid >= 'AAATCjAA0AAAzhSAAp' and rowid < 'AAATCjAA0AABOtGAAa''
 and rowid >= 'AAATCjAA0AAB3pdAAh' and rowid < 'AAATCjAA0AAB5dmAAT''
 and rowid >= 'AAATCjAA0AAB5dmAAT' and rowid < 'AAATCjAA0AACrFuAAW''
 and rowid >= 'AAATCjAA0AABOtGAAa' and rowid < 'AAATCjAA0AABe24AAE''
 and rowid >= 'AAATCjAA0AABe24AAE' and rowid < 'AAATCjAA0AABjVgAAQ''
 and rowid >= 'AAATCjAA0AABjVgAAQ' and rowid < 'AAATCjAA0AABn4LAA3''
 and rowid >= 'AAATCjAA0AABn4LAA3' and rowid < 'AAATCjAA0AAB3pdAAh''
 and rowid >= 'AAATCjAA0AACrFuAAW' and rowid < 'AAATCjAA6AAAXpOAAq''
 and rowid >= 'AAATCjAA6AAA8CZAAO' and rowid < 'AAATCjAA6AABLAYAAj''
 and rowid >= 'AAATCjAA6AAAXpOAAq' and rowid < 'AAATCjAA6AAA8CZAAO''
 and rowid >= 'AAATCjAA6AABLAYAAj' and rowid < 'AAATCjAA6AABlwbAAg''
 and rowid >= 'AAATCjAA6AABlwbAAg' and rowid < 'AAATCjAA6AACBEoAAM''
 and rowid >= 'AAATCjAA6AACBEoAAM' and rowid < 'AAATCjAA6AACCYGAA1''
 and rowid >= 'AAATCjAA6AACCYGAA1' and rowid < 'AAATCjAA6AACKfBABI''
 and rowid >= 'AAATCjAA6AACKfBABI' and rowid < 'AAATCjAA6AACe0cAAS''
 and rowid >= 'AAATCjAA6AACe0cAAS' and rowid < 'AAATCjAA6AAFmytAAf''
 and rowid >= 'AAATCjAA6AAF6RAAAQ' and rowid < 'AAATCjAA6AAHJjDAAV''
 and rowid >= 'AAATCjAA6AAFmytAAf' and rowid < 'AAATCjAA6AAFp+bAA6''
 and rowid >= 'AAATCjAA6AAFp+bAA6' and rowid < 'AAATCjAA6AAF6RAAAQ''
 and rowid >= 'AAATCjAA6AAHJjDAAV' and rowid < 'AAATCjAA6AAIR+jAAL''
 and rowid >= 'AAATCjAA6AAIR+jAAL' and rowid < 'AAATCjAA6AAKomNAAE''
 and rowid >= 'AAATCjAA6AAKomNAAE' and rowid < 'AAATCjAA6AALdcMAA3''
 and rowid >= 'AAATCjAA6AALdcMAA3' and rowid < 'AAATCjAA9AAACuuAAl''
 and rowid >= 'AAATCjAA9AAACuuAAl' and rowid < 'AAATCjAA9AABgD6AAD''
 and rowid >= 'AAATCjAA9AABgD6AAD' and rowid < 'AAATCjAA9AADiA2AAC''
 and rowid >= 'AAATCjAA9AADiA2AAC' and rowid < 'AAATCjAA9AAEQMPAAT''
 and rowid >= 'AAATCjAA9AAEQMPAAT''

33 rows selected.

SQL> select count(*) from BIGTABLE where  1=1 and rowid  <  AAATCjAA0AAAKAVAAd ;

  COUNT(*)
----------
    518712

SQL> select count(*) from BIGTABLE where  1=1 and rowid  >= 'AAATCjAA9AAEQMPAAT'' ;

  COUNT(*)
----------
   1846369

Nice but not accurate...

The problem is that your query implies that ROWID, and ROWNUM are classified in the same way. For small tables it is very often the case, but not for the larger tables. Oracle does not guarantee return records in the order the rowid. However usually it works this way.

You could test ensuring that get you the rownum after you ordered. And see if it works then.

select rn, mod, frow, rownum
from (select rn, rownum frow, mod(rownum, 2000000) mod
        from  (select rowid rn from bigtable order by rn)
        order by rn
        )
where mod = 0
/

Path to XML index table is full table scan

Hi all
I have a version of oracle 11.2.0.4.6 database
Try to implement partitioning on XML indexes.
Creates a table and index partitioned by time stamp as below.
Whenever I'm trying to find the path table makes a full table scan.
I have applied the fix as indicated ( Doc ID 13522189.8 ).
So the recovery is quite slow and partition pruning does not not on XML indexes.
Wondering if anyone has experienced the same problem?
CREATE TABLE INCIDENT
(
INCIDENT_PK NUMBER (14.5).
INCIDENTGROUPING_PK NUMBER (14.5).
INCIDENTTYPE_PK NUMBER (14.5).
SECURITYCLASS_PK NUMBER (14.5).
STAMP OF INCIDENT_DATE,
SYS INCIDENT_DETAIL. XMLTYPE
)
TABLESPACE DATA_TBS_INCIDENT
PCTUSED 0
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE)
64K INITIALS
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
DEFAULT USER_TABLES
)
LOGGING
NOCOMPRESS
PARTITION BY RANGE (INCIDENT_DATE)
(PARTITION SEP2013_WEEK1 VALUES LESS THAN (to_timestamp (' 00:00:00.00 2013-09-08 ',' YYYY-MM-DD HH24:MI:SS.))) FF2')),
PARTITION SEP2013_WEEK2 VALUES LESS THAN (to_timestamp ('2013-09-15 00:00:00.00 ',' YYYY-MM-DD HH24:MI:SS.)) FF2')),
PARTITION SEP2013_WEEK3 VALUES LESS THAN (to_timestamp ('2013-09-22 00:00:00.00 ',' YYYY-MM-DD HH24:MI:SS.)) FF2')),
..........);
CREATE the INDEX INCIDENTxdb_idx
ON corpaudlive. INCIDENT (INCIDENT_detail) INDEXTYPE IS XDB. LOCAL XMLINDEX 10 PARALLEL
PARAMETERS (' PATH TABLE INCIDENT_PATHTABLE (TABLESPACE DATA_TBS_INCIDENT))
PIKEY INDEX INCIDENT_PATHTABLE_PIKEY_IX (TABLESPACE IDX_TBS_INCIDENT)
PATH ID INDEX INCIDENT_PATHTABLE_ID_IX (TABLESPACE IDX_TBS_INCIDENT)
INCIDENT_PATHTABLE_VALUE_IX VALUE INDEX (TABLESPACE IDX_TBS_INCIDENT)
ORDER KEY INDEX INCIDENT_PATHTABLE_KEY_IX (TABLESPACE IDX_TBS_INCIDENT)
Paths (INCLUDE (//forename //surname //postcode //dateofbirth //street //town))');
SQL > explain the plan for
2 Select INCIDENT_pk in INCIDENT where XMLEXISTS ('/ / name [text () = 'john']' by the way of INCIDENT_detail)
3 and XMLEXISTS ("/ / name [text () 'clark' =]' by the way of INCIDENT_detail")
4 and a.INCIDENT_date between TO_TIMESTAMP (January 10, 2014 ',' DD/MM/YYYY "")
5 and TO_TIMESTAMP (September 10, 2014 ',' DD/MM/YYYY ');
He explained.
Elapsed time: 00:00:02.77
SQL > select * from table (dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 123057549
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation                                       | Name                           | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |    TQ | IN-OUT | PQ Distrib.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                                |     1.    70. 1803 (5) | 00:00:22 |       |       |        |      |            |
|   1. COORDINATOR OF PX |                                |       |       |            |          |       |       |        |      |            |
|   2.   PX SEND QC (RANDOM). : TQ10003 |     1.    70. 1803 (5) | 00:00:22 |       |       | Q1, 03 | P > S | QC (RAND) |
|   3.    SEMI NESTED LOOPS.                                |     1.    70. 1803 (5) | 00:00:22 |       |       | Q1, 03 | SVCP |            |
|   4.     NESTED LOOPS |                                |     1.    57. 1800 (5) | 00:00:22 |       |       | Q1, 03 | SVCP |            |
|   5.      VIEW                                       | VW_SQ_1                        |   239. 5975 | 1773 (5) | 00:00:22 |       |       | Q1, 03 | SVCP |            |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   6.       UNIQUE HASH |                                |   239. 25334 |            |          |       |       | Q1, 03 | SVCP |            |
|   7.        RECEIVE PX |                                |   239. 25334 |            |          |       |       | Q1, 03 | SVCP |            |
|   8.         PX SEND HASH | : TQ10002 |   239. 25334 |            |          |       |       | Q1, 02 | P > P | HASH |
|   9.          UNIQUE HASH |                                |   239. 25334 |            |          |       |       | Q1, 02 | SVCP |            |
| * 10 |           HASH JOIN |                                |   239. 25334 | 1773 (5) | 00:00:22 |       |       | Q1, 02 | SVCP |            |
| 11.            KIND OF BUFFER.                                |       |       |            |          |       |       | Q1, 02 | ISSUE |            |
| 12.             RECEIVE PX |                                |     1.    22.     3 (0) | 00:00:01 |       |       | Q1, 02 | SVCP |            |
| 13.              PX SEND BROADCAST | : TQ10000 |     1.    22.     3 (0) | 00:00:01 |       |       |        | S > P | BROADCAST |
| 14.               TABLE ACCESS BY INDEX ROWID | X$ PT74MSS0WBH028JE0GUCLBK0LHM4 |     1.    22.     3 (0) | 00:00:01 |       |       |        |      |            |
| * 15 |                INDEX RANGE SCAN | X$ PR74MSS0WBH028JE0GUCLBK0LHM4 |     1.       |     2 (0) | 00:00:01 |       |       |        |      |            |
| * 16.            HASH JOIN |                                | 12077 |   990K | 1770 (5) | 00:00:22 |       |       | Q1, 02 | SVCP |            |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 17.             RECEIVE PX |                                |   250K |    10 M |    39 (0) | 00:00:01 |       |       | Q1, 02 | SVCP |            |
| 18.              PX SEND BROADCAST | : TQ10001 |   250K |    10 M |    39 (0) | 00:00:01 |       |       | Q1, 01 | P > P | BROADCAST |
| 19.               SYSTEM PARTITION ALL |                                |   250K |    10 M |    39 (0) | 00:00:01 |     1.   112. Q1, 01 | ISSUE |            |
| * 20.                TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE |   250K |    10 M |    39 (0) | 00:00:01 |     1.   112. Q1, 01 | SVCP |            |
| * 21.                 INDEX RANGE SCAN | INCIDENT_PATHTABLE_VALUE_IX |   161.       |    25 (0) | 00:00:01 |     1.   112. Q1, 01 | SVCP |            |
| 22.             ITERATOR BLOCK PX |                                |   221 M | 8865M | 1671 (1) | 00:00:21 |    53.    54. Q1, 02 | ISSUE |            |
| * 23.              TABLE ACCESS FULL | INCIDENT_PATHTABLE |   221 M | 8865M | 1671 (1) | 00:00:21 |    53.    54. Q1, 02 | SVCP |            |
| * 24.      TABLE ACCESS BY ROWID USER | INCIDENT |     1.    32.     1 (0) | 00:00:01 | ROWID | ROWID | Q1, 03 | SVCP |            |
| * 25.     SEE PUSHED PREDICATE. VW_SQ_2                        |     1.    13.    20 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
| 26.      NESTED LOOPS |                                |     1.   106.    20 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
| 27.       NESTED LOOPS |                                |     4.   106.    20 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 28.        NESTED LOOPS |                                |     4.   256.     8 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
| 29.         TABLE ACCESS BY INDEX ROWID | X$ PT74MSS0WBH028JE0GUCLBK0LHM4 |     1.    22.     3 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
| * 30 |          INDEX RANGE SCAN | X$ PR74MSS0WBH028JE0GUCLBK0LHM4 |     1.       |     2 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
| 31.         ITERATOR SYSTEM PARTITION.                                |     4.   168.     5 (0) | 00:00:01 |    53.    54. Q1, 03 | SVCP |            |
| * 32 |          TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE |     4.   168.     5 (0) | 00:00:01 |    53.    54. Q1, 03 | SVCP |            |
| * 33 |           INDEX RANGE SCAN | INCIDENT_PATHTABLE_PIKEY_IX |     4.       |     4 (0) | 00:00:01 |    53.    54. Q1, 03 | SVCP |            |
| 34.        ITERATOR SYSTEM PARTITION.                                |     1.       |     2 (0) | 00:00:01 |   KEY |   KEY | Q1, 03 | SVCP |            |
| * 35 |         INDEX RANGE SCAN | INCIDENT_PATHTABLE_KEY_IX |     1.       |     2 (0) | 00:00:01 |   KEY |   KEY | Q1, 03 | SVCP |            |
| * 36 |       TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE |     1.    42.     3 (0) | 00:00:01 |     1.     1. Q1, 03 | SVCP |            |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
10 - access("SYS_P9".") PATHID '=' ID')
Access (SYS_PATH_REVERSE ("PATH") 15 - > = HEXTORAW ('02582E') AND SYS_PATH_REVERSE ("PATH") < HEXTORAW ('02582EFF'))
16 - access("SYS_P11".") RID "IS 'SYS_P9'." GET RID OF"AND TBL$ OR$ IDX$ PART$ NUM ("CORPAUDLIVE". "THE INCIDENT", 0,7,65535, "SYS_P9" "." " "RID") = TBL$ OR$ IDX$ PART$ NUM ("CORPAUDLIVE". "INCIDENT_PATHTAB
THE', 0,7,65535, ROWID))
filter ("SYS_P9". "ORDER_KEY" < = 'SYS_P11' "." " ORDER_KEY' AND 'SYS_P11 '. "" ORDER_KEY "< SYS_ORDERKEY_MAXCHILD ("SYS_P9". "ORDER_KEY")) "
20 filter (SYS_XMLI_LOC_ISTEXT ("SYS_P11". "LOCATOR", "SYS_P11" "." " PATHID') = 1)
21 - access("SYS_P11".") The VALUE "= 'John')
23 filter (SYS_XMLI_LOC_ISNODE ("SYS_P9". "LOCATOR") = 1 AND SYS_OP_BLOOM_FILTER (: BF0000, "SYS_P9".) " PATHID'))
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
24 - filter("A".") INCIDENT_DATE' > = TIMESTAMP' 2014 - 10 - 01 00:00:00.000000000 "AND"A"". "" INCIDENT_DATE"< = TIMESTAMP' 2014 - 10 - 09 00:00:00.000000000' AND
"ITEM_2" = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT", 0,7,65535, "A". ROWID))
25 filter ("ITEM_4" = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT", 0,7,65535, "A".) ROWID))
30 - access (SYS_PATH_REVERSE ("PATH") > = HEXTORAW('027FF9') AND SYS_PATH_REVERSE ("PATH") < HEXTORAW ('027FF9FF'))
32 filter (SYS_XMLI_LOC_ISNODE ("SYS_P2". "LOCATOR") = 1) "
33 - access("SYS_P2".") GET RID OF"="A ". ROWID AND 'SYS_P2 '. ("' PATHID '=' ID ')
35 - access("SYS_P4".") GET RID OF"="A ". ROWID AND 'SYS_P2 '. "" ORDER_KEY "< ="SYS_P4. " "" ORDER_KEY "AND"SYS_P4 ". "" ORDER_KEY "< SYS_ORDERKEY_MAXCHILD ("SYS_P2". "ORDER_KEY")) "
filter ("SYS_P4". "RID"IS "SYS_P2"." GET RID OF"AND TBL$ OR$ IDX$ PART$ NUM("INCIDENT",0,7,65535,"SYS_P2".") "RID") = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT_PATHTABL
E «(, 0,7,65535, ROWID)).
36 - filter("SYS_P4".") The VALUE '= 'clark' AND SYS_XMLI_LOC_ISTEXT ("SYS_P4".' LOCATOR', 'SYS_P4 '. (("" PATHID ') = 1).
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Note
-----
-dynamic sample used for this survey (level = 6)
69 selected lines.
Elapsed time: 00:00:00.47
SQL > spool off
Thank you
CenterB

You must create a XMLIndex with two groups:

create table actionnew)

number of action_pk

action_date timestamp

action_detail xmltype

)

partition by (range (action_date)

partition values before_2015 less (timestamp ' 2015-01-01 00:00:00 ')

, partition values jan_2015 less (timestamp ' 2015-02-01 00:00:00 ')

, partition values feb_2015 less (timestamp ' 2015-03-01 00:00:00 ')

);

create index actionnew_sxi on actionnew (action_detail)

indexType is xdb.xmlindex

local

parameters (q'~)

Group my_group_1

XMLTable actionnew_xt1

"/ audit/action_details/screen_data/tables/table/row.

path of varchar2 (100) the columns "name".

, path of surname varchar2 (100) "first name".

Group my_group_2

XMLTable actionnew_xt2

"/ audit/action_details/fields.

path of varchar2 (100) the columns "name".

, path of surname varchar2 (100) "first name".

~'

);

Select x.*

to actionnew t

xmltable)

"/ audit/action_details/screen_data/tables/table/row.

in passing t.action_detail

path of varchar2 (100) the columns "name".

, path of surname varchar2 (100) "first name".

) x

where t.action_date between timestamp ' 2015-02-01 00:00:00 '

and timestamp ' 2015-03-01 00:00:00 '

and x.forename = 'anwardo. '

and x.surname = 'gram '.

;

How to avoid the full table scan?

Similar Questions

Maybe you are looking for