最佳實踐：針對效能問題的主動型資料收集 (文件 ID 1549179.1)

文件內容

適用於:

用途

本文件介紹了一種最佳實踐方法，用於確保在第一次發生問題時主動收集到足夠的效能資料，從而能夠有效地確定根本原因。您可以將本文件與下列文件結合使用，幫助避免問題發生，或者在問題無法避免時收集進行快速診斷所需的資訊：

.

提出問題、獲取幫助並分享您的經驗

您想要與其他 Oracle 客戶、Oracle 員工及業內專家深入探討嗎？

適用範圍

本文件旨在為資料庫使用者提供關於診斷效能資料收集的主動型最佳實踐的建議。

詳細資訊

方法

我們的最佳實踐方法包括：

• 自上而下的資料收集方法
• 建立多條基線
• 在問題發生前安裝並執行正確的工具
• 針對不穩定的環境部署專用工具

自上而下的方法：

作業系統 (OS) 級的資料收集。

只有當 Oracle 所在的伺服器以最佳狀態執行時，Oracle 才能以最佳狀態執行。因此，當您開始在伺服器級別進行資料收集時，最好使用 OSWatcher 來捕獲作業系統指標，從而可以監視並調整伺服器效能。

• OSWatcher OSWatcher(OSW) 包含一個內建的分析器，透過該分析器，可以對已收集的資料進行自動分析，進而主動查詢 CPU、記憶體、IO 和網路問題。建議所有使用者安裝並執行 OSWbb，因為對於查詢 OS 問題，OSWbb 的作用非常大，且幾乎沒有開銷。
  
  在預設情況下，一旦安裝並執行 OSWatcher，它將提供對最近 48 個小時的 OS 資料進行“回看”功能。因此，如果在凌晨 2 點發生了節點驅逐，Oracle Support 將能夠從 OSWatcher 日誌中看到當時在 OS 上發生的情況。在 OSWatcher Black Box 之前，您沒有辦法回看在失去服務或出現嚴重效能問題的時候 OS 上可能發生的事情，Oracle 也無法瞭解 OS 上的情況。
  
   有關 OSWatcher 的下載、使用者指南和使用影片等資訊，請參閱以下文件。
  
  
  Document 301137.1 OSWatcher User Guide (Includes: [Video])

資料庫級的資料收集

幾個可用於收集進行效能分析所需綜合資料的工具：

• AWR 在有關資料庫效能問題的資料收集方面，AWR 是最全面的工具。它主要用於收集資料庫指標（儘管它也可能包含一些 OS 指標）。
  
  如果您預計不會發生效能問題且環境穩定，我們的最佳實踐建議是每 60 分鐘（預設）收集一次 AWR 快照。如果您擔心會發生效能問題，建議您提高快照的頻率。這種情況下，建議的最大快照時間間隔為 20 分鐘；如果系統能夠負擔得起，更高頻率的快照會更好。更高頻率的快照可以讓我們更加細緻地看到在資料庫上發生的情況，然後可以將這些情況與資料庫效能良好時的情況進行比較。無論您選擇哪種快照時間間隔，請保持這個間隔一直收集，以便能夠進行報告比較。
  
  在效能良好的時候抓取一些快照作為正常基線，以便在發生問題時進行比較，這一點非常重要。在很多時候，就算只有 AWR 資料我們也足以定位 bug，並且在一些例項中，AWR 資料會提供足夠多的資訊用於診斷資料庫掛起及其他問題，且無需進行其他特殊的診斷，如收集 systemstate和 hanganalyze。
  
  此外，AWR 還可用於深入探查特定的 sql 語句。如果問題發生在會話級別，則可以先獲取 AWR 報告並進行分析，然後嘗試進行其他 10046 或 sql 跟蹤診斷。上述資訊也可與 ASH 報告一起使用（見下文）。
  
  有關 AWR 的更多資訊，請參閱以下文章：
  
  
  Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point
• ASH Active Session History（ASH）報告會提供非常細緻的指標收集資訊，因為它們會深入到會話級別。與 AWR 提供的效能資料的聚合檢視相比，ASH 以 1 秒級精度提供各個資料庫會話的資訊。對於間歇效能問題或掛起，這非常重要。利用 ASH 資料有時足以在會話級別診斷問題，從而無需進行其他 10046 或 sql 跟蹤診斷。可以根據需要透過 Automatic Workload Repository（AWR） 獲取 ASH 報告。
  

  有關 Active Session History (ASH) 的更多詳細資訊，請參閱：
  

  Document 243132.1 10g and above Active Session History (Ash) And Analysis Of Ash Online And Offline

Automatic Workload Repository (AWR) 和 Active Session History (ASH) 報告是 Oracle Diagnostics Pack 的兩個獨立元件，且必須作為單獨選項獲得使用許可。最佳實踐建議是獲取並使用該許可，從而可以訪問該資料。請參閱：

否則，您必須使用 statspack 工具。

建立多條基線：

應根據您的業務特徵，獲取並儲存不同時段的基線。建議的基線收集包括：

• 正常活動
• 非繁忙時間
• 一天中最忙的時間
• 月末或業務週期處理
• 批處理作業

擁有上述多條基線時，您將會清楚地瞭解系統是如何正常執行的。當發生問題時，與這些基線進行比較將有助於解決問題。如果未建立基線，要理解效能問題的本質將更加困難。如果使用者在系統效能不佳時僅提供 AWR，則將更加難以分析資料庫的效能；在沒有比較的情況下，資料庫效能好壞與否可能就會變成“主觀臆測”。作為最佳實踐，Oracle Support 建議建立 O/S (OSWbb) 和資料庫 (AWR) 的基線。

做好準備！：在問題發生前安裝並執行正確的工具

除了安裝並執行 OSW 以及在指定的時間間隔收集 AWR 外，Oracle Support 還提供了一些專用工具，您應該在伺服器上安裝這些工具，一旦發生問題，可確保能立即派上用場。

• HangFG

  HangFG 可以自動收集掛起診斷，使用者無需知道要生成的 trace 的型別和級別。如果 HangFG 已安裝，並且資料庫發生了掛起，此時使用者可以使用一個簡單的 unix shell 命令列介面，他們可以根據自己的需要選擇不同資料量的資料收集。
  
  請參閱下列文件，獲取有關 Hangfg 的下載和使用者指南。
  
  
  Document 362094.1 HANGFG User Guide
  
  當前有 3 個級別可供使用者選擇，以啟動掛起診斷資訊的自動生成。這為使用者提供了一定的靈活性，使用者可以確保在進行掛起診斷的時候儘可能不干擾資料庫（如果資料庫仍處於正常執行狀態）。
  
  
  1. 對系統產生輕度影響。此選項收集 2 個 hanganalyze 級別 3 的 trace 檔案，然後確定是否還可以在對系統產生最小影響的情況下收集 1 個 hanganalyze 級別 4 的 trace 檔案。如果可以，它將收集 hanganalyze 級別 4 的 trace 檔案。如果不可以，它將不收集其他 trace 檔案。
  2. 對系統產生中度影響（預設值）。此選項收集 1 個 hanganalyze 級別 3 的 trace 檔案，然後確定是否還可以在對系統產生最小影響的情況下收集 2 個 hanganalyze 級別 4 的 trace 檔案。如果可以，它將收集 2 個其他的 hanganalyze 級別 4 的 trace 檔案。如果不可以，它將收集 1 個其他的 hanganalyze 級別 3 的 trace 檔案。此選項還收集 1 個 systemstate 級別 266 的 trace 檔案。
  3. 對系統產生重度影響。此選項收集 2 個 hanganalyze 級別 4 的 trace 檔案和 2 個 systemstate 級別 266 的 trace 檔案。

• SQLHC

  SQL Tuning Health-Check Script 是 Oracle Server Technologies Center of Expertise 開發的一款工具。該工具，又稱為 SQLHC，用於檢查單個 SQL 語句執行的環境，並檢查基於成本的 optimizer (CBO) 統計資訊、schema 物件後設資料、配置引數和可能會影響正在分析的 SQL 效能的其他元素。
  有關此工具的更多詳細資訊，請參閱：
  
  
  Document 1366133.1 SQL Tuning Health-Check Script (SQLHC)
  
  SQLHC 旨在允許使用者確保單個 SQL 執行的環境是健康的，並儘量避免能夠避免的 SQL 效能問題。執行時，它“不會在資料庫上留下任何痕跡”，從而確保可以在所有系統上執行。針對一個 SQL_ID 執行時，該指令碼會生成一個 HTML 報告，其中包括有關所提供的那個 SQL 語句的一組健康檢查結果。

• SQLTXPLAIN (SQLT)

  這是一款更加複雜的工具，用於解決 SQL 效能問題（但會在資料庫上留下痕跡）。SQLTXPLAIN，又稱為 SQLT，是由 Oracle Support 提供的一款工具，輸入一個 SQL 語句後，它會輸出一組診斷檔案。這些檔案通常用於診斷效能不佳的 SQL 語句。SQLT 會連線到資料庫，並收集執行計劃、基於成本的 optimizer CBO 統計資訊、schema 物件後設資料、效能統計資訊、配置引數和會影響正在分析的 SQL 效能的其他因素。
  
  有關 SQLT 的更多詳細資訊，請參閱以下文件。
  
  
  Document 215187.1 SQLT (SQLTXPLAIN) - Tool that helps to diagnose a SQL statement performing poorly

針對不穩定的環境部署專用工具：

大部分使用者的環境是穩定的，沒有任何效能問題。對於擁有不穩定環境且正遇到無法透過上述傳統資料收集方法解決的掛起或遇到瞬間效能問題的使用者，Oracle Support 提供了一些專用工具，以協助除錯此類問題。

• LTOM

  LTOM 是一款可安裝在客戶 unix/linux 平臺上的非常特別的工具。對於那些很少發生，或者發生時間很短以至於無法手工收集資訊的問題，此工具可以用來自動收集需要的資訊。例如，LTOM 可以監控瞬間發生的問題，並在發生問題時自動收集診斷，然後透過電子郵件通知使用者，同時生成解決問題所必需的診斷 trace 檔案。如果您的資料庫在凌晨 2 點掛起，周圍沒有工作人員，LTOM 會自動檢測並獲取診斷，因此在您記錄 SR 時 Oracle Support 就可以獲取所必需的診斷 trace 檔案。
  
  有關下載和使用者指南，請參閱以下文章。
  
  
  Document 352363.1 LTOM - The On-Board Monitor User Guide

• Procwatcher

  Procwatcher 工具用於按時間間隔檢查和監控 Oracle 資料庫和/或叢集程式。該工具會使用 Oracle 工具（如 oradebug short_stack）和/或 OS 除錯程式（如 pstack、gdb、dbx 或 ladebug）收集堆疊 trace 檔案，如果指定的話還會收集 SQL 資料。
  
  有關詳細資訊，請參閱以下文章：
  
  
  Document 459694.1 Procwatcher: Script to Monitor and Examine Oracle DB and Clusterware Processes

升級前要收集的資訊

升級可以視為一種您知道某些東西將要發生變化的特殊情況，特別是資料庫的版本變化。由於版本變化可能會包含新的功能以及可能會改變某些查詢效能的缺陷修正，因此有必要在升級前收集基線資訊，從而能夠在升級後進行比較。為進行此操作，我們建議建立以下基線：

AWR baselines

與前面建議的標準基線類似，獲取關鍵基線效能操作的 AWR 快照，從而可以在發生問題時將其與升級後的情況進行比較。建議的基線收集包括：

• 正常活動
• 一天中最忙的時間
• 月末或業務週期處理
• 批處理作業

SQL Plan management Baselines

SQL Plan Management 可用於跨版本保持SQL 效能。如果您希望保持升級前後的 SQL 效能，請對有此需求的 SQL 語句建立基線。我們建議您至少對應用程式中的 關鍵SQL 語句執行該操作。將這些基線傳輸到新系統中並啟用它們。

主動型最佳實踐的核對錶

______ 將 OSWatcher 安裝在安裝了 Oracle Database 的每個節點上，然後執行它。
             每天執行 OSWatcher Analyzer 以檢視伺服器上的效能問題。

______ 獲取 Diagnostics Pack 許可

______ 配置 AWR 快照時間間隔並驗證 AWR 快照是否按預期時間間隔進行

______ 建立 O/S（使用 OSW）和資料庫（使用 AWR）的多條基線。

______ 下載 Hangfg 並準備好在資料庫掛起時執行

______ 安裝 SQLHC 並按預期時間間隔執行

______ 下載 SQLT 並準備好在需要時安裝到資料庫上

______ 如果執行環境不穩定，且問題無法使用上述工具解決，請考慮下載並安裝 LTOM

建立服務請求

如果需要 SR，請參閱以下文件，瞭解有關 ＳＲ 內容的詳細資訊：

如果未進行主動型收集，怎麼辦

在出現問題之前沒有采取主動型步驟來收集資訊的情況是存在的。針對這些情況，我們有大量的文章概述瞭如何處理每種特定的情況，並給出了關於收集相關資料的最佳實踐建議。請參閱：

請注意，在這些情況下，為了能夠收集資訊，可能需要重現問題，因為無法以回顧性方式收集所有情況下的診斷資訊。

關於效能問題服務請求診斷資訊收集的文件(SRDC)

服務請求診斷資訊收集(SRDC) 文件是一個提供給使用者對於各種效能問題來如何逐步收集診斷資訊的文件.

參考