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

遠隔地にバックアップ／レプリケーションする

■2.Oracle Databaseの災害対策の方法

　Oracle Databaseが備えている災害対策の機能としては、まずは遠隔地へのバックアップとレプリケーションが挙げられます。以下では、遠隔地バックアップ1種類と、遠隔地レプリケーション3種類（図2）を紹介します。

■2.1.遠隔地バックアップ（RMANを使用）

　1つ目の遠隔地バックアップとは、本番データベースで取得したバックアップを、ネットワーク経由やテープ搬送などによって、遠隔地で保存する方法です。

　Oracle Databaseには、標準でバックアップ／リカバリ・ソフトのRecovery Manager（以下、RMAN）が付属しています。RMANでは、データの暗号化や圧縮も可能です。Oracle Enterprise ManagerのGUI経由でRMANを使うことも可能です。

　遠隔地バックアップの注意点としては、データ保護に対する高度な要件を満たせないケースが多い点が挙げられます。

※RMANの詳細については、オンライン・セミナーや技術資料（http://www.oracle.co.jp/iSeminars/080904_1730/20080904_OrD_RMAN.pdf）をご覧ください。

■2.2.遠隔地レプリケーション（アドバンスト・レプリケーションを使用）

　遠隔地レプリケーションの1つ目は、アドバンスト・レプリケーション機能を使う方法です。特定範囲のデータ（表やスキーマ）を別データベースと同期させておき、障害発生時に別データベースへ処理を切り替えます。

　アドバンスト・レプリケーションの注意点は、障害の発生から本番データベースの復旧までに、工数（手間や時間）がかかる点です。

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

■2.3.遠隔地レプリケーション（Oracle Streamsを使用）

　遠隔地レプリケーションの2つ目は、Oracle Streamsを使う方法です。ログ情報を利用して別データベースと同期させておき、障害発生時に別データベースへ処理を切り替えます。

　柔軟な構成が可能になる一方で、設計が複雑になってしまう点が注意点として挙げられます。更新処理が増えても性能劣化が少ないOracle Streamsは、頻繁（ひんぱん）に更新がかかる特定のオブジェクトを保護したい場合に適します。

※Oracle Streamsの詳細については、オンライン・セミナーや技術資料（http://www.oracle.co.jp/iSeminars/071011_1600/doc/Streams_basic.pdf）をご覧ください。

■2.4.遠隔地レプリケーション（Oracle Data Guardを使用）

　遠隔地レプリケーションの3つ目は、Oracle Data Guardを使う方法です。本番データベースと待機データベースを同期させておき、障害発生時に待機データベースへ処理を切り替えます。データベース全体を保護することができます。

　一般的なストレージ・ミラーリングに比べてOracle Data Guardが優れている点は、以下の通りです。

・ストレージの機種を問わないため、ストレージ・コストを削減できる
・転送量を低く抑えられるので、ネットワーク帯域のコストを削減できる（11gR2からはデータ圧縮と組み合わせることでさらに低減可能）
・障害時に短時間で処理を切り替えられる
・災害対策環境を多目的に利用できる（次章で解説します）

　一方、ストレージ・ミラーリングがOracle Data Guardよりも優れている点としては、本番データベースにかかる負荷が低い点が挙げられます。ただし、この点については、バージョンアップによる性能向上はもちろん、構成や設定によってOracle Data Guardでも負荷を少なくすることが可能です。パートナー各社と協力してベストプラクティス（http://www.hitachi.co.jp/Prod/comp/soft1/oracle/pdf/OBtecinfo-08-007.pdf）を公開しています。

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

Oracle Data Guardで待機データベースを運用する

■3.災害対策環境を最大限に生かす

　ここからは、冒頭で紹介した「費用対効果を考えると複数個所での多重化は難しい（複数個所での多重化は費用がかかりすぎる）」という問題について、その対応策を紹介します。

　今回紹介するのは、最も広く活用されているOracle Data Guardを用いて、遊休リソースとなってしまいがちな災害対策環境を有効に活用しているケースです。

■3.1.参照及びバックアップ用途に活用（Oracle Active Data Guardを使用）

　一般に、Oracle Data Guardを用いて待機データベースを構築した場合、待機データベースの負荷は非常に低くなります。そこで、この待機データベースを参照用データベースとして活用することで、待機データベースのリソースが無駄にならずに済みます。

　Oracle DatabaseにOracle Active Data Guardと呼ぶオプションを適用することで、Oracle Data Guardによる待機データベースをオープン状態（データの参照が可能な状態）にすることができます。

　本番データベースからの同期状態を保ったまま待機データベースをオープン状態にできるので、常に最新のデータを参照したいというニーズにも対応できます。こうしたニーズに対応するため、Oracleの分析ツールである「Oracle Business Intelligence Enterprise Edition」とOracle Active Data Guardを組み合わせたベストプラクティス（http://www.oracle.com/technology/deploy/availability/pdf/maa_wp_11g_biee_activedataguard.pdf）も用意しています。

　待機データベースは本番データベースとデータ・ブロック・レベルで同一であるため（フィジカル・スタンバイ方式の場合）、待機データベース側でデータ・バックアップを実行することも可能です。

　また、「Oracle Database 11g Release2」では、本番データベースでブロック破損を検出した場合、自動的に待機データベースのデータを用いて自動修復する機能も搭載されています（後述のOracle Active Data Guardを利用）。

　待機データベースを参照用に活用しているユーザーの1社が、デジタル地図を提供する米Intermap Technologiesです。同社は、顧客からの問い合わせやレポートの生成を待機データベースで行うことで、メインのデータベースにかかる負荷を低減させています。読み取り専用のため、セキュリティも高くなっています。

■3.2.テスト用途に活用（スナップショット・スタンバイを使用）

　Oracle Data Guardによる待機データベースは、テスト用途にも使えます。具体的には、最新版の「Oracle Database 11g」のOracle Data Guardでは、待機データベースを一時的に書き込み可能な状態にすること（スナップショット・スタンバイ）が可能です。これを利用すれば、待機データベースを一時的にテスト用途で活用できます。

　テストが終わったら、前回（http://thinkit.jp/article/1050/2/）で解説したフラッシュバック・テクノロジーを利用して、データベースを元の状態に戻します。なお、テスト用途で利用している最中でも本番データベースの変更情報を受け取り続けているので、テスト中に本番データベースに障害が起こった場合でもデータを保護できます。

　スナップショット・スタンバイを活用したユーザーの1社が、ブルガリアの携帯電話キャリアであるMobilTelです。同社は、システムのテスト環境として待機データベースを活用しています。従来、テスト環境の構築には数日、場合によっては数カ月かかっていましたが、スナップショット・スタンバイ導入後は、たった1つのコマンドで数分でテスト環境を利用できるようになりました。