問題

當Oracle數據庫出現復雜性能問題時，需要Oracle技術人員提供技術支持，但收集足夠的數據來解決復雜的性能問題是很難實現的。

從歷史上看，用戶會遇到性能問題，聯系Oracle支持人員，結果卻被告知當時收集的數據不足，或者不存在任何數據，無法在問題首次出現后讓支持人員解決問題。然后建議用戶在事后打開額外的數據收集（然后是收集更多數據的迭代過程），將其發送給支持部門，但再次被告知收集的數據不足，需要進一步中斷和收集更多數據。

本文檔描述了一種消除或減少不必要的數據收集的方法，以減少所花費的時間和精力，及時解決問題。所有概述的方法對數據庫本身的性能影響最小，有些方法（如與自動工作負載存儲庫（AWR）相關的方法）已經集成。

簡介

Oracle主動收集

目的

本文檔描述了一種最佳實踐方法，以確保在問題首次出現時主動收集足夠的性能數據，從而能夠有效地確定根本原因。它可以與以下文檔一起使用，以避免問題，然后如果不可避免，收集快速診斷所需的信息：

注意

這些建議是適用于支持遇到的主要場景的最佳實踐。

每個問題都是不同的，在某些情況下可能需要特定的額外診斷來完全實現根本原因診斷。

為每個問題預先收集這些有針對性的信息不一定可行，因為解決一個特定問題所需的特定診斷可能并不適用于所有情況。目標是提供一個堅實的起點，收集足夠的信息來解決大多數問題，或為進一步追蹤提供及時的建議。

方法論 

我們的最佳實踐方法包括以下內容：

1.自上而下的數據收集方法
2.建立多個基線
3.在問題發生之前，已經安裝并運行了正確的工具
4.為不穩定環境部署專用工具

一、自上而下的方法

1.操作系統（O/S）級別的數據收集

Oracle只有在其運行的服務器也達到最佳性能時才能達到最佳性能。因此，通過使用OSWatcher捕獲操作系統指標，在服務器級別開始數據收集是明智的，這樣可以監控和調整服務器的性能。

1.1 OSWatcher

OSWatcher（OSW）包含一個內置的分析器，可以自動分析收集到的數據，主動查找cpu、內存、io和網絡問題。建議所有用戶安裝并運行OSW，因為它對于查看操作系統上的問題非常有價值，而且開銷很小。

一旦安裝并運行，OSWatcher將默認提供48小時的操作系統“回顧”數據。因此，例如，如果節點驅逐發生在凌晨2點，Oracle支持人員將能夠從OSWatcher日志中查看在此期間操作系統上發生了什么。在OSWatcher出現之前，沒有辦法回顧操作系統在停機或嚴重性能問題期間可能發生的情況，Oracle也不知道操作系統上發生了什么。

有關OSWatcher上的下載、用戶指南和使用視頻，請參閱以下內容

Refer to the following for download, user guide and usage videos on OSWatcher
Document 301137.1 OSWatcher
Document 2942344.1 OSWatcher Video Series

其他相關文章：

Document 1531223.1 OSWatcher User Guide
Document 461053.1 OSWatcher Analyzer User Guide

OSWatcher介紹

圖片

OSWatcher（oswbb）是一個可下載的實用程序，用于從操作系統中捕獲性能指標。OSWatcher的使用符合Oracle的標準許可條款，不需要額外的許可證。當您安裝并運行oswbb作為性能診斷數據收集最佳實踐的一部分時，您可以通過支持和開發來幫助更快地解決SR問題。oswbb由兩個獨立的組件組成：

1.oswbb：一個收集和存儲數據的unixshell腳本數據收集器。
2.oswbba：一個java實用程序，它將自動分析數據，提供建議，并生成圖形和html文檔

這兩個組件都包含在一個可下載的tar文件中。

請勿將此實用程序與OSWatcher的Exadata版本混淆。

下載方式：

下載鏈接在 301137.1  文檔里，可以單獨下載，也可以作為TFA/AHF工具的一部分進行安裝。

圖片

最佳實踐:

作為最佳實踐，支持人員建議所有Oracle用戶在運行Oracle的服務器上部署OSWatcher。OSWatcher應被視為對可能存在的任何其他數據收集的補充或補充。

主要原因是，如果支持人員必須向開發人員提交錯誤，開發人員很可能會堅持提供OSWatcher數據。否則，在安裝OSWatcher并再次出現問題之前，該錯誤可能無法繼續。此外，支持分析師熟悉并接受過了解基本操作系統診斷實用程序（如vmstat、iostat、top等）輸出的培訓。支持分析師可能不熟悉您現有的其他類型的自定義或特定于操作系統的數據收集。最后，支持人員能夠使用內部工具分析OSWatcher數據，從而避免了手動檢查數十個文件的耗時任務。這將大大縮短您的解決時間。

支持人員建議您運行OSWatcher，默認快照間隔為30秒，默認保留期為48小時。以大于60秒的速率拍攝不太頻繁的快照或采樣對于診斷性能問題沒有幫助。

例如:

./startOSWbb.sh 30 48 None /usr/app/archive

監控結果，示例如下:

I/O

圖片

進程

圖片

內存

圖片

圖片

圖片

圖片

2.數據庫級別的數據收集

Data collection at Database level

2.1 AWR

自動工作量資料檔案庫

Automatic Workload Repository

AWR是圍繞數據庫性能問題收集數據的最全面的實用程序。它主要用于收集數據庫周圍的指標（盡管它也包括一些操作系統指標）。

如果您預計不會出現性能問題，并且處于穩定的環境中，我們的最佳實踐建議是以默認的60分鐘速率啟用AWR快照。如果您擔心出現性能問題，建議更頻繁地進行快照。在這種情況下，我們建議以最長20分鐘的間隔進行快照；如果你能負擔得起，比這更頻繁的快照總是更好。更頻繁的快照使我們能夠以更高的粒度查看數據庫上發生的事情，并可用于比較數據庫性能良好的時間。無論您選擇什么快照間隔，都要盡量堅持下去，以方便報告之間的比較。

捕獲一些快照非常重要，這些快照可以被視為正常性能的良好基線，可以在以后與問題發生時進行比較。很多時候，僅僅擁有AWR數據就可以為錯誤識別提供足夠的信息，在某些情況下，還可以提供足夠的數據來診斷數據庫掛起和其他問題，而不需要進行特殊的額外診斷，如systemstate 轉儲和 hanganalyze跟蹤。

AWR還可以用于深入查看特定的sql語句。如果問題在會話級別，則可以在嘗試進行額外的10046或sql trace診斷之前獲取并分析AWR報告。此信息也可與ASH報告結合使用（見下文）。

有關AWR的更多信息，請參閱以下文章：

Document 1363422.1 Automatic Workload Repository (AWR) Reports - Start Point
How to Generate an AWR Report and Create Baselines (Doc ID 748642.1)
FAQ: Automatic Workload Repository (AWR) Reports (Doc ID 1599440.1)
NOTE:94224.1 - FAQ- Statspack Complete Reference
NOTE:1301503.1 - Troubleshooting: Missing Automatic Workload Repository (AWR) Snapshots and Other Collection Issues
NOTE:782974.1 - How to Recreate the Automatic Workload Repository (AWR)?
NOTE:1399365.1 - Troubleshooting Issues with SYSAUX Space Usage
NOTE:329984.1 - Usage and Storage Management of SYSAUX tablespace occupants SM/AWR, SM/ADVISOR, SM/OPTSTAT and SM/OTHER
NOTE:754639.1 - How to Read Buffer Cache Advisory Section in AWR and Statspack Reports.
NOTE:560204.1 - MMON Trace Shows: "*** KEWRAFC: Flush slave failed, AWR Enqueue Timeout"
NOTE:1490798.1 - AWR Reporting - Licensing Requirements Clarification
NOTE:1359094.1 - How to Use AWR Reports to Diagnose Database Performance Issues
NOTE:748642.1 - How to Generate an AWR Report and Create Baselines
NOTE:276103.1 - Performance Tuning Using Advisors and Manageability Features: AWR, ASH, ADDM and SQL Tuning Advisor
NOTE:459887.1 - ORA-13516 AWR Operation failed: SWRF Schema not initialized ORA-06512 SYS.DBMS_WORKLOAD_REPOSITORY
NOTE:733655.1 - AWR Diagnostic Collection Script
NOTE:287679.1 - How to Address Issues Where AWR Data Uses Significant Space in the SYSAUX Tablespace
NOTE:296765.1 - Solutions for possible AWR Library Cache Latch Contention Issues in Oracle 10g
NOTE:786554.1 - How to Read PGA Memory Advisory Section in AWR and Statspack Reports to Tune PGA_AGGREGATE_TARGET
NOTE:1357637.1 - How to Control the Number of SQL Statements and other information displayed in AWR Report

AWR報告可以通過運行各種SQL腳本來生成，以滿足各種要求。每份報告都有HTML或TXT格式：

awrrpt.sql
顯示一系列快照ID的各種統計信息。
awrrpti.sql
顯示指定數據庫和實例上快照ID范圍的統計信息。
awrsqrpt.sql
顯示一系列快照ID的特定SQL語句的統計信息。運行此報告以檢查或調試特定SQL語句的性能。
awrsqrpi.sql
顯示指定數據庫和實例上快照ID范圍的特定SQL語句的統計信息。
awrddrpt.sql
比較兩個選定時間段之間的詳細性能屬性和配置設置。
awrddrpi.sql
比較特定數據庫和實例上兩個選定時間段之間的詳細性能屬性和配置設置。

例如:

圖片

2.2 ASH

Active Session History

活動會話歷史（ASH）報告在深入到會話級別時提供了非常精細的度量收集。與AWR提供的性能數據的匯總視圖相比，ASH為每個單獨的數據庫會話提供1秒級精度的信息。這對于間歇性性能問題或掛起非常重要。利用ASH數據有時足以在會話級別診斷問題，從而避免進行額外的10046或sql trace診斷。ASH報告可以根據需要通過高級工作負載存儲庫（AWR）獲得。

相關文檔:

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

性能調優和問題診斷是任何數據庫管理員執行的兩項最具挑戰性和最重要的管理任務。

與服務器可管理性工作的主要驅動力相一致，自動數據庫診斷監視器（ADDM）試圖使執行這兩項任務變得更加簡單和容易。

ADDM采用自上而下的迭代方法，并驅動基于規則的專家系統，以識別系統中的瓶頸，并提出相關建議來解決這些瓶頸。

ASH通過從數據庫內核的會話狀態對象中采樣來獲取活動會話的活動信息。

ASH采樣的信息量可能非常大，因此ASH在數據庫系統全局區域（SGA）中維護一個固定大小的循環緩沖區，該緩沖區在數據庫啟動時分配。

此ASH數據會定期刷新到磁盤并存儲在自動工作負載存儲庫（AWR）中。

這些信息可用于問題診斷或性能調優期間的深入分析。

ASH的沖洗和凈化政策，包括ASH尊重AWR基線的方式，與AWR政策完全相關。

盡管如此，將ASH的全部內容刷新到磁盤上可能太多，不可行，因此，每十個活動會話樣本中只有一個會被刷新到磁盤。

除了ADDM使用ASH實現其目標外，ASH內容還將顯示在Oracle Enterprise Manager（EM）性能屏幕上。

EM性能屏幕中總結ASH內容的圖形將是一個堆疊圖，顯示每分鐘內經過的數據庫時間在各種等待時間和CPU時間上的分布。

Ash 內存大小

Size of ASH Circular Buffer = Max [Min [ #CPUs * 2 MB, 5% of Shared Pool Size, 30MB ], 1MB ]

二、建立多個基線

根據您的業務概況，應獲取基線捕獲并存儲不同的時間段。

建議的基線收集將是：

1.正常活動

2.非繁忙時間

3.一天中最繁忙的時間

4.月末或業務周期處理

5.批量處理。

有了這些多個基線，你就能很好地了解系統的正常運行情況。

當出現問題時，與這些基線進行比較將有助于解決問題。

未能建立基線會使理解性能問題的性質變得更加困難。

如果用戶只在系統性能不佳時提供AWR，那么分析數據庫的性能就困難得多；

與數據庫性能相比，沒有什么可以成為一種“主觀觀察”。

作為最佳實踐，支持人員建議為O/S（OSW）和數據庫（AWR）創建基線。

三、提前安裝正確的工具

做好準備！：在問題發生之前，已經安裝并運行了正確的工具

除了安裝和運行OSW以及以指定的時間間隔收集AWR外，Oracle支持還提供了一些專門的工具，這些工具應該安裝在您的服務器上，并在出現問題時隨時可用。

注意：這些工具不必運行，但預安裝允許您在出現問題時快速收集信息，而不是錯過機會并等待再次發生。

3.1 HangFG

HangFG允許收集掛起診斷，而用戶不必知道要采取何種類型和級別的跟蹤。

如果安裝了HangFG，并且發生掛起，則用戶有一個簡單的unix shell命令行界面，允許他們選擇他們能夠承受的數據收集的“繁重”程度。

有關Hangfg的下載和用戶指南，請參閱以下內容。

Document 362094.1 HANGFG User Guide
Document 1482811.1 Best Practices: Proactively Avoiding Database and Query Performance Issues
Document 1477599.1 Best Practices Around Data Collection For Performance Issues

目前，用戶可以選擇3個級別來啟動掛起診斷的自動生成。

這為用戶提供了在盡可能不引人注目的情況下進行掛起診斷的靈活性（如果數據庫仍處于功能狀態）。

1.光對系統的影響。

此選項收集2個hanganalyze級別3跟蹤，然后確定它是否也可以在對系統影響最小的情況下收集1個hanganalyse級別4跟蹤。如果是這樣，它將收集hanganalyze 4級跟蹤。如果沒有，則不會收集其他跟蹤文件。

2.對系統影響中等（默認值）。

此選項收集1個hanganalyze級別3跟蹤，然后確定它是否也可以在對系統影響最小的情況下收集2個hanganalyse級別4跟蹤。如果是這樣，它會收集另外2個hanganalyze級別4的痕跡。如果沒有，它將收集額外的hanganalyze 3級跟蹤。此選項還收集1個系統狀態級別266跟蹤。

3.對系統影響較大。

此選項收集2個hanganalyze級別4跟蹤和2個系統狀態級別266跟蹤。

運行HangFG：

./hangfg.sh <ARG1>

參數如下:

3.2 SQLHC

SQL Tuning Health-Check

SQL調優健康檢查腳本是由Oracle Server技術專家中心開發的一種工具。

該工具也稱為SQLHC，用于檢查單個SQL語句運行的環境，檢查基于成本的優化器（CBO）統計數據、模式對象元數據、配置參數和其他可能影響所分析SQL性能的元素。

SQLHC的目的是允許用戶確保單個SQL運行的環境是健全的，并希望避免SQL性能問題產生可避免的問題。

它做到了這一點，同時“沒有數據庫足跡”，確保它可以在所有系統上運行。

當對一個SQL-ID執行時，此腳本會生成一個HTML報告，其中包含圍繞所提供的一個SQL語句進行的一組健康檢查的結果。

使用示例:

sqlplus / as sysdba
SQL> START sqlhc.sql "T" djkbyr8vkc64h

圖片

相關文檔:

Document 1366133.1 SQL Tuning Health-Check Script (SQLHC)

3.3 SQLTXPLAIN (SQLT)

存在一種更復雜的工具來解決SQL性能問題（但這需要數據庫上的足跡）。

SQLTXPLAIN，也稱為SQLT，是由支持提供的工具，輸入一條SQL語句并輸出一組診斷文件。

這些文件通常用于診斷性能不佳的SQL語句。

SQLT連接到數據庫并收集執行計劃、基于成本的Optimizer CBO統計數據、模式對象元數據、性能統計數據、配置參數以及影響所分析SQL性能的類似元素。

下載地址:

SQLT收集的文件

以下是SQLT收集的文件類型的帶注釋列表（在本例中使用XECUTE方法）：

圖片

相關文檔:

Document 215187.1 SQLT (SQLTXPLAIN) - Tool that helps to diagnose a SQL statement performing poorly
Potential Uses for Information Collected by SQLT (Doc ID 1948770.1)

四、為不穩定的環境部署專用工具

大多數用戶在穩定的環境中運行時沒有任何性能問題。

對于那些沒有穩定環境并且遇到掛起或瞬態性能問題的用戶，這些問題無法通過上述傳統數據收集來解決，Oracle支持部門有一些專門的工具來幫助調試這些問題。

4.1 Procwatcher

Procwatcher是一個定期檢查和監視Oracle數據庫和/或集群軟件進程的工具。該工具將使用Oracle工具（如oradebug short_stack）和/或操作系統調試器（如pstack、gdb、dbx或ladebug）收集這些進程的堆棧跟蹤，并在指定的情況下收集SQL數據。

詳見以下文章：

Document 459694.1 Procwatcher: Script to Monitor and Examine Oracle DB and Clusterware Processes

當前打不開了

五、升級前要收集什么

升級可以被視為一種特殊情況，在這種情況下，你知道有些事情會發生變化；

特別是數據庫的版本。由于版本更改可能包含新功能和對可能改變某些查詢性能的缺陷的修復，因此在升級之前收集基線信息是有意義的，這樣您就可以在升級后進行比較。

為此，我們建議：

AWR基線

以與之前建議的標準基線類似的方式，對關鍵基線性能操作進行AWR快照，以便在出現問題時將其與升級后的情況進行比較。

建議的基線收集將是：

1.正常活動
2.一天中最繁忙的時間
3.月末或業務周期處理
4.批量處理

SQL計劃管理基線

SQL Plan management Baselines

SQL計劃管理可用于跨版本保持SQL性能。

如果希望在升級前后保持SQL的性能，請創建要保留的SQL語句的基線。

我們建議至少對應用程序中的關鍵SQL語句這樣做。

將它們傳輸到新系統并啟用它們。

六、主動最佳實踐清單

主動最佳實踐清單

1.在安裝了Oracle數據庫的每個節點上安裝并運行OSWatcher。
每天運行OSWatcher分析器，查找服務器上的性能問題。
2.獲取診斷包許可證
3.配置AWR快照間隔，并驗證AWR快照是否按預期間隔進行
4.為O/S（使用OSW）和數據庫（使用AWR）建立多個基線。
5.如果您遇到數據庫掛起，請下載Hangfg并準備好運行
6.安裝SQLHC并按預期的時間間隔運行
7.如果需要在數據庫上安裝SQLT，請下載SQLT并做好準備
8.如果您在不穩定的環境中運行，并且使用上述工具無法解決問題，請考慮下載并安裝LTOM

七、記錄服務請求

如果需要SR，請參閱以下內容以了解包括哪些內容的詳細信息：

A.數據庫范圍內的問題

1.一般數據庫性能問題 

數據庫運行速度比正常情況慢，問題似乎不是由于一個SQL語句或會話造成的。

1.1 一些好問題

(1)問題是否一致，或者它是否只在一天中的某些時間或在某些負載下運行緩慢（例如，當它變慢時，您可能有一個sqlloader會話在運行？）如果它只在某些時間運行，那么請調查該時間的具體情況（可能是熱備份、計劃作業、批處理運行）。

(2)發生了什么變化？

(3)大多數性能問題都是由重大變化引起的（與負載逐漸增加引起的變化相反）。

(4)您是否升級了Oracle版本，最近是否應用了補丁？

(5)您是否更改了init.ora參數？

(6)負載是否大幅增加（例如新應用程序或正在實施的應用程序的一部分）？

(7)咨詢您的UNIX和網絡管理員，以確定最近是否有更改。

(8)如果你能夠恢復業績（但因此無法滿足你的短期業務需求），那么你做了什么來影響它？

(9)您運行的是當前版本的最新補丁集嗎？

(10)查看patchset發布說明，了解最新可用的patchset。它將指示哪些BUG被固定在其中。

(11)對照你看到的問題檢查這份清單。也許你正在打其中一個。確保補丁已正確應用。

上述信息對于解決問題至關重要，因此在記錄SR時，請盡量描述可能對我們有所幫助的更改類型或相關信息。

1.2 你可以做些什么來幫助確定根本原因?

如果可以，請撤消您所做的任何更改，看看問題是否仍然存在。

如果你做了不止一個更改，那么就逐一撤銷它們，直到問題消失。

即使問題沒有消失，這仍然是一個很好的信息，因為它證明了問題與更改無關。

1.3 我們需要什么證據？

1.提供一份涵蓋性能問題期間的AWR報告

2.提供性能正常且工作量相似的一段時間內的AWR（最好是幾天前的同一時間）

下載:

參考:

Best Practices: Proactive Data Collection for Performance Issues (Doc ID 1477599.1)