| Oracle® Database Quality of Service Managementユーザーズ・ガイド 11gリリース2 (11.2) B61036-03 |
|
 前 |
 次 |
この章では、Oracle Database Quality of Service Management(Oracle Database QoS Management)の概要について説明します。この章の内容は次のとおりです。
多くの企業では、データ・センターのコンピュータ・システムを統合し、標準化しています。アプリケーションごとに個別のサーバーを使用するかわりに、クラスタ化したデータベースで複数のアプリケーションを実行します。また、アプリケーションをインターネットに移行することで、オープン・ワークロードの管理の問題が発生しました。オープン・ワークロードにより、完全には予想または計画できない要求のサージを原因とする新しいタイプのアプリケーション障害がもたらされます。このような環境でアプリケーションの可用性とターゲット・サービス・レベルでの実行を維持するには、リソースのプール、パフォーマンス・ボトルネックをリアルタイムで検出する管理ツール、および要求の変化に対応するためのリソースの再割当てが必要です。
Oracle Database QoS Managementは、システム全体のワークロード・リクエストを監視する自動化されたポリシーベースの製品です。Oracle Database QoS Managementは、アプリケーション間で共有されるリソースを管理し、システム構成を調整して、アプリケーションの実行をビジネスに必要なパフォーマンス・レベルに維持します。Oracle Database QoS Managementは、システム構成および要求で発生した変更に対応し、アプリケーションのパフォーマンス・レベルがそれ以上変動することを回避します。
Oracle Database QoS管理は、ターゲット・システムの各作業リクエストのパフォーマンスを監視します。Oracle Database QoS Managementは、作業リクエストがデータベース・サービスを使用してデータベースへの接続をリクエストした時点で作業リクエストの追跡を開始します。作業リクエストの完了に必要な時間、つまりレスポンス時間(エンドツーエンドのレスポンス時間またはラウンドトリップ時間とも呼ばれます)は、データのリクエストが開始された時点からデータ・リクエストが完了した時点までの時間です。レスポンス時間の2つの構成要素、つまりリソースの使用に費やした時間とリソースの使用の待機に費やした時間を正確に測定することで、Oracle Database QoS Managementはシステム内のボトルネックを迅速に検出できます。その後、Oracle Database QoS Managementは、ボトルネックを緩和してサービス・レベルを維持または復元するためのリソースの再割当てを提案します。
Oracle Database QoS Managementは、次の目的でシステムのリソースを管理します。
要求を満たすのに十分なリソースが使用可能な場合は、ワークロードが変化した場合でも、アプリケーションに対するビジネスレベルのパフォーマンス要件が満たされるようにします。
要求を満たすのに十分なリソースが使用可能でない場合、Oracle Database QoS Managementは重要度の低いパフォーマンス要件を犠牲にして、より重要度の高いビジネス・パフォーマンスを満たそうとします。
一般的な企業では、アプリケーションのレスポンス時間が許容レベル内にない場合、問題の解決に非常に時間がかかることがあります。多くの場合、管理者が行う最初の質問は、「システムは正しく構成されているか。パラメータを変更して問題を解決できるか。ハードウェアの追加が必要か」です。残念ながら、これらの質問に正確に回答するのは非常に困難です。その結果、非生産的でフラストレーションの多い実験を長時間にわたって行うことになります。
Oracle Database QoS Managementには次の利点があります。
Oracle Real Application Clusters(Oracle RAC)リソースを管理するシステム管理者の時間と費用の要件が軽減されます。
パフォーマンス低下の回数の削減に役立ちます。
アプリケーションのパフォーマンスを制限または低下させる問題の解決に必要な時間を短縮します。
ワークロードが変化したときでもシステムを安定させます。
サーバーの追加または削除をアプリケーションに対して透過的にします。
サーバー障害がシステムに与える影響を低減します。
サービス・レベル合意(SLA)が満たされるようにします。
ハードウェア・リソースをより効果的に共有できるようにします。
Oracle Database QoS Managementは、クラスタ内のアプリケーションによって共有されるリソースの管理に役立ちます。Oracle Database QoS Managementは、パフォーマンス・ボトルネックの識別と解決を支援できます。Oracle Database QoS Managementは、アプリケーションまたはデータベースのパフォーマンスの問題を診断またはチューニングしません。アプリケーションのパフォーマンスをチューニングする場合、目標は最適なパフォーマンスの実現です。Oracle Database QoS Managementはアプリケーションのより高速な実行を追求するのではなく、アプリケーションが最適なパフォーマンス・レベルで稼働することを妨げる障害を排除します。
ここでは、システムでOracle Database QoS Managementがどのように動作し、ワークロードのパフォーマンスをどのように評価するかについて簡単に説明します。
この項の内容は次のとおりです。
前回のデータベース・リリースでは、特定のワークロード専用のサーバー・グループでサービスを開始することにより、サービスを使用してシステムのワークロードを管理できました。たとえばデータベース層では、あるサーバー・グループをオンライン・トランザクション処理(OLTP)専用にし、別のサーバー・グループをアプリケーション・テスト専用にし、第3のグループを内部アプリケーションに使用できました。システム管理者は、データベース・サービスを実行できるサーバーの数を手動で変更することで、リソースを特定のワークロードに割り当てることができます。あるワークロードの要求のサージ、障害およびその他の問題が他のワークロードに影響することを防ぐためにワークロードは相互に分離されます。このタイプのデプロイメントでは、リソースが共有されないため、各ワークロードをピーク要求に対して個別にプロビジョニングする必要があります。
Oracle Database QoS Managementが実行する基本的な手順は次のとおりです。
QoS管理者が作成したポリシーを使用して次の処理を行います。
受信した作業リクエストの属性(アプリケーションの接続先のデータベース・サービスなど)を使用して各作業リクエストをパフォーマンス・クラスに割り当てます。
各パフォーマンス・クラスの目標レスポンス時間(パフォーマンス目標)を判断します。
ビジネスにとって最も重要なパフォーマンス・クラスを判断します。
すべてのパフォーマンス・クラスのリソース使用率とリソース待機時間を監視します。
パフォーマンス・クラスに対して有効になっているパフォーマンス目標に照らして、そのパフォーマンス・クラスの平均レスポンス時間を分析します。
目標のレスポンス時間を超えているパフォーマンス・クラスのパフォーマンスを向上させるリソース再割当ての推奨を生成し、その推奨が実装された場合に各パフォーマンス・クラスのパフォーマンス・レベルに対して予測される影響を分析します。
Oracle Database QoS Management管理者から指示された場合に、推奨にリストされているアクションを実装し、システムを評価して、リソースの再割当て後に各パフォーマンス・クラスがそのパフォーマンス目標を満たしているかどうかを確認します。
|
注意: デフォルトでは、指定されたどのユーザーもサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するために、CRS管理者リストに特定のユーザーを追加することを強くお薦めします。CRS管理者リストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Database 11gリリース2以降では、サーバー・プールを使用し、クラスタ内にサーバーのグループを作成してワークロードを分離できます。いかなる時点においても、1つのサーバーは1つのサーバー・プールにしか所属できません。データベースは、単一のサーバー・プールで、または複数のサーバー・プールにわたって作成できます。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数)は、サーバー・プール内のデータベースの各インスタンスで均一である必要があります。
インスタンス・ケージングを実装すると、Oracle Database QoS Managementで、あるスライスから同一サーバー・プール内の別のスライスへのCPUリソースの再割当てを提案できます。インスタンス・ケージング設定を変更する推奨を実装する場合、Oracle Database QoS Managementは、サーバー・プールのサーバー上で実行されているすべてのデータベース・インスタンスのCPU_COUNTパラメータを均一に変更します。
CPU_COUNTパラメータを変更して、リソース・プランをアクティブ化するようにOracle Database QoS Managementを構成すると、インスタンス・ケージング機能が有効になります。インスタンス・ケージングを使用してインスタンスのCPU使用率に制約を加えると、そのインスタンスはCPUバウンドになる可能性があります。このとき、リソース・マネージャによって、アクティブなリソース・プランに基づき、様々なデータベース・セッション間でのCPU占有率の割当てが開始されます。
Oracle RACクラスタでは、Oracle Database QoS Managementはデータベース・サービスが提供されているサーバー・プールとノードを監視します。1つのサービスは1つのサーバー・プールでのみ実行できます。データベースが複数のサーバー・プールにわたる場合、すべてのサーバー・プールのインスタンスにアクセスするために、複数のサービスを作成する必要があります。
ワークロードは、Oracle Clusterwareによって管理されているデータベース・サービスを使用してデータベースに接続するクライアントとアプリケーションについて監視されます。接続では、Java Database Connectivity(JDBC)(シックまたはシン)またはOracle Call Interface(OCI)を使用する必要があります。接続では、次のように(Server Control(SRVCTL)および-Bオプションを使用して)ロード・バランシング・アドバイザのランタイム目標がSERVICE_TIMEに設定され、(SRVCTLおよび-jオプションを使用して)接続ロード・バランシング目標がLONGに設定されているサービスを使用する必要があります。
srvctl modify service -d myracdb -s sales_cart -B SERVICE_TIME -j LONG
Oracle Database QoS Managementでは、データベース・サービスを次のオプションで構成する必要があります。
サービスが実行されるサーバー・プールの最大サイズが1より大きい(または無制限)場合、サービスのカーディナリティ(-c)をUNIFORMに設定します。
サービスが実行されるサーバー・プールの最大サイズが1の場合、サービスのカーディナリティ(-c)をSINGLETONに設定します。
Oracle Database QoS Managementの中心となる概念はポリシー・セットです。ポリシー・セットでは、リソース、パフォーマンス・クラス(ワークロード)、および各パフォーマンス・クラスのパフォーマンス目標を指定する1つ以上のパフォーマンス・ポリシーを指定できます。ポリシー・セットでは、リソースの可用性に対する制約も指定できます。Oracle Database QoS Managementで使用されるパフォーマンス・ポリシーは、システム全体で実装されます。これらのポリシーを使用して各パフォーマンス・クラスのリソースの可用性を管理し、パフォーマンス・ポリシーで指定されたパフォーマンス目標が満たされるようにします。
Oracle Database QoS Managementは、Oracle Enterprise Managerを使用して新しいデフォルト・ポリシー・セットが作成されるときに、デフォルトの分類ルールおよび関連するパフォーマンス・クラス名を提供します。たとえば、最初のポリシー・セットが作成されたときに、クラスタ内のすべてのデータベース・サービスが検出されます。これらの各サービスのパフォーマンス・クラスが作成されます。パフォーマンス・クラスの名前は、サービス名に_pcを追加することで指定されます(たとえばsales_pc)。
ポリシー・セット内では一度に1つのパフォーマンス・ポリシーをアクティブにできます。パフォーマンス・ポリシーは、カレンダ・スケジュール、メンテナンス・ウィンドウ、イベントなどに基づいてアクティブにできます。パフォーマンス・ポリシーの詳細は、「パフォーマンス・ポリシーとパフォーマンス目標の概要」を参照してください。
ポリシー・セットを作成する場合は、Oracle Database QoS Managementで管理する必要のあるクラスタ内のサーバー・プールを指定します。(類似するパフォーマンス要件を持つワークロードの分類に使用される)パフォーマンス・クラスも定義します。次に、パフォーマンス・ポリシーを作成して、優先順位が最高のパフォーマンス・クラスと各パフォーマンス・クラスのパフォーマンス目標を指定します。パフォーマンス目標を満たすために、Oracle Database QoS Managementは必要に応じてリソースの再割当てを推奨し、推奨アクションが各パフォーマンス・クラスのパフォーマンス目標を満たす能力に与える影響を予測します。
たとえば、営業時間中のアプリケーション・ワークロードを管理するポリシーを作成できます。顧客が製品またはサービスを購入するために使用するアプリケーションは、この期間中にビジネスに対する優先順位が最も高いアプリケーションです。注文調達および請求アプリケーションにも高い優先順位を指定します。人事およびエンタープライズ・リソース・プランニング(ERP)アプリケーションは、この期間中に優先順位が低いアプリケーションです。オンライン販売アプリケーションで要求のサージが発生する場合は、販売アプリケーションに割り当てるリソースを増やし重要度の低いアプリケーションに割り当てるリソースを減らすことがOracle Database QoS Managementによって推奨されるときに、その推奨には各パフォーマンス・クラスに対するパフォーマンスの変化(プラスまたはマイナス)の予測も含まれます。推奨の詳細は、「推奨の概要」を参照してください。
図1-2に示すポリシー・セットは次の要素から構成されます。
Oracle Database QoS Managementで管理されているサーバー・プール
類似するパフォーマンス目標を持つ作業リクエストのグループであるパフォーマンス・クラス
次のものを使用してリソースをパフォーマンス・クラスに割り当てる方法を記述するパフォーマンス・ポリシー。
ビジネスに対して作成するクラスタ数を決定する場合は、サーバーの統合によって可能になるコストの節約と、統合されたワークロードがある程度有意に相互干渉する危険性とを比較する必要があります。サーバー・プールを導入してクラスタを論理的に分割すると、ワークロードを分離したまま物理的な統合とリソースの機敏性の利点を実現できます。
|
注意: デフォルトでは、指定されたどのユーザーもサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するために、CRS管理者リストに特定のユーザーを追加することを強くお薦めします。CRS管理者リストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
管理者は、図1-3に示すように、様々なサーバー・プールで実行できるワークロードを定義できます。Oracle RACデータベースに接続するアプリケーションは、そのサーバー・プールに現在割り当てられているサーバー上でのみ稼働するサービスを使用します。たとえば、図1-3に示す例について考えると、CSサービスを使用する接続とアプリケーションはHRサーバー・プール内のサーバーにのみアクセスするため、これらの接続によって実行される作業はSalesサービスを使用しているアプリケーションに干渉しません。Oracle Database QoS Managementは、サービス・レベルを満たすためのこれらの各グループ内のリソース割当ての管理、およびビジネス要件の変化に対応するためのリソースの自動的な再配布を支援できます。
図1-3 サーバー・プール、Oracleデータベースおよびデータベース・サービスのダイアグラム
サーバー・プールを使用して、単一エンティティとして管理できるサーバーのグループを作成できます。これらのサーバー・プールで実行するようにデータベースを作成できます。各サーバーがデータベースの単一インスタンスのみを実行する場合、そのデータベースにより多くのリソースが必要な場合は、サーバー・プールに追加のサーバーを割り当てることができます。複数のデータベース・インスタンスが単一のサーバー上で実行されている場合、データベース・インスタンスはそのサーバーの共有リソース(メモリーやCPUなど)を競う必要があります。あるデータベース・インスタンスが他のインスタンスよりもワークロードが大幅に高い場合、そのデータベース・インスタンスによって、同じサーバー上で実行されている他のインスタンスのパフォーマンスが低下することがあります。
インスタンス・ケージングを使用して、Oracleデータベース・インスタンスのCPU使用率を制限できます。CPU_COUNTパラメータを設定して1つのインスタンスが使用できる最大CPU数を制限することで、サーバー上のデータベース・インスタンス間でCPUをパーティション化して、インスタンスがCPUリソースを過剰に使用するのを防ぐことができます。CPU_COUNT設定は、サーバー・プール内のデータベースの各インスタンスで同じである必要があります。Oracle Database QoS Managementは、サーバー・プール内のすべてのデータベース・インスタンスのCPU使用率を監視し、必要に応じて、現在の設定の変更を推奨できます。
複数のサーバー・プールを作成して異なるプール間でリソースを移動するかわりに、1つのサーバー・プールにすべてのサーバーを置かないのはなぜでしょうか。これには次のようないくつかの理由があります。
異なるタイプのワークロードには異なる構成が必要であり、チューニング目標も異なります。たとえば、OLTPアプリケーションを使用して商品またはサービスを購入する顧客は、出荷および支払い情報の画面のレスポンス時間が短いことを期待します。アプリケーションが顧客の注文の処理に要する時間が長すぎると、顧客が興味を失い、会社は販売機会を逸する可能性があります。対照的に、社内HRアプリケーションにアクセスしている従業員は、アプリケーションでオンライン・タスクの完了に予想より長い時間がかかっても、作業を中止する可能性はほとんどありません。
アプリケーションには、1日、1週間または1か月中にビジネス目標を満たすための様々なリソース要件があります。特定の期間のパフォーマンス目標を満たすために、サーバー・プールを使用してアプリケーション・ワークロード間でリソースを分割し、パフォーマンス・ポリシーでサーバー・プールのディレクティブ・オーバーライドを使用してサーバー・プールのデフォルト属性(MaxやMinなど)を変更します。
たとえば、オンライン税務サービスでは、政府が指定する期日までに顧客の税金申告書を準備し、提出する必要があります。提出期限の直前の期間中、税金申告書の準備と提出に関連するアプリケーションはその年の他の期間よりも多くのリソースを必要とします。QuarterlyFilingsという名前のパフォーマンス・ポリシーを作成し、このパフォーマンス・ポリシーがアクティブなときは、追加のワークロードを処理するために税金準備アプリケーションで使用するサーバー・プールに2台ではなく最低4台のサーバーが必要であることを指定できます。QuarterlyFilingsパフォーマンス・ポリシーが有効でないときは、税金準備サーバー・プールに対してサーバー・プールのディレクティブ・オーバーライドは使用されないため、そのサーバー・プール内の最小サーバー数は2です。
ワークロードをホストするサーバー数を調整することで、要求レベルが変化した場合でもアプリケーション・ユーザーのパフォーマンス・レベルが一貫します。これにより、ワークロード・レベルが低から高に変化した場合に顧客のパフォーマンスの期待値がリセットされるのを防ぎます。
たとえば、新しい消費者製品の需要が多く、その製品を割引価格で大量に販売することを企業が広告した場合に、多くの新規顧客がシステムで注文を作成すると、OLTPアプリケーションで処理されるトランザクション数が急激に増加します(要求のサージが発生します)。新製品に関心のない既存の顧客ベースの顧客は、新規顧客の大量流入によって自身のオンライン・ショッピングのエクスペリエンスが影響を受けることを望みません。また、OLTPアプリケーションがすべての受信注文を受け入れることができない場合、新規顧客の一部は別の会社に注文するか、小売店に行くことを決める可能性があります。
Oracle Database QoS Managementでは、使用可能なリソースの再割当てを管理して、他のアプリケーションのサービスのクオリティを低下させずに要求のサージに対応できます。
一部のワークロードは適切にスケーリングできませんが、クラスタ環境の高可用性の利点は享受できます。これらのワークロードを固定サイズのサーバー・プールにデプロイすると、パフォーマンスの管理性と高可用性の両方が実現されます。
たとえば、サーバー数が1に固定されたサーバー・プールでERPアプリケーションを実行できます。これは、サーバー・プールの最大サイズとサーバー・プールの最小サイズが両方とも1に設定されていることを意味します。そのサーバー・プールに割り当てられているサーバーに障害が発生した場合、Oracle Clusterwareはそのサーバー・プールに新しいサーバーを自動的に割り当てて、最小サイズが維持されるようにします。停止したサーバーで実行されていたインスタンスとサービスは、新しいサーバーで開始し、アプリケーションは使用可能なままになります。
|
関連項目:
|
|
注意: デフォルトでは、指定されたどのユーザーもサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するために、CRS管理者リストに特定のユーザーを追加することを強くお薦めします。CRS管理者リストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
クラスタにOracle Grid Infrastructureを初めてインストールするときに、デフォルトのサーバー・プール(空きプール)が作成されます。最初は、すべてのサーバーがこのサーバー・プールに配置されます。管理する必要のあるワークロードに応じて、1つ以上のサーバー・プールを作成する必要があります。新規サーバー・プールを作成する場合、そのサーバー・プールに割り当てるサーバーは空きプールから自動的に移動され、新規に作成されたサーバー・プールに配置されます。この時点で、そのサーバー・プールで実行するデータベースをインストールし、そのデータベースに接続するアプリケーションに対してOracle Clusterwareで管理されるデータベース・サービスを作成できます。
Oracle RACデータベースでサーバー・プールの柔軟性を利用するには、ポリシー管理型デプロイメント・オプションを使用してデータベースを作成する必要があります。これにより、データベースが複数のサーバー・プールに配置されます。アップグレードされたOracleデータベースは管理者管理型データベースに直接変換されるため、ポリシー管理型データベースに別途移行する必要があります。管理者管理型データベースのポリシー管理型データベースへの変更の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。
|
注意: Oracle Database QoS Managementでは、候補サーバー・リストはサポートされません。(server_names属性を使用して)候補サーバー・リストのあるサーバー・プールを作成しないでください。候補サーバー・リストは、Oracleデータベースではなく、サードパーティ・アプリケーションをホストするサーバー・プールで主に使用されます。 |
|
関連項目:
|
前述のように、ポリシー・セットを作成する場合は、クラスタで実行する様々なパフォーマンス・クラス、つまりワークロードのパフォーマンス目標を定義します。作業リクエストが属するパフォーマンス・クラスを特定するために、作業リクエストがクラスタによって最初に検出されたときに、その作業リクエストに対して一連の分類ルールが評価されます。これらのルールにより、値を作業リクエストの属性と照合できます。作業リクエストのタイプとパフォーマンス・クラスに含める基準が一致する場合、作業リクエストはそのパフォーマンス・クラスに分類されます。作業リクエストをパフォーマンス・クラスに割り当てるために使用する基本的な分類子は、データベースへの接続に使用するサービスの名前です。
この項の内容は次のとおりです。
作業リクエストの分類では、作業リクエストが属するパフォーマンス・クラスを識別するユーザー定義の名前(タグ)が適用されます。特定のパフォーマンス・クラスにグループ化されているすべての作業リクエストは、同じパフォーマンス目標を持ちます。事実上、タグは作業リクエストを関連するパフォーマンス・クラスのパフォーマンス目標に結び付けます。タグは各作業リクエストに永続的に割り当てられるため、システムのすべてのコンポーネントが測定を行い、該当するパフォーマンス目標に照らして評価するためのデータをOracle Database QoS Managementに提供できます。
分類は、新しい作業がシステムに入るたびに行われます。作業リクエストがサーバーに到着すると、作業リクエストのタグがチェックされます。作業リクエストにタグがある場合、サーバーはこの作業リクエストがすでに分類されていると判断し、タグは変更されません。作業リクエストにタグが含まれていない場合は、分類子がチェックされ、対応するパフォーマンス・クラスのタグが作業リクエストに付加されます。
作業リクエストの分類方法を示すために、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パフォーマンス・クラスのタグが割り当てられます。
1つのアプリケーションで、一連のパフォーマンス特性を持つ多くのタイプの作業リクエストをサポートできます。デフォルトの分類ルールを拡張および調整することで、Oracle Database QoS Management管理者は1つのアプリケーションに対して複数のパフォーマンス目標を記述できます。たとえば管理者は、Webベースのアプリケーションに、ログイン、参照、検索および購入に関連する作業リクエストごとに異なるパフォーマンス目標が必要であると判断する場合があります。
Oracle Database QoS Managementでは、パフォーマンス・クラスをデータベースで実行されている実際のワークロードにマップするために、接続パラメータのユーザー定義の組合せがサポートされます。これらの接続パラメータは2つの一般クラスに属しており、結合してファイングレイン・ブール式を作成できます。
構成パラメータ: サポートされる構成パラメータはSERVICE_NAMEおよびUSERNAMEです。パフォーマンス・クラスの各分類子では、データベース・サービスの名前を指定する必要があります。クライアントまたは中間層からデータベース接続を行っているユーザーの名前を識別することで、粒度を高めることができます。これらの分類子を使用する利点は、異なるワークロードを別々のパフォーマンス・クラスに関連付けるためにアプリケーション・コードを変更する必要がないことです。
アプリケーション・パラメータ: サポートされるアプリケーション・パラメータはMODULE、ACTIONおよびPROGRAMです。これらはオプションのパラメータです。MODULEとACTIONの値はアプリケーション内で設定する必要があります。アプリケーションのタイプに応じて、これらのパラメータは次のように設定できます。
PROGRAMパラメータは、データベース・ドライバとプラットフォームごとに異なる方法で設定または導出されます。詳細と例については、適切なOracle Database開発者ガイドを参照してください。
|
関連項目:
|
アプリケーションのワークロードを管理するには、アプリケーション・コードで特定のサービスを使用してデータベース接続を行います。アプリケーションの様々な部分で生成されたワークロードをより正確に制御するために、追加のパフォーマンス・クラスを作成し、サービスまたはユーザー名に加えてPROGRAM、MODULEまたはACTIONを含む分類子を使用できます。たとえば、salesサービスを使用するクラスタへのすべての接続がsales_pcパフォーマンス・クラスに属するが、salesサービスを使用していてもユーザー名がAPPADMINの接続はsales_adminパフォーマンス・クラスに属することを指定できます。
特定のデータ・センターで使用するパフォーマンス・クラスは、時間の経過とともに変更されることが予想されます。たとえば、アプリケーションのある部分に対するパフォーマンス目標の変更が必要になることがあります。この場合は、追加の分類子を持つ新しいパフォーマンス・クラスを作成してターゲットの作業リクエストを識別し、パフォーマンス・ポリシーを更新してこのパフォーマンス・クラス用の新しいパフォーマンス目標を追加します。つまり、1つのパフォーマンス目標を1つ以上のよりきめ細かなパフォーマンス目標で置換し、1つのパフォーマンス・クラスの作業リクエストを複数のパフォーマンス・クラスに分割します。
アプリケーション開発者は、使用するパフォーマンス・クラスを推奨できます。具体的には、アプリケーション開発者は異なるアプリケーション・ワークロードを識別する方法を推奨でき、ユーザーはこれらの推奨を使用して、各タイプの作業リクエストが別々に管理されるようにパフォーマンス・クラスの分類子を作成できます。
異なるアプリケーション・ワークロードに対して許容されるレスポンス時間を指定できまるように、追加のパフォーマンス・クラスの作成が必要になることがあります。たとえば、パフォーマンス目標では、sales_pc_checkoutパフォーマンス・クラスのcheckoutアクションを実行している作業リクエストは1ミリ秒以内に完了する必要があり、sales_pc_browseパフォーマンス・クラスのbrowseアクションを実行している作業リクエストは100ミリ秒以内に完了する必要があることを指定できます。
様々なパフォーマンス目標を管理するには、1つ以上のパフォーマンス・ポリシーを定義します。パフォーマンス・ポリシーは、パフォーマンス目標のコレクションであり、ビジネスに対する重要度の基準です。たとえば、通常の営業時間、平日の非営業時間、週末の運用、および四半期決算の処理中に使用するパフォーマンス・ポリシーをそれぞれ定義できます。どの時間についても、Oracle Database QoS Management管理者によって指定された1つのパフォーマンス・ポリシーが有効になります。各パフォーマンス・ポリシーの中で、パフォーマンス目標の重要度(ランキング)を変えて、特定の期間中に特定のワークロードに高い優先順位を与えることができます。
パフォーマンス・ポリシーには、同時に有効になるパフォーマンス目標のコレクションがあります(クラスタ上で実行されているアプリケーションまたはワークロードごとに1つ以上のパフォーマンス目標)。一部のワークロードとそれらのパフォーマンス目標は、他のワークロードとそれらのパフォーマンス目標よりもビジネスにとって重要です。一部のパフォーマンス目標は、特定に期間に重要度が高く、その他の期間には重要度が低い場合があります。
次の各トピックで、パフォーマンス・ポリシーのコンポーネントについて説明します。
各パフォーマンス・クラスのパフォーマンス目標を作成して、各パフォーマンス・クラスに割り当てられているすべての作業リクエストのターゲット・パフォーマンス・レベルを指定します。パフォーマンス目標では、ビジネス要件(ターゲットのパフォーマンス・レベル)とそのパフォーマンス目標が適用される作業(パフォーマンス・クラス)の両方を指定します。たとえば、パフォーマンス目標では、hr_pcパフォーマンス・クラス内の作業リクエストの平均レスポンス時間が0.2秒未満である必要があることを指定できます。
パフォーマンス目標は、パフォーマンス・ポリシーで指定します。パフォーマンス・クラスが「測定のみ」としてマークされていないかぎり、各パフォーマンス・ポリシーには各パフォーマンス・クラスのパフォーマンス目標が含まれます。このリリースのOracle Database QoS Managementでは、平均レスポンス時間という1種類のパフォーマンス目標のみサポートされます。
ワークロードのレスポンス時間はデータベース・クライアント・リクエストに基づきます。レスポンス時間では、ネットワーク上でクラスタがリクエストを受信してからリクエストがクラスタから離れるまでの時間が測定されます。レスポンス時間には、ネットワーク上でのクライアントとの情報の送受信に必要な時間は含まれません。パフォーマンス・クラス内のすべてのデータベース・クライアント・リクエストのレスポンス時間は、1秒間のデータベース・リクエスト数として測定された平均レスポンス時間として平均および提示されます。
パフォーマンス・ポリシーには、サーバー・プールのディレクティブ・オーバーライドのセットを含めることもできます。サーバー・プールのディレクティブ・オーバーライドは、パフォーマンス・ポリシーが有効な場合に、サーバー・プールに「最小」、「最大」および「重要度」の可用性プロパティを設定します。サーバー・プールのディレクティブ・オーバーライドは、パフォーマンス・ポリシーのアクティブ化期間中に有効になるため、Oracle Database QoS Managementが推奨する割当て変更に対する制約として機能します。たとえば、サーバー・プールからサーバーを移動するとサーバー・プールのサーバー数が指定された最小サーバー数よりも少なくなる場合、Oracle Database QoS Managementはサーバー・プールからのサーバーの移動を推奨しません。
図1-5に示すように、システムのパフォーマンス・ポリシーを作成して、1年または1日の中での時間に基づいてワークロードを管理できます。通常の条件下では、これらのパフォーマンス・ポリシーはデータベース・ワークロードの実行を安定した速度に保ちます。データベースのワークロード・リクエストが突然増加した場合は、特定のサーバー・プールにパフォーマンス・ポリシーで指定されているよりも多くのリソースが必要になることがあります。
たとえば、電話で注文を受け、販売アプリケーションを使用して注文を作成するとします。電話セールス部門は通常の営業時間中にのみ応対しますが、顧客はインターネットで注文することもできます。日中は多くの注文が行われるため、販売アプリケーションはワークロードを処理するためにより多くのリソースを必要とします。この構成は、営業時間パフォーマンス・ポリシーを作成してバック・オフィス・サーバー・プールに最大2台のサーバーを配置できることを指定し、Oracle Database QoS Managementが必要に応じてオンライン・サーバー・プールにサーバーを移動できるようにすることで管理されます。電話セールス部門が営業を終了した後は、販売アプリケーションのワークロードが減ります。この構成を管理するには、営業時間後パフォーマンス・ポリシーを作成してバック・オフィス・サーバー・プールに最大4台のサーバーを配置できることを指定し、社内アプリケーションが翌営業日より前にワークロードを完了するのに必要な追加リソースを獲得できるようにします。
このシナリオでは、営業時間パフォーマンス・ポリシーと営業時間後パフォーマンス・ポリシーにサーバー・プールのディレクティブ・オーバーライドが含まれることがあります。パフォーマンス・ポリシーにサーバー・プールのディレクティブ・オーバーライドが含まれる場合、指定したサーバー・プールに対する「最小」、「最大」および「重要度」の現在の設定は、パフォーマンス・ポリシーが有効になっているときにオーバーライドされます。これにより、販売サーバー・プールに追加のサーバーを配置してオンライン販売アプリケーションに必要なリソースを与え、バック・オフィス・サーバー・プールで使用されるリソースを制限して、そのワークロードが販売ワークロードに干渉しないようにすることができます。
パフォーマンス・ポリシー内で、各パフォーマンス・クラスにビジネスの重要度レベル(ランク)を割り当てて、重要度の低いパフォーマンス・クラスよりも重要度の高いパフォーマンス・クラスのパフォーマンス目標を満たすことを優先できます。すべてのパフォーマンス・クラスのすべてのパフォーマンス目標を同時に満たすだけの十分なリソースがない場合は、重要性の低いパフォーマンス目標を犠牲にして、重要性の高いパフォーマンス・クラスのパフォーマンス目標を満たす必要があります。パフォーマンス・ポリシーは、各パフォーマンス・クラスのビジネスの重要度を指定します。これには、最高、高、中、低または最低を指定できます。
たとえば、図1-5に示したパフォーマンス・ポリシーを使用すると、営業時間パフォーマンス・ポリシーが有効なときは、オンライン・サーバー・プールにアクセスする販売アプリケーションが最高ランクを持ちます。すべてのパフォーマンス・クラスのパフォーマンス目標を満たすのに十分なリソースがない場合は、バック・オフィス・サーバー・プールを使用しているアプリケーションがパフォーマンス目標を満たしていない場合でも、オンライン・サーバー・プールを使用するアプリケーションが使用可能なリソースに優先的にアクセスします。
同じランクに複数のパフォーマンス・クラスがあってもかまいません。Oracle Database QoS Managementで、パフォーマンス目標を満たしていない複数のパフォーマンス・クラスが検出され、そのパフォーマンス・クラスにアクティブなパフォーマンス・ポリシー内で同じランクが割り当てられている場合、Oracle Database QoS Managementはパフォーマンス目標の実現に最も近いパフォーマンス・クラスにより多くのリソースを与えるような変更を推奨します。推奨されたアクションが実装された後、パフォーマンス・クラスがターゲットのパフォーマンス・レベル以上になると、Oracle Database QoS Managementはシステム・パフォーマンスの評価を新規に実行します。
Oracle Database QoS Managementサーバーは、管理対象サーバー・プールで実行されている各データベース・インスタンスからメトリック・データを取得します。データは、5秒ごとにパフォーマンス・クラスによって関連付けられます。データには、データベース・リクエスト到着率、CPU使用率、CPU待機時間、I/O使用率、I/O待機時間、グローバル・キャッシュ使用率、グローバル・キャッシュ待機時間など、多くのメトリックが含まれます。クラスタの現在のトポロジとサーバーの状態に関する情報がデータに追加されます。Oracle Database QoS Managementのポリシーおよびパフォーマンス管理エンジン(図1-6に示します)は、データを分析して、アクティブなパフォーマンス・ポリシーによって設定された現在のパフォーマンス目標に関してシステムの全体的なパフォーマンス・プロファイルを判断します。
パフォーマンス評価は1分間に1回実行され、いずれかのパフォーマンス・クラスがその目標を満たしていない場合は推奨が行われます。推奨では、どのリソースがボトルネックであるかが示されます。可能な場合は、推奨に具体的な修正処理が含まれます。推奨には、推奨された処理を実装することに決定した場合にすべてのパフォーマンス・クラスに対して予測される影響のリストも含まれます。
図1-6に、様々なデータ・ソースからのデータの収集のダイアグラムと、Oracle Enterprise Managerでその情報を使用する方法を示します。この図では、CHMはOracle Cluster Health Monitorを示し、Server Manager(SRVM)はOracle Clusterwareのコンポーネントです。
図1-6 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は「アクションは必要ありません。パフォーマンス目標はすべて達成されています」と通知します。
パフォーマンス・クラスのパフォーマンス目標が満たされていない場合、Oracle Database QoS Managementはボトルネックを軽減するためにリソースの使用のリバランスの推奨を発行します。Oracle Database QoS Managementは考えられるいくつかのソリューションを評価して、次のようなソリューションを選択します。
システム全体を最も向上させる
システムの中断を最も少なくする
違反中の最もランクの高いパフォーマンス・クラスをサポートする
Oracle Database QoS Managementは、次のタイプの推奨を行うことができます。
パフォーマンス・クラスのパフォーマンス目標が満たされておらず、パフォーマンス・クラスが他のパフォーマンス・クラスと同じデータベースにアクセスしている場合、Oracle Database QoS Managementはコンシューマ・グループ・マッピングの変更を推奨できます。コンシューマ・グループ・マッピングを変更すると、パフォーマンス目標を満たしていないパフォーマンス・クラスがより多くのCPUリソースにアクセスできるようになります。Oracle Database QoS Managementは、同じデータベースとサーバー・プール内のリソースに対して競合しているパフォーマンス・クラスについてのみコンシューマ・グループ・マッピングの推奨を発行します。
サーバー・プールのサーバーで複数のデータベース・インスタンスが実行されている場合、Oracle Database QoS Managementは、サーバー上のあるスライスでデータベース・インスタンスによって使用されているCPUリソースを、より多くのCPUリソースを必要とするスライスに提供するように推奨できます。パフォーマンス目標を満たしていないパフォーマンス・クラスがあり、システム上に使用可能なヘッドルームのある別のスライスがある場合、またはそのスライスを使用するパフォーマンス・クラスのランクが低い場合、Oracle Database QoS Managementはアイドル・スライスからオーバーロードしているスライスへのCPUの移動を推奨できます。この推奨が実装されると、サーバー・プール内のすべてのサーバーで、アイドル・インスタンスの場合は下方に、オーバーワーク・インスタンスの場合は上方に、CPU_COUNTパラメータが調整されます。
Oracle Database QoS Managementが表示できる別の推奨アクションは、あるサーバー・プールから別のサーバー・プールにサーバーを移動し、パフォーマンス・クラスのパフォーマンス目標を満たすための追加リソースを提供することです。クラスタ内のすべてのサーバー・プールのサイズが指定された最小サイズの場合、またはリソースが必要なサーバー・プールが最大サイズの場合、Oracle Database QoS Managementはサーバー・プールからのサーバーの削除を推奨できません。この場合、ダッシュボードに現在推奨されるアクションはありませんと表示されます。
サーバー・プールの最小サイズは、サーバー・プールに必要なサーバー数です。クラスタ内の各サーバー・プールのサーバー・プール最小値属性に値を追加する場合、この合計とクラスタ内のサーバー総数の差は、要求の変化を満たすためにサーバー・プール間で移動できる共有サーバー(フロート)を表します。たとえば、クラスタに10台のサーバーと2つのサーバー・プールがあり、各サーバー・プールの最小サイズが4の場合、システムには、サーバー・プール間で移動できる2台のサーバーがあることになります。ターゲット・サーバー・プールが最大サイズに達していない場合、これらのサーバーを移動できます。Oracle Database QoS Managementは、サーバーの移動を推奨する場合、常にポリシーで設定されている最小および最大サイズ制約を考慮します。
サーバー・プールの最小サイズをゼロに設定した場合にシステムで要求のサージが発生すると、Oracle Database QoS 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は、ターゲットのパフォーマンス・クラスのレスポンス時間の向上が小さすぎるため、このアクションを推奨しない可能性があります。
推奨の分析データには、図1-7に示すように、各パフォーマンス・クラスのレスポンス時間の予測される変化、各パフォーマンス・クラスのパフォーマンス満足度メトリック(PSM)の予測される変化、および数あるアクションの中でこのアクションが選択される理由が含まれます。この例では、推奨されるアクションを実装した場合、Oracle Database QoS Managementは、ランキングが最高のsales cartパフォーマンス・クラスのレスポンス時間がデータベース・リクエスト当たり0.00510秒から0.00426秒に向上することを予測します。これは、PSMの11.6%向上に相当します。他のパフォーマンス・クラスは別のサーバー・プールを使用するため、変更の影響を受けません。
Oracle Database QoS Managementは、推奨を自動的には実装しません。ただしパフォーマンス・クラスが目標を達成していない期間に基づいて警告を生成するように、EMを構成できます。Oracle Database QoS Management管理者が推奨を実装した後、新しい推奨が行われる前に、指定された設定時間にわたってシステム・パフォーマンスが再評価されます。
オンライン・サーバー・プールに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パフォーマンス・クラスのパフォーマンスを向上させる推奨を作成します。
Oracle Database QoS Managementは、Oracle Real Application Clusters(Oracle RAC)およびOracle Clusterwareと連動します。Oracle Database QoS Managementは、Oracle RACクラスタ全体で稼働し、様々なアプリケーションをサポートできます。
この項の内容は次のとおりです。
Oracle Database QoS Managementは、クラスタのCPUリソースを管理します。Oracle Database QoS ManagementはI/Oリソースを管理しないため、I/O集中型のアプリケーションはOracle Database QoS Managementによって効果的に管理されません。Oracle Database QoS Managementは、サーバーのメモリー使用率も監視し、メモリーがオーバーコミットされている場合はそのサーバーから接続をリダイレクトします。
Oracle Database QoS Managementは、次の手法でOracle RACデータベースと統合され、クラスタ内のリソースを管理します。
Oracle Database QoS Managementは、使用されているすべてのリソースのリソース待機時間を定期的に評価します。パフォーマンス・クラスの作業リクエストの平均レスポンス時間がパフォーマンス目標で指定されている値より大きい場合、Oracle Database QoS Managementは収集されたメトリックを使用してボトルネック・リソースを探します。可能な場合、Oracle Database QoS Managementは、サーバー・プールのサイズを調整するかOracle Database Resource Managerで使用されているリソース・プランのコンシューマ・グループを変更する推奨を提供します。
関連する作業リクエストのグループ化のメカニズムを提供するには、データベース・サービスを作成します。アプリケーションは、データベース・サービスを使用してクラスタ・データベースに接続します。ユーザーがデータベースに対して開始した問合せは、Webベース・アプリケーションとは異なるサービスを使用する場合があります。異なるサービスは、異なるタイプの作業リクエストを表す場合があります。Oracle RACデータベースに対して行われた各コールまたはリクエストが作業リクエストです。
データベース・サービスを使用して、データベース・ワークロードを管理および測定することもできます。サービスで使用されるリソースを管理するために、一部のサービスは複数のOracle RACインスタンスに同時にデプロイできますが、その他のサービスはサービスを使用するワークロードを分離するために単一のインスタンスにのみデプロイできます。
Oracle RACクラスタでは、Oracle Database QoS Managementはデータベース・サービスが提供されているサーバー・プールとそのノードを監視します。サービスは、データベース管理者がデータベースに対して作成します。ポリシー管理型データベースでは、サービスは指定されたサーバー・プールのすべてのサーバーで実行されます。アプリケーションを水平にスケーリングできないためシングルトン・サービスが必要な場合は、最小サイズと最大サイズが1のサーバー・プールで実行するようにサービスを制限できます。
Oracle Database QoS Managementを使用するには、サーバー・プールで実行される1つ以上のポリシー管理型データベースを作成する必要があります。Oracle Database QoS Managementを初めて構成する場合、監視されているサーバー・プールに検出されたサービスごとにデフォルトのパフォーマンス・ポリシーが作成されます。これらのデフォルト・パフォーマンス・クラスの名前はservice_name_pcです。リソースを監視および管理するワークロードでは、データベース・サービスを使用してデータベースに接続する必要があります。
|
関連項目: サービスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Database Resource Manager(リソース・マネージャ)は、リソース割当てメカニズムの例です。リソース・マネージャは、管理者が指定したリソース・プランに基づいて、リソース・コンシューマ・グループのコレクション間にCPU占有率を割り当てることができます。リソース・プランは、CPUで実行する機会のパーセンテージを割り当てます。
Oracle Database QoS Managementは、既存のリソース・マネージャ・プランは調整しません。Oracle Database QoS Managementは、複雑なマルチレベルのリソース・プランであるAPPQOS_PLANというリソース・プランをアクティブ化します。Oracle Database QoS Managementは、パフォーマンス・クラスであるコンシューマ・グループおよび各コンシューマ・グループのリソース・プラン・ディレクティブも作成します。
Oracle Database QoS Managementの推奨を実装してパフォーマンス・クラスのコンシューマ・グループをプロモートまたは降格する場合、Oracle Database QoS Managementは、APPQOS_PLANリソース・プランで指定されたCPU占有率へのパフォーマンス・クラスのマッピングに推奨された変更を加えます。コンシューマ・グループを変更することで、現在パフォーマンス目標を満たしていないパフォーマンス・クラスがアクセスできるCPUリソースが増やされます。
デフォルトでは、APPQOS_PLANはOracle Schedulerのメンテナンス・ウィンドウ中に置換されます。APPQOS_PLANリソース・プランにはDEFAULT_MAINTENANCE_PLANプランのコンシューマ・グループが組み込まれているため、これらの毎日のウィンドウ中はこのリソース・プランを使用することをお薦めします。SQL*Plusで次のコマンドを実行することにより、APPQOS_PLANを強制的に使用できます。
BEGIN DBMS_SCHEDULER.DISABLE(name=>'"SYS"."MONDAY_WINDOW"'); END; / BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE(name=>'"SYS"."MONDAY_WINDOW"', attribute=>'RESOURCE_PLAN',value=>'APPQOS_PLAN'); END; / BEGIN DBMS_SCHEDULER.ENABLE(name=>'"SYS"."MONDAY_WINDOW"'); END; /
TUESDAY_WINDOWのように、曜日ごとにこれらのコマンドを繰り返します。
|
注意: デフォルトでは、指定されたどのユーザーもサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するために、CRS管理者リストに特定のユーザーを追加することを強くお薦めします。CRS管理者リストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Database QoS Managementを使用する前に、Oracle Clusterwareをインストールして構成する必要があります。CRS管理者は、ポリシー管理型Oracle RACデータベースで使用するサーバー・プールを作成する必要があります。
Oracle Database QoS Managementを初めて構成し、初期ポリシー・セットを作成するときに、Oracle Database QoS Managementで管理する必要のあるサーバー・プールと監視のみ必要なサーバー・プールを指定します。Oracle Database QoS Managementで管理するサーバー・プールを選択した場合、Oracle Database QoS Managementは、そのサーバー・プールで実行するすべてのパフォーマンス・クラスで使用されるリソースを監視します。パフォーマンス・クラスがパフォーマンス目標を満たしていない場合、Oracle Database QoS Managementは、必要に応じて追加リソースを提供するためにサーバー・プール間でのサーバーの移動を推奨できます。
Oracle Database QoS Managementでは、Oracle Cluster Health Monitor(CHM)を使用してクラスタ内のサーバーのメモリー・メトリック・データを収集します。
|
関連項目: ポリシー管理型データベースとサーバー・プールの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
ランタイム接続ロード・バランシングでは、アプリケーションが作業を完了するために接続をリクエストしたときに、Oracleクライアントが接続プール内の接続をインテリジェントに割り当てることができます。新しい接続のルーティング先インスタンスの決定は、データベース・インスタンスが提供する現在のパフォーマンス・レベルに基づいて行われます。
Oracle Database QoS Managementで管理されているリソースを使用するアプリケーションでは、接続ロード・バランシングと透過アプリケーション・フェイルオーバー(TAF)も利用できます。接続ロード・バランシングにより、サービスをサポートしているすべてのインスタンスにユーザー接続を分散できます。サービスごとに、-jオプションを指定した適切なSRVCTLコマンドを使用して接続ロード・バランシングの目標を設定することで、リスナーがロード・バランシングに使用する方法を定義できます。-m(フェイルオーバー・メソッド)、-e(フェイルオーバー・タイプ)などのオプションを指定したSRVCTLを使用して、サービスのすべてのユーザーに対して単一のTAFポリシーを指定することもできます。
|
関連項目:
|
オープン・セッションまたはランナウェイ・ワークロードが多すぎるため、エンタープライズ・データベース・サーバーが使用可能メモリーをすべて使用することがあります。メモリーが不足すると、トランザクションが失敗することがあります。極端な場合には、サーバーが再起動し、アプリケーションの貴重なリソースが失われることもあります。Oracle Database QoS Managementは、サーバー上のメモリー不足をリアルタイムで検出し、新しいセッションを他のサーバーにリダイレクトして、メモリーが不足しているサーバー上のすべての使用可能メモリーが使用されることを防ぎます。
Oracle Database QoS Managementが有効になっていて、Oracle Clusterwareサーバー・プールを管理している場合、Cluster Health Monitorは、クラスタ・サーバーのメモリー・リソースに関するリアルタイム情報を提供するメトリック・ストリームをOracle Database QoS Managementに送信します。この情報の内容は次のとおりです。
使用可能メモリーの量
現在使用されているメモリーの量
各サーバーでディスクにスワップされているメモリーの量
ノードのメモリーが不足しているとOracle Database QoS Managementが判断した場合は、新しい接続が作成されないように、そのノード上のOracle Clusterwareで管理されているデータベース・サービスが停止されます。メモリー不足が緩和されると、そのノードのサービスが自動的に再開し、リスナーはそのサーバーへの新規接続の送信を開始します。メモリー不足は、いくつかの方法で緩和できます(たとえば、既存のセッションの終了やユーザーの介入など)。
新しいセッションを別のサーバーにリルートすると、メモリーが不足しているサーバー上の既存のワークロードが保護され、サーバーを使用可能な状態に保つことができます。サーバーのメモリー不足の管理によって、Oracle RACデータベースにホストされているアプリケーションのサービス・レベルの管理に新しいリソース保護機能が追加されます。
パフォーマンス管理と高可用性管理システムは密接に関連しています。通常、ユーザーはパフォーマンスが許容される場合にのみシステムが稼働している(使用可能である)とみなします。Oracle Database QoS Managementとパフォーマンス目標を使用して、許容されるパフォーマンス・レベルを指定および維持できます。
Oracle Database QoS Managementは、システムが動的ワークロード条件下でサービス・レベル合意を満たせるようにリソース割当てを最適化するランタイム・パフォーマンス管理製品です。Oracle Database QoS Managementは、ビジネスにとって最も重要な作業が必要なリソースを取得できるようにするための推奨を提供します。Oracle Database QoS Managementは、現在の要求とリソースの可用性に基づいてリソース割当てのリバランスを支援します。ビジネスにとって重要な作業が正常に完了するように、重要でない作業は抑止されます。
Oracle Database QoS Managementは、パフォーマンスを向上させるための機能ではありません。Oracle Database QoS Managementの目的は、最適なパフォーマンス・レベルを維持することです。Oracle Database QoS Managementは、パフォーマンスと可用性の両方に影響するシステム・パラメータが適切に設定され、それらが一定であることを前提としています。たとえば、FAST_START_MTTR_TARGETデータベース・パラメータは、データベースがredoログ・データをディスクに書き込む頻度を制御します。このパラメータに低い値を使用すると、データベースのリカバリに要する時間が短縮されますが、redoログ・データを頻繁に書き込むオーバーヘッドがデータベースのパフォーマンスに悪影響を及ぼす可能性があります。Oracle Database QoS Managementは、このようなパラメータに指定された値については推奨を行いません。
高可用性の管理には、ワークロードに関連せず、ワークロードの管理の影響を受けない問題が数多く含まれます。たとえば、システムの可用性は、ソフトウェア・アップグレード・イベントの頻度と期間に大きく依存します。システムの可用性は、ハードウェア障害の頻度にも直接依存します。ワークロードの管理では、ソフトウェア・アップグレードの頻度やハードウェア障害の頻度を変更できません。
|
関連項目:
|
Oracle Database QoS Managementは、作業リクエストがリソースの待機に費やす時間の長さの観察データに基づいて決定を行います。作業リクエストが待機するリソースの例として、CPUサイクル、ディスクI/Oキュー、グローバル・キャッシュ・ブロックなどのハードウェア・リソースがあります。ラッチ、ロック、ピンなど、データベース内で発生する待機もあります。データベース内でのリソース待機はOracle Database QoS Managementメトリックで考慮されますが、タイプ別には管理または指定されません。
作業リクエストのレスポンス時間は、実行時間と様々な待機時間で構成されます。実行時間を変更または改善するには、一般にアプリケーション・ソース・コードの変更が必要です。このため、Oracle Database QoS Managementでは待機時間のみを監視および管理します。
Oracle Database QoS Managementは、システム内のすべてのサーバーによって収集される標準化されたメトリックのセットを使用します。作業リクエストのレスポンス時間の測定に使用されるメトリックには、パフォーマンス・メトリックとリソース・メトリックの2種類があります。作業リクエストはシステムを構成するサーバー、ネットワークおよびストレージ・デバイスを通過するため、これらのメトリックにより、各パフォーマンス・クラスの作業リクエストで発生する待機時間を、リクエストされたリソースごとに直接観察できます。別のタイプのメトリックであるパフォーマンス満足度メトリックは、パフォーマンス・クラスのパフォーマンス目標がどの程度満たされているかを測定します。
パフォーマンス・メトリックは、システムの各サーバーへのエントリ・ポイントで収集されます。システムのどこで時間が費やされているかの概要を示し、システム全体で待機時間を比較できます。データは定期的に収集され、分析、意思決定および履歴格納のために中央ポイントに転送されます。システム・データの収集方法の図は、図1-6「Oracle Database QoS Managementサーバー・アーキテクチャのダイアグラム」を参照してください。
パフォーマンス・メトリックは、レスポンス時間(リクエストを受信した時刻とレスポンスを送信した時刻の差)を測定します。パフォーマンス・クラス内のすべてのデータベース・クライアント・リクエストのレスポンス時間は、1秒当たりのデータベース・リクエスト数として測定された平均レスポンス時間として平均および提示されます。
システムの各対象リソースには2つのリソース・メトリックがあります。
リソース使用時間: 各作業リクエストでリソースの使用に費やした時間を測定します。
リソース待機時間: リソース取得の待機に費やした時間を測定します。
リソースは、CPU、ストレージI/O、グローバル・キャッシュおよびその他(データベース待機)に分類されます。データは、Oracle RACデータベース、Oracle Clusterwareおよびオペレーティング・システムから収集されます。
ワークロード・パフォーマンスの分析に役立つメトリックは、パフォーマンス・クラスの作業リクエストがそのパフォーマンス・クラスの現在のパフォーマンス目標をどの程度満たしているかに関する共通および一貫した数値メジャーです。この数値メジャーをパフォーマンス満足度メトリックと呼びます。
次の表に示すように、様々なパフォーマンス目標を使用してワークロードのパフォーマンスを測定します。
| ワークロード・タイプ | パフォーマンス目標 |
|---|---|
| OLTP | レスポンス時間、1秒当たりのトランザクション |
| バッチ | 速度、スループット |
| DSS | 読取りまたはキャッシュ・ヒット率、期間、スループット |
現在、Oracle Database QoS ManagementではOLTPワークロードのみサポートされます。OLTPワークロードについては、レスポンス時間パフォーマンス目標のみ構成できます。
Oracle Database QoS Managementメトリックは、システムのパフォーマンス・クラス・ボトルネックをシステムで識別するために必要な情報を提供します。パフォーマンス・クラスがそのパフォーマンス目標に違反している場合、そのパフォーマンス・クラスのボトルネックは、そのパフォーマンス・クラスの各作業リクエストの最大平均待機時間に寄与するリソースです。
Oracle Database QoS Managementメトリックを使用して、次の手順でパフォーマンス・クラスのボトルネックを探します。
Oracle Database QoS Managementは、パフォーマンス目標を満たしていない、最もランクの高いパフォーマンス・クラスを選択します。
そのパフォーマンス・クラスについて、収集されたメトリックから各リソースの待機時間が判断されます。
リクエスト当たりの待機時間が最も長いリソースが、ボトルネック・リソースとして判断されます。
各データベース・リクエストの平気待機時間と各パフォーマンス・クラスの合計リクエスト数を分析すると、各パフォーマンス・クラスのレスポンス時間のリソース待機時間コンポーネントが提供されます。このような貢献度が最大のリソース(CPU、ストレージI/O、グローバル・キャッシュまたはその他)がパフォーマンス・クラスの現在のボトルネックです。
