非空闲的等待事件(四)

非空闲的等待事件(一)http://blog.chinaunix.net/u3/107027/showart_2146592.html

非空闲的等待事件(二)http://blog.chinaunix.net/u3/107027/showart_2146601.html

非空闲的等待事件(三)http://blog.chinaunix.net/u3/107027/showart_2146610.html

 

十五、log file switch(archiving needed)

 

1. 日志文件转换，必须归档。在使用归档方式下的数据库时，只有arch进程通过将REDO文件复制到归档日志文件中（完成归档），LGWR进程才可以改写或转换该重做日志文件。
2. 对归档文件的写入失败，可能会中止归档进程，在警告日志中报告。
3. 等待时间：1秒
4. 无参数

十六、log file switch(checkpoint imcomplete)

1. 由于对REDO的检查点进程未完成而使日志文件的转换变得不可能。
2. 无参数
3. 等待时间：1秒

十七、log file switch completion

1. 当日志文件转换完成时产生的等待事件
2. 无参数
3. 等待时间：1秒

十八、log file sync(Commit类)

1. ORACLE在SGA中的日志缓冲区中记录事务和块改变，通过以各种时间条件将内容写入到日志文件，LGWR负责这项工作，写入的时间条件是：

A. 每隔3秒  

B. 当日志缓冲区的1/3已满或具有1MB的重做条目时 

C. 当用户提交或回滚事务时   

D. 当DBWR进程给LGWR发出信号(当DBWR将脏块写入到数据文件之前写入)

2. 由用户提交或回滚的写入称为"同步写入"，其他的称为"后台写入"。log file sync只和同步写入有关。用户会话从来不需要等待后台写入的完成。
3. 当用户会话通过提交或回滚完成一个事务时，必须用LGWR进程将会话的重做信息写入重做日志，会话才能继续其处理。在LGWR同步期间，LGWR进程在log file parallel write事件上等待同步写入完成，而用户会话则在log file sync事件上等待LGWR的完成。

   

4. log file sync等待事件与事务的终止(提交或回滚)相关。当进程在log file sync事件上花费大量时间时，通常表明过多的提交或短事务。
5. 每个COMMIT必须得到相关REDO写入磁盘的确认。
6. 调整LGWR进程使其得到良好的磁盘吞吐量。如：不要将重做日志放在RAID5阵列；如果有大量的短周期的事务，则看能否批处理这些事务，使COMMIT次数减少。
7. 查询会话中谁执行了大量的提交：

SELECT a.sid,
       a.event,
       a.time_waited,
       round(a.time_waited / c.sum_time_waited * 100, 2) || '%' pct_wait_time,
       d.VALUE user_commits,
       round((SYSDATE - b.logon_time) * 24) hours_connected
  FROM v$session_event a,
       v$session b,
       (SELECT sid, SUM(time_waited) sum_time_waited
          FROM v$session_event
        
         WHERE event NOT IN
               ('smon timer', 'pmon timer', 'rdbms ipc message', 'Null event',
                'parallel query dequeue', 'pipe get', 'client message',
                'SQL*Net message to client', 'SQL*Net message from client',
                'SQL*Net more data from client', 'dispatcher timer',
                'virtual circuit status',
                'lock manager wait for remote message', 'PX Idle Wait',
                'PX Deq: Execution Msg', 'PX Deq: Table Q Normal',
                'wakeup time manager', 'slave wait', 'i/o slave wait',
                'jobq slave wait', 'null event', 'gcs remote message',
                'gcs for action', 'ges remote message', 'queue messages')
         HAVING SUM(time_waited) > 0
         GROUP BY sid) c,
       v$sesstat d
 WHERE a.sid = b.sid
   AND a.sid = c.sid
   AND a.sid = d.sid
   AND d.statistic# =
       (SELECT statistic# FROM v$statname WHERE NAME = 'user commits')
   AND a.time_waited > 10000
   AND a.event = 'log file sync'
 ORDER BY hours_connected DESC, pct_wait_time

8. 可以使用Oracle Log Miner深入研究重做日志文件，这能查看系统范围的提交行。
9. IO的吞吐量也是考量之一，如下：

SELECT s.event, s.time_waited, s.average_wait
  FROM v$system_event s
 WHERE s.event IN ('log file parallel write', 'log file sync')
注：'log file parallel write'事件的平均等待时间大于10ms(1cs)，这通常表示存在缓慢的IO吞吐量。

10. 产生该等待事件的主要原因：

高提交率	原因： >> 高提交率会增加开始与结束事务时的系统开销(事务表的更新、提交后的清除、回滚段的使用被记录在日志缓冲区中等等)。 解决方法： >> 以事务单元作为提交的准则。 >> 不要因为回滚段空间不足或死锁的原因而引入附加的提交。如果回滚段空间不够而造成不可以处理一个工作单位，可以分配足够的空间给UNDO表空间，并且设置适当的UNDO保留时间(通过初始化参数undo_retention设置)。 >> 来自于中间层的持久性连接，因为服务于许多前端用户，所以只能用10046事件进行跟踪，以观察应用程序的行为；或使用Oracle Log Miner查看重做日志文件。
缓慢的IO子系统	通过查询v$system_event视图，找出LGWR平均等待时间。小于1厘秒(cs)一般是可以接受的。
过大的日志缓冲区	>>  日志缓冲区过小，会造成log buffer space事件上的等待，而日志缓冲区过大，会造成LGWR进程写入频率变慢，一次写入量变大。 >> 可以通过减少初始化参数_LOG_IO_SIZE的值，这将增LGWR的后台写入，从而减少log file sync等待时间，但这种方法仍然需要一定的系统开销，更为活跃的LGWR将在redo copy和redo writing锁存器方面添加更多的负载。 >> 获得_LOG_IO_SIZE设置值： select trunc(a.value/b.value*512) as "REDO每次写入字节数",         trunc(1024*1024/3) as "9I系统设置写入字节数"   from         (SELECT s.VALUE FROM v$sysstat s           WHERE s.NAME = 'redo blocks written') a,         (SELECT s.VALUE FROM v$sysstat s           WHERE s.NAME = 'redo writes') b >> 较大的processes参数值也可增加log file sync的等待，在每个同步操作期间，LGWR必须扫描所有进程的数据结构查找哪些会话正在这个事件上等待，并将它们的重做写入到硬盘。

11. 参数：

事件号：184

事件名：log file sync

参数一：需要同步的日志缓冲区的区号

 

十九、log buffer space(Configuration类)

1. 当会话由于日志缓冲区空间不足而无法将重做日志条目复制到日志缓冲区时，会话将在log buffer space事件上等待。LGWR负责写出重做条目，腾出日志缓冲区空间。
2. 当会话必须等待日志缓冲区中的空间变成可用以写入新的信息时产生该事件。
3. LGWR进程周期性地从日志缓冲区写入重做日志文件，使得日志缓冲区可以重复可以。
4. 该等待事件表示：应用程序生成重做日志的速度比LGWR进程将其写入重做日志文件的速度快。
5. 通过查询v$sesstat和v$sysstat查询统计""可跟踪进程或系统必须等待空间的次数。

-- 会话级统计必须等待日志缓冲区的次数。

SELECT s.SID , s.VALUE
  FROM v$sesstat s
 WHERE s.statistic# =
       (SELECT t.statistic#
          FROM v$statname t
         WHERE t.NAME = 'redo buffer allocation retries')

-- 系统级统计必须等待日志缓冲区的次数

SELECT  s.STATISTIC#, s.CLASS, s.NAME , s.VALUE
  FROM v$sysstat s
 WHERE s.statistic# =
       (SELECT t.statistic#
          FROM v$statname t
         WHERE t.NAME = 'redo buffer allocation retries')

6. 该事件没有参数。
7. 产生该等待的原因：

过小的日志缓冲区	>> 检查当前LOG BUFFER的设置，并根据需要做适当的调整。 >> 日志缓冲区不是SGA中的动态组件，因此必须生效前需要重启实例。
缓慢的I/O子系统	>> 确保log file parallel write等待事件的平均等待时间在可接受的范围内，否则需要改进IO性能。 >> 根据应用程序的情况，在适当的位置设置NOLOGGING选项。 >> 作为辅助手段借助Oracle Log miner深入研究来自于v$sql视图或重做日志文件的DML，发现异常行为。

 

二十、log file parallel write(SYSTEM I/0类)

1. LGWR专属事件，将日志缓冲区中的重做信息写入到联机重做日志组的所有成员，LGWR在该事件上等待写入的完成。
2. 写入时机：

>> 每隔3秒写入一次

>> 在提交或回滚时

>> 在满足_LOG_IO_SIZE阈值时

>> 在日志缓冲区有1MB的重做项时

>> 由DBWR提交时

3. 用户会话提交事务时，LGWR会等待该事件的完成，用户会话则等待log file sync事件。
4. 该事件的等待表示重做日志所处的磁盘设备缓慢或存在争用。

SELECT s.event, s.time_waited, s.average_wait
  FROM v$system_event s
 WHERE s.event IN ('log file parallel write', 'log file sync')

注：'log file parallel write'事件的平均等待时间大于10ms(1cs)，这通常表示存在缓慢的IO吞吐量。

5. 如果该事件的等待时间过长，除了改进IO吞吐量外，

也可以设法降低重做的数量。

>> 只要有可能就使用NOLOGGING选项。

>> CTAS操作也应该使用该选项。

也可以以较高的回滚段使用率为代价的较低提交频率，来缓解一些IO需求，使用以下SQL查出谁在频繁提交数据：

SELECT sid, VALUE
  FROM v$sesstat s
 WHERE s.statistic# =
       (SELECT statistic# FROM v$statname WHERE NAME = 'user commits')
 ORDER BY VALUE

SELECT b.NAME, a.VALUE, round(SYSDATE - c.startup_time) day_old
  FROM v$sysstat a, v$statname b, v$instance c
 WHERE a.statistic# = b.statistic#
   AND b.NAME IN ('redo wastage', 'redo size')

注：由于LGWR不象DBWR那样能够有多个，所以尽可能将REDO放在IO快的磁盘结构上，不要放在象RAID5这样的磁盘上。

6. 热备可能创建大量的重做项，从而增加log file parallel write等待事件，所以热备份应该在非高峰时间内运行，并且应该尽可能将表空间排除在热备份模式外。
7. 注意不要同时使用过多的重做项堵塞LGWR。可以使用下需的查询来找到每次写入的平均重做日志块的数量，以及以字节为单位的LGWR IO平均大小：

SELECT round((a.VALUE / b.VALUE) + 0.5, 0) AS avg_redo_blks_per_write,
       round((a.VALUE / b.VALUE) + 0.5, 0) * c.lebsz AS avg_io_size -- 字节为单位
  FROM v$sysstat a, v$sysstat b, x$kccle c
 WHERE c.lenum = 1
   AND a.NAME = 'redo blocks written'
   AND b.NAME = 'redo writes'

注：x$kccle.lebsz字段包含每个日志块的大小。

8. 参数说明：

事件号：176

事件名：log file parallel write

参数一：写入的日志文件号

参数二：写入的块数

参数三：IO请求的号码

9. 等待时间：完成所有IO所占用的实际时间。

二十一、log file sequential read

1. 当进程等待从REDO文件中读入块时会产生该等待事件。
2. ARCH进程在读取REDO文件时会遭遇此等待事件。
3. 参数说明：

事件号：174

事件名：log file sequential read

参数一：REDO日志组中重做日志文件的相对序列号。

参数二：开始读入的块号

参数三：块数

4. 等待时间：完成请求读取的IO所占用的实际时间。

二十二、SQL*Net message from client

1. 当会话等待来自CLIENT的消息到达时提交该事件。一般而言，这意味着会话处于空闲状态。
2. 在不与用户操作交互的批处理环境中，若此事件上的等待时间过多，则表示在应用程序代码中或网络层存在低效率因素。
3. 但该事件上的过高等待时间并不降低数据的性能的情况下，可以查觉出并不是真正的数据库问题
4. 参数说明：

参数一：显示客户端网络驱动的类型。

参数二：来自客户端的字节数

5. 等待时间：无超时

二十三、SQL*Net message to client

1. 当会话发送一个消息至客户端时，而客户端太忙造成不能接受消息的传送，使得服务器端的会话等待　或网络层延迟而使消息传送花费更长的时间
2. 参数说明：

参数一：客户端连接使用的网络驱动器的类型

参数二：发送到客户端的字节数

3. 等待时间：无超时