従来のデータベース・バックアップ方法
すべての本番Oracleデータベースではデータ保護が必要です。Oracleでは優先バックアップ・ソリューションとしてRMANを提供しています。ほとんどのエンタープライズは、この項で説明する1つ以上のデータベース・バックアップ計画を採用しています。
週次完全バックアップと日次増分バックアップ
図1-1に示す一般的なアプローチの1つでは、RMANを使用して、完全バックアップを毎週、増分バックアップを毎日作成します。増分バックアップのパフォーマンスを向上させるには、ブロック変更トラッキングを有効化することをお薦めします。このようなバックアップは、データベースに対するアクティビティが最も少ないときに行われます。
この方法のメリットは、本番サーバーに影響するバックアップ・ウィンドウが、増分バックアップを作成する日には比較的短いことです。デメリットは、複数のグローバル・タイムゾーンに合せて稼働している場合のようにデータベースが継続してアクティブなときには、バックアップ・ウィンドウを設定しにくいことです。
1つのソリューションは、Oracle Data Guardを設定して、スタンバイ・データベースをバックアップすることです。こうすると、バックアップの負荷を本番サーバーから除くことができます。ただし、多くの場合、すべてのデータベースをOracle Data Guardで保護することは実用的ではありません。
増分バックアップとRECOVER COPY
図1-2に示すRMANのアプローチは、増分バックアップを毎日作成し、RECOVER COPYコマンドを使用して、増分変更をデータベース全体のコピーにマージします。こうすると、ディスク上のデータベース・コピーが毎日「ロール・フォワード」されます。
この方法には次のメリットがあります。
-
完全バックアップは最初に1回しか必要ないため、毎週のバックアップ・ウィンドウの合計時間が短縮されます。
-
RMAN
SWITCHコマンドで制御ファイルにデータベース・コピーを指定できます。これにより、コピーが実際のデータベース・ファイルになり、RESTOREステップが省かれます。
デメリットは次のとおりです。
-
データベース全体のコピーをディスクに保持するために十分なディスク領域と、そのリカバリに必要なアーカイブREDOログ・ファイルが必要です。
-
データベースの物理コピーが1つしか存在しません。どのポイント・イン・タイムのコピーを保存するかを選択しますが、リカバリできるのはそれ移行のポイント・イン・タイムです。たとえば、過去1週間の任意のポイント・イン・タイムにリストアするには、物理コピーが
SYSDATE-7よりも古いことが必要です。デメリットは、次のとおりです:-
データベースのコピーを保存した時点よりも前の時点にはリカバリできません。
-
リカバリのポイント・イン・タイムが現在時刻に近くなるほど、リストアしてコピーに適用する必要がある増分バックアップ数が増加します。この方法では、全体のリカバリ時間の目標が延長されます。
-
-
データベース・コピーを圧縮または暗号化できません。
サードパーティの重複除外アプライアンスへの完全バックアップ
RMANによる増分バックアップとテープ・ドライブのかわりに、サードパーティの重複除外アプライアンスを使用してバックアップ・ストリームを処理する場合もあります。図1-3では、集中管理されるサードパーティ・アプライアンスに3つのデータベースが書き込んでいます。
この方法には次のメリットがあります。
-
一元管理されるバックアップの場所で、環境内のすべてのデータベースを処理します。
-
サードパーティ・ソフトウェアが、バイト・レベルおよびサブバイト・レベルでパターンを検索し、バックアップ間の冗長なデータを消去します。たとえば、完全データベース・バックアップが1週間前のバックアップとほぼ同一である場合、ソフトウェアは、受け取るバックアップ・ストリームから冗長ビットを除去しようとします。
-
ネットワーク・ロードを抑えるために、ソース側で重複除外を利用することもできます。この場合、バックアップ・ストリームはサードパーティ・アプライアンスではなくデータベース・ホスト上で重複除外されます。通常、この処理ではRMAN SBTプラグインを使用します。
デメリットは次のとおりです。
-
これらのサードパーティ・アプライアンスではOracleデータベース・ブロックは認識されず、検証されません。アプライアンスの観点からは、データベース・バックアップはファイル・システムのバックアップと同じバイト・ストリームとして認識されます。
-
重複除外が有効になるのは、冗長性の高い完全データベース・バックアップのみです。多くの場合、増分バックアップを使用する計画では高い重複除外率が達成されることはありません。
-
サードパーティ・アプライアンスによって、使用するOracle Databaseの機能が指定されます(逆ではありません)。多くの場合、アプライアンスの要件に従うことは、既存のバックアップ・スクリプトの再作成を意味します。
サードパーティの記憶域スナップショット
サードパーティの記憶域スナップショットは、スナップショットの作成時に存在していた記憶域ブロック(Oracleブロックではない)に対するポインタのセットです。この仮想コピーは、元のデータと同じストレージ・アレイに存在します。図1-4は、サードパーティ・スナップショットの1つであるcopy-on-writeスナップショットです。スナップショットが作成された後で、記憶域ブロックに対する最初の変更が発生すると、アレイは変更前イメージ・ブロック(C)をディスク上の別の場所にコピーし、新しいブロック(C')を元の場所に書き込みます。
この方法には次のメリットがあります。
-
データベースの初期コピーが必要ありません。スナップショットはブロックの物理コピーとして保存されるわけではないためです。したがって、RMAN計画に比べて使用される記憶域が少なくなります。
-
スナップショットの処理は非常に高速です。データベースをバックアップ・モードにしてから(記憶域がスナップショット記憶域最適化の要件を満たさない場合を除く)、スナップショットを作成します。スナップショットが物理ブロックを格納する必要があるのはブロックが変更される場合のみです。つまり、変更されていないファイルのバックアップではメタデータしか処理されません。
-
スナップショットは記憶域を効率よく使用します。1ブロックしか変更されていないファイルのバックアップでは、格納する必要があるのは該当ブロックのもう1つのバージョンのみです。スナップショットの方法に応じて、ブロックの古いバージョンか新しいバージョンが格納されます。
デメリットは次のとおりです。
-
スナップショットは、Oracleデータベース・ブロック構造を認識していないため、Oracleブロックを検証できません。
-
スナップショットはソース・データベースと同じストレージ・アレイに存在するため、記憶域の障害やデータ破損に対して脆弱です。アレイにアクセスできない場合、または記憶域にデータ・ブロックの破損が含まれる場合は、スナップショットをリカバリに使用できません。
-
その場でスナップショットをリストアすると、そのスナップショットの後で作成されたすべてのスナップショットが無効になります。スナップショットは別の場所に完全にリストアする必要があります。
関連項目:
データベースのサードパーティ・スナップショットを作成するための記憶域スナップショット最適化についてさらに学習するには、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。