High Waits on 'Db File Sequential Read' Due to Table Lookup Following Index Access (文档 ID 875472.1)
2013-12-02 09:16
846 查看
In this Document
Oracle Server - Enterprise Edition - Version 8.0.3.0 to 11.2.0.2 [Release 8.0.3 to 11.2]
Information in this document applies to any platform.
A query can wait on 'db file sequential read' for a long time even if the execution plan appears to be optimal.
This usually happens when the result set of index scan is large.
For example:
In most cases like this, the execution of the query waits on "TABLE ACCESS BY INDEX ROWID" much longer than on INDEX SCAN. It is because the random access to the table rows is much more expensive than index scan.
[align=left] [/align]
You can try one or more of the following.
1. Check if there is a better index or plan. You may need to re-design index configuration.
2. Try table full scan. Full scan often runs faster than Index scan, though its CBO cost is higher than the cost of Index scan.
3. Create a concatenated index to avoid the table access if the query has only a few columns of the table in SELECT and WHERE clauses.
For example:
NOTE : This can only be applied to SELECT for the table. If the query updates the table, this will not help.
4. Move the table into the tablespace with a larger block size. A larger block has more rows in it, so it may help to reduce block I/O.
And it will also be helpful to reorganize the table so that the index may have a smaller clustering factor.
5. Consider increasing buffer cache so that more table blocks can be cached. It is a good idea to use keep buffer pool if the table is frequently accessed.
Note 76374.1 Multiple Buffer Pools
6. Consider using IOT(Index Organized Table). IOT may reduce I/O because it stores data in a B*Tree index structure.
For example, if the column 'A' is the primiary key of BIG_TABLE, you can try to create IOT as follows.
create table BIG_TABLE (A number primary key, B char(2), C number, D varchar2(10))
organization index;
7. Consider using parallel execution if there is sufficient free resource(CPU, memory) in the server.
This option does not reduce I/O. But, this may help to reduce execution time.
8. Bad disk I/O can be a reason. In this case, improve the I/O of devices where the table resides. This requires help from a system administrator.
NOTE:34559.1 - WAITEVENT: "db file sequential read" Reference Note
NOTE:76374.1 - Multiple Buffer Pools
Oracle
Database Products > Oracle
Database > Oracle
Database > Oracle
Database - Enterprise Edition > RDBMS
DB
FILE SEQUENTIAL READ
Symptoms |
Cause |
Solution |
References |
APPLIES TO:
Oracle Server - Enterprise Edition - Version 8.0.3.0 to 11.2.0.2 [Release 8.0.3 to 11.2]Information in this document applies to any platform.
SYMPTOMS
A query can wait on 'db file sequential read' for a long time even if the execution plan appears to be optimal. This usually happens when the result set of index scan is large.
For example:
SELECT D FROM BIG_TABLE WHERE A = 1253 AND B in ('CA', 'CO') AND C > 210 ; Rows Row Source Operation ------- --------------------------------------------------- 215431 TABLE ACCESS BY INDEX ROWID BIG_TABLE (cr=880191 pr=430780 pw=0 time=2293667056 us) <<< 3582275 INDEX RANGE SCAN BIG_TABLE_IDX (cr=664748 pr=218595 pw=0 time=352506821 us) Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 14363 0.00 0.02 db file sequential read 461688 1.15 2254.55 <<< SQL*Net message from client 14363 0.01 9.77 SQL*Net break/reset to client 1 0.00 0.00 ...
CAUSE
In most cases like this, the execution of the query waits on "TABLE ACCESS BY INDEX ROWID" much longer than on INDEX SCAN. It is because the random access to the table rows is much more expensive than index scan.[align=left] [/align]
SOLUTION
You can try one or more of the following.1. Check if there is a better index or plan. You may need to re-design index configuration.
2. Try table full scan. Full scan often runs faster than Index scan, though its CBO cost is higher than the cost of Index scan.
SELECT /*+ FULL(BIG_TABLE) */ D FROM BIG_TABLE WHERE A = 1253 AND B in ('CA', 'CO') AND C > 210 ;
3. Create a concatenated index to avoid the table access if the query has only a few columns of the table in SELECT and WHERE clauses.
For example:
CREATE INDEX <INDEX_NAME> ON BIG_TABLE (A, B, C, D);
NOTE : This can only be applied to SELECT for the table. If the query updates the table, this will not help.
4. Move the table into the tablespace with a larger block size. A larger block has more rows in it, so it may help to reduce block I/O.
And it will also be helpful to reorganize the table so that the index may have a smaller clustering factor.
5. Consider increasing buffer cache so that more table blocks can be cached. It is a good idea to use keep buffer pool if the table is frequently accessed.
Note 76374.1 Multiple Buffer Pools
6. Consider using IOT(Index Organized Table). IOT may reduce I/O because it stores data in a B*Tree index structure.
For example, if the column 'A' is the primiary key of BIG_TABLE, you can try to create IOT as follows.
create table BIG_TABLE (A number primary key, B char(2), C number, D varchar2(10))
organization index;
7. Consider using parallel execution if there is sufficient free resource(CPU, memory) in the server.
This option does not reduce I/O. But, this may help to reduce execution time.
8. Bad disk I/O can be a reason. In this case, improve the I/O of devices where the table resides. This requires help from a system administrator.
REFERENCES
NOTE:34559.1 - WAITEVENT: "db file sequential read" Reference NoteNOTE:76374.1 - Multiple Buffer Pools
|
|
Database Products > Oracle
Database > Oracle
Database > Oracle
Database - Enterprise Edition > RDBMS
|
DB
FILE SEQUENTIAL READ
相关文章推荐
- High Waits on 'Db File Sequential Read' Due to Table Lookup Following Index Access
- How To Reclaim Wasted Space on The Segment (Table, Index and LOB) and Tablespace Levels (文档 ID 16827
- How To Reclaim Wasted Space on The Segment (Table, Index and LOB) and Tablespace Levels (文档 ID 16827
- ORA-39181:Only Partial Table Data Exported Due To Fine Grain Access Control [ID 422480.1]
- ORA-39181: Only partial table data may be exported due to fine grain access control on "OE"."PURCHAS
- Oracle waits event:DB File Sequential Read
- ORA-39181: Only partial table data may be exported due to fine grain access control on "OE"."PURCHAS
- How To Mirror Controlfile To FRA On ASM (文档 ID 1305674.1)
- about FTS(Full Table Scan) V db file scattered read&db file sequential read
- Db file sequential read while doing full table scan?
- How to Determine the Blocking Session for Event: 'cursor: pin S wait on X' (文档 ID 786507.1)
- High 'cursor: pin S wait on X' . Cause: Shared Pool/Buffer Cache Resize Activity (文档 ID 742599.1)
- The system cannot log you on due to the following error:access is denied
- ORA-00604 ORA-00376 Unable to Drop a tablespace in GoldenGate (文档 ID 1930964.1)
- MySQL坏表?异常:Incorrect key file for table './xx_db/xx_table.MYI'; try to repair it
- How To Make A DFF Read Only Through Form Personalisations? (文档 ID 1289789.1)
- Cannot read configuration file due to insufficient permissions
- 表上索引过多,引发db file sequential read 等待事件
- How to Check Device UUID or File System UUID. (文档 ID 1505398.1)