この章では、すべてのタイプのRMANバックアップを作成するために理解しておく必要がある一般的な概念について説明します。この章の内容は次のとおりです。
バックアップを作成するためのRMANのコマンドはBACKUP
です。RMANのBACKUP
コマンドでは、次のタイプのファイルのバックアップがサポートされています。
データファイルおよび制御ファイル
サーバー・パラメータ・ファイル
アーカイブREDOログ
RMANバックアップ
データベースは、ネットワーク構成ファイル、パスワード・ファイル、Oracleホームの内容などの他のタイプのファイルに依存していますが、これらのファイルはRMANではバックアップできません。同様に、Oracle Databaseの一部の機能(外部表など)には、データファイル、制御ファイルおよびREDOログ以外のファイルが必要な場合があります。RMANでは、これらのファイルをバックアップできません。リストにないファイルについては、RMAN以外の方法でバックアップします。
RMANでBACKUP
コマンドを実行すると、出力は常に1つ以上のバックアップ・セットまたは1つ以上のイメージ・コピーになります。バックアップ・セットはRMANに固有の独自の形式ですが、イメージ・コピーはファイルのビットごとのコピーです。デフォルトでは、RMANはバックアップ・セットを作成します。
BACKUP
コマンドを使用すると、データベースの一貫性バックアップおよび非一貫性バックアップを作成できます。一貫性バックアップは、データベースが一貫性のある状態のときに実行します。SHUTDOWN
NORMAL
、SHUTDOWN IMMEDIATE
またはSHUTDOWN TRANSACTIONAL
コマンドを使用して停止すると、データベースは一貫性のある状態になります。一貫性のある状態での停止では、すべてのREDOがデータファイルに確実に適用されています。データベースをマウントし、この時点でバックアップを作成すると、後でデータベース・バックアップをリストアし、メディア・リカバリを実行せずにオープンすることができます。
一貫性のないデータベース・バックアップを非一貫性バックアップといいます。インスタンスでの障害の発生後またはSHUTDOWN ABORT
コマンドの実行後に作成されたバックアップと同様に、データベースがオープンされているときに作成されたバックアップには一貫性がありません。非一貫性バックアップからデータベースをリストアする場合、Oracle Databaseでは、データベースをオープンする前に、メディア・リカバリを実行し、REDOログ内の保留中の更新情報を適用する必要があります。
注意: データベースがNOARCHIVELOG モードの場合、RMANで非一貫性バックアップを作成することはできません。NOARCHIVELOG モードのデータベースに対してユーザー管理のバックアップ方法を使用する場合、このデータベースの非一貫性バックアップは作成しないでください。 |
データベースがARCHIVELOG
モードで実行されているときに、アーカイブREDOログおよびデータファイルをバックアップする場合、非一貫性バックアップを適切なバックアップおよびリカバリ計画の基礎にすることができます。非一貫性バックアップでは、データベースを完全に保護するバックアップを作成するためにデータベースを停止する必要がないため、優れた可用性が実現されます。
オンラインの表領域またはデータベースのユーザー管理のバックアップを実行すると、データベース・ライター(DBWR)によるファイルの更新と同時に、オペレーティング・システム・ユーティリティによってデータファイルのバックアップが作成される場合があります。ユーティリティは、更新途中の状態のブロックを読み取ることができるため、バックアップ・メディアにコピーされるブロックの前半は更新されていても、後半には古いデータが含まれていることがあります。このタイプの論理的な破損は、分裂ブロックと呼ばれます。つまり、SCNに関して一貫性のないブロックです。このバックアップを後でリストアし、ブロックをリカバリする必要がある場合は、ブロックを使用できないため、リカバリは失敗します。
ユーザー管理のオンライン・バックアップを実行する場合は、BEGIN BACKUP句を指定してALTER DATABASEまたはALTER TABLESPACE
文を使用して、データファイルをバックアップ・モード
にする必要があります。表領域がバックアップ・モードに設定されている場合、データベースは、ブロックを変更する前に、ブロック全体の変更前のイメージをREDOストリームに書き込みます。データベースは、ブロックに対する変更をオンラインREDOログに記録もします。また、バックアップ・モードでは、ファイルがバックアップ・モードから削除されるまで、データファイル・チェックポイントがフリーズされます。Oracle Databaseでは、サード・パーティのバックアップ・ツールでデータ・ブロックのコピーの前にファイル・ヘッダーがコピーされることを保証できないため、このようなセーフガードが実行されます。
ユーザー管理ツールとは異なり、RMANでは、データ・ブロックの形式が認識されるため、追加のロギングまたはバックアップが必要ありません。RMANでは、分裂ブロックがバックアップされないことが保証されています。RMANによるバックアップ中、データベース・サーバー・セッションは各データ・ブロックを読み取り、ブロック・ヘッダーとフッターを比較することによって、分裂していないかどうかを確認します。ブロックが分裂している場合、セッションはそのブロックを再度読み取ります。同じ分裂が検出された場合、ブロックは永続的に破損しているとみなされます。また、RMANでは、ブロックが読み取られる順序が認識されているため、データファイルのヘッダーのチェックポイントをフリーズする必要がなく、このため、そのファイルに最適なチェックポイントを取得できます。
RMANでBACKUP
コマンドを実行すると、1つ以上のバックアップ・セットまたはイメージ・コピーを作成できます。デフォルトでは、出力先がディスクの場合もメディア・マネージャの場合も、バックアップ・セットが作成されます。
注意: 通常、データファイルのバックアップ・セットはデータファイルのイメージ・コピーよりサイズが小さく、書込みにかかる時間が短くなります。 |
この項の内容は、次のとおりです。
RMANは、バックアップ・データをバックアップ・セット(RMANバックアップの最小単位)と呼ばれる論理構造に格納できます。バックアップ・セットには、1つ以上のデータファイル、アーカイブREDOログ、制御ファイルまたはサーバー・パラメータ・ファイルのデータが含まれます。バックアップ・セットは、RMANによってテープ・ドライブやテープ・ライブラリなどのメディア・マネージャにバックアップを書き込むことができる唯一の形式です。
バックアップ・セットには、1つ以上のバイナリ・ファイルがRMAN固有の形式で含まれます。各ファイルは、バックアップ・ピースと呼ばれます。1つのバックアップ・セットに、複数のデータファイルを含めることができます。たとえば、1つのバックアップ・ピースで構成される1つのバックアップ・セットに、10個のデータファイルをバックアップできます。この場合、RMANでは、1つのバックアップ・ピースが出力として作成されます。バックアップ・セットには、このバックアップ・ピースのみが含まれます。
BACKUP
コマンドにSECTION SIZE
パラメータを指定すると、RMANによってマルチセクション・バックアップが作成されます。これは、複数のチャネルでパラレルに作成される単一の大規模なファイルのバックアップです。各チャネルによって、1つのバックアップ・ピースが作成されます。各バックアップ・ピースには、バックアップされるファイルのファイル・セクションが1つ含まれます。
マルチセクション・バックアップ以外のバックアップでは、RMANは、正常に完了したバックアップ・セットのみをリポジトリに記録します。部分バックアップ・セットのようなものはありません。これは、RMANメタデータに部分的なバックアップ・セットのレコードが含まれる可能性がある失敗したマルチセクション・バックアップとは異なります。後者の場合は、DELETE
コマンドを使用して、部分的なバックアップ・セットを削除する必要があります。
注意: RMANは、部分的なバックアップをリストアおよびリカバリの候補とみなしません。 |
バックアップ・セットの作成時に、RMANでは、2種類のブロックの圧縮が使用されます。
未使用ブロックの圧縮(ディスク・バックアップおよびOracle Secure Backupテープ・バックアップをサポート)
NULLブロックの圧縮(すべてのバックアップをサポート)
ブロックの圧縮と呼ばれていますが、ブロックのスキップと考えるとわかりやすくなります。RMANは、データをブロックに圧縮するのではなく、ブロックをバックアップから完全に削除します。RMANでは、データファイルからブロックが読み取られ、バックアップ・セットにブロックが書き込まれます。未使用ブロックの圧縮を有効にすると、RMANでは、現在データベース・セグメントに属しているエクステント内のデータファイルのブロックのみが読み取られます。未使用ブロックの圧縮は、領域がローカルで管理されている表領域をバックアップする場合にのみ使用できます。未使用ブロックの圧縮を使用しない場合、RMANでは、データファイルのすべてのブロックが読み取られます。RMANは、バックアップ・セットにブロックを書き込む前にNULLブロック・テストを適用し、ブロックが一度も使用されていない場合は、このブロックをバックアップ・セットに書き込みません。
未使用ブロックの圧縮では、RMANは各ブロックを確認しません。かわりに、RMANは現在割り当てられているブロックを示すビットマップを読み取った後、現在割り当てられているブロックのみを読み取ります。
未使用ブロックの圧縮は、次の5つの条件がすべて満たされている場合に自動的に実行されます。
COMPATIBLE
初期化パラメータが10.2以上に設定されている。
現在、データベースに定義されている保証付きリストア・ポイントがない。
データファイルがローカルで管理されている。
データファイルが、全体バックアップまたはレベル0の増分バックアップの一部としてバックアップ・セットにバックアップされている。
ディスクにバックアップ・セットが作成されているか、またはOracle Secure Backupがメディア・マネージャである。
RMANでは、バックアップ・セットのバイナリ圧縮がサポートされています。バイナリ圧縮は、BACKUP
コマンドでAS COMPRESSED BACKUPSET
を指定した場合、またはCONFIGURE DEVICE TYPE <DISK | SBT> BACKUP TYPE TO COMPRESSED BACKUPSET
コマンドを使用した場合(1回のみ)に有効になります。バイナリ圧縮には2つのオプションがあります。
BASIC
圧縮アルゴリズムを使用できます。この場合、Advanced Compressionオプションは必要ありません。この設定を使用すると、MEDIUM
に相当する圧縮率を得られますが、CPU使用率は増加します。
Oracle Database 11gリリース2 Advanced Compressionオプションを有効にすると、「Advanced Compressionオプション」に示す圧縮レベルのいずれかを選択できます。
関連項目:
|
UNDOのバックアップの最適化では、RMANは、トランザクションがコミットされているためバックアップのリカバリに不要となったUNDOを除外します。UNDOのバックアップの最適化は、レベル0および全体のディスク・バックアップおよびOracle Secure Backup(OSB)テープ・バックアップに機能します。バックアップの最適化とは異なり、UNDOのバックアップの最適化は構成不可能です。
RMANでは、バックアップ・セットのバックアップの暗号化がサポートされています。ウォレットベースの透過的暗号化またはパスワードベースの暗号化(あるいはその両方)を使用できます。CONFIGURE ENCRYPTION
コマンドを使用すると、永続的な透過的暗号化を構成できます。パスワードベースの暗号化を指定するには、RMANセッション
・レベルでSET ENCRYPTIONコマンドを使用します。
注意: ウォレットベースの暗号化は、パスワードが必要ないため、パスワードベースの暗号化より安全です。パスワードベースの暗号化は、バックアップをトランスポータブルにする必要があるため絶対に必要な場合にのみ使用してください。 |
RMANを使用してディスクに暗号化バックアップを作成するには、データベースでAdvanced Security Optionを使用している必要があります。Oracle Secure Backup SBTは、暗号化RMANバックアップをテープに直接作成するためにサポートされている唯一のインタフェースです。
バックアップ・ピースの一意の名前をRMANに決定させることも、FORMAT
句を使用して名前を指定することもできます。FORMAT
パラメータを指定しない場合、RMANは、%U
置換変数を含む一意のファイル名をデフォルトのバックアップ場所に自動的に生成します。
%U
によってRMANで生成されるSBTバックアップ・ピース名の例は、次のとおりです。
2i1nk47_1_1
ディスクの非Oracle Managed File(OMF)バックアップ・ピースの例は、次のとおりです。
/backups/TEST/2i1nk47_1_1
FORMAT
句では、一意のファイル名を生成するために%U
以外の置換変数がサポートされています。たとえば、データベースの名前を生成するために%d
、DBID用に%I
、タイムスタンプ用に%t
などを使用できます。
最大4つのFORMAT
パラメータを指定できます。複数のFORMAT
パラメータを指定すると、複数のコピーを指定する場合にのみRMANで複数のFORMAT
パラメータを使用できます。BACKUP ...
COPIES
、SET BACKUP COPIES
またはCONFIGURE ... BACKUP COPIES
コマンドを使用すると、複数のコピーを作成できます。
注意: メディア・マネージャを使用する場合のFORMAT の制限(名前のサイズ、ネーミング規則など)については、ベンダーのドキュメントを参照してください。 |
デフォルトでは、バックアップ・セットは、1つのバックアップ・ピースで構成されます。各バックアップ・ピースのサイズを制限するには、CONFIGURE CHANNEL
または
ALLOCATE CHANNELコマンドの
MAXPIECESIZEオプションを指定します。このオプションによって、バックアップ・ピースのサイズが指定したバイト数に制限されます。バックアップ・セットの合計サイズが指定したバックアップ・ピースのサイズを超えた場合、RMANは、バックアップ・セットの内容を保持する複数の物理ピースを作成します。
このオプションは、複数のテープにまたがるバックアップ・ピースを管理できないメディア・マネージャに使用できます。たとえば、最大容量が10GBのテープに、80GBのデータを保持するバックアップ・セットを作成する必要がある場合、メディア・マネージャで使用するテープに格納できる10GBのバックアップ・ピースを作成するように、RMANに指示する必要があります。この場合、バックアップ・セット・メディアは8つのテープから構成されます。SBT 2.0をサポートしているメディア・マネージャの場合、サポートするバックアップ・ピースの最大サイズを示す値をRMANに戻すことができるため、RMANはその値をバックアップ・アクティビティの計画に使用できます。
BACKUP
コマンドにSECTION SIZE
パラメータを指定すると、RMANによってマルチセクション・バックアップを作成できます。この場合、1つのバックアップ・セットに複数のバックアップ・ピースを含めることができます。各バックアップ・ピースにはファイル・セクションが含まれます。マルチセクション・バックアップの目的は、複数のチャネルで大規模なファイルをパラレルでバックアップできるようにすることです。
関連項目:
|
BACKUPコマンドの
backupSpec句を使用すると、バックアップするオブジェクトを指定できます。
backupSpec
句を1つ指定するごとに、1つ以上のバックアップ・セットが作成されます。
バックアップ・セットの合計数および合計サイズは、主にRMANの内部アルゴリズムに基づいています。ただし、CONFIGURE
またはBACKUP
コマンドのMAXSETSIZE
パラメータを使用して、RMANの動作に影響を及ぼすことができます。このパラメータを使用してバックアップ・セットのサイズを制限することによって、セット内のファイル数を間接的に制限でき、場合によっては、RMANに追加のバックアップ・セットを作成させることができます。また、BACKUP ... FILESPERSET
を指定して、各バックアップ・セット内のファイルの最大数を指定することもできます。
関連項目:
|
バックアップ・セットの作成時に、RMANは、ディスクから複数のファイルを同時に読み取って、同じバックアップ・セットにそれらのブロックを書き込むことができます。たとえば、RMANは、2つのデータファイルから同時に読取りを行って、それらのデータファイルのブロックを単一のバックアップ・ピースに組み合せることができます。複数のファイルからのブロックの組合せは、バックアップの多重化と呼ばれます。これに対して、イメージ・コピーは多重化されません。
図8-1に示すように、RMANは、1つのバックアップ・ピースのみを含むバックアップ・セットに3つのデータファイルをバックアップできます。このバックアップ・ピースには、3つの入力データファイルのデータ・ブロックが組み合されて格納されます。
RMANによる多重化は、複数の要因によって決定されます。たとえば、各バックアップ・セットに格納されるデータファイルの数は、BACKUP
コマンドのFILESPERSET
パラメータによって決定されます。RMANが同時に読み取ることができるデータファイルの数は、ALLOCATE CHANNEL
またはCONFIGURE CHANNEL
のMAXOPENFILES
パラメータによって定義されます。基本的な多重化アルゴリズムは、次のとおりです。
各バックアップ・セット内のファイルの数
この数は、FILESPERSET
設定および各チャネルによって読み込まれるファイル数の最小値です。FILESPERSET
のデフォルトは64です。
これは、同時に読み取られ、同じバックアップ・ピースに書き込まれる入力ファイルの数です。多重化のレベルは、MAXOPENFILES
および各バックアップ・セット内のファイル数の最小値です。MAXOPENFILES
のデフォルトは8です。
FILEPERSET
が4に設定されている場合に、1つのチャネルで12のデータファイルをバックアップするとします。多重化のレベルは、この数と8の小さい方になります。したがって、ブロックは、チャネルによって4つのデータファイルから各バックアップ・ピースに同時に書き込まれます。
次に、1つのチャネルで50のデータファイルをバックアップするとします。各バックアップ・セット内のファイル数は50です。多重化のレベルは、この数と8の小さい方になります。したがって、ブロックは、チャネルによって8つのデータファイルから各バックアップ・ピースに同時に書き込まれます。
RMANによるバックアップ・セットの多重化は、メディア・マネージャによる多重化とは異なります。メディア・マネージャによる多重化のタイプの1つとして、メディア・マネージャが、複数のRMANチャネルからの同時出力を単一のシーケンシャル・デバイスに書き込んだ場合に発生するものがあります。また、別のタイプとして、バックアップによって同じテープ上にデータベース・ファイルとデータベース以外のファイルが混在した場合に発生するものもあります。
注意: RMANバックアップには、メディア・マネージャによる多重化を使用しないことをお薦めします。 |
関連項目:
|
プロキシ・コピーでは、RMANは、プロキシ・コピー機能をサポートしているメディア・マネージャに、データ送信の制御を移します。プロキシ・コピーはこの機能をサポートしているメディア・マネージャでのみ使用でき、タイプがDISK
のチャネルでは使用できません。BACKUPコマンドの
PROXY
オプションを使用して、バックアップでプロキシ・コピーを実行することを指定します。
BACKUP
PROXY
コマンドでバックアップするファイルごとに、RMANは、プロキシ・コピーを実行できるかどうかをメディア・マネージャに問い合せて確認します。メディア・マネージャがファイルのプロキシ・コピーを実行できない場合、RMANは、PROXY
オプションを使用しなかった場合と同様にファイルをバックアップします。(PROXY
ONLY
オプションを使用している場合に、プロキシ・コピーが実行できない場合は、RMANはバックアップを行いません。)
制御ファイルはプロキシ・コピーではバックアップされません。制御ファイルのバックアップ操作でPROXY
オプションを指定した場合、このオプションは自動的に無視され、制御ファイルのバックアップが行われます。
関連項目:
|
イメージ・コピーは、1つのデータファイル、アーカイブREDOログ・ファイルまたは制御ファイルの正確なコピーです。 イメージ・コピーはRMAN固有の形式では格納されません。これらは、オペレーティング・システム・コマンドでファイルをコピーした場合と同じ形式で格納されます。イメージ・コピーは、RMANのリストアおよびリカバリ操作中に使用できます。また、RMAN以外のリストアおよびリカバリ方法でもイメージ・コピーを使用できます。
イメージ・コピーを作成してRMANリポジトリに記録するには、RMANのRMAN BACKUP
AS
COPY
コマンドを実行します。また、ディスクのデフォルトのバックアップ・タイプをイメージ・コピーとして構成することもできます。コピーの作成には、データベース・サーバー・セッションが使用されます。このサーバー・セッションが、ファイル内のブロックの検証やRMANリポジトリへのイメージ・コピーの記録などの処理を実行します。
バックアップ・ピースの場合と同様に、FORMAT
変数を使用してイメージ・コピーの名前を指定します。イメージ・コピーの場合は、デフォルトの書式%U
(「バックアップ・ピースのファイル名」を参照)の定義が異なります。次に、%U
によって生成されるデータファイル2
の名前の例を示します。
/d1/oracle/work/orcva/RDBMS/datafile/o1_mf_sysaux_2qylngm3_.dbf
イメージ・コピーを作成する場合は、 BACKUPコマンドの
DB_FILE_NAME_CONVERT
パラメータで、出力コピーに名前を指定することもできます。このパラメータの動作は、DB_FILE_NAME_CONVERT
初期化パラメータと同一です。ファイル名の接頭辞のペアを指定すると、出力ファイルの名前が変更されます。 ファイルがペアのいずれによっても変換されない場合、FORMAT
仕様が使用されます。FORMAT
が指定されていない場合、デフォルトの書式%U
が使用されます。
例8-1では、ファイル名の先頭に/maindisk/oradata/users
が付くデータファイルを、先頭に/backups/users_ts
が付くファイル名に変更してコピーします。
例8-1 DB_FILE_NAME_CONVERTを使用したファイル名の指定
BACKUP AS COPY DB_FILE_NAME_CONVERT ('/maindisk/oradata/users', '/backups/users_ts') TABLESPACE users;
RESTORE
コマンドを実行すると、デフォルトでは、イメージ・コピー・バックアップをコピーすることによって、データファイルまたは制御ファイルが元の場所にリストアされます。イメージ・コピーが選択されるのは、バックアップ・セットを使用すると、リストアするファイルを検索するためにバックアップ・セット全体が読み取られ、オーバーヘッドが増加するためです。
現行のデータファイルをリストアおよびリカバリする必要があり、ディスク上に使用可能なイメージ・コピーが存在する場合は、RMANでイメージ・コピーを元の場所にコピーする必要はありません。リストア対象のデータファイルのかわりに、イメージ・コピーを使用できます。このタスクの実行方法については、「コピーへの切替え後の完全リカバリの実行」を参照してください。
関連項目:
|
RMANでは、ディスク上にファイルのイメージ・コピーを作成するオペレーティング・システム固有のファイル・コピー・コマンドや、サード・パーティ・ユーティリティなど、RMAN以外のメカニズムで作成したイメージ・コピーを使用できます。このタイプのコピーは、ユーザー管理バックアップまたはオペレーティング・システムのバックアップと呼ばれます。
CATALOG
コマンドを使用して既存のイメージ・コピーを検査し、そのメタデータをRMANリポジトリに入力できます。ただし、CATALOG
コマンドでは、次の処理は行われません。
破損がないことを保証するためのデータファイルのコピー内のすべてのブロックの読取り
イメージ・コピーがバックアップ・モードで正常に作成されたことの保証
これらのファイルをカタログに追加した後、それらをRESTORE
またはSWITCH
コマンドで使用できます。これは、RMANによって生成されるイメージ・コピーの場合と同様です。
ミラー化されたディスク・ボリューム上にデータファイルを格納しているサイトでは、ミラー化の解除によってイメージ・コピーの作成が可能になります。ミラー化を解除した後で、新しいユーザー管理コピーが存在することをRMANに通知して、そのコピーをバックアップの対象にします。CHANGE
...
UNCATALOG
コマンドを使用することによってコピーを今後利用できなくした場合は、RMANに通知する必要があります。
関連項目:
|
RMANでは、次の方法を使用して、バックアップの同じコピーを複数作成できます。
BACKUP
... COPIES
コマンドでバックアップを多重化しますが、この場合、RMANは各バックアップ・セットの複数のコピーを作成します。
ファイルをバックアップ・セットまたはイメージ・コピーとしてバックアップしてから、RMANのBACKUP
BACKUPSET
またはBACKUP
COPY OF
コマンドで、そのバックアップ・セットまたはイメージ・コピーをバックアップします。
データファイル、アーカイブREDOログ・ファイル、サーバー・パラメータ・ファイルおよび制御ファイルをバックアップ・ピースにバックアップする場合、RMANは、多重バックアップ・セットを作成して、1つのBACKUP
コマンドで、異なるバックアップ先にバックアップ・セットの各バックアップ・ピースの同じコピーを最大4つ作成できます。イメージ・コピーを作成するバックアップ操作では、多重化はサポートされていません。
BACKUP
コマンドの使用時に、CONFIGURE
、SET
または BACKUP
コマンドでCOPIES
パラメータを使用して、バックアップ・セットの多重化を指定できます。RMANでは、ディスクまたはテープにバックアップを多重化できますが、テープとディスクにバックアップを同時に多重化することはできません。テープへのバックアップ時に、コピーの数が、使用可能なテープ・デバイスの数を超えないようにしてください。
BACKUP
コマンドのFORMAT
パラメータでは、多重バックアップの出力先を指定します。次の例では、データファイル7
のバックアップのコピーを3つ作成します。
BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 FORMAT '/disk1/%U','?/oradata/%U','?/%U';
この場合、RMANは、各バックアップ・ピースの最初のコピーを/disk1
に、2番目のコピーを?/oradata
に、3番目のコピーをOracleホームに格納します。RMANは、それぞれ異なる一意のバックアップ・セット・キーを持つ3つのバックアップ・セットを作成するわけではありません。RMANは、一意のキーを持つ1つのバックアップ・セットを作成して、そのバックアップ・セット内の各バックアップ・ピースの同じコピーを3つ生成します。
関連項目:
|
BACKUP
コマンドを使用すると、既存のバックアップ・セットおよびイメージ・コピーをバックアップできます。
RMANのBACKUP
BACKUPSET
コマンドを使用すると、ディスク上に作成したバックアップ・セットをバックアップできます。このコマンドは、複数のメディア間でバックアップを実行する場合に有効です。
バックアップ・セットのいずれかのコピーが破損または欠落していることが検出された場合、RMANは、同じバックアップ・セットの他のコピーを検索します。この動作は、複数のアーカイブ先に存在するアーカイブREDOログをRMANがバックアップする際の動作に似ています。
例8-2は、本番バックアップ・スケジュールの一部として、週に1回BACKUP
コマンドを実行する方法を示しています。この方法では、すべてのバックアップがディスクとテープの両方に作成されます。
例8-2 テープへのバックアップ・セットのバックアップ
BACKUP DEVICE TYPE DISK AS BACKUPSET DATABASE PLUS ARCHIVELOG; BACKUP DEVICE TYPE sbt BACKUPSET ALL; # copies backup sets on disk to tape
注意: 自動チャネルを使用したsbt へのバックアップでは、最初にCONFIGURE DEVICE TYPE sbt コマンドを実行する必要があります。 |
BACKUP
BACKUPSET
を使用して、バックアップ領域の割当てを管理することもできます。例8-3では、1週間以上前に作成されたバックアップ・セットをディスクからテープにバックアップして、それらをディスクから削除しています。
ここで使用しているDELETE
INPUT
は、DELETE
ALL
INPUT
と同等であり、RMANは、バックアップ・セットのすべての既存のコピーを削除します。バックアップを4つの場所に多重化している場合、RMANは、バックアップ・セットのピースのコピーを4つともすべて削除します。
制御ファイルおよびサーバー・パラメータ・ファイルの最新のバックアップを作成しておくと、多くのリカバリ状況で非常に役立ちます。これらのファイルのバックアップを確実に作成するために、データベースには、制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップ機能が備わっています。自動バックアップは、BACKUP
コマンドで明示的に要求された現行の制御ファイルのバックアップとは関係なく行われます。
制御ファイルの自動バックアップによって、RMANは、現行の制御ファイル、リカバリ・カタログおよびサーバー・パラメータ・ファイルにアクセスできない場合でも、データベースをリカバリできます。自動バックアップの格納に使用されるパスは標準的な書式に準拠しているため、RMANは、その自動バックアップからサーバー・パラメータ・ファイルを検索してリストアできます。リストアされたサーバー・パラメータ・ファイルを使用してインスタンスを起動すると、RMANによって自動バックアップから制御ファイルがリストアされます。制御ファイルをマウントした後、マウントされた制御ファイル内のRMANリポジトリを使用して、データファイルをリストアします。
CONFIGURE CONTROLFILE AUTOBACKUP
がON
に設定されている場合、RMANは、正常なBACKUP
コマンドの最後に、制御ファイルおよび現行のサーバー・パラメータ・ファイル(データベースの起動に使用された場合)を自動的にバックアップします。データベースがARCHIVELOG
レベルで実行されている場合、データベースの構造上の変更によって制御ファイルの内容が影響を受けると、RMANは、制御ファイルの自動バックアップを作成します。
注意: Oracle Database 11gリリース2以降では、スクリプトに含まれている複数の構造変更(表領域の追加、表領域またはデータファイルの状態の変更、新しいオンラインREDOログの追加、ファイルの名前変更など)が適用されている場合、RMANは、制御ファイルの自動バックアップを1つのみ実行します。 |
自動バックアップは、バックアップ・ジョブ中に割り当てられた最初のチャネルによって作成され、独自のバックアップ・セットに格納されます。データベースの構造変更後の自動バックアップの場合は、構造変更に関連付けられたサーバー・プロセスによってバックアップが作成されます。
サーバー・パラメータ・ファイルがデータベースによって使用されている場合は、RMANによって、制御ファイルの自動バックアップと同じバックアップ・セットにバックアップされます。自動バックアップが完了すると、バックアップ・ピースの完全パスおよびデバイス・タイプを含むメッセージが、データベースによって自動診断リポジトリ(ADR)にあるアラート・ログに書き込まれます。
注意: 制御ファイルの自動バックアップは多重化されません。 |
制御ファイルの自動バックアップのファイル名には、すべてのデバイス・タイプのデフォルトの書式%F
が使用されるため、RMANは、リポジトリを使用しなくても、ファイルの場所を判断してそのファイルをリストアできます。CONFIGURE
CONTROLFILE
AUTOBACKUP
FORMAT
コマンドを使用すると、別の書式を指定できます。ただし、すべての自動バックアップの書式に%F
変数を含める必要があります。デフォルトの書式を使用しない場合は、障害リカバリ中に、自動バックアップの生成に使用された書式を指定する必要があります。そうしない場合、RMANは自動バックアップをリストアできません。
関連項目:
|
デフォルトでは、RMANは全体バックアップを作成します。データファイルの全体バックアップには、バックアップするファイルのすべての割当て済ブロックが含まれます。 データファイルの全体バックアップは、イメージ・コピーである場合があります。この場合は、すべてのデータ・ブロックがバックアップされます。また、バックアップ・セットに格納される場合もあります。この場合は、使用されていないデータファイル・ブロックはスキップされます。
全体バックアップは、RMANバックアップのデフォルト・タイプです。全体バックアップは、後続の増分バックアップには影響せず、増分バックアップ計画の一部とはみなされません。イメージ・コピーにはデータファイル内のすべてのデータ・ブロックが含まれるため、イメージ・コピーは常に全体バックアップとなります。 バックアップ・セットにはデータファイル内のすべてのデータ・ブロックが含まれる可能性があるため、バックアップ・セットはデフォルトでは全体バックアップとなります。ただし、未使用ブロックの圧縮は、未使用のブロックは除外され、現在使用されていないブロックが除外される場合もあることを意味します(「バックアップ・セットのブロック圧縮」を参照)。
全体バックアップに対し、増分バックアップでは、以前のバックアップ以降に変更されたデータ・ブロックのみがコピーされます。RMANを使用して、データファイル、表領域またはデータベース全体の増分バックアップを作成できます。全体バックアップを増分バックアップ計画に含めて、後続の増分バックアップの親として指定することはできません。
RMANでは、マルチレベル増分バックアップを作成できます。各増分レベルは、0または1の値で示されます。レベル0の増分バックアップは、後続の増分バックアップの基本となるバックアップであり、データが含まれるすべてのブロックをコピーします。レベル0のデータベース・バックアップは、バックアップ・セットまたはイメージ・コピーとして作成できます。
レベル0の増分バックアップと全体バックアップの違いは、全体バックアップは増分計画には含まれないという点のみです。したがって、レベル0の増分バックアップは、レベルが0より大きい増分バックアップの親である全体バックアップです。
レベル1の増分バックアップは、次のいずれかのタイプです。
差分増分バックアップ: レベル1またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックをバックアップします。
累積増分バックアップ: レベル0の最新の増分バックアップ以降に変更されたすべてのブロックをバックアップします。
デフォルトでは、増分バックアップは、差分バックアップに設定されています。
注意: リカバリ時間がディスク領域より重要である場合は、差分バックアップより累積バックアップをお薦めします。これは、リカバリ中に適用する必要がある増分バックアップが少ないためです。 |
バックアップ・ファイルのサイズは、変更されたブロック数、増分バックアップ・レベルおよび増分バックアップのタイプ(差分または累積)によって異なります。
レベル1の差分バックアップでは、RMANは、レベル1(累積または差分)またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックをバックアップします。たとえば、レベル1の差分バックアップでは、RMANはレベル1の最新のバックアップを確認して、そのバックアップ以降に変更されたすべてのブロックをバックアップします。レベル1のバックアップが使用できない場合、RMANは、レベル0の基本バックアップ以降に変更されたすべてのブロックをコピーします。
現行または親のインカネーションでレベル0のバックアップが使用できない場合の動作は、互換性モード設定によって異なります。互換性が10.0.0以上の場合、RMANは、ファイルの作成以降に変更されたすべてのブロックをコピーします。それ以外の場合、RMANは、レベル0のバックアップを生成します。
図8-2に示す例では、毎週、次のアクティビティが実行されます。
日曜日
レベル0の増分バックアップによって、このデータベースでこれまでに使用されたすべてのブロックがバックアップされます。
月曜日から土曜日
月曜日から土曜日には、レベル1の差分増分バックアップによって、レベル1またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックが毎日バックアップされます。つまり、月曜日のバックアップでは、日曜日のレベル0のバックアップ以降に変更されたブロックがコピーされ、火曜日のバックアップでは、月曜日のレベル1のバックアップ以降に変更されたブロックがコピーされる、というように実行されます。
レベル1の累積バックアップでは、RMANは、現行または親のインカネーションでレベル0の最新の増分バックアップ以降に使用されたすべてのブロックをバックアップします。累積増分バックアップでは、特定のレベルの1つの増分バックアップのみが必要となるため、リストア操作に必要な作業が軽減されます。累積バックアップでは、同じレベルの以前のバックアップによって実行された作業が繰り返されるため、差分バックアップよりも多くの領域および時間が必要です。
図8-3に示す例では、毎週、次のアクティビティが実行されます。
日曜日
レベル0の増分バックアップによって、このデータベースでこれまでに使用されたすべてのブロックがバックアップされます。
月曜日から土曜日
レベル1の累積増分バックアップによって、レベル0の最新のバックアップ以降に変更されたすべてのブロックがコピーされます。レベル0の最新のバックアップは日曜日に作成されているため、月曜日から土曜日まで毎日行われるレベル1のバックアップでは、日曜日のバックアップ以降に変更されたすべてのブロックがバックアップされます。
増分バックアップのブロック・チェンジ・トラッキング機能を使用すると、各データファイル内の変更されたブロックをブロック・チェンジ・トラッキング・ファイルに記録することによって増分バックアップのパフォーマンスが向上します。このファイルは、データベース領域に格納される小さなバイナリ・ファイルです。REDOの生成時に、RMANは、変更されたブロックを追跡します。
ブロック・チェンジ・トラッキングを有効にした場合、RMANは、チェンジ・トラッキング・ファイルを使用して、増分バックアップ用の変更されたブロックを識別します。レベル0の増分バックアックにはすべてのブロックが含まれるため、増分レベルが0(ゼロ)より大きい場合にのみ、RMANはブロック・チェンジ・トラッキングを使用します。
RMANで増分バックアップの作成に使用されるアルゴリズムを理解するには、次の概念を理解しておく必要があります。
チェックポイントSCN
すべてのデータファイルにデータファイル・チェックポイントSCNがあり、このSCNは、V$DATAFILE.CHECKPOINT_CHANGE#
で参照できます。このSCNより小さいSCNを持つすべての変更がそのファイル内に存在することが保証されます。レベル0の増分バックアップがリストアされると、リストアされたデータファイルには、レベル0が作成されたときのチェックポイントSCNが含まれます。 レベル1の増分バックアップがファイルに適用されると、そのファイルのチェックポイントSCNは、レベル1の増分バックアップが作成されたときにファイルに含まれていたチェックポイントSCNに進みます。
増分開始SCN
このSCNは、レベル1の増分バックアップにのみ適用されます。バックアップには、SCNが増分開始SCN以上のすべてのブロックが含まれます。SCNが増分開始SCNより小さいブロックは、バックアップには含まれません。増分開始SCNは、多くの場合、レベル1のバックアップの親のチェックポイントSCNです。
ブロックSCN
データファイルの各データ・ブロックには、ブロックに対する最新の変更が行われた時点のSCNが記録されます。
RMANは、ファイルのレベル1の増分バックアップの作成時に、ファイルを読み取り、すべてのブロックのSCNを確認し、SCNがこのバックアップの増分開始SCN以上であるブロックをバックアップします。差分バックアップの場合、増分開始SCNは最新のレベル1のバックアップのチェックポイントSCNです。累積バックアップの場合、増分開始SCNは最新のレベル0のバックアップのチェックポイントSCNです。
ブロック・チェンジ・トラッキングが有効になっている場合、RMANは、ビットマップを使用して、増分開始SCNからチェックポイントSCNまでの範囲内で変更されていないブロックの読取りを回避します。RMANは、読み取るすべてのブロックを確認し、ブロック内のSCNを使用してバックアップに含めるブロックを決定します。
増分バックアップ・アルゴリズムによって、RMANは、リカバリ中、変更されたデータが含まれるすべてのブロックを適用できます。これには、NOLOGGING
オプションで作成されたオブジェクトに対する変更も含まれます。したがって、NOLOGGING
の変更を行う前に作成されたバックアップをリストアする場合、これらの変更をリカバリする方法は、増分バックアップのみとなります。
関連項目: NOLOGGINGモードの詳細は、『Oracle Database概要』 を参照してください。 |
メディア・リカバリ中、RMANは、リストアされるファイルを確認し、増分バックアップを使用してそれらをリカバリできるかどうかを判断します。増分バックアップとアーカイブREDOログのいずれかを選択できる場合、RMANは常に増分バックアップを選択します。ブロック・レベルで変更を適用する方が、REDOを適用するより高速なためです。
RMANでは、リカバリ中、増分バックアップをデータファイルに適用するためにデータファイルの基本増分バックアップをリストアする必要はありません。たとえば、データファイルのイメージ・コピーをリストアし、増分バックアップを使用してそれらをリカバリできます。
CONFIGURE RETENTION POLICY
コマンドを使用して、永続的かつ自動のバックアップの保存方針を作成できます。バックアップの保存方針が有効な場合、RMANは、CONFIGUREコマンドで指定された条件に従って、データファイルまたは制御ファイルのバックアップを不要なバックアップ(つまり、今後リカバリに不要)とみなします。
REPORT OBSOLETE
コマンドを使用して不要なファイルを表示したり、DELETE OBSOLETE
コマンドを使用して不要なファイルを削除できます。
長期にわたってバックアップを作成していると、古いバックアップは保存方針を満たすために必要ではなくなります。RMANは、不要になったファイルを識別できますが、自動的には削除しません。DELETE
OBSOLETE
コマンドを使用して、保存方針を満たすために必要ではなくなったファイルを削除する必要があります。
高速リカバリ領域が構成されている場合、新しいファイル用にリカバリ領域がさらに必要になると、不要になったファイルまたはテープにバックアップされたファイルがデータベースによって自動的に削除されます。ディスク割当て制限の規則は、保存方針の規則とは異なりますが、ディスク割当て制限を満たすために、保存方針に違反してファイルが削除されることはありません。「高速リカバリ領域が一杯になった場合の対応」を参照してください。
バックアップが不要になるのは、REPORT
OBSOLETE
またはDELETE
OBSOLETE
で、ユーザー定義の保存方針に基づいて、バックアップがリカバリに必要ないと判断された場合です。バックアップが期限切れのバックアップとみなされるのは、RMANがクロスチェックを実行してファイルを検出できない場合のみです。したがって、不要とはファイルが必要ないことを意味し、期限切れとはファイルが検出されないことを意味します。
バックアップ保存方針は、全体またはレベル0のデータファイルおよび制御ファイルのバックアップにのみ適用されます。データファイルのコピーおよびプロキシ・コピーの場合、RMANがコピーまたはプロキシ・コピーを不要と判断すると、それらのコピーを削除できます。データファイルのバックアップ・セットの場合、バックアップ・セット内のすべてのデータファイルのバックアップが不要になると、RMANはそのバックアップ・セットを削除できます。
保存方針は、不要なアーカイブREDOログおよびレベル1の増分バックアップの削除またはレンダリングには関係しません。これらのファイルは、それらを必要とする全体バックアップが存在しなくなった場合に不要となります。保存方針は、データファイルおよび制御ファイルの全体バックアップまたはレベル0のバックアップのみでなく、アーカイブREDOログおよびレベル1の増分バックアップにも影響します。まず、RMANは不要なデータファイルおよび制御ファイルのバックアップを判断します。次に、RMANは、保持する必要がある最も古いデータファイルまたは制御ファイルのバックアップをリカバリする際に必要ないすべてのアーカイブ・ログおよびレベル1の増分バックアップを、不要とみなします。
注意: RMANを使用せずに(メディア・マネージャのテープの保存方針などによって)バックアップを削除すると、RMANは自動保存方針を実装できません。テープ上のすべてのRMANバックアップがメディア・マネージャのカタログから削除されるまで、メディア・マネージャがそのテープを期限切れにしないように設定することをお薦めします。 |
保存方針を実装する場合、冗長性とリカバリ期間という相互に排他的な2つのオプションがあります。
リカバリ期間とは、現在の時点からリカバリ可能ポイントまでの期間です。リカバリ可能ポイントは、想定されるPoint-in-Timeリカバリの最も早い時点(メディア障害後にリカバリ可能な最も早い時点)です。たとえば、1週間のリカバリ期間を実装した場合、RMANは、データベースを最大7日前までリカバリできるように、全体バックアップおよび必要な増分バックアップとアーカイブ・ログを保持します。この保存方針は、次のように構成します。
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
このコマンドを実行すると、各データファイルに対して、リカバリ可能ポイントより前のバックアップが1つ保持されます。たとえば、リカバリ期間が7
の場合、次の条件を満たす各データファイルのバックアップが常に1つ存在する必要があります。
SYSDATE - BACKUP CHECKPOINT TIME >= 7
この条件を満たす最新のバックアップよりも古いすべてのバックアップは不要となります。
図8-4に示す保存方針を設定するとします。保存方針の内容は、次のとおりです。
リカバリ期間は7日です。
データベースのバックアップは2週間ごとにスケジュールされ、次の日付に実行されます。
1月1日
1月15日
1月29日
2月12日
データベースはARCHIVELOG
モードで実行され、アーカイブ・ログは、保存方針で必要とされる間のみ、ディスク上に保存されます。
図8-4に示すように、現在の時点は1月23日、リカバリ可能ポイントは1月16日です。このため、リカバリには、1月14日のバックアップおよびログ順序500から850のアーカイブ・ログが必要です。500より前のログおよび1月1日のバックアップは、期間内の時点へのリカバリには必要ありません。
図8-5に、1週間後の同じ例を示します。
この例では、現在の時点は1月30日、リカバリ可能ポイントは1月23日です。最新(1月28日)のバックアップがリカバリ期間に存在していますが、この場合でも1月14日のバックアップは不要ではありません。これは、1月28日のバックアップをリストアしても、期間の最初の時点(1月23日)にはリカバリできないためです。期間内のいずれの時点にもリカバリできるようにするために、1月14日のバックアップおよび順序500から1150のすべてのアーカイブ・ログを保存する必要があります。
リカバリ期間を使用すると、保持する必要があるバックアップの数が一定ではなく、バックアップ・スケジュールによって異なるため、ディスク領域の計画が複雑になる場合があります。これに対して、冗長性に基づく保存方針では、データファイルごとに保持する必要があるバックアップ数を指定します。たとえば、次のように入力して冗長性を2に構成できます。
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
デフォルトの保存方針は、REDUNDANCY
1
に構成されています。
REPORT
OBSOLETE
コマンドを実行すると、保存方針に従って、現在不要なバックアップを確認できます。関連コマンドDELETE
OBSOLETE
を実行すると、保存方針に従って、不要なすべてのファイルを削除できます。DELETE
OBSOLETE
を定期的に実行して、不要なバックアップの格納によって消費される領域を最小限に抑えることができます。たとえば、週に1回実行するスクリプトでDELETE
OBSOLETE
を実行できます。
また、REPORT
またはDELETE
コマンドでREDUNDANCY
またはRECOVERY
WINDOW
オプションを指定して、構成されている保存方針を無効にすることもできます。構成したリカバリ期間より短いリカバリ期間でDELETE OBSOLETE
を使用すると、リカバリ可能な期間が事実上短縮されます。たとえば、構成した期間が14日にもかかわらず、DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS
を実行した場合は、7日から14日前の間の時間にはリカバリできなくなります。
関連項目:
|
RMANのステータスOBSOLETE
は、常に保存方針に応じて決定されます。たとえば、RMANリポジトリ内のデータベースのバックアップがOBSOLETE
とみなされる理由は、そのバックアップがリカバリ期間内の時点へのリカバリに必要ないか、または冗長であるためです。
高速リカバリ領域を構成している場合、内部アルゴリズムを使用して、高速リカバリ領域のファイルから、構成されている保存方針を満たす必要がなくなったファイルが選択されます。ステータスがOBSOLETE
のバックアップは、ディスク割当て制限の規則によって削除対象となっています。ディスク割当て制限の規則に従って高速リカバリ領域から削除するファイルが決定される際に、保存方針が違反されることはありません。
高速リカバリ領域のOBSOLETE
ステータスの規則と、ディスク割当て制限で削除対象とする規則には、1つの重要な違いがあります。1000から2000のアーカイブ・ログがディスク上に存在し、現行のリカバリ期間に必要であるとします。これらのログをテープにバックアップする場合、保存方針では、ディスク上のログは必要であるとみなされます。一方、高速リカバリ領域のディスク割当て制限のアルゴリズムでは、ディスク上のログはテープにバックアップされているため、削除対象とみなされます。したがって、ディスク上のログはリポジトリではOBSOLETE
ステータスを持ちませんが、高速リカバリ領域では削除対象になります。