Oracle 提供了深入的診斷表面：AWR 快照、ASH 樣本、等待事件直方圖、ADDM 建議、警報記錄條目，以及數百個V$ 動態性能視圖。每個信號都在數據庫邊界停止，而這裡往往是最難的生產案例所在。

A Concurrency 在 WebLogic 連接池耗盡時等待尖峰產生與穩定負載下真實鎖競爭相同的 AWR 輸出。一個 db file sequential read 在索引範圍掃描中的爬升可能意味著一個壞的執行計劃，或是一個儲存陣列因為一個獨立系統上的批量 ETL 工作使後端飽和而增加了十幾毫秒的延遲。每個例子都遵循著相同的模式：Oracle 告訴你 什麼 數據庫正在等待；基礎設施和應用數據告訴你 為何。縮小這個差距意味著將數據庫事件放在與周圍堆疊相同的時間線上。

ManageEngine OpManager Nexus 正是這樣做的，它在一個控制台裡顯示 WebLogic、OCI、儲存和網絡信號，以及 Oracle 指標。

本指南是一個決策框架，用於Oracle 19c 性能監控：等待事件分類、V$指標解讀、表空間容量和警報路由。

AWR報告導航

一個典型的AWR報告 可能有數十個部分，但三個部分承載了大多數調查的診斷重量。

載入配置檔 可供您查看每秒及每筆交易的執行率、交易率，以及邏輯/物理讀取率的標準化數據。透過這些指標比較一個健康的快照與一個退化狀態的快照，是判斷性能變化是由工作負載容量導致，還是由相同容量下的執行效率退化所引發的最快方法。它的兩個值DB Time 和 DB CPU，提供下一節的分流比例。

Top 5 時間事件，排名在快照期間消耗最多 DB 時間的等待事件，以絕對秒數和總 DB 時間的百分比表示。將主要事件映射到等待類別決策表進行路由。

SQL 按經過時間排序 識別負責最高資料庫時間消耗的個別 SQL 語句。與前五名事件交叉參考，以區分特定查詢瓶頸與系統性瓶頸。

AWR 按設計是歷史性的。在活躍的事件期間，將 AWR 結果與 ASH 資料搭配，以查看哪些會話目前正貢獻延遲時間：

SELECT wait_class, event, COUNT(*) AS samples
FROM V$ACTIVE_SESSION_HISTORY
WHERE sample_time   > SYSTIMESTAMP - INTERVAL '15' MINUTE
  AND session_state = 'WAITING'
GROUP BY wait_class, event
ORDER BY samples DESC
FETCH FIRST 10 ROWS ONLY;

當工作流程本身是瓶頸時（例如在事件中間生成HTML報告，或是在需要提供者門檻直接訪問的雲管理Oracle部署中讀取AWR），OpManager Nexus會持續傳輸這些相同的指標，並透過雲端API暴露相等的收集。當需要時，手動生成路徑仍然可用，最常見的情況是Oracle Support案例或並行快照比較：@$ORACLE_HOME/rdbms/admin/awrrpt.sql (請求報告格式及開始/結束快照ID來自DBA_HIST_SNAPSHOT)或DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML(l_dbid, l_inst_num, l_bid, l_eid).

在應用任何這些之前，有兩點需要注意。AWR、ASH和ADDM需要Oracle Diagnostics Pack 授權 (與企業版捆綁); 本指南中使用的 V$ 查詢則不在此限。Oracle 23ai 自動化數據庫自動管理 AWR，因此上述快照機制在那裡不適用.

從這裡開始，這些信號會輸送到下一節概述的初步分類路徑.

初步分類決策框架

性能分類跟隨兩個分支：先對CPU密集型與等待密集型進行初步篩選，然後對等待密集型情況進行等待類別路由。

從AWR快照到行動

DB時間是所有前景會話中經過時間的總和；DB CPU是CPU上的子集。它們的比例是第一個分類信號。

當 DB CPU 主導 DB 時間（以 OLTP 開始點約 75% 以上，根據您的環境進行校準），工作負載受 CPU 限制。SQL 調整或資源爭奪是調查方向，而 按耗時排序的 SQL 識別了消耗最多 DB 時間的語句。

當佔比明顯低於此值時，工作負載以延遲為主，前 5 項耗時事件 變成主要的診斷表面。先閱讀 %DB Time 欄位；原始等待次數會誤導。消耗高比例的事件是需要優先處理的，較小的部分是背景噪音.

在行動前交叉參考這兩種視角。Adb file sequential read 主導事件與頂級 SQL 做成千上萬的單塊讀取搭配在一起是一個查詢特定的候選者。相同的等待主導與簡單查詢的頂級 SQL 指向系統性瓶頸（儲存、快取壓力）而不是查詢本身.

當主導等待類別被識別出來後，下一節將每個類別導向其調查路徑和基礎設施檢查.

等待類別決策表

關於Oracle 19c的13等待類別，下表涵蓋了在生產OLTP排程中出現的其中一些。Idle行是為了診斷語境，而不是作為瓶頸。

以下查詢產生類別級別等待分佈，作為分類輸入：

SELECT
  wait_class,
  COUNT(*)                                     AS session_count,
  ROUND(AVG(seconds_in_wait), 2)               AS avg_wait_sec,
  COUNT(DISTINCT event)                        AS distinct_events
FROM V$SESSION
WHERE state      = 'WAITING'
  AND wait_class <> 'Idle'
GROUP BY wait_class
HAVING COUNT(*) > 2  -- adjust threshold for your concurrency level
ORDER BY session_count DESC;

從這裡開始，每個主要類別都有自己的分類路徑，詳情請參考後續的深入探討。

等待事件深入分析按類別

每個分析都遵循相同模式：首先為 Oracle 等待數據，然後進行基礎設施檢查以命名實際根本原因。Oracle 的 等待事件描述參考 目錄中每個事件；這裡的重點是分類，而不是定義。

系統 I/O：物理讀取事件

db file sequential read 在索引範圍掃描上觸發，其中 Oracle 從特定索引條目讀取一個塊，然後讀取其對應的表塊。優化後的執行計劃中高延遲時間指向儲存延遲，而不是查詢結構。

db file scattered read 在全表掃描上觸發，其中 Oracle 在單次 I/O 中讀取多個連續塊。這裡的延遲時間升高意味著預期會進行全表掃描（大型分析查詢與db_file_multiblock_read_count 已針對工作負載進行調整) 或缺失索引正強制進行全表掃描，而範圍掃描將更為精準。

兩項事件都可能在儲存子系統飽和時觸發，而無需更改查詢執行路徑。當系統 I/O 等待與主機儲存延遲同時升高時，解決方案屬於基礎設施層，而不是 SQL。OpManager Nexus 通過在相同時間線上顯示 Oracle 等待數據和主機儲存指標，縮短了診斷時間.

並發：圖書館緩存和熱塊爭奪

library cache lock 通常表示硬解析的風暴，其中會話競爭解析可能可以共享的 SQL 語句。首先排除 DDL 操作 (ALTER TABLE, CREATE INDEX)；這些操作對受影響的對象佔有獨佔鎖，並產生相同的等待。如果沒有並發的 DDL，則修復在 cursor_sharing 方面：設置它為FORCE 將字面值轉換為綁定變量並減少硬解析，但這會導致潛在的計劃不穩定性，其中字面值會影響基數估計.

buffer busy waits 指示多個會話競爭訪問緩存中的同一緩衝區，通常是高並發OLTP工作負載中熱區段塊的症狀。查詢V$WAITSTAT 用於判斷具有最高計數的區塊類別，以確認爭用是否發生在撤銷區塊、數據區塊或區段標頭：

SELECT class, count AS wait_count, time AS wait_time
FROM V$WAITSTAT
WHERE count > 0
ORDER BY count DESC
FETCH FIRST 10 ROWS ONLY;

AConcurrency 在新應用程式部署後立即出現等待尖峰是一個指示問題程式碼產生未共享游標的回退指標。在維護期間發生的相同事件是背景噪音。應用層上下文（部署時間線、WebLogic 線程池狀態）解決了這種模糊性.

提交: 重做寫入延遲

log file sync 每次當一個會話發出 COMMIT 時就會觸發，並等待日誌寫入器 (LGWR) 將重做緩衝區刷寫到磁碟。高 log file sync 時間與重做寫入延遲直接相關。如果重做日誌檔案位於緩慢的儲存設備上，或與數據檔案共享 I/O 帶寬，那麼高 COMMIT 負載的工作負載會在此處停頓。

檢查重做日誌放置和儲存吞吐量，再調整應用程式提交頻率。最直接的測量是 log file parallel write 從 V$SYSTEM_EVENT 的平均等待時間：

SELECT event,
       total_waits,
       ROUND(time_waited_micro / NULLIF(total_waits, 0) / 1000, 2) AS avg_wait_ms
FROM V$SYSTEM_EVENT
WHERE event = 'log file parallel write';

持續的平均等待時間超過低十幾毫秒範圍，表示有日誌寫入瓶頸或重做卷的儲存限制。V$SYSTEM_EVENT 的值是從實例啟動以來的累積值；將它們讀取為增量（請參考 V$ 指標參考以了解累積值與增量值規則）。

應用程式：列鎖爭用

enq: TX - row lock contention 在一個會話持有列鎖而另一個會話等待修改相同列時觸發。阻塞性別對在 V$LOCK 與 V$SESSION 連接時可見：

SELECT
  l.sid        AS waiting_sid,
  s.username   AS waiting_user,
  l.type       AS lock_type,
  l.id1, l.id2,
  bk.sid       AS blocking_sid,
  bs.username  AS blocking_user,
  bs.status    AS blocking_status
FROM V$LOCK l
JOIN V$SESSION s  ON l.sid    = s.sid
JOIN V$LOCK bk    ON bk.type  = l.type
                 AND bk.id1   = l.id1
                 AND bk.id2   = l.id2
                 AND bk.request = 0
JOIN V$SESSION bs ON bk.sid   = bs.sid
WHERE l.request > 0;

bk.type = l.type這個條件防止TX等待者與無關係的TM或UL持有者配對，這些持有者恰好共享id1/id2。為了更簡單的診斷，V$SESSION.BLOCKING_SESSION (10g+)直接返回阻塞者的SID，而不進行自連接，但這會犧牲上述的每個鎖細節。

修復應該屬於應用層：縮短交易持續時間，重新排序 DML 動作以最小化鎖佔用時間，或重新設計數據訪問模式.

空閒：客戶端等待事件

SQL*Net message from client (Oracle 依為機密分類為闲置、非網絡) 記錄了 Oracle 等待用戶端應用程式發送下一個請求所花費的時間。在部署窗口期間出現的尖峰通常表示新的應用程式版本進行了更多往返或之間的連接保持更長時間。當此事件佔據顯著的 DB 時間比例（四分之一或更多）且沒有應用程式變更時，值得調查作為潛在的連接洩漏。

為了網路層相關性，OpManager Nexus 會同時顯示網路設備指標以及已經可見的應用程式和伺服器資料。一個SQL*Net message from client的尖峰，與連接應用伺服器和資料庫層的網路段落出現網路飽和同時發生，是一個需要這兩種視野來診斷的問題。

超越個人等候事件，V$ 動態表現檢視提供一個持續的指標信號，補充基於 AWR 的分類。

V$ 指標參考

下表綜合了與可執行的生產事件相關的 V$ 指標。將值視為起點，並根據您環境的穩態基線進行校準。

閾值參考表

累積統計資料如物理讀取會跨實例生命週期累積。AWR 將其作為快照之間的變化量捕捉預設間隔：60分鐘，預設保留：8天 在 Oracle 19c)。實時掃描工具通過追踪連續掃描之間的變化來計算每秒的速率.

需要上下文的指標

當 緩存區命中率 落入警告帶，會話進行更多物理讀取，超過 SGA 能夠吸收的範圍；預期在 db file sequential read 和 db file scattered read 中會出現相關的尖峰。在具有小工作集的工作負載中，非常高的比率（高於 99%）可能會掩蓋 SQL 效率問題，因此確切的轉折點取決於工作負載。從緩存特定的計數器計算它：

WITH stats AS (
  SELECT name, value
  FROM V$SYSSTAT
  WHERE name IN ('physical reads cache',
                 'db block gets from cache',
                 'consistent gets from cache')
)
SELECT
  ROUND(
    (1 - (MAX(CASE WHEN name = 'physical reads cache' THEN value END)
          / NULLIF(MAX(CASE WHEN name = 'db block gets from cache'   THEN value END)
                 + MAX(CASE WHEN name = 'consistent gets from cache' THEN value END), 0)
    )) * 100, 2
  ) AS cache_hit_ratio
FROM stats;

過往使用裸physical reads的公式會將直接路徑讀取（全表掃描、平行查詢、大LOB讀取）計算為失敗，儘管這些讀取完全繞過了緩衝快取；在混合工作負載下，這會降低比例，但並未指示出真正的快取問題.

活動會話接近sessions參數限制（Oracle的預設公式是）1.5 x PROCESSES + 22) 是連接池錯誤配置或連接洩漏的領先指標。檢查當前利用率：

SELECT current_utilization                                AS curr_sessions,
       limit_value                                         AS limit_value,
       CASE WHEN limit_value = 'UNLIMITED' THEN NULL
            ELSE ROUND(TO_NUMBER(current_utilization)
                       / NULLIF(TO_NUMBER(limit_value), 0) * 100, 1)
       END                                                 AS pct_used
FROM V$RESOURCE_LIMIT
WHERE resource_name = 'sessions';

物理讀取和邏輯讀取應作為每秒的速率來追蹤。5分鐘的掃描間隔可以捕捉到短暫的峰值，而60分鐘的AWR窗口則會將其平均掉。

重寫延遲在上述的提交子節中已有說明（查詢和解釋）。

解析CPU / 解析耗時是解析所花CPU時間與總解析耗時的比例。比例接近1.0表示解析在CPU上完成而無需等待；那是軟解析信號。當比例遠低於1.0時，會話在解析鎖上等待。沒有Oracle官方文檔中標準的切斷點，因此需根據您環境的穩態基線進行校準。

WITH parse_stats AS (
  SELECT name, value
  FROM V$SYSSTAT
  WHERE name IN ('parse time cpu', 'parse time elapsed')
)
SELECT
  ROUND(
    MAX(CASE WHEN name = 'parse time cpu'     THEN value END)
    / NULLIF(MAX(CASE WHEN name = 'parse time elapsed' THEN value END), 0)
  , 2) AS parse_cpu_to_elapsed_ratio
FROM parse_stats;

V$SYSSTAT 的解析時間值是以百分之一秒為單位。這兩個計數器自實例啟動以來都是累積的，因此這個查詢返回的是整體平均數，將完全隱藏30分鐘的解析鎖定風暴。為了獲得可操作的實時信號，請在相隔5-10分鐘的時間內捕捉兩次讀數，並計算差值的比率。

ASM 統計 會顯示 TOTAL_MB、FREE_MB 和USABLE_FILE_MB 每個磁碟群組。對於鏡像磁碟群組，USABLE_FILE_MB 才是重要的數字：一個顯示為原始空間有 30% 開放的磁碟群組，在考慮鏡像開銷後，實際可用容量可能遠低於此數字。

操作基線建立

設立這些基線需要一個結構化的收集期間，按工作負載窗口進行分割，並基於百分位數導出閾值。

收集期間. 一個基準期間 兩至四週足以捕捉足夠的變化以解釋週別批次循環、月底處理和負載波動.

負載視窗分割. OLTP 白天時段與過夜批次時間的效能指標不同。在 OLTP 時段中維持在 90% 中間區間的緩存命中率，在進行合法的批次 ETL 執行（scans large tables）時可能會顯著下降。將這些視為分開的基準值，而不是將它們平均起來；針對混合平均命中率設定的閾值會在批次時間中忽略實際異常情況，並在 OLTP 時段中產生偽陽性。

閾值導出. 對於物理讀取次數/秒和活動會話計數等指標，由於"正常"情況會因工作負載而變化，應從觀察到的百分位數導出閾值。在基線期間的95百分位數設置警告閾值，在99百分位數設置嚴重閾值，可以捕捉真實的異常情況，同時容忍正常變異。當還沒有基線數據時，參考表中提供的乘數是一個合理的起始點。

從AWR數據計算百分位數（需要診斷套裝套件）：

SELECT
  PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY value) AS p95,
  PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY value) AS p99
FROM DBA_HIST_SYSMETRIC_HISTORY
WHERE metric_name = 'Physical Reads Per Sec'
  AND end_time   >= SYSTIMESTAMP - INTERVAL '30' DAY;

對您基線期間的每個指標使用相同的模式；根據end_time按一天中的時間進行篩選，以區分OLTP和批次窗口。

動態與靜態基線。 靜態基準在負載模式穩定時有效。對於負載量隨時間變動的環境（用戶基數增長、季節性流量模式、遷移階段），OpManager Nexus的SaaS交付 提供AI驅動的動態閾值，可自動調整而無需手動重新校準。

已有基準設定，相同的校準邏輯會應用於接下來的容量監控。

表空間和儲存容量

僅僅看使用率百分比會錯過實際導致頁面操作的失敗模式：增長在輪詢週期之間遇到上限。正確的 主要信號是增長率對於最近的上限，無論那是一個檔案系統、MAXSIZE，還是 ASM 磁碟組容量。

永久表空间監控

Autoextend 是靜默失敗模式。啟用了 autoextend 的表空间將會 消耗磁碟空間，直到文件系統填滿、表空間達到其 MAXSIZE 限制，或底層 ASM 磁碟組沒有可用的容量。當 MAXSIZE 設定為 UNLIMITED (表示MAXBYTES=0在DBA_DATA_FILES), Oracle 會持續擴充數據檔，直到檔案系統滿或小檔/大檔平台最大限制達到（以先到者為準），在數據檔層級沒有 Oracle 空間閾值警報。到那時，ORA-01653 (無法延伸表格)或ORA-01688 (無法擴展表分區) 出現在警告記錄中，會話已經失敗了.

這個查詢顯示每個表空间的剩餘容量，而不仅仅是當前使用量：

SELECT
  m.tablespace_name,
  ROUND(m.tablespace_size * t.block_size / 1073741824, 2)       AS total_gb,
  ROUND(m.used_space      * t.block_size / 1073741824, 2)       AS used_gb,
  ROUND((m.tablespace_size - m.used_space) * t.block_size
        / 1073741824, 2)                                         AS remaining_gb,
  ROUND(m.used_percent, 2)                                      AS used_pct,
  ROUND(100 - m.used_percent, 2)                                AS remaining_pct
FROM DBA_TABLESPACE_USAGE_METRICS m
JOIN DBA_TABLESPACES t ON m.tablespace_name = t.tablespace_name
ORDER BY m.used_percent DESC;

追蹤增長趨勢（一個表空間每天增長多少吉字節）並在利用率達到自動擴展上限前發出警報。在授權環境中，從AWR歷史中計算每日增長：

SELECT
  v.name AS tablespace_name,
  ROUND(
    (MAX(h.tablespace_usedsize) - MIN(h.tablespace_usedsize))
    * t.block_size / 1073741824
    / NULLIF(EXTRACT(DAY FROM MAX(s.end_interval_time) - MIN(s.end_interval_time)), 0)
  , 2) AS avg_growth_gb_per_day
FROM DBA_HIST_TBSPC_SPACE_USAGE h
JOIN DBA_HIST_SNAPSHOT s
  ON  h.snap_id = s.snap_id
  AND h.dbid    = s.dbid
JOIN V$TABLESPACE    v ON h.tablespace_id = v.ts#
JOIN DBA_TABLESPACES t ON v.name          = t.tablespace_name
WHERE s.end_interval_time >= SYSDATE - 30
GROUP BY v.name, t.block_size
ORDER BY avg_growth_gb_per_day DESC NULLS LAST;

沒有診斷套裝軟體，擷取定期的快照DBA_TABLESPACE_USAGE_METRICS傳送至外部追蹤表，並計算行之間的差異。

為識別具有無限增長潛力的數據檔案：

SELECT file_name, tablespace_name,
  ROUND(bytes / 1073741824, 2)                        AS current_size_gb,
  CASE WHEN maxbytes = 0 THEN 'UNLIMITED'
       ELSE TO_CHAR(ROUND(maxbytes / 1073741824, 2))
  END                                                  AS max_size_gb,
  CASE WHEN maxbytes = 0 THEN NULL
       ELSE ROUND((maxbytes - bytes) / 1073741824, 2)
  END                                                  AS growth_headroom_gb
FROM DBA_DATA_FILES
WHERE autoextensible = 'YES'
ORDER BY tablespace_name;

MAXBYTES = 0 表示並非字面無限的容量，而是沒有明確的自動擴展上限；Oracle 仍然會在小型檔案與大型檔案平台最大值處限制數據檔案 (~32 GB 和 ~32 TB 分別在 8 KB 塊大小下)，因此在容量規劃時應考慮這個上限，而不是將 "UNLIMITED" 視為真正無限。

临时表空间監控

临时表空间耗盡ORA-01652: unable to extend temp segment) 是常見的生產事件。大型排序操作、哈希連結以及全域暫存表的使用可能會在未事先警告的情況下耗盡暫存空間。在配置暫存空間大小的 75-80% 設定警告閾值：

SELECT tablespace_name,
       ROUND(tablespace_size / 1048576, 2)              AS temp_total_mb,
       ROUND(allocated_space / 1048576, 2)              AS temp_allocated_mb,
       ROUND(free_space      / 1048576, 2)              AS temp_free_mb,
       ROUND((tablespace_size - free_space)
             / NULLIF(tablespace_size, 0) * 100, 2)     AS temp_used_pct
FROM DBA_TEMP_FREE_SPACE;

V$TEMP_SPACE_HEADER 報告從暫存檔頭位圖獲取的配置高水位記錄，且不反映可回收的範圍。Oracle的懶惰回收意味著釋放的排序段會被標記為使用狀態，直到暫存檔縮小或實例重新啟動，因此對其進行查詢往往會在健康的系統上觸發警報。DBA_TEMP_FREE_SPACE 考慮了已釋放但未釋出的空間，是容量閾值的正確來源；在事件期間當前的活躍排序/哈希使用情況，V$SORT_SEGMENT 或 V$TEMPSEG_USAGE 顯示個別會話所持有內容。

表空間增長變化緩慢，於是每30-60分鐘掃描一次對大多數環境而言已足夠。

從單實例範圍來說，下一節添加了RAC和多租戶範圍規則，這些規則改變了上述V$查詢回傳資料的方式。

RAC和多租戶監控

在 RAC 環境中，本指南中所示的所有 V$ 查詢僅返回本地實例的數據。使用 GV$ 視圖（例如，GV$SESSION，GV$WAITSTAT）並透過 INST_ID 篩選，以查詢所有節點。針對特定 RAC 節點的單實例診斷，V$ 查詢仍然正確，但將不反映其他節點上的等待事件或活動會話。

群集等待類別事件。 gc buffer busy acquire 和gc cr block 2-way 指示會話正在等待資料塊透過 RAC 間的私人互連傳輸。延遲時間增加指向互連飽和或跨實例對相同資料塊的競爭。檢查私人互連吞吐量，並考慮在節點間分割或重新平衡工作負載以減少節點間資料塊傳送。OpManager Nexus 將這些 RAC 指標與節點狀態和 ASM 磁碟區容量一起呈現在一個視圖中。

CDB/PDB V$ 視圖範圍設定. 在 Oracle 19c 多租戶架構 (非 CDB 在 21c 已棄用)，V$SESSION，V$SYSSTAT，以及表空間視圖預設返回屬於當前容器的數據。在 CDB 根級監控顯示所有 PDB 的聚合指標。若要獲取每個 PDB 的可見性，請為每個 PDB 設置獨立的監控器或使用CON_ID 在您的查詢中進行篩選。例如，若要將會話等待查詢範圍限制在特定 PDB：

SELECT wait_class, COUNT(*) AS session_count,
       ROUND(AVG(seconds_in_wait), 2) AS avg_wait_sec
FROM V$SESSION
WHERE state = 'WAITING'
  AND wait_class <> 'Idle'
  AND con_id = (SELECT con_id FROM V$PDBS WHERE name = 'YOUR_PDB_NAME')
GROUP BY wait_class
HAVING COUNT(*) > 2
ORDER BY session_count DESC;

OpManager Nexus 支援自動 PDB 發現（在監控器建立期間將「發現可插拔資料庫」設為是）。

當監控器從正確的範圍收集數據後，下一節將說明當值超出閾值時該如何處理。

閾值設定與警報路由

群組級或整體健康警報將多個屬性狀態合併為單一信號；結果是警報雜音和模糊的路由。每個屬性的閾值是 Oracle 環境中正確的單位，其中緩衝區缓存命中率、表空间利用率、物理讀取和等待事件狀態都需要不同的響應。OpManager Nexus 直接支援此模式。

設定每個屬性閾值

OpManager Nexus 對 Oracle 監控屬性使用四種嚴重性狀態：

• 嚴重：一個已確認的問題需要立即採取行動
• 警告：一個潛在問題值得注意但尚未造成運營影響
• 清除：一個先前觸發的條件，目前已解決
• 未知：當屬性值與任何配置的嚴重性條件不匹配時顯示

請以 V$ Metrics 節的參考表作為每個屬性閾值的起點。Oracle 自己的 表空間預設值 (85%/97%) 與 ASM 預設值 (75%/90%) 比表格中的建議更寬鬆，所以請決定您的環境能否容忍那額外的餘量。物理讀取和會話計數閾值在它們有意義之前需要一個基線期間（請參閱操作基線建立部分）。

表空間統計資料收集在設定 > 執行效能掃描中配置。> 在 OpManager Nexus 中優化數據收集。從 Monitor Type 下拉選單中選擇 Oracle，然後從 metric 下拉選單中選擇 TableSpace Statistics。兩個排程選項：「在每個掃描週期收集數據」在每個掃描週期運行表空間收集（適合高增長 OLTP 環境）；「在自定義時間間隔收集數據」在固定時間排程收集（適合穩定的 OLAP 或數據倉庫表空間，且增長可預測）。

警示記錄收集遵循相同路徑：設定 > 性能掃描 > 優化數據收集，然後從指標下拉菜單中選擇 Oracle Alert Log。OpManager Nexus 在每次掃描時收集 alert log 條目，並將 alert log 歷史儲存一段可配置的保留期間，這對於將指標異常與特定的 Oracle 錯誤相關聯很有用。您可以在設置下的錯誤忽略字段中輸入已知的無害錯誤模式來抑制它們。> 性能掃描 > 數據庫伺服器.

警報檔監控

Oracle 警報檔會顯示沒有任何指標能夠自行捕捉到的錯誤。 ORA-600 (通常需要 Oracle 支援介入的內部錯誤)， ORA-4031 (共享池記憶耗盡，可能觸發級聯解析失敗)，ORA-27xxx (I/O 和作業系統錯誤)，以及指示數據檔或重做日誌損毀的媒體恢復事件，都是在警報檔中出現，而在 V$ 指標中出現之前。

盡可能於個別錯誤模式層級設定閾值。ORA-600 和 ORA-4031 需要重要嚴重性並立即升級。ORA-12514 (TNS 聆聽器錯誤) 在維護窗口期間可能需要警告嚴重性，但在其他時間則為重要嚴重性.

Webhook 和事件管理整合

為了將警報導向您的事件管理平台，請設定 webhook 動作。在 OpManager Nexus 中，前往管理員 > 警報/動作 > 動作，並建立 RestAPI 動作。提供您的事件平台 webhook URL，將表單提交方法設為 POST，並使用 OpManager Nexus 的可替換標籤來設定 JSON 載荷：

{
  "source": "$MONITORNAME",
  "host": "$HOSTNAME",
  "attribute": "$ATTRIBUTE",
  "severity": "$SEVERITY",
  "value": "$ATTRIBUTEVALUE",
  "message": "$RCAMSG_PLAINTEXT",
  "timestamp": "$STRMODIFIEDTIME"
}

在 OpManager Nexus 的 webhook 設定介面中，標籤無需輸入反斜線（例如，$MONITORNAME，$SEVERITY）。某些文件來源中顯示的反斜線是渲染產生的現象.

這個載荷包含$SEVERITY，它將目前的警報嚴重性（嚴重、警告或清除）傳遞給接收系統。當與清除事件搭配使用時，這可啟用任何接受進來網頁回調的事件平台的工單自動解決。

當達到閾值條件時，ServiceDesk Plus 集成會自動創建工單，而在警報解除時解決它們。它使用專用的 REST API 集成，而不是通用的 webhook 動作，但自動創建/自動關閉的行為是相同的.

在閾值和路由處理完成後，結束部分將引導監控設置，使其生效。

監控器設定及初始設定

要在OpManager Nexus中添加您的第一個Oracle資料庫監控器，請前往新監控器並在資料庫伺服器下選擇Oracle DB伺服器。輸入主機IP或主機名稱、埠、用戶名，並輸入有效的SID或主機連接字串，然後設定您的掃描間隔。

監控用戶至少需要：CONNECT權限，SELECT_CATALOG_ROLE（涵蓋DBA_* 觀察和最多 V$ 觀察在19c)，以及對底層 V_$ 表的明確授權，對於任何無法繼承角色的工具（例如，定義者權限的儲存過程，其中在執行時角色被禁用）：

GRANT SELECT ON V_$SESSION         TO monitor_user;
GRANT SELECT ON V_$SYSSTAT         TO monitor_user;
GRANT SELECT ON V_$SYSMETRIC       TO monitor_user;
GRANT SELECT ON V_$SYSTEM_EVENT    TO monitor_user;
GRANT SELECT ON V_$WAITSTAT        TO monitor_user;
GRANT SELECT ON V_$RESOURCE_LIMIT  TO monitor_user;

上述清單僅為代表性而非詳盡；本指南中的其他查詢也觸及 V$LOCK、V$ACTIVE_SESSION_HISTORY、V$TABLESPACE 和 V$PDBS，而 SELECT_CATALOG_ROLE 在角色感知的語境中已涵蓋。若您的工具無法繼承角色權限，請添加對應的 V_$ 權限，並GRANT SELECT ON V_$TEMP_SPACE_HEADER TO monitor_user; 若要保留傳統的 TEMP 查詢以進行臨時調試，

在多租戶環境中，將 Discover Pluggable Database 設置為是，以自動枚舉 PDBs。對於 RAC，在監控創建期間，請選擇 Oracle RAC Server 而不是 Oracle DB Server，提供掃描主機名稱或掃描 IP，並授權GV_$ 等同於監控用戶。OpManager Nexus 的文件說明列出了其特定 Oracle 監控實現的完整授權集。

監控啟動後：

1. 啟用 TableSpace 統計和 Oracle 警報日誌收集（設置 > 性能掃描 > 優化數據收集）
2. 以 V$ 指標參考表為出發點，設定每個屬性的閾值，包括緩衝區高速緩存命中率、表空間利用率，以及物理讀取
3. 設定 webhook 或 ServiceDesk Plus 整合，用於警報路由
4. 在收緊基於乘數的閾值（物理讀取和會話計數）之前，先收集基線數據一段足夠的時間（通常為兩到四週）

對於投票節奏：V$指標受益於次AWR間隔投票，表空間統計資料容忍較低頻率的間隔，而警報日誌最好在每個循環中進行投票，以便錯誤能在投票窗口內被捕捉。

本指南中的分類框架（從DB時間比率到等待類別路由到V$指標閾值）為您提供從症狀到矯正措施的可重複路徑。OpManager Nexus 將 Oracle 事件與周圍的堆疊放在同一時間軸上，跨本地和 SaaS 部署，這減少了上下文切換，縮短了事件解決時間。