データベースの性能問題に悩まされていませんか？New Relicの新機能「Database 360」を活用し、データベースのボトルネックを可視化し、迅速に原因を特定・改善する方法を解説します。
この機能はプレビューとして公開されている機能でまだ開発中です。
はじめに
アプリケーションのパフォーマンス問題が発生した際、「アプリ、インフラ、DBのどこに原因があるのか」の切り分けに時間を取られた経験はないでしょうか。
従来の調査では、アプリチーム、インフラチーム、DBAと、複数のチーム間での状況確認（ファクトのすり合わせ）だけで多くの時間を費やすこともあったかと思います。さらに、Oracleデータベースのように複数のアプリケーションやバッチで共有し、同時にアクセスされることが多い場合は、あるSQLが過剰なリソースを消費して他のSQLに影響を与えることもあるため、問題を特定するのは困難になっていきます。
こうした「チーム間で認識合わせをする手間」や「原因特定の困難さ」という課題を根本から解決するのが、今回ご紹介する Database 360 (DB360) です。
最新のアップデートの詳細はこちら
New Relic アップデート一覧
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
Database 360とは
Database 360 (DB360) は、データベースのクエリテレメトリ、APM（アプリケーション）、そしてインフラストラクチャのコンテキストを1つのUIに統合した、New Relicの新しいフルスタックDB根本原因分析（RCA）機能です。
DB360では、データベースが「独立した単なる箱」ではなく、依存しているアプリケーションサービスや基礎となるインフラと紐づいたエンティティとしてモデル化されます。これにより、画面を切り替えることなく「何が変更され、どこに影響があり、次に何を直すべきか」を1つの画面で直感的に把握できるようになります。
DB360で可視化できる情報
New RelicはOpenTelemetryベースのコレクターを利用することで、Oracleデータベースから以下のような詳細なパフォーマンス情報を自動収集し、DB360上で可視化できます。
1. クエリの実行詳細とボトルネックの可視化
- スロークエリの特定: 応答時間の閾値を超えたクエリの実行回数や経過時間
- 子カーソルの詳細: SQLの実行ごとに生成される子カーソルの経過時間やCPU時間、I/O待機時間
- リソース消費: 物理/論理読み書き回数、ディスクブロックの読み書き時間
2. 実行計画（Explain Plan）
Oracleのオプティマイザが選択した SQL実行計画（推定コスト、カーディナリティ、リソース見積もり、インデックス有無など） を直感的なUIで確認できます
3. セッションとシステム全体の健全性
- アクティブ/非アクティブセッション数、SGA/PGAのメモリ利用状況、バッファキャッシュのヒット率
- テーブルスペースごとの割り当て容量や使用率
今回はOracleを例にご紹介していますが、DB360はSQL Serverにも対応しています。
収集しているメトリクスの一覧はこちらをご覧ください
始め方
Database 360によるOracle監視機能は、現在プレビュー版として提供されています 。まずプレビュー機能を有効化した後にセットアップを行います。
1. Previews & Trials の有効化
- New Relic UIにログインし、画面左下のユーザー名をクリックします。
- Administration > Previews & Trials を選択します。
- Performance Risks Inbox の機能を「Opted in (有効)」に切り替えることで、すぐに利用が開始できます。
2. NRDOT Collectorのセットアップ
Oracleデータベースのテレメトリを収集するために、New Relic Distribution of OpenTelemetry (NRDOT) Collector を導入します 。こちらの手順を参考にNRDOT Collectorのインストールと設定、さらにOracleの設定を行ってください。
オンホスト環境またはマルチテナント環境のOralceと、RDS環境のOracleで設定手順が異なります。
設定ファイルにパスワードを平文でハードコーディングすることは避けましょう 。NRDOTでは環境変数を利用した AES暗号化 や、AWS Secrets Manager から実行時に安全にシークレットを取得する機能がサポートされています
3. （オプション）APMとDB相関の有効化
APMとの相関関係を設定すると、DB360の真価を発揮することができます。これにより、「どのマイクロサービスが、どのクエリを発行してDBに負荷をかけているか」 を正確にトラッキングすることができるため、APM側/Oracle側、双方から正確に原因調査をすることができるようになります。
2026年5月現在はJavaのAPMにしか対応していません。
設定する場合はこちらの手順を参考に設定してください。
実際の画面
DB360には全体の概要を把握するためのOverviewと、Slow Queryの詳細を確認するためのQuery performanceというメニューがあります。
OverView
処理件数、セッション数、トランザクション数、CPU利用率、コネクション数、バッファ・キャッシュへの読み書き回数などの推移を見ることができます。
Query performance
Active QueriesとCompleted Slow Queriesに分かれており、それぞれ該当のクエリを選択すると詳細を確認することが出来ます。
対象のスロークエリを開くと、実際のクエリや、実行回数、処理行数、CPU時間などを確認することができます。
さらに、最下部には、待機時間に加えて、ツリー表示された実行計画を確認することができます。
Query performance analysis (実行計画)
実行計画が可視化され、処理順やコスト、インデックス有無などが直感的に理解できるようになっています。
インデックスが張られていない場合はこのような表示になります。
ここから、処理順、インデックスやスキャン行数などが想定通りか、最適になっているか、を確認し、SQLやテーブル設計の改善につなげることができます。
その他のメトリクス
実際には、DB360のデフォルトで用意されているUIで表示されている情報以外にも、様々なメトリクスが自動収集されているため、確認する場合はData Explorerからoracledbと入力してご確認ください。その中で可視化したいメトリクスがあれば、DashboardやNotebooksを作成してチームで共有すると問題解決の強力な武器になります。
まとめ
今回は「Database 360」では、紹介した実行計画の可視化だけでなく、待機タイプ・ロック分析によるデッドロックの把握や、過剰にリソースを消費し、他の処理に悪影響を与えている状態を把握する、 アイドル状態やアンダーユーズドなインスタンスを特定し、クラウドコストを最適化する、といった事が可能になります。
なお、データベース単体でボトルネックを探すだけでなく、システム全体を俯瞰して「そもそもどのトランザクションが全体に最も影響を与えているか」をスクリーニングするには、APMのTransaction Eventを活用した優先順位付け戦略が非常に有効です 。
具体的なスクリーニング用のNRQLや、N+1問題とSlow Queryを綺麗に切り分ける全体のワークフローについては、こちらの素晴らしい記事「「どこから直せばいい？」を解決する。New Relicを使ったDBパフォーマンス改善の優先順位付け戦略」で詳しく解説されています 。
APM側での優先順位付け と、DB360によるDディープダイブ を合わせて利用することで、推測ではなく「計測」に基づいた、より精緻で迅速な課題解決が実現できます 。ぜひ、この強力なフルスタックRCAを体験してみてください！
DB360はSQL Serverにも対応していますので、ぜひお試しください。
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！
New Relic株式会社のX(旧Twitter) や Qiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！