Author: mac

Direct path writes allow a session to queue an I/O write request and continue processing while the OS handles the I/O. If the session needs to know if an outstanding write is complete then it waits on this wait event. This can happen because the session is out of free slots and just needs an…

Often related to sorting operations, check to see if occurring primarily in temp tablespaces. Solutions 1) Reading from temp tablespaces If the database parameter workarea_size_policy = AUTO: Increase the database parameter pga_aggregate_target. Otherwise: Increase the database parameter sort_area_size. Another possible solution is to cache the temp datafile at the O/S or Storage system level. 2)…

Sometimes related to sorting operations, check to see if occurring primarily in temp tablespaces. During Direct Path operations the data is asynchronously read from the database files. At some point the session needs to make sure that all outstanding asynchronous I/O have been completed to disk. This can also happen if, during a direct read,…

Waits on ‘db file sequential read’ normally occur during index lookups when the block is not in memory and must be read from disk. They are generally considered a ‘good’ read unless the index being used is not very efficient. In this case the query will read more blocks than necessary and possibly age out…

Oracle中db file scattered read等待事件发生在当一个会话在等待一个多数据块的IO请求完成。其典型的发生在当有全表扫描和索引快速扫描INDEX FAST FULL SCAN时。Oracle一次性读取DB_FILE_MULTIBLOCK_READ_COUNT对应的连续数据块，并将它们分散到buffer cache中的buffer中。 换句话说从IO读取上和物理存储的顺序上这些数据块应当是连续的，一个块排在一个块后面，但从buffer cache角度看这些数据块对应的buffer并不连续在一起。   具体的行为当然也和操作系统版本以及oracle版本相关，以及不同的存储设备特性都会有关系。 该db file scattered read等待的相关参数： p1 file#  这是db file scattered read读取的数据块所在的数据文件文件号，从Oracle 8开始是绝对数据文件号ABSOLUTE file number (AFN)。 p2 block# 这是db file scattered read读取的起始数据块号 p3 blocks 这是db file scattered read读取的块的数量，最大为DB_FILE_MULTIBLOCK_READ_COUNT，从Oracle 10.2开始该参数会自动调优。   db file scattered read的等待时间 是直到所有数据块的IO请求都被满足。注意操作系统可能基于文件系统缓存来满足这些IO请求，对于Oracle来说 起始它并不知道这些IO请求是从文件系统缓存返回的，还是真的左了磁盘的读取操作或存储响应返回的，它只负责做read() pread()这些操作系统系统调用而已。   Waits on this event indicate the statement is performing…

This event occurs in the DBWR. It indicates that the DBWR is performing a parallel write to files and blocks. When the last I/O has gone to disk, the wait ends. This wait only occurs in the DBWR processes. Problem Ultimately, the operating system’s I/O subsystem is the bottleneck. User sessions wait for DBWR to…

The process has issued multiple I/O requests in parallel to read blocks from data files into memory and is waiting for all requests to complete. This occurs during regular activity when a session batches many single block I/O requests together and issues them in parallel. This is also occurs during recovery. This wait event does…

‘cursor: pin * events’等待事件 该类等待事件一般是为了pin相关的子游标   ‘cursor: pin X’  当一个进程需要以EXCL X mode获得mutex时， 这类需要EXCL X 模式的串行操作包括: 构建一个子游标 某个进程已经以X mode持有该Mutex 一个或多个进程正在reference 该Mutex (shared mutex pin)   如果自己搞不定可以找诗檀软件专业ORACLE数据库优化团队成员帮您调优! 诗檀软件专业数据库优化团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]   详见 《深入理解Oracle中的Mutex》一文 Cursor: pin X    A session waits on this event when it needs to get a mutex in X mode…

‘cursor: pin * events’等待事件 该类等待事件一般是为了pin相关的子游标 ‘Cursor: pin S on X’ 最常见的等待事件，  进程为了共享操作例如执行pin游标而以SHRD S mode申请mutex， 但是未立即获得。原因是该游标被其他进程以EXCL X mode 持有了。 实际该 cursor: pin S wait on X等待事件往往是由于其他因素诱发的。Mutex争用仅仅是问题的症状，但根本原因需要Database Consultant 进一步挖掘。   下面我们列出一些已知的常见案例， 在这些例子中可以看到 我上面提到的 Mutex的争用仅仅是伪争用:   过多的子游标 High Version Counts   过多的子游标版本Version Count可能导致Mutex 争用，一般一个SQL的Version Count不要高于500。 检查High Version Count很简单， 在AWR里就有SQL ordered by High Version Count，也可以写SQL查V$SQL、V$SQLAREA     昂贵的X$、V$视图查询   一些对于V$、X$视图的查询，需要访问X$KGL*之类的fixed…

‘cursor: pin * events’等待事件 该类等待事件一般是为了pin相关的子游标 cursor: pin S  当一个进程以共享pin模式申请一个Mutex，而不能立即获得时，进入cursor: Pin S等待事件。 Mutex Pin是以共享类型的操作，例如执行一个游标。 当一个进程等在cursor: pin S上，说明该进程在对一个共享的mutex pin 参考或取消参考时，有其他的进程也正在为同样的cursor heap创建或者取消一个共享Mutex pin。 实际上cursor: pin S 等待事件应当很少见，因为更新共享Mutex pin 的reference 应当是很快的。 再重复一次，S mode的Mutex可以被并发持有， 但是更新Mutex的Ref Count仍需要串行地处理 。 一旦reference count被增加好，则后续进程将可以为同样的cursor heap增加reference count。 因此此处mutex 即可以扮演Latch的角色(串行控制ref count的更新)，又可以扮演pin的角色(ref count本身)。   详见 《深入理解Oracle中的Mutex》一文    cursor: pin S 相关的AWR报告。     A session waits on this…