1. ユーザーズ・ガイド
  2. データベース・ワークロード・パフォーマンスの監視および管理
  3. Oracle Database QoS Managementの概要
  4. Oracle Database QoS Managementの概要

6.3 Oracle Database QoS Managementの概要

ここでは、システムでOracle Database QoS Managementがどのように動作し、ワークロードのパフォーマンスをどのように評価するかについて簡単に説明します。

6.3.1 Oracle Database QoS Managementの動作

Oracle Databaseでは、特定のワークロード専用のサーバー・グループでサービスを開始することにより、サービスを使用してシステムのワークロードを管理できます。たとえば、データベース層では、あるサーバー・グループをオンライン・トランザクション処理(OLTP)専用にし、別のサーバー・グループをアプリケーション・テスト専用にし、第3のサーバー・グループを内部アプリケーション専用にすることができます。システム管理者は、データベース・サービスを実行できるサーバーの数を手動で変更することで、リソースを特定のワークロードに割り当てることができます。

このようにサーバー・グループを使用すると、あるワークロードの要求のサージ、障害およびその他の問題が他のワークロードに影響することを防ぐために、ワークロードは相互に分離されます。しかし、このタイプのデプロイメントでは、リソースが共有されないため、各ワークロードのピーク要求に対応するために各グループにサーバーを個別にプロビジョニングする必要があります。

Oracle Database QoS Managementでは、次のアクションが実行されます。

  1. QoS管理者が作成したポリシーを使用して次の処理を行います。

    • 受信した作業リクエストの属性(アプリケーションの接続先のデータベース・サービスなど)を使用して各作業リクエストをパフォーマンス・クラスに割り当てます。

    • 各パフォーマンス・クラスの目標レスポンス時間(パフォーマンス目標)を判断します。

    • ビジネスにとって最も重要なパフォーマンス・クラスを判断します。

  2. すべてのパフォーマンス・クラスのリソース使用率とリソース待機時間を監視します。

  3. パフォーマンス・クラスに対して有効になっているパフォーマンス目標に照らして、そのパフォーマンス・クラスの平均レスポンス時間を分析します。

  4. 目標のレスポンス時間を超えているパフォーマンス・クラスのパフォーマンスを向上させるリソース再割当ての推奨を生成し、その推奨が実装された場合に各パフォーマンス・クラスのパフォーマンス・レベルに対して予測される影響を分析します。

  5. Oracle Database QoS Management管理者から指示された場合に、推奨にリストされているアクションを実装し、システムを評価して、リソースの再割当て後に各パフォーマンス・クラスがそのパフォーマンス目標を満たしているかどうかを確認します。

6.3.1.1 Oracle Database QoS Managementとサーバー・プール

サーバー・プールを使用し、クラスタ内にサーバーのグループを作成してワークロードを分離できます。

いかなる時点においても、1つのサーバーは1つのサーバー・プールにしか所属できません。Oracle Databaseは、単一のサーバー・プールで、または複数のサーバー・プールにまたがって作成できます。Oracle Database QoS Managementは、測定および予測された要求に基づいてサーバーをあるサーバー・プールから別のサーバー・プールに移動するための推奨を作成できます。また、Oracle Database QoS Managementは、現在有効になっているパフォーマンス目標を満たすためにサーバーを再配置することもできます。

関連項目

6.3.1.2 Oracle Database QoS Managementとインスタンス・ケージング

複数のデータベース・インスタンスが1つのサーバーを共有している場合、データベース・インスタンスはサーバーのCPU、メモリーおよびI/O帯域幅を共有する必要があります。インスタンス・ケージングでは、Oracle Database Resource ManagerとCPU_COUNTデータベース初期化パラメータを使用して、Oracleデータベース・インスタンスのCPU使用率を制限します。Oracle Database QoS Managementを使用する場合、サーバーのすべてのインスタンスのCPU_COUNT値の合計を、物理CPUの合計数以下にする必要があります。また、各CPUパーティション、つまりスライスの厚さ(CPU数)は、サーバー・プール内のデータベースの各インスタンスで均一である必要があります。これらの要件により、各データベースの予測可能で分離されたパフォーマンスを確認できます。

図6-1 インスタンス・ケージングとCPUスライス

図6-1の説明が続きます
「図6-1 インスタンス・ケージングとCPUスライス」の説明

インスタンス・ケージングを実装すると、Oracle Database QoS Managementで、あるスライスから同一サーバー・プール内の別のスライスへのCPUリソースの再割当てを提案できます。インスタンス・ケージング設定を変更する推奨を実装する場合、Oracle Database QoS Managementは、サーバー・プールのサーバー上で実行されているすべてのデータベース・インスタンスのCPU_COUNTパラメータを均一に変更します。

CPU_COUNTパラメータを変更して、リソース・プランをアクティブ化するようにOracle Database QoS Managementを構成すると、インスタンス・ケージング機能が有効になります。インスタンス・ケージングを使用してインスタンスのCPU使用率に制約を加えると、そのインスタンスはCPUバウンドになる可能性があります。このとき、リソース・マネージャによって、アクティブなリソース・プランに基づき、様々なデータベース・セッション間でのCPU占有率の割当てが開始されます。

6.3.1.3 Oracle Database QoS Managementとサービス

Oracle Database QoS Managementは、データベース・サービスを使用してクライアントとアプリケーションのワークロードを監視および管理します。

Oracle RACクラスタでは、Oracle Database QoS Managementはデータベース・サービスが提供されているサーバー・プールとノードを監視します。1つのサービスは1つのサーバー・プールでのみ実行できます。データベースが複数のサーバー・プールにわたる場合、すべてのサーバー・プールのインスタンスにアクセスするために、複数のサービスを作成する必要があります。

管理者管理型データベースの場合、すべてのインスタンスは汎用サーバー・プールで実行され、サービスは特定のインスタンス上で実行されますが、この場合も単一プール内で実行されます。

ワークロードは、Oracle Clusterwareによって管理されているデータベース・サービスを使用してデータベースに接続するクライアントとアプリケーションについて監視されます。接続では、Java Database Connectivity(JDBC)(シックまたはシン)またはOracle Call Interface(OCI)を使用する必要があります。接続では、ロード・バランシング・アドバイザのランタイム目標がSERVICE_TIMEに設定され、接続ロード・バランシング目標がLONGに設定されているサービスを使用する必要があります。次に例を示します。 

srvctl modify service -db db_name -service service_name -rlbgoal SERVICE_TIME 
-clbgoal LONG -cardinality UNIFORM

次のように、データベース・サービスのカーディナリティを定義する必要があります。

  • サービスが実行されるサーバー・プールの最大サイズが1より大きい(または無制限)場合、サービスのカーディナリティをUNIFORMに設定します。

  • サービスが実行されるサーバー・プールの最大サイズが1の場合、サービスのカーディナリティをSINGLETONに設定します。

関連項目

6.3.2 ポリシー・セットの概要

Oracle Database QoS Managementの中心となる概念はポリシー・セットです。ポリシー・セットでは、リソース、パフォーマンス・クラス(ワークロード)、および各パフォーマンス・クラスのパフォーマンス目標を指定する1つ以上のパフォーマンス・ポリシーを指定できます。ポリシー・セットでは、リソースの可用性に対する制約も指定できます。Oracle Database QoS Managementのパフォーマンス・ポリシーは、システム全体で各パフォーマンス・クラスのリソースの可用性を管理し、パフォーマンス・ポリシーに設定されたパフォーマンス目標が満たされるようにします。

Oracle Enterprise Managerを使用してシステムの新しいデフォルト・ポリシーを作成するとき、Oracle Database QoS Managementによってデフォルトの分類ルールおよび関連するパフォーマンス・クラス名が提供されます。たとえば、最初のポリシー・セットを作成するとき、Oracle Database QoS Managementによってクラスタ内のすべてのデータベース・サービスが検出され、各サービスのパフォーマンス・クラスが作成されます。パフォーマンス・クラスには、サービス名の最後に_pcを追加して名前が付けられます。たとえば、サービスの名前がsalesである場合、そのサービスのパフォーマンス・クラスに割り当てられる名前はsales_pcです。

ポリシー・セット内では一度に1つのパフォーマンス・ポリシーをアクティブにできます。パフォーマンス・ポリシーは、カレンダ・スケジュール、メンテナンス・ウィンドウ、イベントなどを使用して特定の要件に対応するようにアクティブにできます。

ポリシー・セットを作成する場合は、Oracle Database QoS Managementで管理する必要のあるクラスタ内のサーバー・プールを指定します。(類似するパフォーマンス要件を持つワークロードの分類に使用される)パフォーマンス・クラスも定義します。次に、パフォーマンス・ポリシーを作成して、優先順位が最高のパフォーマンス・クラスと各パフォーマンス・クラスのパフォーマンス目標を指定します。パフォーマンス目標を満たすために、Oracle Database QoS Managementは必要に応じてリソースの再割当てを推奨し、推奨アクションが各パフォーマンス・クラスのパフォーマンス目標を満たす能力に与える影響を予測します。

たとえば、営業時間中のアプリケーション・ワークロードを管理するポリシーを作成できます。顧客が製品またはサービスを購入するために使用するアプリケーションは、この期間中にビジネスに対する優先順位が最も高いアプリケーションです。注文調達および請求アプリケーションにも高い優先順位を指定します。人事およびエンタープライズ・リソース・プランニング(ERP)アプリケーションは、この期間中に優先順位が低いアプリケーションです。オンライン販売アプリケーションで要求のサージが発生する場合は、販売アプリケーションに割り当てるリソースを増やし、重要度の低いアプリケーションに割り当てるリソースを減らすことがOracle Database QoS Managementによって推奨されます。推奨には、各パフォーマンス・クラスに対するパフォーマンスの変化(プラスまたはマイナス)の予測も含まれます。

図6-2に示すポリシー・セットは次の要素から構成されます。

図6-2 Oracle Database QoS Managementポリシー・セットの要素


図6-2の説明が続きます
「図6-2 Oracle Database QoS Managementポリシー・セットの要素」の説明

関連項目

6.3.3 サーバー・プールの概要

ビジネスに対して作成するクラスタ数を決定する場合は、サーバーの統合によって可能になるコストの節約と、統合されたワークロードがある程度有意に相互干渉する危険性とを比較する必要があります。サーバー・プールを導入してクラスタを論理的に分割すると、ワークロードを分離したまま物理的な統合とリソースの機敏性の利点を実現できます。

管理者は、図6-3に示すように、様々なサーバー・プールで実行できるワークロードを定義できます。Oracle RACデータベースに接続するアプリケーションは、そのサーバー・プールに現在割り当てられているサーバー上でのみ稼働するサービスを使用します。たとえば、図6-3では、OSサービスを使用する接続とアプリケーションはHRサーバー・プール内のサーバーにのみアクセスするため、これらの接続によって実行される作業はSalesサービスを使用しているアプリケーションに干渉しません。Oracle Database QoS Managementは、サービス・レベルを満たすためのこれらの各グループ内のリソース割当ての管理、およびビジネス要件の変化に対応するためのリソースの自動的な再配布を支援できます。

図6-3 サーバー・プール、Oracleデータベースおよびデータベース・サービスのダイアグラム

図6-3の説明が続きます
「図6-3 サーバー・プール、Oracleデータベースおよびデータベース・サービスのダイアグラム」の説明

サーバー・プールを使用して、単一エンティティとして管理できるサーバーのグループを作成できます。これらのサーバー・プールで実行するようにデータベースを作成できます。各サーバーがデータベースの単一インスタンスのみを実行する場合、そのデータベースにより多くのリソースが必要な場合は、サーバー・プールに追加のサーバーを割り当てることができます。複数のデータベース・インスタンスが単一のサーバー上で実行されている場合、データベース・インスタンスはそのサーバーの共有リソース(メモリーやCPUなど)を競う必要があります。あるデータベース・インスタンスが他のインスタンスよりもワークロードが大幅に高い場合、そのデータベース・インスタンスによって、同じサーバー上で実行されている他のインスタンスのパフォーマンスが大幅に低下することがあります。

インスタンス・ケージングを使用して、Oracle DatabaseインスタンスのCPU使用率を制限できます。CPU_COUNTパラメータを設定して1つのインスタンスが使用できる最大CPU数を制限することで、サーバー上のデータベース・インスタンス間でCPUをパーティション化して、インスタンスがCPUリソースを過剰に使用するのを防ぐことができます。CPU_COUNT設定は、サーバー・プール内のデータベースの各インスタンスで同じである必要があります。Oracle Database QoS Managementは、サーバー・プール内のすべてのデータベース・インスタンスのCPU使用率を監視し、必要に応じて、現在の設定の変更を推奨できます。

図6-4 サーバー・プールとCPUスライス

図6-4の説明が続きます
「図6-4 サーバー・プールとCPUスライス」の説明

単一のサーバー・プールを使用するかわりに、複数のサーバー・プールを作成してサービスを管理し、プール間にサービスを再配置することをお薦めします。この構成の使用には、次の利点があります。

  • 異なるタイプのワークロードには異なる構成が必要であり、チューニング目標も異なります。たとえば、OLTPアプリケーションを使用して商品またはサービスを購入する顧客は、出荷および支払い情報の画面のレスポンス時間が短いことを期待します。アプリケーションでの注文の処理に要する時間が長すぎると、顧客は興味を失い、会社は販売機会を逸する可能性があります。対照的に、社内HRアプリケーションを使用している従業員は、HR画面のスポンス時間が短くなくても、画面を使用し続けようとします。HRアプリケーションでのオンライン・タスクの処理に予想より長い時間がかかった場合でも、従業員が使用を中止する可能性はほとんどありません。

  • アプリケーションには、1日、1週間または1か月中にビジネス目標を満たすための様々なリソース要件があります。サーバー・プールを使用してアプリケーションのワークロード間でリソースを分割できます。特定の期間のパフォーマンス目標を満たすために、パフォーマンス・ポリシーでサーバー・プールのディレクティブ・オーバーライドを使用してサーバー・プールのデフォルト属性(MaxやMinなど)を変更できます。

    たとえば、会社にオンライン納税申告アプリケーションがある場合、そのアプリケーションでは、政府が指定する期日までに顧客の納税証明書を準備し、提出する必要があります。提出期限の直前の期間中、納税証明書の準備と提出に関連するアプリケーションはその年の他の期間よりも多くのリソースを必要とします。このサービス要件を確実に満たすために、QuarterlyFilingsという名前のパフォーマンス・ポリシーを作成して標準のサーバー・プール・ディレクティブをオーバーライドし、QuarterlyFilingsがアクティブなときは、追加のワークロードを処理するために確定申告書類作成アプリケーションで使用するサーバー・プールに2台ではなく最低4台のサーバーが必要であることを指定できます。QuarterlyFilingsパフォーマンス・ポリシーが有効でないときは、デフォルトのパフォーマンス・ポリシーが有効であるため、そのサーバー・プール内の最小サーバー数は2です。

  • ワークロードをサポートするサーバー数がOracle Database QoS Managementによって調整されるため、要求レベルが変化した場合でもアプリケーション・ユーザーのパフォーマンス・レベルが一貫します。これにより、ワークロード・レベルが低から高に変化した場合に顧客のパフォーマンスの期待値がリセットされるのを防ぎます。

    たとえば、需要の高い新しい消費者製品を販売しており、その製品を割引価格で大量に販売することを会社が広告したとします。その結果、多くの新規顧客がこの製品を注文するため、OLTPアプリケーションでは急増するトランザクション数を処理する必要があります(要求のサージが発生します)。新規顧客は、OLTPアプリケーションのパフォーマンスに対して何を期待すべきかわかりません。しかし、既存の顧客は、新規顧客の大量流入によって自身のオンライン・ショッピングの操作性が影響を受けた場合、否定的な反応を示す可能性があります。また、OLTPアプリケーションがすべての受信注文を処理できない場合、新規顧客の一部はアプリケーションを中止し、かわりに別の会社に注文したり小売店に行ったりする可能性があります。

    Oracle Database QoS Managementでは、使用可能なリソースの再割当てを管理して、他のアプリケーションのサービスのクオリティを低下させずに要求のサージに対応できます。

  • 一部のワークロードは適切にスケーリングできませんが、クラスタ環境の高可用性の利点は享受できます。これらのワークロードを固定サイズのサーバー・プールにデプロイすると、パフォーマンスの管理性と高可用性の両方が実現されます。

    たとえば、サイズが1サーバーに固定されたサーバー・プールでERPアプリケーションを実行すると、サーバー・プールの最大サイズとサーバー・プールの最小サイズが両方とも1に設定されます。そのサーバー・プールのサーバーに障害が発生した場合、Oracle Clusterwareはそのサーバー・プールに新しいサーバーを自動的に割り当てて、最小サイズの1サーバーが維持されるようにします。障害が発生したサーバー上にあるインスタンスおよびサービスは、新しいサーバーで再開されるため、これらのインスタンスおよびサービスを使用しているアプリケーションは使用可能な状態のままです。

関連項目:

6.3.4 Oracle Database QoS Managementがサーバー・プールを使用する方法

管理する必要のあるワークロードに応じて、1つ以上のサーバー・プールを作成する必要があります。

クラスタにOracle Grid Infrastructureを初めてインストールするときに、デフォルトのサーバー・プール(空きプール)が作成されます。最初は、すべてのサーバーがこのサーバー・プールに配置されます。新規サーバー・プールを作成する場合、そのサーバー・プールに割り当てるサーバーは空きプールから自動的に移動され、新規に作成されたサーバー・プールに配置されます。この時点で、そのサーバー・プールで実行するデータベースをインストールし、そのデータベースに接続するアプリケーションに対してOracle Clusterwareで管理されるデータベース・サービスを作成できます。

Oracle RACデータベースでサーバー・プールの柔軟性を利用するには、ポリシー管理型デプロイメント・オプションを使用してデータベースを作成する必要があります。これにより、データベースが複数のサーバー・プールに配置されます。

Oracle Database 12c リリース1 (12.1.0.2)では、Oracle Database Quality of Service (QoS) Managementは管理者管理のOracle RACおよびOracle RAC One Nodeデータベースをその測定のみモードと監視モードでサポートしていました。Oracle Database 12cリリース2 (12.2.0.1)以降、ポリシー管理型または管理者管理型であるOracle RACおよびOracle RAC One Nodeデータベースとともに管理モードでOracle Database QoS Managementを使用できます。

注意:

サーバー・プールの作成時に、候補サーバー・リスト(server_names attribute)またはカテゴリを使用する場合、Oracle Database Quality of Service (QoS) Managementでサーバー・プールを拡張できる能力がこのような制限により限定されるため、適切ではないサーバーは使用されません。

関連項目

6.3.5 パフォーマンス・クラスの概要

ポリシー・セットには、クラスタで実行する様々なパフォーマンス・クラス、つまりワークロードのパフォーマンス目標が含まれています。Oracle Database QoS Managementでは、ポリシー・セットに定義された一連の分類ルールを使用して、作業リクエストをパフォーマンス・クラスに分類します。作業リクエストをパフォーマンス・クラスに割り当てるために使用する基本的な分類子は、データベースへの接続に使用するサービスの名前です。

6.3.5.1 パフォーマンス・クラス・タグ

作業リクエストの分類では、作業リクエストが属するパフォーマンス・クラスを識別するユーザー定義の名前(タグ)が適用されます。特定のパフォーマンス・クラスにグループ化されているすべての作業リクエストは、同じパフォーマンス目標を持ちます。事実上、タグは作業リクエストを関連するパフォーマンス・クラスのパフォーマンス目標に結び付けます。Oracle Database QoS Managementによってタグが各作業リクエストに割り当てられるため、システムのすべてのコンポーネントが測定を行い、該当するパフォーマンス目標に照らして評価するためのデータをOracle Database QoS Managementに提供できます。

6.3.5.2 作業リクエストへの分類子の適用

分類は、新しい作業がシステムに入るたびに行われます。作業リクエストがサーバーに到着すると、作業リクエストのタグがチェックされます。作業リクエストにタグがある場合、サーバーはこの作業リクエストがすでに分類されていると判断し、タグは変更されません。作業リクエストにタグが含まれていない場合は、分類子がチェックされ、対応するパフォーマンス・クラスのタグが作業リクエストに付加されます。

作業リクエストの分類方法を示すために、Oracle RACデータベースに接続するアプリケーションについて考えます。アプリケーションでは、データ・サービスsalesを使用します。Oracle Database QoS Management管理者は、Oracle Database QoS Managementの初期構成中に、sales_pcパフォーマンス・クラスにsalesサービスを使用する作業リクエストが含まれる必要があることを指定しました。接続リクエストがデータベースによって受信されると、Oracle Database QoS Managementはタグをチェックします。タグが見つからない場合、Oracle Database QoS Managementは、パフォーマンス・ポリシーで指定された順序で接続リクエスト内の情報を各パフォーマンス・クラスに対して指定されている分類子と比較します。分類される接続リクエストがsalesサービスを使用している場合は、sales_pcパフォーマンス・クラス内の分類子が接続リクエストの情報と比較されるときに、一致が見つかり、データベース作業リクエストにsales_pcパフォーマンス・クラスのタグが割り当てられます。

6.3.5.3 作業リクエストを分類するための追加フィルタの使用方法

1つのアプリケーションで、一連のパフォーマンス特性を持つ多くのタイプの作業リクエストをサポートできます。デフォルトの分類ルールを拡張および調整することで、Oracle Database QoS Management管理者は1つのアプリケーションに対して複数のパフォーマンス目標を記述できます。たとえば管理者は、Webベースのアプリケーションに、ログイン、参照、検索および購入に関連する作業リクエストごとに異なるパフォーマンス目標が必要であると判断する場合があります。

Oracle Database QoS Managementでは、パフォーマンス・クラスをデータベースで実行されている実際のワークロードにマップするために、接続パラメータのユーザー定義の組合せがサポートされます。これらの接続パラメータは2つの一般クラスに属しており、結合してきめ細かいブール式を作成できます。

  • 構成パラメータ: サポートされる構成パラメータはSERVICE_NAMEおよびUSERNAMEです。パフォーマンス・クラスの各分類子では、データベース・サービスの名前を指定する必要があります。クライアントまたは中間層からデータベース接続を行っているユーザーの名前を識別することで、粒度を高めることができます。これらの分類子を使用する利点は、異なるワークロードを別々のパフォーマンス・クラスに関連付けるためにアプリケーション・コードを変更する必要がないことです。

  • アプリケーション・パラメータ: サポートされるアプリケーション・パラメータはMODULE、ACTIONおよびPROGRAMです。これらはオプションのパラメータです。MODULEとACTIONの値はアプリケーション内で設定する必要があります。アプリケーションのタイプに応じて、これらのパラメータは次のように設定できます。

    • OCI: OCI_ATTR_MODULEおよびOCI_ATTR_ACTIONを使用します。

    • Oracle Data Provider for .NET(ODP.NET): OracleConnectionオブジェクトでModuleNameおよびActionNameプロパティを指定します。

    • JDBC: SYS_CONTEXTにMODULEおよびACTIONを設定します。

PROGRAMパラメータは、データベース・ドライバとプラットフォームごとに異なる方法で設定または導出されます。詳細と例については、適切なOracle Database開発者ガイドを参照してください。

アプリケーションのワークロードを管理するには、アプリケーション・コードで特定のサービスを使用してデータベース接続を行います。アプリケーションの様々な部分で生成されたワークロードをより正確に制御するために、追加のパフォーマンス・クラスを作成し、サービスまたはユーザー名に加えてPROGRAM、MODULEまたはACTIONを含む分類子を使用できます。たとえば、salesサービスを使用するクラスタへのすべての接続がsales_pcパフォーマンス・クラスに属するが、salesサービスを使用していてもユーザー名がAPPADMINの接続はsales_adminパフォーマンス・クラスに属することを指定できます。

関連項目

6.3.5.4 新規パフォーマンス・クラスの作成の決定

時間が経つにつれて、ワークロードおよびパフォーマンス目標が変更される可能性があります。

特定のデータ・センターで使用するパフォーマンス・クラスは、時間の経過とともに変更されることが予想されます。たとえば、アプリケーションのある部分に対するパフォーマンス目標の変更が必要になることがあります。この場合は、追加の分類子を持つ新しいパフォーマンス・クラスを作成してターゲットの作業リクエストを識別し、パフォーマンス・ポリシーを更新してこのパフォーマンス・クラス用の新しいパフォーマンス目標を追加します。つまり、1つのパフォーマンス目標を1つ以上のよりきめ細かなパフォーマンス目標で置換し、1つのパフォーマンス・クラスの作業リクエストを複数のパフォーマンス・クラスに分割します。

アプリケーション開発者は、使用するパフォーマンス・クラスを推奨できます。具体的には、アプリケーション開発者は異なるアプリケーション・ワークロードを識別する方法を推奨でき、ユーザーはこれらの推奨を使用して、各タイプの作業リクエストが別々に管理されるようにパフォーマンス・クラスの分類子を作成できます。

追加のパフォーマンス・クラスを作成すると、異なるアプリケーション・ワークロードに対して許容されるレスポンス時間を指定できます。たとえば、パフォーマンス目標では、sales_pc_checkoutパフォーマンス・クラスのcheckoutアクションを実行している作業リクエストは1ミリ秒以内に完了する必要があり、sales_pc_browseパフォーマンス・クラスのbrowseアクションを実行している作業リクエストは100ミリ秒以内に完了する必要があることを指定できます。

関連項目

6.3.6 パフォーマンス・ポリシーとパフォーマンス目標の概要

様々なパフォーマンス目標を管理するには、1つ以上のパフォーマンス・ポリシーを定義します。

パフォーマンス・ポリシーは、パフォーマンス目標のコレクションであり、ビジネスに対する重要度の基準です。たとえば、通常の営業時間、平日の非営業時間、週末の運用、および四半期決算の処理中に使用するパフォーマンス・ポリシーをそれぞれ定義できます。どの時間についても、Oracle Database QoS Management管理者によって指定された1つのパフォーマンス・ポリシーが有効になります。各パフォーマンス・ポリシーの中で、パフォーマンス目標の重要度(ランキング)を変えて、特定の期間中に特定のワークロードに高い優先順位を与えることができます。

パフォーマンス・ポリシーには、同時に有効になるパフォーマンス目標のコレクションがあります(クラスタ上で実行されているアプリケーションまたはワークロードごとに1つ以上のパフォーマンス目標)。一部のワークロードとそれらのパフォーマンス目標は、他のワークロードとそれらのパフォーマンス目標よりもビジネスにとって重要です。一部のパフォーマンス目標は、特定に期間に重要度が高く、その他の期間には重要度が低い可能性があります。

6.3.6.1 パフォーマンス目標の概要

各パフォーマンス・クラスのパフォーマンス目標を作成して、各パフォーマンス・クラスに割り当てられているすべての作業リクエストのターゲット・パフォーマンス・レベルを指定します。

パフォーマンス目標では、ビジネス要件(ターゲットのパフォーマンス・レベル)とそのパフォーマンス目標が適用される作業(パフォーマンス・クラス)の両方を指定します。たとえば、パフォーマンス目標では、hr_pcパフォーマンス・クラス内の作業リクエストの平均レスポンス時間が0.2秒未満である必要があることを指定できます。

パフォーマンス目標は、パフォーマンス・ポリシーで指定します。パフォーマンス・クラスが「測定のみ」としてマークされていないかぎり、各パフォーマンス・ポリシーには各パフォーマンス・クラスのパフォーマンス目標が含まれます。このリリースのOracle Database QoS Managementでは、平均レスポンス時間という1種類のパフォーマンス目標のみサポートされます。

ワークロードのレスポンス時間はデータベース・クライアント・リクエストに基づきます。レスポンス時間では、ネットワーク上でクラスタがリクエストを受信してからリクエストがクラスタから離れるまでの時間が測定されます。レスポンス時間には、ネットワーク上でのクライアントとの情報の送受信に必要な時間は含まれません。パフォーマンス・クラス内のすべてのデータベース・クライアント・リクエストのレスポンス時間は、秒単位のデータベース・リクエスト数として測定された平均レスポンス時間として平均および提示されます。

関連項目

6.3.6.2 サーバー・プールのディレクティブ・オーバーライドの概要

サーバー・プールのディレクティブ・オーバーライドは、パフォーマンス・ポリシーが有効な場合に、サーバー・プールに「最小」、「最大」および「重要度」の可用性プロパティを設定します。

パフォーマンス・ポリシーには、サーバー・プールのディレクティブ・オーバーライドのセットを含めることができます。サーバー・プールのディレクティブ・オーバーライドは、パフォーマンス・ポリシーのアクティブ化期間中に有効になるため、Oracle Database QoS Managementが推奨する割当て変更に対する制約として機能します。たとえば、サーバー・プールからサーバーを移動するとサーバー・プールのサーバー数が指定された最小サーバー数よりも少なくなる場合、Oracle Database QoS Managementはサーバー・プールからのサーバーの移動を推奨しません。

図1-5に示すように、システムのパフォーマンス・ポリシーを作成して、6年または1日の中での時間に基づいてワークロードを管理できます。通常の条件下では、これらのパフォーマンス・ポリシーはデータベース・ワークロードの実行を安定した速度に保ちます。データベースのワークロード・リクエストが突然増加した場合は、特定のサーバー・プールにパフォーマンス・ポリシーで指定されているよりも多くのリソースが必要になることがあります。

図6-5 パフォーマンス・ポリシーによるベースライン・リソース管理

図6-5の説明が続きます
「図6-5 パフォーマンス・ポリシーによるベースライン・リソース管理」の説明

たとえば、電話で注文を受け、販売アプリケーションを使用して注文を作成するとします。電話セールス部門は通常の営業時間中にのみ応対しますが、顧客はインターネットで注文することもできます。日中は多くの注文が行われるため、販売アプリケーションはワークロードを処理するためにより多くのリソースを必要とします。この構成は、営業時間パフォーマンス・ポリシーを作成してバック・オフィス・サーバー・プールに最大2台のサーバーを配置できることを指定し、Oracle Database QoS Managementが必要に応じてオンライン・サーバー・プールにサーバーを移動できるようにすることで管理されます。電話セールス部門が営業を終了した後は、販売アプリケーションのワークロードが減ります。この構成を管理するには、営業時間後パフォーマンス・ポリシーを作成してバック・オフィス・サーバー・プールに最大4台のサーバーを配置できることを指定し、社内アプリケーションが翌営業日より前にワークロードを完了するのに必要な追加リソースを獲得できるようにします。

このシナリオでは、営業時間パフォーマンス・ポリシーと営業時間後パフォーマンス・ポリシーにサーバー・プールのディレクティブ・オーバーライドを含めることができます。パフォーマンス・ポリシーにサーバー・プールのディレクティブ・オーバーライドが含まれる場合、指定したサーバー・プールに対する「最小」、「最大」および「重要度」の現在の設定は、パフォーマンス・ポリシーが有効になっているときにオーバーライドされます。これにより、販売サーバー・プールに追加のサーバーを配置してオンライン販売アプリケーションに必要なリソースを与え、バック・オフィス・サーバー・プールで使用されるリソースを制限して、そのワークロードが販売ワークロードに干渉しないようにすることができます。

関連項目

6.3.6.3 パフォーマンス・クラスのランクの概要

パフォーマンス・クラスにランクを指定すると、作業の優先順位を決定するのに役立ちます。

パフォーマンス・ポリシー内で、各パフォーマンス・クラスにビジネスの重要度レベル(ランク)を割り当てて、重要度の低いパフォーマンス・クラスよりも重要度の高いパフォーマンス・クラスのパフォーマンス目標を満たすことを優先できます。すべてのパフォーマンス・クラスのすべてのパフォーマンス目標を同時に満たすだけの十分なリソースがない場合は、重要性の低いパフォーマンス目標を犠牲にして、重要性の高いパフォーマンス・クラスのパフォーマンス目標を満たす必要があります。パフォーマンス・ポリシーは、各パフォーマンス・クラスのビジネスの重要度を指定します。これには、最高、高、中、低または最低を指定できます。

注意:

ランクに基づいたリソースへの優先アクセスは、単一インスタンスのOracle RACデータベースやOracle RAC One Nodeには適用されません。

たとえば、図6-5に示したパフォーマンス・ポリシーを使用すると、営業時間パフォーマンス・ポリシーが有効なときは、オンライン・サーバー・プールにアクセスする販売アプリケーションが最高ランクを持ちます。すべてのパフォーマンス・クラスのパフォーマンス目標を満たすのに十分なリソースがない場合は、バック・オフィス・サーバー・プールを使用しているアプリケーションがパフォーマンス目標を満たしていない場合でも、オンライン・サーバー・プールを使用するアプリケーションが使用可能なリソースに優先的にアクセスします。

同じランクに複数のパフォーマンス・クラスがあってもかまいません。Oracle Database QoS Managementで、パフォーマンス目標を満たしていない複数のパフォーマンス・クラスが検出され、そのパフォーマンス・クラスにアクティブなパフォーマンス・ポリシー内で同じランクが割り当てられている場合、Oracle Database QoS Managementはパフォーマンス目標の実現に最も近いパフォーマンス・クラスにより多くのリソースを与えるような変更を推奨します。推奨されたアクションが実装された後、パフォーマンス・クラスがターゲットのパフォーマンス・レベル以上になると、Oracle Database QoS Managementはシステム・パフォーマンスの評価を新規に実行します。

関連項目

6.3.6.4 Oracle Database QoS Managementポリシー・ワークロードの重要性によるデータベースの起動順序の決定

ユーザー作成のOracle Database QoS Managementポリシーがアクティブな場合、パフォーマンス・クラスのランク付けされた順序により、関連するOracle RACデータベースの開始順序またはリクエスト・リアルタイムLMSプロセス・スロットが決定されます。パフォーマンス・クラス・ランキングの使用により、統合環境で実行しているミッションクリティカルなデータベースに、リアルタイムで実行するLMSプロセスが確実に含まれることになるので、ノード間通信でのリソースのボトルネックが解消されます。Oracle Database QoS Managementポリシーでは各ワークロードのランクを指定するので、各データベースにMax(Ranks)の値を使用することにより、各データベースのビジネスの重要度を一貫性のある表現で示すことができます。

6.3.7 Oracle Database QoS Managementがパフォーマンス・データを収集および分析する方法

Oracle Database QoS Managementサーバーは、クラスタのOracle Real Application Clusters (Oracle RAC)およびOracle RAC One Nodeデータベースからメトリック・データを取得します。

データは、5秒ごとにパフォーマンス・クラスによって関連付けられます。データには、データベース・リクエスト到着率、CPU使用率、CPU待機時間、I/O使用率、I/O待機時間、グローバル・キャッシュ使用率、グローバル・キャッシュ待機時間など、多くのメトリックが含まれます。クラスタの現在のトポロジとサーバーの状態に関する情報がデータに追加されます。Oracle Database QoS Managementのポリシーおよびパフォーマンス管理エンジン(図6-6に示します)は、データを分析して、アクティブなパフォーマンス・ポリシーによって設定された現在のパフォーマンス目標に関してシステムの全体的なパフォーマンス・プロファイルを判断します。

パフォーマンス評価は1分間に1回実行され、いずれかのパフォーマンス・クラスがその目標を満たしていない場合は推奨が行われます。推奨では、どのリソースがボトルネックであるかが示されます。可能な場合は、推奨に具体的な修正処理が含まれます。推奨には、推奨された処理を実装することに決定した場合にすべてのパフォーマンス・クラスに対して予測される影響のリストも含まれます。

図6-6に、様々なデータ・ソースからのデータの収集のダイアグラムと、Oracle Enterprise Managerでその情報を使用する方法を示します。この図では、CHMはOracle Cluster Health Monitorを示し、Server Manager(SRVM)はOracle Clusterwareのコンポーネントです。

図6-6 Oracle Database QoS Managementサーバー・アーキテクチャのダイアグラム

図6-6の説明が続きます
「図6-6 Oracle Database QoS Managementサーバー・アーキテクチャのダイアグラム」の説明

関連項目

6.3.8 推奨の概要

Oracle Database QoS Managementでは、推奨を通じて特定のパフォーマンス目標を満たすための余剰容量を管理できます。

ビジネスで定期的に要求のサージが発生する場合、またはオープン・ワークロードをサポートする必要がある場合は、アプリケーションのパフォーマンス・レベルを維持するためにピーク・ワークロードを満たすシステムを設計できます。通常、ピーク・ワークロードを処理できるシステムの作成は、必要に応じて使用可能にでき、不要なときにはアイドルにしておける追加ハードウェアの取得を意味します。要求のサージが発生したとき以外にサーバーをアイドルにしておくかわりに、他のアプリケーションのワークロードの実行にそれらのサーバーを使用することもできます。ただし、要求のサージが発生したときに他のアプリケーションの実行でサーバーがビジー状態の場合は、ピーク・ワークロードを満たすことができず、ビジネス・アプリケーションが期待どおりに実行されない可能性があります。

  • Oracle Database QoS Managementが推奨を生成する方法
    パフォーマンスの目的が達成されていない場合、Oracle Database QoS Managementは、いくつかの考えられる解決策を評価し、最も効果的な解決策を推奨として提示します。
  • 推奨のタイプ
    パフォーマンス・クラスのパフォーマンス目標が満たされていない場合、Oracle Database Quality of Service Managementはボトルネックを軽減するためにリソースの使用のリバランスの推奨を発行します。
  • 最適な推奨の選択
    Oracle Database Quality of Service Managementは、ワークロード・パフォーマンスを向上させるための推奨を複数提供できます。
  • 推奨の内容
    各推奨は、いくつかの情報で構成されます。
  • 推奨の実装の概要
    Oracle Database QoS Managementは、推奨を自動的には実装しません。
  • 例: 推奨の生成方法

6.3.8.1 Oracle Database QoS Managementが推奨を生成する方法

パフォーマンス目標が達成されていない場合、Oracle Database QoS Managementは、いくつかの考えられる解決策を評価し、最も効果的な解決策を推奨として提示します。

Oracle Database QoS Managementを使用する場合、システムは反復的なプロセスで絶えず監視され、アクティブなパフォーマンス・ポリシーのパフォーマンス目標が満たされているかどうかが確認されます。パフォーマンス・データがOracle Enterprise Managerに送信され、Oracle Database QoS Managementダッシュボード(ダッシュボード)および「パフォーマンス履歴」ページに表示されます。

1つ以上のパフォーマンス目標が満たされていない場合は、システムのパフォーマンスを評価した後で、Oracle Database QoS Managementは1つのパフォーマンス目標(通常は、現在満たされていないパフォーマンス目標のうち、ランクが最高のもの)のパフォーマンスの向上を追求します。現在のワークロードと予測されるワークロードの両方に対して確保されている容量ですべてのパフォーマンス目標が満たされる場合、Oracle Database QoS Managementは「アクションは必要ありません。パフォーマンス目標はすべて達成されています」と通知します。

関連項目

6.3.8.2 推奨のタイプ

パフォーマンス・クラスのパフォーマンス目標が満たされていない場合、Oracle Database Quality of Service Managementはボトルネックを軽減するためにリソースの使用のリバランスの推奨を発行します。

Oracle Database QoS Managementは考えられるいくつかのソリューションを評価して、次のようなソリューションを選択します。

  • システム全体を最も向上させる

  • システムの中断を最も少なくする

  • 違反中の最もランクの高いパフォーマンス・クラスをサポートする

Oracle Database QoS Managementは、次のタイプの推奨を行うことができます。

6.3.8.2.1 コンシューマ・グループの昇格と降格

パフォーマンス・クラスのパフォーマンス目標が満たされておらず、パフォーマンス・クラスが他のパフォーマンス・クラスと同じデータベースにアクセスしている場合、Oracle Database QoS Managementはコンシューマ・グループ・マッピングの変更を推奨できます。コンシューマ・グループ・マッピングを変更すると、パフォーマンス目標を満たしていないパフォーマンス・クラスがより多くのCPUリソースにアクセスできるようになります。Oracle Database QoS Managementは、同じデータベースとサーバー・プール内のリソースに対して競合しているパフォーマンス・クラスについてのみコンシューマ・グループ・マッピングの推奨を発行します。

6.3.8.2.2 CPU数の変更

サーバー・プールのサーバーで複数のデータベース・インスタンスが実行されている場合、Oracle Database QoS Managementは、サーバー上のあるスライスでデータベース・インスタンスによって使用されているCPUリソースを、より多くのCPUリソースを必要とするスライスに提供するように推奨できます。パフォーマンス目標を満たしていないパフォーマンス・クラスがあり、システム上に使用可能なヘッドルームのある別のスライスがある場合、またはそのスライスを使用するパフォーマンス・クラスのランクが低い場合、Oracle Database QoS Managementはアイドル・スライスからオーバーロードしているスライスへのCPUの移動を推奨できます。この推奨が実装されると、サーバー・プール内のすべてのサーバーで、アイドル・インスタンスの場合は下方に、オーバーワーク・インスタンスの場合は上方に、CPU_COUNTパラメータが調整されます。

6.3.8.2.3 サーバー・プール間でのサーバーの移動

Oracle Database QoS Managementが表示できる別の推奨アクションは、あるサーバー・プールから別のサーバー・プールにサーバーを移動し、パフォーマンス・クラスのパフォーマンス目標を満たすための追加リソースを提供することです。クラスタ内のすべてのサーバー・プールのサイズが指定された最小サイズの場合、またはリソースが必要なサーバー・プールが最大サイズの場合、Oracle Database QoS Managementはサーバー・プールからのサーバーの削除を推奨できません。この場合、ダッシュボードに現在推奨されるアクションはありませんと表示されます。

注意:

このタイプの推奨は、管理者管理型データベースに使用できません。

サーバー・プールの最小サイズは、サーバー・プールに必要なサーバー数です。クラスタ内の各サーバー・プールのサーバー・プール最小値属性に値を追加する場合、この合計とクラスタ内のサーバー総数の差は、要求の変化を満たすためにサーバー・プール間で移動できる共有サーバー(フロート)を表します。たとえば、クラスタに10台のサーバーと2つのサーバー・プールがあり、各サーバー・プールの最小サイズが4の場合、システムには、サーバー・プール間で移動できる2台のサーバーがあることになります。ターゲット・サーバー・プールが最大サイズに達していない場合、これらのサーバーを移動できます。Oracle Database QoS Managementは、サーバーの移動を推奨する場合、常にポリシーで設定されている最小および最大サイズ制約を考慮します。

サーバー・プールの最小サイズをゼロに設定した場合にシステムで要求のサージが発生すると、Oracle Database QoS Managementは、そのサーバー・プールからすべてのサーバーを移動してサーバー・プールを最小サイズにすることを推奨する場合があります。この結果、そのサーバー・プールを使用するパフォーマンス・クラスはリソースが完全に不足し、基本的に停止します。最小サイズがゼロのサーバー・プールには、ビジネスでの重要度が低く、パフォーマンス・ポリシーでパフォーマンス・クラスに低いランクが割り当てられているアプリケーションのみホストする必要があります。

6.3.8.2.4 プラガブル・データベースに割り当てられるCPU共有の変更

Oracle Database Quality of Service (QoS) Managementは、マルチテナント・データベースのプラガブル・データベース(PDB)間で使用されるCPUリソースを管理します。

各プラガブル・データベースは個別に管理されます。パフォーマンス目標がプラガブル・データベースを利用するパフォーマンス・クラスで満たされていない場合、Oracle Database QoS Managementでは、プラガブル・データベースに割り当てられているCPU共有を増やすことを推奨できます。CPU共有の割当ては、リソース・プランのDatabase Resource Managerコンシューマ・グループ・マッピングで実装されます。CDBが管理されている場合、各PDBの共有は1から50に増加します。その後、そこから必要に応じて再割当てされます。

CDBのリソース・マネージャ・プランでは、次の2つのレベルでリソースを管理します。

  • すべてのPDB間のCPU共有の割当て

  • 各PDB内のコンシューマ・グループ間のCPUの優先順位の設定

6.3.8.3 最適な推奨の選択

Oracle Database Quality of Service Managementは、ワークロード・パフォーマンスを改善する複数の推奨を提供できます。

特定のパフォーマンス・クラスのリソース・ボトルネックを緩和しようとする場合、Oracle Database QoS Managementでは、そのパフォーマンス・クラスにより多くのリソース(CPU時間など)を追加するか、パフォーマンス・クラスの作業リクエストに対してリソースをより迅速に使用可能にすることが推奨されます。推奨は、ターゲット・パフォーマンス・クラスのより高いコンシューマ・グループへの昇格、リソース・プラン内の競合パフォーマンス・クラスの降格、サーバー・プール内の様々なスライス間で共有されているCPUリソースの調整、またはサーバー・プール間でのサーバーの移動の形式をとります。

推奨アクションを実装すると、他のパフォーマンス・クラスに使用できるリソースが減ります。推奨を生成する場合、Oracle Database QoS Managementは全体的なシステム・パフォーマンスへの影響を評価します。リソースの割当ての変更に対して可能な推奨によって1つのパフォーマンス・クラスのレスポンス時間が若干向上しても、他のパフォーマンス・クラスのレスポンス時間が大幅に低下する場合、Oracle Database QoS Managementはパフォーマンス利得が小さすぎるため変更は推奨されないことをレポートします。

Oracle Database QoS Managementは、次の場合に、パフォーマンス・クラスのパフォーマンスに悪影響のある推奨を発行することがあります。

  • リソースを奪われるパフォーマンス・クラスに対する悪影響がパフォーマンス目標違反の原因になることが予測されず、リソースへのアクセスが向上するパフォーマンス・クラスについてよい影響が予測される場合

  • リソースを奪われるパフォーマンス・クラスのランクが低く、ビジネスに対する重要度が、リソースを増やされるパフォーマンス・クラスの重要度よりも低い場合

リソース・ボトルネックを複数の方法で解決できる場合、Oracle Database QoS Managementは、目標に違反している最もランクの高いパフォーマンス・クラスのパフォーマンスを向上させるアクションを推奨します。Oracle Database QoS Managementで生成された別の推奨を表示し、アクションの実装が推奨されているかどうかを確認することもできます。たとえば、CPUリソース上のボトルネックを解決するために考えられる1つのソリューションは、CPUを最も使用しているパフォーマンス・クラスに関連付けられているコンシューマ・グループを降格させることです。このパフォーマンス・クラスの作業リクエストに対してCPUへのアクセスを制限することにより、そのデータベースに対する他のパフォーマンス・クラスの作業リクエストが使用できるCPU時間が多くなります。ただし、Oracle Database QoS Managementは、ターゲットのパフォーマンス・クラスのレスポンス時間の向上が小さすぎるため、このアクションを推奨しない可能性があります。

関連項目

6.3.8.4 推奨の内容

各推奨は、いくつかの情報で構成されます。

推奨の分析データには、図6-7に示すように、各パフォーマンス・クラスのレスポンス時間の予測される変化、各パフォーマンス・クラスの「パフォーマンス満足度メトリック」(PSM)の予測される変化、および数あるアクションの中でこのアクションが選択される理由が含まれます。この例では、推奨されるアクションを実装した場合、Oracle Database QoS Managementは、ランキングが最高のsales cartパフォーマンス・クラスのレスポンス時間がデータベース・リクエスト当たり0.00510秒から0.00426秒に向上することを予測します。これは、PSMの11.6%向上に相当します。他のパフォーマンス・クラスは別のサーバー・プールを使用するため、変更の影響を受けません。

図6-7 推奨されるアクションの分析例

図6-7の説明が続きます
「図6-7 推奨されるアクションの分析例」の説明

関連項目

6.3.8.5 推奨の実装の概要

Oracle Database QoS Managementは、推奨を自動的には実装しません。

推奨アクションが実行されるのは、QoS管理者が「実装」ボタンをクリックした後のみです。Oracle Database QoS Management管理者が推奨を実装した後、新しい推奨が行われる前に、指定された設定時間にわたってシステム・パフォーマンスが再評価されます。また、Enterprise Managerを構成して、パフォーマンス・クラスが目標を満たしていない期間に基づいてアラートを生成できます。

関連項目

6.3.8.6 例: 推奨の生成方法

オンライン・サーバー・プールに2台のサーバーがあり、バック・オフィス・サーバー・プールに2台のサーバーがあるシステムについて考えます。オンライン・サーバー・プールは、sales_pcパフォーマンス・クラスおよびsales_cartパフォーマンス・クラスという2つのワークロードをホストします。オンライン・サーバー・プールの最小サイズは2です。バック・オフィス・サーバー・プールは、人事(HR)アプリケーションとエンタープライズ・リソース・プランニング(ERP)アプリケーションの2つの社内アプリケーションをホストします。バック・オフィス・サーバー・プールの最小サイズは1です。sales_cartパフォーマンス・クラスのランクは最高で、erp_pcパフォーマンス・クラスのランクは最低です。sales_pcパフォーマンス・クラスのランクはhr_pcパフォーマンス・クラスよりも高くなっています。

このシナリオでは、sales_pcのワークロード・サージが発生した結果、リソースの競合とsales_cartパフォーマンス・クラスのパフォーマンス目標違反が発生した場合に、OLTPアプリケーションのサービス・レベル合意(SLA)違反が引き起こされることがあります。sales_cartパフォーマンス・クラスの方がランクが高く、より高いランクはsales_cartパフォーマンス・クラスのパフォーマンス目標を満たすことがsales_pcパフォーマンス・クラスのパフォーマンス目標を満たすことよりも重要であることを示しているため、Oracle Database QoS Managementは、sales_pcワークロードを犠牲にしてsales_cartパフォーマンス・クラスのCPUアクセスを増やす推奨を発行します。

推奨を実装しても、sales_cartおよびsales_pcパフォーマンス・クラスがまだパフォーマンス目標を満たさない場合、Oracle Database QoS Managementは、バック・オフィス・サーバー・プール(重要度の低いワークロードまたはヘッドルームの多いワークロードをホストするサーバー・プール)からサーバーを移動することによりオンライン・サーバー・プールのサーバー数を増やす推奨を発行します。このシナリオでは、バック・オフィス・サーバー・プールは現在最小サイズである1を超えているため、バック・オフィス・サーバーからサーバーを移動できます。バック・オフィス・サーバー・プールの最小サイズが2の場合、Oracle Database QoS Managementは、使用可能なサーバーを別のサーバー・プールで探す必要があります。Oracle Database QoS Managementは、サーバー・プールからサーバーを移動するとそのサーバー・プールが最小サイズを下回る場合には、サーバーの移動を推奨しません。

推奨されたアクションを実装し、アプリケーションでクラスタ管理サービスおよびクライアント・ランタイム・ロード・バランシングを使用する場合、アプリケーション・ユーザーに対してこの再割当てによるサービスの中断は発生しません。サービスは、移動されるサーバー上でトランザクションによって停止されます。ストレスがかかっているサーバー・プールにサーバーが追加された後、すべてのデータベース・インスタンスとそれらによって提供されているサービスは、再割当てされたサーバー上で開始されます。この時点で、セッションはサーバー・プール内の新しいサーバーを使用するように徐々に切り替えられ、ボトルネックが緩和されます。

同じシナリオで、sales_pcパフォーマンス・クラスとhr_pcパフォーマンス・クラスの両方がパフォーマンス目標を満たすために追加のサーバーを必要とする場合、sales_pcパフォーマンス・クラスはhr_pcパフォーマンス・クラスよりもランクが高いため、Oracle Database QoS Managementは最初にsales_pcパフォーマンス・クラスのパフォーマンスを向上させる推奨を発行します。sales_pcパフォーマンス・クラスのパフォーマンス目標が満たされると、Oracle Database QoS Managementはhr_pcパフォーマンス・クラスのパフォーマンスを向上させる推奨を作成します。