共計 2217 個字符，預計需要花費 6 分鐘才能閱讀完成。

本篇內容主要講解“怎么解決數據庫中沒有索引導致的 DIRECT PATH READ”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“怎么解決數據庫中沒有索引導致的 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，說明系統是提交過于頻繁的。

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

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

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

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

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

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

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