dpa_sql_job_failure.txt
DPAには、ジョブステップのいずれかが失敗した際にトリガーされるデフォルトの「データベース・ジョブ失敗」アラートが用意されています。しかし、一部のジョブは条件分岐ロジックで設計されており、あるステップが失敗しても、後続のステップに処理が移行され、最終的に正常に完了する場合があります。そのような場合、ジョブは最終的に意図した通りに完了しているにもかかわらず、デフォルトのアラートが発動してしまう可能性があります。この拡張アラートは、真のジョブ失敗のみに焦点を当て、ジョブ全体が正常に完了しなかった場合に通知します。
アラートを作成するには、アラート > アラートの管理に移動し、新しいカスタム SQL アラート – 複数の数値リターンを追加します。以下の設定を使用してアラートを構成し、添付のコードにある SQL をSQL ステートメントフィールドに貼り付けます。ステータスが正常ではない場合にトリガーされるよう、通知ポリシーを必ず更新してください。
1. AI Query Assistとは？
AI Query Assistは、生成AIと実行プランのコンテキストを活用して、パフォーマンス重視のSQL書き換えを提案するSolarWindsの機能です。
2. なぜ一般的なAIツールを使わないのですか？
一般的なAIツールには実行コンテキストが欠けていたり、機密性の高いクエリの詳細が漏洩する恐れがあります。AI Query AssistはSolarWindsのワークフローに組み込まれており、データベースのチューニングを目的に設計されています。
3. AI Query Assistはどのように機能しますか？
パフォーマンスの低いクエリを選択し、分析に送信すると、最適化されたバージョンと元のクエリを並べて確認でき、提案された変更点についての明確な説明も表示されます。
4. AI Query Assist はどこで利用できますか？
AI Query Assist は、SQL Sentry、Database Performance Analyzer (DPA)、および SolarWinds Observability SaaS で利用可能です。
5. 手動によるクエリチューニングの代わりになりますか？
いいえ。書き換えの段階を迅速化しますが、提案された SQL を展開するかどうかは、引き続きユーザー自身が確認、テスト、判断する必要があります。
パフォーマンスチューニングのようなことに関しては、「無駄な時間」という言葉にはあまり共感できません。確かに、誰もがそう感じることはあるでしょう。特に、何時間も費やした挙句、最初から間違った方向に進んでいたと気づいた時はなおさらです。
その代わり、それを「投資した時間」、つまり何かを学ぶために費やした時間だと捉えるようにすべきです。次にこう尋ねるべきです。「週に何時間、何かを学ぶために費やしていますか？」。これによって大抵、研修についての議論が始まり、そこから「実務を通じた」研修へと話題が移り、気がつけばまさに目指していた場所、つまりSQL文のパフォーマンスチューニングに費やす時間について話し合っているのです。
では、その時間はどれくらいになると見積もりますか？まだ答えないでください。開発、デプロイ、保守、本番サポート、管理など、あらゆる分野について考えてみてください。気づけば、時間の75％近くを単に処理を高速化しようとすることに費やしていることに気づくかもしれません。それはかなりの時間です！
もし、システムを高速化するためにそれほど多くの時間を費やすのであれば、できるだけ効率的に作業を進めたいと思うはずです。それを実現するには、待機イベントを活用します。
考え方は単純です。クエリが何を待っているのかが分かれば、そのボトルネックを取り除き、クエリの実行速度を向上させることができるのです。
以下は、DPAに関して現在取り組んでいる、または検討中の事項の一覧です：
（注） 上記の機能の記載順は優先度を示すものではありません。また上記のリストは、現在開発中または検討中の項目を示していますが、これらの機能がいつ、あるいは実際に提供されるかを保証するものではありません。
Database Performance Analyzer (DPA) 2026.1が一般提供（GA：general availability）を開始したことをお知らせいたします。本リリースでは、アラートメールの認証に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 設定を更新してください。
DPA 2026.1 では、ネットワーク上のデータベースインスタンスを特定し、監視のためのオンボーディングプロセスを効率化する新しいデータベース検出機能が導入されました。
この機能により、DPAはユーザーが指定したIPアドレスとポートをスキャンし、DPAにまだ登録されていないデータベースインスタンスを検出します。検出結果は登録ワークフローに直接反映され、IPアドレスとポート情報が自動的に入力されるため、導入から価値創出までの時間を短縮し、データベース環境全体の可視化を加速します。
今後の検出機能の強化点には以下が含まれます：
このリリースでは、DPAは「AI Query Assist」という機能を通じてAIの力を提供します。この機能はSQLを書き換え、パフォーマンスを向上させることで、問題のあるクエリの解決にかかる平均時間を短縮します。詳細および今回のDPAリリースに含まれるその他の機能については、以下をご覧ください。
最適なパフォーマンスを発揮しつつ、望ましい結果を生み出すクエリを作成することは、特に複雑なSQLの場合やスキーマが十分に理解されていない場合には、困難な作業となり得ます。さらに、パフォーマンスの低いクエリを書き直すには、DBAや開発者が数多くの試行錯誤を繰り返す必要があり、多大な時間を要する場合があります。
AI Query Assistは、SQLのパフォーマンス向上を目的にトレーニングされたSolarWinds AIを活用し、機能的な同等性を維持しつつ、より高いパフォーマンスを発揮するクエリへと巧みに書き換えます。SolarWinds AIは管理された環境内で動作し、機密性の高い個人識別情報（PII）が完全にマスキングされ、安全に保たれることを保証します。AI Query Assistは現時点ではSQL Serverのクエリ最適化をサポートしていますが、今後のリリースではより幅広いDBMSへの対応が予定されています。
SolarWinds AIは、SQLテキストと実行計画（Explain Plan）を入力としてクエリを書き換え（最適化）ます。これにより、DBMSがクエリをどのように実行することを選択したかについての洞察を得ることができます。DDLには実行計画がないため、DDLステートメントは最適化できない点に注意してください。最適化の結果には以下が含まれます：
AIは新興技術であり、時間とともに改善されている点に注意してください。したがって、最適化結果を採用する前に、分析とテストを行う必要があります。
この機能を使用するための前提条件は次のとおりです：
最適化の取得:
新しい最適化のリクエスト
AIクエリアシストによるクエリの最適化について、皆様のご感想をお聞かせください！AIが優れた提案を行ったかどうかに関わらず、その内容をお知らせいただければ、最適化機能の改善に役立てたり、最適化されたクエリの成果を皆様と共に喜んだりすることができます。フィードバックは、「いいね」または「イマイチ」のアイコンをクリックし、結果に関するコメントを入力して送信してください。
PostgreSQL のパラメータ化クエリ（つまり、バインド変数を使用するクエリ）については、PostgreSQL は自動的に実行プランを生成しないため、DPA がクエリのパフォーマンスに関する詳細な洞察を提供することが困難でした。
このリリースでは、DPA が PostgreSQL にパラメータ化クエリの実行プランを生成するよう明示的に要求するようになりました。実行プランの詳細を確認できるという利点に加え、「テーブルチューニング」や「インデックスアドバイス」など、プランを活用する機能の利便性がさらに向上します。
DPAはIPv6を完全にサポートするようになり、IPv6またはハイブリッドネットワーク環境でもDPAを利用できるようになりました。IPv6アドレスを指定する際は、次のように角括弧で囲むのが最適な場合があります：
Teamsの連携機能について、Microsoftは従来のコネクタベースのWebhook URLのサポートを終了し、WebflowベースのWebhook URLに移行します。Microsoftは、新しいコネクタベースのWebhookに対して暫定的なサポートを提供していますが、これは2025年末をもって終了する予定です。
DPAは現在、暫定的なコネクタベースのWebhookと新しいWebFlowベースのWebhookの両方をサポートしており、連絡先に対して暫定または従来のWebhookを設定している場合、製品内でメッセージを表示します。また、DPAのREST APIも更新され、連絡先に従来のWebhookを割り当てようとするとエラーが返されるようになりました。
DPAには、カスタムで暗号化されたSSL証明書を使用してDPAに接続できるようにする「キーストアの管理」ページが追加されました。管理者は「オプション」ページにある「キーストアの管理」リンクを使用して、証明書とキーストアのパスワードが格納されたカスタムキーストアの保存場所を指定できます。
DBA(データベース管理者)のバーンアウト（燃え尽き）は、単なる人材確保の課題にとどまらず、ビジネス上のリスクでもあります。「State of Database Report」調査によると、DBAの38%が職を辞することを検討したことがあるとのことです。
1人の離職がもたらす影響：
なぜDBAは退職を考えているのでしょうか？それは、彼らの1日が純粋に事後対応的な業務に費やされているからです。報告書によると、彼らは週に27時間（時間の68％近く）という驚くべき時間を、以下の業務に費やしています：
「消火活動」に費やされる1時間は、最適化、自動化、あるいはイノベーションに費やされるはずだった1時間です。この不均衡が仕事の満足度を蝕み、バーンアウトを加速させています。
この業務負荷の問題は、経営陣とDBAの間にある根本的な認識のズレによってさらに悪化しています。経営陣は、監視体制が包括的かつ統合されていると想定しがちです。一方、DBAはそれが
危険なほどサイロ化されていることを知っています：
この認識のギャップは、重大な死角を生み出し、アラート疲労を助長し、インシデントの見落としを招くことで、リスクの高い非効率性を招いています。この乖離は、すでに手一杯のチームに直接的なプレッシャーを加えています。
経営陣とDBAの認識が一致していないと、非効率性とリスクが倍増します。認識のズレは、単にフラストレーションを引き起こすだけでなく、対応時間の遅延、ダウンタイムの増加、そしてイノベーションの阻害につながります。その影響はビジネス全体に波及し、人事部門だけに留まりません：
DBAの燃え尽きがもたらす経済的コストを削減し、経営層とDBAの間の溝を埋める方法はDPA（Databese Performance Analyser）の導入です。
Database Performance Analyzer（DPA）は、継続的な監視を提供し、応答時間分析と履歴動作ログを組み合わせることでパフォーマンスのベースライン確立を支援し、SQLパフォーマンスチューニングプロセスにおける推測作業を大幅に削減するように設計されています。DPAを使用すると、特にDPAのインテリジェントな機械学習機能と組み合わせることで、異常な動作を迅速に検出することも可能です。
DPAに統合されたテーブルチューニングアドバイザー機能は、クエリと実行計画を分析し、非効率なSQLクエリが実行されているテーブルを特定することで、Microsoft SQL Serverの最適化機会に対処し、情報に基づいたチューニング判断を下せるよう支援します。DPAの組み込みSQLパフォーマンス分析ツールでは、相対的なワークロード順にランク付けされた、テーブルにアクセスする非効率なSQLの詳細な分析も確認可能です。
DPAにはクエリパフォーマンスアナライザー機能も含まれており、クエリに関する最重要データを収集し、直感的で分かりやすいダッシュボードビューで表示します。クエリ詳細ページでは待機タイプやクエリ・チューニングアドバイザーを色分け表示し、チャートを組み立てることで、ユーザーは特定されたパフォーマンス問題を容易に検証・対処できます。カスタマイズ可能なレポートとアラートにより、ブロック階層やブロッキングがデータベース全体のパフォーマンスに与える影響に関する洞察も提供します。
多くの企業や組織（オンライン小売業者から政府機関まで）の主要な機能は、データベースにおける情報の保存とアクセスを中心に展開しています。内部ユーザーも外部ユーザーも、アプリケーションやウェブサイトが効率的かつ迅速に動作することを期待しています。このため、サーバーとデータベースが可能な限り効率的に機能することが重要です。
1回のクエリで数ミリ秒の遅延はさほど大きく感じられないかもしれませんが、データベース内の各クエリで遅延が発生すると、それはすぐに累積していきます。これに、生成され続ける膨大なデータ量が加わることで、データベースへの書き込みや情報取得のプロセスはますます煩雑で時間のかかるものとなります。ビジネスに不可欠なプロセスに遅延や速度低下が生じると、組織全体の機能が損なわれる可能性があります。
効果的なMS SQLチューニングには、データベース管理者とIT専門家がSQL Serverのパフォーマンスを常に把握し、データベース関連の操作が可能な限り効率的に実行されるようにすることが求められます。
多くの企業や組織（オンライン小売業者から政府機関まで）の主要な機能は、データベースにおける情報の保存とアクセスを中心に展開しています。内部ユーザーも外部ユーザーも、アプリケーションやウェブサイトが効率的かつ迅速に動作することを期待しています。このため、サーバーとデータベースが可能な限り効率的に機能することが重要です。
1回のクエリで数ミリ秒の遅延はさほど大きく感じられないかもしれませんが、データベース内の各クエリで遅延が発生すると、それはすぐに累積していきます。これに、生成され続ける膨大なデータ量が加わることで、データベースへの書き込みや情報取得のプロセスはますます煩雑で時間のかかるものとなります。ビジネスに不可欠なプロセスに遅延や速度低下が生じると、組織全体の機能が損なわれる可能性があります。
効果的なMS SQLチューニングには、データベース管理者とIT専門家がSQL Serverのパフォーマンスを常に把握し、データベース関連の操作が可能な限り効率的に実行されるようにすることが求められます。
SQL Serverデータベースのパフォーマンスチューニングの第一歩は、必要または望まれるほど効率的に実行されていない遅いSQLクエリを特定することです。
SQLチューニングには、将来予測可能な問題を未然に防ぐ「予防的」アプローチと、特定のユーザー問題が発生した際の「事後対応的」アプローチがあります。データベースクエリのチューニングにおいて、DBAが考慮すべき基本的なベストプラクティスを以下に示します：
待機時間と統計情報は、SQL Serverのパフォーマンスチューニングの重点領域を特定する有効な手段です。SQL Serverは「スレッド」を介してユーザー要求を管理し、各種スレッドのパフォーマンスを監視することで、管理者はどのクエリが低パフォーマンスであるかをより正確に判断できます。チューニングプロセスの目的は以下の通りです：
応答時間の短縮： ステートメント実行から応答までの時間
スループットの最適化： ステートメント処理に必要なリソース量
ただし、SQL Server パフォーマンス問題の根本原因を特定するには、データベース管理者はデータベースとサーバーの全レイヤーに関する洞察が必要となる場合があります。SQL Server チューニングツールは、上位 SQL ステートメント、待機タイプ、ブロックされたクエリ、およびインデックス不足がサーバーやデータベースのパフォーマンスに与える影響に関する理解を深めるプロセスを迅速化・効率化するのに役立ちます。
SQLパフォーマンスチューニングは、リレーショナルデータベースのクエリを可能な限り迅速かつ効率的に実行するために設計された一連の手順とプロセスです。SQLチューニングにはいくつかのステップが含まれます。まず、遅延が発生しているクエリを特定し、次にそれらのクエリを最適化して効率を最大化し、応答時間を短縮します。SQL Server、MySQLなど、多くのリレーショナルデータベースでSQLチューニングが必要となる場合があります。
管理者はシステムレベルでサーバーのパフォーマンス問題に対処しようと試みることができます（追加メモリやプロセッサの導入など）。しかし、これらの対策は実装コストが比較的高く、SQL Serverへの遅延クエリの根本原因に対処できない場合があります。SQLパフォーマンスチューニングは、不適切に記述されたSQLクエリや非効率的なインデックスを特定することでパフォーマンス向上を支援します。これはハードウェアや技術仕様の改善よりも、より的を絞った解決策となり得ます。
ただし、SQLのパフォーマンスチューニングは、特に手動で行う場合や大量のデータを管理する組織にとっては困難な作業となり得ます。こうした調整（たとえ小さな変更であっても）は、SQLサーバーやデータベースのパフォーマンスに広範な影響を及ぼす可能性があります。
データがキングである世界では、データベースの健全性とアプリケーションのパフォーマンスは表裏一体の関係にあります。遅いクエリ、リソースのボトルネック、最適化されていないワークロードは、ユーザー体験を悪化させ、コスト増を招きます。多くの企業はこうした問題に対処するため、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、ネットワーク応答などの要因で待機する時間を特定できる点です。
クエリの詳細分析
各ステートメントの実行頻度、リソースコスト、待機時間、実行時間に関する情報をユーザーに提供します。これにより開発者とDBAが連携し、機能不全のクエリを改善できます。
過去の発生傾向
DPAは長期間にわたりパフォーマンスデータを保持するため、パターンを分析し将来の要件を予測できます。チームは日単位、週単位、さらには年単位での進捗状況を振り返ることができます。
多様なプラットフォーム上で動作
DPAは様々なデータベースエンジンと連携するため、組織は全てを追跡するために多種多様なツールを使用する必要がありません。
使いやすいレポートとダッシュボード
可視化機能により、複雑なパフォーマンス統計を、必ずしもDBAではない開発者、システム管理者、マネージャーなど他の関係者にも理解しやすくします。
APMおよびITSMツールの活用
DPAは、チケットシステム、自動化プラットフォーム、アプリケーションパフォーマンス管理技術と連携して使用されることが多く、チームが単一のパフォーマンスエコシステムを構築するのを支援します。
現代のIT環境においてDPAが重要な理由
1. 作業の迅速化
クエリレベルや待機レベルでのパフォーマンス問題を特定することで、チームは大幅な時間節約が可能です。
2. アプリケーションの効率化
通常、データベースワークロードを最適化すれば、エンドユーザーにとって即座に改善が実感できます。
3. 連携の強化
DPAは全員に同一のパフォーマンスビューを提供するため、IT運用、開発者、データベースチームの協業が容易になります。
4. コスト削減
リソースの使用状況を正確に把握できれば、より的を絞った要求が可能になり、技術への負荷を軽減し、場合によっては高額なインフラ改善を回避できるかもしれません。
5. 信頼性の向上
プロアクティブな監視により、過酷な負荷条件下でも重要アプリケーションの安定稼働が保証され、ダウンタイム発生リスクを低減します。
データベースパフォーマンスアナライザーの活用タイミング
動作遅延アプリの高速化手法
不正動作SQL文の特定
アプリケーション移行・更新支援
拡張・増設準備
ハイブリッドクラウド／オンプレミスデータベースの監視
データベース変更がパフォーマンスに与える影響の検証
要約すると、データベースパフォーマンスアナライザーは、データベースに依存する多数のアプリケーションを運用する企業にとって優れたツールです。待機時間分析、明確なクエリ可視化、使いやすいダッシュボードにより、チームは問題発生後の対応から、問題発生前の機能改善へと移行できます。DPAは、データ環境が迅速かつ信頼性高く、ビジネスの必要に応じて拡張できることを保証するツールを提供します。
この機能は、個別のDPAサーバーを相互に連携させるために使用されます。中央サーバーはリモートサーバーから情報を収集し、データを単一のインターフェースに統合します。各DPAサーバーは独自のリポジトリを持ちます。中央サーバーのオーバーヘッドは低く、他のDPAインストール環境からの追加情報はリポジトリデータベースに追加されません。DPA Centralの導入を検討すべき状況は以下の通りです:
注記: SolarWindsでは、データベースインスタンスの監視にも使用するサーバーにDPA Centralを設定することを推奨します。DPA Central専用の別サーバーを用意する必要はありません。
– サーバーにDPAをインストールします。これが中央サーバーとなります。
– そのインスタンスに管理者としてログインします。
– 右上のDPAメニューから[オプション]をクリックします。
– [管理] > [表示] で [セントラル管理] をクリックします。
– 登録済みサーバーの一覧に、DPA サーバーが「セントラル DPA サーバー」として表示されていることを確認します
– 右上隅の DPA メニューから [オプション] をクリックします。
– [管理] > [表示] で [セントラル管理] をクリックします。
– [サーバーの追加] をクリックします。
– リモート DPA サーバーに関する情報を入力します。
– [接続テスト] をクリックし、[保存] をクリックします。
注記: リモートDPAサーバーの詳細はリポジトリではなく、中央サーバー上の以下のファイルに保存されます:
DPA-install-dir/iwc/tomcat/ignite_config/iwc/central/RemoteRepositories.json
これはプレーンテキストのJSONファイルです。このファイルには機密データは保存されません。
一部の長いSQL文は調整にうまく対応しない可能性があります（例: データベースのバックアップ、レプリケーション、データロードに関連するSQL文）。特定のクエリをDPAから除外することで、トレンドチャートを占有したり、効果のないチューニングアドバイスを生成したりするのを防げます。
注記: 除外されたSQL文がデータベースのパフォーマンスに影響を与え始めた場合、除外されているためDPAでは問題として表示されません。
– 「トレンドチャートに表示」設定を無効にすると、複数日または1日のトレンドチャートからSQL文が除外されます。1日未満の期間をドリルダウンすると、チャートにSQL文が含まれます。
– [アドバイザー分析を有効にする] 設定をオフにすると、クエリアドバイザーおよびテーブルチューニングアドバイザーを生成するために DPA が実行する分析からこのステートメントが除外されます。分析が無効な場合、DPA は SQL ステートメントの問題を検出しません。注記: [トレンドチャートに表示] 設定をオフにすると、両方のオプションがオフになります。DPA は、トレンドチャートに表示されない SQL ステートメントの分析を実行しません。
・Saveをクリック
レポートグループは、関連するレポートのデータを同一ページに表示するために使用されます。レポートグループを使用すると、複数のレポートを簡単に実行またはスケジュールできます。
追加リソース: レポートグループの作成
SQL検索 機能は、SQL文に関する既知の情報に基づいて任意のSQL文を検索するために使用されます。時間範囲を指定し、任意のフィルタと検索文字列の組み合わせを適用できます。
– データベースユーザー: SQL文を実行したユーザーID。
– プログラム: SQL文を実行したアプリケーション。
– データベース: SQL文がクエリを実行したデータベース。
– マシン: SQL文が実行されたコンピュータ。
・フィルターカテゴリに10件以上のアイテムが含まれる場合は、「すべて表示」リンクをクリックしてください。
・ダイアログが開いたら、ページをめくってすべての項目を表示したり、並べ替え順を変更したり、検索したりできます。
注:
追加リソース: SQLドキュメントの検索
DPAに初めてサインインした際に概要動画を見逃した場合、トレンドページの右上に「詳細を見る」タブが配置されています。
注釈は、パフォーマンスに影響を与える可能性のある変更（インデックスの追加、クエリのチューニング、リソースの追加など）を行う際に使用します。注釈はすべてのトレンドチャートおよびタイムスライスチャートに表示されます。変更前後のパフォーマンスデータを比較することで、変更がどのような影響を与えたかを確認できます。
リソースメトリックは、データベースの健全性を監視し、リソース競合とデータベース待機時間の増加を関連付けるために使用されます。リソースメトリックのグラフは、メトリックが警告または重大なしきい値を超えたことを示します。事前設定されたしきい値は、環境の要件に合わせて変更できます。メトリックに既定のしきい値が設定されていない場合、デフォルトのしきい値を追加できます。監視対象のインスタンスはすべて定義されたしきい値以下である必要があり、特定のデータベースインスタンスのみを対象とすることも可能です。カスタムしきい値は「デフォルトとして保存」をクリックすることで、すべてのインスタンスのデフォルトとして保存できます
– メトリックにデフォルトのしきい値がない場合、有効にしたい各しきい値レベルの横にあるトグルスイッチをクリックします。
– 警告レベルと重大レベルの双方を有効にする場合、両レベルの交点に同じ値を入力します：
– DPAは値が警告範囲内（範囲を含む）の場合に警告アラートを発行します。DPAは値が最小重大閾値を超えた場合に重大アラートを発行します。
– 例：ステップ1で示したしきい値の場合、値が10から20の間にあればDPAは警告アラートを発行します。値が20を超えると、DPAは重大アラートを発行します。
– DPAは、値が警告範囲（範囲内を含む）にある場合に警告アラートを発行します。DPAは、値が最小重大しきい値未満の場合に重大アラートを発行します。
– 例：下記のしきい値の場合、DPAは値が90から95の間に警告アラートを発行します。DPAは値が90未満の場合に重大アラートを発行します。
– このデータベースインスタンスのみに新しい値を適用するには、[保存]をクリックします。
– すべてのデータベースインスタンスに新しい値を適用するには、[デフォルトとして保存]をクリックします。
追加リソース: カスタムリソースしきい値
アイドルブロッキングは、セッションがトランザクションを開いた（リソースにロックを設定した）後、明示的にコミットまたはロールバックを行わなかった場合に発生します。トランザクションは、現在作業が行われていないにもかかわらず、開いたままになります。アイドルブロッカーが存在するかどうかを確認するには、次の手順を実行します。
– 一意の名前を入力します
– アラートを無効にするには、[有効] チェックボックスをオフにします
– 実行間隔を選択します。（DPAでは、実行間隔を少なくとも10分以上にすることを推奨します。）
– メール通知と共に送信する通知テキストを入力します。問題の説明と推奨される解決策を含めてください。
– アラートが適用されるデータベースインスタンスを指定します。これにより、SQLクエリまたはストアドプロシージャが（DPAリポジトリではなく）対象インスタンス上で実行されます。1つ以上の条件を満たすインスタンスは、手動で選択するか、ルールを使用して検索できます。
– [ルールを使用]をクリック
– [ルール]ページには既存のルールが一覧表示されます
– 既存のルールを選択するか、新規ルールを作成して選択します。
– [ルールの割り当てをクリア]
– アラート定義には、選択したルール名、ルール式、および現在ルール条件を満たしているインスタンスの一覧が表示されます。
– [データベースインスタンスの選択] をクリックします。
– 利用可能なデータベースインスタンスページにはデータベースインスタンスが一覧表示されます。アラートタイプが特定のデータベースタイプに限定されている場合、該当タイプのインスタンスのみが表示されます。
– 検索バーを使用してインスタンスを検索するか、フィルターを適用してリストを絞り込みます
– リスト内の全インスタンスを選択するには、リスト上部のチェックボックスを選択します。個々のインスタンスを選択するには、各インスタンスの横にあるチェックボックスを選択します。
– [割り当て]をクリックして戻る
– アラート定義画面に選択したインスタンスの一覧が表示されます。
– 実行するSQL文を入力するか、ストアドプロシージャの呼び出しを入力します。カスタムタグを使用して、データベースIDなどの変数や、ストアドプロシージャに必要な出力パラメータを含めることができます。
– [実行対象]ドロップダウンで、SQL文またはストアドプロシージャを、選択したデータベースインスタンスに対して実行するか、DPAリポジトリデータベースに対して実行するかを指定します。
– [説明]フィールドが利用可能な場合、アラート用のカスタム説明を入力できます。この説明は、メールテンプレートに[説明]パラメータが含まれている場合、アラートタイプのDPAデフォルト説明に置き換わります。
– アラートが数値を返す場合、返される値の単位を指定します。
– 最高レベルの最大値は空白のままにすると、そのレベルの最小値を超えるすべての値に対してアラートが通知されます。
– 複数のレベルを設定する場合、下位レベルの最大値は必ず等しい上位レベルの最小値に設定してください。
– レベルの最大値を入力すると、値が最小値を上回るか等しいが、最大値を下回る場合に、DPAはそのレベルでアラートを通知します。例えば、最小値が5で最大値が10の場合、値が5以上10未満のときにDPAはそのレベルでアラートを通知します。
– アラートが複数のデータベースインスタンスに適用される場合、[メールプレビュー]ダイアログボックスでインスタンスを選択し、[OK]をクリックします。メールを確認後、別のデータベースインスタンスを選択するか、[キャンセル]をクリックして[メールプレビュー]ダイアログボックスを閉じることができます。プレビュー中に評価できないアラートパラメータがあるため、ユーザーに送信されるメールはプレビューと完全に一致しない場合があります。
追加リソース: カスタムアラートのドキュメント
