你的位置:首页 > 数据库

[数据库]Oracle 11g新特性direct path read引发的系统停运故障诊断处理


黎俊杰 | 2016-07-28 14:37

声明:部分表名为了脱敏而用XX代替

1、故障现象

(1)一个业务系统输入用户名与密码后无法进入首页,表现为一直在运行等待,运行缓慢

(2)整个系统无法正常使用,接近停运状态

2、故障解决方法

调整数据库参数alter system setevent='10949 trace name context forever, level 1'来关闭“direct path read”(直接路径读)特性,使SQL语句可以从缓存中查询数据,达到降低I/O读取量,使全表扫描的数据从缓存中读取,加快SQL语句运行速度的目的。

3、故障原因总结

(1)由于部分SQL语句设计或编写效率低下,以及表缺少适应的索引,导致SQL语句需要全表扫描,在表较小时,ORACLE数据库将数据读取到缓存后,后续虽然是全表扫描,但均是从缓存中读取,所以问题未体现出来

(2)在表的大小不断增大后,根据ORACLE 11g数据库的算法,在表达到db_cache_size(GB)的2%(默认值)以后,认为采用直接路径读(跳过缓存,直接从磁盘文件中全扫描读取)

(3)DX_T_XXVIATE表大小为1GB,在大量反复以direct pathread磁盘重复读取的情况下,消耗大量的I/O资源,将服务器I/O几乎耗尽

(4)在主机I/O耗尽的情况下,系统的读、写,均几乎处于瘫痪状态

(5)在关闭ORACLE 11G数据库的direct path read新特性功能后,读取方式恢复到从缓存中读取,磁盘读降到“0”,系统恢复正常

4、改进建议

(1)优化访问DX_T_XXVIATE 相关的SQL语句与设计合适的索引,避免大表全表扫描。

5、故障原因分析

5.1 7月11日故障时段数据库服务器I/O等待严重

wps5655.tmp[4]

5.2 7月11日故障时段磁盘响应非常缓慢

wps5665.tmp[4]

5.3 对比故障当日(7月11日)与上周的I/O磁盘读取量,比上周大十倍

wps5676.tmp[4]

故障前、中、后磁盘读取量对比图:

wps5686.tmp[4]

上面高的蓝色线,是故障当日(2016年7月1日,周一)的磁盘Disk Read KB/s指标线

5.4 高度消耗I/O的SQL语句。

上面SQL_ID为b8m6wy846qgbk的SQL语句,physical reads鹤立鸡群,可见此SQL语句的影响最为严重。

5.5 全表扫描单次超过6秒的表与其SQL语句统计。

统计汇总时间:08:00—10:00

wps5687.tmp[4]

wps5698.tmp[4]

统计时间:08:00—10:00单次扫描超过6秒的SQL语句及时长详细清单

wps56A9.tmp[4]

上面数据显示,08:00—10:00统计时间内,所有全表扫描超过6秒的表,全部是DX_T_XXVIATE这一张表,涉及到的SQL语句有60多条,执行次数最多的数SQL_ID为b8m6wy846qgbk的语句。

5.6 全表扫描最严重SQL语句故障前、后、故障解决后磁盘读取数量对比

5.6.1 7月11日以前系统运行正常的情况下SQL_ID为b8m6wy846qgbk的语句执行统计信息

--执行统计信息(buffer get很大,但是disk reads为0,判定数据基本从buffer中读取):

wps56B9.tmp[4]

--执行计划(对DT_T_OBVIATE全表扫描,预计时间为5分钟30秒):

wps56BA.tmp[4]

5.6.2 7月11日故障当日SQL_ID为b8m6wy846qgbk的语句执行统计信息

--执行统计信息(buffer get和disk reads都一样的巨大,基本判定每次数据全是从磁盘读取到BUFFER):

wps56CB.tmp[4]

--执行计划(对DT_T_OBVIATE全表扫描,预计时间为5分钟30秒,从执行计划的PHV和plan均看出执行计划在系统故障时与正常时,是保持一致的):

wps56DC.tmp[4]

5.6.3 故障解决后(取7月12日数据)SQL_ID为b8m6wy846qgbk的语句执行统计信息

--执行统计信息(故障解决后,PVH值不变,Disk Reads又恢复到了故障前的“0”,说明每次执行数据又是从BUFFER中读取的):

wps56DD.tmp[4]

5.7等待事件变化识别数据读取方式变化比较

wps56DE.tmp[4]

看来,系统实际上在2016年7月10日(周日),SQL语句的数据读取方式就发生了少量的direct path read,系统实际上已经处于间歇式缓慢状态,到了2016年7月11日(周一),问题特别严重,约99%左右的执行是direct path read,导致I/O耗尽,系统瘫痪。

About Me

.........................................................................................................................................................................................................

● 本文来自于微信公众号转载文章,若有侵权,请联系小麦苗及时删除,非常感谢原创作者的无私奉献

● 本文在ITpub(http://blog.itpub.net/26736162)、博客园(http://www.cnblogs.com/lhrbest)和个人微信公众号(xiaomaimiaolhr)上有同步更新

● 小麦苗分享的其它资料:http://blog.itpub.net/26736162/viewspace-1624453/

● 原文地址:http://mp.weixin.qq.com/s?__biz=MzA5MDQ5Nzc0MA==&mid=2247483720&idx=1&sn=646e8c1fc34d7afb13484dd7e483534b&scene=1&srcid=0815syZkJIb1ficYRJVbbc6H#rd

● QQ群: 230161599   微信群:私聊

● 联系我请加QQ好友(642808185),注明添加缘由

● 【版权所有,文章允许转载,但须以链接方式注明源地址,否则追究法律责任】

.........................................................................................................................................................................................................

长按下图识别二维码或微信客户端扫描下边的二维码来关注小麦苗的微信公众号:xiaomaimiaolhr,学习最实用的数据库技术。

wpsF73.tmp