如何解讀Oracle的LOAD PROFILE

這段時間一直在出差中，所以發文時間可能會不確定，如果早上有空，我儘量寫點東西，如果一大早就有會或者在交通工具上，我就偷個懶了。

大多數做資料庫最佳化的DBA在閱讀AWR報告的時候，都是從TOP EVENT開始閱讀的，或者把TOP EVENTS當成重點來閱讀，所有的分析都是圍繞著TOP EVENTS的，我剛剛開始學習閱讀STATSPACK報告的時候，也是如此。不過隨著對Oracle資料庫最佳化與診斷的經驗的深入，這個習慣逐漸被改變了。如果你讓我看一份Oracle報告，我會圍繞著Load profile來分析。因為大多數資料庫的效能問題與故障都是與資料庫負載相關的，經常有朋友說，為什麼這套系統會出問題，另外一套不出問題，或者說為什麼RAC的一個節點出問題，另外一個節點為什麼不出問題。要回答這樣的問題，大多數情況也都可以從負載的不同裡去找答案。

Oracle的LOAD PROFILE是AWR報告中十分重要的一個章節，包含了大量的關於資料庫負載的有價值的資訊。LOAD PROFILE報告了資料庫系統在一段時間內的平均負載情況，其中包括了許多效能關鍵指標，如每秒鐘的邏輯讀(logical reads per second)、物理讀(physical reads per second)、執行的SQL語句數(SQL執行數)、每秒REDO量、每秒事務數、使用者連線數(user calls per second)等。透過分析LOAD PROFILE，可以幫助DBA評估資料庫系統的負載情況，並作出相應的最佳化決策。例如，如果LOAD PROFILE報告物理讀非常高，那麼可以嘗試增加記憶體快取，減少物理讀取的次數，以提高資料庫的效能，或者最佳化後端儲存的IO效能。

我們該如何閱讀LOAD PROFILE呢?今天我把我對LOAD PROFILE的閱讀經驗分享給大家。

大家能從LOAD PROFILE上看到些什麼呢?我們先從指標的含義來簡單地看看這份LOAD PROFILE。

1.DB Time(s): 這個指標表示資料庫系統用了多長時間來完成所有的操作，單位為秒。每秒平均處理時間為1,345.4秒，這是一個非常高的數值，表明資料庫系統正在經歷一定的壓力和負載，或者存在某種異常的等待或者阻塞，需要檢視和最佳化資料庫的配置和效能，以提高系統的響應時間。

2.DB CPU(s): 這個指標表示在資料庫系統中使用的 CPU 時間，單位為秒。每秒平均使用 CPU 時間為165.1秒，這也是一個較高的數字，表明資料庫系統的 CPU 使用率較高。這可能意味著需要進一步最佳化查詢和應用程式的效能，以減少 CPU 的負載。

3.Redo size (bytes): 這個指標表示在資料庫中記錄事務日誌的大小，單位為位元組。每秒平均 redo 日誌大小為14,425,930.7位元組，這是一個相對較高的數字。如果系統的 redo 日誌緩衝經常寫滿或者需要經常進行日誌切換，這可能會影響系統的效能，需要進一步檢視相關的指標來確定REDO效能是否存在問題。如果該指標較高，則要透過LOG FILE SYNC，LOG FILE PARALLEL WRITE，LOG FILE SWITCH COMPLETE等等待事件的延時來分析REDO負載是否已經對資料庫的效能造成了較為嚴重的影響。並透過分析REDO相關的LATCH的丟失率分析是否存在過高的爭用。

4.Logical read (blocks): 這個指標表示資料庫系統每秒平均進行的邏輯讀取次數，單位為塊。每秒平均邏輯讀取次數為9,643,527.6次，這是一個相對較高的數字，表示系統正在經歷相當大的CPU壓力。可以透過最佳化SQL來減少邏輯讀取次數，從而提高系統的效能。

5.Block changes: 這個指標表示每秒平均進行的塊更改次數。每秒平均塊更改次數為108,760.0次，這個數字也比較高，可能表明資料庫中的更新操作較為頻繁。需要檢視更新操作是否可以進行批次處理或者調整更新策略。

6.Physical read (blocks): 這個指標表示每秒平均進行的物理讀取次數，單位為塊。每秒平均物理讀取次數為75,738.2次，這個數值比較高，可能表示系統需要從磁碟上讀取資料的次數較多，可能需要考慮加快磁碟 I/O 的速度或者最佳化查詢以減少物理讀取次數。

7.Physical write (blocks): 這個指標表示每秒平均進行的物理寫入次數，單位為塊。每秒平均物理寫入次數為2,561.1次，這個數字與讀相比不算太高，表明資料庫系統的寫入操作較少。

8.Read IO requests: 每秒25,547.9，這個是資料庫讀IO對OS產生的讀IOPS的數量，如果該數量較高，則說明資料庫對底層IO子系統的壓力較大。

9.Write IO requests: 每秒434.9，這個是資料庫寫IO對OS產生的寫IOPS的數量，如果該數量較高，則說明資料庫對底層IO子系統的寫IO壓力較大。本系統的寫IOPS不算太高。

10.Read IO (MB): 每秒591.7MB,這是讀IO的吞吐量，本系統雙節點RAC，一個節點在半小時平均值中的每秒就高達591MB，說明本系統的IO負載還是很大的。

11.Write IO (MB): 每秒磁碟寫入量為20.0MB，這個指標不算高，如果要分析是否對資料庫造成了較大影響。

12.Global Cache blocks received: 每秒894.7個BLOCK，這個指標表示從遠端例項每秒獲取的資料塊數量，如果存在異常則說明RAC叢集的GCS服務存在效能問題。

13.Global Cache blocks served: 每秒657.7塊，這個指標表示每秒傳送給遠端例項的資料塊數量，如果存在異常則說明RAC叢集的GCS服務存在效能問題。

14.User calls: 每秒25,408.0，這個數值對於這樣的系統來說並不算高。每秒使用者呼叫數量包含SQL語句執行的數量。該指標越高說明資料庫的併發負載越高。

15.Parses (SQL): 每秒解析數量1,784.8，對於這個系統來說並不算高。

16.Hard parses (SQL): 每秒硬解析344.0，對於每秒只有2萬5 USER CALL的系統來說，這個硬解析數量是相當高了。不過硬解析是否造成了效能影響，還要看後面的等待事件裡的SHARED POOL，CURSOR相關的等待是否比較嚴重，或者延時過高。

17.SQL Work Area (MB): SQL工作區的大小為361.8MB，這個指標實際上是很容易被忽略的。對當前150GB的共享池的系統來說，這個資料並不算高，因為這個系統的特點是單個SQL的開銷過大，而併發量並不算大。如果這個區域很大，並且增長異常，那麼大機率是遇到了某些BUG了，或者說你需要關注它，避免因為SQL AREA擴充套件太大，引發一些問題。

18.Logons: 每秒登入3.3個會話，這說明系統存在一些短連結應用。

19.Executes (SQL): 每秒SQL執行3,094.0次，對於256 CPU執行緒的8路伺服器來說，算是比較低的了。

20.Rollbacks: 每秒4.5個，如果這個指標異常高就需要查查了，不過有些資料庫應用獲取了連線後，會先執行一個ROLLBACK，以避免應用BUG導致的問題，這種系統中，這個指標會比較高。可以以此為基線來觀察，嚴重超出此基線才說明系統有問題。

21.Transactions: 每秒44.5個事務。

似乎看上去，上面的這21個指標都不難看懂，實際上我們似乎看懂了，但是似乎什麼也沒看見，因為我們無法直接從這些指標中獲得到分析系統問題所需要的線索。看LOAD PROFILE，首先要把LOAD PROFILE中的各個指標串起來看，而不是單一地去看某個指標。比如本系統硬解析比較高，達到344次每秒，那麼會不會對共享池或者CURSOR產生較大爭用呢?這時候我們要看USER CALL和Executes這兩個指標了，如果這兩個指標也很高，那麼硬解析如此高肯定會帶來效能問題，幸運的是這個系統中的這些指標都不高。

我們從TOP EVENTS和等待事件總體分析上，都看出共享池相關的而等待並不嚴重，concurrency相關的等待也佔比很低。這樣就可以排除這個負載指標可能引發效能問題了。

現在我們的國產資料庫大多數也有LOAD PROFILE，不過看這些LOAD PROFILE我們更是一頭霧水，因為缺少後面可以進一步分析某個負載指標異常的相關資料了。而Oracle這方面就十分豐富。比如我們發現IO負載很高，那麼IO到底有沒有問題呢?AWR報告中我們可以從很多角度去驗證。

比如上面的wait Class的彙總分析，USER IO平均延時3毫秒，佔比18.9%，SYSTEM IO平均延時1毫秒，佔比0.1%。這說明IO問題並未對資料庫造成較大影響。再看具體等待事件。

前臺等待事件中的io相關等待延時均較為正常。

後臺程式的IO也很正常。從上面我們就基本上可以確定，雖然IO很高，但是後端儲存很給力，IO效能目前沒有問題。

如果你還不放心，你可以繼續分析IO stats去檢視更詳細的資訊。甚至透過FILE IO的章節去看是不是存在整體IO效能不錯，單個檔案存在問題的情況。這種情況在以前使用裸裝置的時候十分常見。或者說你使用ASM的時候，存在多個ASM磁碟組，而這些磁碟組的磁碟來源於不同的儲存，或者不同型別的儲存。那麼可能總體IO效能指標很好，但是存在某些盤的IO存在效能問題。

為了分析清如此複雜的情況，必須以LOAD PROFILE為綱，以此為起點去做綜合分析才可以得到更為精準的分析結論。這也給我們的國產資料庫的可觀測效能力提供了一個樣板，我們提供了LOAD PROFILE，是否也提供了足以分析LOAD PROFILE的指標呢?