Database Impact Advisor

Database Impact Advisorを個々のExadataシステムに対して実行して、他のデータベースまたは他のオペレーティング・システム・プロセスによってパフォーマンスが影響を受けた可能性があるデータベースを特定するために、システム全体のデータベースCPU使用率のノイジー・ネイバー分析を実行できます。分析では、Autonomous Health Framework (AHF)バランス機能によって確立されたアルゴリズムが、過去30日間のOracle Enterprise Manager履歴メトリック・データに適用されます。さらに、Database Impact AdvisorはAHFバランスと直接統合され、検出されたCPUベースのパフォーマンスへの影響を最小限に抑えるために、すべてのデータベースにわたってデータベース・リソース・マネージャ(DBRM)設定を最適化するための推奨事項が生成されます。

Database Impact Advisorは、Exadata管理パックが有効になっているDatabase Machineターゲットで使用できます。「データベース・マシン」をクリックし、メニューから「Database Impact Advisor」を選択して起動できます。

前提条件

  • 自己更新は、Oracle Enterprise Managerで構成する必要があります。『Cloud Control管理者ガイド』「自己更新の設定」を参照してください。
  • Database Impact Advisorでは、Oracle Enterprise Managerから構成および管理される特定のAHFインストールを使用します。このAHFインストールは、「Database Impact Advisor用のAHF構成」の手順に従って、Oracle Enterprise Manager管理者が構成する必要があります。
  • Database Impact AdvisorからAHFバランス・レポートを実行するには、Oracle Enterprise Managerユーザーに、「Database Impact Advisor用のAHF構成」に示されているロールのいずれかが付与されている必要があります。

主要な概念

Database Impact Advisor分析フレームワークの基礎となるコア概念の一部を次に示します。これらの概念およびその他の概念の詳細は、『Oracle Autonomous Health Frameworkユーザーズ・ガイド』「ノイジー・ネイバーの問題の解決」を参照してください。

  • 制限: データベース・インスタンスが同時に使用できるvCPUの最大数。DBRMパラメータCPU_COUNTは、インスタンスの制限を実装します。

  • 保証: データベース・インスタンスが常に使用できることが保証されているvCPUの数。クラスタがデータベースの実行専用である場合、DBRMとオペレーティング・システムは連携して保証を提供します。オーバープロビジョニング率R=sum(CPU_COUNT)/物理vCPUの場合、データベース・インスタンスの保証はCPU_COUNT/Rになります。

    たとえば、64個のvCPUマシンで8つのデータベース・インスタンスが実行されており、すべてCPU_COUNTが16に設定されている場合、オーバーサブスクリプション率Rは2 (つまり8 * 16/64)となり、個々のデータベース・インスタンスごとに8 (16/2)が保証されます。

  • 危険範囲外時間: データベース・インスタンスのCPU使用量がCPU保証を超えていない時間。インスタンスが危険範囲外にある場合、マシンで実行されている他のインスタンスのCPU消費に関係なく、CPUベースのノイジー・ネイバーの問題が発生することはありません。

  • 危険範囲内時間: 1つ以上のデータベース・インスタンスのCPU使用量がCPU保証を超えている時間。インスタンスが危険範囲内にある場合、マシンで実行されている他のインスタンスのCPU消費に応じて、ノイジー・ネイバーの問題が発生する可能性があります。

  • 影響時間: 危険範囲内時間のうち、ホストのCPU使用率が70%を超えた時間。インスタンスが影響を受ける場合、マシンの合計CPU使用量が高いため、ノイジー・ネイバーの問題が発生している可能性があります。

  • パーティション化: クラスタがパーティション化されている場合、各データベース・インスタンスには専用のCPU容量があります。ネイバーによるCPU消費は、データベース・インスタンスに干渉できません。CPUリソース(構成された制限 - CPU_COUNTまで)は、常に使用可能であることが保証されます。ただし、CPUリソースは特定のデータベース・インスタンス専用であるため、インスタンスは他のインスタンスで使用されていないCPUサイクルを利用(借用)できません。通常、クラスタがパーティション化されている場合、データベース統合の程度は、クラスタ内の各マシンの物理CPUの数と、クラスタでホストされている各データベースのピークCPU消費によって制限されます。

    クラスタは、クラスタ内の各マシンで実行されているすべてのデータベース・インスタンスのCPU_COUNT DBRMパラメータ値の合計が、マシン上の物理CPUの数以下の場合にパーティション化されます。たとえば、クラスタ内のマシンにそれぞれ64個のCPUがあり、各マシンが4つのデータベース・インスタンスをホストしており、それぞれCPU_COUNTが16に設定されている場合、クラスタはパーティション化されます。

    クラスタをパーティション化することが目標である場合、過去のCPU消費データを分析することで、適切なCPU_COUNT設定を割り出すことができます。AHFバランスはこの分析をサポートしています。

  • 影響ステータス: データベースの全体的な影響ステータス。データベースの収集内に影響時間がある場合、そのステータスはFAILであり、危険範囲内時間がある場合、そのステータスはWARNINGであり、それ以外の場合、そのステータスはINFOです。

    クラスタがオーバー・プロビジョニングされていない場合、定義上、影響時間や危険範囲内時間がない可能性があり、ステータスはPASSと示されます。

Database Impact Advisorの使用

「Database Impact Advisor」の「CPU影響」タブには、「危険範囲内」(「警告」)および「影響」(「失敗」)カテゴリにある、Exadataシステム上のクラスタ、ホスト、データベースおよびデータベース・インスタンスの数の大まかなサマリーを示すチャートがあります。チャートの下の表には、各クラスタ、データベースおよびデータベース・インスタンスの特定の影響ステータスの詳細が列挙されています。表内の特定のデータベースまたはインスタンスを選択すると、データベースまたはインスタンスの危険範囲内時間および影響時間の詳細な履歴がビジュアル化されます。