データベース

Database Performance Analyzer (DPA)の開発状況 (updated March 2026)

DPAの最新リリース状況

  • データベース検出機能により、ネットワーク上のデータベースを検索できるため、データベース環境を簡単に特定して登録し、可観測性の実現までの時間を短縮できます。
  • DPA Centralの機能が拡張され、環境全体のビューが表示されるようになりました。カスタムプロパティでフィルタリングしたり、カスタムプロパティを列として表示したりできます。その他の改善点として、ページネーション、グループ化ビュー、SAMLのサポートが追加されています。
  • 「AI Query Assist」機能で SolarWinds AI を活用し、SQL Server および Oracle ターゲットのクエリパフォーマンスを最適化するためのクエリ書き換えの提案を提供します。
  • 多数の Azure SQL DB メトリクスが追加され、tempDB の使用状況を含め、データベースの動作のさまざまな側面とクエリパフォーマンスを関連付けることが可能になりました。
  • PostgreSQLおよびMySQLデータベースワークロード向けのテーブルチューニングおよびインデックスアドバイザー。
  • DPAのPlatform Connectを通じて、ServiceNowおよびPagerDutyとのアラート通知連携が簡素化されました。
  • IPv6専用またはハイブリッド環境向けのIPv6サポート。
  • 認証サポートの強化(MySQL向けのgMSAおよびSHA2パスワード)。

現在取り組んでいること

以下は、DPAに関して現在取り組んでいる、または検討中の事項の一覧です:

 

  • データベース検出機能について、検出結果をDPAの各インストール間で共有し、異なるDPAインストールに登録されている検出結果を無視するようにします。また、検出対象をクラウドアカウントにも拡張します。
  • DPAをDockerコンテナで提供し、ポータブルかつ効率的なデプロイ環境を実現します。
  • DPAの統合の柔軟性を高めるため、汎用的なWebhookを統合用に導入します。
  • SAP Hanaを監視対象としてサポートします。これにはオンプレミスおよびHana Cloudのデプロイメントが含まれ、シングルコンテナおよびマルチコンテナアーキテクチャに対応します。
  • Oracle Autonomous Databaseを監視対象としてサポートします。
  • DB2の最新バージョン向けに、セッションブロッキング情報を提供します。
  • 既存のインデックス、テーブルサイズ、カラムのカーディナリティなどの追加プロンプト入力により、AIクエリアシストの出力品質を継続的に向上させます。また、将来のリリースでは他のDBMSタイプにも対応を拡大します。
  • ホームページにアラームアイコンが表示されないよう、チューニングアドバイザーをミュートする機能を追加します。これは、監視対象への変更を行う能力が限られている場合に役立ちます。これらのアドバイザーをミュートすることで、対処不可能な問題に気を取られることがなくなります。
  • チューニングの意思決定を支援するため、SQL ServerのtempDBのアクティビティおよび構成情報の可視化を拡充します。DPAは、懸念されるtempDBの動作や状態について通知するアラートを提供します。
  • ユーザー権限管理用のエンドポイントを含むDPAのAPI。
  • SolarWinds製品(SquadCastおよびService Desk)へのアラート通知(Platform Connect経由)。
  • 複数のDPAサーバー間で一貫性を維持できるようにする、大規模なDPA環境向けの管理機能。
  • DPAのセキュリティが、米国連邦政府および共通基準相互承認協定(CCRA)参加国での利用に必要な厳格な保護プロファイルを満たすことを保証するための、共通基準(Common Criteria)認証。

 

(注) 上記の機能の記載順は優先度を示すものではありません。また上記のリストは、現在開発中または検討中の項目を示していますが、これらの機能がいつ、あるいは実際に提供されるかを保証するものではありません。

 

Database Performance Analyzer (DPA) 2026.1 のGA

DPA 2026.1 リリース

Database Performance Analyzer (DPA) 2026.1が一般提供(GA:general availability)を開始したことをお知らせいたします。本リリースでは、アラートメールの認証にOAuth 2.0に対応したほか、ネットワーク上のデータベースを特定し、監視対象として検討できるようにする新しい検出機能を導入しています。

Microsoft Exchange Online 向け OAuth 2.0

セキュリティ強化のため、Microsoft は Exchange Online における基本 SMTP 認証を段階的に廃止し、OAuth 2.0 への移行を進めており、2026年3月からこの変更が適用されます。この変更は、アラートメールの配信に Exchange Online を使用するように DPA が設定されている環境に影響します。

サービスの中断を防ぐため、DPA 2026.1 にアップグレードし、Microsoft Exchange Online との通信に OAuth 2.0 を使用するように SMTP 設定を更新してください。

image.png

新機能:データベース検出 !

DPA 2026.1 では、ネットワーク上のデータベースインスタンスを特定し、監視のためのオンボーディングプロセスを効率化する新しいデータベース検出機能が導入されました。

この機能により、DPAはユーザーが指定したIPアドレスとポートをスキャンし、DPAにまだ登録されていないデータベースインスタンスを検出します。検出結果は登録ワークフローに直接反映され、IPアドレスとポート情報が自動的に入力されるため、導入から価値創出までの時間を短縮し、データベース環境全体の可視化を加速します。

今後の検出機能の強化点には以下が含まれます:

  • クラウドアカウントベースのデータベース検出
  • 複数のDPAデプロイメント間での検出結果の共有
  • インテリジェンスと自動化の拡張

image.png

 

迫りくる脅威:DBAの大量離職

DBA(データベース管理者)のバーンアウト(燃え尽き)は、単なる人材確保の課題にとどまらず、ビジネス上のリスクでもあります。「State of Database Report」調査によると、DBAの38%が職を辞することを検討したことがあるとのことです。

 

1人の離職がもたらす影響:

  • 財務的損失:DBA1人を補充するのに6~9ヶ月分の給与が必要
  • 知識の喪失:組織のノウハウが失われる
  • 運用リスク:ダウンタイムの増加、システムの不安定化、およびインシデントの深刻化

 

バーンアウトの原因とは?その「消火活動」の過負荷

なぜDBAは退職を考えているのでしょうか?それは、彼らの1日が純粋に事後対応的な業務に費やされているからです。報告書によると、彼らは週に27時間(時間の68%近く)という驚くべき時間を、以下の業務に費やしています:

  • アラートやチケットへの対応
  • バックアップと復旧
  • パフォーマンス問題の修正

「消火活動」に費やされる1時間は、最適化、自動化、あるいはイノベーションに費やされるはずだった1時間です。この不均衡が仕事の満足度を蝕み、バーンアウトを加速させています。

 

監視における重大な認識のギャップ


この業務負荷の問題は、経営陣とDBAの間にある根本的な認識のズレによってさらに悪化しています。経営陣は、監視体制が包括的かつ統合されていると想定しがちです。一方、DBAはそれが
危険なほどサイロ化されていることを知っています:

  • 経営陣の認識:IT経営幹部の50%近くが、自社の環境は統合されていると考えている
  • DBAの現実:これに同意するDBAはわずか40%

この認識のギャップは、重大な死角を生み出し、アラート疲労を助長し、インシデントの見落としを招くことで、リスクの高い非効率性を招いています。この乖離は、すでに手一杯のチームに直接的なプレッシャーを加えています。

 

事態を悪化させる認識のズレ

経営陣とDBAの認識が一致していないと、非効率性とリスクが倍増します。認識のズレは、単にフラストレーションを引き起こすだけでなく、対応時間の遅延、ダウンタイムの増加、そしてイノベーションの阻害につながります。その影響はビジネス全体に波及し、人事部門だけに留まりません:

  • 離職コストの増加:DBAの大量離職という悪循環を招く
  • 対応時間の遅延:事業継続性に直接的な影響を与える
  • イノベーション能力の低下:デジタルトランスフォーメーションの取り組みを阻害する

DBAの燃え尽きがもたらす経済的コストを削減し、経営層とDBAの間の溝を埋める方法はDPA(Databese Performance Analyser)の導入です。

 

データ中心型企業になる方法

物理世界では、メールから猫動画、このブログ記事に至るまで、情報は絶えず生成され、管理され、消費されている。エラーメッセージやシステムログ、誰も読まないアラートメールは言うまでもない。そしてこのデジタルデータは決して消滅せず、ROT(冗長・陳腐・無意味な情報)の氾濫を招く。

データ中心の姿勢を強化すれば、ROTの過剰を削減し、適切なデータのみを収集して情報に基づいた意思決定が可能になる。複雑である必要はない。このサーバーは何度再起動されたか?再起動にはどれくらい時間がかかるか?データ収集は、こうした単純な質問に過剰なデータ加工なしで答えられるようにすべきです。データは何に使うのか?プレゼン資料や監視環境のダッシュボード用かもしれません。あるいは開発マネージャーに「チームが2週間データベースサーバーにログインしていない」と示すためのメトリクス収集かもしれません。最終目標を明確に把握することで、最も合理的な方法でデータを収集できます。質問はしばしば仮定に基づきますが、データから得られる情報は偏見を裏付けるのではなく、事実を明らかにする助けとなるべきです。例えば、サーバー再起動がパッチの頻繁な適用によって引き起こされているかどうかを判断したい場合、「パッチはどのくらいの頻度で適用されていますか?」と尋ねる代わりに、「再起動を必要とするパッチはいくつありますか?」と尋ねることができます。この数値をサーバー再起動の総数と比較することで、パッチ適用が再起動に与える影響頻度を結論付けられます。

  1. 適切な質問から始める
  2. 最終目標を設定する
  3. 良い質問を投げかける

データが容易に入手できる現代では、価値あるデータのみを収集することに集中するのが難しい場合があります。データ中心の考え方を強化し、データ駆動型のアプローチを採用することで、環境内のROT(Redundant, Obsolete, Trivial)を減らし、データの過剰蓄積を防ぐことができます。

Database Performance AnalyzerはSQLパフォーマンスに何ができるのか

Database Performance Analyzer(DPA)は、継続的な監視を提供し、応答時間分析と履歴動作ログを組み合わせることでパフォーマンスのベースライン確立を支援し、SQLパフォーマンスチューニングプロセスにおける推測作業を大幅に削減するように設計されています。DPAを使用すると、特にDPAのインテリジェントな機械学習機能と組み合わせることで、異常な動作を迅速に検出することも可能です。

DPAに統合されたテーブルチューニングアドバイザー機能は、クエリと実行計画を分析し、非効率なSQLクエリが実行されているテーブルを特定することで、Microsoft SQL Serverの最適化機会に対処し、情報に基づいたチューニング判断を下せるよう支援します。DPAの組み込みSQLパフォーマンス分析ツールでは、相対的なワークロード順にランク付けされた、テーブルにアクセスする非効率なSQLの詳細な分析も確認可能です。

DPAにはクエリパフォーマンスアナライザー機能も含まれており、クエリに関する最重要データを収集し、直感的で分かりやすいダッシュボードビューで表示します。クエリ詳細ページでは待機タイプやクエリ・チューニングアドバイザーを色分け表示し、チャートを組み立てることで、ユーザーは特定されたパフォーマンス問題を容易に検証・対処できます。カスタマイズ可能なレポートとアラートにより、ブロック階層やブロッキングがデータベース全体のパフォーマンスに与える影響に関する洞察も提供します。

SQLパフォーマンス・チューニング・ツールどう役立つのか

多くの企業や組織(オンライン小売業者から政府機関まで)の主要な機能は、データベースにおける情報の保存とアクセスを中心に展開しています。内部ユーザーも外部ユーザーも、アプリケーションやウェブサイトが効率的かつ迅速に動作することを期待しています。このため、サーバーとデータベースが可能な限り効率的に機能することが重要です。

1回のクエリで数ミリ秒の遅延はさほど大きく感じられないかもしれませんが、データベース内の各クエリで遅延が発生すると、それはすぐに累積していきます。これに、生成され続ける膨大なデータ量が加わることで、データベースへの書き込みや情報取得のプロセスはますます煩雑で時間のかかるものとなります。ビジネスに不可欠なプロセスに遅延や速度低下が生じると、組織全体の機能が損なわれる可能性があります。

効果的なMS SQLチューニングには、データベース管理者とIT専門家がSQL Serverのパフォーマンスを常に把握し、データベース関連の操作が可能な限り効率的に実行されるようにすることが求められます。

なぜSQLパフォーマンス・チューニングは重要なのか

多くの企業や組織(オンライン小売業者から政府機関まで)の主要な機能は、データベースにおける情報の保存とアクセスを中心に展開しています。内部ユーザーも外部ユーザーも、アプリケーションやウェブサイトが効率的かつ迅速に動作することを期待しています。このため、サーバーとデータベースが可能な限り効率的に機能することが重要です。

1回のクエリで数ミリ秒の遅延はさほど大きく感じられないかもしれませんが、データベース内の各クエリで遅延が発生すると、それはすぐに累積していきます。これに、生成され続ける膨大なデータ量が加わることで、データベースへの書き込みや情報取得のプロセスはますます煩雑で時間のかかるものとなります。ビジネスに不可欠なプロセスに遅延や速度低下が生じると、組織全体の機能が損なわれる可能性があります。

効果的なMS SQLチューニングには、データベース管理者とIT専門家がSQL Serverのパフォーマンスを常に把握し、データベース関連の操作が可能な限り効率的に実行されるようにすることが求められます。

SQLパフォーマンス・チューニングはどのように始動するのか

SQL Serverデータベースのパフォーマンスチューニングの第一歩は、必要または望まれるほど効率的に実行されていない遅いSQLクエリを特定することです。

SQLチューニングには、将来予測可能な問題を未然に防ぐ「予防的」アプローチと、特定のユーザー問題が発生した際の「事後対応的」アプローチがあります。データベースクエリのチューニングにおいて、DBAが考慮すべき基本的なベストプラクティスを以下に示します:

  • インデックスは慎重に作成する。 インデックスはデータ取得用のデータ構造であり、行の選択を高速化しますが、ボトルネックを避けるため慎重に作成する必要があります。
  • ループ処理を避ける。 クエリ実行時の繰り返し処理や過剰負荷を回避すべきです。
  • SQLサブクエリの相関を避ける。 サブクエリは親クエリを参照し、行単位で処理されるため、処理速度が低下します。

待機時間と統計情報は、SQL Serverのパフォーマンスチューニングの重点領域を特定する有効な手段です。SQL Serverは「スレッド」を介してユーザー要求を管理し、各種スレッドのパフォーマンスを監視することで、管理者はどのクエリが低パフォーマンスであるかをより正確に判断できます。チューニングプロセスの目的は以下の通りです:

応答時間の短縮: ステートメント実行から応答までの時間

スループットの最適化: ステートメント処理に必要なリソース量

ただし、SQL Server パフォーマンス問題の根本原因を特定するには、データベース管理者はデータベースとサーバーの全レイヤーに関する洞察が必要となる場合があります。SQL Server チューニングツールは、上位 SQL ステートメント、待機タイプ、ブロックされたクエリ、およびインデックス不足がサーバーやデータベースのパフォーマンスに与える影響に関する理解を深めるプロセスを迅速化・効率化するのに役立ちます。

SQLパフォーマンス・チューニングとは

SQLパフォーマンスチューニングは、リレーショナルデータベースのクエリを可能な限り迅速かつ効率的に実行するために設計された一連の手順とプロセスです。SQLチューニングにはいくつかのステップが含まれます。まず、遅延が発生しているクエリを特定し、次にそれらのクエリを最適化して効率を最大化し、応答時間を短縮します。SQL Server、MySQLなど、多くのリレーショナルデータベースでSQLチューニングが必要となる場合があります。

管理者はシステムレベルでサーバーのパフォーマンス問題に対処しようと試みることができます(追加メモリやプロセッサの導入など)。しかし、これらの対策は実装コストが比較的高く、SQL Serverへの遅延クエリの根本原因に対処できない場合があります。SQLパフォーマンスチューニングは、不適切に記述されたSQLクエリや非効率的なインデックスを特定することでパフォーマンス向上を支援します。これはハードウェアや技術仕様の改善よりも、より的を絞った解決策となり得ます。

ただし、SQLのパフォーマンスチューニングは、特に手動で行う場合や大量のデータを管理する組織にとっては困難な作業となり得ます。こうした調整(たとえ小さな変更であっても)は、SQLサーバーやデータベースのパフォーマンスに広範な影響を及ぼす可能性があります。

データレプリケーションシステムにおける最大のリスクは、宛先のデータがソースの実際の状態を反映していないことです

分散環境では、データレプリケーションは、可用性、スケーラビリティ、回復性を確保するための確立されたプラクティスです。ただし、最大のリスクの 1 つは、デスティネーションにレプリケートされたデータがソースの現在の状態を反映していないことです。

データの不整合として知られるこの不整合は、ビジネス上の意思決定のエラーから自動化されたプロセスの誤動作まで、深刻な結果をもたらす可能性があり、システム全体の信頼性を直接損ないます。

複数のノード、データセンター、または分散サービスで運用されている組織では、テクノロジーガバナンスの原則に従って堅牢でスケーラブルで一貫性のあるアーキテクチャを構築するには、レプリケートされたデータの整合性を最優先事項にする必要があります。

 

📌 このずれの原因は何ですか?

 

➡️ レプリケーション・モデルの設計が不十分

➡️ ノード間のレイテンシーが高い

➡️ 書き込み競合の処理におけるエラー

➡️ 検証と整合性監査の欠如

📌 このリスクを軽減するにはどうすればよいでしょうか?

➡️ 効率的なトポロジーの設計

➡️ 整合性とリカバリの明確なポリシー

➡️ 運用の継続的な監視とトレーサビリティ

➡️ 技術アーキテクチャとビジネス目標の整合性

 

今日、企業のデータは戦略的資産です。

このため、複製されるものが原点に忠実であることを保証することは、事業継続性、制度的セキュリティ、デジタルの持続可能性のための構造的条件です。

DynamoDBバックアップについて

●DynamoDB Streamsを活用して近リアルタイムのバックアップ強化を実現: 定期的なバックアップを補完し、部分的なデータ損失が発生した場合に最近の更新を再実行することで、最後のバックアップと現在の状態のギャップを最小限に抑えます。

 

●重要なデータにバージョン管理を実装(S3エクスポート): エクスポートされたバックアップの履歴コピーを維持することで、追加の保護層を提供し、誤った上書きや削除からの復旧を容易にします。

 

●バックアップ前の検証を自動化: Lambda関数またはAWS Systems Manager Automationを使用して、バックアップ開始前にテーブルの状態を検証します。例えば、データの一貫性を確認したり、スループット制限がバックアッププロセスに影響を与えないことを確認します。

 

●オンデマンドバックアップとPITRを組み合わせる: 両方を組み合わせることで、長期的な履歴記録を維持しつつ、最近の変更に対する粒度の細かい復元を可能にします。

 

●AWS Backup Vault Lockをコンプライアンスに利用: この機能は、保持期間中にバックアップが変更または削除されないようにし、金融や医療業界などの厳格なコンプライアンス要件を満たします。

 

Database Performance Analyzer (DPA): 2024.4

Database Performance Analyzer (DPA) 2024.4 ソフトウェアの提供のお知らせです。

  • 柔軟なデータベースライセンス: セルフホスト型データベース製品に対するライセンスの付与方法を変更しました。 セルフホスト型ライセンスを1つ取得するだけで、ニーズに合わせてDPAを使用できます。 Azure SQL Databaseを監視している場合は、DBaaS環境専用の分割コストライセンスも導入しました。これにより、クラウドデータベースを簡単にコスト効率よく組み込むことができます。詳細については、担当のアカウントマネージャーまでお問い合わせください。
  • MySQL/Percona MySQLワークロード分析は、SQL Server、Oracle、PostgreSQL(実行計画収集)用の強力なDPA機能、インデックスアドバイザ、テーブルチューニングアドバイザなど、人気の高い機能が含まれています。
  • また、MySQL に関するセキュリティ対策も改善し、caching_sha2_password 認証をサポートするようになりました。チューニングアドバイザと併用することで、MySQL ユーザーの大幅な増加が見込まれます。
  • セキュリティを念頭に置き、お客様からご要望のあった Windows のグループ管理サービスアカウント(gMSA)認証もサポートするようになりました。
  • Oracle 関連では、Oracle のマルチテナント・アーキテクチャ上のターゲットとしてCDB をサポートするようになりました。これにより、より広範なアラート機能と可視性機能を備えた PDB を活用するインスタンスの全体像が完成しました。

 

Database Performance Analyzer (DPA):2024.3

Database Performance Analyzer (DPA)と の最新統合機能として、ServiceNow®とPagerDuty®を発表できることを嬉しく思います。この機能強化は、多くの要望に応えるもので、アラート通知を拡張し、IT運用をこれまで以上に効率的かつ迅速に行うことを可能にします。
DPAは、ServiceNow®とPagerDuty®に直接アラートを送信できるようになり、より効率的なワークフローが可能になりました。これにより、インシデントとイベントをより効果的に管理できるようになり、ITイベントの適切な通知、追跡、論理的なワークフローを確保できます。

動作方法
この統合により、SolarWinds Platform Connect 経由で SQL Sentry と DPA が貴社の ServiceNow® および PagerDuty® アカウントに接続されます。 設定が完了すると、DPA によって生成されたアラートは自動的にこれらのチャネルに送信され、IT チームはリアルタイム通知を受け取ることができ、問題が発生するとすぐに適切な優先順位付けと対処が行われるようになります。

統合のメリット
対応の迅速化:ServiceNow®とPagerDuty®にリアルタイムのアラートが送信されるため、チームはインシデントに迅速に対応でき、ダウンタイムを削減し、システムの信頼性を向上させることができます。

●インシデント管理の一元化:この統合により、すべてのITイベントを一元的に管理できるようになります。一元化によりワークフローが簡素化され、問題の追跡と解決が容易になります。
●業務の合理化:新しい統合により、適切なタイミングで適切な担当者にアラートが送信されることが保証されます。これにより、ITイベントやインシデントの優先順位付けと管理がより効果的に行われ、リソースが最適に利用されることが保証されます。
●すべてのサブスクリプション顧客が利用可能
この機能は、追加費用なしで、すべてのサブスクリプション顧客が利用可能です。これは、お客様のITインフラストラクチャを効率的に管理するための最高のツールと統合を提供するという、当社の継続的な取り組みの一環です。

データベース・バックアップへのヒント

●階層型ストレージのアプローチ:迅速な復元のために、最近のバックアップは高速ストレージ(SSDなど)に保存し、古いバックアップは安価で低速のストレージ(クラウドコールドストレージなど)に保存します。これにより、パフォーマンスとコストのバランスを取ることができます。

●きめ細かなバックアップウィンドウのスケジュール:高度な監視ツールを使用して、システム負荷とユーザーのトラフィックパターンを分析します。特に24時間365日稼働の業務では、パフォーマンスへの影響を最小限に抑えるため、最も業務が少ない時間帯にバックアップをスケジュールします。

●バックアップ・チェーニングの使用:増分バックアップを定期的にフル・バックアップにマージする「バックアップ・チェーニング」を導入します。これにより、リストアの複雑さが軽減され、増分バックアップ・プロセスの効率が向上します。

●クロス・データベースの整合性チェック:相互に作用する複数のデータベース(マイクロサービス・アーキテクチャなど)を扱う場合は、リストア時に依存関係にあるデータベース間の整合性を確保するために、システム全体のバックアップの整合性を定期的にチェックします。

●バックアップのメタデータ:特に複雑な環境では、データベースのスキーマと構成の詳細を常にバックアップします。バックアップに重要なメタデータが欠けていると、完全に機能する状態へのリストアに時間がかかったり、不完全な結果になることがあります。