11gリリース1（11.1）
E05760-03
 目次 |
 索引 |
| Oracle Database 管理者ガイド 11gリリース1（11.1） E05760-03 |
|
この章の内容は次のとおりです。
REDOログは、リカバリ操作にとって最も重要な構造です。これは、データベースに加えられたすべての変更を発生時に格納する、2つ以上の事前割当てファイルから構成されます。Oracle Databaseの各インスタンスには、インスタンスの障害時にデータベースを保護するためのREDOログが1つずつ対応付けられています。
複数のデータベース・インスタンスのコンテキストでは、各データベース・インスタンスの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ログ・ファイルには、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ログは、2つ以上のREDOログ・ファイルから構成されます。データベースでは、一方のファイルのアーカイブ中にも（データベースがARCHIVELOGモードのとき）、他方のファイルが常に書込み可能であることを保証するために、最低2つのファイルを必要とします。詳細は、「アーカイブREDOログの管理」を参照してください。
LGWRは、REDOログ・ファイルに循環方式で書き込みます。つまり、現行のREDOログ・ファイルがいっぱいになると、LGWRは次に使用可能なREDOログ・ファイルへの書込みを開始します。使用可能な最後のREDOログ・ファイルがいっぱいになると、LGWRは最初のREDOログ・ファイルに戻って書込みを行い、再び循環を開始します。図10-1は、REDOログ・ファイルへの循環方式の書込みを示しています。各ラインの隣の番号は、LGWRが各REDOログ・ファイルに書き込む順序を示しています。
いっぱいになったREDOログ・ファイルは、アーカイブが使用可能になっているかどうかに応じて、LGWRで再利用できます。
NOARCHIVELOGモードのとき）、いっぱいになったREDOログ・ファイルは、そこに記録された変更がデータファイルに書き込まれた後に使用可能になります。
ARCHIVELOGモードのとき）、いっぱいになったREDOログ・ファイルは、そこに記録された変更がデータファイルに書き込まれ、かつ、そのファイルがアーカイブされた後に、LGWRで使用可能になります。 
Oracle Databaseは、REDOログ・ファイルを一度に1つのみ使用して、REDOログ・バッファから書き込まれたREDOレコードを格納します。LGWRが書込み中のREDOログ・ファイルを現行のREDOログ・ファイルと呼びます。
インスタンス・リカバリに必要なREDOログ・ファイルをアクティブなREDOログ・ファイルと呼びます。また、インスタンス・リカバリには不要なREDOログ・ファイルを非アクティブなREDOログ・ファイルと呼びます。
アーカイブを使用可能にしている場合は（データベースがARCHIVELOGモードのとき）、いずれかのアーカイバ・バックグラウンド・プロセス（ARCn）によって内容がアーカイブされるまで、データベースはアクティブなオンライン・ログ・ファイルの再利用または上書きができません。アーカイブが使用禁止になっている場合は（データベースがNOARCHIVELOGモードのとき）、最後のREDOログ・ファイルがいっぱいになると、LGWRは使用可能な最初のアクティブ・ファイルを上書きして書込みを継続します。
ログ・スイッチは、データベースが、あるREDOログ・ファイルへの書込みを終了して他のファイルへの書込みを開始するポイントです。現行のREDOログ・ファイルが完全にいっぱいになり、引き続き次のREDOログ・ファイルへの書込みが必要になると、通常はログ・スイッチが発生します。ただし、ログ・スイッチは、現行のREDOログ・ファイルが完全にいっぱいになっているかどうかに関係なく、定期的に発生するように構成できます。ログ・スイッチは、手動で強制的に発生させることもできます。
Oracle Databaseは、ログ・スイッチが発生してLGWRが書込みを開始するたびに、各REDOログ・ファイルに新しいログ順序番号を割り当てます。データベースがREDOログ・ファイルをアーカイブしても、そのファイルのログ順序番号は変わりません。一巡して再び使用可能になったREDOログ・ファイルには、次に使用可能なログ順序番号が割り当てられます。
各オンラインREDOログ・ファイルまたはアーカイブREDOログ・ファイルは、そのログ順序番号で一意に識別されます。クラッシュ、インスタンスまたはメディア・リカバリ中に、データベースは必要なアーカイブおよびREDOログ・ファイルのログ順序番号を使用して、REDOログ・ファイルを昇順に正しく適用します。
ここでは、データベース・インスタンスのREDOログを構成するときに考慮する必要があるガイドラインについて説明します。この項の内容は、次のとおりです。
REDOログ自体が影響を受ける障害に備え、Oracle DatabaseではREDOログを多重化できます。つまり、REDOログの2つ以上の同一コピーを自動的に別の場所に保持できます。最大の効果を得るためには、この保存場所を別々のディスクにする必要があります。ただし、REDOログのすべてのコピーが同一ディスク上にある場合でも、冗長性によって、I/Oエラー、ファイルの破損などから保護できます。REDOログ・ファイルを多重化すると、LGWRは同じREDOログ情報を複数のREDOログ・ファイルに書き込むため、REDOログの単一の障害箇所は問題になりません。
多重化は、REDOログ・ファイルのグループを作成することによって実装されます。グループは、REDOログ・ファイルとその多重化されたコピーで構成されます。それぞれの同一コピーはグループのメンバーと呼ばれます。各REDOログ・グループは、グループ1、グループ2のように数値で定義されます。
図10-2のA_LOG1とB_LOG1はどちらもグループ1のメンバーで、A_LOG2とB_LOG2はどちらもグループ2のメンバーです。グループ内の各メンバーのサイズは、完全に一致させてください。
同一のログ順序番号がLGWRにより割り当てられることが示すように、ログ・ファイル・グループの各メンバーは同時にアクティブになり、LGWRによって同時に書き込まれます。図10-2では、LGWRは最初にA_LOG1とB_LOG1の双方に同時に書き込みます。次にA_LOG2とB_LOG2の双方に同時に書き込みます。以降も同様です。LGWRが異なるグループのメンバー（A_LOG1とB_LOG2など）に同時に書き込むことはありません。
LGWRがグループのメンバーに書き込めない場合、データベースはそのメンバーにINVALIDを示すマークを付け、LGWRトレース・ファイルとデータベース・アラート・ログに、アクセス不可能ファイルの問題を示すエラー・メッセージを書き込みます。REDOログ・メンバーが使用不可能な場合のLGWR固有の処理は、次の表に示すように、使用不可能になった理由によって決定します。
ほとんどの場合、多重REDOログ・ファイルを対称型にする必要があります。つまり、REDOログのどのグループも、メンバーが同数になるようにします。ただし、データベースでは、必ずしも多重REDOログ・ファイルを対称型にする必要はありません。たとえば、あるグループのメンバーは1つ、他のグループのメンバーは2つでもかまいません。この構成は、一部のREDOログ・メンバーには一時的に影響しても、他のメンバーには影響しないディスク障害からデータベースを保護します。
インスタンスのREDOログに関する唯一の要件は、最低2つのグループを持つことです。図10-3は、多重REDOログに有効な構成と無効な構成を示しています。2番目の構成は、グループが1つしかないため無効です。
多重REDOログ・ファイルを設定する場合は、グループのメンバーを異なる物理ディスク上に配置します。このようにすると、1つのディスクで障害が発生しても、LGWRが使用できなくなるのはグループの1つのメンバーのみで、それ以外のメンバーには引き続きアクセスできるので、インスタンスは継続して機能します。
REDOログをアーカイブする場合は、バックグラウンド・プロセスLGWRとARCn間の競合をなくすために、REDOログ・メンバーを複数のディスクに分散します。たとえば、多重化したREDOログ・メンバーのグループが2つある場合（二重化されたREDOログ）は、各メンバーを異なるディスク上に配置し、アーカイブ先を5つ目のディスクに設定します。このようにすると、LGWR（メンバーへの書込み）とARCn（メンバーの読込み）間の競合は発生しません。
データ・ブロックやREDOレコードの書込み時の競合を減らすために、データファイルもREDOログ・ファイルとは異なるディスク上に配置することをお薦めします。
REDOログ・ファイルのサイズを設定するときは、REDOログをアーカイブするかどうかを考慮してください。REDOログ・ファイルのサイズは、いっぱいになったグループを1つのオフライン記憶メディア（テープやディスクなど）にアーカイブできるとともに、そのメディア上の未使用領域が最小になるように設定します。たとえば、いっぱいになった1つのREDOログ・グループを1本のテープにアーカイブし、そのテープの記憶容量の49%が未使用のまま残っているとします。この場合は、REDOログ・ファイルのサイズを小さくして、テープごとに2つずつREDOログ・グループがアーカイブされるように構成することをお薦めします。
同一の多重REDOログ・グループのメンバーは、すべて同じサイズにする必要があります。異なるグループのメンバーは異なるサイズにすることができます。ただし、グループ間でファイル・サイズを変えても特に利点はありません。ログ・スイッチ間にチェックポイントが発生するように設定していない場合は、グループのサイズを同一に設定して、チェックポイントが一定の間隔で発生することを保証してください。
REDOログ・ファイルの最小サイズは4MBです。
データベース・インスタンスに対するREDOログ・ファイルの適切な数を決定する最良の方法は、様々な構成をテストすることです。最適な構成では、LGWRがREDOログ情報を書き込むのを妨げない最小の数がグループ数になります。
データベース・インスタンスに必要なグループが2つのみの場合もあります。また、LGWRが使用可能な再利用グループが常に存在するようにするため、データベース・インスタンスにグループを追加する必要がある場合もあります。テスト中に、現行のREDOログ構成に問題がないかどうかを確認するには、LGWRトレース・ファイルおよびデータベース・アラート・ログの内容を調べるのが最も容易です。チェックポイントが未完了か、またはグループがアーカイブされていないため、LGWRが頻繁にグループを待機することをメッセージが示す場合は、グループを追加してください。
インスタンスのREDOログ構成を設定または変更する前に、REDOログ・ファイル数を制限するパラメータを検討してください。次のパラメータは、データベースに追加できるREDOログ・ファイルの数を制限します。
CREATE DATABASE文のMAXLOGFILESパラメータは、データベース当たりのREDOログ・ファイルの最大グループ数を決定します。グループの値は1〜MAXLOGFILESです。互換性レベルが10.2.0より前に設定されている場合、この上限値を変更する唯一の方法はデータベースまたは制御ファイルを再作成することです。したがって、データベースを作成する前にこの上限値を十分検討してください。互換性が10.2.0以上に設定されている場合は、MAXLOGFILES制限を超えることが可能で、制御ファイルは必要に応じて拡張されます。CREATE DATABASE文にMAXLOGFILESパラメータが指定されていない場合は、オペレーティング・システム固有のデフォルト値が使用されます。
CREATE DATABASE文のMAXLOGMEMBERSパラメータは、グループに含まれるメンバーの最大値を決定します。この上限値を変更する唯一の方法は、MAXLOGFILESの場合と同様、データベースまたは制御ファイルを再作成することです。したがって、データベースを作成する前にこの上限値を十分検討してください。CREATE DATABASE文にMAXLOGMEMBERSパラメータが指定されていない場合は、オペレーティング・システムのデフォルト値が使用されます。すべての有効なREDOログ・スレッドについて、そのカレント・ログを一定の間隔で強制的に切り替えることができます。プライマリ/スタンバイ・データベース構成では、プライマリ・サイトのREDOログをアーカイブしてスタンバイ・データベースにトランスポートすることによって、スタンバイ・データベースを変更できます。プライマリ・データベースで変更が発生してから、スタンバイ・データベースでその変更が適用されるまで、タイムラグが発生します。これは、プライマリ・データベースでREDOログがアーカイブREDOログにアーカイブされてから、スタンバイ・データベースにトランスポートされるまで、スタンバイ・データベースは変更を待機する必要があるためです。ARCHIVE_LAG_TARGET初期化パラメータを設定すると、このタイムラグを制限できます。このパラメータを設定することによって、許容するタイムラグの長さを秒単位で指定できます。
ARCHIVE_LAG_TARGET初期化パラメータを設定すると、データベースはインスタンスの現行のREDOログを定期的に調べます。次の条件が満たされると、インスタンスはログを切り替えます。
ARCHIVE_LAG_TARGET初期化パラメータの値を超えている。
Oracle Real Application Clusters環境では、他のスレッドが遅れている場合、前述の条件を検出したインスタンスによって他のスレッドも切り替えられ、ログがアーカイブされます。これは、Oracle Real Application Clustersで2つのノードを持つプライマリ/セカンダリ構成を実行しているときのように、クラスタ内に他のインスタンスよりも稼働率の低いインスタンスがある場合に特に有効です。
ARCHIVE_LAG_TARGET初期化パラメータは、Oracle Data Guard環境が非データ消失モードで構成されていない場合に、プライマリ側で停止や障害が起こったとき、スタンバイ側で失ってもかまわないREDO時間（秒）のターゲットを指定します。また、このパラメータは、プライマリ・データベースのカレント・ログが使用される時間の上限（秒単位）も指定します。アーカイブ見積り時間も考慮されるため、これはログ・スイッチ時間そのものではありません。
次の初期化パラメータ設定では、ログ・スイッチ間隔を30分（標準的な値）に設定します。
ARCHIVE_LAG_TARGET = 1800
0（ゼロ）を指定すると、時間ベースのログ・スイッチ機能は使用禁止になります。これはデフォルトの設定です。
スタンバイ・データベースが存在していなくても、ARCHIVE_LAG_TARGET初期化パラメータを設定できます。たとえば、強制的にログ・スイッチを発生させてアーカイブを行うために、ARCHIVE_LAG_TARGET初期化パラメータを設定できます。
ARCHIVE_LAG_TARGETは動的パラメータで、ALTER SYSTEM SET文を使用して設定できます。
ARCHIVE_LAG_TARGETパラメータを設定するかどうか、またはその設定値を決定するには、次の要因を考慮してください。
指定した間隔より短い頻度ですでにログ・スイッチが自然に発生している状況では、ARCHIVE_LAG_TARGETを設定しても特に利点はありません。ただし、REDOの生成速度が一定でない場合は、時間間隔を指定することで、各カレント・ログが使用される時間範囲の上限を設定できます。
ARCHIVE_LAG_TARGET初期化パラメータに極端に小さい値を指定すると、パフォーマンスに悪影響を及ぼすことがあります。これは、小さい値によって頻繁にログ・スイッチが発生するためです。このパラメータには、プライマリ・データベースのパフォーマンスを低下させないように適切な値を設定してください。
データベースのREDOログを事前に計画し、データベースの作成時に必要なREDOログ・ファイルのグループとメンバーをすべて作成してください。しかし、グループやメンバーの追加作成が必要な状況もあります。たとえば、REDOログにグループを追加することによって、REDOログ・グループの可用性の問題を解決できます。
新たにREDOログ・グループおよびメンバーを作成するには、ALTER DATABASEシステム権限が必要です。データベースには、最大MAXLOGFILES個までグループを作成できます。
REDOログ・ファイルの新しいグループを作成するには、SQL文ALTER DATABASEでADD LOGFILE句を指定します。
次の文は、データベースに新しいREDOログ・グループを追加します。
ALTER DATABASE ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M;
また、次のようにGROUP句を使用して、グループの識別番号を指定することもできます。
ALTER DATABASE ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M;
グループ番号を使用することによって、REDOログ・グループの管理がより簡単になります。ただし、グループ番号には1からMAXLOGFILESの範囲の値を使用する必要があります。REDOログ・ファイルのグループ番号をスキップする（つまり、グループに10、20、30などの番号を付ける）と、データベースの制御ファイル内で不要な領域が消費されてしまうため、グループ番号はスキップしないでください。
完全なREDOログ・ファイルのグループを作成する必要がない場合もあります。つまり、グループはすでに存在しているが、そのグループの1つ以上のメンバーが（ディスク障害などにより）削除されたために完全ではない場合です。このような場合は、既存のグループに新しいメンバーを追加できます。
既存のグループ用に新しいREDOログ・メンバーを作成するには、SQL文ALTER DATABASEでADD LOGFILE MEMBER句を指定します。次の文は、REDOログ・グループ2に新しいREDOログ・メンバーを追加します。
ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;
REDOログ・メンバーを追加する際、ファイル名は指定する必要がありますが、サイズを指定する必要はありません。新しいメンバーのサイズは、既存グループのメンバーのサイズによって決まります。
ALTER DATABASE文を使用するときは、次の例のように、TO句にグループの他のメンバーをすべて指定することによって、目的のグループを選択的に識別できます。
ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo' TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');
オペレーティング・システムのコマンドを使用してREDOログを再配置し、ALTER DATABASE文を使用してデータベースにそのREDOログの新しい名前（位置）を通知できます。たとえば、REDOログ・ファイルが現在保存されているディスクを削除する場合や、複数のデータファイルやREDOログ・ファイルが同一のディスク上に格納されていて、競合を少なくするためにそれらを分離する場合に、この手順が必要となります。
REDOログ・メンバーの名前を変更するには、ALTER DATABASEシステム権限が必要です。さらに、ファイルを目的の位置にコピーするためのオペレーティング・システム権限と、データベースをオープンしてバックアップするための権限が必要となることもあります。
REDOログを再配置したり、データベースにその他の構造上の変更を加えたりする前には、各操作の実行中に発生する問題に備えて、データベース全体のバックアップを作成してください。また、今後発生する可能性のある問題に備えて、一連のREDOログ・ファイルを名前変更または再配置した後、ただちにデータベースの制御ファイルのバックアップを作成してください。
REDOログを再配置する手順は、次のとおりです。これらの手順では、次の状況を想定しています。
diskaおよびdiskbという2つのディスク上にあります。
/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となります。
SHUTDOWN
REDOログ・メンバーなどのオペレーティング・システム・ファイルは、適切なオペレーティング・システム・コマンドを使用してコピーする必要があります。ファイルのコピーに関する説明は、オペレーティング・システム固有のマニュアルを参照してください。
次の例では、オペレーティング・システム・コマンド（UNIX）を使用して、REDOログ・メンバーを新しい位置に移動しています。
mv /diska/logs/log1a.rdo /diskc/logs/log1c.rdo mv /diska/logs/log2a.rdo /diskc/logs/log2c.rdo
CONNECT / as SYSDBA STARTUP MOUNT
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';
REDOログの変更は、データベースがオープンされたときに有効となります。
ALTER DATABASE OPEN;
場合によっては、REDOログ・メンバーを含むグループ全体を削除できます。たとえば、インスタンスのREDOログのグループ数を少なくする場合などです。また、1つ以上の特定のREDOログ・メンバーの削除が必要になる場合もあります。たとえば、ディスク障害が発生した場合は、アクセスできないファイルに書き込まれないように、障害のあったディスク上のREDOログ・ファイルをすべて削除します。これ以外にも、特定のREDOログ・ファイルが不要になることがあります。たとえば、適切ではない位置にファイルを配置した場合です。
REDOログ・グループを削除するには、ALTER DATABASEシステム権限が必要です。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
SQL文ALTER DATABASEにDROP LOGFILE句を指定して、REDOログ・グループを削除します。
次の文は、REDOログ・グループ3を削除します。
ALTER DATABASE DROP LOGFILE GROUP 3;
データベースからREDOログ・グループを削除するときは、Oracle Managed Files機能を使用していないかぎり、オペレーティング・システム・ファイルはディスクから削除されません。より正確に言えば、対応するデータベースの制御ファイルが更新されて、そのグループのメンバーがデータベース構造から削除されます。REDOログ・グループを削除した後は、この処理が正常に終了したことを確認してから、適切なオペレーティング・システム・コマンドを使用して、削除したREDOログ・ファイルを実際に削除します。
Oracle Managed Files機能を使用している場合は、オペレーティング・システム・ファイルのクリーン・アップが自動的に実行されます。
REDOログ・メンバーを削除するには、ALTER DATABASEシステム権限が必要です。各REDOログ・メンバーを削除する前に、次の制限と注意点について検討してください。
V$LOGFILEビューを使用します。REDOログ・ファイルは、データベースがアクセスできないとINVALIDになります。データベースがそのログ・ファイルを完全でない、または正しくないと判断すると、そのログ・ファイルはSTALEになります。この失効したログ・ファイルは、次にそのグループがアクティブ・グループになったときに、再び有効になります。
V$LOGビューを使用します。
非アクティブである特定のREDOログ・メンバーを削除するには、ALTER DATABASE文でDROP LOGFILE MEMBER句を指定します。
次の文は、REDOログ/oracle/dbs/log3c.rdoを削除します。
ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';
データベースからREDOログ・メンバーを削除しても、オペレーティング・システム・ファイルはディスクから削除されません。より正確に言えば、対応するデータベースの制御ファイルが更新されて、データベース構造からメンバーが削除されます。REDOログ・ファイルを削除した後は、処理が正常終了したことを確認してから、適切なオペレーティング・システム・コマンドを使用して、削除したREDOログ・ファイルを実際に削除します。
アクティブ・グループのメンバーを削除するには、最初にログ・スイッチを発生させる必要があります。
ログ・スイッチは、LGWRがあるREDOログ・グループへの書込みを中止して、別のログ・グループへの書込みを開始するときに発生します。デフォルトでは、現行のREDOログ・ファイル・グループがいっぱいになると、ログ・スイッチが自動的に発生します。
REDOログのメンテナンス操作を実行するために、ログ・スイッチを強制的に発生させて、現在アクティブなグループを非アクティブの状態に変更できます。たとえば、現在アクティブなグループを削除する場合は、アクティブでない状態になるまでそのグループを削除できません。また、現在アクティブなグループのメンバーが完全にいっぱいになる前に、特定の時点でそのグループをアーカイブする必要がある場合にも、ログ・スイッチの強制的な実行が必要です。このオプションは、いっぱいになるまで長い時間を必要とする大きなREDOログ・ファイルが含まれた構成で有効です。
ログ・スイッチを強制するには、ALTER SYSTEM権限が必要です。ALTER SYSTEM文でSWITCH LOGFILE句を指定します。
次の文は、ログ・スイッチを強制します。
ALTER SYSTEM SWITCH LOGFILE;
データベースは、チェックサムを使用してREDOログ・ファイル内のブロックを検証するように構成できます。初期化パラメータDB_BLOCK_CHECKSUMをTYPICAL（デフォルト）に設定すると、ディスクに書き込まれる各データベース・ブロック（カレント・ログに書き込まれている各REDOログ・ブロックを含む）に対するチェックサムが計算されます。チェックサムは、ブロックのヘッダーに格納されます。
Oracle Databaseは、チェックサムを使用してREDOログ・ブロック内の破損を検出します。リカバリ処理中にREDOログ・ブロックがアーカイブ・ログから読み込まれるとき、およびブロックがアーカイブ・ログ・ファイルに書き込まれるとき、そのブロックの検証が行われます。破損が検出されると、エラーが発生しアラート・ログに書き込まれます。
REDOログ・ブロックのアーカイブ時に破損が検出されると、システムは、グループ内の別のメンバーからそのブロックを読み込もうとします。REDOログ・グループ内のすべてのメンバーでブロックが破損していると、アーカイブ処理は継続できません。
DB_BLOCK_CHECKSUMパラメータの値は、ALTER SYSTEM文で動的に変更できます。
データベースがオープンしている間にREDOログ・ファイルが破損し、その結果アーカイブが継続できなくなり、データベース・アクティビティが停止することがあります。このような状況では、ALTER DATABASE CLEAR LOGFILE文を使用して、データベースを停止せずにファイルを再初期化できます。
次の文は、REDOログ・グループ3のログ・ファイルを初期化します。
ALTER DATABASE CLEAR LOGFILE GROUP 3;
この文は、REDOログの削除が不可能な次の2つの状況に対応できます。
破損したREDOログ・ファイルがアーカイブされていない場合は、この文にUNARCHIVEDキーワードを使用します。
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;
この文によって、破損したREDOログは初期化され、アーカイブを回避できます。初期化されたREDOログは、アーカイブされていなくても使用できます。
バックアップのリカバリに必要なログ・ファイルを初期化すると、そのバックアップからのリカバリ処理ができなくなります。データベースは、そのバックアップからのリカバリ処理ができないことを示すメッセージをアラート・ログに書き込みます。
オフライン表領域をオンラインにするために必要な、アーカイブされていないREDOログを初期化するには、ALTER DATABASE CLEAR LOGFILE文でUNRECOVERABLE DATAFILE句を指定します。
オフライン表領域をオンラインにするために必要なREDOログを初期化すると、その表領域は二度とオンラインにはできません。表領域を削除するか、不完全リカバリを実行する必要があります。正常にオフライン化された表領域には、リカバリは必要ありません。
次のビューには、REDOログに関する情報が表示されます。
| ビュー | 説明 |
|---|---|
|
|
制御ファイルのREDOログ・ファイル情報が表示されます。 |
|
|
REDOログ・グループとメンバーおよびメンバーの状態を識別します。 |
|
|
ログの履歴情報が含まれます。 |
次の問合せは、データベースのREDOログに関する制御ファイル情報を返します。
SELECT * 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 * 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が空白の場合、そのファイルは使用中です。
