10gリリース2（10.2）
B19215-02
 目次 |
 索引 |
| Oracle Database 概要 10gリリース2（10.2） B19215-02 |
|
バックアップおよびリカバリ・プロシージャにより、データベースのデータ消失が防止され、データは消失した場合にも再構築されます。データの再構築はメディア・リカバリを介して行われます。メディア・リカバリは、データベース・ファイルのバックアップのリストア、ロールフォワードおよびロールバックに伴う各種の作業を指します。この章では、バックアップおよびリカバリ方針を設計する際の基礎となる概念について説明します。
この章の内容は、次のとおりです。
関連項目
バックアップとは、データのコピーです。このコピーには、制御ファイルとデータファイルなど、データベースの重要な部分を含めることができます。バックアップは、予期しないデータ消失やアプリケーション・エラーに対する防護策です。オリジナル・データが消失しても、バックアップを使用して再構築できます。
バックアップは、物理バックアップと論理バックアップに分かれています。物理バックアップはバックアップおよびリカバリ方針の中心概念であり、物理データベース・ファイルのコピーです。物理バックアップを作成するには、Recovery Manager（RMAN）ユーティリティを使用する方法と、オペレーティング・システムのユーティリティを使用する方法があります。これに対して、論理バックアップには、Oracleのユーティリティにより抽出され、バイナリ・ファイルに格納された論理データ（表やストアド・プロシージャなど）が含まれます。論理バックアップを使用して物理バックアップを補足できます。
Oracleのバックアップおよびリカバリを実行するには、Recovery Managerを使用する方法と、ユーザー管理バックアップおよびリカバリを使用する方法があります。
Recovery Manager（RMAN）は、データベース・ファイルをバックアップ、リストアおよびリカバリできるOracleユーティリティです。Recovery ManagerはOracleデータベース・サーバーの機能であり、個別にインストールする必要はありません。
また、バックアップにはオペレーティング・システム・コマンド、リカバリにはSQL*Plusを使用することもできます。この方法はユーザー管理バックアップおよびリカバリとも呼ばれ、Oracleで全面的にサポートされています。ただし、Recovery Managerの方が堅牢で管理作業が大幅に簡素化されるため、Recovery Managerを使用することをお薦めします。
Recovery Managerとユーザー管理方式のどちらを使用する場合も、Export Utilityを使用して作成したスキーマ・オブジェクトの論理バックアップを使用して物理バックアップを補足できます。このユーティリティは、Oracleデータベースからバイナリ形式のオペレーティング・システム・ファイルにデータを書き込みます。後でインポート・ユーティリティを使用して、このデータをデータベースにリストアできます。
この項の内容は、次のとおりです。
一貫性バックアップとは、バックアップ対象ファイルに同じシステム変更番号までの変更がすべて含まれているバックアップです。つまり、バックアップのファイルには、同じ特定時点から使用されたデータがすべて含まれています。非一貫性バックアップとは異なり、一貫性のあるデータベース全体のバックアップの場合、リストア後にリカバリする必要はありません。
非一貫性バックアップとは、データベースのオープン中またはデータベースの異常終了後に作成する1つ以上のデータベース・ファイルのバックアップです。
データベースまたはその一部の一貫性バックアップとは、すべての読取り/書込みデータファイルと制御ファイルに対して、同じSCNでチェックポイントが実行されるバックアップです。
一貫性のあるデータベース全体のバックアップを作成するには、NORMAL、IMMEDIATEまたはTRANSACTIONALオプションを指定してデータベースを停止し、データベースがクローズしている間にバックアップを作成する必要があります。データベースが読取り専用データベースでないかぎり、インスタンス障害が発生した場合や、SHUTDOWN ABORT文を発行した場合など、データベースが正常に停止していないと、常にそのデータベースのデータファイルの一貫性が損なわれます。
Oracleは、データベースのチェックポイント時に、制御ファイルとデータファイルを同じSCNまで一貫したものにします。一貫性バックアップのうち、古いSCNが許可されるのは読取り専用表領域とNORMALモードでオフラインされた表領域のみで、これらは変更されていないため、バックアップ内でも他のデータファイルと引き続き一貫性が保たれます。
データはすでに一貫した状態になっているため、一貫性のあるデータベース全体のバックアップをリストアした後は、そのままデータベースをオープンでき、リカバリ不要であることに注意してください。リストアしたデータファイル内のデータを正常にするための処理は不要です。そのため、メディア・リカバリを実行したり、Oracleでインスタンス・リカバリを実行させなくても、データベースの1年前の一貫性バックアップをリストアできます。当然ながら、REDOを適用せずに一貫性のあるデータベース全体のバックアップをリストアすると、バックアップの実行後に実行されたトランザクションはすべて失われます。
一貫性のあるデータベース全体のバックアップは、NOARCHIVELOGモードで稼働しているデータベースに有効な唯一のバックアップ・オプションです。これは、他の方法では一貫性を保つためにリカバリが必要となるためです。NOARCHIVELOGモードでは、REDOログがアーカイブされないため、必要なREDOログがディスクに存在しない場合があります。一貫性のあるデータベース全体のバックアップは、ARCHIVELOGモードで稼働しているデータベースにも有効なバックアップ・オプションです。このタイプのバックアップをリストアしており、アーカイブ・ログが使用可能な場合は、2つの選択肢があります。つまり、データベースを即時にオープンし、バックアップの作成後に実行されたトランザクションを消失させる方法と、アーカイブ・ログを適用して、消失したトランザクションをリカバリする方法です。
非一貫性バックアップとは、バックアップ対象のファイルにすべてのSCNで行われた変更が含まれていないバックアップです。つまり、一部の変更が欠落しています。これは、バックアップのファイルには、異なる時点から使用されたデータが含まれていることを意味します。この状況が発生するのは、バックアップの実行中にデータファイルが変更されている場合などです。Oracleのリカバリでは、いずれかのデータファイル・ヘッダーにある最小SCNから順番にすべてのアーカイブ・ログとオンラインREDOログを読み取り、ログからの変更をデータファイルに適用することで、非一貫性バックアップが一貫したものになります。
データベースを1週7日24時間稼働させる必要がある場合、他に選択肢はなく、データベース全体の非一貫性バックアップを実行するしかありません。オンライン・データファイルのバックアップをオンライン・バックアップと呼びます。この場合は、データベースをARCHIVELOGモードで実行する必要があります。
データベースをARCHIVELOGモードで実行すると、データベース全体のバックアップを一度に作成する必要がありません。たとえば、データベースに7つの表領域が含まれており、制御ファイルとともに毎晩異なる表領域のバックアップを実行すると、データベースの表領域すべてと制御ファイルのバックアップに1週間かかることになります。このような時差バックアップをデータベース全体のバックアップとみなすこともできます。ただし、この種の時差バックアップのリストアが必要になった場合、最初に実行したバックアップ以降に作成されたアーカイブREDOログをすべて使用して、リカバリする必要があります。
オンライン・バックアップまたはクローズ状態の非一貫性バックアップの実行後は必ず、アーカイブされていないREDOログをアーカイブして、バックアップのリカバリに必要なREDOが揃っていることを確認します。
オープン状態またはクローズ状態の非一貫性バックアップを実行した後、バックアップ中に生成されたアーカイブ・ログすべてのバックアップを作成し、そのバックアップの完了後に制御ファイルのバックアップを作成することをお薦めします。バックアップ中に生成されたアーカイブREDOログがすべて揃っていないと、一貫性を保つために必要なREDOレコードに欠落があるため、バックアップをリカバリできません。
この項の内容は、次のとおりです。
データベース全体のバックアップとは、データベース内の各データファイルと制御ファイルのバックアップです。これは最も一般的なタイプのバックアップです。
データベース全体のバックアップは、ARCHIVELOGまたはNOARCHIVELOGモードで実行できます。ただし、この種のバックアップを実行する前に、ARCHIVELOGおよびNOARCHIVELOGモードによるバックアップの内容に注意する必要があります。
図15-1に、実行するバックアップのタイプに有効な構成オプションを示します。
データベース全体のバックアップには、一貫性バックアップと非一貫性バックアップがあります。バックアップに一貫性があるかどうかによって、そのリストア後にREDOログを適用する必要があるかどうかが決定されます。
表領域のバックアップとは、表領域を構成するデータファイルのバックアップです。たとえば、表領域usersにデータファイル2、3および4が格納されている場合は、表領域usersのバックアップを実行すると、この3つのデータファイルのバックアップが作成されます。
オンラインかオフラインかにかかわらず、表領域のバックアップが有効なのはデータベースがARCHIVELOGモードで稼働している場合のみです。これは、リストア後の表領域とデータベースの他の表領域との一貫性を保つには、REDOが必要であるためです。
データファイルのバックアップとは、1つのデータファイルのバックアップです。この種のバックアップは、表領域のバックアップほど一般的ではありませんが、ARCHIVELOGモードのデータベースには有効です。NOARCHIVELOGモードのデータベースでは、データファイルのバックアップが有効なのは次の場合のみです。
バックアップには、イメージ・コピーおよびバックアップ・セットという2つのタイプがあります。イメージ・コピーとは、データファイル、制御ファイルまたはアーカイブ・ログを正確に複製したものです。オペレーティング・システムのユーティリティまたはRecovery Managerを使用して物理ファイルのイメージ・コピーを作成し、それ以上は処理を実行せずに、それをそのままリストアできます。
バックアップ・セットとは、バックアップ・ピースと呼ばれる1つ以上の物理ファイルで構成される、固有のフォーマットによるバックアップです。イメージ・コピーとは異なり、複数のデータベース・ファイルを含めることができ、圧縮や増分バックアップのような特殊処理を使用してバックアップを作成できます。バックアップ・セットのリストアには、Recovery Managerを使用する必要があります。
データベースではオンライン・バックアップ中にもファイルへの書込みが続くため、ブロック内に一貫性のないデータのバックアップが作成される可能性があります。たとえば、データベース・ライターによるブロックの更新中に、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データがログに記録されます。この追加データは、オペレーティング・システムのユーティリティでバックアップが作成された分裂ブロックの修復に必要となります。
制御ファイルのバックアップは、バックアップおよびリカバリの重要な側面です。制御ファイルがなければ、データベースのマウントもオープンもできません。
Recovery Managerに対して、バックアップ・ジョブを実行するたびに制御ファイルのバックアップを自動的に作成するように指示できます。この場合に使用するコマンドはCONFIGURE CONTROLFILE AUTOBACKUPです。自動バックアップではデフォルトのファイル名が使用されるため、Recovery Managerリポジトリが使用できない場合にも、Recovery Managerはこのバックアップをリストアできます。そのため、この機能は障害時リカバリにきわめて役立ちます。
制御ファイルの手動バックアップを実行するには、次の方法を使用できます。
BACKUP CURRENT CONTROLFILEコマンドを実行すると、制御ファイルのバイナリ・バックアップがバックアップ・セットまたはイメージ・コピーとして作成されます。
ALTER DATABASE BACKUP CONTROLFILEを実行すると、制御ファイルのバイナリ・バックアップが作成されます。
ALTER DATABASE BACKUP CONTROLFILE TO TRACEを実行すると、制御ファイルの内容がSQLスクリプト・ファイルにエクスポートされます。このスクリプトを使用して新規制御ファイルを作成できます。トレース・ファイルのバックアップには、1つ重大なデメリットがあります。つまり、アーカイブREDOログのレコード、Recovery Managerによるバックアップおよびコピーが含まれません。このため、バイナリ・バックアップの方が適切です。アーカイブREDOログは、非一貫性バックアップのリカバリに不可欠です。アーカイブ・ログなしで非一貫性バックアップをリカバリするには、Recovery Managerの増分バックアップを使用する必要があります。最新のログでバックアップをリカバリできるようにするには、この2つの時点の間に生成されたすべてのログが使用可能であることが必要です。つまり、ログ173が欠落している場合、ログ100からログ200までのリカバリはできません。この場合はリカバリをログ172で停止し、RESETLOGSオプションを指定してデータベースをオープンする必要があります。
アーカイブREDOログはリカバリに不可欠であるため、それらのバックアップを定期的に作成する必要があります。可能な場合は、定期的にテープにバックアップを作成してください。
アーカイブ・ログのバックアップを作成するには、次の方法を使用できます。
BACKUP ARCHIVELOGコマンド
BACKUP ...PLUS ARCHIVELOGコマンド
データファイルまたは制御ファイルの物理バックアップのリストアとは、それを再構築してOracleデータベース・サーバーで使用可能にすることです。リストアされたデータファイルのリカバリとは、アーカイブREDOログとオンラインREDOログ、つまり、バックアップの実行後にデータベースに対して行われた変更のレコードを適用して更新することです。Recovery Managerを使用すると、増分バックアップを使用してデータファイルをリカバリすることもできます。増分バックアップは、前回の増分バックアップ後に変更があったブロックのみを含むデータファイルのバックアップです。
必要なファイルがリストアされた後、ユーザーがメディア・リカバリを実行する必要があります。メディア・リカバリは、データベース・ファイルのリストア、ロールフォワードおよびロールバックのための各種操作を伴います。
メディア・リカバリでは、アーカイブREDOログとオンラインREDOログが適用され、データファイルがリカバリされます。データファイルに変更がある度に、その変更はオンラインREDOログに最初に記録されます。メディア・リカバリでは、オンラインおよびアーカイブREDOログに記録された変更がリストア後のデータファイルに選択的に適用され、ロールフォワードされます。
論理データの破損やユーザー・エラーによる問題を解決するために、Oracle Flashbackを使用できます。Oracle Flashback DatabaseとOracle Flashback Tableを使用すると、以前の時点まですばやくリカバリできます。
図15-2に、データベース上でのバックアップ、リストアおよびメディア・リカバリ実行の基本原理を示します。
メディア・リカバリとは異なり、クラッシュ・リカバリとインスタンス・リカバリはインスタンス障害の発生後に自動的に実行されます。クラッシュ・リカバリとインスタンス・リカバリでは、データベースはインスタンス障害直前のトランザクション一貫性のある状態までリカバリされます。定義によれば、クラッシュ・リカバリとは、単一インスタンス構成またはOracle Real Application Clusters構成において、すべてのインスタンスがクラッシュした場合にデータベースをリカバリすることです。これに対してインスタンス・リカバリとは、Oracle Real Application Clusters構成において、障害が発生した1つのインスタンスを稼働中のインスタンスでリカバリすることです。
この項の内容は、次のとおりです。
バックアップを作成してREDOを適用するタイプのリカバリを、メディア・リカバリと呼びます。メディア・リカバリでは、バックアップが現時点またはそれ以前の特定時点まで更新されます。通常、メディア・リカバリという用語はデータファイルのリカバリを指します。ブロック・メディア・リカバリはさらに特化されている操作で、1つ以上のファイル内で少数のブロックのみが破損している場合に使用します。いずれにせよ、リカバリの実行には常にリストア後のバックアップを使用します。
この項の内容は、次のとおりです。
完全リカバリでは、データベース、表領域またはデータファイルのバックアップとREDOデータまたは増分バックアップの組合せを使用して、最新の時点まで更新する必要があります。この方法が完全バックアップと呼ばれるのは、アーカイブ・ログとオンライン・ログに含まれるREDO変更すべてがバックアップに適用されるためです。通常、完全メディア・リカバリは、メディア障害によりデータファイルまたは制御ファイルが破損した後に実行します。
完全リカバリは、データベース、表領域またはデータファイルに対して実行できます。データベース全体の完全リカバリを実行する場合は、次の操作が必要です。
表領域またはデータファイルの完全リカバリを実行する場合は、次の操作が必要です。
不完全リカバリはPoint-in-Timeリカバリとも呼ばれ、バックアップを使用してデータベースの以前のバージョンを生成します。つまり、最新バックアップ以後に生成されたREDOレコードすべてを適用するわけではありません。通常、データベース全体の不完全リカバリは、次の場合に実行します。
不完全メディア・リカバリを実行するには、リカバリが必要な時点より前に作成されたバックアップからデータファイルをすべてリストアし、リカバリの完了時にRESETLOGSオプションを指定してデータベースをオープンする必要があります。RESETLOGS操作では、データベースの新規インカネーションが作成されます。つまり、ログ順序1から始まるログ順序番号の新規ストリームを含むデータベースです。
不完全リカバリの実行後は、OPEN RESETLOGSコマンドを使用してデータベースを読取り/書込みモードでオープンする前に、まず読取り専用モードでオープンし、データを検査して適切な時点までリカバリされたことを確認することをお薦めします。正しい時点までリカバリされていない場合、OPEN RESETLOGSを実行していなければ、リカバリを再実行する方が簡単です。データベースを読取り専用モードでオープンし、リカバリが十分に実行されていないことが判明した場合は、単に必要な時点までリカバリを再実行します。必要以上の時点までリカバリされたことが判明した場合は、データベースをリストアし直してからリカバリを再実行する必要があります。
表領域のPoint-in-Time（TSPITR）機能を使用すると、1つ以上の表領域をデータベースの残りの部分とは異なる時点までリカバリできます。TSPITRが最も役立つのは、次の操作が必要な場合です。
TSPITRには、次の制限があります。
SYSTEM表領域、UNDO表領域またはロールバック・セグメントを含む表領域では使用できません。
データベースを最新の時点まで完全にリカバリしないため、Oracleに対してリカバリの終了時点を指定する必要があります。次のタイプのメディア・リカバリを実行できます。
| リカバリのタイプ | ファンクション |
|---|---|
|
時間ベースのリカバリ |
指定した時点までのデータのリカバリ |
|
取消しベースのリカバリ |
|
|
変更ベースのリカバリ |
指定したSCNまでのリカバリ |
|
ログ順序リカバリ |
指定したログ順序番号までのリカバリ（Recovery Managerの使用時にのみ使用可能） |
データファイル・メディア・リカバリを使用するのは、消失または破損した現行のデータファイルまたは制御ファイルをリカバリする場合です。また、OFFLINE NORMALオプションを指定せずに表領域がオフライン化され、消失した変更をリカバリする場合にも使用します。データファイル・メディア・リカバリとインスタンス・リカバリでは、どちらもデータベースの整合性を修復する必要があります。ただし、この2つのタイプのリカバリは、追加の機能に違いがあります。メディア・リカバリには次の特性があります。
オンライン・データファイルのメディア・リカバリが必要な場合は、データベースをオープンできません。また、メディア・リカバリが完了するまでは、メディア・リカバリを必要とするデータファイルはオンライン化できません。次の使用例では、メディア・リカバリが必要です。
OFFLINE NORMALオプションを指定せずに（ユーザーにより、またはOracleにより自動的に）オフライン化される場合。
データベースがインスタンスによりオープンされていれば、データファイルのメディア・リカバリはオフライン・データファイルにのみ機能します。クラッシュ・リカバリで十分な場合にも、データベースをオープンする前にデータファイル・メディア・リカバリを実行できます。その場合も、データベースのオープン時にクラッシュ・リカバリが自動的に実行されます。
ファイルにメディア・リカバリが必要な場合には、必要な変更がすべてオンライン・ログに含まれていても、メディア・リカバリを実行する必要があることに注意してください。つまり、アーカイブ・ログが不要であってもリカバリを実行する必要があります。リカバリを必要しないファイルに対してメディア・リカバリを起動すると、リカバリ対象が検出されず、エラー「リカバリは必要ありません」が通知されます。
ブロック・メディア・リカバリは、すべてのデータベース・ファイルをオンラインで使用可能な状態に保ったまま、個々のデータ・ブロックをリストアしてリカバリするテクニックです。破損がデータベース・ファイルのサブセットのうち少数のブロックのみに限られている場合は、データファイル・リカバリよりもブロック・メディア・リカバリが適しています。
ブロック・メディア・リカバリへのインタフェースは、Recovery Managerで提供されます。主要なバックアップおよびリカバリ・ソリューションとしてRecovery Managerをまだ使用していない場合も、必要なユーザー管理データファイルとアーカイブREDOログのバックアップをRecovery Managerリポジトリにカタログ化することで、ブロック・メディア・リカバリを実行できます。
物理ファイルをリカバリする場合は、2つの基本的な方法から選択できます。 次のことができます。
RECOVERコマンドを実行してリカバリする方法
どちらの方法を選択した場合も、データベース、表領域またはデータファイルをリカバリできます。メディア・リカバリを実行する前に、どのデータファイルをリカバリするかを決定する必要があります。通常は、固定ビューV$RECOVER_FILEを使用できます。このビューには、リカバリが必要な全ファイルと、リカバリを必要とするエラーの説明が表示されます。
Recovery Managerの基本的なリカバリ・コマンドは、RESTOREおよびRECOVERです。RESTOREを使用して、バックアップ・セットまたはディスク上のイメージ・コピーから、データファイルを現行または新規の場所にリストアします。アーカイブREDOログを含むバックアップ・セットもリストアできますが、通常、この操作は不要です。Recovery Managerでは、リカバリに必要なアーカイブ・ログが自動的にリストアされ、リカバリの完了後に検出されるためです。Recovery ManagerのRECOVERコマンドを使用してメディア・リカバリを実行し、アーカイブ・ログまたは増分バックアップを適用します。
Recovery Managerでは、バックアップとコピーのリカバリおよびリストア手順が自動化されます。
Recovery Managerを使用しない場合は、オペレーティング・システムのユーティリティを使用してバックアップをリストアしてから、SQL*PlusのRECOVERコマンドを実行してデータベースをリカバリできます。次の基本手順に従う必要があります。
データファイルを元の場所にリストアできない場合は、リストア後のデータファイルを配置し直して、制御ファイル内で場所を変更します。
RECOVERコマンドを使用してデータファイルのバックアップをリカバリします。論理データの破損やユーザー・エラーによる問題を解決するために、Oracle Flashbackを使用できます。フラッシュバック・データベースとフラッシュバック・テーブルを使用すると、以前の時点まですばやくリカバリできます。
この項の内容は、次のとおりです。
Oracle Flashback Databaseを使用すると、Oracleデータベースを以前の時点まで迅速にリカバリし、論理データの破損やユーザー・エラーによる問題を解決できます。
フラッシュ・リカバリ領域と呼ばれるOracle管理ディスク領域が構成されており、フラッシュバック機能を使用可能にしている場合は、Recovery ManagerとSQLのFLASHBACK DATABASEコマンドを使用して、データベースを以前の時点まで戻すことができます。フラッシュバック・データベースは、物理ファイルのリストアを伴わないため、実際のメディア・リカバリではありません。ただし、迅速かつ容易であり、データベース全体のリストアを必要としないため、RESTOREおよびRECOVERコマンドを使用するよりもフラッシュバックの方が適切な場合があります。
データベースをフラッシュバックするために、Oracleはブロックのパスト・イメージを使用してデータベースに対する変更をバック・アウトします。通常のデータベース操作中には、これらのブロック・イメージがフラッシュバック・ログに記録されることがあります。フラッシュバック・ログは順次書き込まれ、アーカイブされることはありません。フラッシュバック・ログは、フラッシュ・リカバリ領域内で自動的に作成、削除およびサイズ変更されます。フラッシュバック・ログに注意する必要があるのは、パフォーマンスを監視する場合と、フラッシュバック・ログ用のフラッシュ・リカバリ領域に割り当てるディスク容量を決定する場合のみです。
データベースのフラッシュバックに要する時間は、データベース全体のリストアおよびリカバリの所要時間ではなく、データベースをどの時点まで戻す必要があるかに比例し、長時間かかる場合があります。フラッシュバック・ログ内のビフォア・イメージは、データベースを過去のある時点までリストアするためにのみ使用され、データベースを過去のいずれかの時点で一貫性のある状態まで戻すにはフォワード・リカバリが使用されます。Oracleはデータファイルを以前の特定時点まで戻しますが、初期化パラメータ・ファイルなどの補助ファイルは特定時点まで戻されません。
Oracle Flashback Tableを使用すると、1つの文で表を指定の時点までリカバリできます。表データとともに、関連する索引、トリガーおよび制約をリストアできます。データベースがオンライン状態のときに、指定された表に対する変更のみが取り消されます。フラッシュバック・テーブルは、不良ディスクやデータ・セグメントと索引の非一貫性など、物理的な破損には対処しません。
フラッシュバック・テーブルは、セルフサービス修復ツールと同様に機能します。たとえば、偶然、表から重要な行を数行削除してしまい、それをリカバリするとします。FLASHBACK TABLE文を使用すると、表を削除前の時点までリストアし、欠落していた表内の行を確認できます。
表とその内容を、特定の実時間またはユーザー指定のシステム変更番号（SCN）まで戻すことができます。フラッシュバック・テーブルをOracle Flashback Version QueryおよびOracle Flashback Transaction Queryとともに使用して、表をどの時点までリストアする必要があるかを調べます。
|
関連項目
Oracleフラッシュバック問合せの詳細は、「Oracleフラッシュバック問合せの概要」を参照してください。 データベース全体を以前の時点まで戻す方法の詳細は、「Oracle Flashback Databaseの概要」を参照してください。 |
フラッシュバック・テーブルを正常に終えるには、システムに指定のSCNまたはタイムスタンプを満たすために十分なUNDO情報が必要であり、表に指定されている整合性制約には違反していない必要があります。また、行移動を使用可能にする必要があります。
フラッシュバック・テーブルで使用する過去の時点は、システムのUNDO保存により制御されます。Oracle Database 10gでは、UNDO保存期間と呼ばれるパラメータが自動的にチューニングされます。UNDO保存期間とは、古いUNDO情報（コミットされたトランザクションのUNDO情報）が上書き可能になるまでの時間を示します。データベースにより、使用統計が収集され、これらの統計およびUNDO表領域サイズに基づいてUNDO保存期間がチューニングされます。
|
関連項目
|
この項の内容は、次のとおりです。
SGAのバッファ・キャッシュ内のデータベース・バッファは、最低使用頻度（LRU）アルゴリズムを使用して、必要な場合にのみディスクに書き込まれます。このアルゴリズムがデータベース・ライター・プロセスで使用され、データベース・バッファがデータファイルに書き込まれる方法により、データファイルにはコミットされていないトランザクションにより変更されたデータ・ブロックや、コミット済トランザクションからの変更が欠落しているデータ・ブロックが含まれている場合があります。
インスタンス障害が発生すると、次の2つの問題が発生する可能性があります。
このジレンマを解決し、システム障害から正常にリカバリするために、通常、Oracleでは2つのステップが使用されます。1つはREDOログを使用したロールフォワード（キャッシュ・リカバリ）、もう1つはロールバック・セグメントまたはUNDOセグメントを使用したロールバック（トランザクション・リカバリ）です。
オンラインREDOログは、データ、索引およびロールバック・セグメントなどのデータベース・ブロックに対する変更をすべて記録する、オペレーティング・システム・ファイルの集合です。変更がコミット済かどうかは問いません。Oracleブロックに対する変更は、すべてオンライン・ログに記録されます。
インスタンス障害またはディスク障害からリカバリする最初のステップを、キャッシュ・リカバリまたはロールフォワードと呼びます。このステップでは、REDOログに記録された変更すべてをデータファイルに再適用する必要があります。REDOログにはロールバック・データも記録されているため、ロール・フォワードでは対応するロールバック・セグメントも再生成されます。
ロールフォワードでは、必要に応じて多数のREDOログ・ファイルをたどり、データベースを後の時点まで進行させます。通常、ロールフォワードにはオンラインREDOログ・ファイルが含まれ（インスタンス・リカバリまたはメディア・リカバリ）、アーカイブREDOログ・ファイルが含まれる場合（メディア・リカバリのみ）もあります。
ロールフォワード後のデータ・ブロックには、コミット済の変更がすべて含まれています。また、障害発生前にデータファイルに保存されていたか、REDOログに記録されてキャッシュ・リカバリ時に取り込まれた、コミットされていない変更も含まれることがあります。
Oracleは、手動UNDO管理モードまたは自動UNDO管理モードで実行できます。手動モードでは、ロールバック・セグメントを作成および管理して、データベースに対する変更のビフォア・イメージを記録する必要があります。自動UNDO管理モードでは、1つ以上のUNDO表領域を作成します。これらのUNDO表領域には、従来のロールバック・セグメントに似たUNDOセグメントが含まれています。主な違いは、OracleによりUNDOが自動的に管理されることです。
UNDOブロックには（ロールバック・セグメントにあるか自動UNDO表領域にあるかにかかわらず）、特定のデータベース操作中に取り消す必要のあるデータベース操作が記録されます。データベース・リカバリの場合、UNDOブロックでは、ロールフォワード・フェーズで以前に適用された、コミットされていないトランザクションの影響がロールバックされます。
ロールフォワード後は、コミットされなかった変更を取り消す必要があります。OracleはUNDOブロックを適用して、障害発生前に書き込まれたか、キャッシュ・リカバリ中にREDOの適用により取り込まれたデータ・ブロック内の、コミットされていない変更をロールバックします。このプロセスをロールバックまたはトランザクション・リカバリと呼びます。
図15-3に、ロールフォワードとロールバックを示します。この2つは、どのタイプのシステム障害からのリカバリにも必要なステップです。
Oracleは、必要に応じて同時に複数のトランザクションをロールバックできます。障害時点でアクティブになっていたシステム全体のトランザクションすべてに、終了マークが付けられます。終了したトランザクションがSMONによりロールバックされるのを待たずに、新規トランザクションでは阻止しているトランザクション自体をリカバリし、必要な行ロックが取得されます。
クラッシュ・リカバリは、シングル・インスタンス・データベースの障害時、またはOracle Real Application Clustersデータベースの全インスタンスの障害時のリカバリに使用します。インスタンス・リカバリでは、障害の発生していないインスタンスがOracle Real Application Clustersデータベース内で障害インスタンスをリカバリする場合について説明します。
クラッシュ・リカバリとインスタンス・リカバリを行う目的は、終了したインスタンスのキャッシュ内にあるデータ・ブロックの変更をリストアし、オープン状態になっていたREDOスレッドをクローズすることです。インスタンス・リカバリおよびクラッシュ・リカバリでは、オンラインREDOログ・ファイルと現行のオンライン・データファイルのみが使用されます。Oracleでは、終了したインスタンスのREDOスレッドも一緒にリカバリします。
クラッシュ・リカバリとインスタンス・リカバリは、2つの異なる操作を伴います。1つはオンラインREDOレコードに含まれるコミット済トランザクションとコミットされていないトランザクションの両方を適用し、現行のオンライン・データファイルをロールフォワードすることです。もう1つは、コミットされていないトランザクションで行われた変更を元の状態までロールバックすることです。
クラッシュ・リカバリとインスタンス・リカバリには、次の共通する特性があります。
SHUTDOWN ABORTの後もディスクに残っている）オンライン・データファイルを使用して変更をREDOします。
Oracleでは、次の2つの場合にこのリカバリが自動的に実行されます。
要点は、クラッシュ・リカバリとインスタンス・リカバリの両方で、REDOが自動的に適用されることです。REDOログを提供するためにユーザーが介入する必要はありません。ただし、データベース・サーバーでパラメータを設定して、インスタンスの存続期間とクラッシュ・リカバリのパフォーマンスをチューニングできます。また、インスタンス・リカバリのロールフォワード・フェーズとロールバック・フェーズを別々にチューニングすることもできます。
この項の内容は、次のとおりです。
メディア・リカバリを使用するのは、1つ以上のデータファイルが物理的に破損した場合です。この状況は、ハードウェア・エラーや、意図せずにファイルを削除するなどのユーザー・エラーが原因で発生することがあります。完全メディア・リカバリは、個々のデータファイル、表領域またはデータベース全体で使用します。
不完全メディア・リカバリを使用するのは、データベースが論理的に破損した場合です。この状況は、アプリケーション・エラーや、意図せずに表または表領域を削除するなどのユーザー・エラーが原因で発生することがあります。不完全メディア・リカバリは、データベース全体でのみ使用し、個々のデータファイルや表領域には使用しません。（データベース全体の不完全メディア・リカバリを実行しない場合は、個々の表領域に対してPoint-in-Timeリカバリを実行できます。）
ブロック・メディア・リカバリを使用するのは、1つ以上のファイル内で少数のブロックが物理的に破損した場合です。通常、この状況は、不良ディスク・コントローラなどのハードウェア・エラーや、オペレーティング・システムのI/Oエラーが原因で発生します。ブロック・メディア・リカバリは個々のデータ・ブロックで使用し、データベースの残りの部分はリカバリ中もオンライン化されたまま使用可能になっています。
フラッシュバック・テーブルは、プッシュ・ボタンによるソリューションであり、表の内容を特定の時点までリストアします。これはフラッシュバック問合せの最上位にあるアプリケーションで実行できますが、効率的ではありません。
フラッシュバック・データベースは、データベース全体に適用されます。構成とリソースが必要ですが、不完全データベース・リカバリにかわる高速な手段を提供します。
フラッシュバック・テーブルでは、UNDO表領域内の情報を使用して表がリストアされます。この方法には、使用しやすさ、可用性および高速リストアという点でメディア・リカバリよりも大きな利点があります。
フラッシュバック・データベースとフラッシュバック・テーブルでは、粒度、パフォーマンスおよび制限に違いがあります。プライマリ・データベースの場合、次の状況ではフラッシュバック・テーブルではなくフラッシュバック・データベースを使用することを考慮してください。
別テーブルからデータのリストアを実行するには、フラッシュバック問合せのSQLのAS OF ...句を使用してCTAS（CREATE TABLE AS SELECT ... AS OF ...）を実行します。たとえば、特定の時点における表のコピーを作成するには、次の文を発行します。
CREATE TABLE old_emp AS SELECT * FROM employees AS OF TIMESTAMP '2002-02-05 14:15:00'
別テーブルのデータを使用してテーブルの作成を行う場合は、データのみが戻されます。制約や索引などはリストアされません。フラッシュバック・テーブルに比べると、この操作は大幅な時間と領域を必要とします。ただし、表のフラッシュバックでは、指定の時刻以降に変更されたブロック内の行のみがリストアされるため効率的です。
物理バックアップに対して、論理バックアップとは、表やストアド・プロシージャなどのスキーマ・オブジェクトをバイナリ・ファイルにエクスポートすることです。Oracleスキーマ・オブジェクトをOracleとの間で移動するには、Oracleユーティリティを使用します。エクスポートまたはData Pump Exportは、Oracleデータベースからバイナリ形式のオペレーティング・システム・ファイルにデータを書き込みます。インポートまたはData Pump Importは、エクスポート・ファイルを読み取って、対応するデータを既存のデータベースにリストアします。
インポートとエクスポートはOracleデータを移動するように設計されていますが、Oracleデータベース内のデータを保護する補足的手段として使用することもできます。OracleのImportおよびExport Utilityのみをデータのバックアップ手段として使用しないでください。
OracleのImportおよびExport Utilityの機能はCTASと類似していますが、制約、索引などをリストアします。フラッシュバック時に対応するよりも前の時点でエクスポートが実行されていれば、どちらのユーティリティでも表全体が効率的に再作成されます。フラッシュバック・テーブルでは、変更があった行のサブセットのみがリストアされるため、Import/Export Utilityよりもパフォーマンスは効率的です。
表領域のPoint-in-Timeリカバリを使用するのは、1つ以上の表領域が論理的に破損しており、データベース全体の不完全メディア・リカバリを実行しない場合です。表領域のPoint-in-Timeリカバリは、個々の表領域で使用されます。
フラッシュ・リカバリ領域は、バックアップおよびリカバリ・ファイル用の中央ディスク位置を提供するOracle管理ディレクトリ、ファイル・システムまたは自動ストレージ管理のディスク・グループです。Oracleは、アーカイブ・ログをフラッシュ・リカバリ領域に作成します。Recovery Managerはフラッシュ・リカバリ領域にバックアップを格納でき、それをメディア・リカバリ中にファイルをリストアするときに使用します。フラッシュ・リカバリ領域は、テープ用のディスク・キャッシュとしても機能します。
Oracleのリカバリ・コンポーネントは、フラッシュ・リカバリ領域と対話し、データベースがフラッシュ・リカバリ領域にあるファイルで完全にリカバリ可能であることを保証します。メディア障害後のデータベースのリカバリに必要なファイルは、すべてフラッシュ・リカバリ領域に属します。
フラッシュ・リカバリ領域には、次のリカバリ関連ファイルが格納されます。
Oracleでは、フラッシュ・リカバリ領域で使用できる容量としてディスク制限を定義できます。このディスク制限により、ディスク全体をフラッシュ・リカバリ領域専用にするのではなく、残りのディスク領域を他の用途に使用できます。これには、Oracleに認識されないオーバーヘッドはありません。たとえば、フラッシュ・リカバリ領域のディスク制限には、圧縮、ミラー化、または他のなんらかの冗長性メカニズムによるファイル・システムの余分なサイズは含まれません。
OracleとRecovery Managerは、使用領域がフラッシュ・リカバリ領域のディスク制限に達するまで、フラッシュ・リカバリ領域にファイルを作成します。その後、Oracleは、廃止、冗長コピー、または3次記憶装置にバックアップされた既存のファイルの最小セットを、フラッシュ・リカバリ領域から削除します。使用可能なディスク領域が15%を下回ると警告が発行されますが、ディスクがフラッシュ・リカバリ領域のディスク制限の100%に達するまでは引き続きディスクを埋めていきます。
フラッシュ・リカバリ領域は、大きいほど有用になります。推奨ディスク制限は、データベース・サイズ、増分バックアップのサイズ、およびテープにコピーされていない全アーカイブ・ログのサイズの合計です。
フラッシュ・リカバリ領域が表領域のコピーを十分に格納できる大きさであれば、その表領域から3次記憶装置にアクセスする必要はありません。フラッシュ・リカバリ領域の最小サイズは、テープにコピーされていないアーカイブ・ログを十分に格納できるサイズ以上に設定する必要があります。たとえば、フラッシュ・リカバリ領域に対して、標準冗長性を持つ100GBのサイズのASMディスク・グループを使用する場合、フラッシュ・リカバリ領域のディスク制限を50GBに設定する必要があります。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|