投稿者「climb」のアーカイブ

DPAは2種類のアドバイザーを提供

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

 

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

 

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

 

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

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

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

 

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

 

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

Kubernetesのデータ保護とDR

Kubernetes (KOO-bur-NEH-teez) または K8S は、コンテナ化されたワークロードとアプリケーションの管理を支援する強力なオープンソースプラットフォームで、コンテナオーケストレーションの標準となっています。また、コンテナで実行されるマイクロサービス・アーキテクチャの人気と普及に伴い、その使用範囲は拡大する一方です。

 

Kubernetesの仕組み
Kubernetesは、コンテナ化されたアプリケーションのライフサイクルを管理するための完全なフレームワークを提供します。DevOpsチームは、コンテナ展開の自動化、フェイルオーバー計画の準備、すべてのアプリケーションとグループが正しく動作していることの確認などを、規模に関係なく環境全体を完全に制御するために設定されたスケーラブルなアプローチで行うことができます。コンテナがオンプレミス、クラウド、またはハイブリッドデータセンターのいずれに保存されていても、Kubernetesによってデータとリソースを完全に管理することができます。

 

コンテナで異なる保護方法が必要
他のデータと同様に、コンテナもバックアップし、保護し、あらゆる災害に備えなければなりませんが、基礎となるさまざまな側面がこれらのプロセスを複雑にしています。まず、コンテナとパイプラインの問題があります。コンテナ・イメージをキャプチャするだけでなく、パイプライン、つまりイメージを生成するためのファクトリーを保護することがより理にかなっています。これには、設定スクリプトやドキュメントも含まれます。また、永続的なアプリケーションデータやボリュームを保護することも重要です。

 

データ保護とDRのためのKubernetesのオプションは限られています。環境がより複雑になり、より多くのコンテナが組み込まれるようになると、企業はコンテナ化されたアプリケーションと、さまざまなクラウドサービスにある残りのデータとの間でディザスタリカバリのアプローチを調整できるソリューションが必要になります。

 

クライムはKubernetesに対する次のデータ保護とDRソリューションを提供します。

 

 

●Kasten K10 Platform

 

●Zerto for Kubernetes

リスクマネジメントとは？

リスクとは、ポジティブであれネガティブであれ、組織の目標や目的に影響を与える可能性のあるあらゆる事象を指します。リスクマネジメントでは、リスクとは、これらの目標にマイナスの影響を与える可能性のある事象のことである。サイバーセキュリティの観点では、リスクとは、データ資産や業務の損傷や暴露につながる可能性があるあらゆる事象を指します。このようなリスクをうまく管理するためには、効果的なプロセスや戦略を開発する必要があります。

 

なぜリスクマネジメントに投資するのか？
サイバーセキュリティの例で説明すると、サイバーセキュリティのリスクはかつてないほど高まっています。例えば、ランサムウェアの攻撃はここ数年エスカレートしており、人質を取って悪質なコードを公開し、企業に破壊的な打撃を与えるケースが増えています。ランサムウェアの攻撃を受けると、企業の重要なデータは暗号化され、身代金を支払うまでアクセスできなくなります。

 

この攻撃から回復するためには、多額の評判と収益の損失が発生する可能性があります。リスクマネジメントは、サイバーセキュリティの脅威を認識し、事前に計画を立てます。サイバーセキュリティの脅威に対応するための十分な情報と効果的な戦略を準備しておくことで、組織の回復力が大幅に向上します。

クラウドデータマネジメントとは？

クラウドデータ管理とは、データを自社のサーバーではなく、クラウド上に置くことです。クラウドデータは、オンプレミスのデータストレージを補完することができますが、すべてのデータをクラウドに置くことを選択する企業も増えています。クラウドデータマネジメントの利点は、ユーザがどこからでもデータにアクセスできることです。また、データ管理にクラウドを利用することで、バックアップ、災害復旧、アーカイブがよりシンプルになり、必要に応じてストレージを追加購入できるため、費用対効果も高くなります。ただし、クラウドによるデータ管理は、セキュリティやデータ損失などの問題が発生する可能性があるのが難点です。

 

なぜクラウドデータマネジメントを選ぶのか？
従来のデータストレージには、いくつかの欠点があります。

・老朽化したハードウェアのアップグレードや交換に費用がかかる
・データセンターの賃貸料の高騰
・スケーリング（拡張）に伴う追加コスト
・コンプライアンスに対応するための専門的な社内ノウハウ
・オンプレミスでのデータ保持のリスク増大

 

クラウドでのデータ管理は、柔軟性、内蔵のセキュリティ、手頃な価格で、これらの問題を解決します。しかし、クラウドへのデータ移行は複雑で時間がかかり、データを危険にさらすだけでなく、社内のリソースを消費してしまう可能性があります。

SaaSとは？

SaaSは、ベンダーが提供する完全なソフトウェアソリューションを、通常は消費ベースで提供します。一般的な例としては、電子メール、カレンダー、オフィスツール（Microsoft Office 365など）などがあります。基本的に、お客様は組織のためにアプリケーションをレンタルし、ユーザはインターネットを介してそのアプリケーションに接続します。

 

インフラからアプリのデータまで、基盤となる部分はすべてサービス・プロバイダーのデータセンターに収容されます。ベンダーは、アプリケーションのアップタイムには責任を負いますが、アプリケーションでホストされているデータには責任を負いません。データに対する責任は、ユーザが負うことになります。

 

なぜSaaSを選ぶのか？

SaaSは、ソフトウェアとハードウェアのための最小限の初期費用で、高度なアプリケーションにアクセスする柔軟性を組織に提供します。SaaSでは、ハードウェア、ミドルウェア、ソフトウェアの購入、インストール、更新、保守の必要がないため、ERPやCRMなどの高度なエンタープライズ・アプリケーションも、あらゆる規模の組織で手頃な価格で利用することができます。通常は使用した分だけを支払います。SaaSサービスは、自動的にスケールアップとスケールダウンを行います。また、インターネットに接続できる環境であれば、どのコンピューターやモバイル機器からでもSaaSアプリケーションやデータにアクセスすることができます。

 

SaaSの保護

しかし、ほとんどのSaaSソリューションが責任共有モデルを採用しているため、SaaSデータの保護は組織に委ねられています。ソフトウェア・ベンダーによる基本的な保護はあるものの、SaaSのデータはベンダーの責任ではなく、ユーザの責任となります。つまり、障害、不慮の削除、ランサムウェアの攻撃は、復元不可能なデータと生産性の損失につながる可能性があるということです。

クラウドの種類は？

パブリッククラウドは、組織がオンデマンドのコンピューティングサービスとインフラストラクチャを管理するためにプロバイダーを雇うコンピューティングモデルである。このプロバイダーは、月額または使用量に応じた料金の購入でコンピューティングリソースを提供し、複数の組織がリソースを共有するのが一般的です。

 

プライベートクラウドは、コンピューティングリソースが専用で専有されており、基盤となるハードウェア層が他のすべてから分離されていることを意味します。企業は、自社のデータセンター、コロケーション施設、またはプライベートクラウドプロバイダーを利用することができます。

 

ハイブリッドクラウドモデルは、プライベートクラウドとパブリッククラウドを組み合わせて使用し、クラウドコンピューティングの柔軟な組み合わせを作成します。ハイブリッドクラウドコンピューティングは、インフラと運用を拡張し、組織のニーズに一貫して対応します。

 

さまざまなクラウドの選択肢は何を提供するのか?

 

パブリッククラウドサービスプロバイダーは、アクセスのしやすさ、コスト効率、オプションサービスなどを提供します。企業は、データの保存や機密性の低いアプリケーションのために、パブリッククラウドサービスを利用することがよくあります。

 

プライベートクラウドは、コントロールしやすく、セキュリティも高いが、メンテナンス、アップグレード、ソフトウェアの管理は、通常エンドユーザーが行います。

 

プライベートクラウドとパブリッククラウドのリソースを組み合わせてハイブリッドクラウドを構築する場合、企業はニーズに合わせてサービスの組み合わせを選択し、運用やコストの変化に応じてアプリケーションやデータを異なるクラウド間で柔軟に移行することが可能になります。

IaaSとは？

IaaSは、インターネット上で必要なコンピューティングインフラを提供し、多くの種類のワークロードのための標準的なモデルとして急速に普及しました。IaaSには物理リソースと仮想リソースの両方が含まれ、クラウド上でアプリケーションやワークロードを実行するために必要なものが提供されます。

 

IaaSプロバイダーは、通常世界中にある大規模なデータセンターを管理しており、その中には、その上にあるさまざまな層の仮想化コンピューティングリソースを動かすのに必要な物理マシンが入っています。これらのサービスには、通常、自動スケーリングやロードバランシングなどのサポートサービスが付属しています。IaaSには、ネットワーキングとストレージのサービスも含まれます。

 

IaaSを選択する理由
IaaSの人気は、その柔軟性と費用対効果に大きく起因しています。IaaSは、組織のニーズや要件に応じて、コンピューティング・インフラストラクチャを簡単にスケールアップまたはスケールダウンできるため、柔軟性があります。また、サードパーティ製のディザスターリカバリーソリューションを柔軟に選択することができます。IaaSの費用対効果は、従量課金制であることと、物理的なコンポーネントやその他のプライベートインフラへの支出を削減できることの両方から生まれます。

PostgreSQL パフォーマンス・チューニング

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などの主要なオープンソースデータベースのシステムおよびデータベースの監視と分析の両方を提供します。

データベーススキーマは何に使うのですか？

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

データベースのスキーマには、大きく分けてどのような種類があるのでしょうか。

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

 

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

データベーススキーマ設計のベストプラクティス

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

 

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

データベーススキーマの設計方法

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

データベース・スキーマ設計とは？

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

データベースのスキーマはどのように設計されているのですか？

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

データベーススキーマの定義

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

Database Performance Analyzer vs. Database Performance Monitor

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など、幅広いオープンソースデータベースプラットフォームをカバー

仮想化されたPostgreSQLの統合監視

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

 

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

PostgreSQL Azure、AWS、Googleの徹底チューニング

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

 

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

 

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

機械学習＋クエリアドバイザ＝PostgreSQLの最適化

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

 

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

 

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

PostgreSQLの重要なメトリクスを可視化する

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

 

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

 

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

クラウドからオンプレミスへのPostgreSQLの適用範囲

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の異常検知

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

DPAのテーブル・チューニング・アドバイザー

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

 

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

DPAのクエリー・パフォーマンス解析

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

 

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

 

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

DPAの待ち時間(Wait-based)を利用した分析

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

 

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

 

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