そのバックアップ、本当に戻せますか？
機密情報を扱い、情報システムの中心とも言えるデータベースにとって、バックアップは欠かすことのできない重要な要素です。現在ではWebサービスやソーシャル・ネットワークなど、あらゆる場面で日常的にデータベースが使われる時代になっているため、データ損失によって多額の金銭的損害が発生するだけでなく、企業に対するマイナス・イメージが即座に伝播してしまいます。
ハードウェアの故障やオペレーション・ミスなどのリスクを抱えるデータベースにとって、バックアップはまさに保険とも言える存在ですが、バックアップさえ取得していれば安心かというと、決してそのようなことはありません。バックアップは戻す（リストアまたはリカバリする※1）ために取得するものなので、「何を」「どこまで」「どうやって」戻すのかというリカバリ要件をきちんと考えておく必要があります。これをやらないと、使えもしないバックアップを日々量産し続けることになってしまいます。
（※1) Oracle Databaseでは、バックアップしたファイルを再配置することを「リストア」、そのファイルに変更履歴を適用してデータを回復させることを「リカバリ」と呼びます。
しかし実際には、こうしたリカバリ要件の検討を十分にできないままデータベースを運用しているケースが数多く存在します。以下のグラフは、弊社にて実施したリカバリの課題に関するアンケート結果をまとめたものです。意外なことに「リカバリを試したことがない」という回答が過半数を超えています。一度も障害が発生していなかったり、リカバリを試せる環境がないなど事情は様々ですが、有事の際にリカバリできないリスクを抱えているデータベースは少なくないようです。
具体的な失敗例を見てみましょう。A社のデータベースはアーカイブログ・モードで運用されており、毎日夜間バッチの前にRecovery Manager（以下、RMAN）による全体バックアップ（物理バックアップ）を取得しています。これまで一度も障害が発生していませんでしたが、ある日オペレーション・ミスにより誤って当日分と翌日分の夜間バッチが続けて実行されてしまいました。事前に作成しておいた翌日分のジョブを、流し忘れと勘違いして実行してしまったのです。これにより、いくつかの表が本来ではありえない状態に更新されてしまいました。
事態に気づいた担当者はすぐにジョブをキャンセルし、データベースのサポートに電話します。誤って更新された表だけを元に戻す方法がないか問い合わせましたが、サポートからは表領域のリストア・リカバリを案内されました。幸い手順書があったので問題なくコマンドを実行できたものの、表領域のサイズが大きすぎてリストアに時間がかかってしまい、翌朝の営業開始に間に合いませんでした。
A社のバックアップには2つの問題点があります。1つはリストアに必要な時間を把握できていなかったことです。せっかくバックアップを取得していても、決められた時間内にリストアできないのでは全く意味がありません。特にデータベースのサイズが大きい場合は、それに比例してリストア時間が長くならないような手法を検討するべきです。
もう1つは、リストア・リカバリの単位が大きすぎることです。データベース全体が壊れてしまうような障害ならまだしも、オペレーション・ミスによっていくつかの表を更新しただけで大規模なリストアが必要になるようでは、効率が良いとは言えません。
後者の解決策としては、Data Pumpによる論理バックアップや、フラッシュバック機能の利用などがあります。もしこれらを利用できれば、今回のようなオペレーション・ミスが発生したとしても短時間で対処することができます。ただし、RMANの物理バックアップが不要になるわけではないので、結果的にバックアップを2重で持ってしまうという欠点もあります。実際の運用でも、物理バックアップと論理バックアップを併用しているケースは珍しくありませんが、バックアップの時間が延びたり、バックアップ先の容量が不足したりといった新たな問題を抱えることになります。
