データベースの障害対策を考える

データベース・サーバーの冗長化で可用性を高める

■2. サーバー障害への対策を考える

　データベース・サーバー障害に対処する一般的な方法は、クラスタリング構成や遠隔地のレプリケーションなどにより、データベース・サーバーを冗長構成で運用するというものです。Oracle Databaseのサーバー冗長化手法は、システム構成に応じて、5つに分かれます。第1回のサーバー統合（http://thinkit.jp/article/1037/2/）でも解説したように、システムの重要度を考えたうえで、付加機能と合わせて選択していく形になります（図2-1）。

■2.1. Active-Active構成（RAC使用）

　サーバー冗長化手法の1つ目は、Oracle Database独自のActive-Active型のクラスタリング機能であるOracle Real Application Clusters（以下、RAC）を利用した方法です。障害発生時に、別サーバー（Active-Active構成のため、インスタンスがすでに起動している）へ処理を引き継ぎます。

　RACのメリットは、障害からの復旧が速い点、待機サーバーが不要な点、などです。従来、RACには「可用性は高いがコストも高い」というイメージを持たれがちでしたが、安価なエディションである「Oracle Database Standard Edition」でもRACが利用できるようになったほか、パートナー各社によって検証済みの構成が揃ったことから、各種の規模のシステムで活用が進んでいます。

・RACの詳細については、オンライン・セミナーや技術資料をご覧ください
（http://blogs.oracle.com/directjp/oracle_database/oracle_database_options/oracle_real_application_clusters/#material）

■2.2. Active-Standby構成（各種のクラスリング・ソフトを使用）

　2つ目は、OracleのOracle Fail Safeやサードパーティ製など、各種のクラスタリング・ソフトを使う方法です。Oracle Fail Safeは、Windows Server上のMicrosoft Cluster Service（Windows Server 2008ではMicrosoft Failover Cluster）と組み合わせて使います。障害が発生した際に、別サーバーでデータベースを再起動する、いわゆるActive-Standby構成です。

　Oracle Fail Safeの注意点は、障害発生時の別サーバーへの切り替えに、RACと比べて時間がかかる点です。さらに、Active-Standby構成では、待機用に別途サーバーが必要になります。

・Oracle Fail Safeの詳細については、オンライン・セミナーや技術資料をご覧ください
（http://www.oracle.com/technology/global/jp/tech/windows/failsafe/index.html）

■2.3. Active-Standby構成（サーバー仮想化ソフトを使用）

　Active-Standby構成には、サーバー仮想化ソフトを利用することもできます。これが3つ目の方法です。今回は、Oracleが提供しているサーバー仮想化ソフトであるOracle VMを利用したケースを想定します。Oracle VMは、HA（High Availability）機能を備えているため、障害発生時に、別のサーバーで仮想マシン（データベースも含む）を再起動できます。

　サーバー仮想化ソフトのメリットは、待機系の物理サーバー機上で別の仮想マシンを稼働させておくことが可能なため、仮想化ソフトを使わない場合と比べて、リソースを有効活用できることです。一方、注意点は、復旧対象がサーバー機の障害に限られており、データベース・インスタンスの障害に対応できないことです。この点については、RACと組み合わせることで対処できます（http://thinkit.jp/article/1037/3/）。

・Oracle VMの詳細については、オンライン・セミナーや技術資料をご覧ください
（http://www.oracle.com/lang/jp/technologies/virtualization/index.html）

■2.4. Standby Site構成（データベースをコピー）

　4つ目の方法は、Oracle Databaseの災害対策機能であるOracle Data Guardを使って、データベースの複製を作るやり方です。平常時に、本番データベースと待機データベースを同期させておき、障害が発生した際に、待機データベースへと切り替えます。一般的に災害対策のために利用する機能ですが、同一サイト内に待機サーバーを設置し、サーバー障害対策として利用するケースも数多くあります。

・Oracle Data Guardの詳細については、オンライン・セミナーや技術資料をご覧ください
（http://blogs.oracle.com/directjp/oracle_database/oracle_database_options/oracle_data_guard/#material）

■2.5. Standby Site構成（レプリケーション）

　5つ目の方法は、Oracle Databaseのレプリケーション機能を利用するものです。アドバンスト・レプリケーションを用いた場合、平常時に特定範囲のデータ（表やスキーマ）を別データベースと同期しておき、障害発生時に別データベースへ処理を切り替えます。注意点は、障害の発生から本番データベースの復旧までに工数がかかる点です。

・アドバンスト・レプリケーションの詳細については、オンライン・セミナーや技術資料をご覧ください
（http://www.oracle.co.jp/iSeminars/090521_0930/090521_Replication.pdf）

　なお、クラスタリング機能の新機軸として、「Oracle Database 11g Release2」ではRAC機能が強化され、「RAC One Node」と呼ぶ小規模データベース向けの新機能も追加されました。1ノード構成で動作するデータベースをRACのサーバー・クラスタに統合することで、小規模のアプリケーションでありながら、サーバーの冗長化機能やアプリケーションのノード間移動など、RACが提供する各種の機能を利用できます。詳細は後の連載で解説します。

フラッシュバックで人為的エラーに対処

■3. 意外な盲点？人為的エラーを考える

　計画外停止を引き起こす要因は、データベース・サーバー障害だけではありません。冒頭で説明したように、データベースにまつわる障害の範囲は広く、そのすべてについて考慮されているケースばかりではありません。実は、障害のうち、特に見落としがちだと感じるのが、人為的なエラーです。管理者やユーザーによる間違ったデータ削除や誤ったバッチの実行などを指します。

　実際に、お客さまの声でも「いくら4ノードのRAC（Real Application Clusters）で安定稼働していたとしても、データが人為的なミスで消えた場合は、業務停止となってしまう」という指摘がありました。

　こうした背景をもとに「Oracle 9i」から登場した機能群が、「フラッシュバック・テクノロジー」（以下、フラッシュバック）です。人為的なエラーからの迅速な復旧を目的に搭載された機能であり、バージョンアップを経るたびに、より広い課題への解決策に対応できるよう機能拡張されています（図2-2）。

　今回は、人為的なエラーからの復旧に関する機能に絞ってご紹介したいと思います。

■3.1. フラッシュバックで誤操作によるデータ削除を復旧

　人為的なエラーの例として、以下のような、表への誤操作を想定してみます。

・間違えて5行分のデータを削除してしまった
・誤ってバッチ処理してしまった。顧客表だけバッチ処理前のデータに戻したい

　こうした、表への誤操作から復旧するための機能として、リカバリ処理を実行することなく、特定時点の状態にすばやく戻せるようにするのが、フラッシュバック・テーブルです。仕組みとしては、図2-3のように、UNDOデータを利用して、特定テーブルの情報を巻き戻します。

■3.2. フラッシュバックで誤操作によるテーブル削除を復旧

　一方、誤って表そのものを削除することもあるでしょう。まずは、この場合の通常の手順を考えてみます。通常の手順は、以下のようなプロセスになります。

（1）過去のある時点のうち、どの時点までのデータをリカバリするかを調査する
（2）データベースをバックアップ・データからリカバリする（不完全なデータ）
（3）失われたトランザクションを再実行して、データを最新のものへと更新する

　通常の手順では、このように非常に複雑かつ膨大な作業が発生して復旧までに時間がかかってしまいます。

　一方、フラッシュバック・ドロップと呼ぶ機能を用いると、次のコマンドを発行するだけで、特定の表を復旧させることができます（管理GUIソフトのEnterprise Managerを使えば、GUIから実施することも可能です）。

---------------------------------------------------
FLASHBACK TABLE TO BEFORE DROP
---------------------------------------------------

　仕組みとしては、表を削除する際に、表とともに、表に付随する索引や制約などをRecyclebinオブジェクトとしてリネームして保管しておく、というものです。これにより、コマンド操作だけで特定の表を復旧させることができます。

　先に挙げたお客さまの声には続きがあります。「いくら4ノードのRAC（Real Application Clusters）で安定稼働していたとしても、データが人為的なミスで消えた場合は業務停止となってしまう。人為的なミスが発生しても迅速に元に戻せる機能（フラッシュバック）は大変魅力的である」。

　フラッシュバックに関する情報は、以下の資料をご活用ください。

・論理障害から復旧するためのフラッシュバック大全
（http://www.oracle.co.jp/iSeminars/090407_1330/Flashback.pdf）