Database Performance Analyzer

DPA 2025.3 を AWS RDS PostgreSQL データベース（バージョン 14.17）に対して実行しています。モニターユーティリティから送信された PREPARE dpaprepare() ステートメントから、これらの持続的なエラーが発生しています。これらのエラーを解決（または解釈）するにはどうすればよいですか？設定が必要な項目はありますか？

2025-10-21 23:03:27 UTC:10.115.16.33(49723):solarwindsdpa_monitor@prd _fad_db:[22271]:ERROR: relation “location_summary” does not exist at character 206
2025-10-21 23:03:27 UTC:10.115.16.33(49723):solarwindsdpa_monitor@prd _fad_db:[22271]:STATEMENT: PREPARE dpaprepare(unknown,unknown,unknown,unknown,unknown,unknown,unknown,unknown,unknown,unknown,unknown,unknown,unknown) as SELECT DISTINCT LS.DRO_PUBLIC_ID, LS.PSL_LATITUDE,LS.PSL_LONGITUDE, null FROM LOCATION_SUMMARY LS JOIN PPID_NETWORK_ASSOCIATION NWK ON LS.DRO_PUBLIC_ID = NWK.DRO_PUBLIC_ID AND NWK.PRODUCT_PROVIDER_NETWORK_ID in ($1,$2,$3,$4) AND NWK.PSL_DISPLAY_IND=’R’ WHERE LS.PSL_LATITUDE>$5 AND LS.PSL_LATITUDE<$6 AND LS.PSL_LONGITUDE>$7 AND LS.PSL_LONGITUDE<$8 AND LS.DRO_TYP_CD IN ($9,$10,$11,$12,$13)
2025-10-21 23:03:27 UTC:10.115.16.33(52799):solarwindsdpa_monitor@prd _fad_db:[4409]:ERROR: relation “location_summary” does not exist at character 244
2025-10-21 23:03:27 UTC:10.115.16.33(52799):solarwindsdpa_monitor@prd _fad_db:[4409]:STATEMENT: PREPARE dpaprepare(unknown,unknown,unknown,unknown,unknown,unknown,unknown,unknown,unknown) as SELECT DISTINCT LS.DRO_PUBLIC_ID, LS.PSL_LATITUDE,LS.PSL_LONGITUDE, CASE when PB.DRO_VALUE_AVP is NULL then ‘N’ else ‘Y’ end DPA_PRMR_APLY_CD FROM LOCATION_SUMMARY LS JOIN PPID_NETWORK_ASSOCIATION NWK ON LS.DRO_PUBLIC_ID = NWK.DRO_PUBLIC_ID AND NWK.PRODUCT_PROVIDER_NETWORK_ID in ($1,$2,$3,$4) AND NWK.PSL_DISPLAY_IND=’R’ LEFT OUTER JOIN LOCATION_EXTRA PB ON LS.DRO_PUBLIC_ID = PB.DRO_PUBLIC_ID AND PB.DRO_ATTRIBUTE_AVP =’BNFT’ and PB.DRO_VALUE_AVP =’PB’ WHERE LS.PSL_LATITUDE>$5 AND LS.PSL_LATITUDE<$6 AND LS.PSL_LONGITUDE>$7 AND LS.PSL_LONGITUDE<$8 AND LS.DRO_TYP_CD IN ($9,$10,$11,$12,$13)

データがキングである世界では、データベースの健全性とアプリケーションのパフォーマンスは表裏一体の関係にあります。遅いクエリ、リソースのボトルネック、最適化されていないワークロードは、ユーザー体験を悪化させ、コスト増を招きます。多くの企業はこうした問題に対処するため、Database Performance Analyzer（DPA）を活用しています。DPAは監視・最適化プラットフォームであり、データベース管理者（DBA）、開発者、ITチームがデータベースのワークロードを詳細に把握するのを支援します。

Database Performance Analyzer（DPA）の機能とは？ITチームは高度なツールであるDPAを活用し、データベースの動作効率に関する問題を検出、修正、診断します。DPAはシステムレベルの指標だけでなく、待機時間データも分析します。これにより、アプリケーションがデータベースとどのように連携しているか、パフォーマンス問題の真の原因がどこにあるかをユーザーが容易に把握できます。DPAは通常、多くの主要なリレーショナルデータベースプラットフォームと連携します。Oracle、SQL Server、MySQL、PostgreSQL、SAP ASE、DB2などです。ハイブリッドまたはマルチデータベースシステムを導入している企業は、多様なデータベースに対応するこの集中監視ソリューションを活用できます。

DPAにおける待機時間分析の重要性

従来のパフォーマンス監視ツールは、CPUやメモリの使用率を監視するだけでした。これらの指標は有用ですが、処理が遅延する根本原因を説明できません。DPAの最大の利点は、SQL文がロック、I/O、ネットワーク応答などの要因で待機する時間を特定できる点です。

1. DPAは待機状態を分析して問題箇所を特定します。
2. 問題を引き起こしている正確なクエリ
3. パフォーマンス低下の主な原因
4. ワークロードの経時的な挙動変化
5. これにより医師は問題を早期に発見し、より正確に診断できます。
6. データベースパフォーマンスアナライザーの最も重要な2つの機能は、リアルタイム監視と通知です。
7. DPAは常にパフォーマンスデータを監視しているため、チームは問題が発生した時点で特定できます。

クエリの詳細分析

各ステートメントの実行頻度、リソースコスト、待機時間、実行時間に関する情報をユーザーに提供します。これにより開発者とDBAが連携し、機能不全のクエリを改善できます。

過去の発生傾向

DPAは長期間にわたりパフォーマンスデータを保持するため、パターンを分析し将来の要件を予測できます。チームは日単位、週単位、さらには年単位での進捗状況を振り返ることができます。

多様なプラットフォーム上で動作

DPAは様々なデータベースエンジンと連携するため、組織は全てを追跡するために多種多様なツールを使用する必要がありません。

使いやすいレポートとダッシュボード

可視化機能により、複雑なパフォーマンス統計を、必ずしもDBAではない開発者、システム管理者、マネージャーなど他の関係者にも理解しやすくします。

APMおよびITSMツールの活用

DPAは、チケットシステム、自動化プラットフォーム、アプリケーションパフォーマンス管理技術と連携して使用されることが多く、チームが単一のパフォーマンスエコシステムを構築するのを支援します。

現代のIT環境においてDPAが重要な理由

1. 作業の迅速化

クエリレベルや待機レベルでのパフォーマンス問題を特定することで、チームは大幅な時間節約が可能です。

2. アプリケーションの効率化

通常、データベースワークロードを最適化すれば、エンドユーザーにとって即座に改善が実感できます。

3. 連携の強化

DPAは全員に同一のパフォーマンスビューを提供するため、IT運用、開発者、データベースチームの協業が容易になります。

4. コスト削減

リソースの使用状況を正確に把握できれば、より的を絞った要求が可能になり、技術への負荷を軽減し、場合によっては高額なインフラ改善を回避できるかもしれません。

5. 信頼性の向上

プロアクティブな監視により、過酷な負荷条件下でも重要アプリケーションの安定稼働が保証され、ダウンタイム発生リスクを低減します。

データベースパフォーマンスアナライザーの活用タイミング

動作遅延アプリの高速化手法

不正動作SQL文の特定

アプリケーション移行・更新支援

拡張・増設準備

ハイブリッドクラウド／オンプレミスデータベースの監視

データベース変更がパフォーマンスに与える影響の検証

要約すると、データベースパフォーマンスアナライザーは、データベースに依存する多数のアプリケーションを運用する企業にとって優れたツールです。待機時間分析、明確なクエリ可視化、使いやすいダッシュボードにより、チームは問題発生後の対応から、問題発生前の機能改善へと移行できます。DPAは、データ環境が迅速かつ信頼性高く、ビジネスの必要に応じて拡張できることを保証するツールを提供します。

この機能は、個別の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ファイルです。このファイルには機密データは保存されません。

一部の長いSQL文は調整にうまく対応しない可能性があります（例: データベースのバックアップ、レプリケーション、データロードに関連するSQL文）。特定のクエリをDPAから除外することで、トレンドチャートを占有したり、効果のないチューニングアドバイスを生成したりするのを防げます。

注記: 除外されたSQL文がデータベースのパフォーマンスに影響を与え始めた場合、除外されているためDPAでは問題として表示されません。

• サーバーに移動
• SQL文を表す名前またはハッシュ値をクリックします。クエリ詳細ページにSQL文に関する情報が表示されます
• 右上隅で「SQLプロパティ」をクリック
• 詳細設定で、以下のいずれかまたは両方のオプションを無効にします：

– 「トレンドチャートに表示」設定を無効にすると、複数日または1日のトレンドチャートからSQL文が除外されます。1日未満の期間をドリルダウンすると、チャートにSQL文が含まれます。

– [アドバイザー分析を有効にする] 設定をオフにすると、クエリアドバイザーおよびテーブルチューニングアドバイザーを生成するために DPA が実行する分析からこのステートメントが除外されます。分析が無効な場合、DPA は SQL ステートメントの問題を検出しません。注記: [トレンドチャートに表示] 設定をオフにすると、両方のオプションがオフになります。DPA は、トレンドチャートに表示されない SQL ステートメントの分析を実行しません。

・Saveをクリック

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

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

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

• OKをクリック

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

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

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

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

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

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

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

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

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

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

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

注:

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

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

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

 注釈は、パフォーマンスに影響を与える可能性のある変更（インデックスの追加、クエリのチューニング、リソースの追加など）を行う際に使用します。注釈はすべてのトレンドチャートおよびタイムスライスチャートに表示されます。変更前後のパフォーマンスデータを比較することで、変更がどのような影響を与えたかを確認できます。

• DPAホームページから、変更の影響を受けるデータベースインスタンスの名前をクリックします。
• トレンドチャートの右上にある「注釈を追加」をクリックします。

• 注釈に名前を付け、追加日時を指定し、変更内容とその理由の詳細を記入してください。保存をクリックします。注記：DPAサーバーが異なるタイムゾーンにある場合は、DPAサーバーの時刻を入力してください。

• 注釈はチャート上にフラグとして表示されます。フラグにカーソルを合わせると概要が表示され、クリックすると詳細が表示されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 適切なサーバーをクリックしてください
• チャート内のハッシュ値（トップSQLステートメントの右側）をクリックしてください。注：SQLステートメントはデフォルトでハッシュ値によって識別されます

• 右上の「SQL プロパティ」をクリックします
• SQL 名フィールドに名前を入力します。

• 保存をクリック
• 現在のページの左上にある戻るをクリックして前のページに戻ります

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

・

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本サイトはこちらです。

環境の大規模化・複雑化に伴い、データベース管理者は、様々な種類のデータベースを監視できる異常検知ツールを必要としています。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)は、24時間365日、異常ベースの監視を行い、機械学習アルゴリズムにより最新の洞察を提供します。30日以上監視が停止した場合、DPAのアルゴリズムは古いデータに基づいて予測を行うことはありません。代わりに、DPAは新しいデータから学習を開始し、3日後に最新のデータに基づいて再び予測を開始します。この機能により、異常検知の取り組みが最新の関連データのみによって裏付けられていることを確認することができます。