今天是2014-04-21，今天簡單只說明一下怎麼影響重做數據的一個因素，那就是i/o吞吐量，oracle的介質恢復依賴於i/o，如果i/o存在瓶頸，那麼勢必會影響備庫的介質恢復。
那麼i/o stack包含hbas，存儲相關的交換機、存儲物理磁盤。那麼oracle建議在應用程序部署的時候，建議去驗證i/o避免存在問題。但是之前有一個很刺手的問題，那就是如何去驗證i/o側吞吐量，換句話說怎麼去驗證i/o吞吐量更符合真實的生產環境。
In Oracle Database 11g, the Real Application Testing feature (Capture/Replay) was introduced to inject real (captured) workload into the system. However, another new 11g feature is available to help assess the I/O capability of the database's storage system, and gauge maximum IOPS and Mbytes/s.
capability i/o feature 是依據一個數據庫內部的函數（dbms_resource_manager.calibrateio()),該函數是oracle database內部集成的，更能滿足測試i/o問題，且在最後將輸出相關報告信息。
那麼執行這個包需要注意什麼呢？
1、權限，必須具有sysdba執行該過程的權限，另外需要打開timed_statistics。
2、確定異步i/o在數據庫的所有數據文件和臨時文件都已經得到應用啟動，我們可以通過v$datafile 和v$iostat_file視圖關聯進行、確認。
eg：
col name format a50
select name,asynch_io from v$datafile f,v$iostat_file i
where f.file#=i.file_no
and (filetype_name='Data File' or filetype_name='Temp File');
如果異步i/o沒有啟動，設置disk_asynch_io=true啟動該功能，但默認是開啟的，如果在linux中最大slots使用完畢，那麼將自動關閉噶 功能，這也就是為什麼雖然設置了disk_asynch_io=true了卻依然沒有達到效果。最大的slots可以查看/proc/sys/fs/aio-max-nr 當前使用的可以查看/proc/sys/fs/aio-nr去分別確認。
3、確保服務器只有需要測試的數據庫開啟，避免 其他應用軟件的影響。
4、對於RAC，需要確保所有的實例都開啟，因為 將會對所有節點做全面的校對，執行該過程只需在一個實例即可。
5、確保只有一個用戶執行一個校對i/o的操作。可以通過v$io_calibration_status查看當前鑒定狀態。
另外查看資料了解到有這麼幾個過程：
The calibration will run in different phases. In the first phase, small block random I/O
workload is performed on each node and then concurrently on all nodes. The second
phase will generate large block sequential I/O on each node. Note, that the Calibrate
I/O is expecting that a datafile is spread across all disks specified in NUM_DISKS
variable. Furthermore, offline files are not considered for file I/O.
一旦執行完畢，其結果將存在於dba_rsrc_io_calibrate表中。
好了。
了解到這些，下面開始去實驗操作。讓實踐得真知。
語法如下：
SET SERVEROUTPUT ON
DECLARE
lat INTEGER;
iops INTEGER;
mbps INTEGER;
BEGIN
-- 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);
end;
/
參數介紹如下：
Parameter Description
num_physical_disks
Approximate number of physical disks in the database storage（物理磁盤個數 input）
max_latency
Maximum tolerable latency in milliseconds for database-block-sized IO requests（最大可用容忍延遲的毫秒數 input）
max_iops
Maximum number of I/O requests per second that can be sustained. The I/O requests are randomly-distributed, database-block-sized reads.（持續中每秒請求最大i/o的數量 output）
max_mbps
Maximum throughput of I/O that can be sustained, expressed in megabytes per second. The I/O requests are randomly-distributed, 1 megabyte reads.（持續中最大的吞吐量M為單位）
actual_latency
Average latency of database-block-sized I/O requests at max_iops rate, expressed in milliseconds（平均延遲）
環境為oracle linux 6.4 +database 11.2.0.4（RAC 2節點 ）+asm 11.2.0.4
對了，另外如果數據庫使用的是asm，那麼如果驗證的死數據文件需要使用datadg中的所有物理磁盤，而不是fra中的物理磁盤。雖然我使用存儲化的lun進行的映射，但是
num_physical_disks必須是真實物理磁盤個數,因為是測試是一個磁盤，那麼這個參數為1。
1、驗證是否啟動async i/o
[oracle@rac-one ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on Mon Apr 21 22:35:23 2014
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
SQL> show parameter disk_asynch_io（查看數據庫是否啟用了異步i/o）
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
disk_asynch_io boolean TRUE
SQL> !
[oracle@rac-one ~]$ more /proc/sys/fs/aio-max-nr （系統slots最大數量）
1048576
[oracle@rac-one ~]$ more /proc/sys/fs/aio-nr （當前使用的slots）
23680
[oracle@rac-one ~]$ exit
exit
SQL> col name for a50
SQL> set linesize 200
SQL> select name,asynch_io from v$datafile f,v$iostat_file i where f.file#=i.file_no and (filetype_name='Data File' or filetype_name='Temp File'); -------------（查看啟用了async的文件信息）
NAME ASYNCH_IO
-------------------------------------------------- ---------
+DATADG/rac/datafile/system.262.839537769 ASYNC_ON
+DATADG/rac/datafile/system.262.839537769 ASYNC_ON
+DATADG/rac/datafile/sysaux.263.839537911 ASYNC_ON
+DATADG/rac/datafile/undotbs1.264.839538031 ASYNC_ON
+DATADG/rac/datafile/undotbs2.266.839538155 ASYNC_ON
+DATADG/rac/datafile/users.267.839538199 ASYNC_ON
6 rows selected.
SQL>
開始驗證i/o:
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(1,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 /
查看狀態信息：
SQL> select * from v$io_calibration_status;
STATUS CALIBRATION_TIME
------------- ---------------------------------------------------------------------------
IN PROGRESS
SQL> select file_no,small_read_megabytes,small_read_reqs,large_read_megabytes,large_read_reqs from v$iostat_file;
FILE_NO SMALL_READ_MEGABYTES SMALL_READ_REQS LARGE_READ_MEGABYTES LARGE_READ_REQS
---------- -------------------- --------------- -------------------- ---------------
0 0 24 0 0
0 107 6819 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
1 40 4808 884 901
FILE_NO SMALL_READ_MEGABYTES SMALL_READ_REQS LARGE_READ_MEGABYTES LARGE_READ_REQS
---------- -------------------- --------------- -------------------- ---------------
1 0 4 0 0
2 28 2515 777 779
3 5 577 351 351
4 3 404 264 264
可知正在進行測試中：
執行結束將輸出結果如下：
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(1,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=45
latency=42
max_mbps=12
PL/SQL procedure successfully completed.
SQL>
可以知道這兩個節點請求小塊讀為45，最大吞吐量為12M/s。虛擬機就是卡的掉渣。
