1. データベース管理者ガイド
  2. Oracle Databaseの構造と記憶域
  3. REDOログの管理

11 REDOログの管理

REDOログの管理では、REDOログ・グループおよびメンバーの作成、REDOログ・メンバーの再配置および名前変更、REDOログ・グループおよびメンバーの削除、ログ・スイッチの強制などのタスクを完了します。

  • REDOログの概要
    リカバリ操作にとって最も重要な構造であるREDOログは、2つ以上の事前に割り当てられたファイルで構成されており、データベースへの変更があるたびにその変更内容が格納されます。Oracle Databaseの各インスタンスには、インスタンス障害の場合にデータベースを保護するためにREDOログが関連付けられています。
  • REDOログの計画
    データベース・インスタンスREDOログを構成する場合は、ガイドラインに従うことができます。
  • REDOログ・グループおよびメンバーの作成
    データベースのREDOログを事前に計画し、データベースの作成時に必要なREDOログ・ファイルのグループとメンバーをすべて作成してください。しかし、グループやメンバーの追加作成が必要な状況もあります。たとえば、REDOログにグループを追加することによって、REDOログ・グループの可用性の問題を解決できます。
  • REDOログ・メンバーの再配置および名前変更
    オペレーティング・システムのコマンドを使用してREDOログを再配置し、ALTER DATABASE文を使用してデータベースにそのREDOログの新しい名前(位置)を通知できます。
  • REDOログ・グループおよびメンバーの削除
    場合によっては、REDOログ・メンバーを含むグループ全体を削除できます。
  • ログ・スイッチの強制
    ログ・スイッチは、LGWRがあるREDOログ・グループへの書込みを中止して、別のログ・グループへの書込みを開始するときに発生します。デフォルトでは、現行のREDOログ・ファイル・グループが一杯になると、ログ・スイッチが自動的に発生します。
  • REDOログ・ファイル内のブロックの検証
    データベースは、チェックサムを使用してREDOログ・ファイル内のブロックを検証するように構成できます。
  • REDOログ・ファイルのクリア
    データベースがオープンしている間にREDOログ・ファイルが破損し、その結果アーカイブが継続できなくなり、データベース・アクティビティが停止することがあります。
  • FORCE LOGGING設定の優先順位
    FORCE LOGGINGおよびNOLOGGINGは、データベース、プラガブル・データベース(PDB)、表領域またはデータベース・オブジェクトなどの様々なレベルで設定できます。1つ以上のレベルでFORCE LOGGINGが設定されている場合、FORCE LOGGING設定の優先順位によってREDOログに記録される内容が決まります。
  • REDOログ・データ・ディクショナリ・ビュー
    REDOログの情報について、一連のデータ・ディクショナリ・ビューを問い合せることができます。

関連項目:

Oracle Databaseサーバーによって作成および管理されるREDOログ・ファイルの詳細は、「Oracle Managed Filesの使用」

親トピック: Oracle Databaseの構造と記憶域

11.1 REDOログの概要

リカバリ操作にとって最も重要な構造であるREDOログは、2つ以上の事前に割り当てられたファイルで構成されており、データベースへの変更があるたびにその変更内容が格納されます。Oracle Databaseの各インスタンスには、インスタンス障害の場合にデータベースを保護するためにREDOログが関連付けられています。

  • REDOスレッド
    複数のデータベース・インスタンスに関する内容では、各データベース・インスタンスのREDOログはREDOスレッドとも呼ばれます。
  • REDOログの内容
    REDOログ・ファイルには、REDOレコードが書き込まれます。
  • Oracle DatabaseによるREDOログへの書込み
    データベースのREDOログは、2つ以上のREDOログ・ファイルから構成されます。データベースでは、一方のファイルのアーカイブ中にも(データベースがARCHIVELOGモードのとき)、他方のファイルが常に書込み可能であることを保証するために、最低2つのファイルを必要とします。

親トピック: REDOログの管理

11.1.1 REDOスレッド

複数のデータベース・インスタンスに関する内容では、各データベース・インスタンスのREDOログはREDOスレッドとも呼ばれます。

標準的な構成では、Oracle Databaseにアクセスするデータベース・インスタンスは1つのみであるため、スレッドは1つしか存在しません。ただし、Oracle Real Application Clusters環境では、複数のインスタンスが単一のデータベースに同時にアクセスし、各インスタンスが専用のREDOスレッドを持ちます。各インスタンスが別々のREDOスレッドを使用するため、1つのセットのREDOログ・ファイルで競合が回避され、その結果、潜在的なパフォーマンスのボトルネックを解消できます。

この章では、標準的な単一インスタンスのOracle Databaseで、REDOログを構成して管理する方法について説明します。文のすべての説明と例では、スレッド番号を1と想定します。Oracle Real Application Clusters環境におけるREDOログ・グループについては、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

親トピック: REDOログの概要

11.1.2 REDOログの内容

REDOログ・ファイルには、REDOレコードが書き込まれます。

REDOレコードはREDOエントリとも呼ばれ、変更ベクトル(データベース内の単一ブロックに加えられた変更の記述)のグループからなっています。たとえば、従業員表の給与値を変更する場合は、その表のデータ・セグメント・ブロック、UNDOセグメント・データ・ブロックおよびUNDOセグメントのトランザクション表の変更内容を記述する変更ベクトルを含むREDOレコードが生成されます。

REDOエントリには、UNDOセグメントなど、データベースに対するすべての変更の再構築に使用できるデータが記録されます。したがって、REDOログによってロールバック・データも保護されます。REDOデータベースを使用してデータベースをリカバリすると、データベースはREDOレコード内の変更ベクトルを読み込んで変更内容を関連ブロックに適用します。

REDOレコードは、循環方式でシステム・グローバル領域(SGA)のREDOログ・バッファに入れられ(「Oracle DatabaseによるREDOログへの書込み」を参照)、データベースのバックグラウンド・プロセスであるログ・ライター(LGWR)によってREDOログ・ファイルの1つに書き込まれます。トランザクションがコミットされると、LGWRによってそのトランザクションのREDOレコードがSGAのREDOログ・バッファからREDOログ・ファイルに書き込まれ、コミットされた各トランザクションのREDOレコードを識別するためにシステム変更番号 (SCN)が割り当てられます。特定のトランザクションに対応付けられたすべてのREDOログ・レコードがディスク上のオンライン・ログに安全に書き込まれた場合にのみ、ユーザー・プロセスはトランザクションがコミットされたことを示す通知を受け取ります。

また、REDOレコードは、対応するトランザクションがコミットされる前にREDOログ・ファイルに書き込むこともできます。REDOログ・バッファが一杯になるか、別のトランザクションがコミットされると、一部のREDOレコードがコミットされていない可能性があっても、LGWRはREDOログ・バッファ内のすべてのREDOログ・エントリをREDOログ・ファイルにフラッシュします。データベースでは、必要に応じて、これらの変更をロールバックできます。

親トピック: REDOログの概要

11.1.3 Oracle DatabaseによるREDOログへの書込み

データベースのREDOログは、2つ以上のREDOログ・ファイルから構成されます。データベースでは、一方のファイルのアーカイブ中にも(データベースがARCHIVELOGモードのとき)、他方のファイルが常に書込み可能であることを保証するために、最低2つのファイルを必要とします。

詳細は、「アーカイブREDOログ・ファイルの管理」を参照してください。

LGWRは、REDOログ・ファイルに循環方式で書き込みます。つまり、現行のREDOログ・ファイルが一杯になると、LGWRは次に使用可能なREDOログ・ファイルへの書込みを開始します。使用可能な最後のREDOログ・ファイルが一杯になると、LGWRは最初のREDOログ・ファイルに戻って書込みを行い、再び循環を開始します。図11-1に、REDOログ・ファイルへの循環方式の書込みを示します。各ラインの隣の番号は、LGWRが各REDOログ・ファイルに書き込む順序を示しています。

一杯になったREDOログ・ファイルは、アーカイブが使用可能になっているかどうかに応じて、LGWRで再利用できます。

  • アーカイブが使用禁止になっている場合(データベースがNOARCHIVELOGモードのとき)、一杯になったREDOログ・ファイルは、そこに記録された変更がデータファイルに書き込まれた後に使用可能になります。

  • アーカイブが有効(データベースがARCHIVELOGモード)の場合は、記録された変更がデータファイルに書き込まれ、さらにそのファイルがアーカイブされた後、一杯になったREDOログ・ファイルをLGWRで使用できるようになります。

図11-1 LGWRによるREDOログ・ファイルの再利用

図11-1の説明が続きます
「図11-1 LGWRによるREDOログ・ファイルの再利用」の説明
  • アクティブ(カレント)および非アクティブなREDOログ・ファイル
    Oracle Databaseは、REDOログ・ファイルを一度に1つのみ使用して、REDOログ・バッファから書き込まれたREDOレコードを格納します。LGWRが書込み中のREDOログ・ファイルを現行のREDOログ・ファイルと呼びます。
  • ログ・スイッチとログ順序番号
    ログ・スイッチは、データベースが、あるREDOログ・ファイルへの書込みを終了して他のファイルへの書込みを開始するポイントです。現行のREDOログ・ファイルが完全に一杯になり、引き続き次のREDOログ・ファイルへの書込みが必要になると、通常はログ・スイッチが発生します。

親トピック: REDOログの概要

11.1.3.1 アクティブ(カレント)および非アクティブなREDOログ・ファイル

Oracle Databaseは、REDOログ・ファイルを一度に1つのみ使用して、REDOログ・バッファから書き込まれたREDOレコードを格納します。LGWRが書込み中のREDOログ・ファイルを現行のREDOログ・ファイルと呼びます。

インスタンス・リカバリに必要なREDOログ・ファイルをアクティブなREDOログ・ファイルと呼びます。また、インスタンス・リカバリには不要なREDOログ・ファイルを 非アクティブなREDOログ・ファイルと呼びます。

アーカイブを使用可能にしている場合は(データベースがARCHIVELOGモードのとき)、いずれかのアーカイバ・バックグラウンド・プロセス(ARCn)によって内容がアーカイブされるまで、データベースはアクティブなオンライン・ログ・ファイルの再利用または上書きができません。アーカイブが使用禁止になっている場合(データベースがNOARCHIVELOGモードのとき)は、最後のREDOログ・ファイルが一杯になって非アクティブになると、LGWRは順序内の次のログ・ファイルを上書きして書込みを継続します。

11.1.3.2 ログ・スイッチとログ順序番号

ログ・スイッチは、データベースが、あるREDOログ・ファイルへの書込みを終了して他のファイルへの書込みを開始するポイントです。現行のREDOログ・ファイルが完全に一杯になり、引き続き次のREDOログ・ファイルへの書込みが必要になると、通常はログ・スイッチが発生します。

ただし、ログ・スイッチは、現行のREDOログ・ファイルが完全に一杯になっているかどうかに関係なく、定期的に発生するように構成できます。ログ・スイッチは、手動で強制的に発生させることもできます。

Oracle Databaseは、ログ・スイッチが発生してLGWRが書込みを開始するたびに、各REDOログ・ファイルに新しいログ順序番号を割り当てます。データベースがREDOログ・ファイルをアーカイブしても、そのファイルのログ順序番号は変わりません。一巡して再び使用可能になったREDOログ・ファイルには、次に使用可能なログ順序番号が割り当てられます。

各オンラインREDOログ・ファイルまたはアーカイブREDOログ・ファイルは、そのログ順序番号で一意に識別されます。クラッシュ、インスタンスまたはメディア・リカバリ時に、データベースでは、必要なアーカイブおよびREDOログ・ファイルのログ順序番号を使用して、REDOログ・ファイルが昇順で正しく適用されます。

11.2 REDOログの計画

データベース・インスタンスREDOログを構成する場合は、ガイドラインに従うことができます。

  • REDOログ・ファイルの多重化
    REDOログそのものに関わる障害から保護するために、Oracle Databaseでは多重REDOログ、つまりREDOログの2つ以上の同一のコピーを異なる場所に自動的に維持する機能を使用できます。
  • 異なるディスクへのREDOログ・メンバーの配置
    多重REDOログ・ファイルを設定する場合は、グループのメンバーを異なる物理ディスク上に配置します。このようにすると、1つのディスクで障害が発生しても、LGWRが使用できなくなるのはグループの1つのメンバーのみで、それ以外のメンバーは引き続きLGWRにアクセスできるので、インスタンスは継続して機能します。
  • REDOログ・ファイルのサイズの計画
    REDOログ・ファイルのサイズを設定するときは、REDOログをアーカイブするかどうかを考慮してください。REDOログ・ファイルのサイズは、一杯になったグループを1つのオフライン記憶メディア(テープやディスクなど)にアーカイブできるとともに、そのメディア上の未使用領域が最小になるように設定します。
  • REDOログ・ファイルのブロック・サイズの計画
    2KBから32KBの間で設定可能なデータベース・ブロック・サイズと異なり、REDOログ・ファイルではディスクの物理セクター・サイズと同じブロック・サイズが常にデフォルトとなります。これは通例として512バイトです。
  • 適切なREDOログ・ファイル数の選択
    データベース・インスタンスに対するREDOログ・ファイルの適切な数を決定する最良の方法は、様々な構成をテストすることです。最適な構成では、LGWRがREDOログ情報を書き込むのを妨げない最小の数がグループ数になります。
  • アーカイブ・タイムラグの制御
    すべての有効なREDOログ・スレッドが定期的に現在のログを切り替えるように強制できます。

親トピック: REDOログの管理

11.2.1 REDOログ・ファイルの多重化

REDOログそのものに関わる障害から保護するために、Oracle Databaseでは多重REDOログ、つまりREDOログの2つ以上の同一のコピーを異なる場所に自動的に維持する機能を使用できます。

これを最大限に活用するには、これらの場所は異なるディスク上に置きます。ただし、REDOログのすべてのコピーが同じディスク上にあっても、冗長性によってI/Oエラー、ファイル破損などに対して保護されます。REDOログ・ファイルを多重化すると、LGWRによって同じREDOログ情報が複数の同一のREDOログ・ファイルに書き込まれるため、REDOログの単一の障害箇所は問題になりません。

多重化を実装するには、REDOログ・ファイルのグループを作成します。グループは、REDOログ・ファイルとその多重化されたコピーで構成されます。それぞれの同一コピーはグループのメンバーと呼ばれます。各REDOログ・グループは、グループ1、グループ2のように数値で定義されます。

図11-2 多重REDOログ・ファイル

図11-2の説明が続きます
「図11-2 多重REDOログ・ファイル」の説明

図11-2では、A_LOG1とB_LOG1はどちらもグループ1のメンバーで、A_LOG2とB_LOG2はどちらもグループ2のメンバーです。同じグループの各メンバーは同じサイズである必要があります。

LGWRによって割り当てられる同一のログ順序番号で示されるように、ログ・ファイル・グループの各メンバーは同時にアクティブ(LGWRによって同時に書き込まれる)になります。図11-2では、最初にLGWRはA_LOG1およびB_LOG1の両方に同時に書き込みます。次にA_LOG2およびB_LOG2の両方に同時に書き込み、以下同様に続きます。LGWRでは、異なるグループのメンバー(たとえばA_LOG1とB_LOG2)に同時に書き込まれることはありません。

注意:

REDOログ・ファイルは多重化することをお薦めします。これは、リカバリが必要になったときにログ・ファイルのデータが失われていると、致命的な事態を招くおそれがあるためです。REDOログを多重化すると、データベースの実行時のI/Oの量が増加するため注意してください。構成によっては、これによってデータベース・パフォーマンス全体が影響を受けます。

  • REDOログの障害への対処
    LGWRがグループのメンバーに書き込めない場合、データベースはそのメンバーにINVALIDを示すマークを付け、LGWRトレース・ファイルとデータベース・アラート・ログに、アクセス不可能ファイルの問題を示すエラー・メッセージを書き込みます。
  • 有効な構成と無効な構成
    ほとんどの場合、多重REDOログを対称にします(すべてのREDOログのグループに同じ数のメンバーを使用します)。ただし、データベースにとっては、多重REDOログが対称である必要はありません。

親トピック: REDOログの計画

11.2.1.1 REDOログの障害への対処

LGWRがグループのメンバーに書き込めない場合、データベースはそのメンバーにINVALIDを示すマークを付け、LGWRトレース・ファイルとデータベース・アラート・ログに、アクセス不可能ファイルの問題を示すエラー・メッセージを書き込みます。

REDOログ・メンバーが使用不可能な場合のLGWR固有の処理は、次の表に示すように、使用不可能になった理由によって決定します。

条件 LGWRの処理

LGWRがグループ内の最低1つのメンバーに正常に書き込める場合

通常どおり書込みが行われます。LGWRはグループのうち使用可能なメンバーにのみ書き込み、使用不可のメンバーは無視します。

グループをアーカイブする必要があるため、LGWRがログ・スイッチの発生時に次のグループにアクセスできない場合

データベース操作は、グループが使用可能になるか、グループがアーカイブされるまで一時的に停止します。

メディア障害のため、ログ・スイッチの発生時にLGWRが次のグループのどのメンバーにもアクセスできない場合

Oracle Databaseはエラーを返し、データベース・インスタンスは停止します。この場合は、データベース上でREDOログ・ファイルの損失からのメディア・リカバリを実行する必要があります。

データベースのチェックポイントが損失したREDOログを超えて移動した場合、そのREDOログに記録されたデータは、データベースによってデータファイルに保存されているため、メディア・リカバリは必要ありません。アクセスできないREDOログ・グループのみ削除してください。データベースによって不良ログがアーカイブされていない場合は、ALTER DATABASE CLEAR LOGFILE UNARCHIVEDを使用してアーカイブを使用禁止にしてから、ログを削除してください。

LGWRが書込み中に、グループのすべてのメンバーに突然アクセスできなくなった場合

Oracle Databaseはエラーを返し、データベース・インスタンスは即座に停止します。この場合は、メディア・リカバリを実行する必要があります。ログのドライブを不注意からオフにした場合など、ログを含むメディアが実際には失われていなければ、メディア・リカバリは不要です。この場合は、ドライブをオンに戻して、データベースで自動インスタンス・リカバリを実行します。
11.2.1.2 有効な構成と無効な構成

ほとんどの場合、多重REDOログを対称にします(すべてのREDOログのグループに同じ数のメンバーを使用します)。ただし、データベースにとっては、多重REDOログが対称である必要はありません。

たとえば、1つのグループには1つのメンバーのみを含め、他のグループには2つのメンバーを含められます。この構成によって、一時的に一部のREDOログ・メンバーに影響を与えても他のメンバーに影響が及ばないようなディスク障害に対して保護できます。

インスタンスのREDOログに関する唯一の要件は、最低2つのグループを持つことです。図11-3に、多重REDOログに有効な構成と無効な構成を示します。2番目の構成は、グループが1つしかないため無効です。

図11-3 多重REDOログ・ファイルの有効な構成と無効な構成

図11-3の説明が続きます
「図11-3 多重REDOログ・ファイルの有効な構成と無効な構成」の説明

11.2.2 異なるディスクへのREDOログ・メンバーの配置

多重REDOログ・ファイルを設定する場合は、グループのメンバーを異なる物理ディスク上に配置します。このようにすると、1つのディスクで障害が発生しても、LGWRが使用できなくなるのはグループの1つのメンバーのみで、それ以外のメンバーは引き続きLGWRにアクセスできるので、インスタンスは継続して機能します。

REDOログをアーカイブする場合は、バックグラウンド・プロセスLGWRとARCn間の競合をなくすために、REDOログ・メンバーを複数のディスクに分散します。たとえば、多重化REDOログ・メンバーのグループが2つある場合(二重化REDOログ)、各メンバーを異なるディスクに配置し、アーカイブ先を5つ目のディスクに設定します。このようにすると、LGWR(メンバーへの書込み)とARCn(メンバーの読込み)間の競合は発生しません。

データ・ブロックやREDOレコードの書込み時の競合を減らすために、データファイルもREDOログ・ファイルとは異なるディスク上に配置することをお薦めします。

親トピック: REDOログの計画

11.2.3 REDOログ・ファイルのサイズの計画

REDOログ・ファイルのサイズを設定するときは、REDOログをアーカイブするかどうかを考慮してください。REDOログ・ファイルのサイズは、一杯になったグループを1つのオフライン記憶メディア(テープやディスクなど)にアーカイブできるとともに、そのメディア上の未使用領域が最小になるように設定します。

たとえば、一杯になった1つのREDOログ・グループを1本のテープにアーカイブし、そのテープの記憶容量の49%が未使用のまま残っているとします。この場合は、REDOログ・ファイルのサイズを小さくして、テープごとに2つずつREDOログ・グループがアーカイブされるように構成することをお薦めします。

同一の多重REDOログ・グループのメンバーは、すべて同じサイズにする必要があります。異なるグループのメンバーは異なるサイズにすることができます。ただし、グループ間でファイル・サイズを変えても特に利点はありません。ログ・スイッチ間にチェックポイントが発生するように設定していない場合は、グループのサイズを同一に設定して、チェックポイントが一定の間隔で発生することを保証してください。

REDOログ・ファイルの最小サイズは4MBです。

関連項目:

使用しているオペレーティング・システム固有のOracleマニュアルを参照してください。REDOログ・ファイルのデフォルトのサイズは、オペレーティング・システムによって異なります。

親トピック: REDOログの計画

11.2.4 REDOログ・ファイルのブロック・サイズの計画

2KBから32KBの間で設定可能なデータベース・ブロック・サイズと異なり、REDOログ・ファイルではディスクの物理セクター・サイズと同じブロック・サイズが常にデフォルトとなります。これは通例として512バイトです。

新しい大容量ディスク・ドライブでは、ECC機能およびフォーマット効率向上のために4KBのセクター・サイズを提供しているものもあります。Oracle Databaseプラットフォームの大部分では、この大きい方のセクター・サイズを検出できます。その後、データベースはブロック・サイズが4KBのREDOログ・ファイルをそれらのディスク上に自動的に作成します。

ただし、4KBのブロック・サイズでは、REDO時のディスク領域の消費が増加します。実際に、4KBのブロックと512バイトのブロックではREDO時のディスク領域の消費量は大幅に異なります。V$SESSTATおよびV$SYSSTATビューに格納されている統計を表示して、REDO時のディスク領域の消費量を判別できます。 

SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo wastage';
 
NAME                                  VALUE
-------------------------------- ----------
redo wastage                       17941684

REDO時のディスク領域の消費を増やさないようにするために、エミュレーションモードのディスク(ディスクのインタフェースにおいて512バイトのセクター・サイズをエミュレートする、セクター・サイズが4KBのディスク・ドライブ)を使用している場合は、REDOログのブロック・サイズに512バイトまたは一部のプラットフォームで1KBを指定し、デフォルトの4KBをオーバーライドできます。ただし、REDOログの書込みが4KBの物理セクターの始まりの位置と揃えられていない場合は、パフォーマンスが大幅に低下します。4KBの物理セクターで512バイトのスロット8つのうち7つの位置が揃っていないために、通常はパフォーマンスの低下が発生します。このため、セクター・サイズが4Kのエミュレーションモード・ディスク上でREDOログのブロック・サイズを計画する場合には、パフォーマンスおよびディスク領域の消費のバランスを検討する必要があります。

CREATE DATABASE、ALTER DATABASE、およびCREATE CONTROLFILE文内のキーワードBLOCKSIZEによって、オンラインREDOログ・ファイルのブロック・サイズを指定できます。一部のプラットフォームで使用可能なブロック・サイズは、512および4096です。その他のプラットフォームで使用可能なブロック・サイズは、1024および4096です。

次の文は、ブロックサイズが512バイトのREDOログ・ファイルのグループを追加します。BLOCKSIZE 512の句は、セクター・サイズが512バイトのディスクでは有効ですが、必須ではありません。セクター・サイズが4KBのエミュレーションモードのディスクでは、BLOCKSIZE 512の句がデフォルトの4KBをオーバーライドします。 

ALTER DATABASE orcl ADD LOGFILE
  GROUP 4 ('/u01/logs/orcl/redo04a.log','/u01/logs/orcl/redo04b.log')
  SIZE 100M BLOCKSIZE 512 REUSE;

REDOログ・ファイルのブロック・サイズを確認するには、次の問合せを実行します。

SQL> SELECT BLOCKSIZE FROM V$LOG;

BLOCKSIZE
---------
      512

関連項目:

親トピック: REDOログの計画

11.2.5 適切なREDOログ・ファイル数の選択

データベース・インスタンスに対するREDOログ・ファイルの適切な数を決定する最良の方法は、様々な構成をテストすることです。最適な構成では、LGWRがREDOログ情報を書き込むのを妨げない最小の数がグループ数になります。

データベース・インスタンスに必要なグループが2つのみの場合もあります。また、LGWRが使用可能な再利用グループが常に存在するようにするため、データベース・インスタンスにグループを追加する必要がある場合もあります。テスト中に、現行のREDOログ構成に問題がないかどうかを確認するには、LGWRトレース・ファイルおよびデータベース・アラート・ログの内容を調べるのが最も容易です。チェックポイントが未完了か、またはグループがアーカイブされていないため、LGWRが頻繁にグループを待機することをメッセージが示す場合は、グループを追加してください。

インスタンスのREDOログ構成を設定または変更する前に、REDOログ・ファイル数を制限するパラメータを検討してください。次のパラメータは、データベースに追加できるREDOログ・ファイルの数を制限します。

  • CREATE DATABASE文のMAXLOGFILESパラメータは、データベース当たりのREDOログ・ファイルの最大グループ数を決定します。グループの値は1からMAXLOGFILESです。MAXLOGFILESの制限を超えることができ、制御ファイルは必要に応じて拡張します。CREATE DATABASE文にMAXLOGFILESパラメータが指定されていない場合は、オペレーティング・システム固有のデフォルト値が使用されます。

  • CREATE DATABASE文のMAXLOGMEMBERSパラメータは、グループに含まれるメンバーの最大値を決定します。この上限値を変更する唯一の方法は、MAXLOGFILESの場合と同様、データベースまたは制御ファイルを再作成することです。したがって、データベースを作成する前にこの上限値を十分検討してください。CREATE DATABASE文にMAXLOGMEMBERSパラメータが指定されていない場合は、オペレーティング・システムのデフォルト値が使用されます。

    関連項目:

    MAXLOGFILESパラメータおよびMAXLOGMEMBERSパラメータのデフォルト値と有効な値については、オペレーティング・システム固有のOracleマニュアルを参照してください。

親トピック: REDOログの計画

11.2.6 アーカイブ・タイムラグの制御

すべての有効なREDOログ・スレッドが定期的に現在のログを切り替えるように強制できます。

プライマリ/スタンバイ・データベース構成では、REDOログをプライマリ・サイトにアーカイブし、その後スタンバイ・データベースに送信することによって変更がスタンバイ・データベースに反映されます。スタンバイ・データベースは、プライマリ・データベースのREDOログの変更がアーカイブされたREDOログにアーカイブされ、送信されるまで待機する必要があるため、スタンバイ・データベースに適用されている変更は、プライマリ・データベースで発生している変更から遅れることになります。この遅延を制限するために、ARCHIVE_LAG_TARGET初期化パラメータを設定できます。このパラメータを設定して、遅延時間を秒単位で指定できます。

親トピック: REDOログの計画

11.2.6.1 ARCHIVE_LAG_TARGET初期化パラメータの設定

ARCHIVE_LAG_TARGET初期化パラメータを設定した場合、データベースによりインスタンスの現在のREDOログが定期的に確認され、ログを切り替えるタイミングが決定されます。

次の条件が満たされると、インスタンスはログを切り替えます。

  • カレント・ログがn秒前に作成され、カレント・ログのアーカイブ見積り時間がm秒(この時間はカレント・ログで使用されているREDOブロック数に比例する)の場合に、n +mがARCHIVE_LAG_TARGET初期化パラメータの値を超えている。

  • カレント・ログにREDOレコードが含まれている。

Oracle Real Application Clusters環境では、他のスレッドが遅れている場合、インスタンスによって他のスレッドも切り替えられ、ログがアーカイブされます。これは、Oracle Real Application Clustersで2つのノードを持つプライマリ/セカンダリ構成を実行しているときのように、クラスタ内に他のインスタンスよりも稼働率の低いインスタンスがある場合に特に有効です。

ARCHIVE_LAG_TARGET初期化パラメータは、データベースの現在のログの持続時間の上限を秒単位で指定します。予測されるアーカイブ時間も考慮されるため、これは厳密なログ切替え時間ではありません。

  • ARCHIVE_LAG_TARGET初期化パラメータを設定します。

次の初期化パラメータ設定では、ログ・スイッチ間隔を30分(標準的な値)に設定します。

ARCHIVE_LAG_TARGET = 1800

0(ゼロ)を指定すると、時間ベースのログ・スイッチ機能は使用禁止になります。これがデフォルトの設定です。

スタンバイ・データベースが存在していなくても、ARCHIVE_LAG_TARGET初期化パラメータを設定できます。たとえば、強制的にログ・スイッチを発生させてアーカイブを行うために、ARCHIVE_LAG_TARGET初期化パラメータを設定できます。

ARCHIVE_LAG_TARGETは動的パラメータで、ALTER SYSTEM SET文を使用して設定できます。

注意:

Oracle Real Application Clusters環境では、すべてのインスタンスのARCHIVE_LAG_TARGETパラメータに同じ値を指定する必要があります。異なる値を設定すると、予測できない動作が発生します。

11.2.6.2 ARCHIVE_LAG_TARGETの設定に影響する要因

ARCHIVE_LAG_TARGET初期化パラメータを設定する場合は、いくつかの検討する要素があります。

ARCHIVE_LAG_TARGET初期化パラメータを設定するかどうか、またはその設定値を決定するには、次の要因を考慮してください。

  • 切替え(およびアーカイブ)に伴うオーバーヘッド

  • ログが一杯になったときに発生する通常のログ・スイッチの頻度

  • スタンバイ・データベースで許容できるREDO損失の量

指定した間隔より短い頻度ですでにログ・スイッチが自然に発生している状況では、ARCHIVE_LAG_TARGETを設定しても特に利点はありません。ただし、REDOの生成速度が一定でない場合は、時間間隔を指定することで、各カレント・ログが使用される時間範囲の上限を設定できます。

ARCHIVE_LAG_TARGET初期化パラメータに極端に小さい値を指定すると、パフォーマンスに悪影響を及ぼすことがあります。これは、小さい値によって頻繁にログ・スイッチが発生するためです。このパラメータには、プライマリ・データベースのパフォーマンスを低下させないように適切な値を設定してください。

11.3 REDOログ・グループおよびメンバーの作成

データベースのREDOログを事前に計画し、データベースの作成時に必要なREDOログ・ファイルのグループとメンバーをすべて作成してください。しかし、グループやメンバーの追加作成が必要な状況もあります。たとえば、REDOログにグループを追加することによって、REDOログ・グループの可用性の問題を解決できます。

新たにREDOログ・グループおよびメンバーを作成するには、ALTER DATABASEシステム権限が必要です。データベースには、最大MAXLOGFILES個までグループを作成できます。

  • REDOログ・グループの作成
    REDOログ・ファイルの新しいグループを作成するには、SQL文ALTER DATABASEでADD LOGFILE句を指定します。
  • REDOログ・メンバーの作成
    完全なREDOログ・ファイルのグループを作成する必要がない場合もあります。つまり、グループはすでに存在しているが、そのグループの1つ以上のメンバーが(ディスク障害などにより)削除されたために完全ではない場合です。このような場合は、既存のグループに新しいメンバーを追加できます。

関連項目:

ALTER DATABASE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

親トピック: REDOログの管理

11.3.1 REDOログ・グループの作成

REDOログ・ファイルの新しいグループを作成するには、SQL文ALTER DATABASEでADD LOGFILE句を指定します。

  • ADD LOGFILE句を含むALTER DATABASE SQL文を実行します。

たとえば、次の文は、データベースに新しいREDOログ・グループを追加します。

ALTER DATABASE
  ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 100M;

注意:

新しいログ・メンバーのフルパス名を入力し、その場所を指定してください。指定しない場合、オペレーティング・システムに応じて、ファイルがデータベース・サーバーのデフォルト・ディレクトリまたはカレント・ディレクトリのいずれかに作成されます。

また、次のようにGROUP句を使用して、グループの識別番号を指定することもできます。 

ALTER DATABASE 
  ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo')
      SIZE 100M BLOCKSIZE 512;

グループ番号を使用することによって、REDOログ・グループの管理がより簡単になります。ただし、グループ番号には1からMAXLOGFILESの範囲の値を使用する必要があります。REDOログ・ファイルのグループ番号をスキップする(つまり、グループに10、20、30などの番号を付ける)と、データベースの制御ファイル内で不要な領域が消費されてしまうため、グループ番号はスキップしないでください。

前の文でのBLOCKSIZE句はオプションです。詳細は、「REDOログ・ファイルのブロック・サイズの計画」を参照してください。

親トピック: REDOログ・グループおよびメンバーの作成

11.3.2 REDOログ・メンバーの作成

完全なREDOログ・ファイルのグループを作成する必要がない場合もあります。つまり、グループはすでに存在しているが、そのグループの1つ以上のメンバーが(ディスク障害などにより)削除されたために完全ではない場合です。このような場合は、既存のグループに新しいメンバーを追加できます。

既存のグループのための新しいREDOログ・メンバーを作成するには:

  • ADD LOGFILE MEMBER句を含むALTER DATABASE SQL文を実行します。

たとえば、次の文は、REDOログ・グループ2に新しいREDOログ・メンバーを追加します。

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;

ファイル名は指定する必要がありますが、サイズを指定する必要はありません。新しいメンバーのサイズは、既存グループのメンバーのサイズによって決まります。

ALTER DATABASE文を使用するときは、次の例のように、TO句にグループの他のメンバーをすべて指定することによって、目的のグループを選択的に識別できます。 

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo'
    TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');

注意:

オペレーティング・システム上のファイルを作成する位置を指定するには、新しいログ・メンバーのファイル名を絶対パスで指定してください。そうしないと、ファイルはオペレーティング・システムごとに異なるデータベースのデフォルトのディレクトリまたはカレント・ディレクトリに作成されます。また、新しいログ・メンバーの状態はINVALIDとして表示されるので注意してください。これは正常であり、最初に使用するときにアクティブ(空白)に変更されます。

親トピック: REDOログ・グループおよびメンバーの作成

11.4 REDOログ・メンバーの再配置および名前変更

オペレーティング・システムのコマンドを使用してREDOログを再配置し、ALTER DATABASE文を使用してデータベースにそのREDOログの新しい名前(位置)を通知できます。

たとえば、REDOログ・ファイルが現在保存されているディスクを削除する場合や、データファイルや複数のREDOログ・ファイルが同一のディスク上に格納されていて、競合を少なくするためにそれらを分離する場合に、この手順が必要となります。

REDOログ・メンバーの名前を変更するには、ALTER DATABASEシステム権限が必要です。さらに、ファイルを目的の位置にコピーするためのオペレーティング・システム権限と、データベースをオープンしてバックアップするための権限が必要になることもあります。

REDOログを再配置したり、データベースにその他の構造上の変更を加えたりする前には、各操作の実行中に発生する問題に備えて、データベース全体のバックアップを作成してください。また、今後発生する可能性のある問題に備えて、一連のREDOログ・ファイルを名前変更または再配置した後、ただちにデータベースの制御ファイルのバックアップを作成してください。

REDOログを再配置するステップは、次のとおりです。これらのステップでは、次の状況を想定しています。

  • ログ・ファイルは、diskaおよびdiskbという2つのディスク上にあります。

  • REDOログは多重化され、最初のグループはメンバー/diska/logs/log1a.rdo と/diskb/logs/log1b.rdoからなり、2番目のグループはメンバー/diska/logs/log2a.rdoと/diskb/logs/log2b.rdoからなっています。

  • diskaにあるREDOログ・ファイルをdiskcに再配置する必要があります。新しいファイル名には新しい位置が反映され、/diskc/logs/log1c.rdoおよび/diskc/logs/log2c.rdoとなります。

REDOログ・メンバーの名前を変更するには:

  1. データベースを停止します。
    SHUTDOWN
  2. REDOログ・ファイルを新しい位置にコピーします。

    REDOログ・メンバーなどのオペレーティング・システム・ファイルは、適切なオペレーティング・システム・コマンドを使用してコピーする必要があります。ファイルのコピーに関する説明は、オペレーティング・システム固有のマニュアルを参照してください。

    注意:

    SQL*PlusのHOSTコマンドを使用すると、既存のSQL*Plusを終了せずにオペレーティング・システム・コマンドを使用してファイルをコピーできます(その他のオペレーティング・システムのコマンドも実行できます)。HOSTという語のかわりに1文字を使用するオペレーティング・システムもあります。たとえば、UNIXでは感嘆符(!)が使用できます。

    次の例では、オペレーティング・システム・コマンド(UNIX)を使用して、REDOログ・メンバーを新しい位置に移動しています。

    mv /diska/logs/log1a.rdo /diskc/logs/log1c.rdo
mv /diska/logs/log2a.rdo /diskc/logs/log2c.rdo
  3. データベースを起動して、マウントします。ただし、オープンはしません。
    CONNECT / as SYSDBA
STARTUP MOUNT
  4. REDOログ・メンバーの名前を変更します。

    ALTER DATABASE文でRENAME FILE句を使用して、データベースのREDOログ・ファイルの名前を変更します。 

    ALTER DATABASE 
  RENAME FILE '/diska/logs/log1a.rdo', '/diska/logs/log2a.rdo' 
           TO '/diskc/logs/log1c.rdo', '/diskc/logs/log2c.rdo';
  5. 通常の操作を実行するためにデータベースをオープンします。

    REDOログの変更は、データベースがオープンされたときに有効となります。

    ALTER DATABASE OPEN;

親トピック: REDOログの管理

11.5 REDOログ・グループおよびメンバーの削除

場合によっては、REDOログ・メンバーを含むグループ全体を削除できます。

たとえば、インスタンスのREDOログのグループ数を少なくする場合などです。また、1つ以上の特定のREDOログ・メンバーの削除が必要になる場合もあります。たとえば、ディスク障害が発生した場合は、アクセスできないファイルに書き込まれないように、障害のあったディスク上のREDOログ・ファイルをすべて削除します。これ以外にも、特定のREDOログ・ファイルが不要になることがあります。たとえば、適切ではない位置にファイルを配置した場合です。

親トピック: REDOログの管理

11.5.1 ログ・グループの削除

REDOログ・グループを削除できます。

REDOログ・グループを削除するには、ALTER DATABASEシステム権限が必要です。REDOログ・グループを削除する前に、次の制限と注意点について検討してください。

  • グループ内のメンバー数にかかわらず、インスタンスには少なくとも2つのREDOログ・ファイルのグループが必要です。(1つのグループは1つ以上のメンバーから構成されます。)

  • REDOログ・グループは、非アクティブである場合にのみ削除できます。カレントのグループを削除する必要がある場合は、最初にログ・スイッチを発生させる必要があります。

  • 削除する前に、REDOログ・グループがアーカイブされていることを確認します(アーカイブが使用可能になっている場合)。アーカイブされているかどうかを確認するには、V$LOGビューを使用します。 

    SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;

   GROUP# ARC STATUS
--------- --- ----------------
        1 YES ACTIVE
        2 NO  CURRENT
        3 YES INACTIVE
        4 YES INACTIVE

REDOログ・グループを削除するには:

  • DROP LOGFILE句を含むALTER DATABASE SQL文を実行します。

たとえば、次の文は、REDOログ・グループ3を削除します。

ALTER DATABASE DROP LOGFILE GROUP 3;

データベースからREDOログ・グループを削除するときは、Oracle Managed Files機能を使用していないかぎり、オペレーティング・システム・ファイルはディスクから削除されません。より正確に言えば、対応するデータベースの制御ファイルが更新されて、そのグループのメンバーがデータベース構造から削除されます。REDOログ・グループを削除した後は、この処理が正常に終了したことを確認してから、適切なオペレーティング・システム・コマンドを使用して、削除したREDOログ・ファイルを実際に削除します。

Oracle Managed Files機能を使用している場合は、オペレーティング・システム・ファイルのクリーン・アップが自動的に実行されます。

親トピック: REDOログ・グループおよびメンバーの削除

11.5.2 REDOログ・メンバーの削除

REDOログ・メンバーを削除できます。

REDOログ・メンバーを削除するには、ALTER DATABASEシステム権限が必要です。各REDOログ・メンバーを削除する前に、次の制限と注意点について検討してください。

  • REDOログ・ファイルを削除することにより、多重REDOログ・ファイルを一時的に非対称にしても問題はありません。たとえば、多重化したREDOログ・ファイルのグループを使用している場合、他のすべてのグループにメンバーが2つずつ残っていても、あるグループのメンバーを1つ削除できます。ただし、すべてのグループに少なくともメンバーが2つ存在するように、この状態をただちに訂正し、REDOログの単一の障害箇所が発生する可能性を取り除いてください。

  • グループ内のメンバー数にかかわらず、インスタンスには常に、少なくとも2つの有効なREDOログ・ファイル・グループが必要です。(1つのグループは1つ以上のメンバーから構成されます。)削除するメンバーがグループの最後の有効なメンバーである場合は、他のメンバーが有効にならないかぎり、そのメンバーを削除できません。REDOログ・ファイルの状態を確認するには、V$LOGFILEビューを使用します。REDOログ・ファイルは、データベースがアクセスできないとINVALIDになります。データベースがそのログ・ファイルを完全でない、または正しくないと判断すると、そのログ・ファイルはSTALEになります。この失効したログ・ファイルは、次にそのグループがアクティブ・グループになったときに、再び有効になります。

  • REDOログ・メンバーは、アクティブまたはカレント・グループの一部ではない場合のみ削除できます。アクティブ・グループのメンバーを削除する場合は、最初にログ・スイッチを発生させます。

  • メンバーを削除する前に、そのREDOログ・メンバーが属するグループがアーカイブされていることを確認します(アーカイブが使用可能になっている場合)。アーカイブされているかどうかを確認するには、V$LOGビューを使用します。

特定の非アクティブなREDOログ・メンバーを削除するには:

  • DROP LOGFILE MEMBER句を含むALTER DATABASE文を実行します。

次の文は、REDOログ/oracle/dbs/log3c.rdoを削除します。 

ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';

データベースからREDOログ・メンバーを削除しても、オペレーティング・システム・ファイルはディスクから削除されません。より正確に言えば、対応するデータベースの制御ファイルが更新されて、データベース構造からメンバーが削除されます。REDOログ・ファイルを削除した後は、この処理が正常に終了したことを確認してから、適切なオペレーティング・システム・コマンドを使用して、削除したREDOログ・ファイルを実際に削除します。

アクティブ・グループのメンバーを削除するには、最初にログ・スイッチを発生させる必要があります。

親トピック: REDOログ・グループおよびメンバーの削除

11.6 ログ・スイッチの強制

ログ・スイッチは、LGWRがあるREDOログ・グループへの書込みを中止して、別のログ・グループへの書込みを開始するときに発生します。デフォルトでは、現行のREDOログ・ファイル・グループが一杯になると、ログ・スイッチが自動的に発生します。

REDOログのメンテナンス操作を実行するために、ログ・スイッチを強制的に発生させて、現在アクティブなグループを非アクティブの状態に変更できます。たとえば、現在アクティブなグループを削除する場合は、アクティブでない状態になるまでそのグループを削除できません。また、現在アクティブなグループのメンバーが完全に一杯になる前に、特定の時点でそのグループをアーカイブする必要がある場合にも、ログ・スイッチの強制的な実行が必要です。このオプションは、一杯になるまで長い時間を必要とする大きなREDOログ・ファイルが含まれた構成で有効です。

ログ・スイッチを強制するには、ALTER SYSTEM権限が必要です。

ログ・スイッチを強制するには、

  • SWITCH LOGFILE句を含むALTER SYSTEM文を実行します。

たとえば、次の文は、ログ・スイッチを強制します。

ALTER SYSTEM SWITCH LOGFILE;

親トピック: REDOログの管理

11.7 REDOログ・ファイル内のブロックの検証

データベースは、チェックサムを使用してREDOログ・ファイル内のブロックを検証するように構成できます。

初期化パラメータDB_BLOCK_CHECKSUMをTYPICAL(デフォルト)に設定すると、ディスクに書き込まれる各データベース・ブロック(カレント・ログに書き込まれている各REDOログ・ブロックを含む)のチェックサムが計算されます。チェックサムは、ブロックのヘッダーに格納されます。

Oracle Databaseは、チェックサムを使用してREDOログ・ブロック内の破損を検出します。リカバリ処理中にREDOログ・ブロックがアーカイブ・ログから読み込まれるとき、およびブロックがアーカイブ・ログ・ファイルに書き込まれるとき、そのブロックの検証が行われます。破損が検出されると、エラーが発生しアラート・ログに書き込まれます。

REDOログ・ブロックのアーカイブ時に破損が検出されると、システムは、グループ内の別のメンバーからそのブロックを読み込もうとします。REDOログ・グループ内のすべてのメンバーでブロックが破損していると、アーカイブ処理は継続できません。

DB_BLOCK_CHECKSUMパラメータの値は、ALTER SYSTEM文で動的に変更できます。

注意:

DB_BLOCK_CHECKSUMを使用可能にすると、わずかなオーバーヘッドとデータベースのパフォーマンスの低下が発生します。データベースのパフォーマンスを監視して、パフォーマンスを犠牲にしてでもデータ・ブロックのチェックサムを使用して破損を検出する利点があるかを判断してください。

関連項目:

DB_BLOCK_CHECKSUM初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。

親トピック: REDOログの管理

11.8 REDOログ・ファイルのクリア

データベースがオープンしている間にREDOログ・ファイルが破損し、その結果アーカイブが継続できなくなり、データベース・アクティビティが停止することがあります。

この状況で、データベースを停止せずにファイルを再初期化する手順:

  • ALTER DATABASE CLEAR LOGFILE SQL文を実行します。

次の文は、REDOログ・グループ3のログ・ファイルをクリアします。

ALTER DATABASE CLEAR LOGFILE GROUP 3;

この文は、REDOログの削除が不可能な次の2つの状況に対応できます。

  • ログ・グループが2つのみの場合

  • 破損したREDOログ・ファイルがカレント・グループに属する場合

破損したREDOログ・ファイルがアーカイブされていない場合は、この文にUNARCHIVEDキーワードを使用します。 

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;

この文によって、破損したREDOログはクリアされ、アーカイブを回避できます。クリアされたREDOログは、アーカイブされていなくても使用できます。

バックアップのリカバリに必要なログ・ファイルをクリアすると、そのバックアップからのリカバリ処理ができなくなります。データベースは、そのバックアップからのリカバリ処理ができないことを示すメッセージをアラート・ログに書き込みます。

注意:

アーカイブされていないREDOログ・ファイルをクリアする場合は、データベースのバックアップをもう1つ作成する必要があります。

オフライン表領域をオンラインにするために必要な、アーカイブされていないREDOログを初期化するには、ALTER DATABASE CLEAR LOGFILE文でUNRECOVERABLE DATAFILE句を指定します。

オフライン表領域をオンラインにするために必要なREDOログをクリアすると、その表領域は二度とオンラインにはできません。表領域を削除するか、不完全リカバリを実行する必要があります。正常にオフライン化された表領域には、リカバリは必要ありません。

親トピック: REDOログの管理

11.9 FORCE LOGGING設定の優先順位

FORCE LOGGINGおよびNOLOGGINGは、データベース、プラガブル・データベース(PDB)、表領域またはデータベース・オブジェクトなどの様々なレベルで設定できます。1つ以上のレベルでFORCE LOGGINGが設定されている場合、FORCE LOGGING設定の優先順位によってREDOログに記録される内容が決まります。

マルチテナント・コンテナ・データベース(CDB)および非CDBをFORCE LOGGINGモードに置くことができます。このモードでは、一時表領域および一時セグメントでの変更を除くデータベースのすべての変更が記録されます。この設定は、各表領域で指定するNOLOGGINGまたはFORCE LOGGING設定、および各データベース・オブジェクトで指定するNOLOGGING設定より優先され、これらの設定には影響されません。

また、表領域をFORCE LOGGINGモードに置くこともできます。個々のオブジェクトのNOLOGGING設定をオーバーライドして、一時セグメントへの変更を除き、表領域内のすべてのオブジェクトに対するすべての変更が記録されます。

さらに、logging_clauseを使用して様々なタイプのデータベース・オブジェクトのロギング属性を指定することで、REDOログ・ファイルに特定のDML操作をログするかどうか(LOGGINGまたはNOLOGGING)を決定することができます。次のデータベース・オブジェクト・タイプのロギング属性を指定できます。

  • 表

  • 索引

  • マテリアライズド・ビュー

次の表は、各レベルのログ設定および非CDBの結果を示しています。

表11-1 非CDBのFORCE LOGGING設定の優先順位

データベース 表領域 データベース・オブジェクトのLOGGING属性 結果
FORCE LOGGING 無視 無視 ログ
NO FORCE LOGGING FORCE LOGGING 無視 ログ
NO FORCE LOGGING NO FORCE LOGGING LOGGING ログ
NO FORCE LOGGING NO FORCE LOGGING NOLOGGING ログされない

次の表は、各レベルのログ設定およびCDBの結果を示しています。

表11-2 CDBのFORCE LOGGING設定の優先順位

CDB PDB 表領域 データベース・オブジェクトのLOGGING属性 結果
FORCE LOGGING 無視 無視 無視 ログ
NO FORCE LOGGING ENABLE FORCE LOGGING 無視 無視 ログ
NO FORCE LOGGING ENABLE FORCE NOLOGGING 無視 無視 ログされない
NO FORCE LOGGING DISABLE FORCE [NO]LOGGING (設定なし) FORCE LOGGING 無視 ログ
NO FORCE LOGGING DISABLE FORCE [NO]LOGGING (設定なし) NO FORCE LOGGING LOGGING ログ
NO FORCE LOGGING DISABLE FORCE [NO]LOGGING (設定なし) NO FORCE LOGGING NOLOGGING ログされない

親トピック: REDOログの管理

11.10 REDOログのデータ・ディクショナリ・ビュー

REDOログに関する情報について一連のデータ・ディクショナリ・ビューを問い合せることができます。

次のビューには、REDOログに関する情報が表示されます。

ビュー 説明

V$LOG

制御ファイルのREDOログ・ファイル情報が表示されます。

V$LOGFILE

REDOログ・グループとメンバーおよびメンバーの状態を識別します。

V$LOG_HISTORY

ログの履歴情報が含まれます。

次の問合せは、データベースのREDOログに関する制御ファイル情報を返します。

SELECT GROUP#, THREAD#, SEQUENCE#, BYTES, MEMBERS, ARCHIVED, 
       STATUS, FIRST_CHANGE#, FIRST_TIME
  FROM V$LOG;

GROUP# THREAD#   SEQ   BYTES  MEMBERS  ARC STATUS     FIRST_CHANGE# FIRST_TIM
------ ------- ----- -------  -------  --- ---------  ------------- ---------
     1       1 10605 1048576        1  YES ACTIVE          11515628 16-APR-00
     2       1 10606 1048576        1  NO  CURRENT         11517595 16-APR-00
     3       1 10603 1048576        1  YES INACTIVE        11511666 16-APR-00
     4       1 10604 1048576        1  YES INACTIVE        11513647 16-APR-00

グループのすべてのメンバーの名前を表示するには、次の問合せを使用します。

SELECT GROUP#, STATUS, MEMBER FROM V$LOGFILE;

GROUP#   STATUS  MEMBER
------  -------  ----------------------------------
     1           D:\ORANT\ORADATA\IDDB2\REDO04.LOG
     2           D:\ORANT\ORADATA\IDDB2\REDO03.LOG
     3           D:\ORANT\ORADATA\IDDB2\REDO02.LOG
     4           D:\ORANT\ORADATA\IDDB2\REDO01.LOG

メンバーのSTATUSが空白の場合、そのファイルは使用中です。

親トピック: REDOログの管理