ヘッダーをスキップ

Oracle Database 概要
11gリリース1(11.1)

E05765-03
目次
目次
索引
索引

戻る 次へ

15 バックアップおよびリカバリ

バックアップおよびリカバリ・プロシージャにより、データベースのデータ消失が防止され、データは消失した場合にも再構築されます。この章では、バックアップおよびリカバリ方針を設計する際の基礎となる概念について説明します。

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

バックアップおよびリカバリの概要

バックアップとは、データのコピーです。このコピーには、ユーザー・データが含まれるデータファイル、および構成情報が含まれるサーバー・パラメータ・ファイルや制御ファイルなど、データベースの重要な部分を含めることができます。

バックアップの主要な目的は、予期しないデータ消失やアプリケーション・エラーに対する防護策です。たとえば、ディスク障害が原因でデータファイルが失われたとします。データのバックアップをリストアし、メディア・リカバリを介して失われたデータを再構築できます。メディア・リカバリとは、データベース・ファイルのバックアップのリストア、ロールフォワードおよびロールバックにかかわる各種操作を意味します。

Oracleデータベースのバックアップおよびリカバリの実行には、Recovery Manager(RMAN)を使用する方法と、ユーザーが管理する方法の2つがあります。RMANは、データベース・ファイルのバックアップ、リストアおよびリカバリに使用されるOracle Databaseユーティリティです。Oracle Databaseの機能であるため、別途インストールする必要はありません。また、バックアップにはオペレーティング・システム・コマンド、メディア・リカバリにはSQL*Plusを使用することもできます。この方法はユーザー管理バックアップおよびリカバリとも呼ばれ、Oracleで全面的にサポートされています。ただし、より堅牢で管理作業が簡素化されるため、RMANを使用することをお薦めします。

Oracle Flashbackテクノロジは、従来のバックアップおよびリカバリに代わるテクノロジです。フラッシュバック機能を使用すると、バックアップからのデータのリストアを行わずに、過去のデータ状態を表示することや特定の時間にあわせてデータを前後に移動することが可能です。1つのコマンドを発行することで、データベース全体または単一の表を過去のある時点に巻き戻しできます。Oracle Databaseのフラッシュバック機能は、該当する状況のほとんどにおいて、メディア・リカバリよりもさらに効率的でわかりやすい機能です。

どのようなバックアップおよびリカバリ・ツールを使用している場合でも、フラッシュ・リカバリ領域を構成してリカバリ関連ファイルを管理することをお薦めします。

フラッシュ・リカバリ領域

フラッシュ・リカバリ領域は、オプションでOracle Databaseによって管理されるディレクトリ、ファイル・システムまたは自動ストレージ管理ディスク・グループで、バックアップおよびリカバリ・ファイルの一元的な格納場所です。フラッシュ・リカバリ領域は、Database Configuration Assistantを使用してデータベースを作成する際に構成することも、後から追加することもできます。

Oracle Databaseでは、フラッシュ・リカバリ領域にアーカイブ・ログを作成できます。RMANはフラッシュ・リカバリ領域にバックアップを格納し、メディア・リカバリ中にそれをフラッシュ・リカバリ領域からリストアできます。フラッシュ・リカバリ領域は、テープ用のディスク・キャッシュとしても機能します。

Oracle Databaseのリカバリ・コンポーネントがフラッシュ・リカバリ領域と対話して、リカバリ領域に格納されたファイルを使用してデータベースを完全にリカバリできるようにします。メディア障害後のデータベースのリカバリに必要なファイルは、すべてフラッシュ・リカバリ領域に属します。

フラッシュ・リカバリ領域には、次に示すリカバリ関連ファイルが格納されます。

Oracle Databaseではディスク領域の制限を定義して、フラッシュ・リカバリ領域に使用できるディスク領域を制限できます。このディスク制限により、ディスク全体をフラッシュ・リカバリ領域専用にするのではなく、残りのディスク領域を他の用途に使用できます。この領域に、Oracle Databaseでは認識されないオーバーヘッドは含まれません。たとえば、ディスク制限には、圧縮、ミラー化、または他のなんらかの冗長性メカニズムの使用によるファイル・システムの余分なサイズは含まれません。

Oracle DatabaseおよびRMANは、使用領域がリカバリ用のディスク領域の制限に達するまで、フラッシュ・リカバリ領域にファイルを作成します。新しいファイル用の領域が必要になった場合、Oracle Databaseは、失効したファイル、冗長なファイルまたは3次記憶装置にバックアップ済のファイルをフラッシュ・リカバリ領域から削除します。使用可能なディスク領域が15%未満になるとOracle Databaseにより警告が発行されますが、制限されたディスク領域の100%に達するまで使用し続けることができます。

フラッシュ・リカバリ領域は、大きいほど有用になります。推奨ディスク制限は、データベース・サイズ、増分バックアップのサイズ、およびテープにコピーされていない全アーカイブ・ログのサイズの合計です。

関連項目

  • ファイル削除の優先順位を定義するルールと、フラッシュ・リカバリ領域に関するその他の情報は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

  • フラッシュ・リカバリ領域の設定および管理方法は、『Oracle Database管理者ガイド』を参照してください。

 

データベースのバックアップ

この項では、物理バックアップについて説明します。この項の内容は、次のとおりです。

データベース・バックアップについて

データベース・バックアップは、物理または論理のいずれかです。物理バックアップはバックアップおよびリカバリ方針の中心概念であり、物理データベース・ファイルのコピーです。物理バックアップを作成するには、RMANユーティリティを使用する方法と、オペレーティング・システムのユーティリティを使用する方法があります。

これに対して、論理バックアップには、表やストアド・プロシージャなどの論理データが含まれます。Oracle Databaseのデータ・ポンプ・エクスポートなどのユーティリティを使用して、論理データを抽出してバイナリ・ファイルに格納できます。論理バックアップは、物理バックアップを補足できます。

データベース・バックアップの主要な目的はデータ保護ですが、アーカイブ・データベース・バックアップを作成してデータを保存することもできます。たとえば、顧客のトランザクション・レコードを指定された期間保存するビジネス要件があるとします。RMANを使用すると、一貫性を保つために必要なREDOと、データベースのアーカイブ・バックアップを外部記憶域に作成できます。不要なバックアップの削除を管理するRMANの保存ポリシーから、このデータベース・バックアップを除外する期間を制御できます。

データベース全体のバックアップと部分バックアップ

データベース全体のバックアップとは、データベース内の各データファイルと制御ファイルのバックアップです。これは最も一般的なタイプのバックアップです。

図15-1に示すように、データベース全体のバックアップはARCHIVELOGまたはNOARCHIVELOGモードで作成でき、一貫性バックアップまたは非一貫性バックアップのいずれかです。バックアップに一貫性を持たせるには、バックアップをリストアした後にREDOログを適用する必要があります。

図15-1    データベース全体のバックアップのオプション


画像の説明

部分バックアップには、個々の表領域またはデータファイルであるデータベースのサブセットが含まれます。表領域のバックアップとは、表領域を構成するデータファイルのバックアップです。オンラインかオフラインかにかかわらず、表領域のバックアップが有効なのはデータベースがARCHIVELOGモードで稼働している場合のみです。これは、リストア後の表領域とデータベースの他の表領域との一貫性を保つには、REDOが必要であるためです。

データファイルのバックアップとは、1つのデータファイルのバックアップです。この種のバックアップは、表領域のバックアップほど一般的ではありませんが、ARCHIVELOGモードのデータベースには有効です。

関連項目

論理バックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』および『Oracle Databaseユーティリティ』を参照してください。 

一貫性バックアップと非一貫性バックアップ

データベース・バックアップは、一貫性バックアップか非一貫性バックアップのいずれかです。この項ではその違いを説明します。

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

一貫性バックアップの概要

データベースの一貫性バックアップにおいて、すべての読取り/書込みデータファイルおよび制御ファイルでは、同じシステム変更番号(SCN)を使用してチェックポイントが実行されます。バックアップ内のファイルは、同じSCNまでのすべての変更内容が含まれていることが保証されます。非一貫性バックアップとは異なり、一貫性のあるデータベース全体のバックアップの場合、リストア後にリカバリする必要はありません。

一貫性のあるデータベース全体のバックアップを作成するには、NORMALIMMEDIATEまたはTRANSACTIONALオプションを指定してデータベースを停止し、データベースがクローズしている間にバックアップを作成する必要があります。データベースが読取り専用データベースでないかぎり、インスタンス障害が発生した場合や、SHUTDOWN ABORT文を発行した場合など、データベースが正常に停止していないと、常にそのデータファイルの一貫性が損われます。

データはすでに一貫した状態になっているため、一貫性のあるデータベース全体のバックアップをリストアした後は、そのままデータベースをオープンでき、リカバリ不要であることに注意してください。リストアしたデータファイル内のデータを正常にするための処理は不要です。そのため、メディア・リカバリやデータベースによるインスタンス・リカバリが実行されなくても、データベースの1年前の一貫性バックアップをリストアできます。


注意

REDOを適用せずに一貫性のあるデータベース全体のバックアップをリストアすると、バックアップの実行後に実行されたトランザクションはすべて失われます。 


一貫性のあるデータベース全体のバックアップは、NOARCHIVELOGモードで稼働しているデータベースでのみ有効なバックアップ・オプションです。他のバックアップ・オプションでは一貫性のためリカバリを必要としますが、これはアーカイブREDOログがなければ不可能です。

一貫性のあるデータベース全体のバックアップは、ARCHIVELOGモードで稼働しているデータベースにも有効なバックアップ・オプションです。このタイプのバックアップをリストアしており、アーカイブ・ログが使用可能な場合は、2つの選択肢があります。つまり、データベースを即時にオープンし、バックアップの作成後に実行されたトランザクションを消失させる方法と、アーカイブ・ログを適用して、消失したトランザクションをリカバリする方法です。

非一貫性バックアップの概要

データベースの非一貫性バックアップでは、読取り/書込みデータファイルおよび制御ファイルは、同じSCNまでのチェックポイントの実行を保証されていません。バックアップのファイルには、異なる時点から取得されたデータが含まれている場合があります。つまり、変更内容が欠落している可能性があります。この状況が発生するのは、バックアップの実行中にデータファイルが変更されている場合などです。

データベースがオープン状態またはマウントされているときにデータベースをバックアップすると、非一貫性バックアップが作成されます。オンライン・データファイルのバックアップをオンライン・バックアップと呼びます。オンライン・バックアップは、データベースをARCHIVELOGモードで実行する必要があります。

ARCHIVELOGモードでデータベースを実行し、アーカイブREDOログおよびデータファイルをバックアップするかぎり、非一貫性バックアップを堅実なバックアップおよびリカバリ計画の基礎とできます。データベースを完全保護するバックアップの作成にデータベースを停止する必要がないため、非一貫性バックアップには優れた可用性があります。

Oracle Databaseのリカバリでは、データファイルのヘッダーにある最小SCNから順にすべてのアーカイブREDOログとオンラインREDOログを読み取り、ログからの変更をデータファイルに適用することで、非一貫性バックアップに一貫性を持たせます。非一貫性バックアップの作成後は必ず、アーカイブされていないREDOログをアーカイブして、バックアップのリカバリに必要なREDOが揃っていることを確認します。バックアップ中に生成されたアーカイブREDOログがすべて揃っていないと、一貫性を保つために必要なREDOに欠落があるため、バックアップをリカバリできません。

関連項目

『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 

Recovery Managerによるバックアップとユーザー管理バックアップ

RMANのBACKUPコマンドでは、イメージ・コピーまたはバックアップ・セットが生成されます。イメージ・コピーとは、データファイル、制御ファイルまたはアーカイブ・ログを正確に複製したものです。オペレーティング・システムのユーティリティまたはRecovery Managerを使用して物理ファイルのイメージ・コピーを作成し、それ以上は処理を実行せずに、それをそのままリストアできます。


注意

オペレーティング・システムによるコピーとは異なり、RMANではファイル内のブロックが検証され、イメージ・コピーがリポジトリに記録されます。 


バックアップ・セットとは、バックアップ・ピースと呼ばれる1つ以上の物理ファイルで構成される、固有のフォーマットによるバックアップです。バックアップ・セットには、複数のデータファイルが含まれます。バックアップ・セットの最小単位は、バックアップ・ピースと呼ばれるバイナリ・ファイルです。RMANのみが作成およびアクセスするバックアップ・セットは、RMANによるテープ・ドライブなどのシーケンシャル・デバイスへのバックアップの書込みが可能な唯一の形式です。

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

オンライン・バックアップ

データベースではオンライン・バックアップ中にもファイルへの書込みが続くため、ブロック内に一貫性のないデータがバックアップされる可能性があります。たとえば、データベース・ライターによるブロックの更新中に、Recovery Managerまたはオペレーティング・システムのユーティリティがそのブロックを読み取る場合を考えます。この場合、Recovery Managerまたはコピー・ユーティリティは、ブロックの前半にある新しいデータと、後半にある古いデータを読み取る可能性があります。このブロックは分裂ブロックであり、このブロック内のデータには一貫性がないことを意味します。

オペレーティング・システムのユーティリティではなくRecovery Managerによるバックアップ中には、Oracleデータベースはデータファイルを読み取ります。各ブロックを読み取って、ブロックが分裂しているかどうかを判断します。ブロックが分裂している場合、データベースは、有効なブロックを取得するまでブロックを読み取ります。

Recovery Managerではなくオペレーティング・システムのユーティリティを使用してオンライン・データファイルのバックアップを実行する場合は、異なる方法で分裂ブロックを処理する必要があります。まず、ALTER TABLESPACE BEGIN BACKUP文(個々の表領域をバックアップ)、またはALTER DATABASE BEGIN BACKUP文(データベース全体をバックアップ)を使用して、ファイルをバックアップ・モードにする必要があります。オンライン・バックアップが完了したら、ALTER TABLESPACE...END BACKUP文またはALTER DATABASE END BACKUP文を実行して、ファイルのバックアップ・モードを解除する必要があります。

バックアップ・モードでファイルが更新されると、追加のREDOデータがログに記録されます。この追加データは、オペレーティング・システムのユーティリティでバックアップが作成された分裂ブロックの修復に必要となります。

制御ファイルのバックアップ

制御ファイルのバックアップは、バックアップおよびリカバリの重要な側面です。制御ファイルがなければ、データベースのマウントもオープンもできません。RMANでは、CONFIGURE CONTROLFILE AUTOBACKUP ONを使用することで、バックアップ・ジョブを実行するたびに制御ファイルが自動的にバックアップされるように指定できます。自動バックアップではデフォルトのファイル名が使用されるため、Recovery Managerリポジトリが使用できない場合にも、Recovery Managerはこのバックアップをリストアできます。そのため、この機能は障害時リカバリにきわめて役立ちます。

制御ファイルの手動バックアップを実行するには、次の方法を使用できます。

アーカイブREDOログのバックアップ

アーカイブREDOログを使用して、バックアップをある時点にロールフォワードできます。最新のアーカイブREDOログでバックアップをリカバリするには、バックアップの作成後に生成されたすべてのログが使用可能であることが必要です。つまり、ログ173が欠落している場合、アーカイブREDOログ100〜ログ200までのリカバリはできません。この場合はログ172の適用後リカバリを停止し、RESETLOGSオプションを指定してデータベースをオープンする必要があります。

アーカイブREDOログはリカバリに不可欠であるため、それらのバックアップを定期的に作成する必要があります。メディア・マネージャを使用する場合は、定期的にテープにログをバックアップします。アーカイブ・ログのバックアップを作成するには、次の方法を使用できます。

データ修復が必要な問題

次に示す障害には、DBAが対応する必要があります。データベース・インスタンスがクラッシュする可能性がありますが、データ損失の原因になることや、バックアップからのリカバリが必要になることはほとんどありません。

通常、メディア障害またはユーザー・エラーの場合に、データ・リカバリを行います。

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

メディア障害

メディア障害は、データベース外部の問題により、Oracle Database操作中にファイルの読取りまたは書込みができない場合に発生します。一般的なメディア障害には、ヘッド・クラッシュなどの物理的な障害、およびデータベース・ファイルの上書き、削除または破損が含まれます。メディア障害は、ユーザーまたはアプリケーションのエラーより頻度は低いですが、バックアップおよびリカバリ計画ではこれに備えておく必要があります。

オンラインREDOログ・ファイルまたは制御ファイルのメディア障害後のデータベース操作は、多重化によりファイルが保護されているかどうかで異なります。オンラインREDOログまたは制御ファイルが多重化されている場合は、データベースによりファイルのコピーが複数維持されています。

多重化されているオンラインREDOログのコピーが1つ含まれるディスクがメディア障害により破損しても、データベースは通常、それほど問題なく稼働し続けます。多重化されていないオンラインREDOログが破損すると、データベース操作が停止し、データが完全に失われる場合があります。

制御ファイルが破損すると、多重化されているかどうかにかかわらず、データベースにより、破損した制御ファイルの読取りまたは書込みが試行された時点でデータベースが停止します。チェックポイントごとおよびオンラインREDOログの切替え時などに、データベースは制御ファイルに頻繁にアクセスします。

メディア障害は、読取りエラーまたは書込みエラーのいずれかです。読取りエラーでは、インスタンスによるデータファイルの読取りが実行できません。また、ファイルが存在しない、ファイルを開けない、ファイルを読み取れないなどのエラーとともに、アプリケーションにオペレーティング・システム・エラーが戻されます。データベースは稼働し続けますが、読取りが失敗するたびにエラーが戻されます。次のチェックポイントでは、データベースにより、チェックポイント処理の一部としてデータファイル・ヘッダーへの書込みが試行されると書込みエラーが発生します。

データファイル書込みエラーの影響は、データファイルがどの表領域に存在するかによって異なります。SYSTEM表領域のデータファイル、UNDO表領域、またはアクティブなロールバック・セグメントのあるデータファイルにインスタンスが書込みを実行できない場合は、データベースによりエラーが発行され、データベースは停止します。SYSTEM表領域のすべてのファイルおよびUNDOまたはロールバック・セグメントを含むすべてのデータファイルは、データベースが正常に稼働するためにオンラインである必要があります。

インスタンスが前述のリストにないデータファイルへの書込みを実行できない場合、結果は、データベースがARCHIVELOGモードで実行されているかどうかに依存します。ARCHIVELOGモードでは、データベースによりエラーがデータベース・ライター・トレース・ファイルに記録され、影響を受けたデータファイルがオフラインになります。このデータファイルを含む表領域のその他すべてのデータファイルはオンラインのままです。原因である問題を修正し、影響を受けた表領域をリストアしてリカバリします。

NOARCHIVELOGモードでは、データベース・ライター・バックグラウンド・プロセスが停止するとインスタンスも停止します。問題の原因により必要な対応が決まります。問題が一時的な場合は、通常、オンラインREDOログ・ファイルを使用してクラッシュ・リカバリが実行されます。そのような場合には、メディア・リカバリは行わずにインスタンスを再起動できます。ただし、データファイルが破損している場合は、データベース全体の一貫性バックアップをリストアする必要があります。

ユーザー・エラー

不適切な更新、表の内容の削除またはデータベース・オブジェクトの削除など、ユーザーまたはアプリケーションにより、データベースに不要な変更が行われる場合があります。適切なバックアップおよびリカバリ計画では、多数のOracle Database機能を使用して、データベースの可用性に対する影響を最小化し、DBAの労力を最低限に抑えて、必要な状態にデータベースを戻すことができます。

関連項目

  • データベース全体に対してポイント・イン・タイム・リカバリを実行する方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

  • 表領域のポイント・イン・タイム・リカバリを実行する方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

  • Oracle Databaseのフラッシュバック機能の使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

 

データ修復

「データ修復が必要な問題」で説明されている問題の解決方法は複数あります。

データ・リカバリ・アドバイザは、診断および修復に関する様々な作業を自動的に行うことができる統合ソリューションです。データ・リカバリ・アドバイザは、障害を診断し、手動および自動の両方の修復オプションを提供し、場合によっては自動的に障害が修復されることもあります。

論理データの破損やユーザー・エラーによる問題を解決するために、メディア・リカバリのかわりとしてOracle Flashbackを使用できます。Oracle Flashback機能を使用すると、データベース全体またはデータベースのサブセットを以前の状態に巻き戻しできます。

メディア障害を修正するには、メディア・リカバリを使用します。メディア・リカバリでは、失われた変更を更新するために、バックアップにREDOまたは増分バックアップが適用されます。ブロック・メディア・リカバリはさらに特化されている操作で、1つ以上のファイル内で少数のブロックのみが破損している場合に使用します。

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

データ・リカバリ・アドバイザ

Oracle Databaseには、データ・リカバリ・アドバイザ・ツールが組み込まれています。このツールを使用すると、永続的なデータ障害が自動的に診断され、適切な修復オプションが提示されて、ユーザーの要求に応じて実行されます。データ・リカバリ・アドバイザは、Enterprise ManagerインタフェースまたはRMANクライアントを介して使用できます。

チェッカは、データベースまたはそのコンポーネントの状態を評価するために状態モニターに登録されている診断操作またはプロシージャです。状態評価はデータ整合性チェックとも呼ばれ、対処的または予防的に起動できます。

障害は通常、対処的に検出されます。破損データが関与するデータベースの操作はエラーとなりますが、これにより自動的にデータ整合性チェックが起動され、エラーに関連する障害がないかデータベースが検索されます。障害が診断された場合、その障害は自動診断リポジトリ(ADR)に記録されます。状態モニターを使用して、またはRecovery ManagerのVALIDATEおよびBACKUPコマンドによるブロック障害のチェックによって、データ整合性チェックを予防的に起動することもできます。

データベースによって障害が検出され、ADRに格納された後にのみ、データ・リカバリ・アドバイザを使用して修復に関するアドバイスを生成し、障害を修復できます。各障害には、オープンまたはクローズというステータスがあります。また、クリティカル、高、低という優先度もあります。優先度がクリティカルの障害は、データベース全体が使用不可になるため、迅速に対応する必要があります。優先度が高の障害では、データベースが部分的に使用不可またはリカバリ不可能になるため、通常はできるだけ時間が経過しないうちに修復する必要があります。優先度が高の障害には、データ・ブロックの破損および致命的ではないI/Oエラーが含まれます。優先度が低の障害は、より重要な障害が修正されるまで待機可能です。

データ・リカバリ・アドバイザは、最善の修復オプションおよびそのデータベースへの影響を自動的に判断します。通常、データ・リカバリ・アドバイザは、それぞれの障害または障害グループに対して手動および自動の両方の修復オプションを生成します。手動のオプションは、必須またはオプションのいずれかとして分類されます。

データ・リカバリ・アドバイザは、自動修復オプションを提示する前に、修復を完了するために必要なメディア・コンポーネントが使用可能かどうか、およびそのオプションが特定の環境に適しているかどうかを検証します。自動修復を選択すると、Oracle Databaseによって自動的に修復されます。データ・リカバリ・アドバイザ・ツールは、修復の成功を確認し、該当する障害をクローズします。

関連項目

  • RMANコマンドライン・インタフェースでのデータ・リカバリ・アドバイザの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

  • Enterprise Managerでのデータ・リカバリ・アドバイザの使用方法の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。

 

Oracle Flashbackテクノロジ

Oracle Databaseには、Oracle Flashbackテクノロジと呼ばれる機能グループが提供されています。フラッシュバック・テクノロジは、バックアップからのデータベースのリストアを必要とせず、過去のデータの状態を表示したり、特定の時間にあわせてデータを前後に巻き戻したりする機能を備えています。データベースへの変更内容によりますが、フラッシュバック機能では、メディア・リカバリよりも迅速で、データベースの可用性に対する影響も少ない状態で、不要な変更を元に戻すことができます。

関連項目

バックアップおよびリカバリには直接関係のない機能も含むすべてのOracle Flashback機能の概要は、「高可用性機能の概要」を参照してください。 

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

Oracle Flashback Database

Oracle Flashback Databaseを使用すると、Oracleデータベースを以前の時点まで巻き戻し、論理データの破損やユーザー・エラーによる問題を解決できます。

フラッシュ・リカバリ領域が構成され、フラッシュバック・データベース機能が使用可能な場合、RMANまたはSQLのFLASHBACK DATABASEコマンドを使用して、データベースを過去のある時点に戻すことができます。フラッシュバック・データベースは、物理ファイルのリストアを伴わないため、実際のメディア・リカバリではありません。迅速かつ容易であり、データベース全体のリストアを必要としないため、RESTOREおよびRECOVERコマンドを使用するよりもフラッシュバック・データベースの方が適切な場合があります。

フラッシュバック・データベースを使用すると、Oracle Databaseは、ブロックの過去のイメージを使用してデータベースに対する変更をバック・アウトします。これらのブロック・イメージは、Oracle Databaseにより、通常のデータベース処理の実行中に、フラッシュバック・ログに書き込まれます。フラッシュバック・ログは順次書き込まれ、アーカイブされません。Oracle Databaseにより、フラッシュバック・ログは、フラッシュ・リカバリ領域内で自動的に作成、削除およびサイズ変更されます。フラッシュバック・ログに注意する必要があるのは、パフォーマンスを監視する場合と、フラッシュバック・ログ用のフラッシュ・リカバリ領域に割り当てるディスク容量を決定する場合のみです。

FLASHBACK DATABASEを使用してデータベースの巻戻しに要する時間は、さかのぼる必要がある過去の時点や、目標時間以後のデータベース・アクティビティの量に比例します。データベース全体のリストアおよびリカバリの所要時間は、長時間かかる場合があります。フラッシュバック・ログ内のビフォア・イメージは、データベースを過去のある時点までリストアするためにのみ使用され、データベースを過去のある時点の一貫性のある状態まで戻すにはフォワード・リカバリが使用されます。Oracle Databaseはデータファイルを以前の特定時点まで戻しますが、初期化パラメータ・ファイルなどの補助ファイルは特定次点まで戻されません。

フラッシュバック・データベースは、Data Guard、リカバリ・アドバイザの補完、およびクローン・データベースの同期化にも使用できます。

関連項目

  • Oracle Flashback Databaseの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

  • フラッシュバック・データベースがOracle Data Guardを補完する方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。

  • フラッシュバック・データベースの使用方法とリストア・ポイントの詳細は、『Oracle Database高可用性概要』を参照してください。

 

Oracle Flashback Table

Oracle Flashback Tableを使用すると、1つの文で表を指定の時点まで巻き戻しできます。表データとともに、関連する索引、トリガーおよび制約をリストアできます。データベースがオンライン状態のときに、指定された表に対する変更のみが取り消されます。Oracle Flashback Tableは、不良ディスクやデータ・セグメントと索引の非一貫性など、物理的な破損には対応しません。

Oracle Flashback Tableは、セルフサービス修復ツールと同様に機能します。たとえば、偶然、表から重要な行を数行削除してしまい、それをリカバリするとします。FLASHBACK TABLE文を使用すると、表を削除前の時点までリストアし、欠落していた表内の行を確認できます。

表とその内容を、特定の実時間またはユーザー指定のシステム変更番号(SCN)までリストアできます。Oracle Flashback TableをOracle Flashback Version QueryおよびOracle Flashback Transaction Queryとともに使用して、表をリストアする時点を調べます。

Oracle Flashback Tableを正常に終了するには、システムに指定のSCNまたはタイムスタンプを満たすために十分なUNDO情報が必要であり、表に指定されている整合性制約には違反していない必要があります。また、表における行移動が有効化されている必要があります。

Oracle Flashback Tableの保存されたUNDO情報の可用性は、自動的にチューニングされたシステムのUNDO保存期間で制御されます。UNDO保存期間とは、古いUNDO情報(コミットされたトランザクションのUNDO情報)が上書き可能になるまでの時間を示します。データベースにより、使用統計が収集され、これらの統計およびUNDO表領域サイズに基づいてUNDO保存期間がチューニングされます。UNDO_RETENTION初期化パラメータを設定することで、最低限のUNDO保存期間をリクエストできます。


注意

UNDO保存の自動チューニングは、データベースが自動UNDO管理モード(デフォルト)の場合にのみ実行されます。最低限のUNDO保存期間のリクエストは、データベースで受け入れられる場合と受け入れられない場合があります。これは、システムの現在のトランザクション・アクティビティ、UNDO表領域が自動拡張であるか固定サイズであるか、UNDO表領域にRETENTION GUARANTEEを指定したかどうかなど、様々な要因に依存します。

UNDO保存の自動チューニングの詳細は、『Oracle Database管理者ガイド』を参照してください。 


関連項目

  • 「自動UNDO保存」

  • Oracle Flashback Tableの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

  • UNDO_RETENTION初期化パラメータおよびFLASHBACK TABLE文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

 

Oracle Flashback Drop

Oracle Flashback Dropは、DROP TABLE操作の効果を無効にします。フラッシュバック・ドロップは、ポイント・イン・タイム・リカバリなど、このような状況で使用できるその他のリカバリ・メカニズムより大幅に速く、最近のトランザクションの損失や停止時間は発生しません。

表を削除しても、データベースではその表に関連する領域はすぐには削除されません。かわりに、その表は名前が変更され、関連するオブジェクトとともにデータベースのごみ箱に配置されます。Oracle Databaseでは、削除されたデータベース・オブジェクトにより占有されている領域が新しいデータの保存に必要になるまで、それらのオブジェクトはごみ箱を使用して管理されます。ごみ箱は、実際は、削除されたオブジェクトに関する情報を含むデータ・ディクショナリ表です。

関連項目

Oracle Flashback Dropの使用方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 

メディア・リカバリ

データファイルまたは制御ファイルの物理バックアップのリストアとは、それを再構築してOracleデータベースで使用可能にすることです。リストアされたデータファイルのリカバリとは、アーカイブREDOログとオンラインREDOログ、つまり、バックアップの実行後にデータベースに対して行われた変更のレコードを適用して更新することです。Recovery Managerを使用すると、増分バックアップを使用してデータファイルをリカバリすることもできます。増分バックアップは、前回の増分バックアップ後に変更があったブロックのみを含むデータファイルのバックアップです。

必要なファイルがリストアされた後、ユーザーがメディア・リカバリを実行する必要があります。メディア・リカバリは、データベース・ファイルのリストア、ロールフォワードおよびロールバックのための各種操作を伴います。

メディア・リカバリでは、アーカイブREDOログとオンラインREDOログが適用され、データファイルがリカバリされます。データファイルに変更がある度に、その変更はオンラインREDOログに最初に記録されます。メディア・リカバリでは、オンラインおよびアーカイブREDOログに記録された変更がリストア後のデータファイルに選択的に適用され、ロールフォワードされます。

図15-2に、データベース上でのバックアップ、リストアおよびメディア・リカバリ実行の基本原理を示します。

図15-2    メディア・リカバリ


画像の説明

メディア・リカバリとは異なり、Oracle Databaseでは、クラッシュ・リカバリとインスタンス・リカバリはインスタンス障害の発生後に自動的に実行されます。クラッシュ・リカバリとインスタンス・リカバリでは、データベースはインスタンス障害直前のトランザクション一貫性のある状態までリカバリされます。クラッシュ・リカバリとは、単一インスタンス構成またはOracle Real Application Clusters構成において、すべてのインスタンスがクラッシュした後にデータベースをリカバリすることです。これに対してインスタンス・リカバリとは、Oracle Real Application Clusters構成において、障害が発生した1つ以上のインスタンスを稼働中のインスタンスでリカバリすることです。

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

データファイル・メディア・リカバリ

データファイル・メディア・リカバリを使用するのは、消失または破損した現行のデータファイルまたは制御ファイルをリカバリする場合です。また、OFFLINE NORMALオプションを指定せずに表領域がオフライン化され、消失した変更をリカバリする場合にも使用します。データファイル・メディア・リカバリとインスタンス・リカバリでは、どちらもデータベースの整合性を修復する必要があります。ただし、この2つのタイプのリカバリは、追加の機能に違いがあります。メディア・リカバリには次の特性があります。

オンライン・データファイルのメディア・リカバリが必要な場合は、データベースをオープンできません。また、メディア・リカバリが完了するまでは、メディア・リカバリを必要とするデータファイルはオンライン化できません。次の使用例では、メディア・リカバリが必要です。

データベースがインスタンスによりオープンされていれば、データファイルのメディア・リカバリはオフライン・データファイルにのみ機能します。

ブロック・メディア・リカバリ

ブロック・メディア・リカバリは、すべてのデータベース・ファイルをオンラインで使用可能な状態に保ったまま、個々のデータ・ブロックをリストアしてリカバリするテクニックです。破損が少数のブロックのみに限られている場合は、データファイル・リカバリよりもブロック・メディア・リカバリが適しています。

関連項目

ブロック・メディア・リカバリの実行方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 

完全リカバリ

完全リカバリでは、アーカイブ・ログとオンライン・ログに含まれるREDO変更すべてがバックアップに適用されます。通常、完全メディア・リカバリは、メディア障害によりデータファイルまたは制御ファイルが破損した後に実行します。完全リカバリは、データベース、表領域またはデータファイルに対して実行できます。

データベース全体の完全リカバリを実行する場合は、次の操作が必要です。

表領域またはデータファイルの完全リカバリを実行する場合は、次の操作が必要です。

データベースのポイント・イン・タイム・リカバリ

データベースのポイント・イン・タイム・リカバリは不完全リカバリとも呼ばれ、データベースの以前のバージョンを生成します。つまり、リストアされたバックアップ以後に生成されたREDOレコードすべてを適用するわけではありません。通常、データベース全体のポイント・イン・タイム・リカバリは、次の場合に実行します。

データベースのポイント・イン・タイム・リカバリを実行するには、リカバリが必要な時点より前に作成されたバックアップからデータファイルをすべてリストアし、リカバリの完了時にRESETLOGSオプションを指定してデータベースをオープンする必要があります。RESETLOGS操作では、データベースの新規インカネーションが作成されます。つまり、ログ順序1から始まるログ順序番号の新規ストリームを含むデータベースです。

不完全リカバリの実行後は、OPEN RESETLOGSコマンドを使用してデータベースを読取り/書込みモードでオープンする前に、まず読取り専用モードでオープンし、データを検査して適切な時点までリカバリされたことを確認することをお薦めします。正しい時点までリカバリされていない場合、OPEN RESETLOGSを実行していなければ、リカバリを再実行する方が簡単です。データベースを読取り専用モードでオープンし、リカバリが十分に実行されていないことが判明した場合は、単に必要な時点までリカバリを再実行します。必要以上の時点までリカバリされたことが判明した場合は、データベースをリストアしなおしてからリカバリを再実行する必要があります。


注意

フラッシュバック・データベースは、データベースのポイント・イン・タイム・リカバリの代替方法です。 


関連項目

「Oracle Flashback Database」 

表領域のポイント・イン・タイム・リカバリ

表領域のポイント・イン・タイム・リカバリ(TSPITR)機能を使用すると、1つ以上の表領域をデータベースの残りの部分より古い時点までリカバリできます。TSPITRが最も役立つのは、次の操作が必要な場合です。

TSPITRには、次の制限があります。

RMANによるリカバリとユーザー管理リカバリ

物理ファイルをリカバリする場合は、2つの基本的な方法から選択できます。次のことができます。

どちらの方法を選択した場合も、データベース、表領域またはデータファイルをリカバリできます。メディア・リカバリを実行する前に、どのデータファイルをリカバリするかを決定する必要があります。通常は、固定ビューV$RECOVER_FILEを使用できます。このビューには、リカバリが必要な全ファイルと、リカバリを必要とするエラーの説明が表示されます。

関連項目

リカバリ使用例でV$ビューを使用する方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 

Recovery Managerでのリストアおよびリカバリ

Recovery Managerの基本的なリカバリ・コマンドは、RESTOREおよびRECOVERです。RESTOREを使用して、バックアップ・セットまたはディスク上のイメージ・コピーから、データファイルを現行または新規の場所にリストアします。アーカイブREDOログを含むバックアップ・セットもリストアできますが、通常、この操作は不要です。Recovery Managerでは、リカバリに必要なアーカイブ・ログが自動的にリストアされ、リカバリの完了後に検出されるためです。Recovery ManagerのRECOVERコマンドを使用してメディア・リカバリを実行し、アーカイブ・ログまたは増分バックアップを適用します。

関連項目

RMANを使用したリストアおよびリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 

ユーザー管理リストアおよびリカバリ

Recovery Managerを使用しない場合は、オペレーティング・システムのユーティリティを使用してバックアップをリストアしてから、SQL*PlusのRECOVERコマンドを実行してデータベースをリカバリできます。

関連項目

オペレーティング・システムのユーティリティとSQL*Plusを使用したリストアおよびリカバリ方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 


戻る 次へ
Oracle
Copyright © 1993, 2008 Oracle Corporation.

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