| Oracle® Database Quality of Service Managementユーザーズ・ガイド 12cリリース1 (12.1) B71294-06 |
|
 前 |
 次 |
この章では、Oracle Database QoS Managementを使用している場合に発生する可能性のあるいくつかの問題と、それらの解決方法について説明します。Oracle Database QoS Managementのトレースまたはログ・ファイルの特定方法についても説明します。
初期構成後に、Oracle Database Quality of Service Managementは自動化されたシステムになります。そのため、発生する可能性のある問題の大部分は、Oracle Database QoS Managementの構成に関連しています。次の各項では、最も一般的な問題とそれらの解決方法について説明します。
クラスタ内でOracle Database QoS Managementを有効にする前に、まずポリシー・セットを作成する必要があります。ポリシー・セットを作成するには、「初期ポリシー・セットの作成」を参照してください。
データベースをOracle Database QoS Managementで管理するには、データベースがコンプライアンスで有効化され、Oracle Database QoS ManagementがAPPQOSSYSデータベース・ユーザーにアクセスできる必要があります。
コンプライアンス・データベースとは、Oracle Databaseリリース11.2.0.2以降が実行されているOracle RACデータベースです。
データベースを有効にするには、Oracle Database QoS Managementがデータベースに接続できる必要があります。接続は、Oracle Enterprise Manager Cloud Controlで「サービスのクオリティ管理の有効化」リンクを選択した場合に構成されます。このリンクを選択すると、データベース内のAPPQOSSYSアカウントのクラスタ資格証明とパスワードの入力を求められます。デフォルトでは、APPQOSSYSアカウントは期限が切れています。パスワードを発行すると、アカウントのロックが解除されます。
APPQOSSYSユーザーのパスワードが他の方法で変更されるかアカウントがロックされた場合は、もう一度「サービスのクオリティ管理の有効化」リンクを選択してこの状況を修正するまで、Oracle Database QoS Managementはこのデータベースに対して無効になります。
関連項目:
Oracle Database QoS Managementを有効化する方法の詳細は、「クラスタに対するOracle Database QoS Managementの有効化」を参照してください。
Oracle Database QoS Managementは、データベースでOracle Database QoS Managementによる管理が有効になるたびに、特殊なOracle Database Resource Managerプラン(APPQOS_PLAN)をインストールします。Oracle Database QoS Managementは、パフォーマンス・クラスを様々なレベルのCPUスケジューリングに移動するためにこのリソース・プランを必要とします。このデータベースでOracle Database QoS Managementが有効になっている間は、他のプランをアクティブにできません。リソース・プランがOracle RACデータベースに対して有効になっていない場合は、データベースでOracle Database QoS Managementによる管理を有効にしようとしたときにエラーが発生します。リソース・プランが有効になった後、データベースでOracle Database QoS Managementによる管理の有効化が成功します。
ターゲット・データベースで必須のAPPQOS_PLANがアクティブであることを確認するには、SQL*Plusを使用して接続し、次の文を発行します。
SQL> show parameter resource_manager_plan
次のような出力が表示されます。
NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_manager_plan string APPQOS_PLAN
サーバー・プールは、特殊なオペレーティング・システム・グループを構成することでデータベースとは別に管理できます。デフォルトでは、クラスタ用Oracle Grid Infrastructureをインストールしたユーザーは、サーバー・プールに対して操作を実行できます。インストールされているOracle Databaseに別のオペレーティング・システムを使用する場合は、そのサーバー・プールにデータベースをデプロイする前に、サーバー・プールに対する実行権限をデータベース・ソフトウェアの所有者に付与する必要があります。この権限を付与するには、CRSCTLユーティリティを使用してサーバー・プールACL属性を変更する必要があります。データベース管理者は、Server Control(SRVCTL)またはOracle Enterprise Managerを使用してサーバー・プールを作成することもできます。
関連項目:
crsctlコマンドの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
Oracle Database QoS Managementがサーバー・プールにデプロイされているパフォーマンス・クラスのパフォーマンスを正しく測定または予測できない場合、そのサーバー・プールは管理不能としてマークされます。サーバー・プールは、次の条件で管理不能とみなされることがあります。
サーバー・プール内のサーバーの物理的なCPU数が異なる。
各データベース・インスタンスのCPU数を取得できない。
サーバー上のすべてのデータベース・インスタンスに対して構成されているCPU数の合計が、その物理的なCPU数より多い。
最大サイズが1より大きいサーバー・プールにシングルトン・サービスがデプロイされている。
Oracle Database QoS Managementがすべてのパフォーマンス・クラスのメトリックを収集できないか、収集されたメトリックに有効なデータが含まれていない。
サーバー・プールに、Oracle Database QoS Managementが有効になっていないデータベースがある。
サーバーがサーバー・プールに追加されると、サーバー・プール内の新規サーバー上でポリシー管理型データベースのインスタンスとサービスが起動されます。新規サーバーでインスタンスが起動されると、既存のインスタンスのSPFILEでCPU_COUNT設定が確認され、この値が新規インスタンスに使用されます。デフォルトでは、SPFILEにCPU_COUNTの設定がない場合、新規サーバー上のインスタンスはCPU_COUNTがサーバーの物理CPU数に設定されて起動されます。これはサポートされている構成ではないため、サーバー・プールは管理不能としてマークされます。また、CPU_COUNTパラメータを変更したにもかかわらず、SPFILEに変更内容を保存しなかった場合、新たに起動されたインスタンスでCPU_COUNTパラメータは間違った値に設定され、構成違反となります。
Oracle Database QoS Managementで管理するデータベースおよびデータベース・インスタンスが、「サポートされるデータベース構成」に記載されている要件に準拠していることを確認してください。
メトリックは、クラスタ内の管理対象データベース・インスタンスを問い合せることでOracle Database QoS Managementによって取得されます。次の条件下では、メトリックは表示されません。
データベース・リクエスト(実行される作業)が、特定のパフォーマンス・クラスに対して定義されている分類子と一致せず、「リクエストなし」と表示される。
パフォーマンス・クラスのより一般的な分類子が最初に評価されている。その結果、より具体的な分類子を持つパフォーマンス・クラスが「リクエストなし」と表示されます。たとえば、sales_pcパフォーマンス・クラスが分類子service=Salesを使用し、sales_searchパフォーマンス・クラスが分類子(service=Sales and action=Search)を使用する場合、sales_pcパフォーマンス・クラスがポリシー・セットのパフォーマンス・クラスの順序の編集画面で最初にリストされていると、Searchアクションを実行している作業リクエストを含め、salesサービスを使用するすべての作業リクエストがsales_pcパフォーマンス・クラスに配置されます。sales_searchパフォーマンス・クラスはメトリックを生成せず、そのパフォーマンス・クラスに対して「リクエストなし」が表示されます。
データベース・インスタンスが過剰に利用され、メトリック問合せがタイムアウト制限に達し、「不完全なデータ」が表示される。
データベースがパフォーマンス・クラスに対して相互に一貫性のあるデータを生成せず、「未確認のデータ」が表示される。たとえば、1秒超過したデータベース・リクエストを分類しているパフォーマンス・クラスはこのレスポンスの原因になります。
問合せを通じて収集されるメトリックが、Oracle Database QoS Managementによって実行される健全性検証チェックに合格せず、「未確認のデータ」が表示される。
サーバーは、Oracle Clusterwareによってクラスタ内で移動されるか、管理者の指示に従って移動されます。
クラスタに新しいサーバーが加入すると、Oracle Clusterwareは、配置アルゴリズムと、サーバー・プールの「最小」、「最大」および「重要度」属性の状態に従ってサーバーをサーバー・プールに配置します。この配置プロセスの詳細な説明は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
クラスタ用Oracle Grid Infrastructureをインストールすると、Oracle Application Server Containers for J2EE(OC4J)リソースのデフォルト・ポートが23792に設定されます。これにより、ポートがJava Remote Method Invocation(RMI)と競合することがあります。環境のOC4J_PORT環境変数を使用可能なポートの番号に設定し、次のコマンドを使用してOC4Jリソースを再起動する必要があります。
srvctl modify oc4j -rmiport port
srvctl stop oc4j
srvctl start oc4j
Oracle Database QoS Managementサーバーの操作ログ・ファイルは、Grid_home/oc4j/j2ee/home/log/dbwlm/auditing/log.xmlにあります。
Oracle Database QoS Managementサーバーのトレース・ログ・ファイルは、Grid_home/oc4j/j2ee/home/log/dbwlm/logging/log.xmlにあります。
OC4J標準出力ログ・ファイルとOracle ClusterwareのServer Manager(SRVM)コンポーネントのトレース・ファイルは、Grid_home/oc4j/j2ee/home/log/oc4j_<timestamp>.outにあります。
OC4J標準エラー・ログ・ファイルは、Grid_home/oc4j/j2ee/home/log/oc4j_<timestamp>.errにあります。
Oracle Database QoS ManagementのDBWLMコンポーネントの開始および終了ログ・ファイルは、Grid_home/oc4j/j2ee/home/log/dbwlm.logにあります。
