EMC SRDF/TimeFinderおよびOracle Database 10g/11gを使用した EMC Symmetrix V-Max

Transcription

1 EMC SRDF/TimeFinder および Oracle Database 10g/11g を使用した EMC Symmetrix V-Max 高度なテクノロジー US ホワイトペーパー翻訳版 要約 このホワイト ペーパーでは EMC Symmetrix V-Max のソフトウェアおよびハードウェアの機能について説明するほか 高可用性およびビジネス継続性を維持しながら EMC Symmetrix V-Max で Oracle Database 10g および 11g を展開するための包括的なベスト プラクティスと手順のセットを紹介します また Oracle データベースで広く展開されている EMC TimeFinder および SRDF (Symmetrix Remote Data Facility) についても取り上げています 2009 年 4 月

2 Copyright 2009 EMC Corporation.All rights reserved. このドキュメントに記載されている情報は ドキュメントの出版日現時点の情報です この情報は 予告なく変更されることがあります この資料に記載される情報は 現状有姿 の条件で提供されています EMC Corporation は この資料に記載される情報に関する どのような内容についても表明保証条項を設けず 特に 商品性や特定の目的に対する適応性に対する黙示の保証はいたしません この資料に記載される いかなる EMC ソフトウェアの使用 複製 頒布も 当該ソフトウェア ライセンスが必要です 最新の EMC 製品名については で EMC Corporation の商標を参照してください 他のすべての名称ならびに製品についての商標は それぞれの所有者の商標または登録商標です パーツ番号 H J 高度なテクノロジー 2

3 目次 エグゼクティブ サマリー...5 はじめに...5 対象読者... 7 製品と機能の概要...7 Symmetrix V-Max... 7 Symmetrix V-Max 自動プロビジョニング グループ... 8 Symmetrix V-Max の強化された仮想 LUN 移行テクノロジー... 9 構成済みの領域への移行 未構成の領域への移行 Symmetrix V-Max TimeFinder 製品ファミリ TimeFinder/Clone と新しいカスケード クローン TimeFinder/Snap と新しい TimeFinder/Snap Recreate TimeFinder Consistent Split TimeFinder と SRDF Symmetrix V-Max SRDF 製品ファミリ SRDF 操作モード...14 SRDF トポロジー...18 TimeFinder と SRDF を利用してデータの整合性を実現 ASM リバランシングとコンシステンシ テクノロジー TimeFinder および SRDF を利用してビジネス継続性ソリューションを実現...22 データベース ストレージ レイアウトとベスト プラクティス 使用例 1: 本番環境でのデータベース バックアップの負荷を軽減する ステップの概要 使用するデバイス グループ ステップの詳細 使用例 2: データベースの並行リカバリ ステップの概要 使用するデバイス グループ ステップの詳細 使用例 3: 本番環境の再起動可能なローカル レプリカ ステップの概要 使用するデバイス グループ ステップの詳細 使用例 4: 災害保護のためのリモート ミラーリング ( 同期および非同期 ) ステップの概要 使用するデバイス グループ ステップの詳細 使用例 5: 他の目的で使用するための再起動可能なリモート データベース レプリカ ステップの概要 使用するデバイス グループ ステップの詳細 使用例 6: リモート データベースの有効なバックアップ レプリカ 高度なテクノロジー 3

4 ステップの概要 使用するデバイス グループ ステップの詳細 使用例 7: リモート バックアップ レプリカからのデータベースの並行リカバリ ステップの概要 使用するデバイス グループ ステップの詳細 使用例 8: 再起動可能なレプリカからのデータベースの高速リカバリ ステップの概要 使用するデバイス グループ ステップの詳細 結論...40 付録 : テスト用ストレージおよびデータベース構成...40 一般的なテスト環境 テストのセットアップ 高度なテクノロジー 4

5 エグゼクティブ サマリー EMC Symmetrix V-Max Series with Enginuity は Symmetrix ファミリの新しい製品です この製品はシンプルでインテリジェントなモジュラー ストレージ戦略に基づいて構築されており 新しく組み込まれた Virtual Matrix インタフェースはすべてのノードに接続し共有します これにより ストレージ アレイをエントリー レベルの構成から世界最大規模のストレージ システムにシームレスに拡張できます Symmetrix V-Max は EMC の幅広いソフトウェア製品群をサポートしながら 要件の厳しいエンタープライズ データベース環境に対して優れたパフォーマンスと拡張性を提供します さらに Enginuity 5874 のリリースにより Symmetrix V-Max システムでは 使いやすさ ビジネス継続性 ILM( 情報ライフサイクル管理 ) 小規模環境から大規模環境への仮想化環境 セキュリティの強化を実現する新しいソフトウェア機能を利用できるようになりました Symmetrix V-Max アレイは Oracle データベースとアプリケーションに適切に統合され パフォーマンスのニーズや将来の成長に対応するだけでなく 拡張性 可用性 操作性を実現します このホワイト ペーパーでは Symmetrix V-Max のソフトウェアおよびハードウェアの機能について説明するほか 高可用性およびビジネス継続性を維持しながら EMC Symmetrix V-Max で Oracle Database 10g および 11g を展開するための包括的なベスト プラクティスと手順のセットを紹介します また Oracle データベースで広く展開されている EMC TimeFinder および SRDF (Symmetrix Remote Data Facility) についても取り上げています はじめに Symmetrix V-Max の操作性 拡張性 仮想化に関する新機能 Symmetrix V-Max ではパフォーマンス 拡張性 可用性が強化され Enginuity 5874 により操作性 仮想化 および ILM に関する機能が新しく追加されました Symmetrix V-Max 自動プロビジョニング グループを使用すると 小規模または大規模な Oracle データベース環境にデバイスを迅速かつ容易にマップできます デバイス HBA WWN またはストレージ ポートを簡単に追加または削除でき こうした変更は自動プロビジョニング グループに自動的に反映されるため すべての物理または仮想環境における複雑なストレージ プロビジョニングを合理化し 向上させます Symmetrix V-Max の強化された仮想 LUN テクノロジーにより データベースがアクティブでも Oracle アプリケーションのデータをストレージ階層間でシームレスに移行でき これにより最適なパフォーマンスとコスト要件を実現できるストレージ階層にデータを配置することが可能です データベースのパフォーマンス要件が変更されても 適切な LUN を新しいストレージ階層に容易かつ効率的に移動できます Symmetrix V-Max 仮想 LUN の移行はホストまたは SAN リソースを消費しません 適切なストレージ階層戦略を使用することで ROI( 投資収益率 ) が向上します また ホスト デバイスが変わらないためバックアップまたは DR 計画を変更する必要がなく 複雑さも緩和されます 可用性 拡張性 操作性の強化点についてはこのホワイト ペーパーの後半で説明します また V-Max の製品ガイドでも詳しく説明します Oracle のミッション クリティカルなアプリケーションでは保護戦略が必要データが増加し その相互接続性が高まり さらに組織のインフラストラクチャが拡大すると データ保護および可用性に対するニーズはますます増大します データベースとアプリケーションに継続的にアクセスし 使用可能なシステム リソースを効率的に使用できるようにすることは非常に重要です データ センターにふりかかる災難は 人為的エラー ハードウェアおよびソフトウェアの障害 自然災害によって発生します 災害が発生したときに 迅速かつシームレスに業務を再開し データ消失を最小限に抑えられるかどうかによって 災害に対する組織の対応力が試されます 有効なバックアップと情報インフラストラクチャ全体の再起動可能なイメージがあれば 必要なレベルの RPO(Recovery Point Objective: 目標復旧時点 ) RTO(Recovery 高度なテクノロジー 5

6 Time Objective: 目標復旧時間 ) SLA(Service Level Agreement) を実現するのに非常に役立ちます SRDF を使用したエンタープライズの保護とコンプライアンスデータの整合性とは データとデータのコピーの正確性と整合性のことです Symmetrix V-Max は Oracle データベースとアプリケーションのデータのローカル レプリケーションとリモート レプリケーションのソリューションを複数提供します SRDF ソフトウェアを使用すると 1 つまたは複数のデータベース ミラーを作成できます この際 外部データ アプリケーション ファイル メッセージ キューもともに作成され これらはすべてコンシステンシ グループを共有します この方法でデータをレプリケートすると 災害が発生する前にビジネス ユニットおよびアプリケーションで整合性ポイントが作成されます DR サイトへのフェイルオーバーは 全体的な複雑さとダウンタイムを緩和する一連の再開オペレーションに過ぎません SRDF は 2 サイトまたは 3 サイト ソリューション および同期 / 非同期レプリケーションを提供するほか SRDF/Star カスケード SRDF またはコンカレント SRDF 新しい SRDF/EDP (Extended Distance Protection) を使用して 距離を問わずにデータ消失ゼロのソリューションを提供します たとえば SRDF/Star を使用すると 本番アレイが使用できない場合でも 災害復旧サイトがないビジネスを運営しない などのコンプライアンス要件を満たすことができます TimeFinder での Oracle データベースのクローンとスナップショットミッション クリティカルなシステムには必ず 開発 テスト バックアップの負荷軽減 レポート作成 データ発行などの処理のためのコピーが複数必要です TimeFinder ソフトウェアを導入した Symmetrix V-Max を導入すると Oracle データベースの複数のコピー ( ボリューム全体のクローンまたは仮想スナップショットのいずれか ) を そのデータベースのサイズに関係なく わずか数秒で作成またはリストアできます この動作は増分コピーであり 変更のみがコピーされます TimeFinder がレプリカを作成 ( またはリストア ) すると 差分コピー操作がバックグラウンドで実行されていても コピーが完了したかのように 最終的なイメージがターゲット デバイス ( またはソース デバイス ) にすぐに表示されます この機能により ビジネス運用時間が大幅に短縮されます たとえば 本番環境で直接バックアップを行うのではなく バックアップの負荷をスタンドアロンのレプリカに数秒で移動して軽減できます また Oracle データベースのリストアが必要な場合は TimeFinder リストアの開始と同時に データベース リカバリ操作を開始できます ストレージ リストアの完了を待つ必要はありません 並列リストアとも呼ばれるこの機能により RTO が大幅に短縮されビジネス可用性が向上します ストレージ コンシステント レプリケーションを使用した Oracle データベース リカバリ場合によっては DR サイトへのフェイルオーバーさえも実行することなく 非常に高速にデータベース リカバリを行わなければならないことがあります ( 特に 多数のデータベースのうち 1 つだけが論理的または物理的に破損している場合 ) TimeFinder 整合性テクノロジーを実装すると Oracle データベースをホット バックアップ モードにすることなく データベース レプリカを定期的に たとえば数時間ごとに取得できます Oracle は 整合性のとれたストレージ レプリカでのデータベース リカバリをサポートし アーカイブおよび REDO ログを適用してデータベースを復旧します (Oracle サポートは Metalink Note に基づいています ) ローカルおよびリモートの Oracle データベース レプリケーションのベスト プラクティスこのホワイト ペーパーでは Symmetrix V-Max システム 自動プロビジョニング グループ 仮想 LUN テクノロジーの概要を Oracle 関連の例とともに紹介しています また 次の使用例の手順とベスト プラクティスについて詳しく説明します 使用例 1: データベース バックアップの負荷を本番環境からローカルの TimeFinder/Clone に移動して軽減してから Oracle の RMAN(Recovery Manager) を使用してさらにバックアップを行う 使用例 2: ローカルの TimeFinder/Clone バックアップ イメージをリストアし ログを適用することで 本番データベースの並列リカバリを容易に行えるようにする 高度なテクノロジー 6

7 使用例 3: データベースを転用 ( テストの作成 開発 コピーのレポートなど ) するために 本番環境の再起動可能なローカル クローン ( またはスナップ ) を作成する 使用例 4: 災害保護の目的で本番データベースのリモート ミラーを作成する ( 同期および非同期 ) 使用例 5: 転用するために 再起動可能で書き込み可能なリモート データベース クローン ( またはスナップ ) を作成する 使用例 6: リモート データベースの有効なバックアップおよびリカバリ クローン ( またはスナップ ) を作成する 使用例 7:TimeFinder/Clone バックアップ イメージを SRDF リストアと同時にリストアし 並行して Oracle ログを本番データベースに適用することで 本番データベースの並行リカバリを容易に行えるようにする 使用例 8: 再起動可能な TimeFinder レプリカを使用してデータベースの高速リカバリを示す 対象読者 このホワイト ペーパーの主な読者は 堅牢なデータベース システムおよびストレージ システムの実装 保守 保護を担当するデータベース管理者 システム管理者 ストレージ管理者 システム設計者です また 読者は Oracle データベース バックアップと EMC ソフトウェアに精通しており データベースの可用性と保護の強化に関心があることを前提としています 製品と機能の概要 Symmetrix V-Max Symmetrix V-Max はシンプルでインテリジェントなモジュラー ストレージ戦略に基づいて構築されており 新しく組み込まれた Virtual Matrix インタフェースはすべてのノードに接続し共有します これにより ストレージ アレイをエントリー レベルの構成から世界最大規模のストレージ システムにシームレスに拡張できます この Symmetrix V-Max では 図 1 に示す新しいハードウェア機能を備えており 最高レベルのパフォーマンスと可用性を提供します 2 16 director boards 最大 2.1 TB( 有効容量 ) Up to 128 FC FE ports Up to 64 FICON FE ports Up to 64 Gig-E / iscsi FE ports 最大 512 GBのグローバル メモリ ( 有効容量 1 GB) 482,400ƒfƒBƒXƒN Eƒhƒ ƒcƒu Enterprise Flash drives 200/400 GB FC drives 146/300/450 GB 15k rpm (or 400 GB 10k rpm) 図 1:Symmetrix V-Max のプラットフォーム 高度なテクノロジー 7

8 Symmetrix V-Max は究極のスケール アウト プラットフォームを提供します 処理モジュール ( ノード ) とストレージ ベイを追加することで フロントエンドとバックエンドのパフォーマンスを段階的に拡張でき 各処理モジュールには 追加のフロントエンド メモリ バックエンドを接続できます また 最大ハイパー サイズが 240 GB(Symmetrix DMX では 64 GB) に増え ストレージ計画とデバイスの割り当てを容易に行えるようになっています これは 特にシン ストレージ プールがストライピングされ 大きなハイパーを簡単に使用できる Virtual Provisioning を使用しているときに便利です Symmetrix V-Max 自動プロビジョニング グループ 自動プロビジョニング グループ機能により Oracle のスタンドアロン データベースおよびクラスタ データベースのストレージ プロビジョニングを簡単で合理的に行えるようになっています 小規模環境および大規模環境でストレージ プロビジョニング タスクが効率化され 所要時間も短縮されました 以前のリリースではストレージ プロビジョニングには多くのステップが必要でしたが この機能によりシンプルで直感的な操作をいくつか行うだけで実行できます 自動プロビジョニング グループ機能は ストレージ グループ イニシエータ グループ ポート グループ および これらのグループをまとめるビューという概念に基づいています ストレージ グループには Symmetrix デバイスが割り当てられます ポート グループには アレイの FA( フロントエンド アダプタ ) ポート番号が割り当てられます イニシエータ グループには HBA WWN 情報が割り当てられます そして ストレージ イニシエータ ポートの各グループがビューにまとめられ このビューでデバイス マスキング操作が自動的に実行されます 使用可能なストレージ デバイス ストレージ アレイ ポート または HBA に変更が必要な場合は 対応するグループのみを変更する必要があります こうした変更はビュー全体にわたって自動的に反映されます たとえば 追加のデバイスが必要な場合は 対応するストレージ グループにそのデバイスを追加するだけで 必要なマッピングおよびマスキング操作のすべてがビュー全体で実行されます ( デバイスがすでにマップされている場合 この操作は短時間で完了します それ以外の場合 Symmetrix 構成変更では マッピングが適切に行われてからマスクされるため多少時間がかかります ) イニシエータ グループは 次の例の示すようにカスケードできます 図 2 は 自動プロビジョニング グループを使用して Oracle RAC( リアル アプリケーション クラスタ ) データベース デバイスをマスクする例を示しています ここでは ストレージ グループはデータベース デバイスで ポート グループは Symmetrix ポートで作成されています また イニシエータ グループは 長期的に管理しやすくするためにホストの HBA ごとに作成されています ただし HBA は クラスタ全体の 1 つのイニシエータ グループにカスケードされています 自動プロビジョニング グループ ビューには ストレージ グループ ポート グループ カスケード イニシエータ グループだけが含まれます クラスタでホストを追加または削除すると カスケード イニシエータ グループのホストも追加または削除されます 同様の方法で グループのデバイスまたは Symmetrix ポートを追加または削除でき ビューはクラスタのデバイス プロビジョニングを自動化します 高度なテクノロジー 8

9 RAC1_HBAs RAC2_HBAs Storage SAN Port: 07E:1 ポート :10E:1 Oracle RAC devices 図 2:Oracle RAC と自動プロビジョニング グループ 自動プロビジョニング グループを使用するステップを次に示します このステップは 図 2 の例に基づいています 1. Create a storage group for RAC devices symaccess -name RAC_devs -type storage devs 790:7AF create 2. Create a port group with storage ports 7E:1 and 10E:1 symaccess -name RAC_ports -type port dirport 7E:1,10E:1 create 3. Create an initiator group for each cluster node s HBAs symaccess -name RAC1_hbas -type initiator -file./rac1_hbas.txt create The file RAC1_hbas.txt contains: WWN: c975c2e4 WWN: c975c336 symaccess -name RAC2_hbas -type initiator -file./rac2_hbas.txt create The file RAC2_hbas.txt contains: WWN: c975c31a WWN: c975c3ab 4. Cascade the cluster nodes initiator groups into a single one for the entire cluster symaccess -name RAC_hbas -type initiator create symaccess -name RAC_hbas -type initiator add ig RAC1_hbas symaccess -name RAC_hbas -type initiator add ig RAC2_hbas 5. Create the view for the entire RAC cluster storage provisioning symaccess create view -name RAC view Symmetrix V-Max の強化された仮想 LUN 移行テクノロジー Enginuity 5874 は強化された Symmetrix 仮想 LUN ソフトウェアを提供することで ストレージ階層または RAID 保護間でデバイスのデータを透過的かつ無停止で移動できるようにします 仮想 LUN 移行テクノロジーにより ユーザーは Symmetrix 論理デバイスを 高パフォーマンスの EFD( エンタープライズ フラッシュ ドライブ ) ファイバ チャネル ドライブ 大容量で低コストの SATA ドライブなどのディスク タイプ間で移動できます デバイスの移行時に そのデバイスの RAID 保護を変更できます 高度なテクノロジー 9

10 仮想 LUN 移行は ホストのオペレーティング システムまたはアプリケーションからは独立して行われるため 移行中でも デバイスはデータベース トランザクションに完全にアクセスできます バックエンド デバイスの特性 (RAID 保護や物理ディスク タイプ ) が変更されても 移行されたデバイスの ID は変わらず シームレスなオンライン移行が可能です 仮想 LUN は Symmetrix レプリケーション テクノロジーに完全に統合されており ソース デバイスは SRDF TimeFinder/Clone TimeFinder/Snap Open Replicator などのレプリケーションに関与できます ストレージ テクノロジーを使用してデータを移行するメリットは 使いやすく効率的 そして合理的であるという点です Symmetrix バックエンドでのデータ移行では SAN またはホストのリソースを必要としないため 効率性が向上します また ターゲットは独自の RAID 保護とストレージ階層を持つにもかかわらず 論理デバイスのもう 1 つの ミラー として内部的に処理されるため 安全に移行をできます 論理デバイスの元の ミラー は移行処理の最後に削除されます 最後に挙げるのは ソース デバイスの ID が変更されないため ストレージ間の移動が簡単で リモート / ローカル レプリケーションやバックアップなどのビジネスの運用管理においてさらなる変更を加える必要がないという点です symqos(symmetrix Quality of Service) コマンドを使用すると 移行のペースをコントロールできます 仮想 LUN 移行は ストレージ階層間でのデータベース全体 テーブルスペース パーティション ASM ディスク グループの移動など お客様がデータベースの ILM( 情報ライフサイクル管理 ) 戦略を実装するうえで役立ちます また サービス レベルやパフォーマンス要件をアプリケーション データに合わせて調整することも可能です たとえば パフォーマンス要件が明確になる前に アプリケーション ストレージがプロビジョニングされることはよくあります 後で要件についてよく理解したら 適切なストレージ階層を使用して ユーザー操作や ROI を向上させるよう簡単に調整することができます 図 3 は 20 個の 50 GB デバイス (ASM メンバー ) を備える ASM ディスク グループ +Sales の仮想 LUN 移行の例を示しています 移行ソース デバイスは 40 個の 300 GB ハード ディスク ドライブにわたって分散され RAID 1 で保護されています 移行ターゲット デバイスは 4 個の 400 GB EFD にわたって分散され RAID 5 で保護されています 40 x 300 GB 15k rpm (RAID 1) Ease of LUN migration for: ASM diskgroups Partitions Tablespaces Filesystems +Sales 20 x 50 GB ASM members 4 x 400 GB Enterprise Flash drives (RAID 5) 図 3: 仮想 LUN テクノロジーを使用した移行の例 高度なテクノロジー 10

11 仮想 LUN を使用するステップを次に示します このステップは 図 3 の例に基づいています 1. Optional: Verify information for a migration session called Sales_mig symmigrate -name Sales_mig file Sales_ASM.txt validate The file Sales_ASM.txt contains the list of source and target migration devices: C C13 2. Perform the migration symmigrate -name Sales_mig file Sales_ASM.txt establish 3. Follow the migration progress and rate at 60-second intervals symmigrate -name Sales_mig file Sales_ASM.txt query i Terminate the migration session after completion symmigrate -name Sales_mig file Sales_ASM.txt terminate 5. Optional: Control migration pace Create a Symmetrix DG with the source devices symdg create Sales_dg symld g Sales_dg range 0100:0113 addall Control the copy pace using the DG 仮想 LUN は ターゲット デバイスの構成済みまたは未構成のディスク領域を利用できます 未構成のディスク領域に移行するということは デバイスが移動して ターゲット ストレージ ディスク グループの使用可能な空きスペースを占有することを意味します 移行後は ソース デバイスの元のストレージ領域が未構成になります いずれの場合も ソース デバイスの ID は変わらず 移行はホストに対してシームレスに行われます DR バックアップ 高可用性構成の面では変更は必要ありません 構成済みのディスク領域を指定するとき ソース デバイスとターゲット デバイスは 基本的にストレージ特性をスワップするだけにすぎません ただし データがターゲット デバイスに移行した後 元のソース ドライブのストレージ領域が再フォーマットされ 元の領域に所属していたデータは公開されなくなります Enginuity 5874 を使用すると 論理デバイスとメタボリュームの移行がサポートされます ( メタヘッド ボリュームのみを指定する必要があります メタメンバーは自動的に選択されます ) 仮想 LUN 移行は シン デバイス ( シン プール デバイス ) 仮想デバイス ( セーブ プール デバイス ) VCM SFS ヴォールトなどの内部 Symmetrix デバイスの移行をサポートしていません 構成済みの領域への移行このオプションは ターゲット ディスク グループの大部分がすでに構成されている場合 ( このため 十分な空きスペースがない場合 ) に便利です また 移行が一時的なもので 後で同じターゲット デバイスに逆移行を行う場合にも役に立ちます この例としては 月次決算報告前の Flash ドライブ階層への SALES ASM ディスク グループの移行が挙げられます この方法では 再移行の際に ソース デバイスが再度以前のストレージ領域を占有するようになります 構成済み領域への移行時に ソース デバイスとターゲット デバイスの両方が指定されます ターゲット デバイスはソース デバイスとサイズが一致し 少なくともすべてのホストに対するマスクが解除されていなければなりません また オプションで Symmetrix FA ポートからのマップが解除されている必要があります こうした要件により 移行先のターゲット デバイスに現在アクティブな顧客データが含まれないようにします 同様に ターゲット デバイスは SRDF Clone Snap Open Replicator などその他すべての Symmetrix コピー操作の対象となるこ 高度なテクノロジー 11

12 とはできません 移行後 ターゲット デバイスは ソース デバイスの元のストレージの場所と保護を占有し 元のソース デバイスのストレージ領域は ターゲットによって古いデータが公開されないようフォーマットされます 未構成の領域への移行このオプションは ターゲット ストレージ ディスク グループに十分な空きスペースがある場合に便利です 未構成の領域に移行するときは ソース デバイスのみが指定されます 移行ターゲットについては ストレージ ディスク グループ番号が 新しい LUN の RAID 保護タイプとともに提供されます 移行完了時に古いソース LUN は未構成になっているため LUN を再フォーマットする必要がありません Symmetrix V-Max TimeFinder 製品ファミリ EMC TimeFinder ファミリのローカル レプリケーション テクノロジーを使用すると データベースおよびアプリケーションの 読み取り / 書き込み可能で無停止のストレージ ベース レプリカを複数作成できます これにより データ レプリケーションの速度 拡張性を向上させる ストレージを効率的に使用する アプリケーションに対する影響を最小限に抑える あるいはまったくなくすなど 顧客の幅広いニーズに対応します TimeFinder は 本番データベースおよびアプリケーションが複数の Symmetrix アレイにまたがる場合でも そのデータベースやアプリケーションのバックアップ 再起動 リカバリのソリューションを提供します TimeFinder は SRDF などの他の EMC 製品に適切に統合されており 同期または非同期レプリケーションを中断することなくリモート ターゲットにレプリカを作成できます リモート レプリカからのリストアが必要な場合 TimeFinder および SRDF は差分リストアを並行して行い 最大レベルの可用性と保護を実現します TimeFinder 製品ファミリは EMC のコンシステンシ テクノロジーを使用した整合性のとれた相互に依存する書き込みのレプリカ および Oracle のバックアップ / リカバリ操作で有効なレプリカの作成をサポートします これについては 以降の使用例で説明します TimeFinder/Clone と新しいカスケード クローン TimeFinder/Clone により ソース ボリューム全体の複数のコピーを作成 更新 またはリストアできます ここで 最初の完全な同期が完了した後 差分変更のみがソース デバイスとターゲット デバイス間で渡されます TimeFinder/Clone の操作では ソース デバイスとターゲット デバイスに対して STD(Standard) と BCV(Business Continuance Volume) を任意に組み合わせて使用でき 極めて高い柔軟性が実現します TimeFinder/Clone はエミュレーション モードで動作でき 従来の理由から TimeFinder/Mirror コマンド (symmir) をシミュレートしますが 新しいスクリプトを作成するときは ネイティブの TimeFinder/Clone コマンド シンタクス (symmclone) を使用することをお勧めします TimeFinder/Clone は何千ものデバイスに拡張でき 各ソース デバイスに対して最大 16 ターゲットを作成できます また ターゲット ボリュームを柔軟に同期させることも可能です たとえば クローン セッション ( レプリカ ) がアクティブ化される前 (precopy とも呼ぶ ) や クローン セッションがアクティブ化された後 (background copy とも呼ぶ ) に同期できます データがアクセスされたときにのみクローン デバイスを同期させる (no-copy とも呼ぶ ) ことも可能です これは たとえば 短期間のゴールド コピーで使用できます TimeFinder は バックグラウンドでコピー操作が進行中の場合でも コピーされた最終的なイメージを常にターゲット デバイス ( レプリカの作成時 ) またはソース デバイス ( レプリカのリストア時 ) に提供します これにより アプリケーションは即座に TimeFinder デバイスを使用できます たとえば TimeFinder が有効なデータベース バックアップ イメージをリストアしているときに Oracle は ロール フォワード リカバリを並行して開始し RTO を短縮します 高度なテクノロジー 12

13 カスケード クローンは Enginuity 5874 の新しい機能で 差分関係の特性を維持しながら クローン ターゲットで追加のクローン操作を 1 回行えるようにします これは 最初のクローンが 使用してはならないゴールド コピー ( たとえば バックアップ イメージ ) である場合に便利ですが 追加のレプリカがバックアップ レポート作成 発行 テスト / 開発などの目的から離れている必要があります これを行うオプションとして 複数の TimeFinder/Snap を使用する方法がありますが 完全なボリューム レプリカが必要なときは Enginuity 5874 から 追加クローンを作成して こうした目的で展開することもできます TimeFinder/Snap と新しい TimeFinder/Snap Recreate TimeFinder/Snap ソフトウェアを使用すると 読み取り / 書き込み可能な省ディスクスペース型の複数のデータ コピーを作成 更新 リストアできます TimeFinder/Snap により 各ソース デバイスのデータを 128 のターゲット デバイスにコピーできます ソース デバイスは STD デバイスまたは BCV のいずれかです ターゲット デバイスは Symmetrix VDEV( 仮想デバイス ) です この Symmetrix VDEV は 変更されたデータをトラッキングするポインタを使用し 物理ストレージをほとんど消費しません スナップ セッション開始後に行われたソース デバイスおよび / またはターゲット デバイスへの更新により 更新前のデータが セーブ デバイス プールと呼ばれる指定された共有ストレージ プールにバックグラウンドでコピーされます その後 仮想デバイスのポインタはその場所に更新されます 最初のデータ変更後に行われる更新では バックグラウンド コピーが不必要になります コピー操作はバックグラウンドで行われるため TimeFinder/Snap の使用に伴うパフォーマンス オーバーヘッドは最小限に抑えられます この処理は ACOFW(Avoid Copy on First Write) と呼ばれています TimeFinder/Snap Recreate は Enginuity 5874 の新機能です この機能を使用すると TimeFinder スナップショットを非常にすばやく更新できます 以前は 新しいスナップ セッションを開始するには 古いスナップ セッションを終了する必要がありました TimeFinder recreate コマンドでは ソース デバイスとターゲット デバイスの関係を再度記述する必要がないため 古いスナップを更新する処理が簡素化されます TimeFinder Consistent Split TimeFinderを使用すると ECA(Enginuity 整合性アシスト ) 機能を使用して 異なるプラットフォームにまたがるソース デバイスとターゲット デバイス間でConsistent Splitを実行できます Consistent Split( インスタント スプリットの実装 ) は データベースを停止せずにデータベース関連のデバイスが分割された場合に発生する可能性がある不整合とリスタートの問題を回避するのに役立ちます 通常のインスタント スプリットとConsistent Splitの違いは デバイスのグループでConsistent Splitを使用中 フォアグラウンドでスプリットが行われるときに データベースへの書き込みがストレージ レベルで一瞬だけ保留になり グループを構成するターゲット デバイスで相互に依存した書き込み順序の整合性が維持されるという点です フォアグラウンドでのインスタント スプリットはわずか数秒で完了するため Oracleをホット バックアップ モードにする必要があるのは この短い間だけです Consistent Splitのみを使用して再起動可能なレプリカを作成するとき ビジネス運用への介入を最小限に抑えられます Consistent Split 実行後の TimeFinder ターゲット デバイスの状態は 電源障害後 またはすべてのデータベース インスタンスが同時に中止された場合のデータベースの状態と同じです この状態は Oracle もよく認識しており 次回データベース インスタンスが開始されたときに クラッシュ リカバリによって簡単に復旧できます 高度なテクノロジー 13

14 TimeFinder と SRDF TimeFinder と SRDF の製品は密接に統合されています 実際 SRDF とリモート TimeFinder を併用し SRDF レプリケーションを中断することなく ターゲット ハードウェア リソースを利用するリモート コピーを作成できるようにすることを強くお勧めします また SRDF ターゲットを更新する必要がある場合はいつでも リモート コピーをゴールド コピーとして使用できます たとえば リモート TimeFinder/Clone を SRDF R2 デバイスから作成し そのクローンから テスト 開発 およびレポートのインスタンス用に追加のスナップを多数作成できます SRDF/A の使用時は すべてのリモート TimeFinder 操作で Consistent Split 機能を使用して SRDF/A サイクル切り替えに合わせてレプリカを調整する必要があります このホワイト ペーパーの使用例では TimeFinder と SRDF が同時に実行する基本的な Oracle ビジネス継続性操作をいくつか紹介します Symmetrix V-Max SRDF 製品ファミリ SRDF(Symmetrix Remote Data Facility) は Symmetrix ベースのビジネス継続性および災害後の業務再開ソリューションです 簡単に言うと SRDF は複数の Symmetrix ユニットの構成で その目的はホスト デバイスのリアルタイム コピーを複数の場所に保持することです Symmetrix ユニットは 同じ部屋 同じキャンパス内の異なる建物 数百マイル離れた場所に存在できます SRDF を使用すると 複数のホスト プラットフォーム オペレーティング システム アプリケーションにまたがってデータを移動したり災害後に業務を再開したりできます また SRDF は数千のデバイスに拡張できるほか 複数のソース アレイから複数のターゲット アレイへの書き込み順序の整合性を維持しながらレプリケートできます さまざまなトポロジーおよび構成をサポートすることもできます ソース (R1) デバイスと呼ばれているローカル SRDF デバイスとリモートのターゲット (R2) デバイスはペアの関係で構成され SRDF ペアを構成しています R2 デバイスが R1 デバイスでミラーリングされるとき R2 デバイスはリモート ホストに対して書込み禁止になります R2 デバイスは R1 デバイスと同期されたらいつでも分割でき ホストから完全にアクセスできるようになります R2 デバイスはホストが直接使用することも ( 分割後 ) R1 デバイスに差分リストアすることも TimeFinder とともに使用して追加のレプリカを作成することも可能です TimeFinder レプリカは SRDF のレプリケート中でも レプリケーションを中断することなく R2 デバイスから取得できます SRDF with Enginuity 5874 には SRDF/EDP(Extended Distance Protection) と呼ばれる保護モードなど 他にも新しいパフォーマンスおよび拡張性に関する機能が多数追加されています 詳細については SRDF の製品ガイドを参照してください SRDF 操作モード SRDF/S(SRDF/Synchronous) SRDF/A(SRDF/Asynchronous) SRDF アダプティブ コピーは SRDF の基本的な操作モードです 最初の 2 つは Oracle データベース保護に対して有効で これらのモードでは相互に依存した書き込み順序の整合性が維持されます 3 番目のモードはバルク データ転送に便利です また SRDF/AR(SRDF/Automated Replication) などのより複雑な SRDF ソリューションと組み合わせて利用できます SRDF/Synchronous モード SRDF/S は コミットされたトランザクションのデータ消失ゼロのソリューションを構築する際に使用します SRDF/S により ソース デバイスとターゲット デバイスのデータをまったく同じ状態に保ちながら 複数のデータベースとアプリケーションのデータをリモートでレプリケ 高度なテクノロジー 14

15 ートできます SRDF/S は 1 つまたは複数のソース Symmetrix ストレージ アレイを同期レプリケーションで保護できます 図 4 に示す SRDF/S 同期レプリケーションでは ローカル ホストからソース R1 デバイスへの各 I/O が最初にローカル Symmetrix キャッシュに書き込まれ (1) その後 SRDF リンクを介してリモート Symmetrix ユニットに送信されています (2) リモート Symmetrix ユニットが I/O を承認してキャッシュで正常に受け取ると (3) I/O は承認されローカル ホストに送信されます Synchronous モードでは リモート イメージがソース イメージの完全かつ正確な複製であることが保証されます Production Database RDF links 2 Source Target 図 4:SRDF/Synchronous レプリケーション 単一ラウンドトリップとコンカレント書き込み SRDF パフォーマンスの向上 Enginuity 5772 サービス リリースから SRDF/S により パフォーマンスを向上するための機能がいくつか追加されています 1 つ目の機能は 単一ラウンドトリップという機能です これにより 長距離間での書き込みレーテンシーが大きいときに SRDF/S レスポンス タイムが高速になります 以前は 実際のデータを送信する前に SRDF ターゲットにより転送 Ready 状態であることが求められていましたが 現在は 転送準備とデータ送信を並行して行うことができ 承認も 1 回で済みます 2 つ目の機能はコンカレント書き込みです この機能を使用すると I/O が別の FA ポートから送信された場合 SRDF/S はソース デバイスごとに最大 8 つの I/O を並行して送信できます これにより Oracle チェックポイント中や EMC PowerPath などのホストマルチパス ツールの使用時に SRDF/S はより高速に動作できます SRDF/Asynchronous レプリケーション モード SRDF/A(SRDF/Asynchronous) は ソース (R1) デバイスからほんのわずかの遅れで存在するターゲット (R2) デバイスで 整合性のとれたポイント イン タイム イメージを提供します SRDF/A を使用すると 無制限の距離にわたってレプリケーションを実行できます このとき ローカル本番データベースのパフォーマンスに対する影響は最小限に抑えられているか まったく影響がありません SRDF/A は ローカル Symmetrix キャッシュを使用し 保存しきれないデータをオプションでディスク プールに保存し (DSE( デルタ セット エクステンション ) とも呼ぶ ) リンクの帯域幅に関する要件を軽減することで ピーク時のワークロードを乗り切ります 図 5 に示すように SRDF/A セッション データは指定されたサイクルでリモート Symmetrix アレイに転送されます ( デルタ セットと呼ばれます ) ここでは 3 つのサイクルが一斉に動作しています 収集サイクルはホストからの新しい I/O すべてを受け取ります R1 および R2 の転送 / 受信サイクルはそれぞれ 収集したサイクルが完全に受信されるまで そのサイクルを送受信します 適用サイクルは 前に完全に受信したサイクルを R2 デバイスに適用します 高度なテクノロジー 15

16 SRDF/A サイクル切り替えプロセスは非常に効率的で拡張性もあります 収集サイクルでデータの一部が複数回更新されると データに対する最新の更新のみが一回だけ転送されます このプロセスは書き込みのための保持と呼ばれます また 各 I/O の書き込みの整合性を維持する必要がありません 代わりに 整合性はサイクル間で維持されます 何らかの理由でレプリケーションが停止した場合 必ず SRDF は完全に受信したサイクルを R2 デバイスに適用するか 最後の完了していないサイクルを破棄します これにより リモート R2 デバイスは 常に R1 デバイスから 1 または 2 サイクル遅れることになります デフォルトの最小サイクル時間は 30 秒ですが ワークロードのピーク時はこの時間を長くして 後からデフォルト値に戻すことが可能です Production Database Transmit Receive 1 2 Capture SRDF links Apply 3 R1 4 R2 移行元 Target 図 5:SRDF/Asynchronous レプリケーション SRDF/A 整合性の除外 Enginuity 5874 では セッション整合性を維持したまま SRDF/A セッションでデバイスを追加または削除し 操作を実行できるようになりました 追加するダイナミック SRDF デバイスには整合性の除外フラグが設定されます これにより 他のデバイスの整合性属性を妨げることなく そのダイナミック SRDF デバイスを同期できます そのデバイスが 2 つのサイクルで同期されたら フラグは自動的に削除されるため セッション整合性属性を適用できるようになります デバイスが中断されると 整合性の除外フラグは自動的に設定されます これにより SRDF セッションの整合性を維持したままデバイスを削除できます この柔軟な新しい機能により データベースの保護と可用性が向上します SRDF/A マルチ セッション コンシステンシ SRDF/S と同様 SRDF/A はサイクル間の書き込み順序の整合性を維持しながら 複数のソース アレイから複数のターゲット アレイにレプリケートできます 複数の Symmetrix アレイにわたる相互に依存する書き込みの整合性が必要なときに SRDF/A MSC( マルチ セッション コンシステンシ ) オプションが使用され SRDF 冗長ホスト デーモンを使用して アレイにわたってサイクル切り替えが調整されます デーモンは すべてのアレイの Ready 状態を待機し サイクル切り替えコマンドを送信し 適切かつ効率的な通信を維持します TimeFinder の Consistent Split と同様 SRDF/A MSC の使用時は サイクル切り替え中にすべてのアレイで書き込み I/O が同時に一瞬だけ保留になり 書き込み順序の整合性が保持されます SRDF アダプティブ コピー レプリケーション モード SRDF アダプティブ コピー レプリケーションは 長距離でのデータ共有と移行を容易にします ( 図 6 を参照 ) SRDF アダプティブ コピー レプリケーションでは プライマリ ボリュームとセカンダリ ボリュームの間に同期していない I/O を複数許容します 同期していない I/O の 高度なテクノロジー 16

17 最大数は最大スキュー値と呼ばれ SRDF 監視 / 管理ソフトウェアを使用して設定できます SRDF アダプティブ コピー レプリケーションの使用時は 書き込み I/O の順序の保持は試みられません Production Database RDF links 3 Source Target 図 6:SRDF アダプティブ コピー モード SRDF アダプティブ コピー レプリケーションは Oracle がサポートする SRDF/S または SRDF/A レプリケーションに変更する前の便利な中間ステップとして実行します また 大量データのポイント イン タイム長距離転送にも使用されます たとえば 両サイド間の接続が長い間切断され その間に大量の変更が蓄積されていると リンクを再開することでリンク トラフィックが急激に増える ( 通常の本番トラフィックによって生成された変更にバックログの変更が追加されることによって作成される ) ことがあります SRDF アダプティブ コピー レプリケーションを使用すると SRDF の優先度が低いキューを使用してインバリッド トラックのバックログが同期されます 一方 新しい書き込みはキャッシュにバッファされ ホスト アプリケーションに影響を及ぼすことなく 優先度が高い SRDF キューを使用して送信されます 変更のバックログが転送されるか 変更されたトラックの合計が指定した数に達すると SRDF/S または SRDF/A レプリケーション モードに変更され データベース保護が行われます SRDF アダプティブ コピー レプリケーションは Oracle データベースのデータベース再起動およびデータベース リカバリのソリューションではサポートされていません SRDF アダプティブ コピー レプリケーション自体を Oracle データベースの災害保護に使用すると リモート データベースが破損し使用できなくなります 高度なテクノロジー 17

18 SRDF トポロジー SRDF は 1 つの SRDF ソースおよびターゲット以外の多数のトポロジーで設定できます したがって SRDF は 高可用性および災害後の業務再開に関するさまざまなニーズに対応します たとえば 1 つのターゲットまたは 2 つのコンカレント ターゲットを使用したり 同期レプリケーションと非同期レプリケーションを組み合わせたりできるほか 長距離環境でデータ消失ゼロを実現する 3 サイト ソリューションなどを提供します 次のセクションでは SRDF で使用できる基本的なトポロジーについていくつか紹介します 1 コンカレント SRDF SRDF を使用すると 複数の SRDF リンクを使用して 1 つの R1 ソース デバイスを最大 2 つのターゲット デバイスに同時にレプリケートできます すべての SRDF リンクが Synchronous モードまたは Asynchronous モードのいずれかで動作できるか 1 つまたは複数のリンクがアダプティブ コピー モードを使用して そのリンク上の使用可能な帯域幅を効率的に利用できます このトポロジーにより 短距離および長距離での同時データ保護が可能です SRDF/S 移行元 SRDF/A Target Target 図 7: コンカレント SRDF カスケード SRDF SRDF では Symmetrix から Symmetrix へとデータが反映されるカスケード構成が可能です このように構成するには 最初の SRDF リンクが Synchronous モードで 次の SRDF リンクが Asynchronous またはアダプティブ コピー モードである必要があります このトポロジーでは 長距離でのリモート レプリケーションをさまざまな度合いの帯域幅を利用して行うことができます データ消失はゼロか あるとしても限られています ( 選択した SRDF モードと災害のタイプによって異なります ) 1 SRDF トポロジーの詳細については SRDF 製品ガイドを参照してください 高度なテクノロジー 18

19 SRDF/S SRDF/A Site A Site B Site C 図 8: カスケード SRDF SRDF/Extended Distance Protection SRDF は 現在のところ カスケード SRDF 構成で複数サイトのレプリケーションをサポートしています この機能は データ消失ゼロまたはそれに近い状態で 遠隔地におけるより効率的な 2 サイト DR ソリューションをサポートするように強化されています この構成では 中間サイトのストレージ キャッシュのみが 変更されたトラックの一時的なパススルー データ ストアとして使用されます その後 変更されたトラックは第 3 のサイトにコピーされます SRDF/S とアダプティブ コピーは プライマリ サイトとセカンダリ サイト間で許可されています SRDF/A とアダプティブ コピーは セカンダリ サイトと第 3 のサイト間で利用できます SRDF/S SRDF/A Production Site Pass-through Site Target 図 9:SRDF/Extended Distance Protection この構成の主な利点を次に示します ターゲット サイトで RPO ゼロを実現する新しい長距離レプリケーション ソリューション データ消失ゼロでターゲット サイトでの災害後の業務再開を実現する低コストの選択肢 SRDF/Star SRDF/Star は 2 サイトまたは 3 サイト保護トポロジーです このトポロジーでは ソース サイト A のデータが 2 つの他の Symmetrix システム ( サイト B とサイト C) に同時にレプリケートされます 1 つのターゲット サイト (B または C) が停止してもデータは保護されたままです サイト A( プライマリ サイト ) が停止した場合 顧客は SRDF/Star の情報に基づいて 起動するサイト ( サイト B かサイト C) を選択できます 正常に稼働している一方のサイトのストレージ データが最新の場合は 起動する正常に稼働中のサイトに変更が段階的に送信されます 保護とコンプライアンスの目的で 新しい DR サイトに対するリモート レプリケーションは直ち 高度なテクノロジー 19

20 に開始できます たとえば データベース操作がサイト C で再開されると まず サイト B からデータが送信されデータ消失ゼロのソリューションが構築されます その後 サイト B が新しい DR ターゲットになります SRDF/Star は柔軟性が高く モードとトポロジーを変更して 各災害シナリオで最大限の保護を実現できます 製品の詳細については SRDF 製品ガイドを参照してください SRDF/S サイト A SRDF/A Site B Site C 図 10:SRDF/Star TimeFinder と SRDF を利用してデータの整合性を実現 ECA(Enginuity 整合性アシスト )Consistent Split を使用した EMC TimeFinder および SRDF ソリューションでは 相互に依存した書き込み順序の整合性を持った ストレージ ベースのレプリカを作成できます レプリカを作成するときは レプリカに含まれるすべてのソース デバイスに対する書き込み I/O を一時的に保留にします すべての書き込みが保留になるため 相互に依存した書き込みは発生しません ( この書き込みは 保留になっている I/O が前に完了したことに依存するため ) たとえば Oracle がデータ ファイルへの書き込み ( チェックポイント ) を行うのは これらのデータの変更に対する REDO 書き込みが完全にログ ファイルに記録されてからです SRDF/S および SRDF/A モードでは 相互に依存する各 I/O をすべて同期させるか (SRDF/S モードの場合 ) 転送されたデータのサイクルを同期させることで (SRDF/A モードの場合 ) 相互に依存した書き込み順序の整合性が確保されます ソース サイト消失につながる実際の災害では リモート サイトでデータベースの再起動オペレーションを完了できます このとき リカバリを探してアプリケーション全体に正しい順番で適用したり 障害が発生する前の指定した時間にリカバリを適用したりすることによる遅延は発生しません 災害後の業務再開に関する利点のほかに SRDF では 高速で信頼性の高いレプリケーション テクノロジーにより災害復旧操作が大幅に強化され 使用例セクションに示すように Oracle のバックアップ操作の負荷をリモート サイトに分散し リストアされたデータを後でローカル サイトに戻します 高度なテクノロジー 20

21 ASM リバランシングとコンシステンシ テクノロジー ASM はシームレスな非割り込みメカニズムを提供し ディスク グループ ストレージを拡大および縮小します ASM は ディスクの追加または削除時にストライプ データの再分配 ( リバランシング ) を行います 2 このリバランス操作はデータベースがオンラインのときに行われ データベースに対して高い可用性を提供します リバランス操作の主な目的は ファイルのエクステント ワークロード データ保護をディスク グループ内のすべてのディスクに均等に分散することです Symmetrix アレイをストレージとして使用した場合 ASM では外部冗長性を使用してデータ保護を実現するのがベスト プラクティスであると見なされます そこで Symmetrix RAID 保護が RAID 1 RAID 5 または RAID 6 内部ディスク保護を提供するために使用されます ストレージ ベースのレプリカのスプリット操作はリバランシング プロセスに敏感であるため ディスク グループのデバイス メンバーがスプリットされるタイミングが少しでも異なっていると ASM ディスク グループに不整合が発生する可能性があります これらの不整合は スプリット操作中に ASM メタデータが変更されたことが原因で発生します 起動時に ASM が不整合を検出すると メタデータ ログを使用して ASM インスタンス リカバリが実行されます さらに Oracle は ストレージ ベースのレプリカをスプリットするときに不整合が発生しないようにするためのツールと処理ステップを提供します ただし これらの手順は EMC コンシステンシ テクノロジーによって簡素化および合理化できます EMC Consistent Split テクノロジーはデータベース I/O を中断して書き込み順序を保持するため このテクノロジーにも スプリット中の ASM メタデータ変更防止の副作用があります Consisntent Split を実行すると レプリケーション プロセス中の ASM メタデータの不整合が防止され 整合性を保持しないスプリットを実行中に ASM リバランスがアクティブの場合に 他の追加のステップまたは使用できないレプリカが排除されます 2 ディスク障害によってもリバランスがトリガーされますが この動作は ASM 障害グループに固 有です 高度なテクノロジー 21

22 TimeFinder および SRDF を利用してビジネス継続性ソリューションを実現 データベース ストレージ レイアウトとベスト プラクティス ASM および Solutions Enabler デバイス計画表 1 は 使用例で使われた RAC データベースおよび Symmetrix デバイス レイアウトの例を示しています デバイス (LUN) のサイズはすべて 50 GB で データベースの実際のサイズは約 400 GB です 表 1:ASM ディスク グループ および Symmetrix デバイスと複合グループ ASM ディスク グループ データベース デバイス リカバリ DG ( デバイス グループ ) +DATA 18 LUN x 50 GB DATA_DG +REDO 4 LUN x 50 GB REDO_DG +FRA 3 LUN x 50 GB FRA_DG リスタート DG( デバイス グループ ) DB_DG SRDF CG( コンシステンシ グループ ) ALL_CG データベース プライマリ デバイス (TimeFinder と SRDF ソース デバイス ) は Symmetrix RAID 1 保護を使用しています TimeFinder/Clone ターゲットは RAID 5 保護を使用して ストレージ使用率を向上させています SRDF ターゲット デバイスも RAID 1 を使用し プライマリ データベース デバイスと同じ保護レベルを確保しています ASM の一般的なベスト プラクティス 3 ASM は Symmetrix アレイ RAID 保護を利用するという EMC の推奨に従って外部冗長性 ( ソフトウェア ミラーリングなし ) を使用しています ASM は +REDO(REDO ログ ) +DATA( データ ファイル 制御ファイル 一時ファイル ) +FRA( アーカイブ フラッシュバック ログ ) の 3 つのディスク グループで設定されていました 通常 EMC では パフォーマンスを監視しバックアップの負荷を軽減するために データからログを分離することをお勧めしています SRDF の使用時 レプリケーション帯域幅が制限されている場合 一時ファイルは独自の +TEMP ディスク グループに移動できます データベースの再起動またはリカバリには一時ファイルは必要ないからです ただし これらの使用例では SRDF FC 帯域幅は問題ではなかったため 一時ファイルは +DATA ディスク グループに含まれていました 最後に +FRA は一般的に SATA ドライブなどの低コスト ストレージ階層を使用できるため 独自のディスク グループが必要です TimeFinder のベスト プラクティス 複数の Symmetrix デバイス グループが TimeFinder/Clone( またはスナップ ) 操作で使用され より細かなレベルで操作を行うことができます リカバリ ソリューションについては データ ファイル ( および制御ファイル ) ログ ファイル アーカイブ ログそれぞれに独自の DG があり それぞれのレプリカをわずかに異なるタイミングで作成できます たとえば 有効なデータ ファイルのバックアップ レプリカを本番環境にリストアする必要があり 本番ログはそのままの状態にする場合は データ ファイ 3 これらのASMベスト プラクティスは 他のボリューム マネージャ ファイルシステム rawデバイスに簡単に適用できます 高度なテクノロジー 22

23 ルとログをそれぞれ独自の DG と ASM ディスク グループに切り離し このリストアによってログが危険にさらされることのないようにします また これにより データベースのフル リカバリが可能になります 業務再開ソリューションについては すべてのデータ ( 制御 ) ファイルとログ ファイルが含まれる 1 つの DG が使用され 整合性を維持しながらこれらのファイルをスプリットし 再起動可能な整合性のとれたレプリカを作成できます TimeFinder 操作は複数の Symmetrix アレイにまたがることができます DG( デバイス グループ ) の代わりに CG( 複合グループ ) を使用する必要があるときは このホワイト ペーパーで紹介するベスト プラクティスを実行してください TimeFinder および SRDF コマンドは データベース本番ホストではなく管理 ( またはターゲット ) ホストから発行することをお勧めします まれですが Consistent Split を使用しているときに大量のライト アクティビティが発生すると Symmetrix 管理コマンドがデータベース書き込みの後ろにキューイングされることがあり レプリケーションの完了を妨げ レプリカが無効であると見なされるからです Symmetrix GNS(Generic Name Services) を使用し それを SRDF ターゲットにレプリケートできるようにすることをお勧めします GNS は アレイ内のすべての DG および CG 定義を管理し その定義を SRDF ターゲットにレプリケートします これにより 管理ホストが発行する TimeFinder および SRDF コマンドは同じ CG および DG 上でソースとして動作できるようになります ( 定義を再作成する必要はありません ) 便宜上 使用例では GNS が使用され リモートでレプリケートされているものとします リモート TimeFinder または SRDF 操作は 使用中はターゲット ホストで発行されます リモート TimeFinder および SRDF コマンドを rdf フラグを使用してローカル管理ホストから発行することも可能です ただし それには SRDF リンクが機能している必要があります SRDF/A からリモートで TimeFinder レプリカを作成するときは必ず consistent フラグを使用して SRDF/A サイクル切り替えを TimeFinder 操作に合わせて調整します 簡単に言うと レプリカの整合性を保証するということです SRDF のベスト プラクティス SRDF は 同期または非同期にかかわらず 整合性が有効になっている CG( 複合グループ ) を常に使用する必要があります (CG はコンシステンシ グループとも呼ぶ ) SRDF/A では整合性を必ず有効にする必要がありますが 同期レプリケーションである SRDF/S については 整合性を有効にしても何のメリットもないと誤解されがちです しかし SRDF/S で整合性が有効になっていれば 1 つでもターゲットにレプリケートできないソース デバイスがあると そのセッションのすべての SRDF デバイスがレプリケートを停止し ターゲットのコンシステント イメージが保持されます SRDF レプリケーションでは すべてのデータベース デバイス ( データ ファイル 制御ファイル ログ ファイル ) が含まれる 1 つの CG が使用されていました 表 1 に示すように これには FRA デバイスも含まれています SRDF 自体が業務再開ソリューションで データベース クラッシュのリカバリはアーカイブ ログを使用しないため SRDF レプリケーションには FRA を含める必要がありません しかし これを含めるには 2 つの理由があるからです 1 つ目は ターゲットでフラッシュバック データベースの機能が必要な場合があるからです 同じコンシステンシ グループの FRA( およびフラッシュバック ログ ) を残りのデータベースと一緒にレプリケートすると フラッシュバック機能をターゲット上で利用できます 2 つ目は バックアップ イメージの負荷をリモートで軽減するのにアーカイブ ログが必要であるという理由です ( 使用例 6 を参照 ) 高度なテクノロジー 23

24 SRDF ターゲットではローリング災害からのゴールド コピー保護としてクローン コピーを利用できるようにしておくことを常に推奨しています ローリング災害とは 通常のレプリケーション アクティビティが最初に中断された後 ソース上のセカンダリ データベースの障害が発生し すぐに利用できる有効なレプリカがデータベースに存在しなくなることを表す用語です たとえば SRDF レプリケーションが何らかの理由で ( 計画的または予期せずに ) しばらく中断され ソース上に変更が蓄積されたとします この状態で同期が再開されると ターゲットは 同期されるか (SRDF/S) 整合性がとれる (SRDF/A) まで 有効なデータベース イメージではなくなります この理由から このような再同期を行う前には TimeFinder ゴールド コピー レプリカをターゲット サイトに配置しておくことをお勧めします これにより データベースの最後の有効なイメージが ローリング災害からの保護として保持されます ソース データベースがクラスタ化されている場合 Oracle RAC は共有ストレージ アーキテクチャに基づいているため すべてのデータベース コンポーネント ( データ ファイル ログ ファイル 制御ファイル ) をレプリケートすることで ターゲット データベースをクラスタ モードまたは非クラスタ モードで開始できます どちらを選択しても クラスタ レイヤー ( 投票ディスクまたはクラスタ構成デバイス ) はレプリケートしないようにすることをお勧めします これにはローカル ホストとサブネットに関する情報が含まれているからです ターゲット ホストでクラスタ レイヤーを必要とする場合は ターゲット ホスト名とサブネットに基づいて前もって構成し 必要に応じていつでもデータベースを起動できるようにしておきます 使用例 1: 本番環境でのデータベース バックアップの負荷を軽減する この使用例は データベース バックアップの負荷を本番環境からローカルの TimeFinder/Clone に移動して軽減し Oracle RMAN を使用してさらにバックアップを行う方法を示しています 本番ホストで Oracle データベースがホット バックアップ モードになっている間に TimeFinder/Clone のアクティブ化が実行され データベースのリカバリ可能なレプリカが作成されます これは Oracle データベースの迅速なリカバリを実行する際に使用できる有効なバックアップ イメージです このイメージは RMAN バックアップを行うために他のホストにマウントすることもできます ステップの概要 1. データベースをホット バックアップ モードにします 2. DATA_DG クローンをアクティブ化します (ASM が使用されているため consistent を使用 ) 3. ホット バックアップ モードを終了します 4. 現在のログをアーカイブします 5. 2 つのバックアップ制御ファイルを FRA ASM ディスク グループにコピーします 6. ARCHIVE_DGクローンをアクティブ化します (ASMが使用されているため consistentを使用 ) 7. ( オプション ) クローン デバイスをバックアップ ホストにマウントし RMAN バックアップを実行します 使用するデバイス グループ DATA_DG および ARCH_DG 高度なテクノロジー 24

25 ステップの詳細 本番ホストでのステップ 1. 本番データベースをホット バックアップ モードにします # export ORACLE_SID=RACDB1 # sqlplus / as sysdba SQL> alter database begin backup; 2. TimeFinder/Clone DATA_DG レプリカをアクティブ化します クローン レプリカにはデータ ファイルと制御ファイルが含まれます ASM またはファイルシステムで consistent を使用します # symclone dg DATA_DG tgt -consistent activate 3. ホット バックアップ モードを終了します SQL> alter database end backup; 4. ログを切り換えて 現在のログ ファイルをアーカイブします SQL> alter system archive log current; 5. 2 つのバックアップ制御ファイルを作成し 便宜上 そのファイルを FRA ディスク グループに置きます (SQL も使用できますが RMAN 構文が表示されます ) 1 つはデータベースのマウントで使用し RMAN バックアップを行います もう 1 つはバックアップ セットと一緒に保存されます RMAN>run { allocate channel ctl_file type disk; copy current controlfile to +FRA/control_file/control_start ; copy current controlfile to +FRA/control_file/control_bakup ; release channel ctl_file; } 6. TimeFinder/Clone ARCHIVE_DG レプリカをアクティブ化します クローン レプリカにはアーカイブ ログとバックアップ制御ファイルが含まれます ASM またはファイルシステムで consistent を使用します RMAN カタログが使用されている場合は まずそのカタログを同期して 最新のアーカイブ ログを登録します RMAN>resync catalog; # symclone g ARCH_DG tgt consistent activate バックアップ ホストでのステップデータベース レプリカは 有効なディスク バックアップ またはテープやディスク ライブラリなどの第 3 のメディアへのバックアップのソースとして使用できます この例では RMAN を使用してバックアップを行います 高度なテクノロジー 25

26 ターゲット / バックアップ ホストの前提条件 : クローン ボリューム上の ASM デバイス ( またはパーティション ) に適切な Oracle 権限が必要です ASM インスタンスの init.ora ファイルの ASM_DISKSTRING パラメータにクローン ボリュームへのパスが含まれている必要があります ASM インスタンスの init.ora ファイルの ASM_DISKGROUPS パラメータに本番データベース ディスク グループの名前が含まれている必要があります データベースが RAC としてマウントされている必要はありません データベースをマウントする前に 必要に応じて ASM とデータベース インスタンスの init.ora 内のパラメータを更新します クラスタ モードが必要ない場合は CLUSTER_DATABASE を false に変更します データベースをクラスタ モードで開始する場合は クラスタ レイヤー ( およびソフトウェア ) が (TimeFinder または SRDF でレプリケートされているのではなく ) ターゲット ホストにすでにインストールおよび構成されている必要があります 7. ( 前のページからのステップ 6 からの続き )ASM インスタンスを開始します 他のボリューム マネージャまたはファイルシステムが使用されている場合は そのボリューム マネージャまたはファイルシステム用のインポートおよびマウント コマンドを使用します すべてのディスク グループが ASM によって正しくマウントされたことを確認します # export ORACLE_SID=+ASM # sqlplus / as sysdba SQL> startup 8. データベース インスタンスをマウントします ホット バックアップ モードによるデータベース バックアップは 読み書き可能で開かなれていない場合にのみ (resetlogs オプションを使用 ) リカバリで有効です この理由から データベース バックアップはマウントのみを行う必要があります これは RMAN バックアップに最低限に必要な前提条件です データ ファイルのあいまいさを解決できるだけのアーカイブ ログが適用されたら読み取り専用モードで開くこともできます データベースをマウント モードで開始する前に init.ora ファイルの CONTROL_FILES を変更し バックアップ制御ファイルを指すように指定します control_files = +FRA/control_file/control_start # export ORACLE_SID=CLONE_DB # sqlplus / as sysdba SQL> startup mount 9. RMAN を使用してバックアップ ホストからデータベースをバックアップします インスタンス (control_bak) のマウントに使用されなかった制御ファイル コピーは バックアップ セットの一部である必要があります control_start ファイルはバックアップしてはいけません これは データベースがバックアップ用にマウントされるときに SCN が更新されるからです RMAN>run {allocate channel t1 type disk; backup format ctl%d%s%p%t controlfilecopy +FRA/control_file/control_bak ; backup full format db%d%s%p%t database; backup format al%d%s%p%t archivelog all; release channel t1; } 高度なテクノロジー 26

27 注意 : フォーマット指定子 %d は日付 %t は 4 バイトのタイムスタンプ %s はバックアップ セット番号 %p はバックアップ番号を示します 高度なテクノロジー 27

28 使用例 2: データベースの並行リカバリ この使用例は ローカル TimeFinder バックアップ レプリカをリストアしてログを適用することで TimeFinder リストアがバックグラウンドで実行されていても データベースの並行リカバリを実行できるようにする方法を示しています 使用例 1 で作成されたクローン コピーを使用して 本番データベースのデータベース リカバリを実行できます データベース リカバリ操作は TimeFinder/Clone リストア操作が始まるとすぐに開始できます これにより 第 3 の宛先メディアからのバックアップ イメージの初期リストアが必要な通常のソリューションに比べると RTO が大幅に短縮されます また 一度だけでも完全にリストアされたら データベース リカバリ操作を開始できます リカバリは 本番ホストで使用可能なアーカイブ ログ または TimeFinder/Clone イメージからリストアされたアーカイブ ログを使用して実行できます この例では 本番環境でリカバリが行われ かつオンライン REDO ログを含むアーカイブ ログを使用できる場合に フル メディア リカバリ ( データ消失ゼロ ) を実行できます 本番ログ ( または一部のアーカイブ ログ ) が使用できる場合は データベースの不完全メディア リカバリを実行できます ステップの概要 1. 本番データベースと ASM インスタンスをシャットダウンします 2. DATA_DG クローンをリストアします ( 後でスプリットします ) 3. ASM を開始します 4. データベースをマウントします 5. データベース リカバリを実行し データベースを開きます 使用するデバイス グループ DATA_DG ステップの詳細本番ホストでのステップ 1. 本番データベースと ASM インスタンスをシャットダウンします ( 実行中の場合 ) # export ORACLE_SID=RACDB1 # sqlplus / as sysdba SQL> shutdown abort # export ORACLE_SID=+ASM1 # sqlplus / as sysdba SQL> shutdown abort 2. TimeFinder/Clone レプリカをリストアします ソース デバイスが リモート R2 デバイスとのアクティブな SRDF セッションの一部でもある場合は force が必要です この場合 本番アーカイブ ログと REDO ログが使用できると思われるため ( データ ファイルと制御ファイルが含まれる )DATA_DG がリストアされます リストアが開始するとすぐに 次のステップに進むことができます ただし 後で バックグラウンドのリストアの完了時に必ずクローン レプリカをスプリットしてください TimeFinder リストアにより ソース デバイスへの変更からレプリカが保護されます # symclone dg DATA_DG tgt restore [ force] 高度なテクノロジー 28

29 # symclone dg DATA_DG tgt split 3. ASM インスタンスを開始します ( 使用例 1 のステップ 7 と同じ操作を行います ) 4. データベースをマウントします ( 使用例 1 のステップ 8 と同じ操作を行います ) 5. 本番データベースを復旧し 開きます 不完全リカバリが行われた場合は resetlogs を使用します # export ORACLE_SID=RACDB1v # sqlplus / as sysdba SQL> startup mount SQL> recover automatic database using backup controlfile until cancel; SQL> alter database open; 使用例 3: 本番環境の再起動可能なローカル レプリカ この使用例は データベースを他の目的 ( テストの作成 開発 コピーのレポートなど ) で利用するために 本番環境の再起動可能なローカル クローン ( またはスナップ ) を作成する方法を示しています 本番ホストで Oracle データベースがトランザクションを実行している間に ホット バックアップ モードを使用せずに コンシステント TimeFinder/Clone セッションをアクティブ化して 再起動可能なデータベースのレプリカを作成します このレプリカは テスト 開発 レポート作成などの目的で他のホストにマウントできます 同じデータベースの複数のレプリカを同じホストにマウントすることもできますが これについては このホワイト ペーパーでは説明しません ステップの概要 1. DB_DG クローンをアクティブ化します ( consistent を使用して再起動可能なレプリカを作成 ) 2. ASM インスタンスを開始します 3. データベース インスタンスを開始します 4. ( オプション ) 後で本番環境からクローン レプリカを更新します 使用するデバイス グループ DB_DG ステップの詳細ターゲット ホストでのステップ 1. TimeFinder/Clone DB_DG レプリカをアクティブ化します クローン レプリカには すべてのデータ ファイル 制御ファイル ログ ファイルが含まれます consistent を使用して 相互に依存する書き込みの整合性がレプリカで確実に維持されるようにします これにより 再起動可能で有効な状態が確保され Oracle はこのレプリカからクラッシュ リカバリを行うことができます # symclone dg DB_DG tgt consistent activate 注意 : 使用例 1 のステップ 7 の前に記載されているターゲット ホストの前提条件と同じ条件に従ってください 高度なテクノロジー 29

30 2. ASM インスタンスを開始します ( 他のボリューム マネージャまたはファイルシステムが使用されている場合は インポート / マウントを実行します ) すべてのディスク グループが ASM によって正しくマウントされたことを確認します # export ORACLE_SID=+ASM # sqlplus / as sysdba SQL> startup 3. データベース インスタンスを開始します リカバリ ログまたはアーカイブ ログは必要ありません # export ORACLE_SID=CLONE_DB # sqlplus / as sysdba SQL> startup この時点で クローン データベースが開き ユーザー接続で使用できます 4. ( オプション )TimeFinder レプリカは本番環境からすばやく簡単に更新できます TimeFinder/Clone の操作は クローン セッションが終了しない限り段階的に行われるからです クローン セッションが再アクティブ化されたら バックグラウンド コピーが行われていても すぐにターゲット デバイスが使用可能になります 4.1. クローン データベース インスタンスは更新する必要があります したがって ここでシャットダウンします SQL> shutdown abort 4.2. 本番環境から TimeFinder/Clone レプリカを再作成し アクティブ化します これにより バックグラウンド コピー操作が開始されます # symclone dg DB_DG tgt recreate # symclone dg DB_DG tgt activate -consistent 4.3. ステップ 2 と 3 を繰り返して クローン ASM とデータベース インスタンスを開始します 使用例 4: 災害保護のためのリモート ミラーリング ( 同期および非同期 ) この使用例は SRDF/S または SRDF/A を使用して災害保護を行うために本番データベースのリモート ミラーを作成する方法を示しています ステップの概要 1. アダプティブ コピー モードで SRDF の初期同期を実行します 2. SRDF ターゲットがソースに十分に近づいたら レプリケーション モードを SRDF/S または SRDF/A に変更します 3. SRDF の整合性を有効にします 使用するデバイス グループ ALL_CG 高度なテクノロジー 30

31 ステップの詳細 1. アダプティブ コピー モードで SRDF の初期同期を実行します SRDF ターゲットがソースに十分に近づくまで このステップを繰り返すかスキュー パラメータを使用します # symrdf cg ALL_CG set mode acp_wp skew <number>] # symrdf cg ALL_CG establish 2. SRDF ターゲットがソースに十分に近づいたら レプリケーション モードを SRDF/S または SRDF/A に変更します 2.1. SRDF/S の場合は 保護モードを sync に設定します # symrdf cg ALL_CG set mode sync 2.2. SRDF/A の場合は 保護モードを async に設定します # symrdf cg ALL_CG set mode async 3. コピーがアクティブではない場合は SRDF レプリケーションを構築し 整合性を有効にします # symrdf cg ALL_CG enable # symrdf cg ALL_CG establish [ full] # symrdf cg ALL_CG verify synchronized -i 60 高度なテクノロジー 31

32 使用例 5: 他の目的で使用するための再起動可能なリモート データベース レプリカ この使用例は SRDF 保護を中断せずにデータベースを他の目的で使用するために 本番環境の再起動可能なリモート クローン ( またはスナップ 4 ) を作成する方法を示しています 同期されたら いつでも SRDF/S または SRDF/A セッションをスプリットし R2 ターゲット デバイスに基づいて 整合性のとれた相互に依存する書き込みのリモート レプリカを作成できます その時点で SRDF はソース デバイスとターゲット デバイスの両方で変更を追跡します そして これらの変更のみが 次回 SRDF が同期されたとき ( ターゲット デバイスを更新 ) またはリストアされたとき ( ソース デバイスを更新 ) にコピーされます ただし SRDF はリモート レプリケーションおよび保護を維持するために同期し続けること そして 代わりにクローンやスナップなどのリモート TimeFinder レプリカをアクティブ化することをお勧めします ( 現在のところは SRDF/S でのみサポートされています ) また リモート クローンから追加のスナップショットを作成することも可能です これらのデータベースのレプリカは 整合性のとれた相互に依存する書き込みで テスト 開発 レポート作成 データ処理 発行などのアクティビティで使用できます また SRDF のベスト プラクティスのセクションで説明したように ローリング災害からのゴールド コピー保護として使用することも可能です ステップの概要 1. リモートDB_DGクローンをアクティブ化します ( consistentを使用して 再起動可能なレプリカを作成 ) 2. リモートASMインスタンスを開始します 3. リモート データベース インスタンスを開始します 4. ( オプション ) 後で本番環境 (SRDFターゲット) からリモート クローン レプリカを更新します 使用するデバイス グループ DB_DG ステップの詳細ターゲット ホストでのステップ 1. TimeFinder/Clone DB_DGリモート レプリカをアクティブ化します クローン レプリカには すべてのデータ ファイル 制御ファイル ログ ファイルが含まれます consistentを使用して 相互に依存する書き込みの整合性がレプリカで確実に維持されるようにします これにより 再起動可能で有効な状態が確保され Oracleはこのレプリカからクラッシュのリカバリを行うことができます # symclone dg DB_DG tgt consistent activate 注意 : 使用例 1 のステップ 7 の前に記載されているターゲット ホストの前提条件と同じ条件に従ってください 4 Enginuity 5874 では TimeFinder/Snap は 同期された SRDF/A ターゲットからサポートされていません 一般的には R2 のクローンを使用するか そのクローンから複数の書き込み可能なスナップショットを作成することが推奨されます 高度なテクノロジー 32

33 2. ASM インスタンスを開始します 使用例 3 のステップ 2 と同じ操作を行います 3. データベース インスタンスを開始します 使用例 3 のステップ 3 と同じ操作を行います この時点で クローン データベースが開き ユーザー接続で使用できます 4. ( オプション ) データベース クローンを更新するには 使用例 3 のステップ 4 と同じ操作を行います 高度なテクノロジー 33

34 使用例 6: リモート データベースの有効なバックアップ レプリカ この使用例は 有効な Oracle バックアップ イメージであるリモート データベース クローンを作成する方法を示しています このクローンは データベース リカバリに使用できます データベース リカバリで有効な TimeFinder リモート レプリカを作成すると リモート サイトで第 3 のメディアへのバックアップを実行できます また TimeFinder レプリカ自体がディスクへの有効なバックアップで これを使用して 必要に応じて本番環境を復旧できます SRDF/A に関する注意事項 :SRDF checkpoint コマンドが制御をユーザーに戻すのは ソース デバイスのコンテンツが SRDF ターゲット デバイスに到達してからです (SRDF は 2 つのデルタ セットを待つだけです ) これは たとえば 本番環境がホット バックアップ モードになってから リモート クローンが取得される場合に便利です ステップの概要 1. データベースをホット バックアップ モードにします 2. SRDF/Aを使用している場合は SRDF checkpointを実行します (SRDF/Sを使用している場合 操作を行う必要はありません ) 3. リモートDATA_DGクローンをアクティブ化します (SRDF/AまたはASMを使用している場合は consistentを使用) 4. ホット バックアップ モードを終了します 5. 現在のログをアーカイブします 6. 2 つのバックアップ制御ファイルを FRA ASM ディスク グループにコピーします 7. SRDF/Aを使用している場合は SRDF checkpointを実行します (SRDF/Sを使用している場合 操作を行う必要はありません ) 8. リモートARCHIVE_DGクローンをアクティブ化します (SRDF/AまたはASMを使用している場合は consistentを使用) 9. ( オプション ) リモート クローン デバイスをバックアップ ホストにマウントし RMANバックアップを実行します 使用するデバイス グループ TimeFinder 操作の場合は DATA_DG と ARCH_DG SRDF 操作の場合は ALL_CG ステップの詳細本番ホストでのステップ 1. 本番環境をホット バックアップ モードにします 使用例 1 のステップ 1 と同じ操作を行います 2. SRDF/A を使用している場合は SRDF checkpoint コマンドによって バックアップ モードでデータ ファイルが SRDF ターゲットにあることも確認します # symrdf cg ALL_CG checkpoint 3. リモート DATA_DG クローンをアクティブ化します SRDF/A または ASM を使用している場合は consistent を使用します 使用例 1 のステップ 2 と同じ操作を行います 4. ホット バックアップ モードを終了します 使用例 1 のステップ 3 と同じ操作を行います 高度なテクノロジー 34

35 5. ログを切り換えて 現在のログ ファイルをアーカイブします 使用例 1 のステップ 4 と同じ操作を行います 6. 2 つのバックアップ制御ファイルを作成し 便宜上 FRA ディスク グループに置きます 使用例 1 のステップ 5 と同じ操作を行います 7. SRDF/A を使用している場合は SRDF checkpoint コマンドによって ターゲットで ( 前回のアーカイブとバックアップ制御ファイルが含まれる )FRA ディスク グループが SRDF ターゲットにあることを確認します # symrdf cg ALL_CG checkpoint 8. リモート TimeFinder/Clone ARCHIVE_DG レプリカをアクティブ化します 使用例 1 のステップ 6 と同じ操作を行います 9. ( オプション ) リモート クローン デバイスをバックアップ ホストにマウントし RMAN バックアップを実行します 使用例 1 の バックアップ ホストでのステップ と同じ操作を行います 使用例 7: リモート バックアップ レプリカからのデータベースの並行リカバリ この使用例は TimeFinder/Clone バックアップ イメージを SRDF リストアと同時にリストアし 並行して Oracle ログを本番データベースに適用することで 本番データベースの並行リカバリを行う方法を示しています これは使用例 2 と似ていますが リモート レプリカからのリカバリのみが行われます ステップの概要 1. 本番データベースと ASM インスタンスをシャットダウンします 2. リモート DATA_DG クローンをリストアします ( 後でスプリットします ) 並行して SRDF をリストアします 3. ASM を開始します 4. データベースをマウントします 5. データベース リカバリを実行し (TimeFinder と SRDF リストアは実行中の可能性があります ) データベースを開きます 使用するデバイス グループ DATA_DG SRDF 操作の場合は ALL_CG ステップの詳細 本番ホストでのステップ 1. 本番データベースと ASM インスタンスをシャットダウンします ( 実行中の場合 ) 使用例 2 のステップ 1 と同じ操作を行います 2. リモート TimeFinder/Clone レプリカを SRDF ターゲット デバイスにリストアしてから SRDF をリストアします ソースからターゲットへの SRDF のレプリケーションが実行中の場合は 最初にそのレプリケーションを停止します そして TimeFinder リストアを開始します TimeFinder リストアを開始したら 並行して SRDF リストアを開始します 場合によっては ソースとターゲット間の距離が長かったり 帯域幅が制限されていたり 高度なテクノロジー 35

36 リストアしなければならない変更が多かったりすることがあります このような場合 違いが少ない間に まずSRDFモードをアダプティブ コピーに変更し その後でSRDF/Sまたは SRDF/Aモードに戻すことをお勧めします # symrdf cg ALL_CG split # symclone dg DATA_DG tgt restore [ force] # symrdf cg ALL_CG restore SRDF リストアが完了していなくても 次のステップに進むことができます 3. 本番ホストで ASM を開始します 使用例 1 のステップ 7 と同じ操作を行います 4. データベースをマウントします 使用例 1 のステップ 8 と同じ操作を行います 5. 本番データベースを復旧し 開きます 使用例 2 のステップ 5 と同じ操作を行います 高度なテクノロジー 36

37 使用例 8: 再起動可能なレプリカからのデータベースの高速リカバリ この使用例では 最新の整合性のとれた ( 再起動可能な ) レプリカを使用して そのレプリカにログを適用することで データベースの高速リカバリを行っています Oracle は SRDF または TimeFinder を使用して作成された 整合性のとれた相互に依存する書き込みのストレージ レプリカに基づいたさまざまなデータベース リカバリ シナリオをサポートしています Oracle サポートは Metalink の注記 ID に記載されています この使用例の目的は 夜間バックアップなど ホット バックアップ モードに基づいたバックアップ戦略の代わりとなる手段を紹介することではありません これは補完的な使用例であり たとえば RTO 要件が非常に厳しい場合に適用できます また archivelog モードでデータベースを実行する強力なソリューションにもなり データベースをホット バックアップ モードにすることなく スナップショットが定期的に実行されます リカバリが必要な場合は 前回のスナップショットがリストアされ そのスナップショットが取得された制限付きトランザクションが並行してリストアされます これにより データベースの高速リカバリ ソリューションが実現します 次のシナリオについて考えます データベースはアーカイブ ログ モードです また データのみが含まれる TimeFinder コンシステント クローンまたはスナップが定期的に作成されます そして ある時点で 前回のレプリカ ( この例ではクローン ) に基づいてデータベース リカバリが必要になります ステップの概要 1. 本番データベースと ASM インスタンスをシャットダウンします 2. 最新の DATA_DG クローンをリストアします ( 後でスプリットします ) 3. ASM を開始します 4. データベースをマウントします 5. データベースのフル リカバリまたは不完全リカバリを実行します (TimeFinder リストアはバックグラウンドで実行中の可能性があります ) 使用するデバイス グループ DATA_DG ステップの詳細 1. 本番データベースと ASM インスタンスをシャットダウンします ( 実行中の場合 ) 使用例 2 のステップ 1 と同じ操作を行います 2. 最新の DATA_DG TimeFinder レプリカをリストアします 使用例 2 のステップ 2 と同じ操作を行います 3. ASM インスタンスを開始します ( 使用例 1 のステップ 7 と同じ操作を行います ) 4. データベースをマウントします ( 使用例 1 のステップ 8 と同じ操作を行います ) 5. 次のオプションのいずれかに基づいてデータベース リカバリを行います 高度なテクノロジー 37

38 奨 ): データベースのフル ( 完全 ) リカバリオンライン REDO ログとアーカイブ ログが利用できる場合 Oracle データベースのフル メディア リカバリを実行し コミットされたトランザクションのデータ消失ゼロを実現できます SQL> recover automatic database; SQL> alter database open; 注意 : リカバリ プロセスでオンライン REDO ログまたはアーカイブ ログの場所を自動的に特定できなかった場合は ログの場所を指定しなければならないことがあります (( 複数のオンライン ログ場所またはアーカイブ ログの場所を備える RAC 実装でも同じ ) ) その目的は必要なアーカイブ ログとオンライン ログを完全にアーカイブすることです データベースのポイント イン タイム リカバリフル メディア リカバリを行いたくない場合やアーカイブ ログまたはオンライン ログが存在しない場合は 不完全リカバリを実行できます 不完全リカバリを実行する場合は データ ファイルのあいまいさが最大になるポイントを渡せるだけのログを適用し 整合性を確保する必要があります そのポイントを渡したら 追加のアーカイブを適用できます 次のスクリプトの例は 前述した Oracle Metalink の注記に基づいており データベースを開くのに最低限必要な SCN を特定するのに役立ちます ただし データ ファイルのスキャンには時間がかかり これは高速リカバリと RTO 短縮の目的からははずれます したがって このスクリプトを実行するかどうかはオプションです 代わりに 次の 2 つの理由でリカバリのみを行うことをお勧めします 1 つ目の理由は データ ファイルと制御ファイルを持つ TimeFinder レプリカは必要に応じて再度リストアできるように必要があり そのリストアによって破損することがあってはいけません 2 つ目は レプリカは Consistent Split で取得されているため データ ファイルのあいまいさのポイントがスプリット時を超えることはできません ( 古くなるだけです ) したがって このレプリカがスプリット時を超えて復旧することでデータ ファイル内のあいまいさが最大になるポイントが渡されるため これで十分であることは明らかです オプションのデータ ファイル スキャン スクリプト (RTO が重要な場合は非推 spool scandatafile.out set serveroutput on declare scn number(12) := 0; scnmax number(12) := 0; begin for f in (select * from v$datafile) loop scn := dbms_backup_restore.scandatafile(f.file#); dbms_output.put_line('file ' f.file# ' absolute fuzzy scn = ' scn); if scn > scnmax then scnmax := scn; end if; end loop; dbms_output.put_line('minimum PITR SCN = ' scnmax); end データ スキャン スクリプトで生成された出力例 : File 1 absolute fuzzy scn = File 2 absolute fuzzy scn = File 3 absolute fuzzy scn = 高度なテクノロジー 38

39 File 22 absolute fuzzy scn = 0 Minimum PITR SCN = データベースの不完全リカバリを実行するコマンドの例 : SQL> alter database recover database until change ; SQL> alter database open resetlogs; 高度なテクノロジー 39

40 結論 Symmetrix V-Max は 拡張性 パフォーマンス 可用性 セキュリティ機能が強化された Symmetrix ファミリの新製品で Oracle のデータベースおよびアプリケーションをすばやく簡単に導入できるようにします Symmetrix は エンタープライズ Flash ドライブと ファイバ チャネルおよび SATA ドライブを導入することで 小規模および大規模データベースのパフォーマンス 容量 コストの要件に対応する統合プラットフォームを実現しています ストレージ階層と 階層間でデータをシームレスに移動する機能を適切に使用すると 最もアクティブなデータを最速の階層に そしてアクティブでないデータを SATA ドライブなどの低コストな高密度ドライブに配置できます また オートプロビジョニングなどの機能により Oracle データベース クラスタ 物理または仮想サーバ ファームへのストレージ プロビジョニングを容易に行うことができます TimeFinder および SRDF テクノロジーにより Oracle データベースおよびアプリケーションの高可用性と災害保護が簡素化され 小規模データベースから大規模データベースへの必要な可用性レベルが実現します この SRDF および TimeFinder は導入が簡単で ASM( 自動ストレージ管理 ) RMAN Grid Control などの Oracle 製品との統合性も非常に優れています また 本番環境でのバックアップの負荷を軽減できるほか 迅速なバックアップ イメージのリストアや再起動可能なデータベース クローンの作成が可能で Oracle のユーザーの操作性とデータ可用性が向上しています Oracle と EMC は 1995 年にエンジニアリング面でのパートナーシップを締結して以来 双方のテクノロジーの革新と統合に対してお互いに投資してきました この統合ソリューションにより データベースの可用性および災害復旧戦略の強化 本番環境へのバックアップの影響の軽減 コストの最小化 1 つのデータベース インスタンスまたは RAC 環境におけるストレージ使用率の向上が実現しています 付録 : テスト用ストレージおよびデータベース構成 この付録では テスト使用例で使用されているストレージおよびデータベース構成について説明します 一般的なテスト環境 次の環境を前提としています Oracle が 本番環境と同様のオプション設定でターゲット ホストにインストールされ ASM 用に構成されている (CSS(Cluster Synchronization Service) がアクティブである ) ASM インスタンスとデータベース インスタンスの本番 init.ora ファイルのコピーがターゲット ホストにコピーされ ターゲット ホスト環境に合わせて必要に応じて変更されている ターゲットが適切なクローン R2 またはリモート クローン( いずれかテストに適したもの ) にアクセスできる SRDF および TimeFinder テストは OLTP ワークロードの実行中に行われ 多数の Oracle ユーザーの同時接続をシミュレートしました ただし TimeFinder および SRDF コマンドは Symmetrix に接続されている任意のホストから発行でき 以降のテスト例では 特に説明がない限り これらのコマンドは本番ホストから発行されま 高度なテクノロジー 40

41 した 本番ホスト は ソース デバイスが使用されているプライマリ ホスト ターゲット ホスト は クローン R2 またはリモート クローン デバイスが使用されているホストを指定するのに使用します テストのセットアップ図 11は 本番サイトのOracle RACと ローカルおよびリモート レプリケーション用の関連するTimeFinder/CloneおよびSRDFデバイスが含まれるテストのセットアップを示しています RAC Node1 Remote Node1 CSS/CRS A S M R 1 R1 R 1 R2 A S M CSS/CRS SRDF Links RAC Node2 Remote Node2 Backup Host ASM ASM Remote Backup Host Clone Clone 図 11: テストの構成 ストレージとデバイスの構成は次のとおりです すべての RAC ノードが同じ一連のデバイスを共有し 適切な所有権を持ちます PowerPath を使用してマルチパスとロード バランシングをサポートします PowerPath デバイス名はすべての RAC ノードで一貫しています Symmetrix デバイス グループが RAC の共有ストレージに対して作成されます ASM ディスク グループが Symmetrix デバイスで構成されています 適切なローカルおよびリモート レプリケーションの関係が SYMCLI コマンドを使用して TimeFinder/Clone および SRDF に対して作成されています 表 2: テスト ハードウェア モデル OS Oracle バージョン ローカル 本番 ホスト :RAC ノード 1 ローカル 本番 ホスト :RAC ノード 2 DELL Red Hat Enterprise Linux g リリース 1( ) DELL Red Hat Enterprise Linux g リリース 1( ) 高度なテクノロジー 41

42 モデル OS Oracle バージョン リモート ターゲット ホスト DELL Red Hat Enterprise Linux g リリース 1( ) 種類 Enginuity バージョン Symmetrix V-Max 5874 Symmetrix V-Max 5874 高度なテクノロジー 42