在Oracle中如何调整 IO 相关的等待.docx
- 文档编号:30668335
- 上传时间:2023-08-19
- 格式:DOCX
- 页数:27
- 大小:31.04KB
在Oracle中如何调整 IO 相关的等待.docx
《在Oracle中如何调整 IO 相关的等待.docx》由会员分享,可在线阅读,更多相关《在Oracle中如何调整 IO 相关的等待.docx(27页珍藏版)》请在冰豆网上搜索。
在Oracle中如何调整IO相关的等待
在Oracle中如何调整I/O相关的等待【转】
本文主要介绍的是在出现了I/O竞争等待的时候如何去优化Oracle数据库。
对Oracle数据库进行调整优化,基本上最终都可以归结到I/O调整上,因此,了解如何来优化Oracle数据库的I/O对于一个DBA来说就显得至关重要了。
一、 Oracle数据库I/O相关竞争等待简介
当Oracle数据库出现I/O相关的竞争等待的时候,一般来说都会引起Oracle数据库的性能低下,发现数据库存在I/O相关的竞争等待一般可以通过以下的三种方法来查看Oracle数据库是否存在I/O相关的竞争等待:
Ø Statpack报告中在"Top5WaitEvents"部分中主要都是I/O相关的等待事件。
Ø 数据库的等待事件的SQL语句跟踪中主要都是I/O相关的等待事件的限制。
Ø 操作系统工具显示存储数据库文件的存储磁盘有非常高的利用率。
数据库如果发现存在I/O竞争,那我们就必须要通过各种方法来调整优化Oracle数据库。
在调优数据库的过程中,其中一个重要的步骤就是对响应时间的分析,看看数据库消耗的时间究竟是消耗在具体什么上面了。
对于Oracle数据库来说,响应时间的分析可以用下面公式来计算:
ResponseTime=ServiceTime+WaitTime
ServiceTime是指'CPUusedbythissession'的统计时间。
WaitTime是指所有消耗在等待事件上的总的时间。
如果我们使用性能调整的工具(如statpack)来调整数据库的时候,评测的则是所有响应时间中各个部分的相对影响,并且应该根据消耗的时间的多少来调整影响最严重的部分。
因为等待事件有很多,因此我们还需要去判定哪些是真的很重要的等待事件,很多调优工具比如说statpack都是列出最重要的等待事件,statpack工具的报告中的重要的等待事件都是包含在一个叫Top5WaitEvents的部分中。
因为这些工具都已经把重要的等待事件全部列出来了,因此就很容易的处理这些已经列出来的等待事件而不必再去首先评估所有响应时间的影响。
在某些情况下,ServiceTime会比WaitTime显得更加重要(例如CPU使用率),此时等待事件产生的影响就显得不是那么重要了,重点调整的目标应该放在ServiceTime上。
因此,我们应该先比较在Top5WaitEvents部分中的'CPUusedbythissession'所占用的时间,然后直接调整最消耗时间的等待事件。
在Oracle9i的release2的版本以后,Top5WaitEvents部分变成了Top5TimedEvents,ServiceTime也由'CPUusedbythissession'变成了'CPUtime'来衡量,这也就意味着可以更加精确的判断在响应时间中的等待事件的影响,从而调整最需要优化的部分。
下面举一个例子来具体说明为什么在调整数据库性能的时候必须同时查看ServiceTime和WaitTime,因为如果不同时都查看这两个方面,就往往容易走入调整的误区。
Top5WaitEvents~~~~~~~~~~~~~~~~~Wait%TotalEventWaitsTime(cs)WtTime---------------------------------------------------------------------------directpathread9,59015,54686.10dbfilescatteredread6,1051,2626.99latchfree2,0361,0475.80logfilesync107131.73
dbfileparallelwrite4069.38
上面是一个大约30分钟的statpack收集的信息的Top5WaitEvents部分,如果基于上面给出的列表,我们很容易发现directpathread的wait很高,并且会试图去调整这个等待事件,但是这样做就没有考虑到ServiceTime。
我们来看看在这个statpack中关于ServiceTime的统计:
StatisticTotalperSecondperTrans-------------------------------------------------------------------------CPUusedbythissession429,648238.7257.4
让我们来大致的计算一下响应时间:
'WaitTime'=15,546x100%/86.10%=18,056cs
'ServiceTime'=429,648cs
'ResponseTime'=429,648+18,056=44,7704cs
接着来计算一下响应时间中各个部分的比例:
CPUtime=95.97%
directpathread=3.47%
dbfilescatteredread=0.28%
latchfree=0.23%
logfilesync=0.03%
dbfileparallelwrite=0.02%
从上面的计算中我们可以明显的看出来,I/O相关的等待事件所消耗的时间在整个响应时间中占的比例并不大,只不过是很小的一部分,而相对来说ServiceTime所消耗的时间远远大于WaitTime,因此,应该直接调整的是ServiceTime(CPU的使用率)而不是I/O相关的等待事件,因此,在调优数据库的时候要尽量的避免走入这种误区。
二、 Oracle数据库I/O相关竞争等待的处理方法
接着来具体看看对于出现的I/O问题处理的一些方法。
在使用了statpack这类的工具分析了数据库的响应时间后,如果数据库的性能主要是被一些I/O相关的等待事件所限制住了,那么可以针对这种情况可以采用处理I/O问题的一些方法,下面对这些方法的一些概念和基本原理进行简单的阐述说明。
方法一:
优化Oracle数据库的SQL语句来减少数据库对I/O的需求:
如果数据库没有任何用户的SQL运行的话,一般来说只会产生很少的磁盘I/O或者几乎没有磁盘I/O,基本上来说数据库产生I/O的最终原因都是直接或者间接的由于用户执行SQL语句导致的。
这也就意味着我们可以控制单个SQL语句避免其产生大量的I/O来减少整个数据库对磁盘I/O的需求,通过优化SQL语句改变其执行计划以便让其产生尽可能少的I/O。
一般典型的存在问题的情况仅仅只是很少的几个SQL语句,但是由于其相应的执行计划不理想,会导致产生大量的物理磁盘I/O,从而使得整个数据库的性能非常之差。
因此,让用户执行的SQL语句优化产生比较好的执行计划来减少磁盘I/O是一种非常行之有效的方法。
方法二:
调整实例的初始化参数来减少数据库的I/O需求:
一般来说可以通过两种途径:
一种途径是通过内存缓存来减少I/O。
数据库的I/O分为两种,一种是实际读取了数据文件的物理I/O,一种是从缓存中读取数据的逻辑I/O,可以通过使用一定数量的内存缓存来减少物理I/O(例如高速缓存区、日志缓存区以及各种排序区等等)。
适当的增大高速缓存区,可以有更多的缓存供给数据库的进程使用,从缓存中读取所需要的数据,这样产生的I/O都是逻辑I/O,而不是直接从物理磁盘上读取数据,减少了物理I/O的产生。
设置一个适当的排序区,可以减少在排序操作中读取临时表空间数据文件所在磁盘的次数,而尽可能多的使用缓存中的排序区来排序。
其他的缓存区的工作原理基本都是一致的,都是通过使用缓存来减少读取物理磁盘的次数来降低I/O。
另外一种途径是调整一次读取多个BLOCK的大小,单独的一次多个BLOCK读取的操作的大小是由实例的初始化参数db_file_multiblock_read_count来控制的。
如果执行比较大的I/O操作,一次读取的多个BLOCK大小越大,所需要的时间就会越短。
例如:
操作系统的一次能够传输的最大I/O大小是8M,一次性请求传输50M的数据会比请求5次每次只是请求1M的速度快的多。
但是,当一次读取的多个BLOCK的大小超过了操作系统一次能够传输的最大的I/O大小,这个差别就基本不明显了。
如一次性传输100M和一次性传输1G的大小在时间上基本上没有什么差别了,效率差不多了。
因为整个I/O的所消耗的时间分为I/OSetupTime和I/OTransferTime两个主要部分,I/OSetupTime可以看成是I/O的寻道所消耗的时间,I/OTransferTime可以看成是I/O传输所消耗的时间。
当一次读取的多个BLOCK的大小比较小的时候,读取的一定数量的BLOCK就使得读取次数就会比较多,每次I/O读取都要先寻道,并且寻道时间在这个时候所用的时间会占到整个I/O完成时间的绝大部分,导致整个I/O完成所消耗的时间也就会比较多了。
而I/O传输一定数量的BLOCK的时间相对固定,不管传输的次数多少,基本上变化不大,因此影响I/O读取时间长短的主要就是取决于I/OSetupTime所花费的时间。
因此,在配置数据库初始化参数的时候,根据操作系统的I/O吞吐能力都会设置的一次读取多个BLOCK的大小尽量多,以减少读取I/O的次数。
方法三:
在操作系统级别上优化I/O:
在操作系统级别上优化磁盘的I/O,以提高I/O的吞吐量,如果操作系统支持异步I/O,尽量去使用异步I/O;还可以使用高级文件系统的一些特性,例如直接I/O读取,忽略掉操作系统的文件缓存,也就是我们平时所说的使用裸设备。
还有一种可行的方法是增大每次传输的最大I/O大小的限制,以便每次能够传输的I/O尽可能的大。
方法四:
通过使用RAID、SAN、NAS来平衡数据库的I/O:
RAID是RedundentArrayofIndependentDisks的缩写,直译为"廉价冗余磁盘阵列",也简称为"磁盘阵列"。
RAID的优点是传输速率高并且可以提供容错功能。
在RAID中,可以让很多磁盘驱动器同时传输数据,而这些磁盘驱动器在逻辑上又是一个磁盘驱动器,所以使用RAID可以达到单个磁盘驱动器几倍、几十倍甚至上百倍的速率。
因为普通磁盘驱动器无法提供容错功能,如果不包括写在磁盘上的CRC(循环冗余校验)码的话。
RAID容错是建立在每个磁盘驱动器的硬件容错功能之上的,所以它提供更高的安全性。
RAID分为以下几个级别:
Ø RAID0:
RAID0并不是真正的RAID结构,没有数据冗余.RAID0连续地分割数据并并行地读/写于多个磁盘上.因此具有很高的数据传输率.但RAID0在提高性能的同时,并没有提供数据可靠性,如果一个磁盘失效,将影响整个数据.因此RAID0不可应用于需要数据高可用性的关键应用。
Ø RAID1:
RAID1通过数据镜像实现数据冗余,在两对分离的磁盘上产生互为备份的数据.RAID1可以提高读的性能,当原始数据繁忙时,可直接从镜像拷贝中读取数据.RAID1是磁盘阵列中费用最高的,但提供了最高的数据可用率.当一个磁盘失效,系统可以自动地交换到镜像磁盘上,而不需要重组失效的数据。
Ø RAID2:
从概念上讲,RAID2同RAID3类似,两者都是将数据条块化分布于不同的硬盘上,条块单位为位或字节.然而RAID2使用称为"加重平均纠错码"的编码技术来提供错误检查及恢复.这种编码技术需要多个磁盘存放检查及恢复信息,使得RAID2技术实施更复杂.因此,在商业环境中很少使用。
Ø RAID3:
不同于RAID2,RAID3使用单块磁盘存放奇偶校验信息.如果一块磁盘失效,奇偶盘及其他数据盘可以重新产生数据.如果奇偶盘失效,则不影响数据使用.RAID3对于大量的连续数据可提供很好的传输率,但对于随机数据,奇偶盘会成为写操作的瓶颈。
Ø RAID4:
同RAID2,RAID3一样,RAID4,RAID5也同样将数据条块化并分布于不同的磁盘上,但条块单位为块或记录.RAID4使用一块磁盘作为奇偶校验盘,每次写操作都需要访问奇偶盘,成为写操作的瓶颈.在商业应用中很少使用。
Ø RAID5:
RAID5没有单独指定的奇偶盘,而是交叉地存取数据及奇偶校验信息于所有磁盘上.在RAID5上,读/写指针可同时对阵列设备进行操作,提供了更高的数据流量.RAID5更适合于小数据块,随机读写的数据.RAID3与RAID5相比,重要的区别在于RAID3每进行一次数据传输,需涉及到所有的阵列盘.而对于RAID5来说,大部分数据传输只对一块磁盘操作,可进行并行操作.在RAID5中有"写损失",即每一次写操作,将产生四个实际的读/写操作,其中两次读旧的数据及奇偶信息,两次写新的数据及奇偶信息。
Ø RAID6:
RAID6与RAID5相比,增加了第二个独立的奇偶校验信息块.两个独立的奇偶系统使用不同的算法,数据的可靠性非常高.即使两块磁盘同时失效,也不会影响数据的使用.但需要分配给奇偶校验信息更大的磁盘空间,相对于RAID5有更大的"写损失".RAID6的写性能非常差,较差的性能和复杂的实施使得RAID6很少使用。
SAN(StorageAreaNetwork,存储局域网)是独立于服务器网络系统之外几乎拥有无限存储能力的高速存储网络,这种网络采用高速的光纤通道作为传输媒体,以FC(FiberChannel,光通道)+SCSI(SmallComputerSystemInterface,小型计算机系统接口)的应用协议作为存储访问协议,将存储子系统网络化,实现了真正高速共享存储的目标。
一个完整的SAN包括:
支持SAN的主机设备,支持SAN的储存设备,用于连接SAN的连接设备,支持SAN的管理软件,支持SAN的服务。
网络附加存储设备(NetworkAttachedStorage,NAS)是一种专业的网络文件存储及文件备份设备,或称为网络直联存储设备、网络磁盘阵列。
NAS是基于LAN的,按照TCP/IP协议进行通信,面向消息传递,以文件的I/O方式进行数据传输。
在LAN环境下,NAS已经完全可以实现异构平台之间的数据级共享,比如NT、UNIX等平台的共享。
一个NAS包括处理器,文件服务管理模块和多个的硬盘驱动器用于数据的存储。
NAS可以应用在任何的网络环境当中。
主服务器和客户端可以非常方便地在NAS上存取任意格式的文件,包括SMB格式(Windows)NFS格式(Unix,Linux)和CIFS格式等等。
NAS系统可以根据服务器或者客户端计算机发出的指令完成对内在文件的管理。
NAS是在RAID的基础上增加了存储操作系统,因此,NAS的数据能由异类平台共享。
因此,利用RAID、SAN、NAS的技术在多个物理磁盘之间平衡数据库的I/O,尽量避免数据库产生I/O竞争的瓶颈。
方法五:
手工分配数据文件到不同的文件系统、控制器和物理设备来重新调整数据库I/O:
如果数据库目前的存储设备不算太好,那么采用这种方法是一个不错的选择。
这样可以让所有的磁盘得到充分的利用,不至于出现某些磁盘的I/O过于太高,而某些磁盘就根本没有被使用的情况,使得在配置较低的情况下得到一个比较好的数据库性能。
需要注意的一点是对于大部分数据库来说,一些I/O是一直会存在的。
如果上述的方法都尝试过但是数据库的I/O性能还是没有达到预定的要求,可以尝试删除数据库中一些不用的旧数据或者使用性能更好的硬件设施。
三、 Oracle数据库I/O相关的等待事件的介绍和相应的解决方法
下面是总结的在Oracle数据库中最经常出现的一些I/O相关的等待事件:
数据文件I/O相关的等待事件:
Ø dbfilesequentialread
Ø dbfilescatteredread
Ø dbfileparallelread
Ø directpathread
Ø directpathwrite
Ø directpathread(lob)
Ø directpathwrite(lob)
控制文件I/O相关的等待事件:
Ø controlfileparallelwrite
Ø controlfilesequentialread
Ø controlfilesinglewrite
重做日志文件I/O相关的等待事件:
Ø logfileparallelwrite
Ø logfilesync
Ø logfilesequentialread
Ø logfilesinglewrite
Ø switchlogfilecommand
Ø logfileswitchcompletion
Ø logfileswitch(clearinglogfile)
Ø logfileswitch(checkpointincomplete)
Ø logswitch/archive
Ø logfileswitch(archivingneeded)
高速缓存区I/O相关的等待事件:
Ø dbfileparallelwrite
Ø dbfilesinglewrite
Ø writecompletewaits
Ø freebufferwaits
下面来对这些I/O相关的等待事件进行具体的说明和相应的处理方法。
数据文件相关的I/O等待事件:
Ø dbfilesequentialread等待事件:
这个是非常常见的I/O相关的等待事件。
在大多数的情况下读取一个索引数据的BLOCK或者通过索引读取数据的一个BLOCK的时候都会去要读取相应的数据文件头的BLOCK。
在早期的版本中会从磁盘中的排序段读取多个BLOCK到高速缓存区的连续的缓存中。
在V$SESSION_WAIT这个视图里面,这个等待事件有三个参数P1、P2、P3,其中P1代表Oracle要读取的文件的ABSOLUTE文件号,P2代表Oracle从这个文件中开始读取的BLOCK号,P3代表Oracle从这个文件开始读取的BLOCK号后读取的BLOCK数量,通常这个值为1,表明是单个BLOCK被读取,如果这个值大于1,则是读取了多个BLOCK,这种多BLOCK读取常常出现在早期的Oracle版本中从临时段中读取数据的时候。
如果这个等待事件在整个等待时间中占主要的部分,可以采用以下的几种方法来调整数据库。
方法一:
从statpack的报告中的"SQLorderedbyReads"部分或者从V$SQL视图中找出读取物理磁盘I/O最多的几个SQL语句,优化这些SQL语句以减少对I/O的读取需求。
如果有IndexRangescans,但是却使用了不该用的索引,就会导致访问更多的BLOCK,这个时候应该强迫使用一个可选择的索引,使访问同样的数据尽可能的少的访问索引块,减少物理I/O的读取;如果索引的碎片比较多,那么每个BLOCK存储的索引数据就比较少,这样需要访问的BLOCK就多,这个时候一般来说最好把索引rebuild,减少索引的碎片;如果被使用的索引存在一个很大的ClusteringFactor,那么对于每个索引BLOCK获取相应的记录的时候就要访问更多表的BLOCK,这个时候可以使用特殊的索引列排序来重建表的所有记录,这样可以大大的减少ClusteringFactor,例如:
一个表有A,B,C,D,E五个列,索引建立在A,C上,这样可以使用如下语句来重建表:
CREATETABLETABLE_NAMEASSELECT*FROMoldORDERBYA,C;
此外,还可以通过使用分区索引来减少索引BLOCK和表BLOCK的读取。
方法二:
如果不存在有问题的执行计划导致读取过多的物理I/O的特殊SQL语句,那么可能存在以下的情况:
数据文件所在的磁盘存在大量的活动,导致其I/O性能很差。
这种情况下可以通过查看Statpack报告中的"FileI/OStatistics"部分或者V$FILESTAT视图找出热点的磁盘,然后将在这些磁盘上的数据文件移动到那些使用了条带集、RAID等能实现I/O负载均衡的磁盘上去。
使用如下的查询语句可以得到各个数据文件的I/O分布:
selectd.namename,f.phyrds,f.phyblkrd,f.phywrts,f.phyblkwrt,f.readtim,f.writetimfromv$filestatf,v$datafiledwheref.file#=d.file#orderbyf.phyrdsdesc,f.phywrtsdesc;
从Oracle9.2.0开始,我们可以从V$SEGMENT_STATISTICS视图中找出物理读取最多的索引段或者是表段,通过查看这些数据,可以清楚详细的看到这些段是否可以使用重建或者分区的方法来减少所使用的I/O。
如果Statpack设置的level为7就会在报告中产生"SegmentStatistics"的信息。
SQL>selectdistinctstatistic_namefromv$segment_statistics;
STATISTIC_NAME
----------------------------------------------------------------
ITLwaits
bufferbusywaits
dbblockchanges
globalcachecrblocksserved
globalcachecurrentblocksserved
logicalreads
physicalreads
physicalreadsdirect
physicalwrites
physicalwritesdirect
rowlockwaits
11rowsselected.
从上面的查询可以看到相应的统计名称,使用下面的查询语句就能得到读取物理I/O最多的段:
selectobject_name,object_type,statistic_name,value
fromv$segment_statistics
wherestatistic_name='physicalreads'
orderbyvaluedesc;
方法三:
如果不存在有问题的执行计划导致读取过多的物理I/O的特殊SQL语句,磁盘的I/O也分布的很均匀,这种时候我们可以考虑增大的高速缓存区。
对于Oracle8i来说增大初始化参数DB_BLOCK_BUFFERS,让Statpack中的BufferCache的命中率达到一个满意值;对于Oracle9i来说则可以使用BufferCacheAdvisory工具来调整BufferCache;对于热点的段可以使用多缓冲池,将热点的索引和表放入到KEEPBuffer
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 在Oracle中如何调整 IO 相关的等待 Oracle 如何 调整 相关 等待