通过数据库评估存储设备IO性能Oracle11gIO校准功能介绍 - Oracle - 次元立方网 - 电脑知识与技术互动交流平台
通过数据库评估存储设备IO性能Oracle11gIO校准功能介绍
通过数据库评估存储设备IO性能
---------Oracle11g IO校准功能介绍
I/O子系统是ORACLE数据库的一个重要组成部分，因为I/O操作是贯穿数据库管理全过程，它操作的对象包括日志、表、索引、数据字典、以及一些排序、undo操作等等，每个数据库读取或者写入磁盘上的数据，都会产生磁盘IO，可以这么说一个正常业务的数据库系统，80%的性能消耗都与IO有关，相对于网络、CPU、内存等其他硬件的迅猛发展，磁盘的读写速度的发展却相对滞后，这也导致许多业务性能瓶颈集中在有限的磁盘IO上,一旦出现IO瓶颈导致的性能问题，表现为CPU有时候会花大部分的时间等待IO操作，我们把这种情况称为IO密集性（I/O-bound）系统。
我们在处理ZLHIS业务系统性能问题的时候，大部分也是在处理IO性能问题，主要表现在三方面：
1、HIS系统是业务高密集系统，在业务高峰期会形成大量集中的并发操作，产生大量的I/O操作；
2、不规范的SQL语句导致的过度的磁盘访问（如：全表扫描等）；
3、由于硬件导致的存储IO本身的性能问题；
上图就是一个某客户真实环境下I/O性能瓶颈的AWR性能报告，TOT5等待事件中，主要就是I/O类型的等待，在处理类似问题的时候，我们都先假定存储的I/O性能是满足我们的业务需求的，忽略存储本身的性能问题，而着重解决1、2应用设计或者SQL代码不规范导致的过度I/O读取，但有时导致I/O性能的问题根本的原因恰恰就是存储，遇到这种问题的时候，我们过去都是通过文件拷贝、复制读写都操作主观的感受存储的性能，或者找硬件商协助分析，前一种方式不便于我们从数据指标上给存储性能予以定型，特别是在某些瞬时集中IO访问出现瓶颈的存储设备上给出充分的说服力，后一种方式如果遇到硬件商本身不配合，我们处理问题就非常的尴尬，这时候我们急需一种方式对够自主的对存储进行性能评估，给出评估性能指标以便对I/O性能进行量化，为问题的分析解决给出可靠的依据。
IO相关概念
在对存储性能进行评估之前，我们有必要了解几个关于IO的指标概念，只有对这几个指标概念有了了解，我们才能客观的评价一个存储性能的好坏。
IOPS(I/OOperations Per Second):是用来计算I/O流中每个节点中每秒传输的数量,表示每秒进行读写(I/O)操作的次数，多用于评估衡量存储随机访问的性能。IOPS通常对于小I/O，且传输I/O的数量比较大的情况下，是一个最主要的衡量指标。例如，典型的OLTP系统中，高的IOPS则意味相同时间内更多的数据库事务可以被存储系统处理。
IO响应时间（latency）：指内核对磁盘发出一个读或者写的IO命令，到内核接收到回应的时间。
吞吐量（Throughput）:来计算每秒在I/O流中传输的数据总量。这个指标，在大多数的磁盘性能计算工具中都会显示，最简单的在Windows文件拷贝的时候，就会显示MB/s，吞吐量衡量对于大I/O，特别是传输一定数据的时候最小化耗时非常有用，例如，备份数据的时候，在备份作业中，我们通常不会关心有多少I/O被存储系统处理了，而是完成备份总数据的时间多少。
以上三个指标基本上能够衡量存储的IO性能，其中IOPS和吞吐量是越大越好，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
确保数据文件允许异步IO，可以通过下面的SQL语句确认：
COL NAME FORMAT A50
SELECT NAME,ASYNCH_IOFROM V$DATAFILE F,V$IOSTAT_FILE I
WHERE F.FILE#=I.FILE_NO
AND FILETYPE_NAME='Data File';
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也行，认为只是一块磁盘。
下面是一个执行DBMS_RESOURCE_MANAGER.CALIBRATE_IO包的案例，语句非常简单，如下：
SET SERVEROUTPUT ON
lat INTEGER;
iops INTEGER;
mbps INTEGER;
--DBMS_RESOURCE_MANAGER.CALIBRATE_IO (&DISKS&, &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);
校准的操作很简单，但是在运行时需要注意以下几点事项：
同一时间只能运行一个IO校准过程，千万不要并行运行，如果您同时运行，I/O校准将不能正常执行；
因过程执行对IO消耗非常大，请确保实例在空闲状态下执行；
如果是RAC环境，要确保所有节点实例都是启动状态；
过程包中的num_physical_disks输入参数是可选的。磁盘数不用太准确，输入个近似值这样可以使得校准更快、更准确。
最后在I/O校准过程中，你可以在v$io_calibration_status视图查看校准状态。在I/O校准成功后，你可以在dba_rsrc_io_calibrate表查看校准结果，为了更好的理解I/O校准过程，我们拿台普通的台式机来进行下演示，看下是如何进行IO校准操作的。
通过v$io_calibration_status可以查看执行状态，可以看到进程正在执行，如下
在操作系统的任务管理器的性能监控中可以看到，每个数据文件都产生大量的IO读取，Oracle就是通过这种读取操作来进行存储性能的评估。
最后在DBA_RSRC_IO_CALIBRATE视图中，可以查询到本次IO校准的各个性能指标值如下，本次测试的存储性能，每秒持续读取数据块请求的最大数量（max_iops）为60，每秒最大可读取（max_mbps）为43mbps,单个进程每秒最大可读取（max_pmbps）为39mbps，读取数据块请求出现有16次延迟
这里我们注意了同样的IO校准执行2次，结果也会有所差异，不可能几次执行结果100%相同，这是因为存储性能涉及的因素非常多，比如当时存储的繁忙状态、温度、IO请求等，这些都会对校准有细微的影响，但是总的范围还是不会有太大的出入。
通过校准我们得到了一些指标，那么怎样的存储性能才是满足业务需求的呢？严格意义上说，当然是IOPS越大，吞吐量越大越好，但是成本也会增加，因此实际情况下还是要根据用户业务的实际情况判断，合适就可以了。用户的IO需求可以通过业务高峰期AWR报告进行查看，通过生成业务高峰期的AWR报告，查看报告中的other instance activity stats这部分内容获取，以某用户的AWR性能报告为例，重点关注这几个指标[physical read total IOrequests],[ physical read total bytes],[ physical write total IO requests],[ physicalwrite total IO requests]每秒的值，因为我们IO校准也是以每秒为单位的统计。
我们可以计算出物理读和写每秒总的请求为70.74+80.62&151次，物理读和写的每秒的大小为1.32+1.09&2.41mbs=19.28mbps,有了这个参照，那我们存储校准的最大IOPS就应该不能低于151，每秒的吞吐量也不能低于19.28mbps,如果IO校准接近或者小于这个值就证明存储性能出现了严重的瓶颈，例如我们测试用的机器就无法满足这个用户的IO性能需求，需要提升性能以满足业务的需要。
延伸阅读：
TimesTen的守护进程分为主守护进程和子守护进程。主守...
本教程为 李华明 编著的iOS-Cocos2d游戏开发系列教程：教程涵盖关于i......
专题主要学习DirectX的初级编程入门学习，对Directx11的入门及初学者有......
&面向对象的JavaScript&这一说法多少有些冗余，因为JavaScript 语言本......
Windows7系统专题 无论是升级操作系统、资料备份、加强资料的安全及管......<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&Orion_-_oracle提供的测试io性能的工具_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
Orion_-_oracle提供的测试io性能的工具
上传于||文档简介
&&o&#8203;r&#8203;a&#8203;c&#8203;l&#8203;e&#8203; &#8203;o&#8203;r&#8203;i&#8203;o&#8203;n
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
下载文档到电脑，查找使用更方便
还剩20页未读，继续阅读
你可能喜欢Oracle性能分析4：数据访问方法之全扫描
SQL语句执行时，的优化器会根据统计信息确定表的访问方式，一般来说，有两种基本的数据访问方式：1）全扫描。在全扫描（全表扫描或者快速全索引扫描）中，多个块被读入到一个IO运算中。2）索引扫描。索引扫描首先扫描索引叶子块以取得特定的行id（rowid），然后利用这些行id来访问父表取得实际的行数据，访问通过单块读取来完成。这里主要讲解全扫描方式，后面将介绍索引扫描。
使用全扫描
当对一个表进行全扫描时，会将表中所有数据块（block）取出并进行处理，筛选出符合条件的数据。注意Oracle必须将整个数据块（block）中的数据读到内存中，再取得符合条件的数据。因此Oracle的优化器需要关心两个信息：获取块的数量和每个块中舍弃的数据量。优化器将根据这两个信息来判断是否使用全扫描，首先我们来看看获取块的数量怎么影响优化器的选择。
获取块的数量
总的来说，如果查询需要取出表的大部分数据块，则应该采用全扫描。但由于很难评估查询将取出的表的数据块的数量，因此在使用全扫描上存在很多这样的&经验法则&：当你的查询会取出表中x%的数据行，则应该选择全扫描。这些法则有一定的道理，但是并不准确，因为当取出的数据行较大时，自然取出的数据块也会较大，这时采用全扫描并没有问题，但有时虽然取出的数据行较小，会取出的数据块也可能会较大，实际上这时也应该采用全扫描，但这些&经验法则&则不再生效。我们看看下面具体的例子。
我们创建一个表T1：
create table t1 as
select trunc((rownum - 1) / 100) id, rownum value
from dba_source
where rownum &= 10000
然后为T1创建索引：
create index idx_t1_id on t1(id)
然后为T1收集统计信息：
dbms_stats.gather_table_stats(user,
&#39;t1&#39;,
method_opt =& &#39;FOR ALL COLUMNS SIZE 1&#39;,
然后我们执行查询：
select * from t1 where id = 0
该查询的执行计划如下：
SELECT STATEMENT, GOAL = ALL_ROWS
TABLE ACCESS BY INDEX ROWID
INDEX RANGE SCAN
该执行计划使用了索引范围扫描，由于符合条件id为0的数据在表中只有100行数据，而整个表有1万行数据，查询出的数据只占整个数据的1%，因此我们认为这是一种合理的执行计划。
接下来我们看下面的例子，创建一个表格T2：
create table t2 as
select mod(rownum,100) id, rownum value
from dba_source
where rownum &= 10000
同样为T2创建索引：
create index idx_t2_id on t2(id)
然后为T2收集统计信息：
dbms_stats.gather_table_stats(user,
&#39;t2&#39;,
method_opt =& &#39;FOR ALL COLUMNS SIZE 1&#39;,
然后执行查询：
select * from t2 where id = 0
该查询的执行计划如下：
SELECT STATEMENT, GOAL = ALL_ROWS
TABLE ACCESS FULL
我们看到表的执行计划变成的全表扫描，我们可以很容易的得到该查询的结果任然是100条数据，占T2表总数据量的1%，如果我们进一步比较T2和T1的数据，会发现两张表的id字段完全一样，那为什么T1选择的是索引扫描，而T2却选择了全表扫描呢？
要了解原因，我们需要从数据在数据块上的分布来分析，在T1表中，id字段的分布如下：
0 0...0 0 1 1...1 1 2 2...2 2......88 88...88 88......99 99...99 99
而T2表中id字段的分布如下：
0 1 2 3 ... 98 99 0 1 2 3 ... 98 99 ...... 0 1 2 3 ... 98 99
从这里可以看出T1表中id为0的数据都集中在几个数据块上，而T2表中id为0的数据则分布在很多不同的块上，这样导致T1的查询只需要读取很少块就可以得到结果，因此使用了索引范围扫描，而T2上的查询则需要读取大部分块，因此优化器选择了全表扫描。
需要注意的是，全扫描的效率不仅取决于读取的数据块个数，也取决于最终的结果集行数。从上面的例子中我们可以看到：当一个数据块被读取后，查询将根据过滤条件舍弃不符合条件的数据。而这个舍弃的过程是需要耗费资源的，由于这个操作在内存中，因此耗费的将是CPU资源，而舍弃的数据量越大，耗费的CPU资源就越多。
因此，读取的数据块的个数越多，舍弃的数据量越大，全扫描的成本（cost）就越高。
不难想象，当表的数据量不断增大，舍弃的行的数量不断增加，全扫描的成本不断增加，最终可能导致优化器放弃全扫描，转而选择索引扫描。
多块读取方式
多扫描使用的是多块读取，即一个单独的IO调用将会读取多个块，读取的块的数量是可变的，但有一个上限，通过db_file_multiblock_read_count参数指定，该参数通过下面的SQL查看：
select * from v$parameter where name = &#39;db_file_multiblock_read_count&#39;
下面描述了Oracle在几种情况下读取的块的数量：
1）Oracle不得不读取超过一定边界范围的数据块。
在这种情况下，Oracle将会在一次调用中读取直到边界范围的数据块，然后发起另一次调用来读取剩下的块。
2）存在块已经在内存中
首先读取那么已经在内存中的块，然后发起调用读取剩下的块，这意味着多块读取可能一次仅读取一块。例如，假定多块读取的上限是16，该次读取的数据块编号为1-16，并且编号为偶数的块已经在内存中，那么在这里例子中，将会有8次的单块读取调用来读取奇数编号的块。
3）多块读取大小超过了操作限制
这时取决于你操作系统，因此是可变的。
所谓高水位线，就是表中最后一块有数据写入的数据块。需要注意的是即使几乎所有数据行都被删除了，并且一些块实际上已经完全变为空的了，高水位线还是保持不变。看下面的例子，当表创建并插入数据后：
而随着后面数据的变化（删除和修改），表中的数据变化为：
虽然很多存储区域已经没有数据，但高水位线任然保持不变。
那么，高水位线对全扫描会造成什么影响呢？
执行全扫描时，Oracle将一直读取到位于表中高水位线的数据块，即使它们是空的，这就意味着许多实际上不需要读取的数据块也被读取了。
下面通过一个具体的实例来看，使用先前的表T2。
1）通过下面的语句判断表所包含的数据块数量：
select blocks from user_segments where segment_name = &#39;T2&#39;
2）确定表中有多少数据块包含数据；
select count(distinct(dbms_rowid.rowid_block_number(rowid))) block_ct from t2
3）执行下面的查询，并查看trace信息（trace信息的获取方面见Oracle性能分析1）
alter system flush buffer_--清理缓存
select * from t2 where id = 0
trace信息为：
------- ------
-------- ---------- ---------- ---------- ----------
----------
------- ------
-------- ---------- ---------- ---------- ----------
----------
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
Row Source Operation
---------------------------------------------------
TABLE ACCESS FULL T2 (cr=20 pr=18 pw=0 time=35975 us)
查询出100行数据，物理读取的数据块数量（disk）为18，包括一个表头数据块的读取（只有17个数据块包含数据）。执行计划使用了全表扫描。
4）执行删除数据的操作
delete from
5）重新获取表包含的数据块数量
select blocks from user_segments where segment_name = &#39;T2&#39;
6）获取包含数据的数据块数量
select count(distinct(dbms_rowid.rowid_block_number(rowid))) block_ct from t2
7）执行查询并查看trace信息
alter system flush buffer_--清理缓存
select * from t2 where id = 0
trace信息为：
------- ------
-------- ---------- ---------- ---------- ----------
----------
------- ------
-------- ---------- ---------- ---------- ----------
----------
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 5
Row Source Operation
---------------------------------------------------
TABLE ACCESS FULL T2 (cr=20 pr=18 pw=0 time=214806 us)
我们可以看到查询出的行数是0，但任然物理读取了18个数据块，执行计划任然使用了全扫描。
修正高水位线
我们已经了解了高水位线给全扫描带来的性能问题，下面介绍了几种降低高水位线的方法。
使用truncate操作
truncate table_name
在删除数据时尽量使用truncate操作，降低高水位线。
alter table table_name move
注意move操作需要使用额外的表空间存储，会锁住表，这样其他并发的用户在表上执行的DML语句会产生等待。move操作会影响到表上的索引，因此索引需要rebuild。
shrink操作
shrink space操作，不需要任何额外的空间，但是速度要比move慢上很多。shrink命令分为下面两种：
1）只压缩空间不调整水位线，在业务繁忙时可以执行
alter table table_name shrink space compact
compact操作通过一系列insert、delete操作，将数据尽量排列在段的前面。在这个过程中需要在表上加RX锁，即只在需要移动的行上加锁。但由于涉及到rowid的改变，因此需要enable row movement。
2)调整水位线 会产生锁，可以在业务比较少的时候执行，oracle 会记住1步骤中的操作，只调整水位线
alter table big_table shrink space
复制要保留的数据到临时表t，drop原表，然后rename临时表t为原表。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'}