登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

飞哥的技术博客

世上无难事,只怕有心人!

 
 
 

日志

 
 
 
 

Oracle IO问题解析-性能调优--3  

2009-07-05 15:32:36|  分类: Oracle优化 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

Oracle IO问题解析

  3.2.3 db file parallel read

  首先,不要被该事件名称所误导——它和并行DML或者并行查询都无关。当从多个数据文件并行读取数据到非联系的内存(PGA、Buffer Cache)缓冲中时,会发生该等待事件。它通常发生在Recovery操作或者利用缓冲预提取(Buffer Prefetching)从数据文件并行读取数据时。

  我们可以通过以下语句找出发生db file parallel read等待事件的数据文件和数据块:

  select p1 "fileid", p2 "block_id", p3 "requests"

  from v$session_wait

  where event = 'db file parallel read';

  优化该等待事件的手段可以参考优化db file sequential read等待事件中非SQL优化方法部分。

  3.2.4 direct path read & direct path read (lob)

  当直接读取(Direct Read)数据到PGA(而不是到Buffer Cache)中去时,会发生Direct Path Read等待事件。对Lob数据的直接读有一个单独的等待事件——direct path read (lob)。

  当Oracle设置支持异步IO时,进程可以在提交IO请求后继续做其他操作,并且在稍后再提取IO请求返回的结果,在提取结果时就产生了direct path read等待事件。

  在没有启用异步IO时,IO请求在完成之前会被阻塞,但在执行IO操作时并不会产生等待事件。进程稍后回来提取那些已经读取到的IO数据,这时尽管能够很快返回,但仍然会显示direct path read等待事件。

  和其他IO等待事件不同的是,对Direct Path Read等待事件要注意以下两点:

  等待次数并不等于IO请求次数;

  统计(如statspack报告中)得出的Direct Path Read的等待时间并不一定代表该事件引起的真正等待时间。

  事件中的P1、P2、P3参数分别代表:

  P1:发生等待事件的数据块所在文件号;

  P2:发生等待事件的数据块号;

  P3:等待事件涉及的连续数据块数量。

  直接读(Direct Read)请求一般发生在以下几种情况:

  磁盘排序IO(Sort Area不足时,排序用到的临时数据会被写到临时表空间上去,当读取这些数据时就使用直接读);

  并行查询;

  预读取(当一个进程认为某个数据块将很快被用到而发出IO请求时)

  Hash Join(Hash Area不足)

  IO负载系统中,服务进程处理缓存的速度比系统IO返回数据到缓存的速度更快时

  通过视图V$SESSION_EVENT我们可以找出当前产生等待的会话,再根据会话中正在进行的操作确定导致等待的原因。针对不同的原因,我们可以采取不同的措施减少Direct Path Read等待事件。

  3.2.4.1 磁盘排序

  首先我们可以考虑优化语句以减少排序操作。排序一般是由以下操作引起的:

  o Order By;

  o JOIN;

  o UNION;

  o Group By;

  o 聚合操作;

  o Select unique;

  o Select distinct;

  可以尝试在语句中减少没必要的上述操作来避免排序操作。另外,创建索引也会引起排序操作。在专业模式(Dedicated)下,排序所占用的内存是从PGA中分配出来的一块区域,叫Sort Area,由参数sort_area_size控制其大小;在MTS中,排序区是从Large Pool中分配的。当sort area大小无法满足排序操作要求时,就会占用临时表空间来存放排序数据,因而产生Direct Path Read等待事件。我们可以通过适当增加该参数来减少磁盘排序操作。

  这个参数可以在系统范围或会话范围进行修改。对于一些需要做大量排序操作而且又比较独立的会话(如Create Index),我们可以在会话级别为其设置比较大的Sort Area以满足排序需要:

  SQL> alter session set sort_area_size = 10000000;

  Session altered.

  该参数大小一般推荐设置为1~3M。在9i之后,不推荐设置该参数,我们可以通过设置PGA_AGGREGATE_TARGET进行PGA内存自动管理(设置WORKAREA_SIZE_POLICY为TRUE)。对于PGA_AGGREGATE_TARGET的大小设置,可以参考文章《Oracle内存全面分析》中的PGA_AGGREGATE_TARGET部分。

  此外,我们还可以通过以下语句来查找系统中存在磁盘排序的会话及其语句:

  SELECT a.sid,a.value, b.name, d.sql_text from

  V$SESSTAT a, V$STATNAME b, V$SESSION c, V$SQLAREA d

  WHERE a.statistic#=b.statistic#

  AND b.name = 'sorts (disk)'

  and a.sid = c.sid

  and c.SQL_ADDRESS = d.ADDRESS(+)

  and c.SQL_HASH_VALUE = d.HASH_VALUE(+)

  and value > 0

  ORDER BY 2 desc,1;

  3.2.4.2 并行查询

  当设置表的并行度非常高时,优化器可能就对表进行并行全表扫描,这时会引起Direct Path Read等待。

  在使用并行查询前需要慎重考虑,因为并行查询尽管能教师程序的响应时间,但是会消耗比较多的资源。对于低配置的数据库服务器不建议使用并行特性。此外,需要确认并行度的设置要与IO系统的配置相符(建议并行度为2~4 * CPU数)。在10g中,可以考虑使用ASM。

  对于表的并行度,我们不建议直接用ALERT修改表的物理并行度:

  ALTER TABLE t_test1 PARALLEL DEGREE 16;

  而是推荐针对特定语句使用提示来设置表的并行度:

  SQL> SELECT /*+ FULL(T) PARALLEL(T, 4)*/ object_name FROM t_test1 t;

  47582 rows selected.

  Execution Plan

  ----------------------------------------------------------

  Plan hash value: 2467664162

  --------------------------------------------------------------------------------

  | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time

  | TQ |IN-OUT| PQ Distrib |

  --------------------------------------------------------------------------------

  | 0 | SELECT STATEMENT | | 47582 | 1068K| 42 (3)| 00:00:01

  | | | |

  | 1 | PX COORDINATOR | | | | |

  | | | |

  | 2 | PX SEND QC (RANDOM)| :TQ10000 | 47582 | 1068K| 42 (3)| 00:00:01

  | Q1,00 | P->S | QC (RAND) |

  | 3 | PX BLOCK ITERATOR | | 47582 | 1068K| 42 (3)| 00:00:01

  | Q1,00 | PCWC | |

  | 4 | TABLE ACCESS FULL| T_TEST1 | 47582 | 1068K| 42 (3)| 00:00:01

  | Q1,00 | PCWP | |

  --------------------------------------------------------------------------------

  3.2.4.3 Hash Join

  Hash Area是用于hash join的内存区域。Hash Area过小会引起Direct Path Read等待。当WORKAREA_SIZE_POLICY为FALSE时,可以考虑增加hash_area_size的大小(建议为sort_area_size大小的1.5倍);当WORKAREA_SIZE_POLICY为TRUE时,可以考虑增加PGA_AGGREGATE_TARGET大小。

  3.2.4.4 Direct path read (lob)

  为了减少LOB的读写时间,通常我们会设置LOB的存储参数NOCACHE,这时读取LOB时会引起Direct Path Read (lob)等待事件。但当我们发现Direct path read (lob) 引起了IO性能问题,就需要考虑将那些被经常读取的LOB字段设置为CACHE。另外,如果操作系统的文件系统有足够的Buffer Cache时可以考虑将LOB数据段存储在文件系统上。

  3.2.4.5 其他优化措施

  当内存资源不足、IO读取数据到内存效率远远低于内存中数据被处理的效率时,会引起Direct Path Read等待事件。作为对上述处理措施的补充,增加内存(PGA)、在确保操作系统支持AIO情况下设置DISK_ASYNCH_IO为TRUE以支持异步IO、采用效率更高的存储设备都能帮助我们减少Direct Path Read等待。

  3.2.5 direct path write & direct path write (lob)

  直接写(Direct Path Write)允许一个会话先将IO写请求放入一个队列中,让操作系统去处理IO,而自身可以继续处理其他操作。当会话需要知道写操作是否完成(如会话需要一块空闲的缓存块或者会话需要确认内存中所有写操作都被flush到磁盘了),会话就会等待写操作完成从而产生Direct Path Write等待事件。Direct Path Write (lob) 是在对LOB数据段(NOCACHE)直接写时产生的等待事件。

  在没有启用异步IO时,IO写请求在完成之前会被阻塞,但在执行IO写操作时并不会产生等待事件。进程稍后回来提取那些已经完成的IO操作数据,这时尽管能够很快返回,但仍然会显示direct path write等待事件。

  和Direct Path Read等待事件相似,对Direct Path Write等待事件也要注意以下两点:

  等待次数并不等于IO请求次数;

  统计(如statspack报告中)得出的Direct Path Write的等待时间并不一定代表该事件引起的真正等待时间。

  事件中的P1、P2、P3参数分别代表:

  P1:发生等待事件的数据块所在文件号;

  P2:发生等待事件的数据块号;

  P3:等待事件涉及的连续数据块数量。

  直接写请求一般发生在以下几种情况:

  直接数据载入操作(如CTAS、SQL*Loader设置Direct选项等);

  并行DML操作;

  磁盘排序(排序内存空间不足,数据写入磁盘);

  载入NOCACHE数据段;

  对Direct Path Write的优化处理措施基本上和Direct Path Write类似。

3.3 控制文件相关的IO事件
  这一类等待事件发生在对控制的IO操作时。对控制文件的IO访问一般都是由Redo Log文件切换、Checkpoint等(如更新SCN)引起的。因此,对这类事件的优化处理也就主要是对这些操作的调优处理。
  3.3.1 control file parallel write
  这一等待事件通常发生在一个服务进程在更新所有控制文件时,通常是以下情况:
  会话启动了一个控制文件事务(在提交事务之前更新所有控制文件为最新);
  会话提交了一个事务到控制文件;
  一个控制文件的条目被修改了,该修改要更新到所有控制文件上去
  如果这一事件明显影响到了系统的IO性能时,可以考虑用以下手段来进行优化:
  在保证控制文件的备份数量足够安全(不会出现控制文件全部丢失)的情况下使控制文件数量最少;
  如果操作系统支持AIO,设置数据库支持AIO;
  将控制文件转移到IO负载比较低的磁盘上去。
  3.3.2 control file sequential read
  这一等待事件通常发生在对一个单独的控制的IO读操作时。通常可能是以下情况:
  备份一个控制文件;
  RAC中在实例之间共享一个控制文件信息时;
  读取控制文件的头数据块或者其他数据块时。
  用以下语句可以找到是访问哪个控制导致的该等待事件:
  select P1 as FileName from V$SESSION_WAIT
  where EVENT = 'control file sequetial read' and STATE='WAITING';
  我们可以采取以下手段来降低这一等待:
  如果操作系统支持AIO,设置数据库支持AIO;
  将控制文件转移到IO负载比较低的磁盘上去。
  3.3.3 control file single write
  这一等待事件通常发生在对一个单独的控制的IO写操作时。用以下语句可以找到是访问哪个控制导致的该等待事件:
  select P1 as FileName from V$SESSION_WAIT
  where EVENT = 'control file single write' and STATE='WAITING';
  我们可以采取以下手段来降低这一等待:
  如果操作系统支持AIO,设置数据库支持AIO;
  将控制文件转移到IO负载比较低的磁盘上去。
  3.4 Redo Log相关的IO事件
  在写Redo Log时,会发生很多等待事件,大部分和IO相关。其中最重要的要属“log file parallel write”和“log file sync”。Oracle的后台LGWR进程会等待“log file parallel write”事件而前台进程会等待“log file sync”事件。
  3.4.1 log file parallel write
  这一等待事件发生在LGWR进程等待完成将Redo记录写入Redo Log文件时。在LGWR进程将Log Buffer中的数据写入Log File时会发生该事件。
  当使用了异步IO时,这种写操作是并行的,否则只会一个接着一个Redo文件的写入。LGWR进程必须等待所有的Redo Log文件都被写入。因而Redo Log文件所在磁盘的IO效率就直接影响了该等待事件的总的等待时间。
  事件中的P1、P2、P3参数分别代表:
  P1:有多少个Redo Log文件在被写入;
  P2:有多少个数据块被写入;
  P3:IO请求的次数。
  降低log file parallel write等待的方法有:
  不要使表空间长期处于热备状态。当表空间处于热备状态时,表空间不再被更新,Redo Log会急剧增加;
  将Redo Log文件放在高速存储设备上,千万别放在RAID5上,可以考虑放在裸设备上;
  Redo log文件所在的磁盘应尽量避免有其他IO操作的存在;
  对某些操作,如大批量数据导入,可以设置NOLOGGIN、UNRECOVERABLE选项,或者在SQL语句中使用提示/*+APPEND*/,以减少Redo Log的产生。
  在确保Redo Log数据足够安全(不会发生Log文件丢失)的情况下,尽量减少Redo Log组的成员数;
  在配置需要使用到Redo Log的功能时,如Streams复制、LogMiner、逻辑模式的DG,尽量设置为最低级别的补充日志(Supplemental Logging);
  适当增加Log_buffer的大小
  我们可以按照以下方法来调整Log_buffer的大小,比较Redo Log buffer分配的重试(在请求log buffer时,无足够buffer,需要重新提交请求)率,如果该比例大于0.1%,我们就需要考虑增加Log_buffer的大小。
  select retries.value/entries.value "Redo Log Buffer Retry Ratio"
  from V$sysstat retries, V$sysstat entries
  where retries.name = 'redo buffer allocation retries'
  and entries.name = 'redo entries';
  另外,如果系统统计数据中redo log space requests大于0,说明有进程在等待分配Redo Log文件空间,而不是等待Buffer空间。这时我们也需要考虑增加Log_buffer的大小。
  SELECT name, value
  FROM v$sysstat
  WHERE name = 'redo log space requests';
  但是,Log_buffer的大小不要超过128K*CPU或512K(取两个数字中最大的一个)数。
  3.4.2 log file sync
  当Oracle前台进程提交或者回滚事务需要等待提交或回滚完成时会产生该等待事件。部分等待的原因可能是等待LGWR进程将会话事务的Redo记录从Log Buffer中拷贝到磁盘上去。这时,就会出现前台进程等待Log File Sync,而后台LGWR进程在等待 Log File Parallel Write的情况。
  事件中的P1、P2、P3参数分别代表:
  P1:发生等待时正在等待哪个Log Buffer数据被写入Log文件;
  P2:无意义;
  P3:无意义。
  实际上,一个Log File Sync等待事件包含了多个步骤:
  1、 如果LGWR空闲则唤醒LGWR进程;
  2、 LGWR收集需要写的Redo记录并提交IO请求;
  3、 等待写Log的IO完成;
  4、 LGWR IO提交处理;
  5、 LGWR提交已经完成了写日志的前台/用户进程;
  6、 前台/用户进程被唤醒。
  如果配置了Data Guard,上述步骤中的第三步还需要将Redo记录通过网络写入到standby数据库的Redo Log文件中去。
  针对不同步骤的等待时间的不同,我们需要采取不同的优化措施:
  第二、三步的相关等待数据可以从statspack或awr的“redo write time”统计项获得;
  第三步的等待时间和Log File Parallel Write的等待时间相同;
  当系统负载非常高时,第五、六两步的时间就会很长,因为此时尽管LGWR进程已经通知了前台/用户进程写日志已经完成,但是系统负载太高,前台/用户进程需要等待操作系统安排其运行计划。
  要了解是什么阻滞了Log File Sync的关键是比较Log File Sync和Log File Parallel Write的平均等待时间:
  如果他们的等待时间差不多,则说明是Log文件的IO问题(即第三步)导致的Log File Sync等待,我们就需要优化Log文件的IO(如上一节所述的方法);
  如果Log File Sync的等待时间远远大于Log File Parallel Write的等待时间,则说明Log File Sync是由于在提交或回滚时的其他Redo Log机制(非IO原因)引起的,如Latch Free、LGWR wait for copy等log buffer相关的latch冲突。
  可以用下面的语句来获取Log File Sync和Log File Parallel Write的平均等待时间的比值:
  select (sum(decode(name, 'redo synch time', value)) / sum(decode(name, 'redo synch writes', value)))
  / (sum(decode(name, 'redo write time', value)) / sum(decode(name, 'redo writes', value)))
  as sync_cost_ratio
  from v$sysstat
  where name in ('redo synch writes', 'redo synch time', 'redo writes', 'redo write time');
  我们还可以采取以下调优手段来降低Log File Sync等待:
  按照上一节中的方法减少Redo Log的产生、提供Redo Log的IO效率、减少Redo Log与其他IO的冲突;
  将一些小事务合并成批量事务,以减少提交和回滚次数。
  3.4.3 log file single write & log file sequential read
  Log file single write只会发生在打开或关闭一个Redo Log文件后,向文件头写入相关信息时。因为文件头的信息中包含了文件号,因此文件头信息不会并行写入多个文件,而是单独一个个写入,因而其等待时间不会被统计到log file parallel write之中。
  事件中的P1、P2、P3参数分别代表:
  P1:写入的Redo Log文件号;
  P2:写入的数据块号;
  P3:写入的数据块数。
  当进程从Redo Log文件中读取redo记录时会产生log file sequential read等待事件,如Arch进程读取Redo Log数据。
  事件中的P1、P2、P3参数分别代表:
  P1:读取的Redo Log文件号;
  P2:开始读取的数据块号;
  P3:读取的数据块数。
  当Redo Log文件存在IO问题时,以上两个等待事件通常都会和log file parallel write等待事件同时出现。因而可以通过在3.4.1中提到的提高Redo Log文件IO效率、减少Log文件IO冲突的方法来减少这两个等待。
  3.4.4 log file switch completion & switch logfile command & log file switch (clearing log file)
  当在产生Redo Log时需要等待LGWR切换Log文件时,会产生log file switch completion等待事件;而switch logfile command则是等待DBA手工执行的切换日志的命令:
  SQL> alter system switch logfile;
  System altered.
  日志切换由以下步骤组成:
  从控制文件获取下一日志文件的文件号;
  获取Redo Copy和Redo Allocation的Latch;
  清空Redo,将buffer中的Redo记录写入Log文件中去;
  关闭当前Redo Log文件;
  更新控制文件,包括:
  o 设置下一日志文件为当前日志文件;
  o 设置之前的日志文件为INACTIVE;
  o 如果在Archive模式下,将之前文件加到归档文件列中;
  o 打开新的日志文件组中的所有文件;
  o 将SCN写入文件头;
  o 打开允许产生Redo Log的开关。
  在等待上述的第三步时,则会产生log file switch (clearing log file) 等待事件。
  我们可以用以下语句查看当前的日志文件:
  SQL> select GROUP#, ARCHIVED, STATUS from v$log;
  GROUP# ARC STATUS
  ---------- --- ----------------
  1 NO INACTIVE
  3 NO INACTIVE
  2 NO CURRENT
  我们可以采取前述方法提高Redo Log文件IO效率来降低这三个等待事件。此外,我们还可以增大Log文件大小,降低日志切换频率(一般来说,在系统运行高峰期以20~30分钟切换一次为佳)。通过以下语句可以查询日志的切换记录及其切换间隔时间:
  SQL> SELECT to_char(b.first_time, 'YYYY-MM-DD HH24:MI:SS') as swtich_time,
  2 (b.first_time - a.first_time) * 24 as "switch_interval(hr)"
  3 FROM v$log_history a, v$log_history b
  4 WHERE a.SEQUENCE# + 1 = b.SEQUENCE#
  5 AND ROWNUM <= 10
  6 ORDER BY 1;
  SWTICH_TIME switch_interval(hr)
  ------------------- -------------------
  2007-08-25 00:28:59 2.3975
  2007-08-25 06:04:53 5.59833333
  2007-08-25 12:15:52 6.18305556
  2007-08-25 21:58:13 9.70583333
  2007-08-25 23:50:39 1.87388889
  2007-08-26 00:28:42 .634166667
  2007-08-26 08:32:04 8.05611111
  2007-08-26 17:58:05 9.43361111
  2007-08-26 23:26:57 5.48111111
  2007-08-27 07:21:35 7.91055556
  ... ...
  另外,从Alert日志中,我们也可以找到日志切换记录。
  ... ...
  Beginning log switch checkpoint up to RBA [0x18106.2.10], SCN: 0x0003.93b3fb7d
  Thread 1 advanced to log sequence 98566
  Current log# 7 seq# 98566 mem# 0: /export/home/icssprd/data/data02/icssprd_redo_07a.rdo
  Current log# 7 seq# 98566 mem# 1: /export/home/icssprd/data/data18/icssprd_redo_07b.rdo
  Mon May 28 12:35:14 2007
  ARC0: Evaluating archive log 2 thread 1 sequence 98565
  ARC0: Beginning to archive log 2 thread 1 sequence 98565
  Creating archive destination LOG_ARCHIVE_DEST_1: '/export/home/icssprd/admin/arch/1_98565.dbf'
  Mon May 28 12:36:47 2007
  Completed checkpoint up to RBA [0x18106.2.10], SCN: 0x0003.93b3fb7d
  Mon May 28 12:38:02 2007
  ARC0: Completed archiving log 2 thread 1 sequence 98565
  Mon May 28 12:41:26 2007
  Beginning log switch checkpoint up to RBA [0x18107.2.10], SCN: 0x0003.93b4a3a6
  Thread 1 advanced to log sequence 98567
  Current log# 8 seq# 98567 mem# 0: /export/home/icssprd/data/data10/icssprd_redo_08a.rdo
  ... ...
  3.4.5 log file switch (checkpoint incomplete)
  当在做日志切换时,同时会做checkpoint,如果此时有其他checkpoint正在进行时,需要等待正在进行的checkpoint完成,此时就会产生log file switch (checkpoint incomplete)等待事件。通常发生这一等待事件时,日志切换的时间都比平时更长。
  要降低该等待事件,就需要降低日志切换时引起的checkpoint遇上系统中其他checkpoint的几率。我们可以通过以下方法来进行调优:
  增加Redo Log文件的大小,使日志切换频率降低;
  增大参数Log_checkpoint_interval大小,该参数设置系统两次checkpoint之间Redo Log数据块(该数据块的大小由操作系统的数据块大小决定)的数量。但是Oracle会限制这些数据块总的大小要小于最小log文件的90%。如最小log文件大小为100M,操作系统的数据块大小为512K,则Log_checkpoint_interval要小于(100 * 90% / 0.5) = 180
  3.4.6 log switch/archive & log file switch (archiving needed)
  log switch/archive等待事件在会话等待所有Archive线程对当前log文件Archive操作完成。当LGWR进程切换日志时,如果要切入的日志还没有被Archive,需要等待其被完成Archive,这时会产生log file switch (archiving needed)等待事件。这时,在alert log中我们还能发现以下信息:
  Thread 1 cannot allocate new log, sequence 9556
  All online logs needed archiving
  这两个事件只有数据库在Archive模式下才会出现。说明Archive操作太慢。对这两个事件的调优主要是针对Archive设置的调优。
  要提高Archive的效率,可以采取以下方法:
  1) 调整Redo Log文件的个数和大小
  大多数情况下,Redo Log文件的个数越多、大小越大,就能让归档进程有更多时间做Archive。如果Redo记录急剧增加,可以考虑加多log文件数量,这样能使归档进程有更多时间均衡归档过程。但是,如果ARCH进程无法跟上LGWR进程的处理速度时,增加Log文件数量就于事无补了。
  2)调整checkpoint的间隔和效率
  增大checkpoint的间隔也可以使归档进程有更多时间来处理归档。增大参数log_checkpoint_interval可以增大checkpoint的间隔。另外,增加DBWR进程数量、配置AIO都可以提高checkpoint的处理效率。
  3)配置多ARCH进程
  通过参数log_archive_max_processes可以配置最大ARCH进程数量。我们可以做一个脚本来执行'alter system archive log all;'命令,然后设置一个作业以固定间隔时间来执行该脚本。这个命令可以强制归档所有未归档的日志文件。这可以帮助均衡ARCH进程的归档处理负担。
  4)调整Archive进程
  增加Archive进程的buffer大小可以提高Archive效率,其大小是由参数log_archive_buffer_size控制的。该参数的初始设置为4K,最大可以增加到128K。但是,要注意,增加该参数虽然可以提供Archive效率,但是可能会使系统的整体性能下降;
  另外,我们还可以通过增加Archive进程的buffer数量来提高Archive效率。Buffer数量由参数log_archive_buffer控制,最大为8.
  5)减少系统的IO冲突、提供系统IO效率
  系统整体的IO性能及冲突问题也会影响到Archive的效率。我们可以用前面介绍的方法来减少系统中存在的IO冲突、提高整体IO效率来提高Archive的效率。
3.5 Buffer Cache相关的IO事件
  Buffer Cache是影响Oracle IO的重要因素。这里要解决的几个等待事件都是涉及到DBWR进程和IO从属进程(Slave)的Buffer Cache操作引起的等待事件。
  3.5.1 db file parallel write
  该事件和并行DML无关。这个等待事件出现在当DBWR进程提交了多IO请求来并行将Buffer Cache中的脏数据写入磁盘中后,等待所有提交的IO请求完成。通常是由于操作系统的IO系统导致的该事件的阻滞。
  事件中的P1、P2、P3参数分别代表:
  P1:(9.2.0.5之前)写入数据的文件号/(9.2.0.5之后)请求次数;
  P2:(9.2.0.5之前)写入的数据块号/(9.2.0.5之后)请求中断的次数;
  P3:(9.2.0.5之前)请求次数/(9.2.0.5之后)请求发生了Timeout的时间
  这一等待事件一般不会显著影响用户会话。但是当用户会话中有很高的“write complete waits”或“free buffer waits”事件的等待时间时,说明该事件已经影响到了用户会话。有时候这一事件对操作系统IO的影响也会影响到进程从同一磁盘读取数据的等待时间。
  解决该事件的关键在于减少相关磁盘的IO冲突。如果这事件已经影响到用户会话,我们需要结合其他等待事件信息,考虑采取均衡热地磁盘负载、提高存储设备IO效率、增加checkpoint间隔、增大Redo log文件等方法来减低该事件。
  3.5.2 db file single write
  当DBWR进程请求修改数据文件头,在等待IO请求完成时,会出现db file single write等待事件。
  事件中的P1、P2、P3参数分别代表:
  P1:写入数据的文件号;
  P2:写入的数据块号;
  P3:写入的数据块数(一般为1)。
  解决这一等待事件的关键还是要处理好磁盘的IO冲突问题,特别是发生该事件所在的磁盘。通过相关SQL的调优等手段来降低事件发生的磁盘的IO、采用更高效率的存储设备、均衡磁盘IO负载等方法是降低这一等待事件的主要方法。
  3.5.3 write complete waits
  当会话对一个正在被写写入磁盘的Buffer数据块发出请求时,需要等待其被写入磁盘完成,这时就会产生write complete waits等待事件。
  事件中的P1、P2、P3参数分别代表:
  P1:要写入数据的文件号;
  P2:要写入的数据块号;
  P3:无意义
  提高Buffer Cache脏数据写入磁盘的效率、提高整体IO效率是降低该等待事件的主要方法:
  配置数据库支持AIO;
  增加db_writer_processes(支持AIO时)或者db_io_slaves(不支持AIO时)大小以增加DBWR进程;
  其他提高IO效率(如采用裸设备等)、减少IO冲突的方法
  3.5.4 free buffer waits
  当会话在Buffer Cache中找不到空闲buffer块,或者在没有空闲buffer块来建立一致性读时,就会产生free buffer waits等待事件。
  事件中的P1、P2、P3参数分别代表:
  P1:要读取数据的文件号;
  P2:要读取的数据块号;
  P3:10gR1之前无意义,10gR1后表示在Buffer Cache中LRU和LRUW列表的SET_ID#
  这一等待事件通常表示Buffer Cache不足或者从Buffer Cache中将脏数据写入磁盘的效率太低。要降低该等待事件,我们就需要分别从这两方面入手:调整Buffer Cache的大小(如根据statspack的建议器来设置);按照我们前述的方法来提高存储设备的IO效率。
  4 结束语
  最后要说的是,一旦数据库服务器出现了IO问题后,首先要检查操作系统本身的IO系统是否有问题,然后再确认是否是Oracle出现了IO问题。
  其次要注意的一点是,上述等待事件在系统出现一定的等待次数对于系统来说是正常的,我们要解决的是对系统IO影响最大的一个或几个等待事件,而不是全部事件。
  总的来说,要调整Oracle中出现的IO性能问题,我们有两种手段:一种是针对特定等待事件的相应方法,如相关SQL语句的调优、相关参数的修改;另外一种是通过提升整体IO效率、减少IO冲突来降低IO等待,如均衡IO负载、使用效率更高的存储设备、激活AIO和重新分布对IO有不同要求的文件。
  事实上,数据库的性能问题大多数是由应用引起的,而其中大部分问题都是Top SQL造成。因此,这里要说的一句题外话就是:SQL调优是每一个DBA必须具备的最基本的技能。因为很多时候无论采用什么手段、什么工具来定位问题,通过各种内部机制来分析问题,但最终解决问题的手段就是SQL调优。
  5 参考文章
  1、 www.HelloDBA.com
  2、 Metalink.Oracle.com
  3、 Oracle OTN
  4、 Oracle Concept
  5、 Oracle Database Performance Tuning Guide
 

引文来源  Oracle IO问题解析-性能调优-Oracle频道-中国IT实验室
  评论这张
 
阅读(702)| 评论(0)

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018