REDOログの管理では、REDOログ・グループおよびメンバーの作成、REDOログ・メンバーの再配置および名前変更、REDOログ・グループおよびメンバーの削除、ログ・スイッチの強制などのタスクを完了します。
関連項目:
Oracle Databaseサーバーによって作成および管理されるREDOログ・ファイルの詳細は、「Oracle Managed Filesの使用」
リカバリ操作にとって最も重要な構造であるREDOログは、2つ以上の事前に割り当てられたファイルで構成されており、データベースへの変更があるたびにその変更内容が格納されます。Oracle Databaseの各インスタンスには、インスタンス障害の場合にデータベースを保護するために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ログ・ファイルには、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ログ・ファイルに戻って書込みを行い、再び循環を開始します。図11-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のように数値で定義されます。
図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の量が増加するため注意してください。構成によっては、これによってデータベース・パフォーマンス全体が影響を受けます。
LGWRがグループのメンバーに書き込めない場合、データベースはそのメンバーにINVALID
を示すマークを付け、LGWRトレース・ファイルとデータベース・アラート・ログに、アクセス不可能ファイルの問題を示すエラー・メッセージを書き込みます。
REDOログ・メンバーが使用不可能な場合のLGWR固有の処理は、次の表に示すように、使用不可能になった理由によって決定します。
条件 | LGWRの処理 |
---|---|
LGWRがグループ内の最低1つのメンバーに正常に書き込める場合 |
通常どおり書込みが行われます。LGWRはグループのうち使用可能なメンバーにのみ書き込み、使用不可のメンバーは無視します。 |
グループをアーカイブする必要があるため、LGWRがログ・スイッチの発生時に次のグループにアクセスできない場合 |
データベース操作は、グループが使用可能になるか、グループがアーカイブされるまで一時的に停止します。 |
メディア障害のため、ログ・スイッチの発生時にLGWRが次のグループのどのメンバーにもアクセスできない場合 |
Oracle Databaseはエラーを返し、データベース・インスタンスは停止します。この場合は、データベース上でREDOログ・ファイルの損失からのメディア・リカバリを実行する必要があります。 データベースのチェックポイントが損失したREDOログを超えて移動した場合、そのREDOログに記録されたデータは、データベースによってデータファイルに保存されているため、メディア・リカバリは必要ありません。アクセスできないREDOログ・グループのみ削除してください。データベースによって不良ログがアーカイブされていない場合は、 |
LGWRが書込み中に、グループのすべてのメンバーに突然アクセスできなくなった場合 |
Oracle Databaseはエラーを返し、データベース・インスタンスは即座に停止します。この場合は、メディア・リカバリを実行する必要があります。ログのドライブを不注意からオフにした場合など、ログを含むメディアが実際には失われていなければ、メディア・リカバリは不要です。この場合は、ドライブをオンに戻して、データベースで自動インスタンス・リカバリを実行します。 |
ほとんどの場合、多重REDOログを対称にします(すべてのREDOログのグループに同じ数のメンバーを使用します)。ただし、データベースにとっては、多重REDOログが対称である必要はありません。
たとえば、1つのグループには1つのメンバーのみを含め、他のグループには2つのメンバーを含められます。この構成によって、一時的に一部のREDOログ・メンバーに影響を与えても他のメンバーに影響が及ばないようなディスク障害に対して保護できます。
インスタンスのREDOログに関する唯一の要件は、最低2つのグループを持つことです。図11-3に、多重REDOログに有効な構成と無効な構成を示します。2番目の構成は、グループが1つしかないため無効です。
多重REDOログ・ファイルを設定する場合は、グループのメンバーを異なる物理ディスク上に配置します。このようにすると、1つのディスクで障害が発生しても、LGWRが使用できなくなるのはグループの1つのメンバーのみで、それ以外のメンバーは引き続きLGWRにアクセスできるので、インスタンスは継続して機能します。
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です。
関連項目:
使用しているオペレーティング・システム固有のOracleマニュアルを参照してください。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
関連項目:
ALTER
DATABASE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
V$SESSTAT
ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
V$SYSSTAT
ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
データベース・インスタンスに対する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ログ・スレッドが定期的に現在のログを切り替えるように強制できます。
プライマリ/スタンバイ・データベース構成では、REDOログをプライマリ・サイトにアーカイブし、その後スタンバイ・データベースに送信することによって変更がスタンバイ・データベースに反映されます。スタンバイ・データベースは、プライマリ・データベースのREDOログの変更がアーカイブされたREDOログにアーカイブされ、送信されるまで待機する必要があるため、スタンバイ・データベースに適用されている変更は、プライマリ・データベースで発生している変更から遅れることになります。この遅延を制限するために、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
パラメータに同じ値を指定する必要があります。異なる値を設定すると、予測できない動作が発生します。
ARCHIVE_LAG_TARGET
初期化パラメータを設定する場合は、いくつかの検討する要素があります。
ARCHIVE_LAG_TARGET
初期化パラメータを設定するかどうか、またはその設定値を決定するには、次の要因を考慮してください。
切替え(およびアーカイブ)に伴うオーバーヘッド
ログが一杯になったときに発生する通常のログ・スイッチの頻度
スタンバイ・データベースで許容できるREDO損失の量
指定した間隔より短い頻度ですでにログ・スイッチが自然に発生している状況では、ARCHIVE_LAG_TARGET
を設定しても特に利点はありません。ただし、REDOの生成速度が一定でない場合は、時間間隔を指定することで、各カレント・ログが使用される時間範囲の上限を設定できます。
ARCHIVE_LAG_TARGET
初期化パラメータに極端に小さい値を指定すると、パフォーマンスに悪影響を及ぼすことがあります。これは、小さい値によって頻繁にログ・スイッチが発生するためです。このパラメータには、プライマリ・データベースのパフォーマンスを低下させないように適切な値を設定してください。
データベースのREDOログを事前に計画し、データベースの作成時に必要なREDOログ・ファイルのグループとメンバーをすべて作成してください。しかし、グループやメンバーの追加作成が必要な状況もあります。たとえば、REDOログにグループを追加することによって、REDOログ・グループの可用性の問題を解決できます。
新たにREDOログ・グループおよびメンバーを作成するには、ALTER DATABASE
システム権限が必要です。データベースには、最大MAXLOGFILES
個までグループを作成できます。
関連項目:
ALTER DATABASE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
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ログ・ファイルのグループを作成する必要がない場合もあります。つまり、グループはすでに存在しているが、そのグループの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ログを再配置し、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ログ・メンバーの名前を変更する手順:
場合によっては、REDOログ・メンバーを含むグループ全体を削除できます。
たとえば、インスタンスのREDOログのグループ数を少なくする場合などです。また、1つ以上の特定のREDOログ・メンバーの削除が必要になる場合もあります。たとえば、ディスク障害が発生した場合は、アクセスできないファイルに書き込まれないように、障害のあったディスク上のREDOログ・ファイルをすべて削除します。これ以外にも、特定のREDOログ・ファイルが不要になることがあります。たとえば、適切ではない位置にファイルを配置した場合です。
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ログ・メンバーを削除できます。
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ログ・ファイルを実際に削除します。
アクティブ・グループのメンバーを削除するには、最初にログ・スイッチを発生させる必要があります。
ログ・スイッチは、LGWRがあるREDOログ・グループへの書込みを中止して、別のログ・グループへの書込みを開始するときに発生します。デフォルトでは、現行のREDOログ・ファイル・グループが一杯になると、ログ・スイッチが自動的に発生します。
REDOログのメンテナンス操作を実行するために、ログ・スイッチを強制的に発生させて、現在アクティブなグループを非アクティブの状態に変更できます。たとえば、現在アクティブなグループを削除する場合は、アクティブでない状態になるまでそのグループを削除できません。また、現在アクティブなグループのメンバーが完全に一杯になる前に、特定の時点でそのグループをアーカイブする必要がある場合にも、ログ・スイッチの強制的な実行が必要です。このオプションは、一杯になるまで長い時間を必要とする大きなREDOログ・ファイルが含まれた構成で有効です。
ログ・スイッチを強制するには、ALTER SYSTEM
権限が必要です。
ログ・スイッチを強制するには、
SWITCH LOGFILE
句を含むALTER SYSTEM
文を実行します。
たとえば、次の文は、ログ・スイッチを強制します。
ALTER SYSTEM SWITCH LOGFILE;
データベースは、チェックサムを使用して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ログ・ファイルが破損し、その結果アーカイブが継続できなくなり、データベース・アクティビティが停止することがあります。
この状況で、データベースを停止せずにファイルを再初期化する手順:
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ログを初期化すると、その表領域は二度とオンラインにはできません。表領域を削除するか、不完全リカバリを実行する必要があります。正常にオフライン化された表領域には、リカバリは必要ありません。
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ログに関する情報について一連のデータ・ディクショナリ・ビューを問い合せることができます。
次のビューには、REDOログに関する情報が表示されます。
ビュー | 説明 |
---|---|
|
制御ファイルのREDOログ・ファイル情報が表示されます。 |
|
REDOログ・グループとメンバーおよびメンバーの状態を識別します。 |
|
ログの履歴情報が含まれます。 |
次の問合せは、データベースの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
が空白の場合、そのファイルは使用中です。
関連項目:
これらのビューの詳細は、『Oracle Databaseリファレンス』