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）。
Oracle 11g中的IO Calibrate（IO校準）
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章