朋友公司一個erp系統業務辦理不了,但從前臺等待事件來看 DB CPU佔了%DB time的91.81%，這個awr報告取樣時間是兩個小時,總的DB time是810分種伺服器顯示有24個邏輯CPU，每個CPU的耗時是33.75分鐘，CPU的使用率也不是很高,那麼我們來看一下後臺等待事件。

後臺等待事件排在第一的是 db file async I/O submit，這是一個非同步IO相關的等待事件,而LNS wait on SENDREQ,LGWR-LNS wait on channel是與DG相關的日誌傳輸相關的等待事件。這裡的作業系統是Linux,而根據Doc ID 1274737.1文件描述，當disk_asynch_io=true時，而filesystemio_options=none，那麼正常的檔案系統在Linux系統支援非同步I/O的情況下Oracle也不能使用異常I/O。

我們先來檢查一下Linux系統中是否執行過非同步I/O操作

[oracle@ErpOracle01 ~]$ cat /proc/slabinfo | grep kio
kioctx               376    640    384   10    1 : tunables   54   27    8 : slabdata     64     64      2
kiocb                  0      0    256   15    1 : tunables  120   60    8 : slabdata      0      0      0

可以看到kiocb的前兩列為0說明沒有執行非同步I/O操作,用於儲存Oracle資料檔案的就是正常的檔案系統

[root@ErpOracle01 ~]# fdisk -l

Disk /dev/sda: 598.9 GB, 598879502336 bytes
255 heads, 63 sectors/track, 72809 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000a66fb

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         131     1048576   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2             131        8486    67108864   82  Linux swap / Solaris
/dev/sda3            8486       72810   516684800   83  Linux

在這種情況下要讓Oracle使用非同步I/O將引數filesystemio_options設定為’asynch’。

SQL> show parameter disk_asynch_io

NAME                                 TYPE                               VALUE
------------------------------------ ---------------------------------  ------------------------------
disk_asynch_io                       boolean                            TRUE

SQL> show parameter filesystemio_options

NAME                                 TYPE                               VALUE
------------------------------------ ---------------------------------  ------------------------------
filesystemio_options                 string                             none
SQL> alter system set  filesystemio_options='asynch' scope=spfile;

System altered.

LNS wait on SENDREQ是DG的RFS I/O時間和網路時間的總計，而它可能是由網路頻寬或備庫的I/O效能引起的。而這經確認是備庫的I/O效能引起的，再加上在這期間後臺維護人員在主庫做大批次的資料更新。在主庫中出現了Log file sync和log file parallel write等待事件。LGWR-LNS wait on channel等待事件是日誌寫程式或網路伺服器程式在KSR通道上等待接受訊息所花的時間.LNS wait on SENDREQ, Log file sync, log file parallel write, LGWR-LNS wait on channel透過調整備庫I/O效能和對主庫增加online and standby redo logs來改善。然後在中午休息時間重啟了資料庫,經過三天的執行，業務沒有出現辦理不了的情況了。