概述

I/O子系统是ORACLE数据库的一个重要组成部分，因为I/O操作是贯穿数据库管理全过程，它操作的对象包括日志、表、索引、数据字典、以及一些排序、undo操作等等，每个数据库读取或者写入磁盘上的数据，都会产生磁盘IO，可以这么说一个正常业务的数据库系统，80%的性能消耗都与IO有关，相对于网络、CPU、内存等其他硬件的迅猛发展，磁盘的读写速度的发展却相对滞后，这也导致许多业务性能瓶颈集中在有限的磁盘IO上,一旦出现IO瓶颈导致的性能问题，表现为CPU有时候会花大部分的时间等待IO操作，我们把这种情况称为IO密集性（I/O-bound）系统。

一、IO相关概念

在对存储性能进行评估之前，我们先了解几个关于IO的指标概念。

1、IOPS(I/OOperations Per Second):

是用来计算I/O流中每个节点中每秒传输的数量,表示每秒进行读写(I/O)操作的次数，多用于评估衡量存储随机访问的性能。

IOPS通常对于小I/O，且传输I/O的数量比较大的情况下，是一个最主要的衡量指标。例如，典型的OLTP系统中，高的IOPS则意味相同时间内更多的数据库事务可以被存储系统处理。

2、IO响应时间（latency）：

指内核对磁盘发出一个读或者写的IO命令，到内核接收到回应的时间。

3、吞吐量（Throughput）:

计算每秒在I/O流中传输的数据总量。这个指标，在大多数的磁盘性能计算工具中都会显示，最简单的在Windows文件拷贝的时候，就会显示MB/s，吞吐量衡量对于大I/O，特别是传输一定数据的时候最小化耗时非常有用，例如，备份数据的时候，在备份作业中，我们通常不会关心有多少I/O被存储系统处理了，而是完成备份总数据的时间多少。

以上三个指标基本上能够衡量存储的IO性能，其中IOPS和吞吐量是越大越好，IO响应时间当然是越短越好。

二、IO校准

存储整体性能主要由一系列关键组件层共同作用，包括HBA、Storage Switches、Storage Array和Physical Disks。这些对象共同合力，才能形成系统整体的IO能力有IO整体性能，通过Oracle的I/O校准功能，我们能够评估存储的整体性能，并判断和确认I/O性能问题是否由数据库或存储系统造成的。不同于其他借助外部I/O评估工具，Oracle的I/O校准功能的原理是数据库随机使用其数据文件访问存储，这样产生的结果能更加真实的反映数据库访问存储的实际性能，它可以帮助计算出当前存储最大的IOPS和吞吐量，要使用这个特性必须满足以下条件：

数据库版本为11g
操作用户必须要有sysdba权限
数据库参数timed_statistics必须是true
必须允许IO异步，但用的是文件系统，可以通过设置FILESYSTEMIO_OPTIONS参数为setall

1、确保数据文件允许异步IO，可以通过下面的SQL语句确认：

COL NAME FORMAT A80
SELECT NAME,ASYNCH_IO FROM V$DATAFILE F,V$IOSTAT_FILE I WHERE F.FILE#=I.FILE_NO AND FILETYPE_NAME='Data File';
--启动异步IO
show parameter disk_asynch_io
show parameter filesystemio_options
--当前使用的是文件系统，因此需要将filesystemio_options设置为asynch，才能开启异步io：
ALTER SYSTEM SET FILESYSTEMIO_OPTIONS = ASYNCH SCOPE=SPFILE;
--重启数据库

2、I/O校准原理

I/O校准是通过调用Oracle内部dbms_resoure_manager.cakibrate_io包来获取，其发出一系列I/O密集型的只读工作量到数据库文件，通过这些操作确定存储的最大IOPS(每秒IO请求数)和存储每秒能够执行的吞吐量MBPS(兆字节每秒I/O)。

I/O校准分为两步：

第一步dbms_resource_manager.calibrate_io包按照数据文件块大小随机读取的所有数据文件，通过持续的读取操作能够获取存储的最大IOPS（max_iops）,同时输出校准期间的平均延迟（actual_latency），也可以通过输入参数max_latency指定目标延迟（指定的最大可容忍数据库块大小的IO请求延迟的毫秒数）。

第二步是通过dbms_resource_manager.calibrate_io包按照1M大小持续读取所有数据文件，这一步主要是为了获取最大吞吐量这个重要的指标。

如果用户能够提供的num_physical_disks输入参数可以使得I/O校准运行更准确，这个参数它指定在数据库中存储系统的物理磁盘的近似数，如果不清楚就输1也行，认为只是一块磁盘。

3、校准案例

执行DBMS_RESOURCE_MANAGER.CALIBRATE_IO包：

SET SERVEROUTPUT ON
DECLARE
lat INTEGER;
iops INTEGER;
mbps INTEGER;
BEGIN
--DBMS_RESOURCE_MANAGER.CALIBRATE_IO (, <max_latency>, iops,mbps, lat);
DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10,iops, mbps, lat);
DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);
dbms_output.put_line('max_mbps = ' || mbps);
end;
/

校准的操作很简单，但是在运行时需要注意以下几点事项：

同一时间只能运行一个IO校准过程，千万不要并行运行，如果同时运行，I/O校准将不能正常执行；
因过程执行对IO消耗非常大，请确保实例在空闲状态下执行；
如果是RAC环境，要确保所有节点实例都是启动状态；
过程包中的num_physical_disks输入参数是可选的。磁盘数不用太准确，输入个近似值这样可以使得校准更快、更准确。

最后在I/O校准过程中，你可以在v$io_calibration_status视图查看校准状态。在I/O校准成功后，可以在dba_rsrc_io_calibrate表查看校准结果.

通过v$io_calibration_status可以查看执行状态，可以看到进程正在执行，如下

select * from v$io_calibration_status

在DBA_RSRC_IO_CALIBRATE视图中，可以查询到本次IO校准的各个性能指标值如下，本次测试的存储性能，每秒持续读取数据块请求的最大数量（max_iops）为516，每秒最大可读取（max_mbps）为135mbps,单个进程每秒最大可读取（max_pmbps）为84mbps，读取数据块请求出现有5次延迟(latency)

select * from DBA_RSRC_IO_CALIBRATE;

注意：同样的IO校准执行2次，结果也可能有差异，不可能几次执行结果100%相同，这是因为存储性能涉及的因素非常多，比如当时存储的繁忙状态、温度、IO请求等，这些都会对校准有细微的影响，但是总的范围还是不会有太大的出入。

三、性能判断

通过校准我们得到了一些指标，那么怎样的存储性能才是满足业务需求的呢？严格意义上说，当然是IOPS越大，吞吐量越大越好，但是成本也会增加，因此实际情况下还是要根据用户业务的实际情况判断，合适就可以了。用户的IO需求可以通过业务高峰期AWR报告进行查看，通过生成业务高峰期的AWR报告，查看报告中的other instance activity stats这部分内容获取，以某用户的AWR性能报告为例，重点关注这几个指标[physical read total IO requests],[ physical read total bytes],[ physical write total IO requests],[ physicalwrite total IO requests]每秒的值，因为IO校准也是以每秒为单位的统计。

我们可以计算出物理读和写每秒总的请求为320.34+135.65≈456次，物理读和写的每秒的大小为64,892,462.30/1024/1024+11,867,839.59/1024/1024≈73.2mbs=585.6mbps,有了这个参照，那我们存储校准的最大IOPS就应该不能低于456，每秒的吞吐量也不能低于585.6mbps,如果IO校准接近或者小于这个值就证明存储性能出现了严重的瓶颈，例如我们测试用的机器就无法满足这个用户的IO性能需求，需要考虑提升性能以满足业务的需要。

觉得有用的朋友多帮忙转发哦！后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~