Oracle db file parallel write 和 log file parallel write 等待事件

Posted 2020-09-01 子鱼猴

 

一。 db file parallel write等待事件

引自如下blog：

http://oradbpedia.com/wiki/Wait_Events_-_db_file_parallel_write

 

db文件并行写

   db文件并行写等待事件属于Oracle数据库写入程序（DBWR）进程，因为它是将块从SGA写入数据文件的唯一进程。当是写入时，DBWR进程编译一组脏块，将批处理交给操作系统，并等待db文件并行写事件以完成I / O。
虽然用户会话从来没有遇到db文件并行写等待事件，但这并不意味着它们从不会受到影响。如果写完成等待或空闲缓冲区等待事件显示在用户会话中，则它们可能受到db文件并行写事件的影响。

如果用户会话需要修改恰好在DBWR写批处理中的块，则它必须等待写完成等待事件，直到该批块完全写入磁盘。如果批量大，或I / O子系统速度慢，则DBWR进程将需要等待I / O完成的额外时间，因此将需要正在写入块的用户会话。

如果用户会话正在经历空闲缓冲器等待事件，并且等待数量稳定增加，这意味着SGA中空闲块不足。如果缓冲区缓存太小，或者DBWR无法跟上块脏的速率，就会发生这种情况。 DBWR进程无法跟上脏块的原因之一是它花费了太多时间在db文件并行写事件上。

参数：

       P1 = Oracle正在写入的文件数。

       P2 =要写入的块数。

       P3 =与P2相同的I / O请求总数，因为不使用多块I / O。
由于P1和P2报告的是文件和块的数量，而不是绝对文件和块的数量，因此DBA无法确定正在写入哪些对象。但是，等待写入完成等待或空闲缓冲区等待事件的用户会话指示其P1和P2值中的绝对文件和块编号。

常见原因和措施

  db文件并行写延迟通常是慢I / O子系统或较差I / O配置的症状。这包括数据库文件布局不当，I / O控制器比率不正确，条带大小和/或RAID级别错误，以及磁盘不足（即有几个高容量磁盘与多个低容量磁盘）。 DBA需要查看平均I / O时间。良好的数据库和I / O子系统应提供不超过2厘秒的平均I / O等待时间。

  如果这是一个问题，DBA应通过映射从装载点到控制器和控制器到物理磁盘组的I / O路由，并确保数据库文件的正确放置来检查I / O配置。此功能的命令是平台。具体和不幸的是，通常需要管理员权限。对于在Sun平台上使用Veritas Volume Manager配置的存储系统，DBA可能能够使用vxprint -ht命令。 DBA还应该使用sar -d，iostat -dxn或等效工具从操作系统级别监视使用情况（即I / O吞吐量和瓶颈）。如果一些磁盘长时间（即几乎100％忙）被命中，并且平均队列长度大于3，则DBA需要重新安排一些数据库文件。

  除了确保I / O子系统配置正确并且数据库文件已正确放置之外，DBA还应使DBWR进程（如果平台）提供非阻塞I / O（DISK_ASYNC_IO = TRUE）。支持异步I / O。

较大的写批处理增加了DBWR I / O等待时间，特别是在数据文件放置不当的环境中。一个确定的标志，写批处理太大是当用户会话开始等待写完成等待事件。在Oracle 8i之前，_DB_BLOCK_WRITE_BATCH参数确定了DBWR写批量大小，并且值可以在X $ KVII中看到。它被列为DB写入程序IO丛集。在8i及更高版本中，此参数由_DB_WRITER_CHUNK_WRITES替换，并列为DBWR写入块。引入了一个新参数_DB_WRITER_MAX_WRITES以限制未完成的DBWR I / O数量。 DBA应确保批量大小不会大到导致写入完全等待和更长的db文件并行写入，并且也不会小到导致长脏队列和空闲缓冲区等待。另外，请记住，自8i以来，Oracle所做的改进应该使写批处理问题休息，DBA不应该混乱。写完成等待事件在8i之前的版本中是普遍的。

 

之前的Oracle 8i

SQL> select * from x $ kvii其中kviitag =‘kcbswc‘;

Oracle 8i及更高版本

SQL> select * from x $ kvii其中kviitag在（‘kcbswc‘，‘kcbscw‘）;

       当DB_BLOCK_MAX_DIRTY_TARGET参数设置得太低时，它也可能导致对db文件的过度等待并行写入和写入完全等待事件。此参数用于影响执行所需的时间量。实例恢复。当脏缓冲区的数量超过参数的值时，DBWR将把脏缓冲区写入磁盘。这称为增量检查点。较小的值提供较短的实例恢复时间，但是它可能导致DBWR进程变得多活动，特别是在正在修改大量缓冲区的活动数据库中。这反过来可能导致过多的写完成等待和更长的db文件并行写时间。此参数在9i中被隐藏，DBA不应该关心它。
   
诊断

       对于系统级诊断，请查询V $ SYSTEM_EVENT视图以确定AVERAGE_WAIT是否是问题。

       SQL> select * from v $ system_event where event =‘db file parallel write‘;

当在V$SYSTEM_EVENT时，还要查找伴随事件。

       SQL> select * from v $ system_event

       SQL> where event in（‘write complete waits‘，‘free buffer waits‘）;

       此事件发生在DBWR中。它表示DBWR正在对文件和块执行并行写入。当最后一个I / O转到磁盘时，等待结束.Wait时间：

Wait until all of the I/Os are completed.

Parameter      Description
 
requests       This indicates the total number of I/O requests, which will be the same as blocks.

interrupt
 
timeout        This indicates the timeout value in centiseconds to wait for the IO completion.

 

二.  log file parallel write 等待事件

引自如下blog：

http://oracle-dox.net/McGraw.Hill-Oracle.Wait.Interf/8174final/LiB0036.html

日志文件并行写

       日志文件并行写等待事件有三个参数：文件，块和请求。在Oracle数据库10g中，此等待事件属于系统I / O等待类。在处理日志文件并行写等待事件时，记住以下关键思想。

       （1）日志文件并行写事件仅属于LGWR进程。

       （2）缓慢的LGWR可以影响前台进程提交时间。

       （3）重要的日志文件并行写等待时间很有可能是I / O问题。

常见原因，诊断和操作

       由于db文件并行写等待事件仅属于DBWR进程，因此日志文件并行写等待事件仅属于LGWR进程。当到了写入时，LGWR进程通过向操作系统发出一系列系统写入调用将重做缓冲区写入联机重做日志。 LGWR进程等待日志文件并行写事件的写入完成。 LGWR进程在满足_LOG_IO_SIZE阈值时，在日志缓冲区中有1MB的重做条目，以及由DBWR进程发布时，在提交时，回滚时，每三秒钟寻找重做块一次写入一次。

       虽然用户会话从来不经历日志文件并行写等待事件，但它们可能受到缓慢的LGWR进程的影响。缓慢的LGWR进程可以放大日志文件同步等待，用户会话在提交或回滚期间等待。在LGWR完成写入之前，用户会话将不会获得提交或回滚完成确认。第7章有关于日志文件同步等待事件的更多细节。

       要查看的关键数据库统计信息是日志文件并行写入和日志文件同步等待事件的系统级TIME_WAITED和AVERAGE_WAIT，因为它们是相互关联的：

SQL> select event，time_waited，average_wait from v $ system_event where（‘log file parallel write‘，‘log file sync‘）;

EVENT TIME_WAITED AVERAGE_WAIT
------------------------- ----------- ------------
log file parallel write   11315158   .508570816
log file sync          7518513   .497255756

  如果日志文件并行写入平均等待时间大于10ms（或1cs），这通常表示缓慢的I / O吞吐量。修复与db文件并行写入等待相同。如果重做日志位于裸设备上，并且操作系统支持异步I / O，则启用异步写入。对于文件系统上的重做日志，请使用同步直接写入。
  不幸的是，你不能产生多个LGWR进程。在这种情况下，关键是没有别的东西共享重做日志文件的安装点。确保为安装点提供服务的控制器不会过载。将重做日志移动到更高速的磁盘也将有所帮助。
  我们强烈建议您避免将重做日志放在RAID5磁盘上，但我们也了解，很多时候，您没有选择或说话。您可以在www.baarf.com发泄您的沮丧。
  除了提高I / O吞吐量，还可以减少重做条目的数量。这将提供一些救济，但不是治愈。只要可能，请使用NOLOGGING选项。应使用NOLOGGING选项创建或重建索引。 CTAS操作也应使用此选项。

注意：

       NOLOGGING选项不适用于正常的DML操作，例如插入，更新和删除。使用NOLOGGING选项创建的对象不可恢复，除非在损坏之前执行备份。如果必须进行额外备份，则通过不记录而保存的I / O将用于备份。 FORCE LOGGING模式下的数据库将记录所有更改（临时表空间中的更改除外），而不管表空间和对象设置如何。

以较高的回滚段使用率为代价的较低提交频率也可以提供一些缓解。

       高提交频率导致LGWR进程过度活动，并且当与慢I / O吞吐量耦合时将仅放大日志文件并行写等待。

       应用程序可能在循环中处理大量数据并提交每个更改，这会导致日志缓冲区被过度刷新。在这种情况下，将应用程序修改为以较低的频率提交。也可能有很多短会话登录到数据库，执行。快速DML操作和注销。

       在这种情况下，可能需要审查应用程序设计。您可以使用以下查询查明谁正在提交频繁：

       SQL> select sid，value from v $ sesstat where statistic＃=（select statistic＃from v $ statname where name =‘user commits‘）order by value desc;

- Another evidence of excessive commits is high redo wastage.

SQL> select b.name, a.value, round(sysdate - c.startup_time) days_old from   v$sysstat a, v$statname b, v$instance c where a.statistic# = b.statistic# and    b.name  in (‘redo wastage‘,‘redo size‘);

NAME VALUE DAYS_OLD
--------------- --------------- ---------------
redo size        249289419360       5
redo wastage     2332945528         5

 
       检查作业调度程序，查看热备份是否在高峰时间运行。他们可以创建大量的重做条目，这反过来增加日志文件并行写等待。热备份应在非高峰时间运行，并且表空间应尽快从热备份模式中移除。

   最后，小心不要一次堵塞LGWR有太多的重做条目。这可能发生在大日志缓冲区，因为三分之一阈值也较大，并保存更多的重做条目。当满足三分之一阈值时，如果LGWR进程尚未激活，则执行后台写入。并且重做条目的数量可能太多，LGWR一次处理，导致扩展的日志文件并行写入等待。所以想法是流LGWR写。这可以通过降低由初始化参数_LOG_IO_SIZE控制的三分之一阈值来实现。

   默认情况下，_LOG_IO_SIZE是LOG_BUFFER的1/3或1MB（以较小者为准），以日志块表示。查询X $ KCCLE.LEBSZ的日志块大小。通常，它是512字节。

   例如，如果LOG_BUFFER为2,097,152字节（2MB），日志块大小为512字节，则_LOG_IO_SIZE的默认值为1,365个使用的日志块。在这个大小，LGWR进程变得懒惰，通常只写在事务终止（同步写）或从3秒超时唤醒。您应该将_LOG_IO_SIZE设置为相当于64K。这样，你仍然可以有一个更大的日志缓冲区，以适应检查点后的缓冲区空间的尖峰，但是当缓冲区中有64K个重做条目时，写入将开始，假设没有用户提交或回滚，LGWR睡眠在此期间没有超时。

 

笔记：

   这种方法不是没有开销。 LGWR写操作需要重做复制和重做写锁存器。因此，更有效的LGWR过程将增加这些锁存器上的负载。如果这些锁存器当前具有高SLEEPS，则不要减小_LOG_IO_SIZE。但是，如果条件允许您更改_LOG_IO_SIZE，则必须通过查询V $ LATCH视图来监视其随时间的影响。确保在实施更改之前获得基线。

   您可以使用以下查询来查找每个写入的重做日志块的平均数量和平均LGWR I / O大小（以字节为单位）：

SQL> select v（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‘和b.name =‘redo writes‘;

AVG_REDO_BLKS_PER_WRITE AVG_IO_SIZE
----------------------- -----------
                      8 8192