ヘッダーをスキップ

Oracle Database 管理者ガイド
10gリリース2(10.2)

B19224-02
目次
目次
索引
索引

戻る 次へ

6 REDOログの管理

この章では、オンラインREDOログを管理する方法について説明します。現行のREDOログは、REDOログのアーカイブ・コピーとは異なり常にオンラインです。したがって、通常、オンラインREDOログは単にREDOログと呼ばれます。

この章の内容は、次のとおりです。

REDOログの概要

REDOログは、リカバリ操作にとって最も重要な構造です。これは、データベースに加えられたすべての変更を発生時に格納する、2つ以上の事前割当てファイルから構成されます。Oracle Databaseの各インスタンスには、インスタンスの障害時にデータベースを保護するためのREDOログが1つずつ対応付けられています。

REDOスレッド

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

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

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ログ・ファイルにフラッシュします。データベースでは、必要に応じて、これらの変更をロールバックできます。

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

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

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

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

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

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ログを構成するときに考慮する必要があるガイドラインについて説明します。この項の内容は、次のとおりです。

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

REDOログそのものが影響を受ける障害に備え、Oracle DatabaseではREDOログを多重化できます。つまり、REDOログの2つ以上の同一コピーを自動的に別の場所に保持できます。 最大の効果を得るために、この保存場所は別々のディスクにすることをお薦めします。 ただし、REDOログのすべてのコピーが同一ディスク上にある場合でも、冗長性により、I/Oエラー、ファイルの破損などから保護できます。REDOログ・ファイルを多重化すると、LGWRは同じREDOログ情報を複数のREDOログ・ファイルに書き込むため、REDOログの単一の障害箇所は問題になりません。

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

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


画像の説明

図6-2A_LOG1B_LOG1はどちらもグループ1のメンバーで、A_LOG2B_LOG2はどちらもグループ2のメンバーです。グループ内の各メンバーのサイズは、完全に一致させてください。

同一のログ順序番号がLGWRにより割り当てられることが示すように、ログ・ファイル・グループの各メンバーは同時にアクティブになり、LGWRによって同時に書き込まれます。図6-2では、LGWRは最初にA_LOG1B_LOG1の双方に同時に書き込みます。次にA_LOG2B_LOG2の双方に同時に書き込みます。以降も同様です。LGWRが異なるグループのメンバー(A_LOG1B_LOG2など)に同時に書き込むことはありません。


注意

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


REDOログの障害への対処

LGWRがグループのメンバーに書き込めない場合、データベースはそのメンバーにINVALIDを示すマークを付け、LGWRトレース・ファイルとデータベース・アラート・ログに、アクセス不可能ファイルの問題を示すエラー・メッセージを書き込みます。REDOログ・メンバーが使用不可能な場合のLGWR固有の処理は、次の表に示すように、使用不可能になった理由によって決定します。

条件  LGWRの処理 

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

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

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

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

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

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

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

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

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

有効な構成と無効な構成

ほとんどの場合、多重REDOログ・ファイルを対称型にする必要があります。つまり、REDOログのどのグループも、メンバーが同数になるようにします。ただし、データベースでは、必ずしも多重REDOログ・ファイルを対称型にする必要はありません。たとえば、あるグループのメンバーは1つ、他のグループのメンバーは2つでもかまいません。この構成は、一部のREDOログ・メンバーには一時的に影響しても、他のメンバーには影響しないディスク障害からデータベースを保護します。

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

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


画像の説明

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

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

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

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

REDOログ・メンバーのサイズの設定

REDOログ・ファイルのサイズを設定するときは、REDOログをアーカイブするかどうかを考慮してください。REDOログ・ファイルのサイズは、いっぱいになったグループを1つのオフライン・ストレージ・メディア(テープやディスクなど)にアーカイブできるとともに、そのメディア上の未使用領域が最小になるように設定します。たとえば、いっぱいになった1つのREDOログ・グループを1本のテープにアーカイブし、そのテープの記憶容量の49%が未使用のまま残っているとします。この場合は、REDOログ・ファイルのサイズを小さくして、テープごとに2つずつREDOログ・グループがアーカイブされるように構成することをお薦めします。

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

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

関連項目

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

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

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

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

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

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

すべての有効なREDOログ・スレッドについて、そのカレント・ログを一定の間隔で強制的に切り替えることができます。プライマリ/スタンバイ・データベース構成では、プライマリ・サイトのREDOログをアーカイブしてスタンバイ・データベースにトランスポートすることによって、スタンバイ・データベースを変更できます。プライマリ・データベースで変更が発生してから、スタンバイ・データベースでその変更が適用されるまで、タイムラグが発生します。これは、プライマリ・データベースでREDOログがアーカイブREDOログにアーカイブされてから、スタンバイ・データベースにトランスポートされるまで、スタンバイ・データベースは変更を待機する必要があるためです。ARCHIVE_LAG_TARGET初期化パラメータを設定すると、このタイムラグを制限できます。このパラメータを設定することによって、許容するタイムラグの長さを秒単位で指定できます。

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

ARCHIVE_LAG_TARGET初期化パラメータを設定すると、データベースはインスタンスの現行のREDOログを定期的に調べます。次の条件が満たされると、インスタンスはログを切り替えます。

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文を使用して設定できます。


注意

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


ARCHIVE_LAG_TARGETの設定に影響する要因

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

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

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

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

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

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

関連項目

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

REDOログ・グループの作成

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

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

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


注意

オペレーティング・システム上のファイルを作成する位置を指定するには、新しいログ・メンバーのファイル名を絶対パスで指定してください。そうしないと、ファイルはオペレーティング・システムごとに異なるデータベースのデフォルトのディレクトリまたはカレント・ディレクトリに作成されます。 


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

ALTER DATABASE 
  ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo')
      SIZE 500K;

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

REDOログ・メンバーの作成

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

既存のグループ用に新しいREDOログ・メンバーを作成するには、SQL文ALTER DATABASEADD 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'); 


注意

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


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

オペレーティング・システムのコマンドを使用してREDOログを再配置し、ALTER DATABASE文を使用してデータベースにそのREDOログの新しい名前(位置)を通知できます。たとえば、REDOログ・ファイルが現在保存されているディスクを削除する場合や、複数のデータ・ファイルやREDOログ・ファイルが同一のディスク上に格納されていて、競合を少なくするためにそれらを分離する場合に、この手順が必要となります。

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

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

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

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ログ・グループおよびメンバーの削除

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

ログ・グループの削除

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

SQL文ALTER DATABASEDROP LOGFILE句を指定して、REDOログ・グループを削除します。

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

ALTER DATABASE DROP LOGFILE GROUP 3;

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

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

REDOログ・メンバーの削除

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

非アクティブである特定の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ログ・ファイル内のブロックの検証

データベースは、チェックサムを使用してREDOログ・ファイル内のブロックを検証するように構成できます。初期化パラメータDB_BLOCK_CHECKSUMTRUEに設定すると、ディスクに書き込まれる各データベース・ブロック(カレント・ログに書き込まれている各REDOログ・ブロックを含む)に対するチェックサムが計算されます。チェックサムは、ブロックのヘッダーに格納されます。

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

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

DB_BLOCK_CHECKSUMのデフォルト値はTRUEです。このパラメータの値は、ALTER SYSTEM文で動的に変更できます。


注意

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


関連項目

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

REDOログ・ファイルの初期化

データベースがオープンしている間に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ログ・ファイルを初期化する場合は、データベースのバックアップをもう1つ作成する必要があります。 


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

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

REDOログ情報の表示

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

ビュー  説明 

V$LOG  

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

V$LOGFILE  

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

V$LOG_HISTORY  

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

次の問合せは、データベースの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が空白の場合、そのファイルは使用中です。

関連項目

これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。 


戻る 次へ
Oracle
Copyright © 2006 Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引