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

dbhelper發表於2014-11-29

 

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趨勢。

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

 

結束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效能不會經常性發生變化。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/8494287/viewspace-1351135/,如需轉載,請註明出處,否則將追究法律責任。

相關文章