Oracle等待事件db file parallel read

时间：2023-01-28 07:52:28
SQL> select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = 'db file parallel read';  

    EVENT# NAME                           PARAMETER1      PARAMETER2      PARAMETER3  
---------- ------------------------------ --------------- --------------- ---------------  
       120 db file parallel read          files           blocks          requests

1. db file parallel read

Contrary to what the name suggests, the db file parallel read event is not related to any parallel 
operation—neither parallel DML nor parallel query. This event occurs during the database recovery 
operation when database blocks that need changes as a part of recovery are read in parallel from the 
datafiles. This event also occurs when a process reads multiple noncontiguous single blocks from 
one or more datafiles.

 
Wait Parameters 
Wait parameters for db file parallel read are described here: 
l P1 Number of files to read from 
l P2 Total number of blocks to read 
l P3 Total number of I/O requests (the same as P2 since multiblock read is not used) 

Wait Time 
No timeouts. The session waits until all of the I/Os are completed.  

案例

http://www.itpub.net/thread-1586802-1-1.html

虽然执行计划正确,但是由于index的聚合因子过高,导致prefetch功能大量预读取数据.

一个语句执行计划没有问题，单独提取出来执行只要0.8秒。但是放到存储过程中就很慢 需要10秒左右甚至更多。

Execution Plan

Id Operation Name Rows Bytes Cost (%CPU) Time
0 SELECT STATEMENT       1839 (100)  
1    SORT AGGREGATE   1 37    
2      FILTER          
3        TABLE ACCESS BY INDEX ROWID V_RPT_PLYEDR_INSRNC 1 37 1839 (1) 00:00:23
4          INDEX RANGE SCAN ACIF_INDEX_001 2147   18 (0) 00:00:01

 

但是带入数据单独这个语句执行计划一样的情况下，只要1秒左右。应该不是绑定变量导致的执行计划问题，因为可以看到执行计划是最优的，我查看了等待事件
       491 db file parallel read                                                   2041
       491 db file sequential read                                                 526
       491 db file scattered read                                                   23 

SQL> select distinct(file_id) from dba_extents where segment_name='V_RPT_PLYEDR_INSRNC'; 
FILE_ID
----------
        25
        22
  
SQL> select name from v$datafile  where file# in ('22','25');

NAME
--------------------------------------------------------------------------------
/repdata/ora9i/CIRCI.dbf
/repdata/ora9i/circi01.dbf

Top 5 Timed Events

Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
db file parallel read

351,880

2,891

8

68.3

 User I/O
db file sequential read

463,984

1,216

3

28.7

 User I/O
CPU time   184

 

   4.4

 

  
log file parallel write

1,346

3

2

.1

 System I/O
db file parallel write

512

3

6

.1

 System I/O


File IO Stats

  • ordered by Tablespace, File
Tablespace Filename Reads Av Reads/s Av Rd(ms) Av Blks/Rd Writes Av Writes/s Buffer Waits Av Buf Wt(ms)
CIRCI /repdata/ora9i/CIRCI.dbf

2,847,514

787

12.59

1.02

1,258

0

3

20.00
CIRCI /repdata/ora9i/circi01.dbf

915,158

253

8.63

1.00

13

0

0

0.00
REPORT /repdata/ora9i/REPORT01.dbf

257,679

71

0.75

15.15

0

0

186,811

0.45
REPORT /repdata/ora9i/REPORT02.dbf

255,701

71

0.71

15.21

0

0

187,164

0.43
REPORT /repdata/ora9i/REPORT03.dbf

135,105

37

0.72

15.35

0

0

125,856

0.39

 

Av Rd(ms) 过大 排除 整列本生有问题，是否和 集群因子过大导致通过ROWID寻找TABLE ROWS时跳跃过大有关？

 

结果显示集群因子相当的大，表中一共3000多W调数据 集群因子达到2600W，但是索引的DISTINCT值确只有846，表只是批量的进行INSERT

所以是否可以考虑如下的方法

1、建立BITMAP索引代替以前爱的B-TREE索引

2、或者建立一个大的联合索引，让查询直接走INDEX FAST FULL SCAN。

3、同时建立一个新的表空间来存放索引，做好把TABLE也MOVE到新建的表空间中。

 

我已经建立了联合索引。效果灰常好。已经不通过TABLE ACCESS BY INDEX ROWID 了。只扫描索引就好了。

新的Execution Plan 如下:

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2161530321
----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |     1 |    37 |   156   (1)| 00:00:02 |
|   1 |  SORT AGGREGATE   |        |     1 |    37 |            |          |
|*  2 |   INDEX RANGE SCAN| TEST01 |     2 |    74 |   156   (1)| 00:00:02 |

原理：

高聚簇因子 index range scan -----> 引发灰常多的 rowid 回表扫描离散的block ------>buffer prefetching(11G) ------------> db file parallel read...

当 db 出现过多的 db file parallel read 优化SQL 去吧。

 

案列二:

http://yangtingkun.net/?p=695  消除11.2上的db file parallel read

客户在11.2.0.3环境中进行压力测试，发现出现大量的db file parallel read等待事件。
这个等待是11g以后才出现的，而在11g以前，一般这个等待事件发生在数据文件的恢复过程中。而11g新增了prefetch的特性，也可能导致这个等待事件的产生。
当运行压力测试时，后台的等待事件如下：

SQL> SELECT event, COUNT(*) FROM v$session WHERE username = USER GROUP BY event ORDER BY 2;
EVENT                                                              COUNT(*)
---------------------------------------------------------------- ----------
SQL*Net message FROM client                                               1
SQL*Net message TO client                                                 1
db file sequential READ                                                  24
db file scattered READ                                                   33
db file parallel READ                                                    42

可以看到用户进程经历比较严重的IO等待，而此时的db file parallel read，并不会带来性能提升。
可以通过添加隐含参数的方法来屏蔽prefetch功能，从而避免db file parallel read等待事件的产生：

_db_block_prefetch_limit=0
_db_block_prefetch_quota=0
_db_file_noncontig_mblock_read_count=0

修改这三个隐藏参数后,发现db file parallel read等待事件已经消失：

SQL> SELECT event, COUNT(*) FROM v$session WHERE username = USER GROUP BY event ORDER BY 2;
EVENT                                                              COUNT(*)
---------------------------------------------------------------- ----------
SQL*Net message TO client                                                 1
db file scattered READ                                                   30
db file sequential READ                                                  70

 

标签：

相关文章