5月20號下午4－5點，某項目組進行數據入庫作業，作業人員反映入庫速度很慢。在16:30和16:50分別采集了快照，並根據兩個快照得到AWR報告。
直接看TOP 5 EVENTS，這是數據庫問題診斷的最快捷徑。
先看占DB TIME達63.33%的direct path read事件。等待次數78586次，等待總時間3833s（約64分鍾），而elapsed time只有20分鍾。因此我們需要弄清楚是什么動作導致這么高的direct path read。
那什么是direct path read呢？一般來說，數據塊BLOCK(即ORACLE的最小存儲單元)總是先由后台服務器進程緩沖至buffer cache，而后才被服務器進程獲取。但對於一些大表，將其緩沖至buffer cache勢必會將buffer cache中的許多其它對象擠出，即ageing out。為了避免這一情況，產生了direct path read,即不需要緩沖到緩存區，而是直接由服務器進程從磁盤獲取。ORACLE通過一些參數控制在何種情況下采取direct path read。
既然direct path read很高，那就直接去查看對於哪些對象的direct path read高。通過查看segment by direct physical reads，可以獲得這一信息：
顯而易見，direct physical reads是由於訪問tbcm_catalogfile引起的。因為physical reads= physical reads cache + physical reads direct，因此，除了查看segment by direct physical reads，也有必要查看一下segment by physical reads 的情況：
Physical reads最多的仍然是表tbcm_catalogfile。現在我們知道了physical reads主要發生在哪個對象上，但仍然不知道發生在哪個業務上（即哪個SQL邏輯上）。即然Physical reads是等待最多，自然地，我們需要去查看Physical reads最多的SQL語句：
根據SQL_ID查看第一條SQL語句，其文本為：
SELECT F_ID, F_OBJECTID, F_FILELOCATION, f_filesrclocation, F_ISONSERVER, F_DATASIZE, F_PACKAGEPATH, F_SERVERID, F_ISMAINFILE, F_FILEPROPERTY, F_DIRTYPE FROM TBCM_CATALOGFILE where F_OBJECTID=:"SYS_B_0" and F_PACKAGEPATH=:"SYS_B_1" order by F_OBJECTID
果然與表tbcm_catalogfile有關，接下來，我們查看該表的相關信息。得知，該表有4,000,000多條記錄，F_OBJECTID字段幾乎是唯一的，然而表上沒有任何索引。由於沒有索引，有執行上述SQL時，ORACLE只有選擇全表掃描的方式，而對於如此大的一張表，恰好符合了DIRECT PATH READ的條件，因此執行計划選擇使用DIRECT PATH READ的方式來獲取數據。如果是單個進程，事實上已經很糟了。多個進程是，同於是direct path read，沒有將block緩沖至緩存區，所以每個進程都得通過direct path read獲取自己想要的數據。情況因此變得更糟。
分析完TOP 5 EVENTS中和第1名，接下來，我們分析一下第2名。
第2名是log file sync。當發出COMMIT或ROLLBACK命令的時間，服務器進程會喚醒LGWR進程，LGWR負責將REDO BUFFER中的日志緩存刷新到日志文件中。而LGWR后台進程產生的等待事件是log file parallel write。因此一般說來，前台log file sync等待事件高，后台log file parallel write也會高，我們在AWR報告中驗證一下：
果不其然。另外log file parallel write的avg wait為28ms，高於20，根據經驗意味着存在日志文件IO急用。
繼續看：
日志在20分鍾內切換了5次，平均每4分鍾切換一次，這個是遠高於15－20分鍾公認的切換一次。這說明REDO FILE文件可能過小。
繼續看：
20分鍾之內，沒有發生回退，即user rollback=0。User calls/(user commints + user rollback) =9.87 ，該值小於經驗值25，說明系統是提交過於頻繁的。
針對上述問題，給出以下應對辦法：
- 在tbcm_catalogfile表的F_OBJECTID,F_PACKAGEPATH字段上創建組合索引
- 由於硬件無法更換，所以日志文件的IO爭用可不管它
- 將日志文件從現在的50M，改為2G大小
-
由於調整代碼工作量過大，COMMIT提交過於頻繁的問題可不用管它。
調整之后，再次執行入庫作業，並收集15:00-15:15之間的AWR報告。通過驗看報告，上述問題解決：
