| Oracle® Database管理者ガイド 11gリリース2 (11.2) B56301-08 |
|
 前 |
 次 |
リカバリ操作にとって最も重要な構造である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ログ・ファイルに戻って書込みを行い、再び循環を開始します。図12-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のように数値で定義されます。
図12-2では、A_LOG1とB_LOG1はどちらもグループ1のメンバーで、A_LOG2とB_LOG2はどちらもグループ2のメンバーです。同じグループの各メンバーは同じサイズである必要があります。
LGWRによって割り当てられる同一のログ順序番号で示されるように、ログ・ファイル・グループの各メンバーは同時にアクティブ(LGWRによって同時に書き込まれる)になります。図12-2では、最初にLGWRはA_LOG1およびB_LOG1の両方に同時に書き込みます。次にA_LOG2およびB_LOG2の両方に同時に書き込み、以下同様に続きます。LGWRでは、異なるグループのメンバー(たとえばA_LOG1とB_LOG2)に同時に書き込まれることはありません。
|
注意: REDOログ・ファイルは多重化することをお薦めします。これは、リカバリが必要になったときにログ・ファイルのデータが失われていると、致命的な事態を招くおそれがあるためです。REDOログを多重化すると、データベースの実行時のI/Oの量が増加するため注意してください。構成によっては、これによってデータベース・パフォーマンス全体が影響を受けます。 |
LGWRがグループのメンバーに書き込めない場合、データベースはそのメンバーにINVALIDを示すマークを付け、LGWRトレース・ファイルとデータベース・アラート・ログに、アクセス不可能ファイルの問題を示すエラー・メッセージを書き込みます。REDOログ・メンバーが使用不可能な場合のLGWR固有の処理は、次の表に示すように、使用不可能になった理由によって決定します。
ほとんどの場合、多重REDOログを対称にします(すべてのREDOログのグループに同じ数のメンバーを使用します)。ただし、データベースにとっては、多重REDOログが対称である必要はありません。たとえば、1つのグループには1つのメンバーのみを含め、他のグループには2つのメンバーを含められます。この構成によって、一時的に一部のREDOログ・メンバーに影響を与えても他のメンバーに影響が及ばないようなディスク障害に対して保護できます。
インスタンスのREDOログに関する唯一の要件は、最低2つのグループを持つことです。図12-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ログのブロック・サイズを計画する場合には、パフォーマンスおよびディスク領域の消費のバランスを検討する必要があります。
Oracle Database 11gリリース2以降では、CREATE DATABASE、ALTER DATABASE、およびCREATE CONTROLFILE文内のキーワードBLOCKSIZEによって、オンラインREDOログ・ファイルのブロック・サイズを指定できます。使用可能なブロック・サイズは512、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ログ・ファイルの適切な数を決定する最良の方法は、様々な構成をテストすることです。最適な構成では、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ログを定期的に調べます。次の条件が満たされると、インスタンスはログを切り替えます。
カレント・ログがn秒前に作成され、カレント・ログのアーカイブ見積り時間がm秒(この時間はカレント・ログで使用されているREDOブロック数に比例する)の場合に、n+mがARCHIVE_LAG_TARGET初期化パラメータの値を超えている。
カレント・ログにREDOレコードが含まれている。
Oracle Real Application Clusters環境では、他のスレッドが遅れている場合、前述の条件を検出したインスタンスによって他のスレッドも切り替えられ、ログがアーカイブされます。これは、Oracle Real Application Clustersで2つのノードを持つプライマリ/セカンダリ構成を実行しているときのように、クラスタ内に他のインスタンスよりも稼働率の低いインスタンスがある場合に特に有効です。
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パラメータを設定するかどうか、またはその設定値を決定するには、次の要因を考慮してください。
切替え(およびアーカイブ)に伴うオーバーヘッド
ログが一杯になったときに発生する通常のログ・スイッチの頻度
スタンバイ・データベースで許容できる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句を指定します。
次の文は、データベースに新しい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ログ・メンバーを作成するには、SQL文ALTER DATABASEでADD LOGFILE MEMBER句を指定します。次の文は、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ログ・メンバーの名前変更の手順
データベースを停止します。
SHUTDOWN
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
データベースを起動して、マウントします。ただし、オープンはしません。
CONNECT / as SYSDBA STARTUP MOUNT
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';
通常の操作を実行するためにデータベースをオープンします。
REDOログの変更は、データベースがオープンされたときに有効となります。
ALTER DATABASE OPEN;
場合によっては、REDOログ・メンバーを含むグループ全体を削除できます。たとえば、インスタンスのREDOログのグループ数を少なくする場合などです。また、1つ以上の特定の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
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ログ・メンバーを削除する前に、次の制限と注意点について検討してください。
REDOログ・ファイルを削除することにより、多重REDOログ・ファイルを一時的に非対称にしても問題はありません。たとえば、多重化したREDOログ・ファイルのグループを使用している場合、他のすべてのグループにメンバーが2つずつ残っていても、あるグループのメンバーを1つ削除できます。ただし、すべてのグループに少なくともメンバーが2つ存在するように、この状態をただちに訂正し、REDOログの単一の障害箇所が発生する可能性を取り除いてください。
グループ内のメンバー数にかかわらず、インスタンスには常に、少なくとも2つの有効なREDOログ・ファイル・グループが必要です。(1つのグループは1つ以上のメンバーから構成されます。)削除するメンバーがグループの最後の有効なメンバーである場合は、他のメンバーが有効にならないかぎり、そのメンバーを削除できません。REDOログ・ファイルの状態を確認するには、V$LOGFILEビューを使用します。REDOログ・ファイルは、データベースがアクセスできないとINVALIDになります。データベースがそのログ・ファイルを完全でない、または正しくないと判断すると、そのログ・ファイルはSTALEになります。この失効したログ・ファイルは、次にそのグループがアクティブ・グループになったときに、再び有効になります。
REDOログ・メンバーは、アクティブまたはカレント・グループの一部ではない場合のみ削除できます。アクティブ・グループのメンバーを削除する場合は、最初にログ・スイッチを発生させます。
メンバーを削除する前に、そのREDOログ・メンバーが属するグループがアーカイブされていることを確認します(アーカイブが使用可能になっている場合)。アーカイブされているかどうかを確認するには、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文で動的に変更できます。
|
注意: DB_BLOCK_CHECKSUMを使用可能にすると、わずかなオーバーヘッドとデータベースのパフォーマンスの低下が発生します。データベースのパフォーマンスを監視して、パフォーマンスを犠牲にしてでもデータ・ブロックのチェックサムを使用して破損を検出する利点があるかを判断してください。 |
|
関連項目: DB_BLOCK_CHECKSUM初期化パラメータの詳細は、『Oracle Databaseリファレンス』 |
データベースがオープンしている間にREDOログ・ファイルが破損し、その結果アーカイブが継続できなくなり、データベース・アクティビティが停止することがあります。このような状況では、ALTER DATABASE CLEAR LOGFILE文を使用して、データベースを停止せずにファイルを再初期化できます。
次の文は、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ログに関する情報が表示されます。
| ビュー | 説明 |
|---|---|
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リファレンス』を参照してください。 |
