Database Performance Analyzer (Ignite) についてよくある質問

データベース管理者は、データベースのパフォーマンスにおけるスパイクに注目しがちです。これは問題のある動作を特定する良い方法ですが、動作のスパイクを分析することだけがパフォーマンスの変化を示す指標ではありません。実際、ほとんどの実稼働データベースでは、パフォーマンスの変動は正常であり、予期されるべきものです。データベース管理者は、予想される変動を考慮し、予期しないものを呼び出す方法を必要としています。

Database Performance Analyzer(DPA)のスマートなSQLデータベース異常検知は、スパイクを越えて、予想される変動を考慮し、何か予期せぬことが起きたときに指摘することができます。この異常検知ツールは、そのような事象をハイライト表示し、標準から逸脱した事態を知るための複数の方法を提供します。

狭い知識に頼っていると、新しい人がそれを習得するのは難しいです。また、大規模な環境では、深く広く理解することができない場合もあります。狭い知識の必要性を排除し、Database Performance Analyzer（DPA）の機械学習アルゴリズムに正常な動作パターンの「理解」の自動化を任せましょう。重要なリソースが異動したときに知識が流出しないように、知識を自動化して保持し、チーム全員の利益につなげます。

DPAの機械学習アルゴリズムは、時間の経過とともに賢くなるように設計されており、より多くのデータを収集することで予測精度を向上させます。

●Database Performance Analyzer (DPA) は、最も複雑なデータベース・パフォーマンスの問題を発見し解決するために設計されています。

●Database Performance Analyzer (DPA)データベースのパフォーマンスに問題がある箇所を一目で確認でき、さらに詳細な情報を得るために簡単に移動することができます。DPAは、単一のインストールで、すべての主要なデータベース・システムでこれを実現できます。

●Database Performance Analyzer (DPA) を使用して、最もリソースを消費し、最も問題を引き起こしているSQLに焦点を当てれば、SQL文のチューニングは容易になります。グラフの各色は、個別のSQLステートメントを表します。

●Database Performance Analyzer (DPA)は、SQL文のテキストをドリルダウンして詳細を確認することも可能です。

●Database Performance Analyzer (DPA)のダイナミックベースラインでは、詳細なメトリクスと数年にわたる履歴を表示し、長期にわたる完全なパフォーマンスストーリーを物語るトレンドとパターンを確認することができます。

使用例と導入範囲

当社では、Database Performance Analyzerを使用して、データベース全体の健全性におけるプロアクティブなパフォーマンス監視と異常検出を行っています。この製品によって、データベースパフォーマンスの全体像を初めて見ることができます。また、アラートとメール通知を設定することで、時間を大幅に節約しています。私たちが最もよく使うケースは、実行プランの変更に対応し、システムのエンドユーザーがパフォーマンスの問題や応答時間について不満を持ち始める前に適切な措置を取ることです。

長所と短所

(+)機械学習による異常検知 – バージョン12の新機能で、統計的分析が非常に便利です。
(+)日次と年次で作業量を比較することで、成長の全体像を把握し、キャパシティを考慮することができます。
(+)直感的なパフォーマンス分析 – 問題点を簡単に調べ、根本的な原因を見つけることができます。
(-)過去2回のバージョン12.0と12.1では、ソーラーウインドは素晴らしい機能拡張を行いました。現在、変更してほしいところはありません。ユーザー・インターフェースに多少の美観はありますが、問題だとは思っていません。

投資対効果

●定量的なデータは提供できませんが、実際にプラスの影響を与えた例をいくつか挙げることができます。
●インターネットバンキングのアプリケーションで、思うように動作しない点がいくつかありました。DPAを使用して、最も重いSQLクエリを特定し、ベンダーに変更依頼を開始しました。変更後、レスポンスタイムを1桁短縮することができました。

Database Performance Monitorのチューニング
私たちの組織では、テーブル・チューニング・アドバイザーを使って、ある MS SQL サーバーの統計情報を追加で作成しました。

ベストバリュー

環境のアップグレードの支援（該当する場合） – 私たちは、製品のバージョンからバージョンへのアップグレードを何度も行いました。一度だけ問題が発生しましたが、非常に迅速に修正されました。実は、その問題に対して私が推薦したのですが、彼らは最初に回避策を与えてくれました。全体的にとても満足しています。

使用例と導入範囲

アラートを利用して問題を未然に防いでいます。パフォーマンスデータを使って問題を診断し、解決しています。ダッシュボードとドリルダウンを使って、現在の状況を把握し、うまくいっているかどうかを確認します。全体的なレスポンスタイムの急上昇や急降下を監視し、ユーザが体験しているUXの原因を理解しようとしています。

長所と短所

(＋)この製品は、管理やパフォーマンスチューニングに必要なデータを、数秒で理解できるように可視化することに優れています。OracleのようなデータベースにはAWRレポートがあり、何ページもあり、すべてテキストで、読みにくいです。SQL Serverには動的な管理ビューがありますが、良いものですが簡単にアクセスできません。 Database Performance Analyzer (DPA)は、このようなレポートをすばやく理解し、実行できるようにレイアウトします。

(+)DPAは、実際に何が起こっているのかを教えてくれます。

例：開発者は、このストアドプロシージャはこのRDBMSでは非常に遅く実行されるが、別のRDBMSでは電光石火のように実行されると述べています。チューニングを試みたが効果がなかった。
そこで、DPAで数分かけて状況を調査したところ、ストアドプロシージャは正常に動作していることがわかりました。その代わり、アプリケーションがプロックに関するメタデータにアクセスしようとする際に、速度が低下していることがわかりました。その結果、メタデータをキャッシュするようになり、今では「遅い」プロックが快調に動作しています。DPAがなければ、微調整すべき正しいコードを探すのに長い時間がかかっていたでしょう。

(+)内蔵のアラート機能を使って、カスタムアラートを作成できるのは素晴らしいことです。カスタムアラートは、監視しているデータベースや、DPAが収集したデータから、OS、ストレージ、ネットワークなど、関連する部分まで情報を収集することができます。

(-)素晴らしい製品で、ほとんどのことがうまくいっています。必要な情報に少ないクリックでアクセスできるように、UIを改善し続けて欲しいと思います。

(-)DPAの競合他社が持っている機能で便利そうなのは、ジョブの実行時間をマッピングして、問題が発生したときに時間単位でマッピングできるようにすることです。

投資対効果

●問題発生時に対応するのではなく、問題を未然に防ぐことができるのは貴重なことです。顧客サービスのレベルも格段に上がりました。

●私が別の機会を求めて退職することを聞いた開発部の不機嫌な部長は、「今までいた最高のDBAをどうして手放すんだ」と上司を叱咤激励しました。 Database Performance Analyzerを使って提供できるサービスのレベルが、私が優れたDBAになるのに役立ちました。

Database Performance Analyzerの貴重な洞察

あるデータベースサーバーで、サードパーティの製品を使用していました。DPAのバーチャートは、1つのSQL文による多くの待ち時間を表していました。その文は実行に数ミリ秒しかかかりませんが、1日に数百万回実行されていました。どうしてその文がそんなに頻繁に実行されなければならないのか？私の上司の上司が、そのデータベースを作成している会社のオーナと知り合いで、私が見つけたものを送ってくれたのです。そして修正してもらったのです。

Database Performance Monitor のチューニング

[Table Tuning Advisors]は、全体的なガイダンスを与えてくれます。しかし、Query Advisorsは、しばしば特定の提案インデックスを持ち、それをコードウィンドウにコピー＆ペーストするだけで、多くのことができます。私はしばしば、実行する前にそれらを微調整し、一部は役立ちませんでしたが、全体として、それらはパフォーマンスにとって非常に有用でした。大きなテーブルで適切なインデックスを使用すると、パフォーマンスが文字通り何百倍も、時には3,000%も向上することがあるのです。

仮想化データベース

そのためには、問題があなたのVMにあるのか、それともホストにあるのかを理解する必要があります。サーバ管理者とオーバープロビジョニングについて議論する必要があるのか、それともデータベースサーバーのVM内でよりコントロールできる問題なのかを？

DPAの1週間あたりの時間節約額

一人当たり週0-4時間の時間節約 ：アラートがないと、反応モードで時間を浪費し、顧客のエクスペリエンスが損なわれます。分析と棒グラフがなければ、問題を診断して修正するために時間を浪費することになります。何度もクエリーを実行する必要がある場合、全体像を一目で把握することができず、時間を浪費してしまいます。

推薦する可能性

管理するインスタンスが何十台もある場合、ダッシュボードはとても便利です。履歴が残るので、昨日や週末に起こった問題を診断したり、毎日同じ時間に起こるのか、毎週同じ曜日に起こるのか、などのパターンを確認することができます。

従来のデータベース監視ツールは、データベースの健全性指標に着目して、パフォーマンス問題のトラブルシューティングを行います。DBA(DB管理者） は、これらの指標を改善するために何時間もかけてデータベースをチューニングしますが、その変更がパフォーマンスにほとんど影響を与えないことに気付くことがあります。

DPA(Database Performance Analyzer)は、データベースの健全性指標の代わりに、アプリケーションとエンドユーザーの待ち時間に注目します。DPAは、待ち時間が最も長い場所をグラフィカルに表示し、待ち時間が予想より長い時間帯（異常）も特定します。パフォーマンス問題の根本原因を掘り下げることができ、その修正方法に関するアドバイスを得ることができます。DPAを使用して、長い待ち時間の直接の原因となっている問題を発見し修正すれば、注目されるパフォーマンス改善を実現することができます。

DPAのホームページを使用して、待ち時間の長いデータベースインスタンスや異常なインスタンスを素早く特定し、ドリルダウンして詳細を確認することができます。

クエリのパフォーマンス問題の根本原因を調査するために、DPAはクエリに関する最も関連性の高いデータをインテリジェントに収集し、「クエリの詳細」ページに表示します。この情報を使用して、次のことを行います。

●パフォーマンスに影響を及ぼしている待機の種類を確認し、各待機の種類に関する詳細情報および推奨事項を表示します。
●クエリおよびテーブルのチューニングアドバイザーを確認する
●統計およびメトリックスチャートで、クエリ待ち時間と他のイベントとの関連性を調べることができます。

DPAは、主な待ちの種類やその他の情報をもとに、最も関連性の高い統計、ブロッキング、プラン、メトリクスチャートを自動的に選択します。これらのチャートを表示するためにスクロールダウンしても、「トップウェイト」チャートは表示されたままなので、同じ時間帯の他のイベントとクエリ待ち時間を関連付けることができます。この情報は、複雑なパフォーマンス問題の根本原因を特定するために必要なコンテキストを提供します。

非効率なクエリ、つまり、多くの行を読み取るが、返す行数は比較的少ないクエリのパフォーマンスを改善する方法を決定する際には、多くの要因を考慮する必要があります。DPAのテーブルチューニングアドバイザーは、十分な情報に基づいた意思決定を支援します。DPAは毎日、非効率的なクエリが実行されたテーブルを特定します。各テーブルについて、テーブル チューニング アドバイザー ページには、非効率的なクエリ、テーブル構造、および既存のインデックスに関する集約された情報が表示されます。こ の情報は、 次の よ う な質問に答 え る のに役立ち ます。

●クエリの計画をレビューする際に、どのステップに焦点を当てるべきか？
●このテーブルには現在いくつのインデックスが存在し、それらはどのようなものか？
●パフォーマンスを向上させるためにインデックスを追加することは可能か？
●統計は古くないか？
●テーブルのチャーン（挿入、更新、削除）はどの程度行われているか？

DPAでは、異常検知アルゴリズムを用いて、予期せぬ待ち時間の増加を検知しています。ある期間では、待ち時間が多くても正常である場合があります。DPAは、過去のデータを使って正常な状態を「学習」し、そのデータに基づいて予測を行います。ある時間帯の待ち時間が予想より大幅に長い場合、DPAは異常を報告します。

PostgreSQLデータベースインスタンスは、Linux、Windows Server、VMware仮想マシン、クラウドプラットフォームのどこで実行しても、Database Performance Analyzer（DPA）でカバーすることができます。

PostgreSQLプラットフォームの広範なサポートは以下のとおりです。

• PostgreSQL
• EDB Postgres
• Azure Database for PostgreSQL
• Amazon RDS for PostgreSQL
• Amazon Aurora for PostgreSQL
• Google Cloud SQL for PostgreSQL

DPAのPostgreSQLデータベース管理へのハイブリッドアプローチは、エージェントレスアーキテクチャと1%未満のオーバーヘッドで、データベースパフォーマンスのチューニングと最適化への一面的なビューを提供します。

DPAは、24時間365日、秒単位のデータ収集により、ディスク、メモリ、ネットワークなどの主要なシステムメトリクスを含むPostgreSQL環境の広範なメトリクスを測定します。さらに、PostgreSQL固有の主要なメトリクスを簡単に利用できます。

キャッシュエビション
チェックポイント
レプリケーション
バキューム
行の操作
ライセンスコンプライアンス

これらの指標と、リアルタイムおよび履歴ビューを組み合わせることで、DBAはPostgreSQLのチューニング指標に簡単にアクセスすることができます。

DPAの異常検知は、時間の経過とともに賢くなる機械学習をベースに、季節性を利用して何が正常で何が正常でないかを判断しています。この強力な機能により、DBAは意識していなかったものも含め、パフォーマンスの問題を通常数秒で発見することができます。

機械学習と高度な待ち時間解析の組み合わせにより、クエリが影響を受けている理由と場所を示し、従来の監視ソリューションでは実現できなかったPostgreSQLの最適化の可視性を提供します。

DPAは、パフォーマンス低下の原因を指摘するクエリアドバイザによる専門的なアドバイスによって、PostgreSQLのチューニングをさらに一歩推し進めます。

クラウドコンピューティングプラットフォーム上でPostgreSQLを実行する場合、パフォーマンスの最適化とチューニングが重要です。なぜなら、計算リソースの対価として、非効率的で不適切なクエリは、フロントエンドアプリケーションのパフォーマンスへの影響は言うまでもなく、コストにつながる可能性があるからです。

DPAは、PostgreSQLのパフォーマンス管理に対して、以下のような全体的なアプローチを提供します。

●リアルタイムおよびヒストリカルビュー
●24時間365日、秒単位のデータ収集が可能
●シンプルでエージェントレスな実装により、オーバーヘッドを1%未満に抑えることができます。
●ポストグレスに特化したレポート（アドホックまたはスケジュール型）
●機械学習による異常検知
●多角的なクエリ待ち時間分析
●問題箇所をピンポイントで特定するクエリアドバイザ
●システムおよびPostgreSQLの両方のメトリクス
●SQLテキストへのドリルダウンとライブプランの実行
●ドラッグ＆ドロップでカスタマイズできるメールアラートテンプレート
●自動化統合のためのRESTful API
●DPAは、物理サーバーやVM、Azure、AWSのサービスとして実装することが可能

DBAは、PostgreSQLのパフォーマンスチューニングと分析に関して、しばしば指南役となります。誰かがアプリケーションのパフォーマンス低下について不満を漏らすと、データベースのバックエンドが最初に非難されることがよくあります。

しかし、PostgreSQLインスタンスがVMware仮想マシンで動作している場合はどうでしょうか。多くの場合、DBAはPostgreSQLインスタンスをサポートする仮想インフ ラの影響（もしあれば）を全く見ることができません。DPA VMオプションによる統合仮想化監視は、VMがPostgresの性能問題を引き起こしているかどうかを判断するために必要なデータをDBAに提供します。VMのメトリクスとデータベースのメトリクスを重ねた独自の「タイムスライス」ビューから、詳細なESXiホストのメトリクスまで、DBAはPostgreSQLインスタンスへの影響を判断するのに必要なデータを手に入れることができます。

Database Performance Analyzer

DBAは、複数のデータベースプラットフォームでより多くのデータベースインスタンスを管理する必要に迫られています。Database Performance Analyzer（DPA）を使用すれば、機械学習による異常検知や履歴およびリアルタイム分析などの機能により、数分でパフォーマンス問題をピンポイントで特定できる、データベースパフォーマンス管理への一貫したアプローチを手に入れることができます。

DPAの主な機能は以下のとおりです。

●専門家によるクエリーのアドバイス、ブロッキング、リソース利用による多次元クエリー分析
●カスタムアラート、メトリクス、レポーティング
●VMwareの監視と分析を統合
●シンプルでエージェントレスなインストールにより、オーバーヘッドを1%未満に抑えることが可能
●オンプレミス、Azure、Amazon（RDSおよびAurora）インスタンスを含む幅広いデータベースプラットフォームが対象

Database Performance Monitor

アプリケーションを所有する開発者、データベースのリアルタイムおよび過去の統計情報を必要とするSREやDBAは、すべて Database Performance Monitor(DPM)の恩恵を受けることができます。直感的なインターフェイスは、コードの展開とデータベースのパフォーマンス監視を行う部門横断的なチームの作業をサポートします。

DPMの主な機能は次のとおりです。

●パフォーマンスの前後を測定するための時間比較
●カスタムアラートとダッシュボード
●システムとデータベースの両方のメトリックスにより、全体的な健全性を洞察
●部門横断的なチーム向けに拡張性のあるSaaSプラットフォーム
●MySQL、MongoDB、Redis、Auroraなど、幅広いオープンソースデータベースプラットフォームをカバー

データベーススキーマとは、リレーショナルデータベース全体の論理的、視覚的な構成のことである。データベースのオブジェクトは、テーブル、関数、リレーションとしてグループ化され表示されることが多い。スキーマは、データベース内のデータの構成と格納を記述し、さまざまなテーブル間の関係を定義します。データベーススキーマは、スキーマ図を通して描くことができるデータベースの記述的な詳細を含んでいます。

データベース設計者は、プログラマーが効率的にデータベースを操作できるように、データベーススキーマを作成します。データベースを作成するプロセスは、データモデリングとして知られています。データベーススキーマを設計するためには、情報を収集し、それらをテーブル、行、列に並べる必要があります。情報を整理することで、理解しやすく、関連付けやすく、使いやすくする必要があります。

データベーススキーマ設計は、データベースのアーキテクチャを開発するための設計図を提供することで、膨大な情報を体系的に格納することができる。また、データベースの構築に関わる戦略やベストプラクティスを指します。データベーススキーマ設計は、データを個別のエンティティに整理し、整理されたエンティティ間の関係を決定することによって、データの消費、解釈、取得をはるかに容易にします。

データベーススキーマの設計は、データの書式が一貫していること、すべての項目が主キーを持つこと、重要なデータが除外されていないことを保証します。データベーススキーマは、視覚的なものと論理的なものがあり、データベースを管理するための公式のセットを含んでいます。開発者は、これらの公式とデータ定義を使用して、データベーススキーマを作成します。

最も一般的なデータベーススキーマの種類を以下に概説します。

階層的モデル: 階層型：ルートノードに子ノードが付随するツリー状の構造を持つデータベーススキーマを階層型という。このデータベーススキーマモデルは、家系図などのネストされたデータを格納することができる。

フラットモデル:フラットモデル: データを単次元または二次元の配列に整理したもので、行と列を持つスプレッドシートのようなモデル。このモデルは、複雑な関係を持たない単純なデータを表形式で整理するのに適している。

リレーショナルモデル:リレーショナルモデルは、データが表、行、列に整理されるフラットモデルに似ている。ただし、このモデルでは、異なるエンティティ間の関係を定義することができる。

スタースキーマ: スターデータベーススキーマは、データを「ディメンション」と「ファクト」に整理します。ディメンジョンには説明的なデータが含まれ、ファクトには数値が含まれる。

スノーフレークスキーマ: スノーフレーク(雪片)型データベーススキーマは、データベース内のデータを論理的に表現したものである。このタイプのスキーマの表現はスノーフレークに似ており、複数のディメンジョンが1つの集中ファクトテーブルにくっ付いている。

ネットワークモデル: ネットワークデータベーススキーマは、データを接続された複数のノードとして含みます。このモデルは、多対多の関係などの複雑な接続を可能にするため、特定のタスクを達成するために使用されます。

データベーススキーマを最大限に活用するためのベストプラクティスを以下に紹介します。

セキュリティ: 効果的なデータベーススキーマの設計は、データセキュリティに重点を置く必要があります。また、ログイン情報、個人を特定できる情報（PII）、パスワードなどの機密データを保護するために、高度な暗号化を使用します。
名前の規則: スキーマ設計をより効果的にするために、データベースで適切な命名規則を定義することができます。テーブル、カラム、フィールド名には、複雑な名前、特殊文字、予約語を使用しないようにします。
正規化: 正規化とは、独立したエンティティやリレーションシップが、同じテーブルやカラムにまとめられないようにすることで、冗長性を排除するものです。これにより、データの整合性が向上し、開発者が情報を取得しやすくなります。また、正規化により、データベースのパフォーマンスを最適化することもできます。
ドキュメンテーション: データベーススキーマは、開発者とドキュメンテーションの作成にとって非常に重要です。データベーススキーマの設計は、説明書、コメント、スクリプトなどとともに文書化する必要があります。

物理データベーススキーマ: 物理データベーススキーマは、データの物理的な配置と、ファイル、インデックス、キーと値のペアなどのストレージのブロックへの格納方法を表します。

論理データベーススキーマ:論理データベーススキーマはデータの論理的な表現を記述し、論理的な制約を伝達する。データはある種のデータレコードとして記述することができ、異なるデータ構造として格納される。ただし、データの実装などの内部的な詳細はこのレベルでは隠されている。

データベーススキーマは、情報を体系的に整理するために設計された認知的な枠組みや概念です。スキーマがあれば、膨大な量の情報を素早く解釈することができる。未整理のデータベースは混乱しやすく、維持・管理も困難です。きれいで、効率的で、一貫性のあるデータベーススキーマの設計により、組織のデータを最大限に活用することができます。リレーショナルデータベースは、データの冗長性を排除し、データの不整合を防ぎ、データの検索と分析を容易にし、データの整合性を確保し、不正なアクセスからデータを保護するために、データベーススキーマ設計に大きく依存します。強力なテスト環境でデータをテーブルとカラムに整理することが極めて重要です。データの整合性を管理し、データベースとソースコードを更新する計画が必要です。

PostgreSQLは、新世代のエンタープライズアプリケーションのためのデータベースです。あなたのデータベースのパフォーマンス監視とチューニングのツールもエンタープライズクラスですか？

クライムとSolarWindsは、Confioからの10年以上に渡ってOracleとSQL Serverのユーザにソリューションを提供してきたため、データベースのパフォーマンス管理について多くのノウハウを持っています。ユーザの声に耳を傾けてユーザから学んでいます。そのため、現在ではオープンソースのデータベースを数多くサポートし、その数は増え続けています。

私たちは、性能監視、PostgreSQLクエリチューニング、I/Oチューニングなどに対応する2つのソリューションで、私たちの専門知識をPostgreSQLに提供します。

どちらもユーザをエンタープライズクラスとして大きく手助けします。

Database Performance Analyzer (DPA)は、Oracle、SQL Server、MySQL、その他を含む広範なデータベースプラットフォームをサポートします。PostgreSQLの深いクエリチューニングと分析に機械学習を組み合わせてエンドツーエンドのITパフォーマンス管理を実現します。

Database Performance Monitor (DPM)はPostgreSQL監視ソリューションで、開発者、SRE、DBAのいずれにも有用なSaaSベースのインターフェイスを提供します。DPMは、MySQL、MongoDB、Redisなどの主要なオープンソースデータベースのシステムおよびデータベースの監視と分析の両方を提供します。

●Query advisors [クエリアドバイザ]は、待ち時間の原因となっている待ちの種類、ステートメントが他のセッションによってブロックされていないか、実行プランにフルテーブルスキャンなどのコストのかかるステップが含まれていないかなど、特定のクエリのパフォーマンスを改善するのに役立つ情報を提供します。

●Table tuning advisors [テーブルチューニングアドバイザー]は、あるテーブルに対して非効率的なクエリが大量に実行された場合に生成されます。これらのアドバイザーは、テーブル、実行された非効率的なクエリ、および既存のインデックスに関する集約された情報を提供します。

DPA ホームページの [チューニング] 列には、データベース インスタンスで警告またはクリティカル ステータスのアドバイザが利用可能な場合、警告またはクリティカル アイコンが表示されます。この列の緑のチェックマークは、アドバイザーが存在しないか、すべてのアドバイザーが情報提供であることを示します。

データベースインスタンスのすべてのアドバイザーを表示する

データベースインスタンスのすべてのアドバイザーを表示するには、次のいずれかの操作を行い、[Tuning Advisors] ページを開きます。

●DPA ホームページから、[Tuning] 列のアイコンをクリックします。
●データベース インスタンスの情報を表示するためにドリルインした場合は、インスタンスの詳細ページの右上隅にある［Tuning］タブをクリックします。

Tuningタブの赤または黄色のバーは、CriticalまたはWarningアドバイザーが利用可能であることを示します。

Tuning Advisors ページには、最新のクエリおよびテーブル・チューニング・アドバイザーが表示されます。ページの上部にあるドロップダウン・メニューを使用して、以前の日付に生成されたアドバイザーを表示します。

DPA の [Resources] タブでリソース メトリクスを表示しているとき、ベースラインを表示して、特定の期間の値を過去の基準値と比較することができます。ベースラインは、現在の値に対するコンテキストを提供します。ベースラインを大幅に上回ったり下回ったりするメトリック値は、チューニングや再設定が必要な領域を示している可能性があります。

ベースラインを計算する前に、少なくとも1日間モニタリングが有効でなければなりません。ベースラインは、モニタリングの日数が増えるほど、より代表的なものになります。

（注）ベースラインは、VMオプションで収集されたメトリクスでは利用できません。

ベースラインの表示/非表示

ベースラインは、選択した期間が1週間以下の場合に利用できます。デフォルトでは、ベースラインは表示されません。[Resource］タブの右上にある［Baselines］トグルスイッチをクリックすると、ベースラインの表示/非表示が切り替わります。

ベースラインを表示する場合（かつ期間が1週間以内の場合）、10%から90%の間の履歴値を網掛けで表示します。

ベースラインはどのように計算されるのですか？

ベースラインは、1時間ごとに計算されます。デフォルトでは、ベースラインは平日（月～金）のデータのみを使用して計算されます。各ベースラインは、平日すべての対応する時間のデータを使用して計算されるため、特定の時間の値はすべての日にわたって同じになります。(例えば、午後1時から2時までは月曜日から金曜日まで同じ値です）。

ベースラインは、チャートに表示されている最も古い時間以前の履歴データを使用して計算されます。例えば、5月10日から始まる1週間のチャートの場合、すべてのベースラインは5月9日以前のデータを使って計算されます。このため、1週間チャートは日毎にパターンが繰り返されます。

ベースライン計算に含まれる日数を変更する

ベースライン計算に含まれる日数を変更するには、詳細オプションの 「METRICS_BASELINE_TYPICAL_HOUR_CALCULATION」 を編集します。このオプションは、グローバルまたは特定の監視対象データベースインスタンスに対して設定することができます。

以下の値のいずれかを選択してください。

●Weekday Only (M-F)：平日（月～金）の対応する時間のデータを用いて、1時間ごとにベースラインを計算します。これはデフォルトです。
●All Days of the Week：ベースラインは、すべての日の対応する時間のデータを使用して、各1時間の期間について計算されます。
●Same Day of Week：各1時間の期間について、該当する日の該当する時間のデータを使用して計算されます。(例えば、月曜日の午後1-2時の値は、月曜日の対応する時間のデータを使用しており、したがって金曜日の午後1-2時の値とは異なります)。このオプションを選択すると、メトリックごとのベースラインの数が24から168に増えることに注意してください。

SSDドライブを買うべきか、より大きなサーバーを買うべきか？

Database Performance Analyzer（DPA）は、アプリケーションがディスクの読み書き、ネットワークの待ち時間、CPUの待ち時間、サスペンド状態や処理の妨げとなるアクティビティの待ち時間を正確に把握できるため、推測する必要がありません。これにより、アプリケーションのパフォーマンスを向上させるために投資する必要がある箇所や、新しいハードウェアが必要ない場合、コードやデータベース/システム構成の修正または改善によってボトルネックを解消できる箇所を把握することができます。

使用例と導入範囲

データベースチームが、SQL ServerとAzure Databasesの両方で、データベースのパフォーマンスを監視し、チューニングするために使用しています。データベースの遅さ、Webサイトやサービス、アプリケーションでのタイムアウトは、データレイヤーが原因であることが多く、そのトラブルシューティングに最適なツールです。

長所と短所

(+)どのストアドプロシージャーのどのステートメントに作業が必要か、または致命的であるかを教えてくれる（該当する場合）。
(+)本当に作業が必要なものに注意を集中させることができ、非常に効率的です。
(-)監視するサーバーが多い場合、UIが不便になる。
(-)複数のサーバーにまたがる問題の順位付けができない。

投資に対するリターン

現在の勤務先ではなく、以前の勤務先での話です。データベースの変更を含む、大量のコードをデプロイしたことがありました。その翌日、そのデータベースサーバーに依存していたすべてのものがダウンし、サーバーはCPU、RAM、I/Oが100%になるまで叩かれました。何が問題なのかを正確に特定するのは非常に困難でしたが、Database Performance Analyzerを立ち上げて正確な問題を見つけるのにわずか数秒、そして問題のあった正確なprocにパッチを当てるのに1分もかかりませんでした。会社全体がビジネスに不可欠なサイトやツールからロックアウトされ、トレースやDMVなどの手段で問題を分析するのに何時間もかかったかもしれません。その代わり、ほとんど時間がかからなかった。

データベースの異常を検出することも重要ですが、24時間365日ダッシュボードを見続ける人はいないため、Database Performance Analyzer(DPA)は動作の変化を検出した際にアラートを送信することが可能です。感度を快適なレベルにカスタマイズしてノイズを減らし、DPAに監視を任せてください。

DPAはデータベースを常時監視し、動作の変化が検出されるとアラートを送信します。この異常検知ツールは、ワークロードのシフト、メンテナンスジョブの営業時間内実行、その他調査したい予期せぬ変化が発生したときに知らせることができます。

データベースの異常検知ツールは、そこに入力されるデータによってのみ、その性能が発揮されます。Database Performance Analyzer(DPA)は、24時間365日、異常ベースの監視を行い、機械学習アルゴリズムにより最新の洞察を提供します。30日以上監視が停止した場合、DPAのアルゴリズムは古いデータに基づいて予測を行うことはありません。代わりに、DPAは新しいデータから学習を開始し、3日後に最新のデータに基づいて再び予測を開始します。この機能により、異常検知の取り組みが最新の関連データのみによって裏付けられていることを確認することができます。

環境の大規模化・複雑化に伴い、データベース管理者は、様々な種類のデータベースを監視できる異常検知ツールを必要としています。Database Performance Analyzer（DPA)は、WindowsおよびLinuxサーバー上の仮想化、物理、クラウドベースのデータベースインスタンス、Azure、またはAWSサブスクリプションとして、1回のインストールで使用できる異常ベースのデータベース監視ツールを提供します。DPAの異常検知ツールは、Oracle、MySQL、Azure SQL Database、Microsoft SQL Serverなどをサポートするよう構築されています。また、DPAはVMオプションでVMware ESXiの可視化機能を統合しています。

データベースのパフォーマンスモニター・分析ツール「Database Performance Analyzer(DPA)」についてよくある質問の一覧です。

本サイトはこちらです。

データベース・パフォーマンスチューニングは、データベース管理者がデータベースを可能な限り効率的に実行する方法を指す広義用語です。DBMSチューニングは、通常、MySQLやOracleなどの一般的なデータベース管理システムのクエリをチューニングすることを指します。

データベースのチューニングは、全体的なパフォーマンスを向上させるために、データベースシステムを上から下まで、ソフトウェアからハードウェアまで、再最適化することを支援します。このチューニングには、最適な使用方法に応じたオペレーティングシステムの再構成、クラスタの展開、システム機能とエンドユーザー体験をサポートする最適なデータベース性能への取り組みが含まれます。

SQLパフォーマンス・チューニングは、データベース・パフォーマンス・チューニングと似ていますが、より狭い範囲に限定されます。SQLパフォーマンス・チューニングは、リレーショナル・データベースが可能な限り効率的に動作するように設計されたベストプラクティスや手順のことを指します。これには主に、SQLクエリーとインデックスのチューニング、管理、および最適化が含まれます。

定期的な SQL パフォーマンス・チューニングは、SQL パフォーマンス問題の一般的な原因である非効率的なインデックスと SQL クエリに取り組む費用対効果の高い方法であり、リソースを再割り当てしてシステムを自助努力で使用することによって実現できます

ここでは、データベース全体のパフォーマンスを向上させるために役立つヒントをいくつか紹介します。

●インデックスが論理的なデータ構造を実装していることを確認し、データ検索プロセスをより効率的にする。
●コンピューティングシステムのメモリーの予備を再割り当てする。十分なメモリがない場合、データベースはしばしば最も大きな打撃を受けます。
●MySQLやOracleの最新版を使用していますか？　データベースを最新に保つだけで、データベースのパフォーマンスが向上することがあります。
●ループのコーディングや相関性のあるSQLサブクエリのような一般的なSQLインデックスの落とし穴を避ける。
●データをデフラグすることで、データベースのスピードアップにつながるかもしれません。十分なディスク容量があることを確認する。
●効果的なデータベースチューニングとパフォーマンス監視は、洞察とピンポイントでのパフォーマンス最適化の推奨事項を提供するのに役立ちます。

データベースのパフォーマンスチューニングのベストプラクティスに関して、ここでは簡単なチュートリアルを紹介します。

1)過去のデータを使って「正常」であることを確認し、データベースのベースラインに関する情報を収集します。ベースラインの指標を収集することで、データベースに何か異常があるかどうかを簡単に（そしてはるかに速く）確認することができます。

2)実行プランに目を通す。MySQL では、データベース管理者がクエリおよびデータベースのパフォーマンスを調査するためのさまざまな方法を提供しています。実行プランに目を通し、可能な限り効率的であることを確認します。

3)すべてのテーブル、インデックス、クエリに非効率性がないかを確認します。待ち時間の増加やインデックスのカラムアライメントを確認します。

4)ボトルネックを特定し、解消する。問題のあるSQLクエリとその原因を特定し、ボトルネックを解決する。

5)効果的な監視を実施する。非効率的なクエリは、データベースのパフォーマンス問題の主な原因であるため、データベースのチューニングの大部分はクエリパフォーマンスの監視に費やされます。たとえば、SolarWinds Database Performance Analyzerは待機ベースの分析機能を備えています。これは、時間関連の問題がデータベースパフォーマンスチューニングの最も顕著な問題点の1つであるためです。この方法は、データベースパフォーマンスチューニングの問題をより正確に切り分け、特定し、調査するのに役立ちます。

データベースクエリーの数ミリ秒の遅れは、あっという間に大きなボトルネックとなり、修正するのに長い時間がかかることがあります。データベースのチューニングが重要なのは、クエリの応答時間を数秒単位で短縮できるため、必要な情報を必要な場所にすばやく届けることができるからです。定期的なチューニングは、データベースパフォーマンスのベストプラクティスの重要な部分であり、アプリケーションのパフォーマンスを加速させる手っ取り早い方法となります。

データベースチューニングツールは、通常データベースチューニングに時間がかかる手動プロセスの多くを自動化することによって、チューニングプロセスを容易にするように設計されています。

また、データベース・チューニング・ソフトウェアは、問題のある箇所を正確に把握できるため、クエリーやアプリケーションの中を探し回る必要がなく、効果的なトラブルシューティングの手段にもなります。見えない問題を解決することはできません。これらのツールは、データベースがどのように動作しているかを概観することができます

Database Performance Analyzer (DPA)は、ユーザーがデータベースパフォーマンスの問題を監視、発見、解決できるように構築された、俊敏でスケーラブルなデータベースチューニングツールです。

DPAは、データベースアクティビティ、待機時間、SQLステートメント、アプリケーションリクエスト、およびその他のディメンションを相関させ、データベース速度低下の原因を正確に突き止めることができるように設計されています。 DPAでは、IBM DB2、SQL Server、SAP Adaptive Server Enterprise（SAP ASE）などの主要な商用データベースについて、SQLステートメントの迅速な分析、パフォーマンス問題の根本原因の特定、専門家のチューニングアドバイスを受けることも可能です。

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インフラストラクチャを効率的に管理するための最高のツールと統合を提供するという、当社の継続的な取り組みの一環です。

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 を活用するインスタンスの全体像が完成しました。

• ホームページで、右上の「アラート」をクリック
• アラートの管理」をクリック

• アラートカテゴリとして「カスタム」を選択し、アラートタイプを選択してから、「アラートを作成」をクリックします。

• アラート情報セクションでは：

– 一意の名前を入力します

– アラートを無効にするには、[有効] チェックボックスをオフにします

– 実行間隔を選択します。（DPAでは、実行間隔を少なくとも10分以上にすることを推奨します。）

– メール通知と共に送信する通知テキストを入力します。問題の説明と推奨される解決策を含めてください。

– アラートが適用されるデータベースインスタンスを指定します。これにより、SQLクエリまたはストアドプロシージャが（DPAリポジトリではなく）対象インスタンス上で実行されます。1つ以上の条件を満たすインスタンスは、手動で選択するか、ルールを使用して検索できます。

• ルールを選択すると、DPAはルール条件に基づいてアラートが監視するインスタンスを決定します。環境が変更されるたびに、インスタンスのリストは自動的に更新されます。

– [ルールを使用]をクリック

– [ルール]ページには既存のルールが一覧表示されます

– 既存のルールを選択するか、新規ルールを作成して選択します。

– [ルールの割り当てをクリア]

– アラート定義には、選択したルール名、ルール式、および現在ルール条件を満たしているインスタンスの一覧が表示されます。

• データベースインスタンスを手動で選択する場合、リストは静的です

– [データベースインスタンスの選択] をクリックします。

– 利用可能なデータベースインスタンスページにはデータベースインスタンスが一覧表示されます。アラートタイプが特定のデータベースタイプに限定されている場合、該当タイプのインスタンスのみが表示されます。

– 検索バーを使用してインスタンスを検索するか、フィルターを適用してリストを絞り込みます

– リスト内の全インスタンスを選択するには、リスト上部のチェックボックスを選択します。個々のインスタンスを選択するには、各インスタンスの横にあるチェックボックスを選択します。

– [割り当て]をクリックして戻る

– アラート定義画面に選択したインスタンスの一覧が表示されます。

• アラートパラメータセクション

– 実行するSQL文を入力するか、ストアドプロシージャの呼び出しを入力します。カスタムタグを使用して、データベースIDなどの変数や、ストアドプロシージャに必要な出力パラメータを含めることができます。

– [実行対象]ドロップダウンで、SQL文またはストアドプロシージャを、選択したデータベースインスタンスに対して実行するか、DPAリポジトリデータベースに対して実行するかを指定します。

– [説明]フィールドが利用可能な場合、アラート用のカスタム説明を入力できます。この説明は、メールテンプレートに[説明]パラメータが含まれている場合、アラートタイプのDPAデフォルト説明に置き換わります。

– アラートが数値を返す場合、返される値の単位を指定します。

• アラートが数値を返す場合、有効にする各アラートレベルのしきい値を指定します。

– 最高レベルの最大値は空白のままにすると、そのレベルの最小値を超えるすべての値に対してアラートが通知されます。

– 複数のレベルを設定する場合、下位レベルの最大値は必ず等しい上位レベルの最小値に設定してください。

– レベルの最大値を入力すると、値が最小値を上回るか等しいが、最大値を下回る場合に、DPAはそのレベルでアラートを通知します。例えば、最小値が5で最大値が10の場合、値が5以上10未満のときにDPAはそのレベルでアラートを通知します。

• 各アラートレベルがトリガーされたとき、およびアラートが解除されたときに通知を受け取る個人またはグループを選択します（アラートステータスは、実行中にエラーが発生した場合に「解除」に設定されます）。アラートが「正常」に戻ったときに通知を送信するには、「正常」の受信者を選択します。アラートが「正常」に戻ったときに通知を送信するには、通知ポリシーが「レベル変更時に通知」である必要があります。
• このアラートによって送信されるメール通知の内容を定義するメールテンプレートを選択します。
• [メールプレビュー]をクリックすると、選択したメールテンプレートと連絡先情報を使用して生成されるメールの例を確認できます。

– アラートが複数のデータベースインスタンスに適用される場合、[メールプレビュー]ダイアログボックスでインスタンスを選択し、[OK]をクリックします。メールを確認後、別のデータベースインスタンスを選択するか、[キャンセル]をクリックして[メールプレビュー]ダイアログボックスを閉じることができます。プレビュー中に評価できないアラートパラメータがあるため、ユーザーに送信されるメールはプレビューと完全に一致しない場合があります。

• アラートをテストし、現在のアラートレベルを確認するには、[アラートテスト] をクリックします。テストではメールは生成されません。
• [保存] をクリックします。

追加リソース: カスタムアラートのドキュメント

• パフォーマンスが低下しているサーバーに移動する
• ページの左上にある「日付と時間」でフィルタリングする

・

• 下にスクロールして「アクティブなセッションを表示」をクリックしてください。

• ロックまたはブロックタブをクリック
• アクションのドロップダウンメニューをクリックし、「KILL」を選択

 アイドルブロッキングは、セッションがトランザクションを開いた（リソースにロックを設定した）後、明示的にコミットまたはロールバックを行わなかった場合に発生します。トランザクションは、現在作業が行われていないにもかかわらず、開いたままになります。アイドルブロッカーが存在するかどうかを確認するには、次の手順を実行します。

• パフォーマンスが低下しているサーバーに移動します
• 日付でフィルタリングします

• ページの一番下までスクロールしてください

• 調査するには、バーまたは軸ラベルをクリックしてください。

リソースメトリックは、データベースの健全性を監視し、リソース競合とデータベース待機時間の増加を関連付けるために使用されます。リソースメトリックのグラフは、メトリックが警告または重大なしきい値を超えたことを示します。事前設定されたしきい値は、環境の要件に合わせて変更できます。メトリックに既定のしきい値が設定されていない場合、デフォルトのしきい値を追加できます。監視対象のインスタンスはすべて定義されたしきい値以下である必要があり、特定のデータベースインスタンスのみを対象とすることも可能です。カスタムしきい値は「デフォルトとして保存」をクリックすることで、すべてのインスタンスのデフォルトとして保存できます

• 現在のしきい値を表示するには、確認したいリソースメトリックのしきい値を持つデータベースインスタンスをクリックします
• リソースをクリック

• 新しいしきい値を入力してください：

– メトリックにデフォルトのしきい値がない場合、有効にしたい各しきい値レベルの横にあるトグルスイッチをクリックします。

– 警告レベルと重大レベルの双方を有効にする場合、両レベルの交点に同じ値を入力します：

• より高い値でアラートが発生するメトリックについては、警告の最大値と重大の最小値と同じ数値を入力します。

– DPAは値が警告範囲内（範囲を含む）の場合に警告アラートを発行します。DPAは値が最小重大閾値を超えた場合に重大アラートを発行します。

– 例：ステップ1で示したしきい値の場合、値が10から20の間にあればDPAは警告アラートを発行します。値が20を超えると、DPAは重大アラートを発行します。

• 低い値でアラートが発生するメトリクスの場合、警告の最小値と重大の最大値に同じ数値を入力します。

– DPAは、値が警告範囲（範囲内を含む）にある場合に警告アラートを発行します。DPAは、値が最小重大しきい値未満の場合に重大アラートを発行します。

– 例：下記のしきい値の場合、DPAは値が90から95の間に警告アラートを発行します。DPAは値が90未満の場合に重大アラートを発行します。

• 次のいずれかを実行します

– このデータベースインスタンスのみに新しい値を適用するには、[保存]をクリックします。

– すべてのデータベースインスタンスに新しい値を適用するには、[デフォルトとして保存]をクリックします。

• [デフォルトとして保存]を選択した場合、インスタンスごとにカスタムしきい値が指定されていない限り、新しいデフォルトしきい値がすべてのデータベースインスタンスに適用されます。カスタムしきい値が設定されているデータベースインスタンスは、引き続きそれらのしきい値を使用します。

追加リソース: カスタムリソースしきい値

DPAに初めてサインインした際に概要動画を見逃した場合、トレンドページの右上に「詳細を見る」タブが配置されています。

 SQL検索 機能は、SQL文に関する既知の情報に基づいて任意のSQL文を検索するために使用されます。時間範囲を指定し、任意のフィルタと検索文字列の組み合わせを適用できます。

• DPAホームページから、検索対象のデータベースインスタンス名をクリックします。
• ページ上部で「SQL検索」をクリックします（選択したデータベースインスタンスでこの機能が有効化されていない場合、ページにメッセージが表示されます）。Find SQL機能を有効化するには、全データベースインスタンスまたは特定のインスタンスに対して設定します。
• ページ上部で事前定義期間を選択するか特定の日付を入力（デフォルトは24時間）し、[検索]をクリック
• フィルターの適用には、選択したデータベースインスタンスに応じて、以下のフィルターカテゴリの一部または全てが利用可能です：

– データベースユーザー: SQL文を実行したユーザーID。

– プログラム: SQL文を実行したアプリケーション。

– データベース: SQL文がクエリを実行したデータベース。

– マシン: SQL文が実行されたコンピュータ。

• 左上隅の「フィルター」をクリック
• 値を検索するには、フィルター検索フィールドに検索文字列を入力します。検索文字列を含む値のみが表示されます

・フィルターカテゴリに10件以上のアイテムが含まれる場合は、「すべて表示」リンクをクリックしてください。

・ダイアログが開いたら、ページをめくってすべての項目を表示したり、並べ替え順を変更したり、検索したりできます。

• 1つ以上のフィルターを選択し、[検索]をクリックして適用します。
• 検索結果には、すべてのフィルターに一致するSQL文のみが含まれます。フィルターに検索語句が適用されていない場合、結果は待機時間順に並べ替えられます。
• 適用されたフィルターは、[フィルター]ボタンと[検索]バーの上に一覧表示されます。

注:

• SQLテキストが不明な場合、特定のユーザーによって実行されたSQL文、特定のアプリケーションの一部として実行されたSQL文、特定のコンピューターから実行されたSQL文、または特定のデータベースに対して実行されたSQL文を特定するためにフィルターを適用できます。
• SQLテキストについて何か知っている場合は、テーブル名や実行されている操作などの検索文字列を入力できます。

追加リソース: SQLドキュメントの検索

レポートグループは、関連するレポートのデータを同一ページに表示するために使用されます。レポートグループを使用すると、複数のレポートを簡単に実行またはスケジュールできます。

• 該当するサーバーをクリック
• ページの右上にある「レポート」をクリック
• 「レポートグループの作成」をクリック
• グループ名と説明を入力（説明は任意ですが、入力することを推奨します）

• グループに含めるレポートを選択し、「追加」をクリック

• OKをクリック

追加リソース: レポートグループの作成

この機能は、個別のDPAサーバーを相互に連携させるために使用されます。中央サーバーはリモートサーバーから情報を収集し、データを単一のインターフェースに統合します。各DPAサーバーは独自のリポジトリを持ちます。中央サーバーのオーバーヘッドは低く、他のDPAインストール環境からの追加情報はリポジトリデータベースに追加されません。DPA Centralの導入を検討すべき状況は以下の通りです:

• DPAを支えるインフラリソース（例：ストレージ可用性、I/Oスループット、RAM、CPU）が、分析対象クエリ量の増加に伴い容量限界に達する場合。
• 監視対象インスタンスが地理的に分散しており、遠隔インスタンスへのネットワーク遅延時間が大きい場合。各拠点に個別のDPAサーバーを設置できます。
• 別々のチームや事業部門が、担当するデータベースインスタンスのサブセットを管理できるようにしたい場合

注記: SolarWindsでは、データベースインスタンスの監視にも使用するサーバーにDPA Centralを設定することを推奨します。DPA Central専用の別サーバーを用意する必要はありません。

• 中央サーバーの設定

– サーバーにDPAをインストールします。これが中央サーバーとなります。

– そのインスタンスに管理者としてログインします。

– 右上のDPAメニューから[オプション]をクリックします。

– [管理] > [表示] で [セントラル管理] をクリックします。

– 登録済みサーバーの一覧に、DPA サーバーが「セントラル DPA サーバー」として表示されていることを確認します

• リモート DPA サーバーの追加

– 右上隅の DPA メニューから [オプション] をクリックします。

– [管理] > [表示] で [セントラル管理] をクリックします。

– [サーバーの追加] をクリックします。

– リモート DPA サーバーに関する情報を入力します。

– [接続テスト] をクリックし、[保存] をクリックします。

1. テストが成功した場合、DPA がプロバイダーのホストとポートを介してリモートサーバーと通信できることを示します。DPA がユーザーを認証できることを示すものではありません。
2. テストが失敗した場合は、[サーバー名] フィールドのホスト名を確認してください。アンダースコア (_) 文字が含まれていませんか？アンダースコアはホスト名として無効です。ホスト名を変更できない場合は、IP アドレスを入力してください。
3. 残りのリモートDPAサーバーについても手順1～4を繰り返します。

注記: リモートDPAサーバーの詳細はリポジトリではなく、中央サーバー上の以下のファイルに保存されます:

DPA-install-dir/iwc/tomcat/ignite_config/iwc/central/RemoteRepositories.json

これはプレーンテキストのJSONファイルです。このファイルには機密データは保存されません。