EMC SRDF/TimeFinder および SRDF/TimeFinder および Oracle Database 10g/11gを使用した EMC Symmetrix V-Max 高度なテクノロジー USホワイトペーパー翻訳版要約

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 月

Copyright © 2009 EMC Corporation.All rights reserved.

このドキュメントに記載されている情報は、ドキュメントの出版日現時点の情報です。この情報

は、予告なく変更されることがあります。

この資料に記載される情報は、「現状有姿」の条件で提供されています。EMC Corporation は、

この資料に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、

商品性や特定の目的に対する適応性に対する黙示の保証はいたしません。

この資料に記載される、いかなる EMC ソフトウェアの使用、複製、頒布も、当該ソフトウェ

ア・ライセンスが必要です。

新の EMC 製品名については、http://japan.emc.com/で EMC Corporation の商標を参照してくださ

い。

他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または登録商標です。

パーツ番号 H6210.1-J

EMC SRDF/TimeFinder および Oracle Database 10g/11g を使用した EMC Symmetrix V-Max 高度なテクノロジー 2

目次エグゼクティブ・サマリー .............................................................................................5

はじめに .............................................................................................................................5 対象読者 .................................................................................................................................................... 7

製品と機能の概要 .............................................................................................................7 Symmetrix V-Max...................................................................................................................................... 7 Symmetrix V-Max自動プロビジョニング・グループ .......................................................................... 8 Symmetrix V-Maxの強化された仮想LUN移行テクノロジー .............................................................. 9 構成済みの領域への移行 .................................................................................................................. 11 未構成の領域への移行 ...................................................................................................................... 12

Symmetrix V-Max TimeFinder製品ファミリ ........................................................................................ 12 TimeFinder/Cloneと新しいカスケード・クローン ......................................................................... 12 TimeFinder/Snapと新しいTimeFinder/Snap Recreate........................................................................ 13 TimeFinder Consistent Split ................................................................................................................. 13 TimeFinderとSRDF ............................................................................................................................. 14

Symmetrix V-Max SRDF製品ファミリ ................................................................................................. 14 SRDF操作モード ................................................................................................................................ 14 SRDFトポロジー ................................................................................................................................ 18 TimeFinderとSRDFを利用してデータの整合性を実現.................................................................. 20

ASMリバランシングとコンシステンシ・テクノロジー .................................................................. 21

TimeFinderおよびSRDFを利用してビジネス継続性ソリューションを実現.........22 データベース・ストレージ・レイアウトとベスト・プラクティス............................................... 22 使用例 1：本番環境でのデータベース・バックアップの負荷を軽減する.................................... 24 ステップの概要 .................................................................................................................................. 24 使用するデバイス・グループ .......................................................................................................... 24 ステップの詳細 .................................................................................................................................. 25

使用例 2：データベースの並行リカバリ ........................................................................................... 28 ステップの概要 .................................................................................................................................. 28 使用するデバイス・グループ .......................................................................................................... 28 ステップの詳細 .................................................................................................................................. 28

使用例 3：本番環境の再起動可能なローカル・レプリカ................................................................ 29 ステップの概要 .................................................................................................................................. 29 使用するデバイス・グループ .......................................................................................................... 29 ステップの詳細 .................................................................................................................................. 29

使用例 4：災害保護のためのリモート・ミラーリング（同期および非同期） ............................ 30 ステップの概要 .................................................................................................................................. 30 使用するデバイス・グループ .......................................................................................................... 30 ステップの詳細 .................................................................................................................................. 31

使用例 5：他の目的で使用するための再起動可能なリモート・データベース・レプリカ ........ 32 ステップの概要 .................................................................................................................................. 32 使用するデバイス・グループ .......................................................................................................... 32 ステップの詳細 .................................................................................................................................. 32

使用例 6：リモート・データベースの有効なバックアップ・レプリカ........................................ 34


ステップの概要 .................................................................................................................................. 34 使用するデバイス・グループ .......................................................................................................... 34 ステップの詳細 .................................................................................................................................. 34

使用例 7：リモート・バックアップ・レプリカからのデータベースの並行リカバリ ................ 35 ステップの概要 .................................................................................................................................. 35 使用するデバイス・グループ .......................................................................................................... 35 ステップの詳細 .................................................................................................................................. 35

使用例 8：再起動可能なレプリカからのデータベースの高速リカバリ........................................ 37 ステップの概要 .................................................................................................................................. 37 使用するデバイス・グループ .......................................................................................................... 37 ステップの詳細 .................................................................................................................................. 37

結論....................................................................................................................................40

付録：テスト用ストレージおよびデータベース構成 ...............................................40 一般的なテスト環境 .............................................................................................................................. 40 テストのセットアップ ...................................................................................................................... 41


エグゼクティブ・サマリー 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


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 604683.1 に基づいています）。

ローカルおよびリモートの Oracle データベース・レプリケーションのベスト・プラクティスこのホワイト・ペーパーでは、Symmetrix V-Max システム、自動プロビジョニング・グループ、

仮想 LUN テクノロジーの概要を Oracle 関連の例とともに紹介しています。また、次の使用例の

手順とベスト・プラクティスについて詳しく説明します。

• 使用例 1：データベース・バックアップの負荷を本番環境からローカルの TimeFinder/Cloneに移動して軽減してから、Oracle の RMAN（Recovery Manager）を使用してさらにバックア

ップを行う • 使用例 2：ローカルの TimeFinder/Clone バックアップ・イメージをリストアし、ログを適用

することで、本番データベースの並列リカバリを容易に行えるようにする


• 使用例 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 のプラットフォーム


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ポートを追加または削除でき、ビュー

はクラスタのデバイス・プロビジョニングを自動化します。


ポート:10E:1

Port: 07E:1

Oracle RAC devices

Storage

SAN

RAC1_HBAs RAC2_HBAs

図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:10000000c975c2e4

WWN:10000000c975c336 symaccess -name RAC2_hbas -type initiator -file ./RAC2_hbas.txt create

The file RAC2_hbas.txt contains: WWN:10000000c975c31a WWN:10000000c975c3ab

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 保護を変更できます。


仮想 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)

4 x 400 GB Enterprise

Flash drives (RAID 5)

Ease of LUN migration for: • ASM diskgroups • Partitions • Tablespaces • Filesystems

‘‘++SSaalleess’’ 2200 xx 5500 GGBB

AASSMM mmeemmbbeerrss

図3：仮想 LUN テクノロジーを使用した移行の例


仮想LUNを使用するステップを次に示します。このステップは、図 3の例に基づいています。

仮想 LUN は、ターゲット・デバイスの構成済みまたは未構成のディスク領域を利用できます。

未構成のディスク領域に移行するということは、デバイスが移動して、ターゲット・ストレー

ジ・ディスク・グループの使用可能な空きスペースを占有することを意味します。移行後は、ソ

ース・デバイスの元のストレージ領域が未構成になります。いずれの場合も、ソース・デバイス

の ID は変わらず、移行はホストに対してシームレスに行われます。DR、バックアップ、高可用

性構成の面では変更は必要ありません。構成済みのディスク領域を指定するとき、ソース・デバ

イスとターゲット・デバイスは、基本的にストレージ特性をスワップするだけにすぎません。た

だし、データがターゲット・デバイスに移行した後、元のソース・ドライブのストレージ領域が

再フォーマットされ、元の領域に所属していたデータは公開されなくなります。

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: 0100 0C00 ... ... 0113 0C13

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 60

4. 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

Enginuity 5874 を使用すると、論理デバイスとメタボリュームの移行がサポートされます。（メ

タヘッド・ボリュームのみを指定する必要があります。メタメンバーは自動的に選択されま

す。）仮想 LUN 移行は、シン・デバイス（シン・プール・デバイス）、仮想デバイス（セー

ブ・プール・デバイス）、VCM、SFS、ヴォールトなどの内部 Symmetrix デバイスの移行をサポ

ートしていません。

構成済みの領域への移行このオプションは、ターゲット・ディスク・グループの大部分がすでに構成されている場合（こ

のため、十分な空きスペースがない場合）に便利です。また、移行が一時的なもので、後で同じ

ターゲット・デバイスに逆移行を行う場合にも役に立ちます。この例としては、月次決算報告前

の Flash ドライブ階層への SALES ASM ディスク・グループの移行が挙げられます。この方法で

は、再移行の際に、ソース・デバイスが再度以前のストレージ領域を占有するようになります。

構成済み領域への移行時に、ソース・デバイスとターゲット・デバイスの両方が指定されます。

ターゲット・デバイスはソース・デバイスとサイズが一致し、少なくともすべてのホストに対す

るマスクが解除されていなければなりません。また、オプションで、Symmetrix FA ポートからの

マップが解除されている必要があります。こうした要件により、移行先のターゲット・デバイス

に現在アクティブな顧客データが含まれないようにします。同様に、ターゲット・デバイスは、

SRDF、Clone、Snap、Open Replicator などその他すべての Symmetrix コピー操作の対象となるこ


とはできません。移行後、ターゲット・デバイスは、ソース・デバイスの元のストレージの場所

と保護を占有し、元のソース・デバイスのストレージ領域は、ターゲットによって古いデータが

公開されないようフォーマットされます。

未構成の領域への移行このオプションは、ターゲット・ストレージ・ディスク・グループに十分な空きスペースがある

場合に便利です。未構成の領域に移行するときは、ソース・デバイスのみが指定されます。移行

ターゲットについては、ストレージ・ディスク・グループ番号が、新しい 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 を短縮します。


カスケード・クローンは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 もよく認識しており、次回データベース・インスタンスが開始されたときに、クラ

ッシュ・リカバリによって簡単に復旧できます。


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 により、ソース・デバイスとターゲット・デバイスのデータをまったく

同じ状態に保ちながら、複数のデータベースとアプリケーションのデータをリモートでレプリケ


ートできます。SRDF/S は、1 つまたは複数のソース Symmetrix ストレージ・アレイを同期レプリ

ケーションで保護できます。

図 4に示すSRDF/S同期レプリケーションでは、ローカル・ホストからソースR1 デバイスへの各

I/Oが初にローカルSymmetrixキャッシュに書き込まれ（1）、その後、SRDFリンクを介してリ

モートSymmetrixユニットに送信されています（2）。リモートSymmetrixユニットが、I/Oを承認

してキャッシュで正常に受け取ると（3）、I/Oは承認されローカル・ホストに送信されます。

Synchronousモードでは、リモート・イメージがソース・イメージの完全かつ正確な複製である

ことが保証されます。

RDF links

Source Target

2

4

1 3

Production

Database

図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 デバイスに適用します。


SRDF/Aサイクル切り替えプロセスは非常に効率的で拡張性もあります。収集サイクルでデータの

一部が複数回更新されると、データに対する新の更新のみが一回だけ転送されます。このプロ

セスは書き込みのための保持と呼ばれます。また、各I/Oの書き込みの整合性を維持する必要があ

りません。代わりに、整合性はサイクル間で維持されます。何らかの理由でレプリケーションが

停止した場合、必ずSRDFは完全に受信したサイクルをR2 デバイスに適用するか、後の完了し

ていないサイクルを破棄します。これにより、リモートR2 デバイスは、常にR1 デバイスから 1または 2 サイクル遅れることになります。デフォルトの小サイクル時間は 30 秒ですが、ワーク

ロードのピーク時はこの時間を長くして、後からデフォルト値に戻すことが可能です。

移行元 Target

1

Production

Database

Transmit Receive

Capture SRDF links

Apply

R2R1

23

4

図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の


大数は大スキュー値と呼ばれ、SRDF監視/管理ソフトウェアを使用して設定できます。

SRDFアダプティブ・コピー・レプリケーションの使用時は、書き込みI/Oの順序の保持は試みら

れません。

RDF links

Source Target

3

2

14

Production

Database

図6：SRDF アダプティブ・コピー・モード

SRDF アダプティブ・コピー・レプリケーションは、Oracle がサポートする SRDF/S または

SRDF/A レプリケーションに変更する前の便利な中間ステップとして実行します。また、大量デ

ータのポイント・イン・タイム長距離転送にも使用されます。たとえば、両サイド間の接続が長

い間切断され、その間に大量の変更が蓄積されていると、リンクを再開することでリンク・トラ

フィックが急激に増える（通常の本番トラフィックによって生成された変更にバックログの変更

が追加されることによって作成される）ことがあります。SRDF アダプティブ・コピー・レプリ

ケーションを使用すると、SRDF の優先度が低いキューを使用してインバリッド・トラックのバ

ックログが同期されます。一方、新しい書き込みはキャッシュにバッファされ、ホスト・アプリ

ケーションに影響を及ぼすことなく、優先度が高い SRDF キューを使用して送信されます。変更

のバックログが転送されるか、変更されたトラックの合計が指定した数に達すると、SRDF/S ま

たは SRDF/A レプリケーション・モードに変更され、データベース保護が行われます。

SRDF アダプティブ・コピー・レプリケーションは、Oracle データベースのデータベース再起動

およびデータベース・リカバリのソリューションではサポートされていません。SRDF アダプテ

ィブ・コピー・レプリケーション自体を Oracle データベースの災害保護に使用すると、リモー

ト・データベースが破損し使用できなくなります。


SRDF トポロジー SRDFは、1 つのSRDFソースおよびターゲット以外の多数のトポロジーで設定できます。したが

って、SRDFは、高可用性および災害後の業務再開に関するさまざまなニーズに対応します。た

とえば、1 つのターゲットまたは 2 つのコンカレント・ターゲットを使用したり、同期レプリケ

ーションと非同期レプリケーションを組み合わせたりできるほか、長距離環境でデータ消失ゼロ

を実現する 3 サイト・ソリューションなどを提供します。次のセクションでは、SRDFで使用で

きる基本的なトポロジーについていくつか紹介します1。

コンカレント SRDF SRDF を使用すると、複数の SRDF リンクを使用して、1 つの R1 ソース・デバイスを大 2 つの

ターゲット・デバイスに同時にレプリケートできます。すべての SRDF リンクが Synchronous モードまたは Asynchronous モードのいずれかで動作できるか、1 つまたは複数のリンクがアダプテ

ィブ・コピー・モードを使用して、そのリンク上の使用可能な帯域幅を効率的に利用できます。

このトポロジーにより、短距離および長距離での同時データ保護が可能です。

移行元

Target

SRDF/S

Target

SRDF/A

図7：コンカレント SRDF

カスケード SRDF SRDF では、Symmetrix から Symmetrix へとデータが反映されるカスケード構成が可能です。こ

のように構成するには、初の SRDF リンクが Synchronous モードで、次の SRDF リンクが

Asynchronous またはアダプティブ・コピー・モードである必要があります。このトポロジーでは、

長距離でのリモート・レプリケーションをさまざまな度合いの帯域幅を利用して行うことができ

ます。データ消失はゼロか、あるとしても限られています（選択した SRDF モードと災害のタイ

プによって異なります）。

1 SRDFトポロジーの詳細については、SRDF製品ガイドを参照してください。


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 サイトに対するリモート・レプリケーションは直ち


に開始できます。たとえば、データベース操作がサイト C で再開されると、まず、サイト B か

らデータが送信されデータ消失ゼロのソリューションが構築されます。その後、サイト B が新し

い DR ターゲットになります。SRDF/Star は柔軟性が高く、モードとトポロジーを変更して、各

災害シナリオで大限の保護を実現できます。製品の詳細については、SRDF 製品ガイドを参照

してください。

図10：SRDF/Star

サイトA

Site C

SRDF/S

Site B

SRDF/A

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 のバックアップ操作の負荷をリモート・サイトに分散し、リストアされたデータを後でローカル・

サイトに戻します。


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障害グループに固

有です。


TimeFinder および SRDF を利用してビジネス継続性ソリュ

ーションを実現

データベース・ストレージ・レイアウトとベスト・プラクティス ASM および Solutions Enabler デバイス計画表 1は、使用例で使われたRACデータベースおよびSymmetrixデバイス・レイアウトの例を示し

ています。デバイス（LUN）のサイズはすべて 50 GBで、データベースの実際のサイズは約 400 GBです。

表1：ASM ディスク・グループ、および Symmetrix デバイスと複合グループ

ASM ディ

スク・グル

ープ

データベース・

デバイスリカバリ DG（デバイス・グ

ループ）

リスタート

DG（デバイ

ス・グルー

プ）

SRDF CG（コンシ

ステンシ・グルー

プ）

+DATA 18 LUN x 50 GB DATA_DG +REDO 4 LUN x 50 GB REDO_DG

DB_DG

+FRA 3 LUN x 50 GB FRA_DG

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デバイスに簡単に適用できます。


ルとログをそれぞれ独自の 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 を参照）。


• 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


ステップの詳細本番ホストでのステップ

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を使用してバックアップを行います。


ターゲット/バックアップ・ホストの前提条件：

• クローン・ボリューム上の 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; }


注意：フォーマット指定子%d は日付、%t は 4 バイトのタイムスタンプ、%s はバックア

ップ・セット番号、%p はバックアップ番号を示します。


使用例 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]


# 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 の前に記載されているターゲット・ホストの前提条件と同

じ条件に従ってください。


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


ステップの詳細

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


使用例 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 のクローンを使用するか、そのクローンから複数の書き込み可能なス

ナップショットを作成することが推奨されます。


2. ASM インスタンスを開始します。使用例 3 のステップ 2 と同じ操作を行います。

3. データベース・インスタンスを開始します。使用例 3 のステップ 3 と同じ操作を行いま

す。この時点で、クローン・データベースが開き、ユーザー接続で使用できます。

4. （オプション）データベース・クローンを更新するには、使用例 3 のステップ 4 と同じ

操作を行います。


使用例 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 と同じ操作を行い

ます。


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リストアを開始します。場合によっては、ソースとターゲット間の距離が長かったり、帯域幅が制限されていたり、


リストアしなければならない変更が多かったりすることがあります。このような場合、違い

が少ない間に、まず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 と同じ操作を行います。


使用例 8：再起動可能なレプリカからのデータベースの高速リカバリこの使用例では、新の整合性のとれた（再起動可能な）レプリカを使用して、そのレプリカに

ログを適用することで、データベースの高速リカバリを行っています。

Oracleは、SRDFまたはTimeFinderを使用して作成された、整合性のとれた相互に依存する書き込

みのストレージ・レプリカに基づいたさまざまなデータベース・リカバリ・シナリオをサポート

しています。Oracleサポートは、Metalinkの注記ID604683.1 に記載されています。この使用例の

目的は、夜間バックアップなど、ホット・バックアップ・モードに基づいたバックアップ戦略の

代わりとなる手段を紹介することではありません。これは補完的な使用例であり、たとえば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. 次のオプションのいずれかに基づいてデータベース・リカバリを行います。


データベースのフル（完全）リカバリオンライン 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

データ・スキャン・スクリプトで生成された出力例：

SQL> @./scandata.sql File 1 absolute fuzzy scn = 27088040 File 2 absolute fuzzy scn = 27144475 File 3 absolute fuzzy scn = 27164171


… File 22 absolute fuzzy scn = 0 Minimum PITR SCN = 27164171

データベースの不完全リカバリを実行するコマンドの例：

SQL> alter database recover database until change 27164171; SQL> alter database open resetlogs;


結論 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に接続されている任意のホストから発行で

き、以降のテスト例では、特に説明がない限り、これらのコマンドは本番ホストから発行されま


した。「本番ホスト」は、ソース・デバイスが使用されているプライマリ・ホスト、「ターゲッ

ト・ホスト」は、クローン、R2、またはリモート・クローン・デバイスが使用されているホスト

を指定するのに使用します。

テストのセットアップ図 11は、本番サイトのOracle RACと、ローカルおよびリモート・レプリケーション用の関連す

るTimeFinder/CloneおよびSRDFデバイスが含まれるテストのセットアップを示しています。

RAC

Node1

RAC

Node2

CSS/CRS R

1 R1

A

S

M

Backup

Host ASM

Remote

Node1

Remote

Node2

CSS/CRS

A

S

M

Remote

Backup Host

SRDF

Links

Clone

R1

R2

ASM

Clone

図11：テストの構成

ストレージとデバイスの構成は次のとおりです。

• すべての RAC ノードが同じ一連のデバイスを共有し、適切な所有権を持ちます。 • PowerPath を使用してマルチパスとロード・バランシングをサポートします。 • PowerPath デバイス名はすべての RAC ノードで一貫しています。 • Symmetrix デバイス・グループが RAC の共有ストレージに対して作成されます。 • ASM ディスク・グループが Symmetrix デバイスで構成されています。 • 適切なローカルおよびリモート・レプリケーションの関係が、SYMCLI コマンドを使用して

TimeFinder/Clone および SRDF に対して作成されています。

表2：テスト・ハードウェア

モデル OS Oracle バージョン

ローカル「本番」ホス

ト：RAC ノード 1 DELL Red Hat Enterprise Linux 5.0 11g リリース 1（11.1.0.6.0）

ローカル「本番」ホス

ト：RAC ノード 2 DELL Red Hat Enterprise Linux 5.0 11g リリース 1（11.1.0.6.0）


OS モデル Oracle バージョン

リモート「ターゲット」

ホスト DELL Red Hat Enterprise Linux 5.0 11g リリース 1（11.1.0.6.0）

種類 Enginuity バージョン

Symmetrix V-Max 5874 Symmetrix V-Max 5874


Documents

EMC SRDF/TimeFinder および SRDF/TimeFinder および Oracle Database 10g/11gを使用した EMC Symmetrix V-Max 高度なテクノロジー USホワイトペーパー翻訳版 要約

EMC SRDF/TimeFinder および SRDF/TimeFinder および Oracle Database 10g/11gを使用した EMC Symmetrix V-Max 高度なテクノロジー USホワイトペーパー翻訳版要約