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

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


Oracle数据库发展到今天,“IO为王”已经是一种发展方向趋势。ExtraData一体机的重要特色之一就是最大程度的发挥IO能力、提高IO吞吐量。
相比CPU和内存,IO存储有其特殊性。我们讨论IO,通常成为I/O栈(I/O Stack)。I/O栈设计的对象是一系列关键组件层,包括HBA、Storage Switches、Storage Array和Physical Disks。这些对象共同合力,才能形成系统整体的IO能力。
四层关键组件,共同形成“木桶效应”。只要有一个层面存在不足,必然成为IO中的短板。I/O难调,也就是在这个方面。但是对于Oracle而言,我们需要关注的是IO整体性能,也就是整体的效果。
 Oracle 11g有两个对于性能方面的测试工具,一个就是RAT(Real Application Test),另一个就是IO校准(Calibrate IO)。RAT是一种负载重演组件,当进行系统软硬件升级的时候,我们一个很关注的问题是:此次变化能否提升系统性能、能提升多少,会不会有新的瓶颈。这个在过去是不能实现的,只能够在升级之后通过实践去发现。但是RAT可以捕获实际系统负载情况,将其在新环境下进行重演,并且进行度量比较。IO调教的作用也是IO负载模拟,从而判断出实际真实的系统IO情况。


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


1、发现IO校准
  首先聊聊为什么要进行校准。IO是一个多组件共同影响的统一体,多个组件之间大部分情况下是不能够完全如同理想情况下工作的。所以需要进行硬件标准指标和实际情况之间进行校准,来获取准确的IO数据。
 获取精确IO有什么用途呢?根源还是Oracle自动化和智能化的需要。进入11g之后,Oracle向智能化的步子是在加快的过程。Oracle从CBO开始,进行自动化并行决策的Auto DOP就需要IO校准的信息。
 
 2、配置IO校准


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


SQL> select * from v$version;


BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE    11.2.0.4.0      Production
TNS for Linux: Version 11.2.0.4.0 - Production
NLSRTL Version 11.2.0.4.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> col name for a80
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
-------------------------------------------------------------------------------- ------------------
/u01/app/oracle/oradata/felix/system01.dbf                                       ASYNC_OFF
/u01/app/oracle/oradata/felix/system01.dbf                                       ASYNC_OFF
/u01/app/oracle/oradata/felix/sysaux01.dbf                                       ASYNC_OFF
/u01/app/oracle/oradata/felix/undotbs01.dbf                                      ASYNC_OFF
/u01/app/oracle/oradata/felix/users01.dbf                                        ASYNC_OFF
/u01/app/oracle/oradata/felix/example01.dbf                                      ASYNC_OFF




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




--调用过程如下:
set serveroutput on;
DECLARE
  lat INTEGER;
  iops INTEGER;
  mbps INTEGER;
BEGIN
--DBMS_RESOURCE_MANAGER.CALIBRATE_IO(<NUM_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);
 end;
 /




SQL> set serveroutput on;
SQL> DECLARE
  2    lat INTEGER;
  3    iops INTEGER;
  4    mbps INTEGER;
  5  BEGIN
  6  --DBMS_RESOURCE_MANAGER.CALIBRATE_IO(<NUM_DISKS>, <MAX_LATENCY>,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 = 3052                        
latency = 0
max_mbps = 179


PL/SQL procedure successfully completed.


SQL> 




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


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


SQL>  select * from v$io_calibration_status;


STATUS                     CALIBRATION_TIME
-------------------------- ------------------------------
IN PROGRESS


SQL> 




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




[root@felix ~]# sar -b 5 100 -o /tmp/res2
Linux 2.6.39-200.24.1.el6uek.x86_64 (felix)     09/08/2015      _x86_64_        (1 CPU)


04:52:40 PM       tps      rtps      wtps   bread/s   bwrtn/s
04:52:45 PM     11.45      1.20     10.24     73.90    128.51
04:52:50 PM      7.43      0.00      7.43      0.00    106.02
04:52:55 PM      6.04      0.00      6.04      0.00     83.70
04:53:00 PM      7.82      1.20      6.61      9.62     96.19
04:53:05 PM      6.64      0.00      6.64      0.00     99.80
04:53:10 PM      5.00      0.00      5.00      0.00     73.60
04:53:15 PM      6.64      0.00      6.64      0.00     96.58
04:53:20 PM     12.50      0.81     11.69      6.45    129.03
04:53:25 PM    236.35    226.71      9.64   1982.33    112.45
04:53:30 PM      8.45      0.40      8.05      3.22    103.02
04:53:35 PM      5.23      0.00      5.23      0.00     77.26
04:53:40 PM      6.63      0.00      6.63      0.00     99.60
04:53:45 PM     44.91     38.32      6.59    427.94     95.81
04:53:50 PM      8.25      3.22      5.03     25.75     74.04
04:53:55 PM     16.50      6.04     10.46    602.01    131.99
04:54:00 PM      7.41      0.80      6.61      6.41     96.19
04:54:05 PM     94.13     86.64      7.49   1457.49     87.45
04:54:10 PM      7.83      0.00      7.83      0.00    112.45
04:54:15 PM      6.61      0.00      6.61      0.00     96.19
04:54:20 PM    135.57    107.32     28.25   1404.88    286.18
04:54:25 PM      7.68      0.00      7.68      0.00    106.67
04:54:30 PM     48.80     40.00      8.80    320.00    115.20
04:54:35 PM      6.21      0.00      6.21      0.00     92.99
04:54:40 PM      6.64      0.00      6.64      0.00     99.80
04:54:45 PM     26.96     16.50     10.46    730.78    144.87
04:54:50 PM     47.39     41.37      6.02    330.92     89.96
04:54:55 PM     55.71     40.88     14.83   1490.98    163.53
04:55:00 PM      7.63      0.00      7.63      0.00    106.02
04:55:05 PM     12.42      0.00     12.42      0.00    141.08
04:55:10 PM      8.65      2.01      6.64    251.11     99.80
04:55:15 PM      9.22      2.40      6.81    365.53    102.61
04:55:20 PM    303.04    294.74      8.30   4093.93     87.45
04:55:25 PM     13.80      0.00     13.80      0.00    208.00
04:55:30 PM     21.02      5.71     15.31     45.71    169.80
04:55:35 PM      6.22      0.00      6.22      0.00     83.53
04:55:40 PM     21.08      0.00     21.08      0.00    221.69
04:55:45 PM      6.63      0.00      6.63      0.00     99.60


--以上各列的含义为:
tps: 每秒向磁盘设备请求数据的次数,包括读、写请求,为rtps与wtps的和。出于效率考虑,每一次IO下发后并不是立即处理请求,而是将请求合并(merge),这里tps指请求合并后的请求计数。
rtps: 每秒向磁盘设备的读请求次数
wtps: 每秒向磁盘设备的写请求次数
bread: 每秒从磁盘读的bytes数量
bwrtn: 每秒向磁盘写的bytes数量




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




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


SQL> select * from v$io_calibration_status;


STATUS                     CALIBRATION_TIME
-------------------------- ---------------------------------------------------------------------------
READY                      08-SEP-15 04.51.27.952 PM


SQL> 




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




---IO校准之前


SQL>  SELECT /*+ PARALLEL */ENAME FROM EMP;


14 rows selected.




Execution Plan
----------------------------------------------------------
Plan hash value: 2873591275


--------------------------------------------------------------------------------------------------------------
| Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |          |    14 |    84 |     2   (0)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR      |          |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)| :TQ10000 |    14 |    84 |     2   (0)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |    PX BLOCK ITERATOR |          |    14 |    84 |     2   (0)| 00:00:01 |  Q1,00 | PCWC |            |
|   4 |     TABLE ACCESS FULL| EMP      |    14 |    84 |     2   (0)| 00:00:01 |  Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------------------------


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




Statistics
----------------------------------------------------------
         34  recursive calls
          0  db block gets
         57  consistent gets
          0  physical reads
          0  redo size
        715  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          6  sorts (memory)
          0  sorts (disk)
         14  rows processed






---IO校准之后


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     |    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------
|   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 |  Q1,00 | P->S | QC (RAND)  |
|   3 |    PX BLOCK ITERATOR |          |    14 |   532 |     2   (0)| 00:00:01 |  Q1,00 | PCWC |            |
|   4 |     TABLE ACCESS FULL| EMP      |    14 |   532 |     2   (0)| 00:00:01 |  Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------------------------


PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------


Note
-----
   - automatic DOP: Computed Degree of Parallelism is 2


15 rows selected.


SQL> 


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




4、结论
Oracle自动化、智能化过程中,是需要提供很多辅助信息的。Calibrate IO是一个重要方面。Oracle不进行自动的Calibrate IO统计量的原因大体有三个:
 
首先是Oracle并不知道实际磁盘的标准指标。
第二是Oracle校准过程生成很大的IO,如果不慎会引起很大产品问题。
第三是Disk IO性能不会经常性发生变化。




























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

你可能感兴趣的:(11g,parallel,io校准)