機械翻訳について

データベース・サービス・イベントの改善

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

次の修正を使用できます:

• 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ソフトウェア(データベース、Clusterware、クラウド・ツール)でエラーや障害が発生する可能性があります。

アクション/修復

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

イベントの説明

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

問題の内容

Cluster Ready Stackがオフライン状態であるか、失敗しました。

リスク

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

イベントの説明

タイプがCRITICALのイベントは、Cluster Ready Service (CRS)がクラスタからノードを削除したときに作成されます。 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)トレース・ファイル・アナライザ(TFA) & ORAchk/EXAchk」を参照してください。 CRSノードの削除のトラブルシューティングの詳細は、「Clusterwareノードの削除のトラブルシューティング(リブート)」を参照してください。

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

イベント名

AVAILABILITY.DB_CLUSTER.SCAN_LISTENER.DOWN

イベントの説明

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

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

問題の内容

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

リスク

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

アクション/修復

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

INFORMATIONタイプのDOWNイベント

1. グリッド・インフラストラクチャ・ソフトウェア更新の実行など、Oracle Cloudメンテナンス・アクションによってイベントが発生した場合、アクションは必要ありません。 影響を受ける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. CRSログとOSログの両方を、ログに示されている<hostName>に対して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)コマンド、またはグリッド・インフラストラクチャ・ソフトウェア更新の実行など、これらのコマンドを使用するOracle Cloudメンテナンス・アクションなど、ユーザー・アクションによってクライアント・リスナーが停止される場合です。 クライアント・リスナーが予期せず停止した場合、イベントのタイプはCRITICALです。 対応するDOWN_CLEAREDイベントは、クライアント・リスナーの起動時に作成されます。

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

問題の内容

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

リスク

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

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

アクション/修復

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

INFORMATIONタイプのDOWNイベント

1. グリッド・インフラストラクチャ・ソフトウェア更新の実行など、Oracle Cloudメンテナンス・アクションによってイベントが発生した場合、アクションは必要ありません。 グリッド・インスタンスに影響するメンテナンスが完了すると、影響を受けるクライアント・リスナーが自動的に再起動されます。
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を使用して、CRSログとOSログの両方を30分前に収集し、ログに示hostNameに対して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メンテナンス・アクションなど、ユーザー・アクションによってデータベース・インスタンスが停止される場合です。 データベース・インスタンスが予期せず停止した場合、イベントのタイプは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. データベースのトレース・ファイル・アナライザ(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の最初の引数を持つORA-00600または5463から通常検出)でトリガーされます。

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

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

物理的破損またはORA-1578エラーの場合、次のノートが役立ちます:

• OERR: ORA-1578「ORACLEデータ・ブロックが破損しています(ファイル番号%s、ブロック番号%s)」プライマリ・ノート(ドキュメントID 1578.1)
• RMANによるデータベースの破損したすべてのオブジェクトの識別方法(ドキュメントID 472231.1)
• ORA-1578 / RMAN / DBVERIFY (Doc ID 819533.1)によってレポートされた破損オブジェクトの識別方法
• Oracle Database破損の問題を処理するための主なノート

ノート:

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

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

• Oracle Database破損の問題を処理するための主なノート
• プライマリまたはスタンバイでスタンバイ状態および書き込み破損が失われた場合は、「スタンバイ・リカバリ中のORA-00752またはORA-600 [3020]の解決(ドキュメントID 1265884.1)」を参照してください。

論理的な破損の場合(ORA-00600からkdsgrp1, kclchkblk_3, 13013または5463の引数で検出される標準)

• 検出されたエラーの詳細については、「Oracle Database破損の問題を処理するための主なノート」を参照してください。
• プライマリでスタンバイおよび論理的な破損がある場合は、「フィジカル・スタンバイ・データベースでの論理ブロック破損エラーの解決(ドキュメント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ログへの書込みを再開でき、アプリケーションの影響が軽減されます。

リスク

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

アクション/修復

• 各スレッド/インスタンスの時間ごとの頻度を確認するには、「REDOログ・スイッチ履歴を検索し、RACの各インスタンスのアーカイブ・ログ・サイズを検索するスクリプト(ドキュメントID 2373477.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ログの追加のステップについては、次のitem1を参照してください。
    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 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

イベントの説明

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

問題の内容

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

リスク

応答しないプロセスまたはブロックは、リソース、オペレーティング・システムまたはアプリケーション・コーディング関連の問題を示すことができます。

アクション/修復

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

• データベースのTFAイベントで、イベントの日時に対応する次のメッセージ・パターンを確認: ORA-32701、"DIA0クリティカル・データベース・プロセスがブロックされました"または"DIA0ルートとしてのクリティカル・データベース・プロセス"。

  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

イベントの説明

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

問題の内容

CDBの日次増分BACKUPが失敗しました。

リスク

バックアップが失敗すると、データベースのリストア/リカバリ可能性にバックアップを使用する機能が損なわれる可能性があります。 リカバリ・ポイント・オブジェクト(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

イベントの説明

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

問題の内容

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のメンテナンス」を参照してください。

---

タイトルおよび著作権情報

Copyright ©2022,2025,

Oracle and/or its affiliates.