怎么解決數(shù)據(jù)庫中沒有索引導致的DIRECT PATH READ

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

直接看TOP 5 EVENTS，這是數(shù)據(jù)庫問題診斷的最快捷徑。

先看占DB TIME達63.33%的direct path read事件。等待次數(shù)78586次，等待總時間3833s（約64分鐘），而elapsed time只有20分鐘。因此我們需要弄清楚是什么動作導致這么高的direct path read。

那什么是direct path read呢？一般來說，數(shù)據(jù)塊BLOCK(即ORACLE的最小存儲單元)總是先由后臺服務(wù)器進程緩沖至buffer cache，而后才被服務(wù)器進程獲取。但對于一些大表，將其緩沖至buffer cache勢必會將buffer cache中的許多其它對象擠出，即ageing out。為了避免這一情況，產(chǎn)生了direct path read,即不需要緩沖到緩存區(qū)，而是直接由服務(wù)器進程從磁盤獲取。ORACLE通過一些參數(shù)控制在何種情況下采取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。現(xiàn)在我們知道了physical reads主要發(fā)生在哪個對象上，但仍然不知道發(fā)生在哪個業(yè)務(wù)上（即哪個SQL邏輯上）。即然Physical reads是等待最多，自然地，我們需要去查看Physical reads最多的SQL語句：

根據(jù)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有關(guān)，接下來，我們查看該表的相關(guān)信息。得知，該表有4,000,000多條記錄，F(xiàn)_OBJECTID字段幾乎是唯一的，然而表上沒有任何索引。由于沒有索引，有執(zhí)行上述SQL時，ORACLE只有選擇全表掃描的方式，而對于如此大的一張表，恰好符合了DIRECT PATH READ的條件，因此執(zhí)行計劃選擇使用DIRECT PATH READ的方式來獲取數(shù)據(jù)。如果是單個進程，事實上已經(jīng)很糟了。多個進程是，同于是direct path read，沒有將block緩沖至緩存區(qū)，所以每個進程都得通過direct path read獲取自己想要的數(shù)據(jù)。情況因此變得更糟。

分析完TOP 5 EVENTS中和第1名，接下來，我們分析一下第2名。

第2名是log file sync。當發(fā)出COMMIT或ROLLBACK命令的時間，服務(wù)器進程會喚醒LGWR進程，LGWR負責將REDO BUFFER中的日志緩存刷新到日志文件中。而LGWR后臺進程產(chǎn)生的等待事件是log file parallel write。因此一般說來，前臺log file sync等待事件高，后臺log file parallel write也會高，我們在AWR報告中驗證一下：

果不其然。另外log file parallel write的avg wait為28ms，高于20，根據(jù)經(jīng)驗意味著存在日志文件IO急用。

    繼續(xù)看：

    日志在20分鐘內(nèi)切換了5次，平均每4分鐘切換一次，這個是遠高于15－20分鐘公認的切換一次。這說明REDO FILE文件可能過小。

    繼續(xù)看：

    20分鐘之內(nèi)，沒有發(fā)生回退，即user rollback=0。User calls/(user commints + user rollback) =9.87 ，該值小于經(jīng)驗值25，說明系統(tǒng)是提交過于頻繁的。

    針對上述問題，給出以下應(yīng)對辦法：

1. 在tbcm_catalogfile表的F_OBJECTID,F_PACKAGEPATH字段上創(chuàng)建組合索引

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

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

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

    

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

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