2. データベースの問題の解決
  3. データベースおよびデータベース・インスタンスの遅延の解決

7.2 データベースおよびデータベース・インスタンスの遅延の解決

ブロッカ・リゾルバは、遅延を解決し、リソースの可用性を維持することによってデータベースのパフォーマンスを保ちます。

親トピック: データベースの問題の解決

7.2.1 ブロッカ・リゾルバのアーキテクチャ

ブロッカ・リゾルバは、データベース内でDIA0タスクとして自律的に実行されます。

ブロッカ・リゾルバは、次の3つのフェーズで動作します:

  • 検出: このフェーズでは、ブロッカ・リゾルバは、すべてのノードのデータを収集し、別のセッションが保持するリソースを待機しているセッションを検出します。

  • 分析: このフェーズでは、ブロッカ・リゾルバは、検出フェーズで検出したセッションを分析し、セッションが潜在的な遅延の一部であるかどうかを確認します。セッションが遅延している可能性がある場合、ブロッカ・リゾルバは一定のしきい値時間まで待機し、セッションが遅延していることを確認します。

  • 検証: このフェーズでは、しきい値時間を経過すると、ブロッカ・リゾルバがセッションの遅延を確認し、遅延の原因となっているセッションを選択します。

遅延の原因となっているセッションを選択すると、ブロッカ・リゾルバがそのセッションに解決方法を適用します。セッションのチェーンまたは遅延が自動的に解決された場合、ブロッカ・リゾルバが遅延の解決方法を適用することはありません。ただし、遅延が単独で解決されない場合、ブロッカ・リゾルバは、遅延の原因となっているセッションを終了して遅延を解決します。セッションの終了が失敗した場合、ブロッカ・リゾルバがセッションのプロセスを終了します。このプロセス全体は自律型であり、リソースを長時間ブロックせず、パフォーマンスに影響することもありません。

たとえば、上位のセッションが遅延セッションのチェーンに含まれる場合、ブロッカ・リゾルバは遅延の原因となっているセッションの終了を促します。遅延の原因となっているセッションを終了すると、上位セッションの長時間待機を回避できるため、その上位セッションのパフォーマンス目標が保たれます。

親トピック: データベースおよびデータベース・インスタンスの遅延の解決

7.2.2 ブロッカ・リゾルバのオプション構成

感度を調整し、ブロッカ・リゾルバで使用されるログ・ファイルのサイズと数を制御できます。

ノート:

DBMS_HANG_MANAGERパッケージは、Oracle Database 23cでは非推奨です。かわりにDBMS_BLOCKER_RESOLVERを使用してください。

DBMS_HANG_MANAGERパッケージは、セッションの問題に対処するために、一部の構成パラメータおよび制約を変更する方法を提供します。このパッケージは、DBMS_BLOCKER_RESOLVERに置き換えられます。DBMS_HANG_MANAGERは、将来のリリースで削除される可能性があります。

感度

ブロッカ・リゾルバが遅延を検出した場合、ブロッカ・リゾルバは一定のしきい値時間まで待機し、セッションが遅延していることを確認します。しきい値時間を変更するには、DBMS_BLOCKER_RESOLVERを使用してsensitivityパラメータをNormalまたはHighに設定します。sensitivityパラメータがNormalに設定されている場合、ブロッカ・リゾルバはデフォルト時間まで待機します。ただし、感度がHighに設定されている場合は、時間が50%短縮されます。

デフォルトでは、sensitivityパラメータはNormalに設定されています。ブロッカ・リゾルバの感度を設定するには、SQL*PlusでSYSユーザーとして次のコマンドを実行します:

  • sensitivityパラメータをNormalに設定するには、次のようにします:
    exec dbms_blocker_resolver.set(dbms_blocker_resolver.sensitivity, dbms_blocker_resolver.sensitivity_normal);
  • sensitivityパラメータをHighに設定するには、次のようにします:
    exec dbms_blocker_resolver.set(dbms_blocker_resolver.sensitivity, dbms_blocker_resolver.sensitivity_high);

トレース・ログ・ファイルのサイズ

ブロッカ・リゾルバは、ファイル名に_base_を含むトレース・ファイルに、遅延の詳細な診断を記録します。base_file_size_limitパラメータを使用して、トレース・ファイルのサイズ(バイト単位)を変更します。たとえば、SQL*Plusで次のコマンドを実行して、トレース・ファイルのサイズ制限を100 MBに設定します:
exec dbms_blocker_resolver.set(dbms_blocker_resolver.base_file_size_limit, 104857600);

トレース・ログ・ファイルの数

ベースのブロッカ・リゾルバ・トレース・ファイルはトレース・ファイル・セットの一部です。base_file_set_countパラメータを使用して、トレース・ファイル・セット内のトレース・ファイルの数を変更します。たとえば、SQL*Plusで次のコマンドを実行して、トレース・ファイル・セット内のトレース・ファイルの数を6に設定します:
exec dbms_blocker_resolver.set(dbms_blocker_resolver.base_file_set_count,6);

デフォルトでは、base_file_set_countパラメータは5に設定されています。

親トピック: データベースおよびデータベース・インスタンスの遅延の解決

7.2.3 ブロッカ・リゾルバの診断およびロギング

ブロッカ・リゾルバは、遅延を自律的に解決し、その解決をデータベース・アラート・ログおよび診断のトレース・ファイルに継続的に記録します。

ブロッカ・リゾルバは、インシデント・コードがORA–32701の自動診断リポジトリ(ADR)インシデントとして、解決をデータベース・アラート・ログに記録します。

また、遅延の検出に関する詳細な診断をトレース・ファイルで確認できます。トレース・ファイルとアラート・ログのファイル名はdatabase instance_dia0_で始まります。

  • トレース・ファイルは$ ADR_BASE/diag/rdbms/database name/database instance/incident/incdir_xxxxxxディレクトリに格納されます
  • アラート・ログは$ ADR_BASE/diag/rdbms/database name/database instance/traceディレクトリに格納されます

例7-1 ローカル・インスタンスのブロッカ・リゾルバ・トレース・ファイル

この例は、ローカル・データベース・インスタンスのブロッカ・リゾルバで表示される出力例を示します

Trace Log File .../oracle/log/diag/rdbms/hm1/hm11/incident/incdir_111/hm11_dia0_11111_i111.trc
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
...
*** 2016-07-16T12:39:02.715475-07:00
HM: Hang Statistics - only statistics with non-zero values are listed

            current number of active sessions 3
              current number of hung sessions 1
  instance health (in terms of hung sessions) 66.67%
       number of cluster-wide active sessions 9
         number of cluster-wide hung sessions 5
   cluster health (in terms of hung sessions) 44.45%

*** 2016-07-16T12:39:02.715681-07:00
Resolvable Hangs in the System
                      Root       Chain Total               Hang
   Hang Hang          Inst Root  #hung #hung  Hang   Hang  Resolution
     ID Type Status   Num  Sess   Sess  Sess  Conf   Span  Action
  ----- ---- -------- ---- ----- ----- ----- ------ ------ -------------------
      1 HANG RSLNPEND    3    44     3     5   HIGH GLOBAL Terminate Process
  Hang Resolution Reason: Although hangs of this root type are typically
    self-resolving, the previously ignored hang was automatically resolved.

例7-2 遅延したセッションを示すアラート・ログ内のエラー・メッセージ

この例は、プライマリ・インスタンスに関するブロッカ・リゾルバ・アラート・ログの例を示します

2016-07-16T12:39:02.616573-07:00
Errors in file .../oracle/log/diag/rdbms/hm1/hm1/trace/hm1_dia0_i1111.trc  (incident=1111):
ORA-32701: Possible hangs up to hang ID=1 detected
Incident details in: .../oracle/log/diag/rdbms/hm1/hm1/incident/incdir_1111/hm1_dia0_11111_i1111.trc
2016-07-16T12:39:02.674061-07:00
DIA0 requesting termination of session sid:44 with serial # 23456 (ospid:34569) on instance 3
     due to a GLOBAL, HIGH confidence hang with ID=1.
     Hang Resolution Reason: Although hangs of this root type are typically
    self-resolving, the previously ignored hang was automatically resolved.
DIA0: Examine the alert log on instance 3 for session termination status of hang with ID=1.

例7-3 ブロック・リゾルバによって解決されたセッション遅延を示すアラート・ログ内のエラー・メッセージ

この例は、解決された遅延に関するローカル・インスタンスのブロッカ・リゾルバ・アラート・ログの例を示します

2016-07-16T12:39:02.707822-07:00
Errors in file .../oracle/log/diag/rdbms/hm1/hm11/trace/hm11_dia0_11111.trc  (incident=169):
ORA-32701: Possible hangs up to hang ID=1 detected
Incident details in: .../oracle/log/diag/rdbms/hm1/hm11/incident/incdir_169/hm11_dia0_30676_i169.trc
2016-07-16T12:39:05.086593-07:00
DIA0 terminating blocker (ospid: 30872 sid: 44 ser#: 23456) of hang with ID = 1
     requested by master DIA0 process on instance 1
     Hang Resolution Reason: Although hangs of this root type are typically
    self-resolving, the previously ignored hang was automatically resolved.
     by terminating session sid:44 with serial # 23456 (ospid:34569)
...
DIA0 successfully terminated session sid:44 with serial # 23456 (ospid:34569) with status 0.

親トピック: データベースおよびデータベース・インスタンスの遅延の解決

7.2.4 クラスタ・リソース・アクティビティ・ログを使用したクラスタ・リソースの障害の監視

クラスタ・リソース・アクティビティ・ログは、診断ログとは別に、リソース障害に関する正確で詳細な情報を提供します。

Oracle Clusterware管理のリソースの障害が発生した場合、Oracle Clusterwareは、その障害に関するメッセージをクラスタ・リソース・アクティビティ・ログに記録します。障害は、リソース、ホスティング・ノードまたはネットワークに関する問題の結果として発生する可能性があります。クラスタ・リソース・アクティビティ・ログには、リソース障害の原因の統合ビューが表示されます。

クラスタ・リソース・アクティビティ・ログへの書込みはアクティビティIDでタグ付けされ、関連するデータは同じ親アクティビティIDを取得し、親データの下にネストされます。たとえば、Oracle Clusterwareの稼働中にcrsctl stop clusterware -allコマンドを実行した場合、すべてのアクティビティがアクティビティIDを取得し、関連するアクティビティに同じ親アクティビティIDがタグ付けされます。ノードごとに、親IDの下にサブIDが作成され、各アクティビティにそれぞれ対応するアクティビティIDがタグ付けされます。さらに、個々のノード上のリソースごとに親IDに基づいてサブIDを作成し、アクティビティIDの階層を作成します。アクティビティIDの階層によってデータを分析し、特定のアクティビティを確認できます。

たとえば、相互に複雑な依存関係があり、1つのデータベース・サービスを使用しているリソースが多数あるとします。金曜日には、すべてのリソースが1つのノードで実行されていますが、月曜日には各リソースが別のノード上で実行されているため、その理由を確認する必要があります。crsctl query calogコマンドを使用して、それらのリソースとデータベース・サービスを含むすべてのアクティビティについてクラスタ・リソース・アクティビティ・ログを問い合せます。出力には完全なフローが表示されるため、ユーザーは親サービス・フェイルオーバーID内のそれぞれのサブIDを問い合せて、発生した問題とその原因を具体的に確認できます。

フィルタを使用すれば、クラスタ・リソース・アクティビティ・ログ内のすべてのフィールドを問い合せることができます。たとえば、rootなど、特定のオペレーティング・システム・ユーザーによって書き込まれたすべてのアクティビティを問い合せることができます。crsctl query calogコマンドで生成される出力は、表形式またはXML形式で表示できます。

クラスタ・リソース・アクティビティ・ログは、現在のOracle Clusterwareのロギングおよびアラート・ログ・メッセージを補足するものです。

ノート:

Oracle Clusterwareでは、ログイン資格証明など、セキュリティ関連の情報を含むメッセージはクラスタ・アクティビティ・ログに書き込まれません。

次のコマンドを使用して、クラスタ・リソース・アクティビティ・ログの内容を管理および表示します:

親トピック: データベースおよびデータベース・インスタンスの遅延の解決