db file async I/O submit等待事件的故障诊断

1

2

3

4

朋友公司一个erp系统业务办理不了,但从前台等待事件来看 DB CPU占了%DB time的91.81%,这个awr报告采样时间是两个小时,总的DB time是810分种服务器显示有24个逻辑CPU,每个CPU的耗时是33.75分钟,CPU的使用率也不是很高,那么我们来看一下后台等待事件。

5
后台等待事件排在第一的是 db file async I/O submit,这是一个异步IO相关的等待事件,而LNS wait on SENDREQ,LGWR-LNS wait on channel是与DG相关的日志传输相关的等待事件。这里的操作系统是Linux,而根据Doc ID 1274737.1文档描述,当disk_asynch_io=true时,而filesystemio_options=none,那么正常的文件系统在Linux系统支持异步I/O的情况下Oracle也不能使用异常I/O。

我们先来检查一下Linux系统中是否执行过异步I/O操作

[oracle@ErpOracle01 ~]$ cat /proc/slabinfo | grep kio
kioctx               376    640    384   10    1 : tunables   54   27    8 : slabdata     64     64      2
kiocb                  0      0    256   15    1 : tunables  120   60    8 : slabdata      0      0      0

可以看到kiocb的前两列为0说明没有执行异步I/O操作,用于存储Oracle数据文件的就是正常的文件系统

[root@ErpOracle01 ~]# fdisk -l

Disk /dev/sda: 598.9 GB, 598879502336 bytes
255 heads, 63 sectors/track, 72809 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000a66fb

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         131     1048576   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2             131        8486    67108864   82  Linux swap / Solaris
/dev/sda3            8486       72810   516684800   83  Linux

在这种情况下要让Oracle使用异步I/O将参数filesystemio_options设置为’asynch’。

SQL> show parameter disk_asynch_io

NAME                                 TYPE                               VALUE
------------------------------------ ---------------------------------  ------------------------------
disk_asynch_io                       boolean                            TRUE

SQL> show parameter filesystemio_options

NAME                                 TYPE                               VALUE
------------------------------------ ---------------------------------  ------------------------------
filesystemio_options                 string                             none
SQL> alter system set  filesystemio_options='asynch' scope=spfile;

System altered.

LNS wait on SENDREQ是DG的RFS I/O时间和网络时间的总计,而它可能是由网络带宽或备库的I/O性能引起的。而这经确认是备库的I/O性能引起的,再加上在这期间后台维护人员在主库做大批量的数据更新。在主库中出现了Log file sync和log file parallel write等待事件。LGWR-LNS wait on channel等待事件是日志写进程或网络服务器进程在KSR通道上等待接受消息所花的时间.LNS wait on SENDREQ, Log file sync, log file parallel write, LGWR-LNS wait on channel通过调整备库I/O性能和对主库增加online and standby redo logs来改善。然后在中午休息时间重启了数据库,经过三天的运行,业务没有出现办理不了的情况了。

1

2

3

4

朋友公司一个erp系统业务办理不了,但从前台等待事件来看 DB CPU占了%DB time的91.81%,这个awr报告采样时间是两个小时,总的DB time是810分种服务器显示有24个逻辑CPU,每个CPU的耗时是33.75分钟,CPU的使用率也不是很高,那么我们来看一下后台等待事件。

5
后台等待事件排在第一的是 db file async I/O submit,这是一个异步IO相关的等待事件,而LNS wait on SENDREQ,LGWR-LNS wait on channel是与DG相关的日志传输相关的等待事件。这里的操作系统是Linux,而根据Doc ID 1274737.1文档描述,当disk_asynch_io=true时,而filesystemio_options=none,那么正常的文件系统在Linux系统支持异步I/O的情况下Oracle也不能使用异常I/O。

我们先来检查一下Linux系统中是否执行过异步I/O操作

[oracle@ErpOracle01 ~]$ cat /proc/slabinfo | grep kio
kioctx               376    640    384   10    1 : tunables   54   27    8 : slabdata     64     64      2
kiocb                  0      0    256   15    1 : tunables  120   60    8 : slabdata      0      0      0

可以看到kiocb的前两列为0说明没有执行异步I/O操作,用于存储Oracle数据文件的就是正常的文件系统

[root@ErpOracle01 ~]# fdisk -l

Disk /dev/sda: 598.9 GB, 598879502336 bytes
255 heads, 63 sectors/track, 72809 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000a66fb

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         131     1048576   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2             131        8486    67108864   82  Linux swap / Solaris
/dev/sda3            8486       72810   516684800   83  Linux

在这种情况下要让Oracle使用异步I/O将参数filesystemio_options设置为’asynch’。

SQL> show parameter disk_asynch_io

NAME                                 TYPE                               VALUE
------------------------------------ ---------------------------------  ------------------------------
disk_asynch_io                       boolean                            TRUE

SQL> show parameter filesystemio_options

NAME                                 TYPE                               VALUE
------------------------------------ ---------------------------------  ------------------------------
filesystemio_options                 string                             none
SQL> alter system set  filesystemio_options='asynch' scope=spfile;

System altered.

LNS wait on SENDREQ是DG的RFS I/O时间和网络时间的总计,而它可能是由网络带宽或备库的I/O性能引起的。而这经确认是备库的I/O性能引起的,再加上在这期间后台维护人员在主库做大批量的数据更新。在主库中出现了Log file sync和log file parallel write等待事件。LGWR-LNS wait on channel等待事件是日志写进程或网络服务器进程在KSR通道上等待接受消息所花的时间.LNS wait on SENDREQ, Log file sync, log file parallel write, LGWR-LNS wait on channel通过调整备库I/O性能和对主库增加online and standby redo logs来改善。然后在中午休息时间重启了数据库,经过三天的运行,业务没有出现办理不了的情况了。

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

转载于:http://blog.itpub.net/26015009/viewspace-1667515/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值