OTN ケース・スタディ：Amadeus Oracle Data Guard を使用した障害時リカバリおよびローリング・アップグレード

「私たちは全体的な可用性を強化するためのさらなる方法を見つけたとき、障害時リカ

バリ保護に対する Oracle Data Guard の標準化をすでにおこなっていました。Michael Amamoo（Amadeus のデータベース管理者）は、Oracle Data Guard とともに Oracle トラ

ンスポータブル表領域を使用するプロシージャを提案して実行し、電子チケット・シス

テムを HP N-Class で動作する Oracle Database 9.2.0.3 から HP-Superdome で動作する

Oracle Database 9.2.0.5 に、わずか 8 分で即座に移行することに成功しました。このプロ

シージャを使用すれば、高速で信頼性の高い方法に加え、最小限の停止時間で Oracle9i Database から Oracle Database10g にアップグレードできます。Oracle Data Guard 10g の

ローリング・アップグレードを使用すれば、今後のデータベースのアップグレードはさ

らに簡単になります。」

Amadeus、データベース・マネージャ Vitor Pacheco

概要 会社概要

• 旅 行 業 界 に お け る 世 界 的 な

E-Commerce サービスおよびソ

リューション・プロバイダ

• 年間収益 19 億ドル（EUR）

• 集中予約システム - 64,000 の旅

行代理店および 16,000 の航空会

社の営業所に提供

• 従業員 5,000 人

• www.amadeus.com

高可用性

• Oracle Real Application Clusters（Oracle RAC）

• 障害時リカバリ

• Oracle Data Guard

• REDO Apply - 障害時リカバリ用

のフィジカル・スタンバイ

Amadeus は、世界中の 210 を超える市場で旅行観光業界のマーケティング、セー

ルス、ディストリビューションのニーズに応える、優れた Global Distribution System（GDS）およびそれに関連するテクノロジーのプロバイダです。Amadeus GDS を介して、旅行代理店や航空会社は、世界の定期航空便の座席の 95%の予

約をおこなっています。

Amadeusは、数多くあるOracle9i Databaseの障害時リカバリ（DR）保護のために、

Oracle Data Guard[1]を配置しました。Oracle Data Guardは、Oracle Database Enterprise Editionに組み込まれている機能で、データベース認識型の障害時リカ

バリ・ソリューションとして動作し、ほかのOracle高可用性（HA）機能と完全

に統合されています。

Amadeus では、多くの新規プロジェクトを Oracle Database 10g で開発していま

す。また、あるデータベースのリリースから次のリリースへアップグレードす

る際にかかる停止時間を大幅に短縮する新機能、Oracle Data Guard 10g のロー

リング・アップグレードを使用する予定です（ローリング・アップグレードを

おこなうには、Oracle Database 10.1.0.3 以降のデータベースが必要です）。

多くのOracleユーザーと同様、Amadeusでは、近いうちに既存の本番システムを

Oracle9i DatabaseからOracle Database 10g.にアップグレードする予定です。

Amadeusがおこなったテストでは、その環境でOracle9i DatabaseからOracle Database 10gにアップグレードするには、完了までに最低 25 分かかることがわ

かりました。これでは、データベースの計画停止時間は四半期ごとに 15 分を越

えてはならないと規定されているAmadeusのIT品質保証契約に違反することに

なります。違反しないためには、ソリューションを見つける必要がありました。

• SQL Apply - レポートおよびロー

リング・アップグレード用のロジ

カル・スタンバイ

• Oracle9i DatabaseおよびOracle Database 10g

AmadeusのIT部門は、世間に知られるようになったその創意工夫力を発揮し、

Oracle9i Data GuardとOracleトランスポータブル表領域を組み合わせて使用する

プロシージャを開発し、Oracle Database 10gへのアップグレードに必要な停止時

間を半分のちょうど 8 分に短縮しました。

1

AMADEUS の高可用性と障害時リカバリ戦略

Amadeus では、すべてのデータベース・サービスに Oracle Real Application Clusters（Oracle RAC）を使用し、アプリケーション層の複数ノードに完全なア

プリケーション・サービスの冗長性を実装することで、CPU 障害からシステム

を保護しています。

システム構成

• プライマリ・サイトと DR サイト

に HP Superdome

• HP-UX 11.11

• 両サイトに EMC Symetrix と HP XP さらに、Amadeus のデータセンターは、6 つの完全に独立した個室に分かれて

おり、各部屋の電源とケーブルは、ほかの部屋から完全に独立しています。す

べてのハードウェア・コンポーネントは、完全な冗長モードでそれぞれの部屋

に配置されています。その構成は、完全に独立した 2 つのネットワーク、最低

2 台の本番マシン、冗長ディスク・エンクロージャなどです。アプリケーショ

ン・コンポーネントも、この同じインフラストラクチャに冗長モードで配布さ

れています。たとえば、2 つの RAC インスタンスは、それぞれ異なる部屋にあ

る別々の LPARS に実装されています。このような設計にすることで、可用性

に影響を及ぼす可能性がある、あらゆる単一の障害に対応しています。

• 50GB から 500GB の複数のデー

タベース

• 高速トランザクション処理が可

能な OLTP システム

• Oracle Database 9.2.0.5

• Oracle Database 10g

• プライマリ・サイトとスタンバ

イ・サイト間の距離は 30km

Oracle Data Guard REDO Apply は、プライマリ・データセンターから 30km の地

点にあるリモート DR サイトの各 Oracle データベースの物理コピーのトランザ

クション一貫性を維持するために使用されています。Oracle Data Guard SQL Apply は、本番データベースのコピーを維持し、レポートを生成するために使

用されています。レポートのデータベースは、SQL Apply の機能を利用して、

本番データベースから受信した更新を適用するのと同時に読取りアクセスを提

供します。アプリケーションとほかのコンポーネント、およびOracleデータベー

スの外部にあるデータには、従来のディスク・レプリケーションが使用されて

います。

この状況で、Amadeusは、Oracle9i DatabaseからOracle Database 10gへのアップグ

レードを準備しています。アップグレード・プロシージャは、次の要件を満た

す必要があります。

AMADEUS のアップグレード要件：

• 計画的メンテナンスのデータベース停止時間の合計は、四半期ごとに 15

分未満にする必要がある。Oracle9i DatabaseからOracle Database 10gへの

アップグレードでは、この 15 分の時間枠を超えることができません。

• 最初にアップグレードするデータベースの 1 つが、Amadeus の電子チケッ

ト・サーバーをサポートする必要がある。このサーバーには、42 の表領域

があり、サイズは約 174GB です。

• データベースのアップグレードが上手くいかなかった場合、Amadeusでは、

許容される最大停止時間の 15 分を超えることなく、以前の環境に戻す必

要があります。

AMADEUS のアップグレード・プロシージャ

Amadeusでは、次の手順を使用して、Oracle Database 10gへのアップグレードを

おこないます。

手順 1：Oracle9i Databaseを実行している独立したシステムに、REDO Applyスタンバイ・データベース（フィジカル・スタンバイ）を作成します。標準プロ

シージャを使用して、プライマリ本番データベースのホット・バックアップか

らスタンバイ・データベースをインスタンス化します。

2

プライマリ・データベースは、Oracle Data Guard LGWR ASYNC 転送サービス

を使用して、REDO データをスタンバイ・データベースに送信するように設定

します。LGWR ASYNC は、非同期プロセスを使用してコミットされたかのよ

うにし、REDO データをスタンバイ・サーバーに送信します。スタンバイ・デー

タベースは、REDO データを受信し、スタンバイ REDO ログ（SRL）に書き込

みます。続いて、プライマリ・データベースのログを切り換え、Oracle Data Guardで SRL をアーカイブして、REDO データをスタンバイ・データベースに適用す

るプロセスを完了します。

Oracle Data Guard が本番データベースのスタンバイ・コピーを維持するために

使用するプロセスは、SRDF などのリモート・ミラー化ソリューションで使用

されるプロセスとは大幅に異なる点に注意してください。SRDF は、すべての

I/O を全データベース・ファイル、オンライン・ログ、アーカイブ・ログ、お

よび制御ファイルにレプリケートする必要があります。そのため、リモート・

ミラー化により、各データベースの変更がリモート・サイトに 3 回以上送信さ

れ（Oracle Data Guard では 1 回です）、ネットワーク I/O が大幅に増加します。

手順 2：プライマリ・データベースと同じメタデータ構造を使用し、データは 0件で、Oracle Database 10gの"シェル"をスタンバイ・システムに作成します（図 1）。

図 1 - スタンバイ・データベースとメタデータ構造のインスタンス化

手順 3：アップグレードの準備ができたら、Oracle Data Guardの非同期バッファ

内のすべてのREDOデータがスタンバイ・データベースに送信されたことを保

証するために、プライマリ・データベースのログを切り換えます。次に、アプ

リケーションを停止し、プライマリ・データベースを閉じます。標準のOracle Data Guardフェイルオーバー操作を実行します。これで、スタンバイ・サーバー

から受信したすべてのREDOデータのスタンバイ・データベースへの適用プロ

セスは完了です。次に、スタンバイ・データベースをプライマリ・ロールで立

ち上げ、読取り/書込みアクセスで開きます。これで、トランスポータブル表領

域からデータベースに書き込めるようになります。フェイルオーバー・プロセ

スの実行には、次のようなシンプルなコマンドが使用されます。

SQL> alter database recover managed standby database finish; SQL> alter database commit to switchover to primary; SQL> shutdown immediate; SQL> startup; 前述の手順と並行して、"空"の Oracle Database 10g でアプリケーションを再起

3

動します。

手順 4：エクスポートおよびトランスポータブル表領域を使用して、Oracle9i Databaseスタンバイ・データベースの表領域を新しいOracle Database 10gのシェ

ルに移動します。これは、2 つの手順から成るプロセスです。まず、読取り専

用アクセスに関係する表領域を設定します。関係する表領域が自己完結型であ

ることを確認します。次のコマンドを使用します。

SQL> EXECUTE SYS.DBMS_TTS.TRANSPORT_SET_CHECK ('users,tools',TRUE,TRUE); SQL> SELECT * FROM SYS.TRANSPORT_SET_VIOLATIONS; この問合せに対して行が戻ってこない、つまり、これらの表領域にかかる依存

関係がないことを確認する必要があります。次に、エクスポートを使用して、

トランスポータブル表のセットを作成します。ここでは、データ自体ではなく、

メタデータだけをエクスポートする点に注意してください。データベースの全

体エクスポートもおこないますが、ROWS=nと指定して、メタデータだけがエ

クスポートされるようにします。これにより、パッケージやプロシージャなど

のオブジェクトがすべて、新しいOracle Database 10gに存在するようになります。

% exp SYS/oracle TRANSPORT_TABLESPACE=y TABLESPACES=(users,tools) ¥ TTS_FULL_CHECK=y % exp SYSTEM/oracle FULL=y FILE=full.dmp ROWS=n

図 2 - Oracle 10g へのメタデータのエクスポート、データファイルのプラグイン

手順 5：表領域を新しいOracle Database 10gにインポートします。表領域は同じ

システム上にあるので、ロケーション間でデータをコピーする必要はありませ

ん。

4

表領域は新しいOracle Database 10gに"プラグ"インされます。事前に取得したフ

ル・インポートをインポートします。

% imp SYS/oracle TRANSPORT_TABLESPACE=y FILE=expat.dmp DATAFILES=('/oracle/oradata/users01.dbf','/oracle/oradat a/tools01.dbf') % imp SYS/oracle FILE=full.dmp ignore=y 図 2 は手順 3～5 を示しています。必要な停止時間の合計は 13 分です。

手順 6：アップグレードは完了です。残りの作業は、新しいOracle Database 10gですでに稼動しているアプリケーションでユーザーを指すだけです。

図 3：アップグレード完了 - Oracle 10g で本番が稼動

手順 7：このプロセスの最後の手順は、新しいOracle 10gバージョンの本番デー

タベースのホット・バックアップを取得し、リモートDRサイトでフィジカル・

スタンバイをインスタンス化することです。

フォールバックのシナリオ

アップグレードの実行中に万が一問題が発生し、許容される停止時間よりも多

くの時間がかかる場合は、オリジナルのOracle9i Databaseを起動して、アプリ

ケーションはOracle9i Databaseを指した状態で再起動し、アップグレードは後日

に延期します。

トランスポータブル表領域

Oracleのトランスポータブル表領域[2]機能を使用すると、Oracleデータベース間

でユーザーの表領域を迅速に移動できます。これは、データベース間で大量の

データを移動するためのもっとも効率的な方法です。前述したAmadeusの例で

は、データの移動はなく、Oracle9i Databaseから単に"アンプラグ"されて、Oracle Database 10gに"プラグ"インされるだけです。

5

6

トランスポータブル表領域を使用すると、同じデータをエクスポートおよびイ

ンポート、またはアンロードおよびロードするよりもはるかに高速にデータを

移動できます。これは、表領域の転送では、データファイルをコピーして、表

領域の構造情報を統合するだけで済むためです。トランスポータブル表領域を

使用して、表と索引データの両方を移動することもできます。これにより、表

データをインポートまたはロードする際、索引を再作成する必要がなくなります。

前述した Amadeus の例では、トランスポータブル表領域を使用して、データ

ベースの移行を支援しています。さらに、以下の操作がおこなわれます。

• データウェアハウスの表でパーティションをエクスポートおよびイ

ンポートする。

• CD の構造化データを公開する。

• 複数のデータベース上にある読取り専用の複数の表領域をコピーする。

• 履歴データをアーカイブする。

• 表領域のポイント・イン・タイム・リカバリ（TSPITR）を実行する。 Amadeusは、Oracle9i Databaseトランスポータブル表領域により、かなりの柔軟

性も得ています。一例をあげると、Amadeusは、HP Logical Volume Manager搭載

のHP N-Classで稼動しているOracleの単一インスタンス（RAC以外）の表領域を、

Veritas Cluster Volume Manager搭載のHP Superdomeで稼動しているOracle RACに転送できました。ただし、Oracle9i Databaseでは、引き続きソース・データベー

スとターゲット・データベースが同じOSのプラットフォームにあることが要求

されます。Oracle Database 10gは、トランスポータブル表領域にクロス・プラット

フォームのサポートを追加して、ユーザーがさまざまなOSのプラットフォーム

間で表領域を転送できるようにします。この機能には、次のような活用方法が

あります。

• 構造化データを公開し、異なるプラットフォーム上で Oracle を使用す

る顧客に構造化データを配布するためのより簡単で効率的な手段を

コンテンツ・プロバイダに提供する。

• データウェアハウス環境から、異なるプラットフォーム上で小規模な

システムを運用することが多いデータ・マートへのデータ配布を簡素

化する。

• 異機種クラスタ間で読取り専用の表領域を共有できるようにする

（ノードは同じエンディアンネスをもっている必要がある）。

• あるプラットフォームから別のプラットフォームへのデータベース

移行を支援する（Data Pump またはインポート/エクスポートを使用）。 ソース・プラットフォームとターゲット・プラットフォームのエンディアンネ

スが異なる場合は、ソース・プラットフォームまたはターゲット・プラット

フォームのいずれかで、Oracle RMAN を使用する追加の変換手順が自動化され、

転送される表領域をターゲットの形式に変換する必要があります。両プラット

フォームのエンディアンネスが同じであれば変換する必要はなく、同じプラッ

トフォームにある場合と同様に表領域を転送できます。

Oracle DATA GUARD 10G およびローリング・アップグレード

Oracle Data Guard 10g [3]（リリース 10.1.0.3 以降）は、データベースのローリン

グ・アップグレードのためのすぐに使えるソリューションであり、前述のプロ

セスを大幅に簡素化し、データベースの合計停止時間を格段に短縮します。

7

Oracle Data Guard 10g のローリング・アップグレード・プロセスは、Oracle Data Guard の標準のプロシージャと同様に、スタンバイ・データベースをインスタ

ンス化することから始まります。しかし、そのあとは異なり、Oracle Data Guard SQL Apply を使用して、プライマリ・データベースの論理コピーを作成します。

スタンバイ・データベースが作成されると、Oracle Data Guard は、プライマリ・

データベースからスタンバイ・データベースにREDOデータを送信します。ロー

リング・アップグレード・プロセスは以下の手順で実行されます。

1. スタンバイ・データベースの SQL Apply を停止して、スタンバイ・データ

ベースの Oracle データベース・ソフトウェアをバージョン"n+1"にアップ

グレードします。プライマリ・データベースは、引き続きトランザクショ

ンを処理します。アップグレード・プロセスが次の手順に進む間に、プラ

イマリ・サーバーに REDO が累積されます。 2. SQL Apply がスタンバイ・データベースで再開され、Oracle Data Guard 構

成が混合モードで動作します（Oracle のバージョンは、プライマリ・デー

タベースでは"n"、スタンバイ・データベースでは"n+1"です）。Oracle Data Guard が自動的に 2 つのデータベースを再同期化し、プライマリ・データ

ベースの最新のトランザクションを使用して、スタンバイ・データベース

を最新の状態にします。本番環境は、新しい Oracle のリリースが予想どお

りに動作していることをDBAスタッフが確認するまでの間、この混合モー

ドで稼動します。アップグレードのこの段階までは、アプリケーションの

停止時間はゼロです。続いて、アップグレード・プロセスが次の手順に進

みます。 3. Oracle Data Guard の標準のスイッチオーバーを実行して、スタンバイ・サー

バーのロールを"新しい"プライマリのロールにリバースします。これが

アップグレード・プロセス中、停止時間が必要となる最初で唯一のタイミ

ングとなります。データベースの合計の停止時間は、Oracle のベスト・プ

ラクティスに従った場合に数秒で完了するタスクである、スイッチオー

バー・プロセスを完了するのにかかる時間と同等です。新しいプライマ

リ・データベースでユーザー・アプリケーションおよびサービスをアク

ティブにします。すべてが予想どおりに動作している場合は、手順 4 に進

んでアップグレード・プロセスを完了します。問題があり、簡単に解決で

きない場合は、単純に以前のプライマリ・データベースを開き、ユーザー

を切り換えてやり直します。 4. すべての確認が終わり、新しいプライマリ・データベースが本番環境で予

想どおりに稼動しています。このタイミングでプロセスを完了し、元のプ

ライマリ・データベース（現在の新しいスタンバイ・データベース）をアッ

プグレードします。新しいスタンバイ・データベースの SQL Apply を停止

します。Oracle データベース・ソフトウェアをバージョン n+1 にアップグ

レードします。SQL Apply を再起動し、Oracle Data Guard により新しいプ

ライマリ・データベースの内容で新しいスタンバイ・データベースを自動

的に最新の状態にできるようにします。手順 1、2、および 4 と同様、本番

アプリケーションの停止時間はゼロです。

結論

Amadeusは、DRソリューションとしてOracle Data Guardを使用することで、そ

の業績をさらに伸ばしました。また、Oracle Data Guardをトランスポータブル

表領域とともに使用することで、Oracle9i DatabaseからOracle Database 10gにアップグレードする際のデータベース停止時間を短縮し、品質保証契約の規定

を守ることができました。

Oracle Data Guard 10gは同様の原則を活用し、標準のすぐに使えるソリューショ

ンで、これまでの"独自"のプロセスを簡素化するデータベースのローリング・

アップグレードを実装します。もっとも重要なのは、Oracle Data Guard 10gの

8

ローリング・アップグレード機能により、データベースの停止時間がほぼゼロ

になる点です。

参考資料

1. 『Oracle Data Guard 概要』 http://www.oracle.com/technology/global/jp/deploy/availability/htdocs/DataGuardOverview.html

2. 『Oracle データベースのクロス・プラットフォームのトランスポータブル

表領域』 http://www.oracle.com/technology/global/jp/deploy/availability/htdocs/xtts.html

3. 『Oracle Database 10g の Oracle Data Guard 企業のための障害時リカバリ ホワイトペーパー』 http://otndnld.oracle.co.jp/products/database/oracle10g/availability/pdf/DataGuardTechOverview_10gR1.pdf

Amadeus - DATA GUARD OTN PROFILE 2004 年 12 月 著者：Phil Grice、Joe Meeks、Ashish Ray、Paul Tsien Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口： 電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com Oracle は米国 Oracle Corporation の登録商標です。本文書内で参照される各種製品とサー

ビスの名称は Oracle Corporation の商標です。その他の製品とサービスの名称はすべてそ

れぞれの会社の商標です。 Copyright © 2004 Oracle Corporation All rights reserved.