Starwd Htels:Oracle Database 10g RMAN を最大に活かすためのベスト プラクティス Oracle Database 10g RMAN による増分バックアップは Oracle9i の RMAN を使用した同じ増分バックアップの約 10 倍の速さであるため バックアップ時間が 19 時間から 2 時間に短縮されました Starwd Htels and Resrts データベース システム マネージャ ---Arup Nanda 会社概要 :Starwd Htels 世界最大級のホテル レジャー企業 Westin Htels & Resrts Sheratn St. Regis などの有名ブランド名で運営 82 カ国で 700 以上の施設と提携 部屋数約 229,000 11 万名以上の従業員 http://www.starwdhtels.cm/ Starwd Htels: データ保護における課題と目標 8TB のデータベースに対する 19 時間のバックアップ時間の短縮と 24 時間 365 日の可用性維持 ハードウェア コストやソフトウェア コストの節約による バックアップ インフラストラクチャへの IT 支出の削減 2 時間のリカバリ時間目標 (RTO) 達成と データベース全体の可用性向上 Starwd HtelsのOracle 環境 Oracle Database 9.2.0.5 から Oracle Database 10.1.0.1 へのアップグレード 8TB のデータウェアハウス データベース 24CPU と 48GB RAM のエンタープライズ クラス マシン 8 ドライブのテープ ライブラリ システム 概要 Starwd Htels では オンライン予約 ブッキング ゲスト コミュニケーション マーケティング キャンペーンの基幹要素として オラクルの OLTP データベースとデータウェアハウス データベースを利用しています これらのミッション クリティカルな Oracle Database を保護するため Oracle 8i Database から始めて 5 年以上に渡り Starwd Htels は Oracle Recvery Manager(Oracle RMAN) を使用しています 多くの企業組織と同様に Starwd Htels でも驚異的にデータが増加しており ビジネス要件からリカバリ時間目標の短縮を求められていました 既存のバックアップとリカバリのインフラストラクチャ とくに 8TB のデータウェアハウス データベースは ハードウェアまたはソフトウェアを追加するか もしくは再設計をおこなわない限り 何らかの問題が発生してしまうことが予想されていました Starwd Htels は Oracle Database 10g RMAN とディスクベース バックアップを活用し リカバリ時間目標を達成するよう バックアップとリカバリのインフラストラクチャの再設計をおこないました はじめに Starwd Htels & Resrts Wrldwide, Inc. は世界有数のホテル レジャー企業であり その所有施設は 80 カ国以上で 700 を超え 所有および管理施設に勤務する従業員は 11 万名におよびます 国際的に有名なブランドをもつ Starwd Htels は ホテルとリゾートの所有 運営 およびフランチャイズをおこなう総合企業であり 傘下には St. Regis The Luxury Cllectin Sheratn Westin Fur Pints by Sheratn W ブランド さらに高級なタイムシェア リゾートの開発と運営をおこなう主要企業の 1 つである Starwd Vacatin Ownership, Inc があります 変更前のバックアップ アーキテクチャ Starwd Htels の企業 IT スタッフは Oracle9i とテープ バックアップ用のサード パーティ製メディア管理ソフトウェアを使用して 一元化されたバックアップ管理戦略を RMAN とともに問題なく実装していました しかし 予測されるデータ増加速度とリカバリ時間目標に対応するように バックアップとリカバリのインフラストラクチャを拡張することは容易ではなく 高いコストも伴いました バックアップとリカバリに関して最大の課題を抱えていたのは 8TB のデータウェアハウス データベースです このデータベースは 次の 12~18 ヶ月以内に容量が 16TB に倍増することが予想されていました 次に Starwd Htels のバックアップ スケジュールとこの拡大するデータベースが抱える課題について説明します 1
リカバリ時間目標 (RTO) 標準的障害の場合 2 時間 完全なサイト障害 ( 災害 ) の場合 24 時間の RTO Oracle9i Database のバックアップ スケジュール RMAN の構成 FILESPERSET=10 チャネルごとに異なるディスク形式文字列を使用することで 並列度 8 を達成 各チャネルが異なるファイル システムに書き込むことで テープ管理ソフトウェアを使用したテープへのパラレル データ移動を実現 1 つの名前をもつ並列度 8 のチャネルでは達成不可能 週次 ( 毎日曜 ) のフル ( レベル 0) バックアップ 日次の増分 ( レベル 1) バックアップ おおよそのバックアップ時間 = 19 時間 ( フルまたは増分 *) 直面していた主要課題 : 1. Oracle9i RMAN を使用した 19 時間のバックアップ時間は バックアップ時間枠を超過 2. フル バックアップよりも増分バックアップでより多くの CPU を使用 * 3. データベース サイズの倍増を予測 (8TB から 16TB の可能性 ) a. バックアップ時間が 38 時間 (19 時間 2) かかるとすると 日次バックアップはもはや実行不可能 4. テープからのリカバリは 2 時間のリカバリ時間目標を未達成 * 通常 Oracle9i Database の増分バックアップではメディア消費量は節約されますが 時間はあまり短縮されません これは バックアップに含める変更ブロックを見つけるためにデータベースのフル スキャンが必要とされるためです 選択肢の比較検討 バックアップとリカバリの課題に対して最適な対応をおこなうため Starwd Htels の経験豊かな DBA スタッフは技術要件と予算に合わせて選択肢の比較検討をおこないました 選択肢利点選択しない理由 バックアップ頻度の減少 ( 日次から 1 日おきに変更 ) バックアップの最適化 ( 読取り専用表領域のバックアップは一度だけに ) テープ ドライブの追加 バックアップ時間の重複がない バックアップ対象のデータ量の削減 バックアップ完了時間の短縮 2 時間という RTO を満たさない このデータベースには読取り専用表領域はほとんど ( またはまったく ) ないため 効果はわずかしか ( またはまったく ) ない テープ ライブラリはすでにドライブ容量を最大限に使用している データ保護における現在と将来の課題を解決するには まったく新しいアプローチを採用する必要がありました そこで もう 1 つの選択肢が協議の対象となりました - ディスクベースのバックアップです ディスク ストレージ テクノロジーの信頼性はきわめて高くなっており またテープと比較しても価格競争力は見劣りしません Starwd Htels は Oracle Database 10g へアップグレードするまでの暫定ステップとして Oracle9i Database にディスクベースのバックアップとリカバリのアーキテクチャを実装することに決めました Oracle Database 10g RMAN の主要拡張機能 Starwd Htels のデータベース システム マネージャである Arup Nanda は Oracle Database 10g のベータ版を扱った経験があり Oracle Database 10g へのアップグレードが Starwd Htels にもたらすであろうメリットについて十分に理解していました Nanda は バックアップとリカバリの目標を達成するために役立つ 3 つの主要な RMAN 機能を特定しました 2
再設計の成功 1. ブロック チェンジ トラッキング - 増分バックアップを高速化する機能を提供 a. 新しいブロック チェンジ トラッキング機能はビットマップ ファイルであり データベースに対する変更の物理的なブロック位置を追跡する b. RMAN はこのチェンジ トラッキング ファイルを使用して前回のバックアップ以降に変更されたブロックを特定するため 増分バックアップ中のデータベースのフル スキャンが不要になる c. データベースのフル スキャンが不要になるため CPU 使用量が削減される 2. フラッシュ リカバリ領域 - オンライン バックアップとリカバリに関連するファイルの管理性を向上 a. すべてのリカバリ関連ファイルに対して統一された格納場所が提供される b. RMAN 保存方針を設定すると 指定されたリカバリ時間に対して不要となった古い RMAN バックアップとアーカイブ ログを削除することで RMAN はフラッシュ リカバリ領域のスペース要件を自動的に管理できる 3. 増分更新バックアップ - フル バックアップの不要化 a. より最新のフル バックアップがオンラインで保持できるため リカバリ時間を短縮できる b. 増分バックアップがオンラインのイメージのフル バックアップにマージされるため マージされた増分の時点までの新規フル バックアップが作成される c. 初回のフル ( レベル 0) バックアップのあと 必要なのは増分のみである Starwd Htels は バックアップとリカバリのインフラストラクチャをディスクベースのバックアップへと再設計することに決めました 初期のディスクベース バックアップ戦略は まずリカバリ目標を達成するように Oracle9i Database を実装し 次に ディスク バックアップと Oracle Database 10g に含まれるストレージ拡張機能の利点を活用するために調整をおこなうというものでした Starwd Htels は Oracle Database 10g にアップグレードする際 オラクルが推奨するバックアップ戦略を採用しましたが この戦略は Starwd Htels の環境に適したものでした 2 時間という RTO を実現するため 増分バックアップ スケジュールを 1 日 2 回に増やし 2 つのフル バックアップを保持することが選択されました 次に Starwd Htels の計画概要を示します リカバリ計画 リカバリ ポイントが 24 時間以内である場合 ディスクを使用 リカバリ ポイントが 24 時間を超える場合 テープを使用 ディスク バックアップ スケジュール フラッシュ リカバリ領域への日次増分バックアップ 1 日 2 回の増分バックアップ 12 時間ごとのスケジュール 前日の増分バックアップから対応するオンラインのフル バックアップへの日次マージ 2 つのフル バックアップの保持と日次更新 3
フラッシュ リカバリ領域内のバックアップ 2 つのフル バックアップによる冗長性を維持 該当する前日の増分バックアップ ( 増分更新バックアップ ) までの時点の 2 つの最新イメージ フル バックアップ それぞれの日次増分バックアップは割り当てられたフル バックアップにマージされるため 12 時間離れた時点までの 2 つの最新オンライン フル バックアップが作成される ( 増分バックアップは 12 時間ごとのスケジュール ) 2 つの増分バックアップ ( 当日の 2 つの増分 ) アーカイブ ログ テープへのアーカイブ テープにアーカイブされたフラッシュ リカバリ領域 即座にテープにバックアップされるアーカイブ ログ ディスクベースのインフラストラクチャと Oracle Database 10g へのアップグレードを通じて Starwd Htels がバックアップとリカバリの課題に対応した方法を次の表に示します Oracle Database 10g の特定の機能に関連して達成された利点については その旨の記載があります 結果 日次増分バックアップを 2 時間で終了 (10 倍の速度 ) 週次フル バックアップの廃止と 増分バックアップによる代替 Oracle 投資に対する ROI の向上 課題への対応 ブロック チェンジ トラッキングの有効化による増分バックアップの高速化の実現 増分更新バックアップによる初回以降のフル バックアップの不要化 フラッシュ リカバリ領域と ASM では 低コスト ディスクのより効果的な実装が可能 Oracle Database 10g Oracle Database 10g Oracle Database 10g 2 時間の RTO を達成リカバリと可用性に関して テープと比較した場合のディスクベース バックアップの利点 リストアとリカバリは テープよりもディスク使用の場合が高速 RMAN ブロック メディア リカバリはランダムなディスク アクセスであるため より効率的である テープの順次読取り形式はパフォーマンスが低下する場合がある ORACLE DATABASE 10g のストレージ拡張機能 Oracle Database 10g の Oracle Autmatic Strage Management(Oracle ASM) により Starwd Htels は安価な SATA ディスクを利用できたため Oracle9i Database の RMAN によるディスク バックアップで利用していた高価な SAN フレームとボリューム マネージャは不要になりました 安価なディスクは ASM ディスク グループとともにグループ化され 多数のディスクにまたがるストライプ化による高いパフォーマンスと ASM ミラー化による信頼性が実現されました Oracle ASM と SATA ディスクを使用することにより Starwd Htels は 通常は高価なディスクでのみ実現可能なレベルのパフォーマンスと信頼性を低コストの実装で実現しました 4
Oracle ドキュメント Oracle Database 10g バックアップおよびリカバリ基礎 Tuning Oracle Recvery Manager ( 英語 ) RMAN Perfrmance Testing at Sun Custmer Perfrmance Center: 1 TB/hr Backup & Restre ( 英語 ) Starwd Htels は フラッシュ リカバリ領域を ASM ディスク グループとして定義しました 結論 Starwd Htels は ディスクベースのバックアップ戦略を利用し Oracle Database 10g のテクノロジー拡張機能を活用することにより バックアップ インフラストラクチャを再設計することで バックアップとリカバリの課題を克服しました 次に この変更による利点を示します 19 時間から 2 時間へ バックアップ時間を短縮 ブロック チェンジ トラッキングの有効化により 増分バックアップの高速化を実現 増分更新バックアップによる フル バックアップの不要化 リカバリ時間を短縮 増分更新バックアップは直近の増分を使用した最新状態にあるため リカバリへの増分適用は不要 テープよりもディスクから実行すると大幅に迅速になるブロック メディア リカバリ リソース使用率の向上 - CPU 使用量の削減 ブロック チェンジ トラッキングを有効化した増分バックアップによる データベース フル スキャンの不要化 SAN フレームとボリューム マネージャの代わりに安価な SATA ディスクと Oracle ASM を使用することで コストを削減 5
Starwd Htels: ケース スタディ 2004 年 11 月著者 : オラクル シニア プロダクト マネージャ Dnna Cksey Starwd Htels and Resrts データベース システム マネージャ Arup Nanda Oracle Crpratin Wrld Headquarters 500 Oracle Parkway Redwd Shres, CA 94065 U.S.A. 海外からのお問い合わせ窓口 : 電話 :+1.650.506.7000 ファクシミリ :+1.650.506.7200 www.racle.cm Oracle は米国 Oracle Crpratin の登録商標です 本文書内で参照される各種製品とサービスの名称は Oracle Crpratin の商標です その他の製品とサービスの名称はすべてそれぞれの会社の商標です Cpyright 2004 Oracle Crpratin All rights reserved. 6