| 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 Managementを使用するための構成要件について説明します。
Oracle Database QoS Managementでは、クラスタとデータベースがサーバー・プールを使用する必要があります。汎用プール内のデータベースはOracle Database QoS Managementで管理できず、ユーザー・インタフェースに表示されません。空きプール内のサーバーを使用して、管理対象サーバー・プールにリソースを追加できます。
|
注意: デフォルトでは、指定されたどのユーザーもサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するために、CRS管理者リストに特定のユーザーを追加することを強くお薦めします。CRS管理者リストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
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はそのサーバー・プールからサーバーを削除して、より優先度の高いワークロードにリソースを提供できます。この場合は、サーバー・プールにOracle Database QoS Managementで管理するリソースがなくても、そのサーバー・プールで実行されているワークロードは引き続き監視され、可能な場合にはワークロードをサポートするためにそのサーバー・プールにリソースが割り当てられます。
Oracle Database QoS Managementは、リリース11.2.0.2以降のOracle RACデータベースとのみ連動します。データベースは、サーバー・プールで実行されるポリシー管理型データベースとして構成する必要があります。データベース・インスタンスによって使用される基礎となるサーバー・プールは、Oracle Database QoS Managementで管理されるものとしてマークする必要があります。
データベース・サービスはUNIFORMサービスとして作成する必要があります。これは、指定されたサーバー・プールで実行されている使用可能なすべてのインスタンスによって、サービスが提供されることを意味します。アプリケーションにSINGLETONサービスが必要な場合、Oracle Database QoS Managementを使用するには、最大サイズが1のサーバー・プールでサービスが実行されている必要があります。最大サイズが1より大きいサーバー・プールでSINGLETONサービスを使用すると、Oracle Database QoS Managementは構成違反をレポートします。
Oracle Database QoS Managementでは、サーバー・プールを共有する複数のデータベースがサポートされます。同じサーバー・プールを使用している複数のデータベースがある場合は、サーバー・プールを使用するすべてのデータベースでOracle Database QoS Managementが有効になっている必要があります。Oracle Database QoS ManagementではOracle RAC One Nodeデータベース(シングルトン・データベースとも呼ばれます)もサポートされますが、これらのデータベースでは最大サイズが1のサーバー・プールを使用する必要があります。
データベースを作成する場合、データベース・インスタンスのCPU_COUNT初期化パラメータのデフォルト値は、インスタンスが実行されている各ノード上の物理的なCPUの数に設定されます。同じノードに複数のデータベース・インスタンスがある場合は、各インスタンスのCPU_COUNTの値を調整して、ノードで実行されている各インスタンスのCPU_COUNTの合計が、そのノード上の物理的なCPUの数以下になるようにする必要があります。また、CPU_COUNTの値はデータベースのすべてのインスタンスに対して同じである必要があります。たとえば、両方のインスタンスが同じサーバー・プールにある場合、salesデータベースで、sales1インスタンスに対してCPU_COUNTを4に設定し、sales2インスタンスに対してCPU_COUNTを2に設定することはできません。
Oracle Database QoS Managementには、Oracle Clusterwareで管理されているデータベース・サービスが必要です。Oracle Database QoS Managementで管理されているすべてのワークロードは、Oracle Clusterwareで管理されているデータベース・サービスを使用してデータベースに接続する必要があります。デフォルトのデータベース・サービスは使用できません。デフォルトのデータベース・サービスは、Oracle Clusterwareで管理されていません。
データベースへの接続に使用されるサービスはUNIFORMである必要があります。アプリケーションにSINGLETONサービスが必要な場合、Oracle Database QoS Managementを使用するには、最大サイズが1のサーバー・プールでサービスが実行されている必要があります。
Oracle RAC高可用性フレームワークは、データベースとそのサービスを監視し、高速アプリケーション通知(FAN)を使用してイベント通知を送信します。Oracle ClusterwareとOracle Net Servicesは、サービス構成で指定されたルールに従ってサービスのロード・バランシングを行います。これらのルールは次のとおりです。
接続ロード・バランシングの目標: インスタンスの現在のワークロードと接続のタイプ(LONGまたはSHORT)を使用して接続がインスタンスにルーティングされ、最高のパフォーマンスを実現できるインスタンスが判断されます。Oracle Database QoS Managementでは、新規サーバーがサービスのサーバー・プールに割り当てられている場合に新規接続が新規サーバーにより高速に移行するように、接続ロード・バランシングの目標をLONGに設定する必要があります。接続を新規サーバーにより迅速に移行することで、ワークロードは使用可能なすべてのインスタンスにより高速に分散され、ワークロードのレスポンス時間がより高速に向上します。
ランタイム接続ロード・バランシングの目標: ロード・バランシング・アドバイザ・データを使用して、サービスに対して指定されている目標を最もよく満たしているインスタンスが判断されます。2つの目標は、SERVICE_TIME(ロード・バランシング・アドバイザ・データはインスタンス内で行われた作業の経過時間に基づきます)とTHROUGHPUT(ロード・バランシング・アドバイザ・データはインスタンス内で作業が完了する速度に基づきます)です。Oracle Database QoS Managementでは、オプションで最大サイズが1のサーバー・プールを除き、サーバー・プールを使用するすべてのデータベース・サービスに対してランタイム接続ロード・バランシングの目標をSERVICE_TIMEに設定する必要があります。
ランタイム接続のロード・バランシングは、Oracle RACデータベース内のインスタンス間で接続リクエストのバランスをとる方法について接続プールにアドバイスを送信します。ロード・バランシング・アドバイザは、受信した作業に対して最適なサービス・クオリティを提供するインスタンスにその作業を転送する方法についてのアドバイスも提供します。これにより、後で作業を再配置する必要性が最小化されます。
サービスのロード・バランシング目標を構成するには、次の例で示すServer Control(SRVCTL)ユーティリティまたはEnterprise Managerを使用します。
srvctl modify service -d db_name -s service_name -B SERVICE_TIME -j LONG
Oracle Database QoS Managementの初期リリースでは、オンライン・トランザクション処理(OLTP)ワークロードのみサポートされます。サポートされるパフォーマンス目標は、データベース・リクエストの平均レスポンス時間のみです。Oracle Database QoS Managementは、オープン・ワークロード、つまり要求がレスポンス時間に依存しないワークロードを管理するように設計されています。
アプリケーション・ワークロードのデータベース・リクエストは、平均レスポンス時間が1秒未満である必要があり、平均時間が0.5秒未満であることが理想です。パフォーマンス・クラス内の各データベース・リクエストは、リソース使用率が同質である必要があります。ワークロードのデータベース・リクエストのサブセットが他のリクエストよりも非常に多くのリソースを使用する場合、新しいパフォーマンス・クラスを作成して、より多くのリソースを必要とするデータベース・リクエストを含める必要があります。「新規パフォーマンス・クラスの作成の決定」を参照してください。
Oracle Database QoS Managementでは、パラレル問合せを含むワークロードはサポートされません。デフォルトでは、パラレル問合せは、データベースへの接続に使用されたサービスに関係なく、データベースのすべての使用可能インスタンスで実行されます。そのため、ワークロードは含まれていないか、サービスを提供するインスタンスのみでの実行に制限されます。同様の理由で、Oracle Database QoS Managementでは、GV$ビューへの問合せを伴う大量のデータベース・リクエストを含むワークロードはサポートされません。
Oracle Database QoS Managementで管理されるワークロードでは、データベース接続にOracle Clusterwareで管理されているデータベース・サービスを使用する必要があります。接続を開始するクライアントまたはアプリケーションは、JDBC(シックまたはシン)クライアント、つまりOCIクライアントである必要があります。データベースへのbequeath接続を使用するワークロードは、Oracle Database QoS Managementで管理されません。
現在、Oracle Database QoS Managementで管理されるワークロードはOLTPデータベース・ワークロードのみです。データベースのワークロードを管理するには、受信作業リクエストがパフォーマンス・クラスに割り当てられる必要があります。ワークロードは分類子を使用してパフォーマンス・クラスにマップされます。
複数層環境では、クライアントからのリクエストが中間層またはロード・バランシングによって様々なデータベース・セッションにルーティングされるため、データベース・セッション間でのクライアントの追跡が難しくなります。分類子は、セッション属性を使用して作業リクエストを識別します。使用される属性は、サービス名、ユーザー名、モジュール・アクションおよびプログラムです。「作業リクエストを分類するための追加フィルタの使用方法」を参照してください。
各分類子では1つ以上のサービス名を指定する必要があります。分類子で複数のサービス名が指定されている場合、接続データをパフォーマンス・クラスと照合するときに、サービス名がOR演算子を使用して評価されます。このため、分類子で指定されているサービス名の1つが作業リクエストのサービス名と一致した場合に、比較がTRUEと評価されます。
MODULEおよびACTION属性を設定するには、OCIAttrSet()コールを使用します。アプリケーション・コンテキストには、デフォルトのネームスペースであるUSERENVを使用します。
オプションで、分類子にUserNameおよびプログラム名を含めることもできます。ユーザー名は、セッションが接続するデータベース・ユーザーの名前です。プログラム属性は、サーバーへのログインに使用したクライアント・プログラムの名前です。
パフォーマンス・クラスの分類子に複数の属性が指定されている場合、セッション属性はAND演算を使用して結合されます。このため、分類子で指定されているすべての属性値が作業リクエストのセッション属性値と一致した場合は、比較がTRUEと評価されます。類似する属性値を使用する分類子が複数ある場合は、最もきめ細かい条件を持つ分類子を先頭に配置します。「作業リクエストへの分類子の適用」を参照してください。
たとえば、次の分類子について考えます。
sales_cartサービス、ORDERモジュールおよびCALCULATE TAXアクションを指定するcreate_invoice_taxes_pc
sales_cartサービスおよびORDERモジュールを指定するcreate_invoice_pc
create_invoice_taxes_pc分類子は、create_invoice_pc分類子より前に評価する必要があります。作業リクエストがsales_cartサービスを使用し、ORDERモジュールのCALCULATE TAXアクションを実行している場合、この作業リクエストはcreate_invoice_taxes_pcに割り当てられます。作業リクエストのすべての属性について一致する値がない場合、作業リクエストは次の分類子であるcreate_invoice_pcと比較されます。create_invoice_pc分類子を最初に評価した場合は、作業リクエストが実行するアクションに関係なく、sales_cartサービスとORDERモジュールを使用するすべての作業リクエストがcreate_invoice_pcパフォーマンス・クラスに割り当てられます。
1つのクラスタに対して最大47個のパフォーマンス・クラスを作成できます。クラスタに47を超えるサービスがある場合は、分類子内で複数のサービス名を使用します。分類子に対して一致が見つかると、Oracle Database QoS Managementは一致する作業リクエストにタグを割り当てます。タグは、TRUEに評価される分類子に基づきます。「パフォーマンス・クラス・タグ」を参照してください。
ここでは、Oracle Database QoS Managementによって管理されるシステムの構成の主要な推奨と要件について説明します。この項の内容は次のとおりです。
Oracle Database QoS Managementは、CPU、グローバル・キャッシュ、I/Oおよびその他のリソースの使用時間と待機時間を測定して、ボトルネックの場所を判断します。ターゲットのパフォーマンス・クラスとそのボトルネック・リソースはOracle Database QoS Managementダッシュボード(ダッシュボード)で識別されますが、このリリースでアクティブに管理されるのはCPUリソースのみです。次の各項では、Oracle Database QoS Managementが各リソース・タイプのボトルネックに対応する方法と、推奨される構成方針について説明します。
CPUリソース・ボトルネックは、ワークロードを実行しているCPUキューのコレクションでの待機時間が過剰な場合に検出されます。Oracle Database QoS Managementは、ボトルネックを緩和するために実装できる推奨を提供します。
このタイプのボトルネックを解決する1つの方法は、ワークロードをCPUで実行する機会を増やすことです。Oracle Database QoS Managementは、サーバー・プール間でCPU占有率の高いコンシューマ・グループにワークロードを割り当てることで、この解決策を実装します。
もう1つの解決策は、提供するCPUリソースを増やすことです。サーバー・プールの各サーバーで複数のインスタンスがCPUリソースを共有していて、インスタンス・ケージングが実装されている場合、Oracle Database QoS Managementはサーバー・プール内のインスタンスのCPU数の変更を提案できます。この解決策では、ランクの低いインスタンスまたはヘッドルームのあるインスタンスからCPUリソースを奪ってリソースを増やし、パフォーマンスの期待値に達していないワークロードにより多くのCPUリソースを与えます。
インスタンス間のCPU数を調整することで緩和できないCPUリソース・ボトルネックがある場合、Oracle Database QoS Managementは新しいサーバーをサーバー・プールに移動することを推奨できます。空きプール、よりストレスの少ないサーバー・プール、または重要度の低いワークロードをホストしているサーバー・プールからサーバーを移動できます。
グローバル・キャッシュ・リソース・ボトルネックは、データベース・インスタンス間でのデータ・ブロックの移動が過剰な場合に検出されます。これは通常、正しく構成されていないか水平にスケーリングできないアプリケーションが原因で発生します。アプリケーションを最大サイズが1のサーバー・プールで実行するように構成するかデータをパーティション化すると、通常はボトルネックが緩和されます。
Oracle Database QoS Managementは、このリリースではどちらのアクションも実行できず、このタイプのボトルネックに対して実装できる推奨を提供しません。
I/O リソース・ボトルネックは、ストレージ・サブシステムでの待機時間が過剰な場合に検出されます。このタイプのボトルネックは、通常はディスク・スピンドルが少なすぎるか、ストレージ相互接続上のネットワーク帯域幅が十分でないことが原因で発生します。このボトルネックを解決するには、より多くのディスクにデータベース・ファイルを分散するか、別のネットワーク・インタフェース・カード(NIC)をストレージ相互接続専用に構成します。
Oracle Database QoS Managementは、このリリースではこのタイプのボトルネックを解決できず、実装できる推奨を提供しません。
ボトルネックの分類に使用される最後のリソース・タイプ「その他」は、他のすべての待機時間に使用されます。これらのデータベース待機時間は、通常、最適化されていないアプリケーションやラッチの待機などによるSQLパフォーマンスの問題が原因です。これらのボトルネックは、自動ワークロード・リポジトリ(AWR)や自動データベース診断モニター(ADDM)などのOracle Databaseチューニング・ツールを使用して調査できます。
これらのタイプのボトルネックの解決は、Oracle Database QoS Managementで提供されるランタイム・システム管理の範囲外であり、Oracle Database QoS Managementは実装できる推奨を提供しません。
ここでは、Oracle Database QoS Managementの実装例について説明します。Oracle Database QoS Managementがパフォーマンスを管理するプロセスについて説明します。この項の内容は次のとおりです。
実装例では、Linux上で実行されている4ノード・クラスタを使用します。ノードの名前はtest_rac1からtest_rac4までです。通常の操作では、各ノードは次の処理を行います。
| ノード | 目的 | サービス |
|---|---|---|
| test_rac1 | クラスタ用Oracle Grid Infrastructureとbackofficeデータベースの最初のデータベース・インスタンスを実行します。 |
HRおよびERP |
| test_rac2 | クラスタ用Oracle Grid Infrastructureとbackofficeデータベースの2つ目のデータベース・インスタンスを実行します。 |
HRおよびERP |
| test_rac3 | クラスタ用Oracle Grid Infrastructureとonlineデータベースの最初のデータベース・インスタンスを実行します。 |
SalesおよびSales_Cart |
| test_rac4 | クラスタ用Oracle Grid Infrastructureとonlineデータベースの2つ目のデータベース・インスタンスを実行します。 |
SalesおよびSales_Cart |
クラスタは、次の制約のある2つのサーバー・プールに論理的に分割されます。
| 名前 | 最小サイズ | 最大サイズ | 現行サイズ | 重要度 |
|---|---|---|---|---|
| バックオフィス | 1 | -1 | 2 | 1 |
| オンライン | 1 | -1 | 2 | 2 |
| 空き | 0 | -1 | 0 | 0 |
ここで示すサーバー・プール制約は、少なくとも1台のサーバーが各サーバー・プール(およびそれらのサーバー・プールで実行されるデータベース)に割り当てられ、残りのサーバーはサービス・レベルを管理するためにオンデマンドで共有できることを保証します。onlineサーバー・プールは、「重要度」の値が最高であるため、最もクリティカルなワークロードをホストします。サーバー障害が発生した場合、onlineサーバー・プールの最小サイズの維持が、他のサーバー・プールの最小サイズの維持よりも優先されます。
このリリースのOracle Database QoS Managementは、OLTPワークロードの管理に重点を置いています。このタイプは、オープン・ワークロード(システム・パフォーマンスが低下した場合でも要求が一定のワークロード)が発生する可能性が最も高く、ワークロードの急増による停止に対して脆弱です。このデモでは、同じクラスタでホストされている内部ワークロードと外部ワークロードの組合せがあり、リソースを共有できることを想定しています。
このデモ・システムには、図2-1に示すように4種類のワークロードがあります。
ERPサービスを使用してbackofficeサーバー・プールのデータベース・インスタンスに接続するJ2EEに基づくERPアプリケーション
HRサービスを使用してbackofficeサーバー・プールのデータベース・インスタンスに接続するOracle C Interface(OCI)に基づく内部HRアプリケーション
Salesサービスを使用してonlineサーバー・プールのデータベース・インスタンスに接続するJ2EEに基づく外部Salesアプリケーション
Salesサービスを使用してonlineサーバー・プールの特定のデータベース・ユーザーを介してデータベース・インスタンスに接続するJ2EEに基づく外部販売チェックアウト・アプリケーション(Sales Cart)
2つのサーバー・プールを使用することで、ワークロードとそれらの依存データベースは論理的に分離されますが、それらの間でリソースを簡単に共有できます。
最初、このシステムにはOracle Database QoS Managementが構成されていません。Oracle Enterprise Manager Database Controlを使用して、クラスタに対してOracle Database QoS Managementを有効にするために完了する2つの構成ワークフローがあります。最初のワークフローでは各データベースをOracle Database QoS Management用に構成し、2つ目のワークフローではクラスタに対してOracle Database QoS Managementを構成および有効化します。
デフォルトのポリシー・セットを作成した後で、自動的に検出されるデータベース・サービスを使用して、Oracle Database QoS Managementを微調整してそれぞれのサービス・レベル合意または目標にワークロードを合せることができます。
ここでは、Oracle Database QoS Managementの実装例をさらに進化させて、パフォーマンス・ポリシーの作成とアクティブ化、および追加のパフォーマンス・クラスでの調整を含めます。
測定のみモードでデータベース・サービスを検出することでデフォルトのパフォーマンス・ポリシーが作成されるため、最初にデフォルトのパフォーマンス・ポリシーをアクティブにし、クラスタ内ですべてのワークロードがどのように実行されるかをテストできます。ダッシュボードには、様々な要求期間中の各パフォーマンス・クラスの平均レスポンス時間を構成するリソースの使用時間と待機時間の両方が表示されます。これらの数値は、割り当てられたリソースで達成できる最小レスポンス時間を理解するのに役立ちます。
定期的に異なる時間にワークロードがピークになる場合、またはサービス・レベル合意(SLA)が時間や曜日などに基づいて変化する場合は、サーバー・プールのサイズを変更する測定のみのパフォーマンス・ポリシーを追加で作成して、ワークロードに必要な最小リソースを評価します。このデモでは、Salesアプリケーションについて、onlineサーバー・プールを使用するワークロードが最低2台のサーバーを必要とします。backofficeサーバー・プールは、ワークロード・リクエストを満たすために1台のサーバーのみ必要とします。両方のサーバー・プールに現在2台のサーバーが含まれている場合は、backofficeサーバー・プールの最小サイズを1に設定することにより、onlineサーバー・プールが必要に応じてbackofficeサーバー・プールからサーバーを取得できるようにすることができます。「Business Hours」パフォーマンス・ポリシーでサーバー・プールのディレクティブ・オーバーライドを使用して、backofficeサーバー・プールの最小サイズを1に指定します。
サーバー・プールの最小サイズは、そのサーバー・プールが所有しているサーバー数として解釈できます。クラスタ内のすべてのサーバー・プールの最小サイズの合計がクラスタ内のサーバー数より少ない場合、余分なサーバーはフロータと呼ばれ、すべてのサーバー・プールで共有されます。たとえば、クラスタに15台のサーバーと3つのサーバー・プールがあり、各サーバー・プールの最小サイズが4の場合、システムには3つのフロータがあります。
パフォーマンス・ポリシーが測定のみモードで実行された後、パフォーマンス目標を各パフォーマンス・クラスに追加できます。パフォーマンス目標は、そのパフォーマンス目標の維持がビジネスにとってどれほど重要かに基づいてランク付けされます。パフォーマンス目標は、観察されたレスポンス時間より長くSLAを満たすのに必要なレスポンス時間より短い範囲でヘッドルームが最大になるように設定する必要があります。パフォーマンス・クラスでワークロード・サージが発生する場合は、少なくとも50%のヘッドルームを維持することが、リソースのトレードオフをサポートするための適切な開始点です。たとえば、パフォーマンス・クラスの平均レスポンス時間が2ミリ秒(ms)の場合、パフォーマンス目標は3ms(2msのレスポンス時間と、50%のヘッドルームに対応する1ms)に設定できます。
サービスベースの分類子によって構成が簡単になりますが、サービスのパフォーマンス目標を複数定義することが必要になる場合があります。たとえば、salesサービスには、製品の参照、顧客アカウントの追加、ショッピング・カート、注文の参照などの多くの異なるワークロードが含まれる場合があります。ショッピング・カート・ワークロードは収益を生成するため、このワークロードのレスポンス時間は他のワークロードよりも短くする必要があります。別のパフォーマンス・クラスおよび関連する分類子を作成して、様々なワークロードに対して特定のパフォーマンス目標を指定する必要があります。
ポリシー・セット・ウィザードの分類子の定義ページで、サービス名にsalesと入力することでsales cart(営業カート)パフォーマンス分類子を定義できます。アプリケーションでMODULEまたはACTIONを設定できる場合は適切な値を入力し、それ以外の場合は中間層とは別のUSERNAMEを構成します。新しいパフォーマンス・クラスを定義すると、測定のみモードのすべてのパフォーマンス・ポリシーにパフォーマンス・クラスが自動的に表示されます。新しいパフォーマンス・クラスには、デフォルトで最も低いランクが付けられます。最初はこれらの値を使用して、システムのパフォーマンスをテストします。平均パフォーマンス・レベルが特定できたら、このパフォーマンス・クラスのパフォーマンス目標とランクを各パフォーマンス・ポリシー内に設定できます。
Oracle Database QoS Managementの実装は、サービス・レベルをアクティブに管理することで完了します。管理とは、アラートへの応答、推奨事項の確認および実装、結果の追跡を意味します。この項では、デモ・システムで実行するアクションについて説明します。
すべてのワークロードが実行され、ダッシュボードにデモ・システムのパフォーマンスが表示された後、ワークロード・サージまたは障害が原因でパフォーマンス目標が満たされなくなっている場合にアラートを生成する必要があります。パフォーマンス満足度メトリック(PSM)は、すべての目標を正規化し、システムの状態を迅速に観察する方法を提供します。PSM傾向インジケータを観察することで、パフォーマンス・クラスが過去5分間にその目標をどの程度満たしていたかを確認し、問題を観察できます。パフォーマンス目標違反によって、ボトルネックを緩和するためにリソースを再割当てする方法を示す推奨が生成されます。ボトルネックおよび考えられる解決策をさらに分析するために詳細と予測を使用できます。推奨がOracle Database QoS Managementで実装できるアクションの場合は、「実装」ボタンが表示されます。
ほとんどのSLAでは、短期間のパフォーマンス目標違反は許容されます。したがって、パフォーマンス・クラスでEnterprise Managerアラートを構成して継続的な違反の期間を指定できます。これらのアラートはデータベース・アラート・ページで構成されますが、クラスタ内のすべてのパフォーマンス・クラスに対して定義できます。
ポリシー変更、違反およびアクションの監査ログは、Oracle Database QoS Managementサーバーをホストするサーバー上のoc4j/j2ee/home/log/dbwlm/auditingディレクトリにあるOracle Grid Infrastructureホームにあります。Oracle Database QoS Managementサーバーをホストしているサーバー(OC4Jコンテナ)を判断するには、オペレーティング・システムのプロンプトに次のコマンドを入力します。
srvctl status oc4j
