この章では、ユーザー管理バックアップおよびリカバリ計画(Recovery Manager (RMAN)を必要としない計画)でOracle Databaseをバックアップする方法について説明します。
この章の内容は次のとおりです。
バックアップを作成する前に、データベース内のすべてのファイルを確認して、バックアップするファイルを決定する必要があります。V$ビューを使用すると、この情報を取得できます。
この項の内容は、次のとおりです。
データベースのデータファイルおよび制御ファイルを確認するには、V$DATAFILE
およびV$CONTROLFILE
ビューを使用します。次に示す手順は、これらのファイルの名前を手動で付けた場合も、Oracle Managed Filesで付けた場合も、同様に使用できます。
注意:
オンラインREDOログ・ファイルはバックアップしないでください。
データファイルおよび制御ファイルを表示する手順
データファイルが現行のオンライン表領域のバックアップの一部であるかどうかを確認するには、V$BACKUP
ビューを問い合せます。
このビューはユーザー管理のオンライン表領域バックアップでのみ有効です。RMANのバックアップおよびオフライン表領域のバックアップでは、表領域のデータファイルをバックアップ・モードに設定する必要がないためです。 一部のユーザー管理バックアップ手順では、分裂ブロックの発生を防ぐため、表領域をバックアップ・モードにする必要があります。ただし、バックアップ・モードでは、データベースへの更新によって通常より多くのREDOが作成されます。
V$BACKUP
ビューは、データベースがオープンしている場合に特に有効です。また、障害時のファイルのバックアップ・ステータスも表示されるため、インスタンス障害の直後にも有効です。この情報を使用して、バックアップ・モードのままになっている表領域があるかどうかを確認します。
現在使用されている制御ファイルが、リストアされたバックアップか、メディア障害の発生後に作成された新しい制御ファイルの場合には、V$BACKUP
は役に立ちません。リストアされた制御ファイルまたは再作成された制御ファイルには、データベースがV$BACKUP
を正確に移入するために必要とする情報が含まれていません。また、ファイルのバックアップをリストアした場合には、V$BACKUP
の中のこのファイルのSTATUS
は、最新のバージョンではなく、ファイルの古いバージョンのバックアップ・ステータスを反映したものになります。このため、このビューにはリストアされたファイルに関して誤解を招くデータが表示される場合があります。
たとえば、次の問合せを実行して、バックアップ・モードに設定された表領域に現在どのようなデータファイルが含まれているかを表示するとします。
SELECT t.name AS "TB_NAME", d.file# as "DF#", d.name AS "DF_NAME", b.status FROM V$DATAFILE d, V$TABLESPACE t, V$BACKUP b WHERE d.TS#=t.TS# AND b.FILE#=d.FILE# AND b.STATUS='ACTIVE';
次の出力例は、tools
およびusers
表領域が現在ACTIVE
ステータスであることを示しています。
TB_NAME DF# DF_NAME STATUS ---------------------- ---------- -------------------------------- ------ TOOLS 7 /oracle/oradata/trgt/tools01.dbf ACTIVE USERS 8 /oracle/oradata/trgt/users01.dbf ACTIVE
STATUS
列にNOT
ACTIVE
が表示されている場合、ファイルが現在バックアップ・モードではない(ALTER
TABLESPACE
...
BEGIN
BACKUP
またはALTER DATABASE BEGIN BACKUP
文を実行していない)ことを意味します。ACTIVE
が表示されている場合、ファイルが現在バックアップ・モードであることを意味します。
NORMAL
、IMMEDIATE
またはTRANSACTIONAL
オプションを使用してデータベースを停止した後で、一貫性のあるデータベース全体のバックアップを実行し、データベース内のすべてのファイルのバックアップを作成できます。データベースのオープン中、またはインスタンス障害やSHUTDOWN
ABORT
コマンドの後に作成されたデータベース全体のバックアップは一貫性のないものになります。この場合のファイルは、データベース・チェックポイントSCNと一貫性がありません。
データベースをARCHIVELOG
モードまたはNOARCHIVELOG
モードのどちらで実行していても、データベース全体のバックアップを作成できます。ただし、データベースをNOARCHIVELOG
モードで実行する場合は、バックアップ前にデータベースを正しく停止して、一貫性のあるバックアップを作成する必要があります。
一貫性のあるデータベース全体のバックアップによって作成されたバックアップ・ファイルのセットでは、すべてのファイルで同じSCNにチェックポイントが設定されているため、一貫性があります。一貫性のあるデータベースのバックアップは、リカバリを実行せずにリストアできます。データベースをARCHIVELOG
モードで実行している場合は、バックアップ・ファイルをリストアした後で、追加のリカバリ手順を実行してデータベースをより新しい時点までリカバリできます。また、データベースがARCHIVELOG
モードの場合には、一貫性のないデータベース全体のバックアップを作成することもできます。
制御ファイルは、データベースのリストアおよびリカバリに重要な役割を果たします。ARCHIVELOG
モードで実行しているデータベースの場合には、ALTER
DATABASE
BACKUP
CONTROLFILE
TO
'
filename
'
文を使用して、制御ファイルをバックアップしておくことをお薦めします。
関連項目:
制御ファイルのバックアップの詳細は、「制御ファイルのユーザー管理バックアップの作成」を参照してください。
一貫性のあるデータベース全体のバックアップの作成
一貫性のあるデータベース全体のバックアップを作成する手順
CDB全体をバックアップする手順
SQL*Plusを開きます。
「ターゲットとしてのrootへの接続」の説明に従って、SYSDBA
またはSYSBACKUP
システム権限を持つユーザーとしてrootに接続します。
「データベース全体のユーザー管理バックアップの作成」の手順に従います。
関連項目:
CDBに対するALTER DATABASEの使用方法の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
PDBをバックアップするには、次の手順を実行します。
表領域およびデータファイルのユーザー管理バックアップを作成する方法は、ファイルがオフラインかオンラインかによって異なります。
この項の内容は、次のとおりです。
SYSTEM
表領域またはアクティブなUNDOセグメントを含む表領域をオフラインにすることはできません。このような表領域では、次の方法は使用できません。
表領域Primary
内に表があり、その索引が表領域Index
にあるとします。表領域Index
をオフラインにし、表領域Primary
をオンラインのままにしておくと、Primary
内にある索引付きの表に対してデータ操作言語(DML)が発行されたときにエラーが発生する可能性があります。この問題は、オプティマイザによって選択されたアクセス方法で、Index
表領域内の索引へのアクセスが必要となった場合にのみ発生します。
オフライン表領域をバックアップする手順
データベースのオープン中は、オンライン表領域のすべてのデータファイルまたは特定のデータファイルをバックアップできます。オンライン表領域が読取り/書込みか読取り専用かによって手順は異なります。
注意:
一時表領域はバックアップしないでください。
この項の内容は、次のとおりです。
表領域がオンラインで、データベースがオープンしているときに、データファイルのユーザー管理バックアップを作成するには、読取り/書込み表領域をバックアップ・モードに設定する必要があります。 ALTER
TABLESPACE
...
BEGIN
BACKUP
文を使用すると、表領域をバックアップ・モードに設定できます。バックアップ・モードでは、変更されたデータ・ブロック全体がREDOストリームにコピーされます。ユーザーがALTER
TABLESPACE
...
END
BACKUP
またはALTER
DATABASE
END
BACKUP
文を使用して表領域のバックアップ・モードを終了すると、データファイル・チェックポイントSCNが現在のデータファイル・チェックポイントSCNまで進みます。
この方法でバックアップされたデータファイルをリストアすると、リカバリが必要な場合は、REDOログ・ファイルの適切なセットを適用するように求められます。REDOログには、データファイルをリカバリし、データファイルを一貫性のある状態にするために必要なすべての変更が含まれています。
オープン状態のデータベース中のオンラインの読取り/書込み表領域をバックアップする手順
複数のオンライン表領域をバックアップする場合には、シリアルまたはパラレルにバックアップできます。必要に応じて、次のいずれかの手順を使用してください。
バックアップが必要な複数の表領域のデータファイルのコピーを、同時にバックアップ・モードで作成できます。 ただし、すべての表領域を一度にオンライン・モードに設定すると、それらの表領域で多くの更新が実行されている場合は、大規模なREDOログが生成される可能性があります。REDOには、変更された各データファイルの変更された各データ・ブロックのコピーを含める必要があるためです。 次に示す手順を実行する前に、生成されるREDOのサイズを検討してください。
オンライン表領域をパラレルにバックアップする手順
バックアップが完了したが、ユーザーがALTER
TABLESPACE
...
END
BACKUP
文を実行していない場合。
インスタンス障害またはSHUTDOWN
ABORT
によってバックアップが中断された場合。
障害からのリカバリが必要なときに、バックアップ・モードのデータファイルをオープンしようとした場合、リカバリ・コマンドが発行されるか、またはデータファイルのバックアップ・モードが終了するまでは、データファイルはオープンされません。
たとえば、起動時に次のようなメッセージが表示される場合があります。
ORA-01113: file 12 needs media recovery ORA-01110: data file 12: '/oracle/dbs/tbs_41.f'
ユーザーが表領域のオンライン・バックアップを終了しなかったために、複数の表領域のデータファイルでメディア・リカバリが必要であると表示された場合、データベースがマウントされているかぎり、ALTER
DATABASE
END
BACKUP
文を実行して、すべてのデータファイルで同時にバックアップ・モードを終了できます。
高可用性が必要な場合およびデータベース管理者(DBA)がデータベースを監視していない場合は、ユーザーの介入を必要とする事態は回避する必要があります。このために、次の内容の障害リカバリ・スクリプトを作成しておくことができます。
ALTER
DATABASE
END
BACKUP
文を実行する。ALTER
DATABASE
OPEN
を実行して、システムが自動的に起動するようにします。ALTER
DATABASE
END
BACKUP
を含む自動化されたクラッシュ・リカバリ・スクリプトは、次の場合に特に有効です。
Oracle Real Application Clusters(Oracle RAC)構成内のすべてのノードで障害が発生した場合。
コールド・フェイルオーバー・クラスタ(最初のノードで障害が発生した場合に、2番目のノードでデータベースをマウントしてリカバリする必要があるOracle RAC構成ではないクラスタ)内の1つのノードで障害が発生した場合。
また、表領域がバックアップ・モードのときに発生したシステム障害後に、次の手動の方法を使用することもできます。
データベースをリカバリし、END
BACKUP
文を発行せずに済ませる。
データベースをマウントし、まだバックアップ・モードになっている各表領域に対してALTER
TABLESPACE
...
END
BACKUP
文を実行する。
オンライン・バックアップが失敗した場合の対処方法は、ALTER
DATABASE
END
BACKUP
文を発行する以外にもあります。つまり、SQL*PlusのRECOVER
コマンドを実行することもできます。他のユーザーがバックアップをリストアしているかどうかがわからない場合は、この方法が有効です。他のユーザーが実際にバックアップをリストアしていた場合に、RECOVER
コマンドによってバックアップが最新に更新されるためです。ALTER
DATABASE
END
BACKUP
またはALTER
TABLESPACE
...
END
BACKUP
文は、ファイルが現行のものであることが確実な場合にのみ実行してください。
注意:
オンライン・バックアップが開始されてから以降に生成されたREDOをスキャンする必要があるため、RECOVER
コマンドを使用した方法には時間がかかります。
RECOVERコマンドを使用して表領域のバックアップ・モードを終了する手順
関連項目:
データベースのリカバリについては、 「ユーザー管理のデータベースのフラッシュバックおよびリカバリの実行」 を参照してください
オンラインの読取り専用表領域をバックアップする場合は、オンライン・データファイルをバックアップするのみで実行できます。データベースではデータファイルに対する変更が許可されないため、表領域をバックアップ・モードに設定する必要はありません。
読取り専用表領域のセットが自己完結型の場合には、オペレーティング・システム・コマンドを使用して表領域をバックアップする以外に、トランスポータブル表領域機能を使用して、表領域のメタデータをエクスポートすることもできます。メディア・エラーまたはユーザー・エラー(読取り専用表領域の表を誤って削除するなど)が発生した場合、表領域を元のデータベースに戻すことができます。
関連項目:
表領域のトランスポート方法については、『Oracle Database管理者ガイド』を参照してください。
オープン状態のデータベースのオンラインの読取り専用表領域をバックアップする手順
「表領域およびデータファイルのユーザー管理バックアップの作成」の項の手順は、次の項で説明する変更を除いて、CDBおよびPDBに当てはまります。
「オフラインの表領域およびデータファイルのユーザー管理バックアップの作成」で説明するガイドラインは、CDBおよびPDBの表領域およびデータファイルにも当てはまります。
rootコンテナでオフラインの表領域をバックアップするには、次の手順を実行します。
SQL*Plusを開きます。
「ターゲットとしてのrootへの接続」の説明に従って、SYSDBA
またはSYSBACKUP
システム権限を持つユーザーとしてrootに接続します。
PDBのオフラインの表領域をバックアップするには、次の手順を実行します。
SYSDBA
またはSYSBACKUP
システム権限を持つユーザーとしてPDBに接続します。「オンラインの表領域およびデータファイルのユーザー管理バックアップの作成」で説明するガイドラインは、CDBおよびPDBの表領域およびデータファイルにも当てはまります。
rootコンテナでオンラインの表領域をバックアップするには、次の手順を実行します。
SQL*Plusを開きます。
「ターゲットとしてのrootへの接続」の説明に従って、SYSDBA
またはSYSBACKUP
システム権限を持つユーザーとしてrootに接続します。
PDBのオンラインの表領域をバックアップするには、次の手順を実行します。
SYSDBA
またはSYSBACKUP
システム権限を持つユーザーとしてPDBに接続します。ARCHIVELOG
モードで実行中のデータベースの構造変更を行った後で、データベースの制御ファイルをバックアップします。データベースの制御ファイルをバックアップするには、ALTER
DATABASE
システム権限が必要です。
この項の内容は、次のとおりです。
制御ファイルは、CREATE CONTROLFILE
文が含まれるテキスト・ファイルにバックアップできます。トレース・ファイルを編集し、トレース・ファイルの作成時点で現行のものであった制御ファイルに基づいて、新しい制御ファイルを作成するスクリプトを作成することができます。
SQL文でRESETLOGS
オプションもNORESETLOGS
オプションも指定しなかった場合は、トレース・ファイルにRESETLOGS
とNORESETLOGS
の両方のオプション用の制御ファイルが含まれます。ALTER TABLESPACE ... ADD TEMPFILE
文を使用すると、出力に一時ファイル・エントリが含まれます。
NORMALモードでオフラインにされた表領域または読取り専用表領域をリカバリしないように、CREATE
CONTROLFILE
文を編集してそれらを除外してください。再作成された制御ファイルを使用してデータベースをオープンすると、データベースではこれらの省略されたファイルはMISSING
としてマークされます。ALTER
DATABASE
RENAME
FILE
文を実行すると、それらのファイルを元のファイル名に戻すことができます。
CREATE CONTROLFILE
文を含むトレース・ファイルは、DIAGNOSTIC_DEST
初期化パラメータに指定されたサブディレクトリに格納されます。CREATE CONTROLFILE
文が書き込まれるトレース・ファイルの名前および場所については、データベースのアラート・ログで確認できます。アラート・ログの場所を確認する方法については、『Oracle Database管理者ガイド』を参照してください。
制御ファイルをトレース・ファイルにバックアップする手順
関連項目:
CREATE
CONTROLFILE
文に含まれる、読取り専用ファイル、NORMALモードでオフライン化されたファイルおよび一時ファイルに関連する特殊な問題については、「再作成された制御ファイルを使用した読取り専用ファイルのリカバリ」を参照してください。
プライマリのアーカイブ場所のディスク領域を節約するために、アーカイブ・ログをテープまたは代替のディスクの場所にバックアップできます。複数の場所にアーカイブするときには、各ログ順序番号の1つのコピーのみバックアップします。
アーカイブREDOログをバックアップする手順
この項の内容は、次のとおりです。
サード・パーティ・ツールには、ディスクまたは論理デバイスのセットをミラー化(プライマリ・データの正確な複製を別の場所に保持)し、後でミラーを分割できるものがあります。ミラーの分割では、コピーが分離されるため、それぞれを別々に使用できます。
SUSPEND
/RESUME
の機能を使用すると、データベースに対するI/Oを一時停止した後、ミラーを分割し、分割されたミラーのバックアップを作成できます。バックアップ・モード機能を補完するこの機能によって、I/Oが新しく実行されないように、データベースI/Oを一時停止できます。その後、一時停止中のデータベースにアクセスし、I/Oに影響を受けずにバックアップを作成できます。
通常、ミラーの分割によるバックアップを作成するためにSUSPEND
/RESUME
を使用する必要はありませんが、使用しているシステムで、ボリュームを分割する前にデータベース・キャッシュの使用済バッファを排除しておく必要がある場合には、このコマンドが必要になります。 RAIDデバイスの中には、分割操作の実行中に書込みを一時停止できるものがあります。使用しているシステムでこの機能を使用できるかどうかは、RAIDのベンダーに確認してください。
ALTER
SYSTEM
SUSPEND
文は、データファイル・ヘッダー、データファイルおよび制御ファイルに対するI/Oを停止して、データベースを一時停止します。データベースが一時停止すると、既存のすべてのI/O操作は完了できますが、データベースに対する新規のI/Oアクセスの試行はキューされます。
ALTER
SYSTEM
SUSPEND
文およびALTER
SYSTEM
RESUME
文は、インスタンスのみではなく、データベースに対して実行されます。ALTER
SYSTEM
SUSPEND
文がOracle RAC構成中の1つのシステムで入力された場合は、内部のロッキング・メカニズムによって全インスタンスに停止要求が伝播され、クラスタ内のすべてのアクティブなインスタンスでI/O操作が一時停止されます。
データベースが正常に一時停止した後、ディスクにデータベースをバックアップするか、ミラー化を解除できます。データベースを一時停止してもI/Oがすぐに終了されるとはかぎらないため、ALTER
SYSTEM
SUSPEND
文の前にBEGIN
BACKUP
文を使用して、表領域をバックアップ・モードにすることをお薦めします。
分割されたミラーをバックアップするには、従来のユーザー管理バックアップ方式を使用する必要があります。データファイル・ヘッダーの読取りが必要になるため、RMANはデータベースのバックアップまたはコピーを作成できません。データベースのバックアップが終了するか、ミラーを復元した後、ALTER
SYSTEM
RESUME
文を使用して、通常のデータベース操作を再開できます。
ミラーを分割せずに一時停止中のデータベースをバックアップすると、バックアップ中はデータベースにアクセスできなくなるため、データベースが長期間停止する可能性があります。ミラーを分割してバックアップを実行すると、停止は短時間で済みます。停止時間は、フラッシュするキャッシュのサイズ、データファイルの数、およびミラー化の解除に必要な時間によって異なります。
SUSPEND/RESUME
機能には次の制限があります。
Oracle RAC構成では、オリジナル・ノードの一時停止中に新規インスタンスを起動できません。
ALTER
SYSTEM
SUSPEND
文またはALTER
SYSTEM
RESUME
文からはチェックポイントは開始されません。
データベースの一時停止中は、IMMEDIATE
、NORMAL
またはTRANSACTIONAL
オプションを指定してSHUTDOWN
コマンドを発行できません。
一時停止中のデータベースに対してSHUTDOWN
ABORT
を発行すると、データベースが再度アクティブになります。この操作により、メディア・リカバリまたは障害リカバリが無応答状態になるのを回避できます。
SUSPENDモードでミラーの分割によるバックアップを作成する手順
RAWデバイスとは、ファイル・システムを持たないディスクまたはパーティションです。RAWデバイスに保管できるファイルは1つのみです。RAWデバイスにファイルをバックアップする場合は、オペレーティング・システム固有の問題が発生します。後続の項では、UNIX、LinuxおよびWindowsでのこれらの問題の一部について説明します。
この項の内容は、次のとおりです。
RAWデバイスとの間でバックアップを行う場合は、LinuxおよびUNIXのdd
コマンドが最も一般的なバックアップ・ユーティリティになります。このユーティリティの詳細は、オペレーティング・システムのマニュアルを参照してください。
dd
を効率的に使用するには、ご使用のデータベースに基づいて適切なオプションを指定する必要があります。表29-1に、dd
に使用するオプションに影響を及ぼすデータベースの詳細を示します。
表29-1 ddの使用に重要なデータベースの詳細
データ | 説明 |
---|---|
ブロック・サイズ |
|
RAWオフセット |
システムによっては、RAWデバイス上のファイルの最初の部分が、オペレーティング・システムの使用のために確保されていることがあります。この記憶領域をRAWオフセットと呼びます。Oracle Databaseでは、これらのバイトをバックアップまたはリストアしません。 |
Oracle Databaseブロック |
すべてのOracle Databaseファイルの最初の部分には、オペレーティング・システム固有のコードによって、ブロック0(ゼロ)と呼ばれるOracleブロックが配置されます。Oracle汎用コードはこのブロックを認識しませんが、このブロックは、オペレーティング・システム上でファイルのサイズに含められます。一般的にこのブロックは、ファイル中の他のOracleブロックと同じサイズになります。 |
表29-1の情報を使用して、表29-2に示すdd
オプションを設定できます。
表29-2 ddコマンドのオプション
オプション | 説明 |
---|---|
|
入力ファイル、つまり読み込むファイルの名前。 |
|
出力ファイル、つまり書き出すファイルの名前。 |
|
|
|
RAWオフセットが存在する場合に、入力RAWデバイスでスキップする |
|
RAWオフセットが存在する場合に、出力RAWデバイスでスキップする |
|
入力ファイルの合計サイズにブロック |
RAWデバイスはバックアップの入力または出力デバイスに使用できるため、4つのバックアップ・シナリオを想定できます。dd
で選択できるオプションは、表29-3に示すように、どのシナリオを選択するかによって異なります。
表29-3 ddバックアップのシナリオ
バックアップ元 | バックアップ先 | ddコマンドで指定されるオプション |
---|---|---|
RAWデバイス |
RAWデバイス |
|
RAWデバイス |
ファイル・システム |
|
ファイル・システム |
RAWデバイス |
|
ファイル・システム |
ファイル・システム |
|
この項で示すdd
ユーティリティの使用方法の例では、次のように想定しています。
30720KBのデータファイルをバックアップします。
データファイルの最初には8KBのブロック0(ゼロ)があります。
RAWオフセットは64KBです。
コピーにRAWデバイスが関係するときには、dd
ブロック・サイズを8KBに設定します。
次の例では、1つのRAWデバイスから別のRAWデバイスにバックアップします。
% dd if=/dev/rsd1b of=/dev/rsd2b bs=8k skip=8 seek=8 count=3841
次の例では、RAWデバイスからファイル・システムにバックアップします。
% dd if=/dev/rsd1b of=/backup/df1.dbf bs=8k skip=8 count=3841
次の例では、ファイル・システムからRAWデバイスにバックアップします。
% dd if=/backup/df1.dbf of=/dev/rsd2b bs=8k seek=8
次の例では、ファイル・システムからファイル・システムにバックアップし、ブロック・サイズに大きい値を設定してI/Oパフォーマンスを高めます。
% dd if=/oracle/dbs/df1.dbf of=/backup/df1.dbf bs=1024k
WindowsはLinuxおよびUNIXと同じようにRAWディスク・パーティションをサポートするため、データファイル、オンライン・ログおよび制御ファイルをこの中に格納できます。 各RAWパーティションにはドライブ文字または物理ドライブ番号が割り当てられます。ファイル・システムは含まれません。LinuxおよびUNIXの場合と同じように、Windowsでも各RAWパーティションは1つのファイルにマップされます。
Windowsでは、Oracleファイルのネーミング規則はLinuxおよびUNIXの場合と異なります。Windowsの場合、RAWデータファイル名は次のような形式になります。
\\.\drive_letter: \\.\PHYSICALDRIVEdrive_number
たとえば、次の名前はRAWファイル名として使用できます。
\\.\G: \\.\PHYSICALDRIVE3
RAWデータファイルのユーザー管理バックアップを作成する手順は、Windowsで提供されるcopy.exe
またはntbackup.exe
ユーティリティのかわりにOracleのOCOPY
ユーティリティを使用することを除いて、Windowsファイル・システムでのファイルのコピーと基本的に同じです。OCOPY
は64ビットのファイルI/O、物理RAWドライブおよびRAWファイルをサポートします。OCOPY
ユーティリティはテープに直接バックアップできません。
OCOPY
のオンライン・マニュアルを表示するには、WindowsプロンプトにOCOPY
とのみ入力します。出力例を次に示します。
Usage of OCOPY: ocopy from_file [to_file [a | size_1 [size_n]]] ocopy -b from_file to_drive ocopy -r from_drive to_dir
表29-4に、OCOPY
の重要なオプションを示します。
表29-4 OCOPYのオプション
オプション | 処理 |
---|---|
|
入力ファイルを複数の出力ファイルに分割します。このオプションは、入力ファイルよりも小さいデバイスにバックアップする場合に有効です。 |
|
複数の入力ファイルを組み合せて、1つの出力ファイルに書き込みます。このオプションは、 |
この例では、次のように想定しています。
データファイル12
はRAWパーティション\\.\G:
にマウントされています。
C:
ドライブにファイル・システムをマウントしています。
データベースはオープンしています。
RAWパーティション\\.\G:
上のデータファイルをローカル・ファイル・システムにバックアップするには、データファイル12
をバックアップ・モードにした後で、プロンプトで次のコマンドを実行します。
OCOPY "\\.G:" C:\backup\datafile12.bak
この例では、次のように想定しています。
\\.\G:
はデータファイル7
を含むRAWパーティションです。
E:
ドライブは取り外し可能なディスク・ドライブです。
データベースはオープンしています。
データファイルをドライブE:
にバックアップするには、データファイル7
をバックアップ・モードにした後で、Windowsプロンプトで次のコマンドを実行します。
# first argument is file name, second argument is drive OCOPY -b "\\.\G:" E:\
ドライブE:
が一杯になると、別のディスクを使用できます。この方法で、データファイル7
のバックアップを複数のファイルに分割できます。
同様に、バックアップをリストアするときには、データファイル7
を含む表領域をオフラインにし、次のコマンドを実行します。
# first argument is drive, second argument is directory OCOPY -r E:\ "\\.\G:"
ストレージ・スナップショットの最適化を使用して、データベースをバックアップ・モードにすることなく、データベースのサード・パーティのスナップショットを取得できます。スナップショットは、この項で説明する要件に準拠する必要があります。
ストレージ・スナップショットの最適化には次の利点があります。
データベースをバックアップ・モードにすることに関連する複雑性やオーバーヘッドが削減されます。
RECOVER ... SNAPSHOT TIME
コマンドを使用して、1つの手順でリカバリを実行します。現在の時間またはスナップショット取得後の任意の時点のいずれかにリカバリできます。
ストレージ・スナップショット最適化を使用するには、サード・パーティのスナップショット・テクノロジが、次の要件に準拠する必要があります。
データベースは、スナップショットの間、クラッシュ一貫性が保持される。
スナップショットは、各ファイルの書込み順序を保持する。
スナップショット・テクノロジによって、スナップショットが完了した時間が格納される。
ベンダーがこれらの要件に準拠できない場合、BEGIN BACKUP
句にALTER DATABASE
またはALTER TABLESPACE
文を使用して、データファイルをバックアップ・モードにする必要があります。データファイルは、スナップショットを作成する直前にバックアップ・モードにしてください。表領域がバックアップ・モードに設定されている場合、データベースは、ブロックを変更する前に、ブロック全体の変更前のイメージをREDOストリームに書き込みます。データベースは、ブロックに対する変更をオンラインREDOログに記録もします。また、バックアップ・モードでは、ファイルがバックアップ・モードから削除されるまで、データファイル・チェックポイントがフリーズされます。Oracle Databaseでは、サード・パーティのバックアップ・ツールでデータ・ブロックのコピーの前にファイル・ヘッダーがコピーされることを保証できないため、このようなセーフガードが実行されます。スナップショットの作成後すぐに、ALTER DATABASE
またはALTER TABLESPACE
コマンドにEND BACKUP
句を使用して、バックアップ・モードからデータファイルを戻します。バックアップ・モードの終了は、スナップショットがバックアップ・メディアに実際にコピーされるまで待つ必要はありません。
Volume Shadow Copy Service(VSS)は、アプリケーションでシャドウ・コピーと呼ばれる一貫性のあるスナップショットの作成を可能にするWindows APIのセットです。Oracle VSSライターは、Windowsシステム上でのサービスとして実行され、VSS対応アプリケーションと統合されます。これらのアプリケーションを使用すると、Oracleインスタンスによって管理されているデータベース・ファイルのスナップショットを作成できます。たとえば、Oracle Databaseを読取り/書込みでオープンしている場合は、そのOracle Databaseデータベースのシャドウ・コピーを作成できます。
関連項目:
VSS対応アプリケーションでデータベースをバックアップおよびリカバリする方法については、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。
データファイル・バックアップの有効性を確認する最適な方法は、別のホストにバックアップをリストアして、必要に応じてメディア・リカバリを実行し、データベースのオープンを試行する方法です。このオプションでは、リストア手順のために別のホストを使用できる必要があります。
関連項目:
SQL*Plusでのファイルのリカバリ方法については、「データベースの完全リカバリの実行」を参照してください。
DBVERIFY
プログラムは、オフライン・データファイルに対して物理的なデータ構造の整合性チェックを実行する、外部のコマンドライン・ユーティリティです。DBVERIFY
は、リストア前にデータファイルのユーザー管理バックアップが有効かどうかを確認するために使用したり、データ破損の問題が発生した場合の診断ツールとして使用します。
DBVERIFY
の名前と位置はオペレーティング・システムごとに異なります。たとえば、LinuxまたはUNIX上でデータファイルusers01.dbf
の整合性チェックを実行する場合は、次のようにdbv
コマンドを実行します。
% dbv file=users01.dbf
dbv
の出力例を次に示します。
DBVERIFY - Verification starting : FILE = users01.dbf DBVERIFY - Verification complete Total Pages Examined : 250 Total Pages Processed (Data) : 1 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 0 Total Pages Failing (Index): 0 Total Pages Processed (Other): 2 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 247 Total Pages Marked Corrupt : 0 Total Pages Influx : 0
関連項目:
DBVERIFY
については、『Oracle Databaseユーティリティ』を参照してください。