怎么解決數據庫中沒有索引導致的DIRECT PATH READ

本篇內容主要講解“怎么解決數據庫中沒有索引導致的DIRECT PATH READ”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“怎么解決數據庫中沒有索引導致的DIRECT PATH READ”吧!

直接看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，說明系統是提交過于頻繁的。

    針對上述問題，給出以下應對辦法：

1. 在tbcm_catalogfile表的F_OBJECTID,F_PACKAGEPATH字段上創建組合索引

2. 由于硬件無法更換，所以日志文件的IO爭用可不管它

3. 將日志文件從現在的50M，改為2G大小

4. 由于調整代碼工作量過大，COMMIT提交過于頻繁的問題可不用管它。

    

調整之后，再次執行入庫作業，并收集15:00-15:15之間的AWR報告。通過驗看報告，上述問題解決：

到此，相信大家對“怎么解決數據庫中沒有索引導致的DIRECT PATH READ”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！