一、背景

今天突然被異地的同事拉來開遠程會議，會議內容是開發反饋每天9點左右有個sqlldr 命令的腳本調用突然執行很慢，以前幾秒的導入操作現在需要30-60s左右，而且數據量基本相同。

二、分析

1）、查看ASH報告

從報告上確認是數據庫的IO的問題，sqlldr導入數據會有IO，但出現gcs log flush sync 事件就很不正常。
再次手動導了一次，用iostat 觀察都怎么產生IO,因此懷疑是存儲或光纖交換機的問題。

2）、查看alert日志

一個節點正常，另一個節點報：minact-scn: useg scan erroring out with error e:12751

百度了一下報錯，發現好多文章說與多路徑有關，查看多路徑狀態ok。

3）、查看系統日志

發現磁盤路徑一直不穩定，4條路徑有1條狀態一會在線一會Fail,并報有I/O error:

于是確認為多路徑引起的IO問題。

4）、查看光纖交換機

交換機0 口中異常：

三、處理

于是安排同事晚上對交換機0口光纖模式進行更換，在拔掉光纖模塊后僅有三條鏈路的時候，進行了一次sqlldr的導入操作，很快就導入12.53s完成：

IO異常的導入時長18分16s,同樣是58460Rows

于是對此口的光纖模塊進行了更換，從而解決了此問題。

四、總結

1、對日志的巡檢不是很到位，本來查看系統日志就能快速的定位問題。（當時同事表示看過日志沒有任何報錯，必定同事也是10年經驗的老DBA了，主觀了忽略了第一時間去查看系統日志。）
2、對多路徑認識不到位，淺意識認為：4條路徑壞1條的話應該不會影響IO，誰成想這種半死不活的狀態最要命。