10.1 一般的な問題
初期構成後に、Oracle Database Quality of Service Managementは自動化されたシステムになります。そのため、発生する可能性のある問題の大部分は、Oracle Database QoS Managementの構成に関連しています。次の各項では、最も一般的な問題とそれらの解決方法について説明します。
- Oracle Database Quality of Service Managementを有効にできない
- データベースに対してOracle Database QoS Managementを有効にできない
- Oracle Database Resource Managerが有効にならず、リソース・プランがエラーになる
Oracle Database Quality of Service (QoS) Managementでは、Database Resource Managerで特定のリソース・プランを使用する必要があります。 - サーバー・プールにアクセスできない
- サーバー・プールが管理不能としてマークされる
- パフォーマンス・クラスのメトリックがない
- Oracle Database QoS Managementが推奨を生成しない
- 最近追加したサーバーが不適切なサーバー・プールに配置されている
サーバーは、Oracle Clusterwareによって、または管理者の指示によってクラスタ内で移動されます。 - RMIポートの競合が検出される
10.1.1 Oracle Database Quality of Service Managementを有効にできない
クラスタ内でOracle Database QoS Managementを有効にする前に、まずポリシー・セットを作成する必要があります。
関連項目
10.1.2 データベースに対して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はこのデータベースに対して無効になります。
10.1.3 Oracle Database Resource Managerが有効にならず、リソース・プランがエラーになる
Oracle Database Quality of Service (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 FORCE:APPQOS_PLAN
マルチテナント・データベースに問い合せている場合、出力は次のようになります。
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
resource_manager_plan string FORCE:ORA$QOS_CDB_PLAN
10.1.4 サーバー・プールにアクセスできない
サーバー・プールは、特殊なオペレーティング・システム・グループを構成することでデータベースとは別に管理できます。デフォルトでは、クラスタ用Oracle Grid Infrastructureをインストールしたユーザーは、サーバー・プールに対して操作を実行できます。インストールされているOracle Databaseに別のオペレーティング・システムを使用する場合は、そのサーバー・プールにデータベースをデプロイする前に、サーバー・プールに対する実行権限をデータベース・ソフトウェアの所有者に付与する必要があります。この権限を付与するには、CRSCTLユーティリティを使用してサーバー・プールACL属性を変更する必要があります。データベース管理者は、Server Control(SRVCTL)またはOracle Enterprise Managerを使用してサーバー・プールを作成することもできます。
10.1.5 サーバー・プールが管理不能としてマークされる
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で管理するデータベースおよびデータベース・インスタンスが、「サポートされるデータベース構成」に記載されている要件に準拠していることを確認してください。
10.1.6 パフォーマンス・クラスのメトリックがない
メトリックは、クラスタ内の管理対象データベース・インスタンスを問い合せることでOracle Database QoS Managementによって取得されます。次の条件下では、メトリックは表示されません。
-
データベース・リクエスト(実行される作業)が、特定のパフォーマンス・クラスに対して定義されている分類子と一致せず、「リクエストなし」と表示される。
-
パフォーマンス・クラスのより一般的な分類子が最初に評価されている。その結果、より具体的な分類子を持つパフォーマンス・クラスが「リクエストなし」と表示されます。たとえば、
sales_pc
パフォーマンス・クラスが分類子service=Sales
を使用し、sales_search
パフォーマンス・クラスが分類子(s
ervice=Sales and action=Search
)を使用する場合、sales_pc
パフォーマンス・クラスがポリシー・セットのパフォーマンス・クラスの順序の編集画面で最初にリストされていると、Search
アクションを実行している作業リクエストを含め、sales
サービスを使用するすべての作業リクエストがsales_pc
パフォーマンス・クラスに配置されます。sales_search
パフォーマンス・クラスはメトリックを生成せず、そのパフォーマンス・クラスに対して「リクエストなし」が表示されます。 -
データベース・インスタンスが過剰に利用され、メトリック問合せがタイムアウト制限に達し、「不完全なデータ」が表示される。
-
データベースがパフォーマンス・クラスに対して相互に一貫性のあるデータを生成せず、「未確認のデータ」が表示される。たとえば、1秒超過したデータベース・リクエストを分類しているパフォーマンス・クラスはこのレスポンスの原因になります。
-
問合せを通じて収集されるメトリックが、Oracle Database QoS Managementによって実行される健全性検証チェックに合格せず、「未確認のデータ」が表示される。
10.1.8 最近追加したサーバーが不適切なサーバー・プールに配置されている
サーバーは、Oracle Clusterwareによってクラスタ内で移動されるか、管理者の指示に従って移動されます。
クラスタに新しいサーバーが加入すると、Oracle Clusterwareは、配置アルゴリズムと、サーバー・プールの「最小」、「最大」および「重要度」属性の状態に従ってサーバーをサーバー・プールに配置します。この配置プロセスの詳細な説明は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
10.1.9 RMIポートの競合が検出される
クラスタ用Oracle Grid Infrastructureをインストールすると、qosmserver
リソースのポートが23792に設定されます。これにより、ポートがJava Remote Method Invocation(RMI)と競合することがあります。使用可能なポートを使用するためにqosmserver
リソースを設定し、次のコマンドを使用してqosmserver
リソースを再起動する必要があります。
srvctl modify qosmserver -rmiport port
srvctl stop qosmserver
srvctl start qosmserver