1. ユーザーズ・ガイド
  2. データベース・ワークロード・パフォーマンスの監視および管理
  3. Oracle Database QoS Managementのトラブルシューティング
  4. 一般的な問題

10.1 一般的な問題

初期構成後に、Oracle Database Quality of Service Managementは自動化されたシステムになります。そのため、発生する可能性のある問題の大部分は、Oracle Database QoS Managementの構成に関連しています。

次の各項では、最も一般的な問題とそれらの解決方法について説明します。

親トピック: Oracle Database QoS Managementのトラブルシューティング

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がサーバー・プールにデプロイされているパフォーマンス・クラスのパフォーマンスを正しく測定または予測できない場合、そのサーバー・プールは管理不能としてマークされます。

サーバー・プールは、次の条件で管理不能とみなされることがあります。

  1. サーバー・プール内のサーバーの物理的なCPU数が異なる。

  2. 各データベース・インスタンスのCPU数を取得できない。

  3. サーバー上のすべてのデータベース・インスタンスに対して構成されているCPU数の合計が、その物理的なCPU数より多い。

  4. 最大サイズが1より大きいサーバー・プールにシングルトン・サービスがデプロイされている。

  5. Oracle Database QoS Managementがすべてのパフォーマンス・クラスのメトリックを収集できないか、収集されたメトリックに有効なデータが含まれていない。

  6. サーバー・プールに、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によって取得されます。

次の条件下では、メトリックは表示されません。

  1. データベース・リクエスト(実行される作業)が、特定のパフォーマンス・クラスに対して定義されている分類子と一致せず、「リクエストなし」と表示される。

  2. パフォーマンス・クラスのより一般的な分類子が最初に評価されている。その結果、より具体的な分類子を持つパフォーマンス・クラスが「リクエストなし」と表示されます。たとえば、sales_pcパフォーマンス・クラスが分類子service=Salesを使用し、sales_searchパフォーマンス・クラスが分類子(service=Sales and action=Search)を使用する場合、sales_pcパフォーマンス・クラスがポリシー・セットのパフォーマンス・クラスの順序の編集画面で最初にリストされていると、Searchアクションを実行している作業リクエストを含め、salesサービスを使用するすべての作業リクエストがsales_pcパフォーマンス・クラスに配置されます。sales_searchパフォーマンス・クラスはメトリックを生成せず、そのパフォーマンス・クラスに対して「リクエストなし」が表示されます。

  3. データベース・インスタンスが過剰に利用され、メトリック問合せがタイムアウト制限に達し、「不完全なデータ」が表示される。

  4. データベースがパフォーマンス・クラスに対して相互に一貫性のあるデータを生成せず、「未確認のデータ」が表示される。たとえば、1秒超過したデータベース・リクエストを分類しているパフォーマンス・クラスはこのレスポンスの原因になります。

  5. 問合せを通じて収集されるメトリックが、Oracle Database QoS Managementによって実行される健全性検証チェックに合格せず、「未確認のデータ」が表示される。

親トピック: 一般的な問題

10.1.7 Oracle Database QoS Managementが推奨を生成しない

Oracle Database QoS Managementダッシュボード(ダッシュボード)にログインすると、推奨が1分間に1回生成されます。

推奨は、次の場合にはダッシュボードに表示されません。

  1. Oracle Database QoS Managementが無効になっている。

  2. 推奨を実装するアクションが進行している。

  3. Oracle Database QoS Managementの有効化から最初の1分間、またはポリシー・セットの送信またはポリシー・セットのアクティブ化中。

親トピック: 一般的な問題

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

親トピック: 一般的な問題