oracle 增加 dbwr 性能,读书笔记-高级owi与oracle性能调整-io

db file scattered read

oracle在执行全表扫描或全索引扫描时,为保障性能,尽量一次性读取多个块,这称为multi block i/o.每次执行multi block i/o,都会等待物理i/o结束,此时等待db file scattered read事件.

解决办法:

(1)需要筛选出主要发生db file scattered read等待的sql语句.如果不必要地执行fts或index full scan,修改sql语句或创建更合理的索引就可以解决.

(2)如果高速缓冲区过小,就会反复需要物理i/o,相应地db file scattered read等待也会增加.这时free buffer waits等待事件一同出现的几率较高.也可以使用多重缓冲池解决.

(3)需要检查,通过合理执行partitioning能否减少fts范围.

(4)如果利用sql的优化或高速缓冲区的优化也不能解决问题,就应该怀疑i/o系统本身的性能.

db file sequential read

每次发生single block i/o时,就会发生一次db file sequential read事件的等待.一般在索引扫描,通过rowid的表扫描,读取控制

文件和文件头时发生.

db file sequential read等待使用性能出现问题,这些性能问题大多数发生在低效的索引扫描,行迁移,行链接引发附加的i/o过程中.

解决办法:

(1)使用选择性较差的索引是发生db file sequential

read等待的主要原因.使用不当的索引不仅引发i/o争用,而且还可能引发高速缓冲区的争用.只需将sql语句优化,有效使用索引,就能防患于未然.总

是拥有最新的统计信息,也是相当重要的,利用dbms_stats程序包,可以对数据库内的所有对象以最优的方式更新统计信息.

(2)如果高速缓冲区过小,就会反复发生物理i/o,因此可能增加db file sequential read等待,这时同时发生free

buffer waits等待的概率较高.即使恰当创建了索引,db file sequential

read等待依然比期待时间长,就需要考虑clustering factor是否过高?行迁移或行链接是否过多发生?

消除行迁移的方法:a.先导出再导入b.执行alter table xxx move...c.利用执行analyze table xxx list chained rows into yyy

筛选发生迁移的行,对于该行执行删除后插入.

(3)若sql优化或高速缓冲区优化,重建表也不能解决问题,就应该怀疑i/o系统本身的性能.

direct path read

direct path read事件的等待是在执行parallel query时,slave session所执行的direct path i/o引发的.

在如下方面寻找调优点:

(1)提高parallel query本身性能.执行parallel query过程中的direct path read等待是必然的,调优这个等待事件本身是不可能的,而通过对sql进行调优,改善parallel query本身性能是恰当的解决方式.

(2)提高i/o系统本身的性能.

direct path write

direct path write等待意味着发生了direct load工作(ctas,insert /*+append*/等).这些工作请求时,oracle将不经过sga

在数据文件上执行直接写入工作.

特点:

(1)不经过sga,在数据文件上执行直接写入

(2)在hwm这后添加块,即,不使用空闲列或位图块上管理空闲块.

(3)对于添加的数据不创建回滚段(只是ctas时,创建对于数据字典修改的撤销)

(4)表里有nologging选项时,不生成重做记录

(5)对于表以exclusive模式获得tm锁,因此不允许其它会话上的dml

如果合理使用direct

load操作,就可以快速创建大量数据.能过并行执行direct模式和parallel模式,可将性能进一步最优化.如果是direct模式,数据将被

直接写入到表的段,但是与parallel模式并行时,暂时直接写入到表所属的永久表空间内的临时段后,在所有的工作成结束之后再合并到表段上.

direct path read temp/direct path write temp

为了排序工作在临时区域读写时,等待direct path read temp/direct path write

temp事件.这个等待事件是从oracle 10g起被分类的,oracle 9i为止是通过direct path read,direct

path write等待观察的.排序段上的direct path

i/o是在需要排序的数据比为排序所分配的pga内存区大时发生的.因此在排序工作时若大量发生direct path read

temp,direct path wirte tmep等待,就可以通过追加内存区域而避免等待.

解决办法:

(1)检查需要排序的sql语句是否已经最优化.不必要的排序操作会导致cpu浪费,pga区域浪费,磁盘i/o浪费.从union和union all的性能差异上可以得知,只靠减少不必要的排序操作,也能解决许多问题.

(2)pga拥有为执行排序,hash join,位图运算等的内存区域,这称为工作区(work

area).从v$sesstat视图查看session pga memory

max值,可以坦到实际使用的最大内存区域.适当设定pga_aggregate_target值时,direct path

i/o将消失,因此direct

path read temp,direct path write temp等待现象完全消失.

direct path read(lob)/direct path write(lob)

如果创建lob列时使用nocache选项,读写lob段的工作就使用direct path i/o,这时等待direct path read(lob),direct path write

(lob)事件.使用cache选项创建lob列时因为经过高速缓冲区,所以应用与一般数据相同的机制.

创建lob时,在cache和nocache中使用哪个选项,是根据系统和数据的特点决定的.如果sga没有剩余空间或lob数据较大,则使用nocache比较有利.如果lob数据不大,而且经常访问的范围固定,则通过使用cache选项可得到性能改善的效果.

创建lob时应该注意如下事项:

(1)使用enable storage in row选项时,比4000 bytes小的lob数据与行一起存储在相同的块,因此引发行链接的可能性高.使用比4000 bytes大的lob数据与使用disable storage in

row选项时具有相同结果.考虑到lob数据的大小,如果被判断为发生行链接的可能性高,最好使用disable storage inrow选项.存储在与行相同块里的lob数据称为in-line lob,存储在Lob段时称为out-of-line lob.

(2)使用disable storage in row时,lob数据存于另外的Lob段,行内只存储20

bytes大小的lob地址信息.这时回滚数据只对lob定位创建.lob数据的实际撤销信息不是存于撤销表空间上,而是存于lob段内.lob段的回滚

段被pctversion选项所控制.例如pctversion为50,lob段的空间中50%用于存储撤销信息.pctversion过小,则发生错误

ora-01555的概率高,pctversion过大,则浪费空间加深.

(3)cache/nocache,logging/nologging:如果lob数据大,且不经常被访问或随机被访问,就应该使用nocache选

项.使用nocache选项时,可以指定创建重做与否.如果不是必须恢复的数据,就可以使用nologging选项,因此能获得性能改善的效果.使用

cache选项时必须要拥有logging属性.

(4)chunk的大小

ut-of-line

lob时,就以chunk为单位存储lob数据.使用较大的chunk问题在于发生空间浪费的可能性高.如果chunk原来是8k,插入1k大小的lob

数据,则余下7k空间可能无法使用.所以决定chunk大小时,应该考虑lob数据的大小后再作决定.chunk大小的单位基本上块大小的整数倍.

db file parallel write

经过高速缓冲区的所有数据是通过dbwr写入到磁盘上的.dbwr请求写入脏块的i/o后,在此工作结束期间等待db file parallel write

事件.

发生的原因和解决办法:

(1)i/o系统的性能缓慢时.如果dbwr进程上db file paralle

write等待时间表现得过长,就可以判断为i/o系统上有问题.如果dbwr上的db file paralle

write等待时间延长,服务器进程就会接连经历free buffer waits事件或write complete waits事件的等待.

通过改善i/o系统解决,改善i/o性能的方法如下:

a.组合使用裸设备和异步i/o是目前为止蝗最好方法.

b.os级上使用direct i/o.若cpu数量充足,可以调整db_writer_processes参数值,将dbwr数量增加.多个dbwr具有模拟异常的效果.

oracle推荐的dbwr进程是cpu_count/8.利用v$filestat视图,可以间接推断是哪些文件上主要发生性能问题的.

(2)i/o工作过多时.频繁发生检查点时,dbwr的活动量过多,可能导致dbwr的性能降低.fast_start_mttr_target参数值设定过小时,

将频繁发生增量检查点工作.日志文件过小时,日志文件切换频繁,查检点工作将增加.因parallel query发生direct path read时,在truncate,drop,host backup时也发生检查点.

(3)不能有效使用高速缓冲区时.间接改善dbwr性能的另一种方法是合理使用多重缓冲池.

db file parallel read

在进行数据库恢复操作期间,当作为恢复的一部份而需要更改的数据库块从数据文件中并行读取时产生该事件.当一个进程从一个或多个数据文件读取多个非连续的单独数据块时也产生该事件.

control file parallel write

控制文件具有如下信息:

the database name

the timestamp of database createion

the names and locations of associated datafiles and redo logfiles

tablespace information

datfile offline ranges

the log history

archived log information

backup set and backup piece information

backup datafile and redo log information

datafile copy information

the current log sequence number

checkpoint information

以下情况可能发生与控制文件相关的争用:

(1)日志文件切换经常发生时.每当发生日志文件切换时,需要对控制文件进行更新.

(2)检查点经常发生时,mttr设定得过乱咬或频繁发生人为的检查点时.

(3)nologging引起频繁的数据文件修改时,为了修改unrecoverable scn需要更新控制文件.对于利用nologging选项创建的lob数据进行修改是代表性的例子.

(4)i/o系统的性能缓慢时.最好是将控制文件位于独产的磁盘空间上,使用裸设备或direct i/o.若控制文件的数量过多时,最好是只保管恢复所需的最少量的控制文件.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28539951/viewspace-1264952/，如需转载，请注明出处，否则将追究法律责任。