小編精選 - 技術文章翻譯 · 11月05日

開始使用 Stored Procedure。可視化資料庫效能風險的 DB360 終於正式 GA！

1. 前言

2026年10月，New Relic 的資料庫效能分析功能「Database 360（DB360）」正式開始一般提供（GA）。

在預覽版發表時，我們曾於「Oracle 也支援了！透過 New Relic 的新功能「Database 360」從執行計畫找出瓶頸！」一文中，介紹了各功能頁面的基本角色與執行計畫的視覺化。

這次隨著正式 GA，除了支援的資料庫引擎擴充之外，也新增了許多在實務現場需求很高的新功能。本文將以 GA 後更新的新增功能與擴充的支援環境為主進行說明，並順便快速介紹既有的基本功能頁面。

2. GA 伴隨的主要更新重點

全面支援 4 大 RDBMS 引擎與多平台支援

4 大引擎皆已 GA：Oracle、Microsoft SQL Server、MySQL、PostgreSQL 這 4 大主要資料庫皆已正式提供（GA）。
多平台支援：除了內部部署與雲端的自架（VM / 容器）環境外，也涵蓋 AWS RDS、Amazon Aurora、OCI Autonomous Database 等全代管環境。

支援的資料庫

新增 Stored Procedure 專用監控畫面

以程序為單位的視覺化：新增了專為 Stored Procedure / PL/SQL / T-SQL 設計的分析畫面。
不僅能分析單一 SQL 查詢，也能直接分析與辨識複雜 Stored Procedure 整體的效能影響與處理時間。

Blocking Chain 與 Deadlock 的視覺化

快速找出頭號阻塞者：透過互動式 UI，可以立即找出成為瓶頸根源的「頭號阻塞者（blocking session）」。
可詳細追蹤連鎖式等待關係、彼此競爭的 session，以及即時持有的資源。

Blocking Chain 畫面

完全符合 OpenTelemetry（CNCF）並支援大規模部署

OpenTelemetry 優先：已透過約 100 件 PR 貢獻至 CNCF 公開儲存庫，能與標準 OpenTelemetry（OTel）收集器無縫協作。也完整支援 BYO-Collector（自帶既有收集器）。
大規模導入自動化：已備妥可透過 Docker、Chef、Ansible、CLI 進行自動化部署的環境，方便批次展開。

3. DB360 的基本功能頁面回顧

以下是既有主要畫面與功能頁面的簡要回顧。（各功能更詳細的畫面操作與執行計畫閱讀方式，請參考前一篇文章）

Overview

這是從整體俯瞰資料庫健康狀態的畫面，例如整體 CPU 使用率、記憶體、活躍 session 數、處理筆數等。

Overview 畫面

Top databases

顯示 DB 伺服器內所有邏輯資料庫的概要資訊。
可視化各邏輯資料庫的資源使用狀況與處理狀況，用來確認是否有大量消耗資源的邏輯資料庫，或是噪音較多的邏輯資料庫。

Query performance

用來找出慢查詢，並透過樹狀顯示的圖形化執行計畫（Explain Plan）進行瓶頸分析。

Query performance 畫面
執行計畫畫面

Sessions

可視化活躍中／被阻塞中的 session 狀態。
Sessions 畫面

Wait events

提供對鎖定等待、I/O 等待等會造成處理延遲的等待事件之分類與分析。

Wait events 畫面

Clients

可視化來自各應用程式與使用者的連線負載狀況。
Clients 畫面

Stored Procedure

針對 Oracle 的 PL/SQL、SQL Server 的 T-SQL 等各類 Stored Procedure，分別分析與視覺化其執行效能、呼叫頻率、處理時間，以及單一 Stored Procedure 內 SQL 的處理時間等資訊。
Stored Procedures 畫面

4. 開始方式與設定概要

從 New Relic UI 的「Integrations & Agents」選單中搜尋各資料庫引擎的「Database 360」磁貼，依照 UI 上的指引進行設定，並建立監控用使用者、授權必要權限，以及導入 NRDOT（New Relic Distribution of OpenTelemetry）收集器。NRDOT 除了可手動導入外，也能透過 Ansible、Chef、Docker 或 CLI 進行大規模批次設定。
Guided UI Flow