ITPub博客

首页 > 数据库 > Oracle > Oracle 11g中的IO Calibrate(IO校准)

Oracle 11g中的IO Calibrate(IO校准)

Oracle 作者:denglt 时间:2015-06-24 16:56:22 0 删除 编辑

转:http://blog.itpub.net/17203031/viewspace-1063523/
Oracle
数据库发展到今天,“IO为王”已经是一种发展方向趋势。ExtraData一体机的重要特色之一就是最大程度的发挥IO能力、提高IO吞吐量。

相比CPU和内存,IO存储有其特殊性。我们讨论IO,通常成为I/O栈(I/O Stack)。I/O栈设计的对象是一系列关键组件层,包括HBAStorage SwitchesStorage ArrayPhysical Disks。这些对象共同合力,才能形成系统整体的IO能力。

四层关键组件,共同形成“木桶效应”。只要有一个层面存在不足,必然成为IO中的短板。I/O难调,也就是在这个方面。但是对于Oracle而言,我们需要关注的是IO整体性能,也就是整体的效果。

Oracle 11g有两个对于性能方面的测试工具,一个就是RATReal Application Test),另一个就是IO校准(Calibrate IO)。RAT是一种负载重演组件,当进行系统软硬件升级的时候,我们一个很关注的问题是:此次变化能否提升系统性能、能提升多少,会不会有新的瓶颈。这个在过去是不能实现的,只能够在升级之后通过实践去发现。但是RAT可以捕获实际系统负载情况,将其在新环境下进行重演,并且进行度量比较。IO调教的作用也是IO负载模拟,从而判断出实际真实的系统IO情况。

本篇我们就介绍IO校准特性。

 

1、发现IO校准

 

首先聊聊为什么要进行校准。IO是一个多组件共同影响的统一体,多个组件之间大部分情况下是不能够完全如同理想情况下工作的。所以需要进行硬件标准指标和实际情况之间进行校准,来获取准确的IO数据。

获取精确IO有什么用途呢?根源还是Oracle自动化和智能化的需要。进入11g之后,Oracle向智能化的步子是在加快的过程。OracleCBO开始,进行自动化并行决策的Auto DOP就需要IO校准的信息。

 

2、配置IO校准

 

我们进行配置过程,首先选择Oracle 11gR2进行测试。

 

SQL> select * from v$version;

 

BANNER

---------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production

PL/SQL Release 11.2.0.3.0 - Production

CORE 11.2.0.3.0 Production

 

TNS for Linux: Version 11.2.0.3.0 - Production

NLSRTL Version 11.2.0.3.0 - Production

 

11g中有一个视图v$io_calibration_status,记录了系统进行校准过程信息。和统计量不同,Oracle是不会自动进行IO校准的,而需要DBA手工完成。

 

SQL> select * from v$io_calibration_status;

STATUS        CALIBRATION_TIME

------------- --------------------------------------------------------------------------------

NOT AVAILABLE

 

注意:进行校准过程,一般需要配置异步IO功能。

 

SQL> show parameter disk_asy

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

disk_asynch_io                       boolean     TRUE

 

 

SQL> select name,asynch_io from v$datafile f,v$iostat_file i

  2  where f.file#=i.file_no

  3  and (filetype_name='Data File' or filetype_name='Temp File');

 

NAME                                               ASYNCH_IO

-------------------------------------------------- ---------

+DATA/ora11g/datafile/system.256.825944325         ASYNC_ON

+DATA/ora11g/datafile/system.256.825944325         ASYNC_ON

+DATA/ora11g/datafile/sysaux.257.825944327         ASYNC_ON

+DATA/ora11g/datafile/undotbs1.258.825944329       ASYNC_ON

+DATA/ora11g/datafile/users.259.825944329          ASYNC_ON

+DATA/ora11g/datafile/example.265.825944513        ASYNC_ON

 

6 rows selected

 

IO校准并不是单独的列出功能,而是融入到OracleResource Manager功能包里面。调用IO校准的功能包DBMS_RESOURCE_MANAGER.CALIBRATE_IO,其中两个输入参数,一个是磁盘的个数,另一个是允许的最大IO延迟。这两个参数可以通过咨询运维团队和厂商实现。

调用过程如下:

 

 

SQL> set serveroutput on;

SQL> DECLARE

  2    lat INTEGER;

  3    iops INTEGER;

  4    mbps INTEGER;

  5  BEGIN

  6  --DBMS_RESOURCE_MANAGER.CALIBRATE_IO(, ,iops, mbps, lat);

  7    DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat);

  8    DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);

  9    DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);

 10    dbms_output.put_line('max_mbps = ' || mbps);

 11  end;

 12  /

 

max_iops = 111

latency = 8

max_mbps = 62

 

PL/SQL procedure successfully completed

 

Executed in 811.547 seconds

 

这个执行过程执行超过800s,时间不算短。最后计算出测算出的最大iops、延迟和最大mbps(每秒MB)。

在执行过程中,我们查看视图v$io_calibration_status

 

 

 

SQL> select * from v$io_calibration_status;

 

STATUS        CALIBRATION_TIME

------------- --------------------------------------------------------------------------------

IN PROGRESS   14-12-13 11.20.20.120 上午

 

 

此时的状态,从Not Available变为Ready。在校准过程中,Oracle会形成对存储的大量IO读写操作。我们借助Linux下的sar命令,监控全部过程。

 

 

[root@SimpleLinux ~]# sar -b 5 100 -o /tmp/res2

Linux 2.6.18-128.el5 (SimpleLinux.localdomain)  12/13/2013

 

11:25:08 AM       tps      rtps      wtps   bread/s   bwrtn/s

11:25:13 AM      8.33      0.00      8.33      0.00    134.92

11:25:18 AM     23.02      1.59     21.43     50.79    311.90

11:25:23 AM      5.96      1.59      4.37     50.89     85.88

11:25:28 AM      7.14      1.59      5.56     50.79     89.68

11:25:33 AM      2.78      0.00      2.78      0.00     44.44

11:25:38 AM      5.96      1.59      4.37     50.89     85.88

11:25:43 AM    257.65    253.28      4.37   4141.55     76.34

11:25:48 AM    281.75    276.19      5.56   4415.87    219.05

11:25:53 AM    278.33    273.56      4.77   4427.83     89.07

11:25:58 AM    289.50    266.53     22.97   4264.55    237.62

11:26:03 AM    232.14    228.97      3.17   3688.89     50.79

11:26:08 AM    268.53    264.14      4.38   4608.76     92.43

 

 

注意TPS的变化过程。启动校准之后,Oracle生成大量的IO操作,来判断存储的极限。这个过程也就是让我们了解当前IO架构的上限。

我们通过Excel画出全过程的TPSRTPSWTPS趋势。

 

结束IO校准之后,我们可以查看到IO调教过程信息。

 

 

SQL> select * from v$io_calibration_status;

 

STATUS        CALIBRATION_TIME

------------- --------------------------------------------------------------------------------

READY         14-12-13 11.39.10.194 上午

 

3、校准使用

 

我们进行IO校准,可以为Oracle很多功能提供决策依据。如果没有进行过IO校准,Auto DOP就不能正常工作。

 

 

SQL> explain plan for select /*+parallel*/ * from scott.emp;

 

Explained

 

SQL> select * from table(dbms_xplan.display);

 

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------

Plan hash value: 1408123770

--------------------------------------------------------------------------------

| Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time

--------------------------------------------------------------------------------

|   0 | SELECT STATEMENT     |          |    14 |   532 |     2   (0)| 00:00:01

|   1 |  PX COORDINATOR      |          |       |       |            |

|   2 |   PX SEND QC (RANDOM)| :TQ10000 |    14 |   532 |     2   (0)| 00:00:01

|   3 |    PX BLOCK ITERATOR |          |    14 |   532 |     2   (0)| 00:00:01

|   4 |     TABLE ACCESS FULL| EMP      |    14 |   532 |     2   (0)| 00:00:01

--------------------------------------------------------------------------------

Note

-----

   - automatic DOP: skipped because of IO calibrate statistics are missing

 

15 rows selected

 

收集IO Calibrate统计量之后,就可以看到并行度效果。

 

 

SQL> explain plan for select /*+parallel*/ * from scott.emp;

 

Explained

 

SQL> select * from table(dbms_xplan.display);

 

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------

Plan hash value: 2873591275

--------------------------------------------------------------------------------

| Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time

--------------------------------------------------------------------------------

|   0 | SELECT STATEMENT     |          |    14 |   532 |     2   (0)| 00:00:01

|   1 |  PX COORDINATOR      |          |       |       |            |

|   2 |   PX SEND QC (RANDOM)| :TQ10000 |    14 |   532 |     2   (0)| 00:00:01

|   3 |    PX BLOCK ITERATOR |          |    14 |   532 |     2   (0)| 00:00:01

|   4 |     TABLE ACCESS FULL| EMP      |    14 |   532 |     2   (0)| 00:00:01

--------------------------------------------------------------------------------

Note

-----

   - automatic DOP: Computed Degree of Parallelism is 2

 

15 rows selected

 

 

4、结论

 

Oracle自动化、智能化过程中,是需要提供很多辅助信息的。Calibrate IO是一个重要方面。Oracle不进行自动的Calibrate IO统计量的原因大体有三个:

首先是Oracle并不知道实际磁盘的标准指标。第二是Oracle校准过程生成很大的IO,如果不慎会引起很大产品问题。第三是Disk IO性能不会经常性发生变化。

相关文档 :
 Auto DOP and calibrate_io
 automatic DOP: skipped because of IO calibrate statistics are missing

视图:DBA_RSRC_IO_CALIBRATE

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

请登录后发表评论 登录
全部评论

注册时间:2010-11-04

  • 博文量
    118
  • 访问量
    702941