Starwood Hotels：Oracle Database 10g RMANを最大に活かすためのベスト・プラクティス

Size: px

Start display at page:

Download "Starwood Hotels：Oracle Database 10g RMANを最大に活かすためのベスト・プラクティス"

としみかがんじ
5 years ago
Views:

1 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, 万名以上の従業員 Starwd Htels: データ保護における課題と目標 8TB のデータベースに対する 19 時間のバックアップ時間の短縮と 24 時間 365 日の可用性維持ハードウェアコストやソフトウェアコストの節約によるバックアップインフラストラクチャへの IT 支出の削減 2 時間のリカバリ時間目標 (RTO) 達成とデータベース全体の可用性向上 Starwd HtelsのOracle 環境 Oracle Database から Oracle Database へのアップグレード 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

2 リカバリ時間目標 (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

3 再設計の成功 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

4 フラッシュリカバリ領域内のバックアップ 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 はフラッシュ

5 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

6 Starwd Htels: ケーススタディ 2004 年 11 月著者 : オラクルシニアプロダクトマネージャ Dnna Cksey Starwd Htels and Resrts データベースシステムマネージャ Arup Nanda Oracle Crpratin Wrld Headquarters 500 Oracle Parkway Redwd Shres, CA U.S.A. 海外からのお問い合わせ窓口 : 電話 : ファクシミリ : Oracle は米国 Oracle Crpratin の登録商標です本文書内で参照される各種製品とサービスの名称は Oracle Crpratin の商標ですその他の製品とサービスの名称はすべてそれぞれの会社の商標です Cpyright 2004 Oracle Crpratin All rights reserved. 6

ホワイトペーパー EMC VFCache により Microsoft SQL Server を高速化 EMC VFCache EMC VNX Microsoft SQL Server 2008 VFCache による SQL Server のパフォーマンスの大幅な向上 VNX によるデータ保護 E

ホワイトペーパー EMC VFCache により Microsoft SQL Server を高速化 EMC VFCache EMC VNX Microsoft SQL Server 2008 VFCache による SQL Server のパフォーマンスの大幅な向上 VNX によるデータ保護 E ホワイトペーパー VFCache による SQL Server のパフォーマンスの大幅な向上 VNX によるデータ保護 EMC ソリューショングループ要約このホワイトペーパーでは EMC VFCache と EMC VNX を組み合わせて Microsoft SQL Server 2008 環境での OLTP( オンライントランザクション処理 ) のパフォーマンスを改善する方法について説明します