首页 存档 技术 查看内容

Oracle 数据库服务器 IO 高的分析方案(理论讲解 案例分享) 慧眼识珠服务器磁盘这么 ...

2018-3-30 13:00 |来自: 互联网 289 0

摘要: 本文原题《ORACLE数据库服务器IO高的分析方案和案例探讨》 目录: 慧眼识珠服务器磁盘这么繁忙,到底是谁干的? 谨记于心ORACLE DBA判断IO有性能问题的标准 带刀侍卫处理IO问题必须掌握的一个ORACLE工具 说难不难用 ...

本文原题《ORACLE数据库服务器IO高的分析方案和案例探讨》


目录:

慧眼识珠服务器磁盘这么繁忙,到底是谁干的?

谨记于心ORACLE DBA判断IO有性能问题的标准

带刀侍卫处理IO问题必须掌握的一个ORACLE工具

说难不难用几句话来说清ORACLE数据库

活得明白一个例子说明ORACLE的工作过程

牢记于心一幅图来总结ORACLE的IO特点

怎么破什么是无效IO以及解决方法

作者:黄远邦(小y),就职于北京中亦安图科技股份有限公司,任数据库团队技术总监。长期活跃于国内多家银行总行生产数据中心,提供Oracle第三方服务,解决过无数疑难问题,在业内具有极佳的口碑。


前言



远邦在为数据中心提供Oracle第三方服务的过程中接触过很多系统/存储管理员,发现很多SA对Oracle数据库缺乏足够的了解,导致在处理综合问题时容易各说各话,因此有了写一个系列文章的想法,本意是尽可能用大白话为大家普及一些常见问题所需的理论,辅以几个实际的案例分析,希望对大家以后的工作有所帮助。

言归正传,在部署了ORACLE数据库的服务器上,我们大家或多或少的遇到过下列情况:

1.业务系统运行缓慢,作为系统管理员需要检查包括IO在内的系统资源,这时系统管理员、存储管理员可能得到DBA(数据库管理员)的反馈说,IO的响应时间很慢,达到了30毫秒以上,要求解决。但存储管理员检查又不存在热点盘的情况,系统的IO量就是很大,除了使用更多的RAID组来重新分布数据、更换为更高端的存储外,似乎没有太好的办法;

2. 我们可能通过iostat和sar -d命令观察到磁盘的busy很高、每秒的IOPS很高、每秒的IO读写量很大、HBA卡的流量很高等危险的现象;

3. IO响应时间长,到底是导致业务慢的原因还是结果?

4. IOPS很高、IO读写量很大,到底是原因还是结果?

5. 除了硬件的扩容或升级,难道没有别的解决方法么?

6. 如何识别ORACLE服务器上的IO来源,如何判断这些IO是否是有效IO,怎么消除无效IO?

7. 作为系统管理员和存储管理员需要掌握哪些数据库简单技能才不会在出现IO问题时处于被动的局面?

8. ORACLE DBA评判IO是否有性能问题的标准是什么?

9. ORACLE数据库的IO有什么特点?哪些IO是比较关键,是必须保障性能的?

我们将通过理论和实际案例穿插介绍的方式为大家进行讲解和分享,希望对大家有所启发。

本文是系列的第一篇。需要说明的是,由于篇幅有限,会暂时省略掉部分在过程中实际发生但与本主题不是那么密切的内容,如UNDO、checkpoint等内容。

同时考虑到AIX专家俱乐部可能更多的是系统/存储管理员,因此会有部分科普的内容,水平较好的ORACLE DBA可以自行跳到案例探讨环节。对于没有真正做过DBA的同学来说,ORACLE可能稍微有点难,但只要静下心来花点时间去主动了解了,那就不难了。


慧眼识珠服务器磁盘这么繁忙,到底是谁干的?


出一个问题时段的AWR报告,将awr报告对应的html文件下载到PC终端
用IE等浏览器打开,查找”SQL ordered by Reads”部分,如下图所示:

可以看到:

1) 排名第一的SQL语句,占了整个数据库服务器IO的99.79%

2) 一共执行了8次,每次执行发生的IO是2,129,053个BLOCK,一个BLOCK是8K,即每次执行该SQL,将发生2,129,053*8K=16.24G

知识点:

BLOCK是ORACLE数据文件的最小分配单元,类似LV的PP,数据就存储在BLOCK中,一个BLOCK可以存储几十到几百条不等的用户表的数据。

是不是很简单?

当然,大家也可以用操作系统的命令看到进程级的IO分布情况。

例如Linux环境下通过pidstat -d 可以监控哪个进程IO消耗较高。

当然,采用操作系统方式查看进程级别的IO分布的方式的缺点是很显然的,更可怕的是,这表明你依然在把数据库当黑盒子来看待,进程具体在做什么?为什么IO那么高?

我们需要继续往前一步。


谨记于心ORACLE DBA判断IO有性能问题的标准


知识点:

一般来说,如果单个IO的响应时间在20毫秒以内,是可以接受的,较好的性能应该在10个毫秒以下,越低越好。超过20毫秒的单个IO响应时间,则可认为性能不佳,需要做调优。需要说明的是,对于IO次数只有个位数的文件,IO超过20毫秒,也是可以接受的,因为在存储层面不容易被cache。


通过OS和数据库AWR报告两个方式均可以判断IO是否有问题,建议以OS方式为准。

1.操作系统方式

sar d 2 10的输出中,avwait和avserv两列之和即为IO的响应时间(AIX环境),单位为毫秒。LINUX环境下有区别,IO的响应时间为AVWAIT列。

可以看到:

hdisk4上单个IO的响应时间达到4000多毫秒和2000多毫秒,远远大于20毫秒,IO性能到了无法忍受的地步,需要尽快分析是否存储存储cache被关闭,硬盘是否出现故障、链路是否出现问题等情况。

2. 数据库AWR报告方式

下图的Av Rd(MS)表示单次读的毫秒数,即为单个IO的响应时间。可以看到,在0.01毫秒,远远低于20毫秒,IO性能非常的好!(能达到整个性能,往往是在文件系统缓存中被缓存了)

下图的Av Rd(MS)表示单次IO读的毫秒数,即为单个IO的响应时间。可以看到,大部分数据文件的IO响应时间超过40毫秒,远远大于20毫秒,IO性能不理想,在对存储进行扩容或者升级前,应该先好好分析IO是否是无效IO,是否可以消除无效IO!通过SQL优化消除无效IO,可以有效保护存储等硬件的投资,满足未来多年的业务发展,而不是盲目扩容。


带刀侍卫处理IO问题必须掌握的一个ORACLE工具


上述的AWR报告是怎么获得的呢?什么是AWR报告呢?容许我嗦一下:

很多同学可能听过AWR报告,收集AWR报告的步骤是固定的,很简单,步骤如下:

#su oracle

$sqlplus “/ as sysdba”

SQL

声明:文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除

路过

雷人

握手

鲜花

鸡蛋

相关分类

返回顶部