Possible causes
control file Sequential read
Reading from the control file. This happens in many cases. For example, while:
1. Making a backup of the control files
2, sharing information (between instances) from the control file
3. Reading other blocks from the control files
4. Reading the header block
Wait time:the wait time is the elapsed time of the read
Parameter |
Description |
file# |
The control file from which the session is reading |
block# |
Block number in the control file from where the session starts to read. The block size is the physical block size of the port (usually bytes, some UNIX ports has 1 or 2 kilobytes). |
Blocks |
The number of blocks the session is trying to read |
Analysis
V$session_wait to see in which file (P1), which block (P2), and how many blocks (p3) The current wait event occurred.
V$session_wait_history records up to 10 records per class of wait events, so there are up to 10 rows of data per item.
There is no "control file sequential read" Item in the current wait event, as can be seen from viewing up to 10 entries in the v$session_wait, the data blocks read in the event are not concentrated, and the number of blocks per read is 1 (1 is normal) and the wait time is 0. This indicates that the database is healthy.
Summary
first , the wait event does not indicate a problem with the database. A healthy system, the physical read event should be the maximum wait event except for idle wait events. This event is particularly noticeable in RAC, in the experience that in a normal RAC cluster, the event should be in Top10, because the instances share the same control file, the control file read is very frequent, if the other wait events out of the top 10, then you have to see what is waiting for the event.
second , the AWR reports the number of waits for the event, the average wait time, the maximum wait time, and other information to confirm. See if this information is significantly abnormal than the daily AWR report information.
Control file sequential Read wait event