データベース・サービス・イベントの修正

この記事では、データベース・サービス・イベントの使用中に発生した問題に対する必要な修正について説明します。

次の修正が使用可能です:

• HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE
• AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN
• AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION
• AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN
• AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN
• AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN
• HEALTH.DB_CLUSTER.CDB.CORRUPTION
• HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG
• HEALTH.DB_CLUSTER.CDB.DATABASE_HANG
• HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE
• HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

イベント名:

HEALTH.DB_GUEST.FILESYSTEM.FREE_SPACE

イベント摘要:

このイベントは、次のファイル・システムに対するオペレーティング・システムのdf(1)コマンドによって特定されるVMゲスト・ファイル・システムの空き領域が10%未満になるとレポートされます:

• /
• /u01
• /u02
• /var
• /tmp

問題の内容:

1つ以上のVMゲスト・ファイル・システムの空き領域が10%を下回っています。

リスク:

VMゲスト・ファイル・システムの空き領域が不足すると、ディスク領域割当てが失敗し、Oracleソフトウェア(Database、Clusterware、Cloud Tooling)で広範囲にわたるエラーや障害が発生する可能性があります。

アクション/修復:

クラウド・ツールによって作成された古いログ・ファイルおよびトレース・ファイルをパージしてファイル・システム領域を再利用するために、Oracle CloudおよびDCSエージェントが自動的に実行されます。

自動ファイル・システム領域再利用ユーティリティがこのイベントをクリアするために古いファイルを十分にパージできない場合は、次のアクションを実行します:

1. 手動で、または顧客がインストールしたアプリケーションまたはユーティリティによって作成された不要なファイルまたはディレクトリ(あるいはその両方)を削除します。顧客がインストールしたソフトウェアによって作成されたファイルは、Oracleの自動ファイル・システム領域再利用ユーティリティの範囲外です。rootユーザーとして実行される次のオペレーティング・システム・コマンドは、過剰なディスク領域を消費するディレクトリを識別する場合に役立ちます:

   sudo du -hx <file system mount point> | sort -hr

   安全に削除できるという確信のあるファイルまたはディレクトリのみを削除してください。

2. クラウド・ツールを使用して自動パージ・ポリシーを設定します。詳細は、autologcleanpolicyコマンドを参照してください。
3. ファイル・システム領域の使用量の削減に関する追加のガイダンスを受け取るためのサービス・リクエストをオープンします。

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

イベント名:

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN

イベント摘要:

Cluster Ready Service (CRS)が停止していることが検出されると、CRITICALタイプのイベントが作成されます。

問題の内容:

クラスタ・レディ・スタックがオフライン状態になっているか、失敗しました。

リスク:

ノード上でCRSがオフラインになっている場合、ノードはアプリケーションのデータベース・サービスを提供できません。

アクション/修復:

1. CRSが、計画メンテナンス・イベントの一部として、またはローカル・ストレージのスケール・アップまたはスケール・ダウンの一部として管理者によって停止されたかどうかを確認します

   1. 次のパッチ適用イベントはCRSを停止します

      1. GRID更新
      2. ゲストの更新
      3. ホストの更新

2. CRSが予期せず停止した場合、crsctl check crsコマンドを発行して現在のステータスを確認できます。

   1. ノードが応答しない場合、VMノードが再起動している可能性があります。ノードの再起動が終了するまで待機します。CRSは通常、initプロセスを介して起動されます。
3. CRSがまだ停止している場合は、/u01/app/grid/diag/CRS/<node_name>/CRS/traceにあるalert.logを参照して、失敗の原因を調査します。停止イベントの日時に対応するログ・エントリを確認し、実行可能な修正があればそれを実行します。
4. crsctl start crsコマンドを発行して、CRSを再起動します。
5. CRSの再起動に成功すると、クリア・イベントAVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEAREDが生成されます

イベントのクリア:

AVAILABILITY.DB_GUEST.CRS_INSTANCE.DOWN_CLEARED

イベントのクリアの説明:

CRSが正常に起動されると、INFORMATIONイベントが作成されます。

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

イベント名:

AVAILABILITY.DB_GUEST.CRS_INSTANCE.EVICTION

イベント摘要:

Cluster Ready Service (CRS)によってクラスタからノードが削除されると、CRITICALタイプのイベントが作成されます。CRSのalert.logが、クラスタからノードが削除されることを示すCRS-1632エラーについて解析されます。

問題の内容:

Oracle Clusterwareは、クリティカルな問題が検出された場合に、クラスタから1つ以上のノードを削除することによってノード削除を実行するように設計されています。クリティカルな問題には、ネットワーク・ハートビートを介して応答しないノード、ディスク・ハートビートを介して応答しないノード、ハングまたは大幅に機能低下したマシン、ハングしたocssd.binプロセスなどがあります。このノード削除の目的は、正常でないメンバーを削除することによって、クラスタ全体の状態を維持することです。

リスク:

削除されたノードが再起動されるまでの時間、ノードはアプリケーションのデータベース・サービスを提供できません。

アクション/修復:

CRSノード削除は、OCSSD (CSSデーモン)、CSSDAGENTまたはCSSDMONITORプロセスで発生する可能性があります。この場合、どのプロセスがノード削除と関連ログ・ファイルの確認を行っていたかを判別する必要があります。OCSSD削除の一般的な原因は、ネットワーク障害/待機時間、CSS投票ディスクに関するIOの問題、メンバーのエスカレーション強制終了です。CSSDAGENTまたはCSSDMONITORの削除は、OSスケジューラの問題や、CSSデーモン内のスレッドのハングが原因である可能性があります。確認するログ・ファイルには、クラスタウェア・アラート・ログ、cssdagentログ、cssdmonitorログ、ocssdログ、lastgaspログ、/var/log/messages、CHM/OS Watcherデータおよびopatch lsinventoryの詳細が含まれます。

ファイルをまとめて収集する方法の詳細は、「Autonomous Health Framework (AHF) Trace File Analyzer (TFA)およびORAchk/EXAchk」を参照してください。CRSノード削除のトラブルシューティングの詳細は、Clusterwareのノード削除(再起動)のトラブルシューティングを参照してください。

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

イベント名:

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

イベント摘要:

SCANリスナーが停止すると、DOWNイベントが作成されます。サーバー制御ユーティリティ(srvctl)またはリスナー制御(lsnrctl)コマンドなどを使用したユーザー・アクションや、これらのコマンドを使用するGrid Infrastructureソフトウェア更新の実行などのOracle Cloudメンテナンス・アクションによってSCANリスナーが停止した場合、このイベントはINFORMATIONタイプになります。SCANリスナーが予期せず停止した場合、このイベントはCRITICALタイプになります。SCANリスナーが起動すると、対応するDOWN_CLEAREDイベントが作成されます。

クラスタごとに、LISTENER_SCAN[1,2,3]という3つのSCANリスナーがあります。

問題の内容:

SCANリスナーが停止しており、アプリケーション接続を受け入れることができません。

リスク:

すべてのSCANリスナーが停止している場合、SCANリスナーを介したデータベースへのアプリケーション接続は失敗します。

アクション/修復:

SCANリスナーを起動し、DOWN_CLEAREDイベントを受信します。

INFORMATIONタイプのDOWNイベント:

1. イベントがOracle Cloudメンテナンス・アクション(Grid Infrastructureソフトウェア更新の実行など)によって発生した場合、処置は必要ありません。影響を受けるSCANリスナーは、使用可能なインスタンスに自動的にフェイルオーバーします。
2. イベントがユーザー・アクションによって発生した場合、次の機会にSCANリスナーを起動します。

CRITICALタイプのDOWNイベント:

1. SCANステータスを確認し、SCANリスナーを再起動します

   • opcユーザーとしてVMにログインし、sudoでgridユーザーにします:

     [opc@vm ~] sudo su - grid

   • 任意のノードでSCANリスナーのステータスを確認します:

     [grid@vm ~] srvctl status scan_listener

   • SCANリスナーを起動します:

     [grid@vm ~] srvctl start scan_listener

   • 任意のノードでSCANリスナーのステータスを再確認します: scan_listenerがまだ停止している場合は、スキャン・リスナーの障害の原因を調査します:

     1. ログに示されている<hostName>に対するCRSログとOSログの両方を、30分前から10分後まで収集します。イベント・ペイロードの時刻は常にUTCで示されます: tfactlの収集の場合は、時刻をVMクラスタのタイムゾーンに調整します。

        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName>
            -from "<eventTime adjusted for local vm timezone> - 30 minute "
            -to "<eventTime adjusted for local vm timezone> + 10 minutes"

     2. SCANリスナーの問題が記録されます:

        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

イベント名:

AVAILABILITY.DB_GUEST.CLIENT_LISTENER.DOWN

イベント摘要:

クライアント・リスナーが停止すると、DOWNイベントが作成されます。サーバー制御ユーティリティ(srvctl)またはリスナー制御(lsnrctl)コマンドなどを使用したユーザー・アクションや、これらのコマンドを使用するGrid Infrastructureソフトウェア更新の実行などのOracle Cloudメンテナンス・アクションによってクライアント・リスナーが停止した場合、このイベントはINFORMATIONタイプになります。クライアント・リスナーが予期せず停止した場合、このイベントはCRITICALタイプになります。クライアント・リスナーが起動すると、対応するDOWN_CLEAREDイベントが作成されます。

ノードごとに、それぞれLISTENERという1つのクライアント・リスナーがあります。

問題の内容:

クライアント・リスナーが停止しており、アプリケーション接続を受け入れることができません。

リスク:

ノードのクライアント・リスナーが停止している場合、ノード上のデータベース・インスタンスはアプリケーションにサービスを提供できません。

クライアント・リスナーがすべてのノードで停止している場合、SCANまたはVIPを使用してデータベースに接続するすべてのアプリケーションは失敗します。

アクション/修復:

クライアント・リスナーを起動し、DOWN_CLEAREDイベントを受信します。

INFORMATIONタイプのDOWNイベント:

1. イベントがOracle Cloudメンテナンス・アクション(Grid Infrastructureソフトウェア更新の実行など)によって発生した場合、処置は必要ありません。グリッド・インスタンスに影響するメンテナンスが完了すると、影響を受けるクライアント・リスナーは、自動的に再起動されます。
2. イベントがユーザー・アクションによって発生した場合、次の機会にクライアント・リスナーを起動します。

CRITICALタイプのDOWNイベント:

1. クライアント・リスナーのステータスを確認し、クライアント・リスナーを再起動します:

   • opcユーザーとしてVMにログインし、sudoでgridユーザーにします:

     [opc@vm ~] sudo su - grid

   • 任意のノードでクライアント・リスナーのステータスを確認します:

     [grid@vm ~] srvctl status listener

   • クライアント・リスナーを起動します:

     [grid@vm ~] srvctl start listener

   • 任意のノードでクライアント・リスナーのステータスを再確認します: クライアント・リスナーがまだ停止している場合。クライアント・リスナーの障害の原因を調査します:

     1. tfactlを使用して、ログに示されているhostNameに対するCRSログとOSログの両方を、30分前から10分後まで収集します。イベント・ペイロードの時刻は常にUTCで示されます: tfactlの収集の場合は、時刻をVMクラスタのタイムゾーンに調整します。

        [grid@vm ~] tfactl diagcollect -crs -os -node <hostName>
            -from "<eventTime adjusted for local vm timezone> - 30 minute "
            -to "<eventTime adjusted for local vm timezone> + 10 minutes"

     2. 次の場所の下にあるリスナー・ログを確認します:

        /u01/app/grid/diag/tnslsnr/<hostName>/<listenerName>/trace

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

イベント名:

AVAILABILITY.DB_GUEST.CDB_INSTANCE.DOWN

イベント摘要:

データベース・インスタンスが停止すると、DOWNイベントが作成されます。SQL*Plus (sqlplus)またはサーバー制御ユーティリティ(srvctl)コマンドなどを使用したユーザー・アクションや、これらのコマンドを使用するデータベース・ホーム・ソフトウェア更新の実行などのOracle Cloudメンテナンス・アクションによってデータベース・インスタンスが停止した場合、このイベントはINFORMATIONタイプになります。データベース・インスタンスが予期せず停止した場合、このイベントはCRITICALタイプになります。データベース・インスタンスが起動すると、対応するDOWN_CLEAREDイベントが作成されます。

問題の内容:

データベース・インスタンスが停止しました。

リスク:

データベース・インスタンスが停止しました。そのため、データベース・インスタンスがクラスタ内の他のノードで使用可能な場合は、パフォーマンスが低下する可能性があります。すべてのノードのデータベース・インスタンスが停止している場合は、全面的な停止時間が発生する可能性があります。

アクション/修復:

データベース・インスタンスを起動し、DOWN_CLEAREDイベントを受信します。

INFORMATIONタイプのDOWNイベント:

1. イベントがOracle Cloudメンテナンス・アクション(データベース・ホーム・ソフトウェア更新の実行など)によって発生した場合、処置は必要ありません。インスタンスに影響するメンテナンスが完了すると、影響を受けるデータベース・インスタンスは、自動的に再起動されます。
2. イベントがユーザー・アクションによって発生した場合、次の機会に影響を受けるデータベース・インスタンスを起動します。

CRITICALタイプのDOWNイベント:

1. データベース・ステータスを確認し、停止しているデータベース・インスタンスを再起動します。

   1. oracleユーザーとしてVMにログインします:

   2. 環境を設定します:

      [oracle@vm ~] . <dbName>.env

   3. データベース・ステータスを確認します:

      [oracle@vm ~] srvctl status database -db <dbName>

   4. データベース・インスタンスを起動します:

      [oracle@vm ~] srvctl start instance -db <dbName> -instance <instanceName>

2. データベース・インスタンス障害の原因を調査します。

   1. データベースのTrace File Analyzer (TFA)イベントを確認します:

      [oracle@vm ~] tfactl events -database <dbName> -instance <instanceName>

   2. 次の場所にあるデータベース・アラート・ログを確認します:

      $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

HEALTH.DB_CLUSTER.CDB.CORRUPTION

イベント名:

HEALTH.DB_CLUSTER.CDB.CORRUPTION

イベント摘要:

プライマリまたはスタンバイ・データベースでデータベースの破損が検出されました。データベースのalert.logは、物理ブロック破損、論理ブロック破損、または書込みの欠落による論理ブロック破損を示す特定のエラーについて解析されます。

問題の内容:

破損はアプリケーションやデータベースのエラーを引き起こす可能性があり、さらに悪い場合には、すぐに対処しないと重大なデータ損失が起こることがあります。

破損ブロックは、Oracle Databaseが予期している検出内容とは異なるように変更されたブロックです。ブロック破損は、物理破損または論理破損に分類されます:

• 物理ブロック破損(メディア破損とも呼ばれます)では、データベースでブロックがまったく認識されません。チェックサムが無効であるか、ブロックのすべてにゼロが含まれます。より複雑なブロック破損の例としては、ブロックのヘッダーとフッターが一致しない場合があげられます。
• 論理ブロック破損では、ブロックの内容は物理的には正常で、物理ブロック・チェックに合格します。ただし、ブロックは論理的な一貫性を欠いている可能性があります。論理ブロック破損の例としては、不正なブロック・タイプ、不正なデータまたはREDOブロック順序番号、行断片または索引エントリの破損、データ・ディクショナリの破損などがあります。

ブロック破損は、ブロック間の破損とブロック内の破損に分類することもできます:

• ブロック内破損の場合、破損はブロック自体で発生し、物理ブロック破損または論理ブロック破損のいずれかになります。
• ブロック間破損の場合、破損はブロック間で発生し、論理ブロック破損のみになります。

Oracleは、alert.logで次のエラーをチェックします:

• ORA-01578
• ORA-00752
• ORA-00753
• ORA-00600 [3020]
• ORA-00600 [kdsgrp1]
• ORA-00600 [kclchkblk_3]
• ORA-00600 [13013]
• ORA-00600 [5463]

リスク:

データ破損による停止が発生するのは、ハードウェア、ソフトウェアまたはネットワーク・コンポーネントによって破損したデータの読取り/書込みが行われた場合です。データ破損による停止のサービスレベルの影響は、アプリケーションまたはデータベースの一部分(単一のデータベース・ブロック)から、アプリケーションまたはデータベースの大部分(基本的に使用不可)まで様々です。修正アクションを迅速に行わない場合、停止時間およびデータ損失が起こる可能性が大きくなることがあります。

アクション/修復:

現在のイベント通知は、現時点では、物理ブロック破損(ORA-01578)、書込み欠落(最初の引数が3020のORA-00752、ORA-00753およびORA-00600)および論理破損(通常は最初の引数がkdsgrp1、kdsgrp1、kclchkblk_3、13013または5463のORA-00600から検出)でトリガーされます。

次のステップをお薦めします:

1. これらの破損がalert.logトレース・ファイルでレポートされていることを確認します。サービス・リクエスト(SR)を登録し、最新のEXAchkレポート、破損エラーを含むalert.logおよびトレース・ファイルの抜粋、最近のアプリケーション、データベースまたはソフトウェアの変更の履歴、および同じ期間のシステム、クラスタウェアおよびデータベースのログを添付します。これらのすべてのケースについて、TFA収集を使用でき、SRに添付する必要があります。
2. 修復の推奨事項の詳細は、Oracle Database破損の問題の処理に関する重要なノートを参照してください。

物理破損またはORA-1578エラーについては、次のノートが役立ちます:

• OERR: ORA-1578 "ORACLE data block corrupted (file # %s、 block # %s)"に関する重要なノート(Doc ID 1578.1)
• RMANを使用してデータベース内のすべての破損オブジェクトを特定する方法(Doc ID 472231.1)
• ORA-1578 / RMAN / DBVERIFYによって報告された破損オブジェクトを特定する方法(Doc ID 819533.1)
• Oracle Database破損の問題の処理に関する重要なノート

ノート: RMANを使用して、物理的に破損した1つ以上のデータ・ブロックをリカバリできます。また、リアルタイム適用でActive Data Guardを使用すると、物理データ破損の自動ブロック修復が自動的に実行されます。

プライマリまたはスタンバイ・データベースでの書込みの欠落(ORA-00752、ORA-00753、および最初の引数が3020のORA-00600)を原因とする論理破損の場合、これらはプライマリで、またはスタンバイのREDO適用プロセスで検出されます。次のノートが役立ちます:

• Oracle Database破損の問題の処理に関する重要なノート
• スタンバイが存在し、プライマリまたはスタンバイに書込みの欠落の破損がある場合は、スタンバイ・リカバリ時のORA-00752またはORA-600 [3020]の解決(Doc ID 1265884.1)を参照してください。

論理破損(通常は引数がkdsgrp1、kclchkblk_3、13013または5463のORA-00600から検出)の場合

• 検出されたエラーの詳細は、Oracle Database破損の問題の処理に関する重要なノートを参照してください。
• スタンバイが存在し、プライマリに論理破損がある場合は、フィジカル・スタンバイ・データベースでの論理ブロック破損エラーの解決(Doc ID 2821699.1)を参照してください。

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

イベント名:

HEALTH.DB_CLUSTER.CDB.ARCHIVER_HANG

イベント摘要:

コンテナ・データベース(CDB)がアクティブなオンラインREDOログをアーカイブできない場合、またはアクティブなオンラインREDOログをログ・アーカイブ保存先に迅速にアーカイブできない場合、CRITICALタイプのイベントが作成されます。

問題の内容:

ログ・ライター(LGWR)がログ・バッファをオンラインREDOログに書き込めないため、CDB RACインスタンスが一時的または永続的に停止している可能性があります。これは、すべてのオンライン・ログにアーカイブが必要であるために発生します。アーカイバ(ARC)が1つ以上のオンラインREDOログをアーカイブできると、LGWRはオンラインREDOログへのログ・バッファの書込みを再開でき、アプリケーションの影響は軽減されます。

リスク:

アーカイバが一時的に応答しなくなった場合、データベースの変更をコミットしようとすると、アプリケーションで短いブラウンアウトまたはストールが発生することがあります。アーカイバが復元されない場合、アプリケーションプロセスの処理に長い遅延が発生する可能性があります。

アクション/修復:

• 各スレッド/インスタンスの1時間ごとの頻度を確認するには、REDOログ・スイッチ履歴およびRACの各インスタンスのアーカイブ・ログ・サイズを検索するスクリプト(Doc ID 2373477.1)を参照してください。

  • 1時間当たりのバケットが12より大きい場合は、オンラインREDOログのサイズを変更することを検討してください。サイズ変更のステップは、次の項目2を参照してください。

• データベースが一時的に応答しなくなった場合、アーカイバは生成されたREDOログに遅れることがあります。

  • alert.log、$ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.logで「All online logs need archiving」を確認してください。短期間の複数のイベントは、2つの可能な解決策を示します。
    1. スレッド当たりのREDOログ・グループの数が4未満の場合は、4に達するために他のログ・グループを追加することを検討してください。REDOログ追加のステップは、次の項目1を参照してください。
    2. もう1つの可能な解決策は、REDOログのサイズを変更することです。サイズ変更のステップは、次の項目2を参照してください。
• Data Guardおよび非Data Guardのサイズ設定のガイドラインは、オンラインREDOログの適切な構成を参照してください。

• スレッドごとにREDOログ・グループを追加します。追加のREDOログは、現在のログ・サイズと同じである必要があります。

  1. 次の問合せを使用します:

     select max(group#) Ending_group_number, thread#,
         count(*) number_of_groups_per_thread,
         bytes redo_size_in_bytes from v$log group by thread#,bytes

  2. 現在のREDOログと同じサイズを使用して、スレッドごとに1つの新しいグループを追加します。

     alter database add logfile thread <thread_number>
         group <max group + 1> ('<DATA_DISKGROUP>') size <redo_size_in_bytes>

• より大きいREDOログを追加し、現在の小さいREDOログを削除することで、オンラインREDOログのサイズを変更します。

  1. 次の問合せを使用します:

     select max(group#) Ending_group_number, thread#,
         count(*) number_of_groups_per_thread,
         bytes redo_size_in_bytes from v$log group by thread#,bytes

  2. 現在存在するスレッドnumber_of_groups_per_threadごとに、同じ数のREDOログを追加します。new_redo_size_in_bytesは、オンラインREDOログの適切な構成に基づいて設定する必要があります。

     1. 次の問合せを使用します:

        alter database add logfile thread <thread_number>
            group <max group + 1> ('<DATA_DISKGROUP>') size <new_redo_size_in_bytes>

     2. 元の小さいREDOログは削除する必要があります。REDOログは、そのステータスが非アクティブの場合にのみ削除できます。REDOログのステータスを確認するには、次のselectを発行します。

        select group#, thread#, status, bytes from v$log order by bytes, group#, thread#;

        元の小さいREDOログを削除します:

        alter database drop logfile <group#>;

• データベースが応答しなくなった場合、プライマリ・ログ・アーカイブの宛先および代替の場所がいっぱいになる可能性があります。

  • RECOおよびDATAディスク・グループの領域の解放の詳細は、HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACEを参照してください。

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

イベント名:

HEALTH.DB_CLUSTER.CDB.DATABASE_HANG

イベント摘要:

プロセスまたはセッションがコンテナ・データベース(CDB)で応答しなくなると、CRITICALタイプのイベントが作成されます。

問題の内容:

ブロッカ・リゾルバは、応答しないプロセスまたはブロックを検出し、ORA-32701エラー・メッセージを生成しました。また、診断プロセス(DIA0)によってクリティカル・データベース・プロセスが応答しなくなったことが検出されると、このイベントが発生する可能性があります。

リスク:

応答しないプロセスまたはブロックは、リソース、オペレーティング・システムまたはアプリケーション・コーディングに関連する問題を示す場合があります。

アクション/修復:

セッション・ブロックの原因を調査します。

• イベントの日時に対応するORA-32701、"DIA0 Critical Database Process Blocked"または"DIA0 Critical Database Process As Root"というメッセージ・パターンについて、データベースのTFAイベントを確認します。

  tfactl events -database <dbName> -instance <instanceName>

• 次の場所に関連付けられているalert.logを確認します:

  $ORACLE_BASE/diag/rdbms/<dbName>/<instanceName>/trace/alert_<instanceName>.log

• ORA-32701の場合: 過負荷になったシステムでは、処理速度が遅くなり、ブロックとして解釈される可能性があります。ブロッカ・リゾルバは、最終的なブロッカ・プロセスを終了することによってブロックの解決を試みる場合があります。
• DIA0クリティカル・データベース・プロセス・メッセージの場合は、プロセスおよびブロックの理由を示している関連する診断行を確認します。

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

イベント名:

HEALTH.DB_CLUSTER.CDB.BACKUP_FAILURE

イベント摘要:

v$rman_statusビューにFAILEDステータスがレポートされたCDBバックアップがある場合、CRITICALタイプのイベントが作成されます。

問題の内容:

CDBの日次増分バックアップが失敗しました。

リスク:

バックアップが失敗すると、データベースのリストア/リカバリにバックアップを使用できなくなることがあります。リカバリ・ポイント目標(RPO)およびリカバリ時間目標(RTO)が影響を受ける可能性があります。

アクション/修復:

イベントの日時に対応するRMANログを確認します。イベント・タイムスタンプeventTimeはUTCで示されているため、VMのタイムゾーンの必要に応じて調整してください。

Oracle管理バックアップの場合:

• RMAN出力は、/opt/oracle/dcs/log/<hostname>/RMANにあります。

• 障害についてログを確認します:

  • 障害の原因がRMANの外部のイベントである場合(たとえば、バックアップの場所がいっぱいだったりネットワーキングの問題だったりした場合)、その外部の問題を解決します。

  • その他のRMANスクリプト・エラーについては、診断ログを収集し、サービス・リクエストをオープンします。

    dbcli collect-diagnostics -h

    Usage: collect-diagnostics [options]
      Options:
        --components, -c
           Supported components: [all, dcs, crs, acfs, asm, db]
           all -- Collects diagnosis for all supported components [all, dcs, crs, acfs, asm, db]
           dcs -- Collects diagnosis for dcs
           crs -- Collects diagnosis for crs
           acfs -- Collects diagnosis for acfs
           asm -- Collects diagnosis for asm.
           db -- Collects diagnosis for db.
           For multiple parameter values, follow the example as "-c c1 c2"
           Default: [dcs]
        --dbNames, -d
           Comma separated database names. Valid only if 'db' or 'all' specified in Components list.
        --endTime, -et
           End time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format
        --help, -h
           get help
        --json, -j
           json output
        --objectstoreuri, -ou
           Pre Authenticated Request URI
        --redaction, -r
           Diagnostic logs redaction. Might take longer time with some components.
        --startTime, -st
        Start time of diagnostic logs. Please give time in yyyy-MM-dd HH:mm:ss format

• 問題が一時的である場合、または解決された場合は、新しい増分バックアップを作成します。詳細は、コンソールを使用したデータベースのバックアップに関する項を参照してください。

RMANを使用して取得された顧客所有および管理のバックアップの場合:

• バックアップについてRMANログを確認します。

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

イベント名:

HEALTH.DB_CLUSTER.DISK_GROUP.FREE_SPACE

イベント摘要:

ASMディスク・グループの領域使用率が90%以上に達すると、CRITICALタイプのイベントが作成されます。ASMディスク・グループの領域使用率が90%未満になると、INFORMATIONタイプのイベントが作成されます。

問題の内容:

ASMディスク・グループの領域使用量が90%以上です。

リスク:

ASMディスク・グループ領域が不足すると、データベース作成の失敗、表領域およびデータ・ファイル作成の失敗、自動データ・ファイル拡張の失敗、またはASMリバランスの失敗が発生する可能性があります。

アクション/修復:

ASMディスク・グループの使用済領域を確認するには、ASMインスタンスへの接続中に次の問合せを実行します。

sudo su - grid
sqlplus / as sysasm

select 'ora.'||name||'.dg', total_mb, free_mb,
    round ((1-(free_mb/total_mb))*100,2) pct_used from v$asm_diskgroup;

NAME             TOTAL_MB    FREE_MB   PCT_USED
---------------- ---------- ---------- ----------
ora.DATAC1.dg     75497472    7408292      90.19
ora.RECOC1.dg     18874368   17720208       6.11

ASMディスク・グループの容量は、次の方法で増やすことができます:

1. VMクラスタ・ストレージをスケーリングして、ASMディスク・グループの容量を追加します。詳細は、DB Systemのスケーリングを参照してください。

DATAディスク・グループの領域使用量は、次の方法で減らすことができます:

1. 未使用のデータ・ファイルおよび一時ファイルをデータベースから削除します。詳細は、データ・ファイルの削除を参照してください。

RECOディスク・グループの領域使用量は、次の方法で減らすことができます:

1. 不要な保証付きリストア・ポイントを削除します。詳細は、通常のリストア・ポイントと保証付きリストア・ポイントの使用を参照してください。
2. フラッシュ・リカバリ領域(FRA)の外部ですでにバックアップされているアーカイブREDOログまたはデータベース・バックアップを削除します。詳細は、Fast Recovery Areaのメンテナンスを参照してください。