ストレージ機能を用いたDBバックアップは取得することに焦点が当たっている
ストレージ機能を用いたバックアップはボリューム全体をそのままコピーするという動作なのでシンプルでわかりやすい技術です。データベース管理者のみなさまの中でもボリュームのスプリット・ミラーやスナップショット機能（図1）に対して「バックアップが瞬時に終わる」あるいは「バックアップ中にサーバーのCPUリソースを使わない」というような印象を持たれている方が多いのではないかと思います。しかし、これらの印象はいずれもバックアップを取得することに注意が向いています。これまで本連載で一貫して繰り返しお伝えしてきた通り、データベースのバックアップは、リカバリに使う場面を考えることが何より大事なのです。以降では、ストレージ機能を使用した場合とRMANを使用した場合でのリストア・リカバリの違いについてお伝えしていきます。
スナップショットはバックアップではない
スナップショット（コピー・オン・ライト方式）はある時点以降に変更のあったデータだけスナップショット領域と呼ばれる領域にコピーして、それ以外のデータに対してはオリジナルのデータに対するポインタのみを保持するという仕組みです。この機能はオペレーションミスなどによってある時点のデータに戻りたいという場合には有効ですが、ディスク故障のようにオリジナルデータが消えてしまうと、同時にスナップショットも消えてしまうことになります。よって、スナップショット自体をバックアップとして使うことは出来ないため、スナップショットで取得した静的な断面からデータをコピーすることが必要となります。
スプリット・ミラーによるバックアップは取得単位でしかリストアできない
次にスプリット・ミラーを用いたバックアップは、指定したディスク・ボリューム全体の複製を持ち、その複製されたボリューム（副ボリュームと呼ぶ）をバックアップとして扱うという手法です。このバックアップを使ってシステムを復旧するには、副ボリュームから元のボリュームに対して逆方向にデータを同期させるか、副ボリューム自体をデータベースサーバーからマウントして利用する方法があります。いずれのケースもボリューム全体を操作します。
データベースの障害と言っても、データベース全体が破損する場合もあれば、単一のデータファイルや、ある特定のデータブロック(8KB)のみが破損するなど様々なケースがあります。例えば、データベースのサイズが1TBあるとします。データベース内のたった1個のブロック(8KB)が壊れた場合であったとしても、スプリット・ミラーによって取得されたバックアップを使って復旧する場合には、1TB分の副ボリュームを使ってリストア・リカバリする必要があります。非常に非効率的で時間のかかる復旧作業となります。当然のことですが、ストレージはOracle Database のブロック構造を認識できないので、特定のデータブロックだけを副ボリュームの中から抜き出してきてそれを本番データベースにリストアするということはできないのです。
また、同じ理由によって、ストレージ機能を用いたバックアップでは、連載の第一回で説明したようにOracle Databaseのデータブロックとしての破損チェックをすることができません。これも取得することに重きを置いたストレージ機能を用いたバックアップが抱える根本的な課題です。
