emc clarix ストレージ・ソリューション： oracle … clarix...

EMC CLARiX ストレージ・ソリューション：

Oracle Database 10g/11g/11gR2 と

CLARiX の組み合わせにおけるストレージ・レプ

リケーションの整合性テクノロジーの適用

要約

このホワイト・ペーパーでは、EMC® CLARiX®ストレージ・レプリケーションの整合性機能である

SnapView™と MirrorView™/Synchronous を Oracle のフラッシュバック機能と組み合わせて使用し、

Linux および Windows 環境において Oracle Database 10g Release 2、Oracle Database 11g、または Oracle Database 11gR2 のオンライン・バックアップを支援する方法について説明します。

2010 年 8 月

EMC CLARiX ストレージ・ソリューション： Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ・レプリケーション

の整合性高度なテクノロジー 2

Copyright © 2006, 2008, 2010 EMC Corporation. All rights reserved.

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

なく変更されることがあります。

本文書に記載される情報は、「現状有姿（AS IS）」の条件で提供されています。EMC Corporationは、この資料に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、

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

本書に記載された EMC ソフトウェアの使用、複製、配布については、適用されるソフトウェアライセン

スを必要とします。

最新の EMC 製品名リストについては、http://japan.emc.com/ にある「EMC Corporation の商標」

を参照してください。

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

パーツ番号：H2104.3-J



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

概要 ....................................................................................................................... 5

対象者 .................................................................................................................... 5

用語 ....................................................................................................................... 6

CLARiX データ・レプリケーション・テクノロジー ........................................................ 6

CLARiX ストレージ・システム ................................................................................... 7

CLARiX レイヤード・ソフトウェア .............................................................................. 8

SnapView の概要 ...................................................................................................... 8

SnapView スナップショット ......................................................................................... 9 SnapView クローン ................................................................................................ 10

MV/S（MirrorView/Synchronous）の概要 ....................................................................... 10

SnapView と MirrorView/S における整合性 .................................................................... 11

SnapView スナップショットの整合性 ........................................................................... 11 SnapView クローン（BCV）の整合性 .......................................................................... 11 MirrorView/S コンシステンシ・グループ ....................................................................... 12

Oracle 環境におけるレプリケーションのアプリケーション・ベースの整合性とストレー

ジ・ベースの整合性 ............................................................................................... 12

アプリケーション・ベースの整合性 ................................................................................. 13

ストレージ・ベースの整合性 ......................................................................................... 14

ストレージ・ベースのコンシステンシ・レプリケーションにおける Oracle フラッシュバッ

ク・テクノロジーの活用 ........................................................................................... 14

Oracle Database 11gR2 のバックアップ/リカバリ .............................................................. 14

ファスト（フラッシュ）・リカバリ領域 ............................................................................... 15 フラッシュバック・ログ .............................................................................................. 15 Flashback Database ............................................................................................. 15

ASM（Automatic Storage Management） ...................................................................... 16

ストレージ・ベースのコンシステンシ・レプリケーションを使用したオンライン Oracle 11gR2 データベースのレプリケーションとリカバリ .................................................... 17

データベース・ファイルのレイアウト ................................................................................ 17

ASM インスタンスのパラメータ・ファイル .......................................................................... 18

データベース・インスタンスのパラメータ・ファイル............................................................... 18

SnapView の整合性機能を使用したレプリケーション ......................................................... 18

SnapView スナップショット・コンシステント・セッション開始の使用 ....................................... 19 SnapView クローンのコンシステント・フラクチャの使用 .................................................... 20

MirrorView/S コンシステンシ・グループを使用したレプリケーション ........................................ 22

MirrorView/S コンシステンシ・グループの作成 .............................................................. 23 MirrorView/S コンシステンシ・グループの使用 .............................................................. 24 MirrorView/S コンシステンシ・グループでの SnapView の使用 ......................................... 25

Oracle 11gR2 の Flashback Database 機能を使用したリカバリ ........................................... 26

整合性テストの表と結果 ........................................................................................ 28

まとめ ................................................................................................................... 29



関連資料 ............................................................................................................. 29

製品資料 ............................................................................................................... 29

ホワイト・ペーパー .................................................................................................... 29



エグゼクティブ・サマリー Oracle Database は、通常、複数の論理ユニット（LUN）上に配置されています。データには論理的

関係があり、相互に依存した書き込み I/O が存在します。このようなデータベースのレプリケーション

を実行する場合、相互に依存した書き込みの整合性を維持することが不可欠です。そのためには、

データベースをシャットダウンするか、データベースをホット・バックアップ・モードにしてから、レプリ

ケーションのプロセスを開始すればよいのですが、どちらの方法も、ダウンタイムであったり、オンライ

ン・バックアップ実行中のパフォーマンスの低下という点で、データベースのユーザーにマイナスの影

響を与えます。現在では、EMC® CLARiX® SnapView™および MirrorView™/Synchronous（MV/S）レプリケーション・ソフトウェアの整合性機能を使用すれば、事前にデータベースをシャットダ

ウンしたり、ホット・バックアップ・モードに切り替えたりしなくても、Oracle Database のレプリケーショ

ンを実行できるようになりました。EMC の実績あるストレージ・ベース・ソフトウェアの整合性機能を

Oracle の Flashback Database 機能とともに使用することで、Oracle Database のレプリケーション

を簡略化する新たな選択肢が提供されます。

概要このホワイト・ペーパーでは、SnapView と MirrorView/Synchronous のコンシステント・ストレージ・

レプリケーション・テクノロジーと、Oracle のフラッシュ・リカバリ領域と Flashback Database 機能、お

よび Oracle ASM （Automatic Storage Management ）機能の組み合わせにより、Oracle Database のオンライン・バックアップを支援する方法について説明します。ASM 環境で EMC レプリ

ケーション・テクノロジーを使用する Oracle Database 11gR2 のオンライン・バックアップの例も提示

します。このホワイト・ペーパーは、ホワイト・ペーパー「EMC CLARiX データベース・ストレージ・ソリューション：Oracle 10g および 11g と CLARiX の組み合わせにおけるストレージ・レプリケーションの整合性」のアップデート版です。

対象者このホワイト・ペーパーは、Linux および Windows プラットフォームで EMC CLARiX SnapView お

よび MirrorView/S の整合性機能を使用する Oracle Database のバックアップおよびリモート災害

保護計画の導入を検討している、データベース管理者およびシステム管理者を対象にしています。

読者は、Oracle Database ソフトウェアおよび ASM ならびに EMC CLARiX SnapView および

MirrorView レプリケーション・テクノロジーに関する知識が必要となります。



用語 FAST Fully Automated Storage Tiering の略語。ストレージ・システムによる自動管理 FAST ストレージ・プール SSD、FC、SATA など、複数のディスク・タイプの物理ドライブを含むストレージ・

プール FC ファイバ・チャネル LUN 論理ユニット番号。ホスト・アプリケーションから参照および操作できる、外部スト

レージ・システムのストレージ・オブジェクトプール・ベースの LUN ストレージ・プール内の利用可能な領域から作成された LUN SATA シリアル ATA SSD 半導体ディスクストレージプール使用可能なディスク・スペースのプールを形成するために指定された、CLARiX シ

ステムに内蔵される物理ドライブのグループシン（Thin）LUN LUN で利用するための領域の全体を、すぐには割り割り当てる必要のないプー

ル・ベースの LUN。LUN のスペースが使用されると、最大許容量に達するまで、も

しくは、プールで使用可能なスペースがなくなるまで（いずれか早いほう）、プール

からさらにスペースが割り当てられます。

CLARiX データ・レプリケーション・テクノロジー EMC SnapView スナップショット、SnapView クローン、および MirrorView/Synchronous は、

CLARiX ストレージ・システムに常駐するオプションのソフトウェアで、ローカルおよびリモートのアレ

イ・ベースのデータ・レプリケーション機能を提供します。これらの機能は、単一ポイント・イン・タイムの

バックアップ・コピー作成から災害保護用の複数のレプリカ作成まで、すべてホストのリソースを使用

せずに実行することができます。SnapView クローン、スナップショット・イメージ、および MV/S コ

ピーは、システム・バックアップ、DSS（意思決定支援システム）、リビジョン・テストの基盤として、また、

再現可能な整合性のあるデータ・イメージが必要とされるあらゆる場面で使用することができます。

Oracle Database は、通常、複数の LUN にまたがって格納されており、レプリケーションを実行する

際には、これらの LUN への書き込み I/O の順序を維持する必要があります。SnapView や

MirrorView を使用すれば、LUN のレプリケーションにはほんの数秒しかかかりません。しかし、各

LUN が個別にレプリケートされると、LUN のコンテンツが別の LUN のコンテンツと不整合となる時間

帯が生まれる可能性があります。この問題は、データベースをシャットダウンするか、データベースを

ホット・バックアップ・モードにしてから、レプリケーションを開始することで解決できます。現在の IT に

広く求められている 24 時間 365 日のアップタイムという要件を考慮すると、Oracle Database の

バックアップでは、シャットダウン前提よりもホット・バックアップ・モードを使用するほうが望ましいと言

えます。Oracle は、Oracle Database がホット・バックアップ状態に維持される限りにおいて、すべて

のファイルのコンテンツで相互に依存した書き込み順序の整合性が保たれることを保証しています。

多数のファイルが複数の LUN に分散されている大規模データベースの場合、データベースをホット・

バックアップ・モードに切り替えて、すべての LUN をレプリケートしてから、データベースを元のモード

に戻すまでに、かなりの時間を要します。ホット・バックアップ・モード時にも、データベースを読み取り

/書き込みに使用できますが、Oracle による記録処理が増えるために、ホスト側のパフォーマンス・イ

ンパクトが生じます。

しかし、SnapView および MV/S のストレージ・ベースの整合性機能を追加することにより、レプリ

ケーションの実行時にデータベースをシャットダウンしたり、ホット・バックアップ・モードに切り替えたり

する必要がなくなります。コンシステント・レプリケーションが実行されると、データベースを構成する

LUN セットに対する変更は、ストレージ・システムによって一瞬ブロックされるため、レプリケートされた

LUN セットでも相互に依存した書き込み順序の整合性が保たれます。このレプリケートされた LUNセットは、突然の電源障害やクラッシュが発生したサーバと同じ状態、つまり、一貫性があり再起動可



能な Oracle Database イメージになります。この再起動可能イメージを Oracle のフラッシュ・リカバリ

領域や Flashback Database 機能と組み合わせて使用すると、キャプチャされたアーカイブ・ログを

使用して後からロール・フォーワードすることができます。さらに、SnapView および MV/S は、サー

バ・アプリケーション・レベルではなくストレージ・システム・レベルで機能するため、さまざまなアプリ

ケーションにまたがって書き込み順序の依存関係がある分散データベースやフェデレーション・デー

タベース環境において、このモデルを使用してトランザクションの整合性を確保することができます。

オンラインの Oracle Database をレプリケーションする際のデータの整合性と動作の正確性を保証

するため、スナップショット・テスト・キットに含まれるホット・バックアップ・テストに変更を加え、CLARiXによるレプリケーションの整合性テストに使用しました。このスナップショット・テスト・キットは、OSCP（Oracle Storage Compatibility Program）の一部として Oracle 社から提供されているものです。

Oracle 10g 以降に搭載された Oracle Database の重要機能の 1 つである ASM（Automatic Storage Management）が、Oracle Database を格納するために実装されました。ASM を使用して

Oracle データの管理、配置、制御を簡便化することにより、パフォーマンスや可用性を損なうことなく、

TCO（総所有コスト）を削減できます。

CLARiX ストレージ・システム EMC CLARiX ストレージ・システムは、高可用性を目的として設計されています。デュアル SP（スト

レージ・プロセッサ）、デュアル・バックエンド FC（ファイバ・チャネル）ループ、デュアル・ポート・ディス

ク・ドライブ、グローバル・ホット・スペア・テクノロジーなどの冗長コンポーネントを備えた CLARiX スト

レージ・システムには、単一障害点がありません。CLARiX は、RAID 1、1/0、3、および 5 のデータ

保護オプションが用意されています。これらの構成は、単一ディスク障害に対する保護を提供します。

さらに、FLARE® リリース 26 より、CLARiX RAID 6 テクノロジーが導入されました。RAID 6 では、1つの RAID グループ内で最大 2 か所のディスク障害に対して保護され、二重のドライブ障害による

データ消失リスクを削減できます。

CLARiX システムは、デュアル SP を搭載しており、SP 間で LUN のバランスをとることでパフォーマ

ンスを向上させます。1 基の SP が使用不能になった場合、その SP に対する I/O リクエストの処理は

もう一方の SP に引き継がれます。そのため、SP の障害は、大きなサービス中断もなく自動的に処理

されます。PowerPath®の定期的な autorestore 機能が有効な場合、障害が修復された後にサービ

スが自動的に元々割り当てられていた SP にフェイルバックします。この機能が無効な場合は、手動

でリストアを行う必要があります。

このホワイト・ペーパーで説明する、Oracle とともに使用する EMC CLARiX レプリケーションの方法

論は、SnapView および MirrorView をサポートする CLARiX ファミリのすべてのモデル（CX、CX3、最新の CLARiX CX4 シリーズ・ストレージなど）に適用されます。

2008 年第 3 四半期にリリースされた CLARiX CX4 シリーズ・ストレージ・プラットフォームは、EMCの最先端のミッドレンジ・ファミリのストレージ・システムです。CX4 は、拡張性および運用性を強化す

るために、64 ビット対応の機能拡張 FLARE ドライバを実装しています。また、追加接続ポートを増設

してサーバから CLARiX への接続パスを拡張できる、新しい UltraFlex™ I/O モジュール設計が採用

されています。このように柔軟な設計で、10 Gigabit Ethernet や 8 GB FC などのより高帯域幅の新

しい接続テクノロジーへのアップグレードに対応します。このプラットフォームでは、類い希な拡張性を

実現できます。CX4-960 モデルで最大 960 台のドライブと 4,096 個の LUN がサポートされ、高可

用性ドライブから高密度ドライブまで、さまざまな種類のドライブを収容できます。そのため、総容量の

拡張性に優れているだけでなく、最もコスト・パフォーマンスの高い Oracle Database ソリューション

の保存および管理手法を実現する、ストレージ階層化も可能です。2008 年下期には、フラッシュ・ド

ライブのサポートが製品ラインに追加されたため、EMC CLARiX ストレージは、この新世代のデータ・

ストレージ・デバイスをサポートする初めてのミッドレンジ・アレイとなりました。EMC は、これを生かして、

ディスク・ドライブの回転数の制限がなくなる、新しい超高性能の「階層 0」を作成しました。EMC テク

ノロジーを使用して最適化されたエンタープライズ・クラスのフラッシュ・ドライブと高度な CLARiX の

機能の組み合わせにより、企業は、ミッドレンジ・ストレージ・プラットフォームには従来なかった新たな



ストレージ階層を手に入れることができます。フラッシュ・ドライブ・テクノロジーを採用した CLARiX CX4 UltraScale シリーズの詳細については、当社の Web サイト（）を参照してください。

CX4 システムの全リリースでは、常に新しい機能が追加されています。FLARE リリース 28 を搭載し

た EMC CLARiX には、ストレージ・プールの概念が導入されています。EMC ストレージ・プラット

フォームにプール・ベースの LUN のサポートが加わったのは、ストレージの過剰プロビジョニングの問

題に対処する EMC の総合仮想化戦略の一環です。このホワイト・ペーパーの裏付けとして実施され

たテストでは、プール・ベースのシン LUN も使用されました。さらに、FLARE リリース 30 では、スト

レージ・システムの既存のキャッシュ機能を拡張してシステム全体のパフォーマンスを向上させる

FAST Cache や、フラッシュ、FC、および SATA ストレージ・リソース間でニーズ変更に応じてデータ

を自動的に移行して配置する FAST などの機能も追加されました。これらの新機能の詳細について

は、このホワイト・ペーパーでは取り上げません。これらの機能拡張の詳細については、当社の Webサイトに掲載されている関連するホワイト・ペーパーを参照してください。

EMC Unisphere™は、リリース 30 で導入されました。これは、Web ベースのユーザー・インタフェー

スからアクセスする単一のシンプルで直感的な管理フレームワークを使用して、CLARiX、Celerra®、および RecoverPoint/SE システムの管理および構成を行う、単一の統合ソリューションです。

Unisphere は、以前のリリースでは別々の機能から提供されていた、さまざまなシステム管理ツール

に代わるものです。Navisphere® CLI は、Unisphere 製品ソフトウェア・スイートの一部で、Web イン

タフェースでサポートされるすべてのアレイ・システム管理機能を呼び出す代替手段となるコマンド・ラ

イン・インタフェースを提供します。後述する SnapView と MV/S は、Navisphere CLI コマンドを使

用するシェル・スクリプトやバッチ・ファイルによって自動化できます。これらの管理ツールを使用する

場合、物理ディスク・ドライブが RAID グループに編成されます。さまざまなサイズの LUN を各 RAIDグループにバインドし、グループの RAID の特性を継承させることができます。さらに、LUN は、

CLARiX ストレージ・システムに接続された 1 台または複数のホスト（ホスト・クラスタとともに）に関連付

けられたストレージ・グループに割り当てられます。ストレージ・グループに属する LUN は、ストレー

ジ・グループ内のホストごとに表示可能なディスク・デバイスとなります。CLARiX ストレージ・システム

における RAID グループ作成、LUN のバインディング、およびストレージ・グループ作成の詳細につ

いては、「EMC Unisphere Help 6.30」（英語版）を参照してください。

Navisphere CLI インタフェースの他に、サーバ・ベースのユーティリティの admsnap を使用して、

SnapView スナップショットとクローンを管理することもできます。admsnap ユーティリティは、

SnapView ソフトウェアがインストールされて有効化されたストレージ・システムに接続している、任意

のサーバにインストールできます。Admsnap は、SnapView の設定には使用できず、動作中の

SnapView の管理にのみ使用できます。

CLARiX レイヤード・ソフトウェア CLARiX レイヤード・ソフトウェアは、ローカルおよびリモートのアレイ・ベースのデータ・レプリケーショ

ン機能を提供する、オプションのストレージ・システム・ベースのアプリケーションです。これらのアプリ

ケーションは、単一ポイント・イン・タイムのバックアップ・コピー作成から災害保護用の複数のレプリカ

作成まで、さまざまな機能を提供します。これらのレイヤード・アプリケーションは、CLARiX ストレー

ジ・システムで実行されるため、ホストのリソースを使用せずにデータをレプリケートできます。このうち

の SnapView と MirrorView/Synchronous の 2 つアプリケーションとその整合性機能について、こ

のホワイト・ペーパーで説明します。

SnapView の概要 SnapView を使用すると、本番データのローカルのポイント・イン・タイム・スナップショットやフル・コ

ピーのクローンを作成して、無停止バックアップを実行することができます。このスナップショット・イ

メージとフラクチャされたクローンは、セカンダリ・サーバにマウントして、バックアップ、意思決定支援、

テストなどに転用することができます。プライマリ・サーバから本番データベースへのアクセスが中断さ

れた場合でも、SnapView のスナップショットとクローン・イメージがあることで、セカンダリ・サーバから



の確実で迅速なデータ・アクセスが保証されます。さらに、スナップショット・イメージやクローン・デー

タは、ソース LUN でデータが破損した場合に、ソース LUN にリストアすることができます。

SnapView スナップショット個々の SnapView スナップショットは、ソース LUN のポイント・イン・タイムの論理コピーを表し、作成

にはわずか数秒しかかかりません。この LUN のポイント・イン・タイム・イメージは、スナップショット・

セッションの開始時にキャプチャされます。スナップショットは、セカンダリ・サーバからは通常の LUNと同じように見え、バックアップ、テスト、その他の用途に使用することができます。スナップショットは、

COFW（Copy on First Write）テクノロジーを使用して、スナップショット作成時点以降のソース LUNの変更を追跡します。ソース LUN に書き込みをすると、SnapView がストレージ・システム上の「予約

済み LUN プール」と呼ばれるプライベート領域に元のブロックをコピーします。この COFW 動作は、

ソース LUN で変更される各データ・ブロックで 1 回しか行われません。予約済み LUN には変更後の

データ・ブロックのみ保持されるため、スナップショットの実装に必要なストレージ容量をソース LUNのサイズのごくわずかに抑えられます。スナップショットはポイント・イン・タイムの仮想コピーであり、未

変更データに関してはソース LUN にアクセスする必要があるため、ソース LUN に影響する障害が発

生すると、そのスナップショットは利用できなくなってしまいます。スナップショットをデータベースの

バックアップとして使用する場合は、耐久性のあるメディアにコピーすることをお勧めします。

FLARE リリース 24 以降では、すべての SnapView セッションがデフォルトで維持されます。スナップ

ショットの継続セッションは、さらに上の保護レベルを提供し、SP の再起動や障害、ストレージ・システ

ムの再起動や電源障害、または、ピア・トレスパスなどが発生した後も継続してスナップショットを使用

することができます。さらに、ロールバックが可能なのは、スナップショットの継続セッションのみです。

ソース LUN が破損した場合や、スナップショット・セッションのポイント・イン・タイム・データがソースと

して求められる場合は、SnapView のロールバック機能を使用して、ソース LUN のコンテンツをス

ナップショット・セッションのポイント・イン・タイム・データでリプレースします。ロールバック処理が確認

されると、本番サーバがただちにスナップショット・セッションのポイント・イン・タイム・データにアクセス

できるようになり、バックグラウンドでは、ソース LUN にデータをコピーする実際の動作は継続されま

す。スナップショット・セッションをアクティブ化して、スナップショットのデータ変更が行われたときに、

ソース LUN をセッションの開始時点の状態に戻したい場合は、ロールバックの前にセッションを無効

化する必要があります。

図 1に示すように、スナップショットは、ソース LUN の未変更データと、予約済み LUN プール内の予

約済み LUN に保存されているデータから成ります。スナップショットは、読み取りと書き込みの両方が

可能であるため、セカンダリ・サーバからのスナップショット書き込みは、すべて予約済み LUN にも保

存されます。これにより、アクティブ化されたスナップショットを使用したロールバック処理時に、スナッ

プショットに対する変更をソース LUN にコピーすることができます。

図 1. スナップショットの例図 2. クローンの例



SnapView クローン各 SnapView クローンは、それぞれのソース LUN にビット単位で対応する完全なレプリカで、ソース

とまったく同じディスク容量を必要とし、初回作成には時間がかかります。クローンの初回作成時間は、

クローニングするソース LUN のサイズによって異なります。いったん作成されると、クローンは、スナッ

プショットと同様に秒単位でフラクチャできます。そのため、セカンダリ・サーバに表示されたときに完

全読み取り/書き込み可能な、ソース LUN のポイント・イン・タイムのレプリカが提供されます。スナップ

ショットと異なり、クローンは、ソース LUN で障害が発生しても完全に使用可能です。クローンでは、

単一のストレージ・システム内のすべてを取り込んだ LUN のコピーを作成できます。クローンがソース

LUN と同期状態にある場合、ソース LUN への書き込みはクローンにも同時にコピーされます。ポイン

ト・イン・タイムのコピーを維持するには、クローンをソース LUN からフラクチャする必要があります。フ

ラクチャされてセカンダリ・ホストに表示されたクローンは、I/O に使用できます。その後のソースまたは

クローン LUN への変更は、フラクチャ・ログとして追跡されます。このログは、「クローン・プライベート

LUN」と呼ばれるディスクに格納されるビットマップです。

フラクチャされたクローンは、バックアップ、意思決定支援、テストなどの他の用途に使用することがで

きます。ソース LUN のデータが破損した場合、SnapView クローンの増分リバース同期機能を使用

して、クローンがフラクチャされた時点までコンテンツをすばやくリストアすることができます。ただし、こ

のクローンが一切変更されていない場合に限ります。クローンが変更されている場合は、リバース同

期時点のクローンの状態がソースに反映されます。さらに高い保護レベルが得られる方法としては、リ

バース同期を開始する前に Protected Restore 機能を選択することにより、保護された状態でリバー

ス同期を実行できます。ソース LUN は、各 LUN でリバース同期が開始されると同時にオンラインに

戻すことができます。そのため、Protected Restore を選択することにより、リバース同期プロセス進行

中に任意のサーバによるソース LUN への書き込みがクローンにコピーされないようにすることができ

ます。さらに、リバース同期が開始されたクローンでは、リバース同期の完了後に自動的にフラクチャ

が実行されます。この機能の本質的な目的は、テストやリカバリのために同じクローン・セットから何回

もリストア操作を実行できる、本番データベースの「ゴールド」バックアップ・コピーを作成することです。

図 2 は、ソース LUN とフラクチャされたクローン LUN がそれぞれのサーバで変更されたときに、ク

ローン・プライベート LUN が、クローンがフラクチャされた後に変更されたソースおよびクローンの領

域を追跡する仕組みを示しています。このロギングの仕組みにより、変更されたデータ・ブロックのみ

が差分コピーされるため、クローンとそのソース LUN の同期またはリバース同期の所要時間が大幅に

短縮されます。

MV/S（MirrorView/Synchronous）の概要 MirrorView は、単一の CLARiX システム上の LUN（プライマリ LUN）に保存された本番データを、

異なる CLARiX ストレージ・システム上の対応する LUN（セカンダリ LUN）にレプリケートする、スト

レージ・システム・ベースの DR（災害復旧）製品です。MV/S は、ローカルとリモートのストレージ・シ

ステム上の LUN の間で、リアルタイムにデータを同期ミラーリングします。同期モードの場合、ローカ

ル（プライマリ）ストレージ・システムへのサーバからの書き込みに対する ACK は、データがリモート

（セカンダリ）ストレージ・システムに正常に転送された後に初めて、そのサーバに返信されます。同

期モードでは、リモート・イメージが完全であり、ソース・イメージの正確なコピーであることが保証され

ます。

図 3は、リモート・ミラー構成の例です。SnapView を MV/S と組み合わせて使用することにより、プ

ライマリやセカンダリ・ミラー・イメージのスナップショットまたはクローン（FLARE リリース 24 以降）を作

成できます。作成されたスナップショットまたはクローンは、検証を実行したり、バックアップ、レポート、

テストなどの並行処理プロセスを実行するために使用したりできます。これにより、ローカルおよびリ

モート・サイトのどちらかでデータが破損した場合の保護レベルが一段と強化されます。



図 3. MirrorView/Synchronous の例

SnapView と MirrorView/S における整合性ストレージ・システム・ベースの SnapView と MV/S の整合性機能は、Oracle アプリケーションから独

立して動作します。コンシステント・レプリケーションは、複数の LUN のセットに対して機能するため、

セット内の 1 つのメンバーでレプリケーションのアクションが失敗した場合、セット内の他のすべてのメ

ンバーのレプリケーションがキャンセルまたは停止されます。そのため、セット内のすべてのレプリケー

ト済み LUN のコンテンツは、ソースと完全に等しいポイント・イン・タイムのレプリカで、相互に依存した

書き込みの整合性が保たれていることが保証されています。この LUN のセットは、必ず単一のスト

レージ・システム上に置かれ、複数のストレージ・システムにまたがって配置することはできません。

Oracle Database を構成する LUN のセットでコンシステント・レプリケーションのプロセスが呼び出さ

れた場合、ストレージ・システムでは、レプリケーション機能が完了するのに十分な時間が与えられる

ように、セット内の各ソース LUN への書き込みを一時的に保留にします。コンシステント・レプリケー

ションを使用すれば、データベースをシャットダウンしたり、「ホット・バックアップ・モード」に切り替えた

りする必要はありません。SnapView または MV/S の整合性機能を使用して作成されたレプリカは、

事前にアプリケーションを停止または終了しなくても、本番データの再起動可能なポイント・イン・タイ

ムのレプリカとなり、相互に依存した書き込みの整合性が確保されます。

SnapView スナップショットの整合性スナップショットの整合性は、整合性のある LUN セットという概念に基づいています。スナップショット・

コンシステント・セッションは、複数の LUN のセットに対して機能します。この LUN のセットは、各ス

ナップショット・セッションの開始時に動的に選択され、通常、アプリケーション・レベルで相互に関連

性のあるコンテンツが含まれます。コンシステント・セッションの開始後は、そのセッションに別の LUNを追加することはできません。Oracle Database を使用している場合は、これがデータベースを構成

する関連コンテンツのファイルを格納した LUN のセットになります。このソース LUN のセットに対する

I/O 要求では、セット内のすべての LUN でセッションが開始されるまでにわずかな遅延が発生します。

それにより、ポイント・イン・タイムの相互に依存した書き込み順序の整合性がとれた、再起動可能な

データベース・コピーが確実にレプリケートされます。個別の LUN メンバーに対してスナップショットの

コンシステント・セッションを停止することは可能ですが、実行しないように強く推奨します。ほとんどの

場合、メンバーを除外するとセットの完全性が失われて、整合性を保てなくなるためです。

SnapView クローン（BCV）の整合性 SnapView クローン・コンシステント・フラクチャとは、クローン・セット内でポイント・イン・タイムの再起

動可能なコピーをキャプチャするために、2 つ以上のクローンが同時にフラクチャされる場合を言いま

す。Oracle Database を使用している場合は、これがデータベースを構成する関連コンテンツのファ

イル（データファイルやログ・ファイルなど）を格納した、クローン LUN のセットになります。このクローン



LUN のセットは、フラクチャが開始されたときに動的に選択され、セット内の各クローンが異なるクロー

ン・グループに属していなければなりません。つまり、同じソース LUN に属している複数のクローンに

対してコンシステント・フラクチャを実行することはできません。SnapView のドライバは、すべてのク

ローンでフラクチャが完了するまで、選択されたクローンのソース LUN への I/O 要求を遅延させます。

そうすることにより、ポイント・イン・タイムの相互に依存した書き込み順序の整合性がとれた、再起動

可能なデータベース・コピーが確実にレプリケートされます。コンシステント・フラクチャが完了すると、

セット内のクローン間における関連性はなくなります。つまり、その後で実行される同期、リバース同

期、削除などのアクションは、個別のクローンに対して行われます。関連性のあるクローンの間でポイ

ント・イン・タイムのデータ・コピーの整合性を保持するためには、セット内のクローンの 1 つで実行し

たアクションをセット内のすべてのクローンに対して実行することを強くお勧めします。

MirrorView/S コンシステンシ・グループ MV/S(MirrorView/S）は、コンシステンシ・グループ機能をサポートしています。コンシステンシ・グ

ループは、同期ミラーリングされる LUN のペアのセットで、そのデータが Oracle Database など、内

容に関連性があり、相互に依存した書き込み順序の整合性を持つことが分かっていて、使用するた

めにはセットとして複製する必要があるものです。コンシステンシ・グループを使用する場合、

MirrorView では、相互に依存した書き込み順序があるボリュームの 1 つ、一部、またはすべてに対

するサービスが停止した場合に、複数のセカンダリ LUN の間で書き込み順序が維持されます。コン

システンシ・グループに属しているミラーLUN を個別にフラクチャ、同期化、またはプロモートすること

はできません。これらのアクションは、グループのすべてのメンバー・ミラーに対してまとめて実行する

必要があります。グループ内の LUN に対する書き込みをセカンダリ・アレイ内の対応する LUN に正

しくミラーできない場合、グループはフラクチャされます。フラクチャは、一方または両方の SP のミ

ラーリング・パスで障害が発生した場合にも自動的に実行されますが、手動で行うこともできます。どち

らの場合も、MirrorView は、コンシステンシ・グループ内のすべてのメンバーをフラクチャします。グ

ループのすべてのメンバーに対するフラクチャが完了するまで、ミラーされていない書き込みの ACKはホストに返信されません。これにより、セカンダリ・イメージ・セットにおけるデータの整合性が保たれ

ます。

セカンダリ・サイトでフラクチャされたイメージ・セットのコンテンツが、本番サイトのコンテンツより多少

遅延する場合があります。しかし、これらのコンテンツは、ポイント・イン・タイムの相互に依存した書き

込み順序が保証された、再起動可能なデータベースです。コンシステンシ・グループがフラクチャされ

た場合、セカンダリ・イメージにアクセスできない間に実行されたプライマリ・イメージへの変更はすべ

て、フラクチャ・ログとして追跡されます。フラクチャ・ログは、ストレージ・プロセッサのメモリに保持され

ているビットマップです。このフラクチャ・ログのビットマップを使用することで、フラクチャされた後のコ

ンシステンシ・グループ同期の所要時間が短縮されます。

プライマリ・サイトでサーバとストレージ・システムのいずれかまたは両方で障害が発生した場合に、セ

カンダリ・イメージ・セットをすばやくプロモートして、プライマリ・セットの役割を引き継がせることにより、

本番データへの継続的なアクセスを可能にします。セカンダリ・イメージが正しくプロモートされた後、

リモート・サイトでアプリケーションをオンラインにするために、アプリケーション・リカバリの追加の手順

が必要になる場合があります。Oracle Database を使用している場合、これは Oracle インスタンス

の再起動を意味します。Oracle Database が正しい順序でシャットダウンされていないため、Oracle Database を正常にオープンする前にクラッシュ・リカバリを実行する必要があります。

Oracle 環境におけるレプリケーションのアプリケーション・

ベースの整合性とストレージ・ベースの整合性 SnapView と MV/S の整合性機能を使用すると、Oracle 環境を実行しているサイトでは、オンライン

の Oracle Database をレプリケートする際に、アプリケーション・ベースの整合性とストレージ・ベース

の整合性のどちらかを選択できるようになります。これらは方法は異なりますが、どちらを選択しても、

作成されたレプリカにおいて関連する LUN の間で相互に依存した書き込み順序の整合性が維持さ



れます。図 4に示すように、Oracle ベースの整合性機能では、Oracle Database の有効なバック

アップが作成され、ストレージ・ベースの整合性機能では、一貫性のある再起動可能な Oracle Database が作成されます。ただし、この再起動可能イメージは、Oracle 11g のフラッシュ・リカバリ

領域や Flashback Database 機能とともに使用した場合に、キャプチャされたアーカイブ・ログを使

用して後からロール・フォーワードすることができます。

Oracle Database のバックアップ SnapView の整合性レプリケー

ション

図 4. プリケーション・ベースとストレージ・ベースのデータベース・レプリカの作成

アプリケーション・ベースの整合性リリース 19 より前の SnapView および MV/S 整合性機能は、いずれもダウンタイムとパフォーマン

ス・インパクトが最小限に抑えられる Oracle Database の有効なバックアップ方法であることが、広範

なテストと Oracle の OSCP プログラムにより実証されています。ストレージ・ベースの整合性機能がな

い場合、ストレージ・システムのレプリケーション対象が有効な Oracle Database バックアップになる

ようにするには、Oracle ベースの整合性が必要でした。言い換えれば、オンラインの Oracle Database のバックアップを作成するには、ストレージ・ベースのレプリケーション・コマンドを実行する

前にデータベースをホット・バックアップ・モードに切り替える必要があります。Oracle Database が

ホット・バックアップ・モードに切り替わると、対象の LUN に対するそれ以後の I/O の変更が Oracleレベルで管理されます。データベースが静止状態になってから、Oracle がホット・バックアップ・モード

から切り替わり、I/O が再開されるまでの間は、関連する LUN をすべて安全にレプリケートできます。

さらに、このレプリケートされたコピーを使用すると、バックアップの作成後にデータベースを再起動し、

一貫性のあるポイント・イン・タイムにリカバリすることができます（リカバリ・モデル）。Oracle のが提供

する整合性保持の手法を用いたオンライン・バックアップでは、有効な Oracle Database のバック

アップが作成されます。

リカバリ・モデルの場合、データベースに適宜トランザクション・ログを適用して、整合するポイント・イ

ン・タイムに復旧させることができるため、通常、リカバリの精度が向上します。さらに、アーカイブ・ログ

の追加変更を使用して、整合性のあるデータベースを特定のポイント・イン・タイムか特定のチェンジ・



ナンバーまでロール・フォーワードすることができます。一方で、データベースをホット・バックアップ・

モードに切り替えなければならないため、そのプロセスの一環として Oracle で余分に処理する必要

があるチェック・ポイント処理、ログへの書き込み、およびログ切り替えにより、ホスト側にパフォーマン

ス・インパクトが発生します。

ストレージ・ベースの整合性ストレージ・ベースの整合性機能は、サーバ上の Oracle アプリケーションから独立して機能するため、

データベースをホット・バックアップ・モードにする必要はありません。関連する Oracle Database の

LUN を特定する必須ステップが完了している場合、ストレージ・システムでは、相互に依存した書き込

み順序が保証された、整合性を持ったデータベース・イメージを作成するために、セット内のすべての

LUN に対する書き込みを一時的に保留します。LUN セットに対する通常の I/O は、レプリケーション

の完了後に再開されます。また、このレプリケートされたコピーを使用して、Oracle Database を再開

できます（リスタート・モデル）。ただし、データベースをロール・フォーワードすることはできません。スト

レージ・ベースの整合化手法のみを使用するオンライン・バックアップでは、一貫性のある再起動可能

な Oracle Database が作成されます。

リスタート・モデルは、精度は劣りますが、処理を再開するプロセスがより簡単です。このレプリケーショ

ン・セットの状態は、突然の電源障害やシステム・クラッシュが原因でクラッシュした本番データベース

と同じ状態になります。したがって、処理を再開するプロセスも、元の本番サイトで予期せずサービス

が停止した後に処理を再開する場合と同じです。データベースをホット・バックアップ・モードに切り替

える必要がないため、レプリケーション・プロセス実行中のホスト側でのパフォーマンス・インパクトは最

小限に抑えられます。

ストレージ・ベースのコンシステンシ・レプリケーションにおける

Oracle フラッシュバック・テクノロジーの活用 Oracle のフラッシュバック・テクノロジーは、時間の前後するデータを表示してその時点の状態に戻

すための一連の機能を提供します。Oracle フラッシュバック・テクノロジーに含まれる 2 つの主要機

能は、Flashback Database とフラッシュ・リカバリ領域です。Flashback Database 機能は、フラッ

シュ・リカバリ領域のフラッシュバック・ログを使用して、Oracle Database 全体を過去の特定時点（ポ

イント・イン・タイム）に戻します。フラッシュ・リカバリ領域は、Oracle Database バックアップ/リカバリに

関連するすべてのファイル（制御ファイル、オンライン・ログ・ファイル、アーカイブ REDO ログ・ファイ

ル、フラッシュバック・ログなど）の格納先として、Oracle が管理および使用する一元化されたディス

ク・ロケーションです。Oracle は、フラッシュ・リカバリ領域の設定には ASM（Automatic Storage Management）を使用することを推奨しています。これは、新しいバックアップ用のスペースが必要に

なった場合に、不要になったファイルが自動的に削除されるメリットがあるためです。

Oracle Database 11gR2 のバックアップ/リカバリ Flashback Database 機能を使用すると、論理データの破損やユーザー・エラーにより発生した問題

を修復するために、過去の整合するポイント・イン・タイムの状態にデータベースをすばやく復旧でき

ます。Oracle は、フラッシュバック・ログでキャプチャされた過去のブロック・イメージを使用してこれを

実行し、データベースの変更を元に戻します。この機能は、フラッシュ・リカバリ領域が設定され、フ

ラッシュバック機能が有効な場合にのみ使用できます。

すでに説明したように、CLARiX のストレージ・ベース整合性を使用して、ホット・バックアップ・モード

になっていないオンライン Oracle Database をキャプチャした場合、作成されるのは、単に一貫性が

あり再起動可能な Oracle Database であり、整合性のあるバックアップ・データベースではありませ

ん。しかし、Oracle の Flashback Database 機能を使用すると、この再起動可能なデータベースをフ

ラッシュバックして、既知の整合性のとれたポイント・イン・タイムに戻すことができます。データベース

が整合性のある状態にフラッシュバックされると、このデータベースに適切なアーカイブ・ログを適用し、



ロール・フォーワードすることができます。この方法では、CLARiX の MV/S または SnapView でのス

トレージ・ベースの整合性機能を使用して、一貫性のある Oracle の再起動可能イメージが作成され

ます。このイメージには、アーカイブ・ログを適用してデータベースをロール・フォーワードすることがで

き、データベースをホット・バックアップ・モードにする必要もありません。

ファスト（フラッシュ）・リカバリ領域フラッシュ・リカバリ領域は、Oracle 11gR2 ではファスト・リカバリ領域と名称が変更されました。ファス

ト・リカバリ領域は、制御ファイル、アーカイブ・ログ、フラッシュバック・ログなど、バックアップ/リカバリ

に関連したファイルの格納先となる、Oracle 管理のディスク・ストレージ・ロケーションです。ファスト・リ

カバリ領域を使用すると、Oracle Database の継続的な管理が容易になります。Oracle では、リカバ

リ・ファイル用に割り当てられたディスク・スペースを自動的に管理します。それらのファイルは、リスト

アやリカバリで必要とされる限り保持され、Orace Database のリストアに不要になった時点で削除さ

れます。

ファスト・リカバリ領域の最大サイズと、バックアップおよびアーカイブ・ログがリカバリ用に保存される期

間を判断する保存ポリシーは、ユーザーによって定義されます。ファスト・リカバリ領域で使用される領

域が指定された限度に達すると、Oracle がファスト・リカバリ領域内の既存のファイルで使用されなく

なったものの中から、最小限のセットを自動的に削除します。ファスト・リカバリ領域に十分なスペース

を割り当てることにより、より高速で簡単な Oracle Database の自動リカバリを確実に行うことができま

す。Oracle が推奨するディスク上限は、データベース・サイズ、増分バックアップのサイズ、および、

他のストレージにバックアップされていないすべてのアーカイブ・ログのサイズの合計です。また、ファ

スト・リカバリ領域は、メディア障害時に本番データベース・ファイルとバックアップの両方が消失する

のを防ぐため、本番データベースのファイルとは異なるディスクに配置する必要があります。ファスト・リ

カバリ領域の最大サイズを指定するには、SQL ステートメントの DB_RECOVERY_FILE_DEST_SIZEを使用し、場所を指定するには、DB_RECOVERY_FILE_DEST を使用します。

フラッシュバック・ログフラッシュ・リカバリ領域に保存されているフラッシュバック・ログは、Oracle によって生成されたログで、

データベースのフラッシュバック処理をサポートするために使用されます。Oracle がフラッシュバック・

ログのページに対するデータベース変更ページの収集を開始するためには、フラッシュバック機能を

有効にする必要があります。Oracle では、これらのログを使用して、過去の特定時点の状態にデータ

ベースをすばやく復旧させます。ロギングを有効にするには、「ALTER DATABASE FLASHBACK ON」SQL ステートメントを使用します。

Flashback Database Flashback Database プロセスでは、ファスト・リカバリ領域のフラッシュバック・ログを使用して、

Oracle Database を過去の特定時点（ポイント・イン・タイム）にすばやく復旧し、事前にデータベース

のバックアップをリストアする必要はありません。Flashback Database を使用するには、ファスト・リカ

バリ領域が構成されている必要があります。Oracle 10g リリース 2 以前の製品では、Flashback Database でサポートされていたのは、TIME または SCN へのフラッシュバックのみでした。Oracle 10g リリース 2 では、リカバリ・プロセスを簡略化するためにリストア・ポイントが追加されています。リス

トア・ポイントとは、ユーザが定義した名前であり、データベースエンジンはそれを既知のコミット済み

の SCN に内部でマッピングします。これにより、トランザクションの SCN や時間を特定する必要がな

くなります。このリストア・ポイント名と SCN のマッピングは、制御ファイルに保存されます。通常のリスト

ア・ポイントまたは保証されたリストア・ポイントは、次の SQL コマンドを使用していつでも作成できます。

CREATE RESTORE POINT restore_point [GUARANTEE FLASHBACK DATABASE]

通常のリストア・ポイントは、手動で削除しなくても、時間が経つと、最終的に制御ファイルから削除さ

れます。古くなったフラッシュバック・ログがフラッシュ・リカバリ領域から削除される場合、削除するかど

うかの判断は、ファスト・リカバリ領域のサイズ（DB_RECOVERY_FILE_DEST_SIZE データベース・パ



ラメータ）と指定された保存期間（DB_FLASHBACK_RETENTION_TARGET データベース・パラメー

タ）によって決まります。

一方、保証されたリストア・ポイントは、時間が経過しても制御ファイルから削除されることはないため、

明示的に削除する必要があります。保証されたリストア・ポイントを使用すると、そのリストア・ポイントに

復元するための十分なフラッシュバック・ログが常に保持されます。結果的に、保証されたリストア・ポ

イントは、フラッシュ・リカバリ領域で大量のスペースを消費することがあります。ファスト・リカバリ領域

のサイジング方法については、「Oracle Database バックアップおよびリカバリ・ユーザーズ・ガイド」を参照してください。

データベースを特定のリストア・ポイントに復元するには、次の SQL コマンドでそのリストア・ポイントの

名前を使用します。

FLASHBACK DATABASE TO RESTORE POINT restore_point

ASM（Automatic Storage Management） ASM は、Oracle Database ファイル用に開発された、Oracle のファイル・システムとボリューム・マ

ネージャです。ASM は、使用可能なすべてのストレージを ASM ディスク・グループに統合すること

により、データベース管理を簡略化します。ASM ディスク・グループは、ASM によって 1 つの論理ユ

ニットとしてまとめて管理される、1 台または複数のディスク・ドライブで構成されます。数千個に達する

こともあるデータベース・ファイルを直接管理するのではなく、これらのファイルを複数のディスク・グ

ループに分割して、ストレージの管理業務をディスク・グループ・レベルに削減します。テーブルス

ペース、制御ファイル、REDO ログ・ファイル、アーカイブ・ログ・ファイルが作成されると、これらのファ

イルを配置する場所がディスク・グループ単位で指定されます。さらに、ASM がファイル名を管理して、

データベース・ファイルの配置をディスク・グループ内で使用可能なすべてのストレージに分散します。

ストレージのアロケーション変更は、データベースをシャットダウンすることなく調整でき、データベース

の実行中でも、ディスク・グループに対してディスクを追加または削除できます。ASM は、I/O ロード

が平準化し、パフォーマンスが最適化されるように、ディスク・グループ内のすべてのディスクにわたっ

てデータを自動的に再配置（リバランス）します。

ASM のディスク・グループとしてディスク管理を行うには、データベースのインスタンスとは別に、

ASM のインスタンスが必要です。ASM のシングル・インスタンスで、1 つまたは複数のデータベー

ス・インスタンスを処理できます。データベースのインスタンスで ASM のファイルにアクセスできるよう

にするには、事前にこの ASM のインスタンスを構成して実行しておく必要があります。論理ボリュー

ム・マネージャとして機能する ASM インスタンスでは、ディスク・グループ内の各メンバー・ディスクの

変更を追跡する、ASM メタデータを更新する必要があります。ASM メタデータ自体も、ディスク・グ

ループのメンバー・ディスク上に置かれます。ASM メタデータはデータベース・ファイルとして同じメン

バー・ディスク・セットに保存されており、データベースそのものに対してユーザーによる変更が行われ

ない場合でも、ASM が自動的に動的にリバランスを行うため、メタデータの内容が更新されることが

あります。

ASM で管理される Oracle Database をレプリケートする場合、レプリカを他の目的に転用できるよう

にするには、レプリケーションの実行時に、ASM メタデータとデータベース・データの両方を整合性

のとれた状態にする必要があります。すなわち、あるディスク・グループ内のすべてのメンバー・ディス

クのコンテンツが変更されてはならないということです。現在のところ、ストレージ・ベースのレプリケー

ションを使用してすべてのディスク・メンバーが正しくレプリケートされるように、ASM インスタンスで、メ

タデータを含む ASM ディスク・グループを強制的に静止状態にする ASM 固有の機能はありません。

Oracle Database をホット・バックアップ・モードに切り替えることにより、データベースのデータを静止

状態にできますが、ASM のメタデータを簡単に静止状態にできる方法はありません。この状況で、

ASM ファイルを含むデータベースのバックアップを確実に実行する唯一の方法は、Oracle の

RMAN（Recovery Manager）ユーティリティを使用することです。

リリース 19 以降でサポートされる SnapView および MV/S のコンシステンシ・レプリケーションを使

用すると、ASM のメタデータとデータベース・データの両方を、ポイント・イン・タイムの整合性のとれ



たセットとしてストレージにレプリケートできます。SnapView スナップショット・コンシステント・セッショ

ン、SnapView クローン・セット・コンシステント・フラクチャ、MV/S コンシステンシ・グループのフラク

チャを使用して、ASM のディスク・メンバーをセットでレプリケートすると、ASM メタデータを静止状態

にする必要がなくなります。ASM ディスク・メンバーがポイント・イン・タイムの整合性のとれたセットとし

てストレージにレプリケートされる限り、ASM は、ASM インスタンスをクラッシュ・リスタートし、ASMディスク・グループを正しくマウントすることができます。

ストレージ・ベースのコンシステンシ・レプリケーションを使用し

たオンライン Oracle 11gR2 データベースのレプリケーション

とリカバリこのセクションでは、SnapView スナップショット、SnapView クローン、および MV/S の整合性機能

を使用して ASM で管理されるオンラインの Oracle 11gR2 Database をレプリケートする場合の、

データの整合性と動作の正確性を保証するためのテストについて説明します。ここで取り上げる

Oracle 11gR2 と CLARiX レプリケーション・ソフトウェアの詳細については、「関連資料」セクション

の対応するドキュメントを参照してください。すべてのテスト・シナリオにおいて、コンシステンシ・レプリ

ケーション・プロセスの間、Oracle Database のホット・バックアップ・モードへの切り替えは行いませ

んでした。ASM リバランシングがある状態およびない状態でのレプリケーションと、Flashback Database を使用したリカバリについても説明します。Oracle Database 10/11g/11gR2 に関連す

るすべてのテストは、OEL 5 Update 2 を実行する Linux x86 および x86_64 および Windows Server 2003 Version 5.2 Service Pack 1 の両方のプラットフォームで実施しました。

図 5は、ストレージ・ベースのコンシステンシ・レプリケーションと Oracle フラッシュバック・テクノロジー

の Flashback Database 機能を使用して、Oracle 11gR2 Database をレプリケートし、その後でリカ

バリするために必要なステップのハイレベルの概要図です。

図 5. ストレージ・ベースの整合性レプリケーションとリカバリ

データベース・ファイルのレイアウト ASM 管理の Oracle 本番データベース・ファイルは、CX4-120 CLARiX ストレージ・アレイに配置さ

れています。すべてのテスト・ケースでは、従来の（トラディショナルな）LUN を含むレプリケーション・

テクノロジーのテスト用に RAID グループから 6 つの 4+1 RAID 5 LUN を作成し、シン LUN を含

むレプリケーション・テクノロジーのテスト用にストレージ・プールから 6 つの 4+1 RAID 5 シン LUNを作成しました。LUN のタイプを除くと、ファイル・レイアウトの点では、従来の LUN とシン LUN のす



べてのテスト・ステップはまったく同じです。SnapView クローンのテストでは、同数の LUN を同じスト

レージ・アレイ上にバインドし、対応する本番 LUN と同期化しました。MirrorView のテストでは、本番

LUN を別個の CLARiX CX4-120 ストレージ・アレイ上の対応する LUN にミラーしました。これらの

6 つの本番 LUN は、外部冗長性を指定して作成された、次の 4 つの ASM ディスク・グループに分

割しました。

• DATA_DGRP ディスク・グループには、すべてのデータベース・ファイルと制御ファイルが含まれ

ます。このグループのメンバー・ディスク（LUN）は、次のとおりです。

LUN 10、LUN 11 • REDO_DGRP ディスク・グループには、オンライン REDO ログが含まれます。このグループのメン

バー・ディスク（LUN）は、次のとおりです。

LUN 12、LUN 13 • RECOVR_DGRP ディスク・グループには、フラッシュバック・ログと多重化された制御ファイルが

含まれます。このグループのメンバー・ディスク（LUN）は、次のとおりです。 LUN 14

• ARCH_DGRP ディスク・グループには、アーカイブ REDO ログが含まれます。このグループのメ

ンバー・ディスク（LUN）は、次のとおりです。 LUN 15

ASM インスタンスのパラメータ・ファイル Oracle 11gR2 Database で ASM 管理ファイルを使用する場合、通常のデータベース・インスタン

スに加えて ASM インスタンスが必要となります。通常のデータベース・インスタンスと同様に、ASM イ

ンスタンスには固有の初期化パラメータ・ファイル（init*.ora）があります。通常のデータベース・インス

タンスと異なる点は、ASM インスタンスに物理ファイルが含まれず、必須パラメータが

INSTANCE_TYPE = ASM の 1 つのみだということです。このパラメータは、Oracle にデータベー

ス・インスタンスではなく ASM インスタンスを開始するよう通知するものです。これ以外のすべての

ASM 関連のパラメータでは、ユーザーが設定しない場合、適切なデフォルトが使用されます。この

ASM インスタンスの init*.ora ファイルには、以下の初期化パラメータを設定しました。

INSTANCE_TYPE = ASM ASM_DISKGROUPS = (DATA_DGRP, REDO_DGRP, RECOVR_DGRP, ARCH_DGRP) LARGE_POOL_SIZE = 12M

データベース・インスタンスのパラメータ・ファイル ASM ディスク・グループに関連する以下の初期化パラメータが、このデータベース・インスタンスの

init*.ora ファイルに設定されました。

INSTANCE_TYPE = RDBMS DB_NAME = TestDB CONTROL_FILES = (‘+DATA_DGRP/ctl1TestDB.ctl’, ‘+DATA_DGRP/ctl2TestDB.ctl’) DB_RECOVERY_FILE_DEST_SIZE = 50G DB_RECOVERY_FILE_DEST = ‘+RECOVR_DGRP’ LOG_ARCHIVE_DEST_1 = ‘LOCATION=+ARCH_DGRP’

SnapView の整合性機能を使用したレプリケーション Oracle Database をレプリケートするための SnapView スナップショットまたは SnapView クローン

の設定に必要なステップは、非コンシステントまたはコンシステント・レプリケーションのどちらでも同じ

です。設定の詳細については、「EMC Unisphere Help 6.30」および「EMC SnapView Command Line Interface (CLI) Reference」で説明されています。非コンシステント・レプリケーションとコンシス

テント・レプリケーションの主な相違点は、イメージのキャプチャ方法にあります。このセクションでは、



SnapView スナップショットおよび SnapView クローンを使用してオンラインのデータベースのコンシ

ステント・レプリケーションをキャプチャするために必要なステップについて説明します。

すべてのスナップショットおよびクローンの例では、以下を前提とします。

• アーカイブ、REDO ログ、フラッシュバック・ログなどを含む本番データベース・ファイルは、ASM管理ファイルとして構成された 6 つの LUN の間で分散される。

• SnapView スナップショット、クローン・グループ、およびクローンが適切に作成され、設定されて

いる。 • ASM インスタンスが実行中である。 • データベースがアーカイブログ・モードで実行され、フラッシュ・リカバリ領域とフラッシュバック・ロ

グが有効である。 • データベースが現在オープンされており、本番サーバからのアクティブなトランザクションが継続

中である。 • レプリケーション実行中に、データベースをホット・バックアップ・モードにしない。 • データベース・ファイル、REDO ログ・ファイル、フラッシュバック・ログを格納した LUN がセットで

レプリケートされる。 • アーカイブ・ログを格納した LUN は、別個のセットとしてレプリケートする。

SnapView スナップショット・コンシステント・セッション開始の使用 SnapView スナップショット・コンシステント・セッションを開始するには、必要なすべてのソース LUNを選択し、それらに対して Navisphere CLI の「snapview –startsession」コマンドに「-consistent」スイッチを指定して実行します。このレプリケーション・セットは、一貫性のある再起動可能な Oracle Database のイメージです。キャプチャされたアーカイブ・ログを使用してこの再起動可能なイメージを

ロール・フォーワードするには、スナップ・セッションの開始前後に特定の準備作業が必要となります。

これには、セッション開始前における「リストア・ポイント」の作成や、セッション開始後における、アク

ティブな REDO ログがアーカイブおよびキャプチャされたことの確認などの作業があり、すべて本番

サーバから実行します。

1. 新しいフラッシュバック・リストア・ポイントを作成します。

sqlplus /nolog SQL> connect sys/manager as sysdba SQL> drop restore point at3pm SQL> create restore point at3pm;

このコマンドを実行すると、「at3pm」という名前の通常のリストア・ポイントが作成されます。この名

前は、その時点のデータベースの SCN の別名です。前述したように、通常のリストア・ポイントは、

フラッシュ・リカバリ領域のサイズと指定された保存期間（デフォルトは 1,440 分）に応じて時間の

経過とともに削除されます。指定されたリストア・ポイントのフラッシュバック・ログが時間の経過に

より削除されないようにするには、次の SQL コマンドを代わりに使用して、保証されたリストア・ポ

イントを作成します。

SQL> create restore point at3pm guarantee flashback database;

2. データベース・ファイル、REDO ログ・ファイル、フラッシュバック・ログを格納した LUN の

SnapView スナップショット・コンシステント・セッションを開始します。

naviseccli –h primary_array snapview –startsession sessionname –lun luns -consistent

例： naviseccli –h CX4-1202a snapview –startsession 3pmDataSession –lun 10 11 12 13 14 –consistent



この Navisphere CLI コマンドを実行すると、「3pmArchSession」という名前のコンシステント・

セッションが LUN 10、11、12、13、および 14 で開始されます。これらの LUN は、ASM ディス

ク・グループの DATA_DGRP、REDO_DGRP、および RECOVR_DGRP のメンバー・ディスクです。

このコマンドの実行は、わずか数秒で完了します。コマンド実行が完了すると、整合性のあるポイ

ント・イン・タイムの再起動可能なデータベース・イメージがキャプチャされ、セカンダリ・サーバ上

で使用可能になります。

3. アーカイブされていないすべてのログをアーカイブします。

sqlplus /nolog SQL> connect / as sysdba SQL> alter system archive log current; SQL> select ‘NextChange’, next_change# from v$log_history where recid= (select max(recid) from v$log_history); SQL> alter database backup controlfile to trace resetlogs;

NEXTCHANGE NEXT_CHANGE# ---------------------- ------------------------ NextChange 70760

すべてのアクティブな REDO ログは、ASM ディスク・グループの ARCH_DGRP にアーカイブされ

ます。これらのアーカイブ・ログは、ステップ 2 でキャプチャされたポイント・イン・タイムのデータ

ベース・イメージをリカバリする際に必要となります。

4. アーカイブ・ログを格納した LUN の SnapView スナップショット・コンシステント・セッションを開始

します。

naviseccli –h primary_array snapview –startsession sessionname –lun luns -consistent

例： naviseccli –h CX4-1202a snapview –startsession 3pmArchSession –lun 15 –consistent

この Navisphere CLI コマンドを実行すると、「3pmDataSession」という名前のコンシステント・

セッションが LUN 15 で開始されます。この LUN は、ASM ディスク・グループの ARCH_DGRPに含まれています。アーカイブ・ログを含むこのレプリケートされた LUN に Oracle の Flashback Database 機能を使用すると、再起動後のデータベースを、ステップ 1 のリストア・ポイント

「at3pm」でキャプチャされた既知の SCN にフラッシュバックし、さらに、アーカイブ・ログを使用

してロール・フォーワードすることができます。

この時点で、ログの適用が可能となる、有効な Oracle バックアップを生成するために必要な、すべて

のファイルがキャプチャされました。「Oracle 11gR2 の Flashback Database 機能を使用したリカバ

リ」のセクションでは、有効な Oracle バックアップを作成するためにデータベース LUN のレプリケー

ション・セットをリカバリして使用する手順について説明しています。

SnapView クローンのコンシステント・フラクチャの使用 SnapView クローンのコンシステント・フラクチャ機能は、セットでフラクチャする必要のあるすべてのク

ローン LUN を特定して、Navisphere CLI の「snapview –consistentfractureclones」コマンドを実

行することにより、これらのクローン間で再起動可能なポイント・イン・タイムのコピーを維持します。こ

のクローン・セットは、同じストレージ・システム上で異なるクローン・グループに属している必要があり

ます。このレプリケートされたクローン・セットは、一貫性のある再起動可能な Oracle Database のイ

メージです。キャプチャされたアーカイブ・ログを使用してこの再起動可能なイメージをロール・フォー

ワードするには、クローン・セットをフラクチャする前後に特定の準備作業が必要となります。これには、

フラクチャする前の「リストア・ポイント」の作成や、フラクチャが正常に完了した後に行う、アクティブな



REDO ログがアーカイブおよびキャプチャされたことの確認などの作業があり、すべて本番サーバか

ら実行します。


sqlplus /nolog SQL> connect sys/manager as sysdba SQL> drop restore point at3pm; SQL> create restore point at3pm;

このコマンドを実行すると、「at3pm」という名前の通常のリストア・ポイントが作成されます。この名

前は、その時点のデータベースの SCN の別名です。前述したように、通常のリストア・ポイントは、

フラッシュ・リカバリ領域のサイズと指定された保存期間（デフォルトは 1,440 分）に応じて時間の

経過とともに削除されます。指定されたリストア・ポイントのフラッシュバック・ログが時間の経過に

より削除されないようにするには、次の SQL コマンドを代わりに使用することで、保証されたリスト

ア・ポイントが作成されます。


2. データベース・ファイル、REDO ログ・ファイル、フラッシュバック・ログを含む各クローン LUN が、

Synchronized（同期）または Consistent（コンシステント）状態にあることを確認します。

naviseccli –h primary_array snapview –listclone –name clone_groupname –cloneid id –CloneState

例： naviseccli –h CX4-1202a snapview –listclone –name Data1CGroup –cloneid 0100000000000000 –CloneState

naviseccli –h CX4-1202a snapview –listclone –name Redo1CGroup –cloneid 0100000000000000 –CloneState

naviseccli –h CX4-1202a snapview –listclone –name RecovrCGroup –cloneid 0100000000000000 –CloneState

3. ステップ 2 でクローンの状態が Synchronized（同期）または Consistent（コンシステント）のいず

れかであることが確認されたら、このクローン LUN セットについて単一の SnapView コンシステ

ント・クローン・フラクチャを実行します。

naviseccli –h primary_array snapview –consistentfractureclones –CloneGroupNameCloneID name1 cloneId1 ... nameN cloneIdN –o

例： naviseccli –h CX4-1202a snapview –consistentfractureclones -CloneGroupNameCloneID Data1CGroup 0100000000000000 Data2CGroup 0100000000000000 Redo1CGroup 0100000000000000 Redo2CGroup 0100000000000000 RecovrCGroup 0100000000000000 –o

この Navisphere CLI コマンドを実行すると、クローン ID が 0100000000000000 のクローン

LUN をクローン・グループ Data1CGroup、Data2CGroup、Redo1CGroup、Redo2CGroup、および RecovrCGroup からフラクチャします。これらの LUN は、10、11、12、13、および 14の各ソース LUN（ASM ディスク・グループ DATA_DGRP、REDO_DGRP、および RECOVR_DGRPのメンバー・ディスク）のクローンです。フラクチャが完了すると、選択したクローン・セットが整合性

のあるポイント・イン・タイムの再起動可能なデータベース・イメージとなり、セカンダリ・サーバで使

用可能になります。


sqlplus /nolog



SQL> connect / as sysdba SQL> alter system archive log current; SQL> select ‘NextChange’, next_change# from v$log_history where recid= (select max(recid) from v$log_history); SQL> alter database backup controlfile to trace resetlogs;





5. アーカイブ・ログを格納するクローン LUN が Synchronized（同期）または Consistent（コン

システント）状態（ステップ 2 を参照）のいずれかであることを確認したら、このクローン LUN で

SnapView のフラクチャを開始します。アーカイブ・ログが複数の LUN に分散されている場

合、ステップ 3 の手順に従って、–consistentfractureclones コマンドを使用するクローンの

コンシステント・フラクチャを開始する必要があります。

naviseccli –h primary_array snapview –fractureclones –name clone_groupname –cloneid id –o

例： naviseccli –h CX4-120b snapview –fractureclone –name ArchCGroup –cloneid 0100000000000000 –o

この Navisphere CLI コマンドを実行すると、クローン ID が 0100000000000000 のクローン

LUN がクローン・グループ ArchCGroup からフラクチャされます。この LUN は、ソース LUN 15（ASM ディスク・グループ ARCH_DGRP のメンバー・ディスク）のクローンです。このレプリケートさ

れた LUN にはアーカイブ・ログが含まれるため、Oracle の Flashback Database 機能を使用し

て、再起動後のデータベースをステップ 1 のリストア・ポイント「at3pm」でキャプチャされた既知

の SCN にフラッシュバックし、さらに、アーカイブ・ログを使用してロール・フォーワードすることが

できます。


のファイルがキャプチャされました。「Oracle 11gR2 の Flashback Database 機能を使用したリカバ

リ」のセクションでは、有効な Oracle バックアップを作成するためにデータベース LUN のレプリケー

ション・セットをリカバリして使用する手順について説明しています。

MirrorView/S コンシステンシ・グループを使用したレプリケーション複数の LUN に分散された Oracle Database のミラー・イメージをキャプチャする場合に、相互に依

存した書き込み順序の整合性を維持するには、MirrorView のコンシステンシ・グループ機能が必要

です。コンシステンシ・グループとは、単一のエンティティとして管理されるミラーのセットで、ミラー相

互の整合性が常に維持されている必要があります。MirrorView が Oracle Database を異なるスト

レージ・システムにミラーするためには、プライマリおよびセカンダリ・イメージを設定するステップが必

須ですが、さらに、コンシステンシ・グループを作成して設定する必要があります。このセクションでは、

コンシステンシ・グループを設定するステップを説明します。この手順では、MirrorView/S のコンシス

テンシ・グループのフラクチャを使用して、オンラインの Oracle Database のコンシステント・レプリ

ケーションを支援し、さらに、セカンダリ・ストレージで SnapView を使用して、セカンダリ・イメージの

ローカル・レプリカを作成します。ミラー・イメージおよびコンシステンシ・グループの設定の詳細につ

いては、「 EMC Unisphere Manager Help 6.30 」および「 EMC MirrorView/Synchronous Command Line Interface (CLI) Reference」を参照してください。

MV/S のすべての例では、以下を前提とします。



• アーカイブ、REDO ログ、フラッシュバック・ログなどの本番データベース・ファイルは、ASM 管理

ファイルとして構成され、6 つの LUN の間で分散される。 • ストレージ・システム間に MirrorView 接続が確立されている。 • セカンダリ・イメージを含むリモート・ミラー（LUN 20、21、22、23、24、25）が正しく作成および

設定されている。 • ASM インスタンスが実行中である。 • データベースがアーカイブログ・モードで実行され、フラッシュ・リカバリ領域とフラッシュバック・ロ

グが有効である。 • データベースが現在オープンしており、本番サーバからのアクティブなトランザクションが継続中

である。 • レプリケーション実行中に、データベースをホット・バックアップ・モードにしない。 • データベース・ファイル、REDO ログ・ファイル、フラッシュバック・ログを格納した LUN が、1 つの

コンシステンシ・グループに属している。 • アーカイブ・ログを格納した LUN は、別のコンシステンシ・グループに属している。

MirrorView/S コンシステンシ・グループの作成 SnapView スナップショットのスタート・セッションやクローン・コンシステント・フラクチャ機能と同じく、

コンシステンシ・グループを作成する最初のステップは、関連する LUN の間で書き込み順序の整合

性を維持するためにセットでミラーする必要がある、データベース・ソース LUN を判別することです。

これにより、作成するコンシステンシ・グループの数も決まります。次の例では、データベース・ファイル、

REDO ログ・ファイル、フラッシュバック・ログを格納する LUN と、アーカイブ・ログを格納する LUN の

ための、2 つのコンシステンシ・グループを作成します。

1. 本番サーバから、本番（プライマリ）ストレージ・システム上で 2 つの MV/S コンシステンシ・グ

ループを作成します。

naviseccli –h primary_array mirror –sync –creategroup -name consistency_groupname –o

例： naviseccli –h CX4-1202a mirror –sync –creategroup -name mirrorDB_CGroup -o naviseccli –h CX4-120b mirror –sync –creategroup -name mirrorARCH_CGroup –o

この Navisphere CLI コマンドを実行すると、mirrorDB_CGroup と mirrorARCH_CGroupという名前の 2 つのコンシステンシ・グループがプライマリ・ストレージ・システム上に作成されます。

2. 本番サーバから、以前に作成したコンシステンシ・グループにミラーを追加します。

naviseccli –h primary_array mirror –sync –addtogroup -name consistency_groupname –mirrorname mirror_name

例： naviseccli –h CX4-1202a mirror –sync –addtogroup -name mirrorDB_CGroup -mirrorname Data1_mirror naviseccli –h CX4-1202b mirror –sync –addtogroup -name mirrorARCH_CGroup –mirrorname Arch_mirror

–addtogroup コマンドを使用してコンシステンシ・グループに一度に追加できるリモート・ミラーは、

1 つのみです。この –addtogroup コマンドを繰り返し実行して、リモート・ミラーの

Data1_mirror 、 Data2_mirror 、 Redo1_mirror 、 Redo2_mirror 、および

Flash_mirror をすべてコンシステンシ・グループ mirrorDB_CGroup のメンバーにします。

コンシステンシ・グループが作成され、1 つまたは複数のミラーが追加されると、MV/S は、セカンダ

リ・システム・システムで同じ名前とコンテンツを持つコンシステンシ・グループを自動的に作成します。



ミラーがコンシステンシ・グループに追加された後は、ミラーを個別に管理することはできなくなります。

コンシステンシ・グループ・コマンドを使用して、グループとして管理する必要があります。

MirrorView/S コンシステンシ・グループの使用 MirrorView/S コンシステンシ・グループのフラクチャを実行するには、コンシステンシ・グループの名

前を Navisphere CLI の「mirror –sync –fracturegroup」コマンドに指定します。コンシステンシ・グ

ループは、フラクチャを実行する前に Synchronized（同期）または Consistent（コンシステント）状態

である必要があります。フラクチャの実行後は、セカンダリ・イメージへの I/O アクセスが可能になるよう

に、セカンダリ・ストレージ・システム上の対応するコンシステンシ・グループをプロモート、スナップ、ま

たはクローン・フラクチャできます。セカンダリ・ストレージ・システム上のこのミラー・セットは、一貫性の

ある再起動可能な Oracle Database のイメージです。キャプチャされたアーカイブ・ログを使用してこ

の再起動可能なイメージをロール・フォーワードするには、コンシステンシ・グループをフラクチャする

前後に特定の準備作業が必要となります。これには、フラクチャする前の「リストア・ポイント」の作成や、

フラクチャが正常に完了した後に行う、アクティブな REDO ログがアーカイブおよびキャプチャされた

ことの確認などの作業があり、すべて本番サーバから実行します。


sqlplus /nolog SQL> connect sys/manager as sysdba SQL> drop restore point at3pm; SQL> create restore point at3pm;

このコマンドを実行すると、「at3pm」という名前の通常のリストア・ポイントが作成されます。この

名前は、その時点のデータベースの SCN の別名です。通常のリストア・ポイントは、フラッシュ・

リカバリ領域のサイズと指定された保存期間（デフォルトは 1,440 分）に応じて時間の経過ととも

に削除されます。指定されたリストア・ポイントのフラッシュバック・ログが時間の経過により削除さ

れないようにするには、次の SQL コマンドを代わりに使用して、保証されたリストア・ポイントを作

成します。


2. データベース・ファイル、REDO ログ・ファイル、フラッシュバック・ログを含むコンシステンシ・グ

ループが、Synchronized（同期）または Consistent（コンシステント）状態のいずれかであること

を確認します。

naviseccli –h primary_array mirror -sync –listgroups –name consistency_groupname –state

例： naviseccli –h CX4-1202a mirror -sync –listgroups –name mirrorDB_CGroup –state

3. ステップ 2 でコンシステンシ・グループが Synchronized（同期）または Consistent（コンシステ

ント）状態のいずれかであることを確認できたら、コンシステンシ・グループのフラクチャを開始し

ます。

naviseccli –h primary_array mirror -sync –fracturegroup -name consistency_groupname –o

例： naviseccli –h CX4-1202a mirror -sync –fracturegroup -name mirrorDB_CGroup –o

この Navisphere CLI コマンドを実行すると、コンシステンシ・グループの mirrorDB_CGroupですべてのミラー・イメージがフラクチャされます。このコンシステンシ・グループのメンバーとなる



のは、ソース LUN 10、11、12、13、14 と、セカンダリ・ストレージ・システム上の対応するミラーさ

れた LUN（ASM ディスク・グループ DATA_DGRP、REDO_DGRP、RECOVR_DGRP のメンバー・

ディスク）です。フラクチャが完了すると、セカンダリ・ストレージ上の対応するイメージが整合性の

あるポイント・イン・タイムの再起動可能なデータベース・イメージとなり、セカンダリ・サーバで使用

可能になります。


sqlplus /nolog SQL> connect / as sysdba SQL> alter system archive log current; SQL> select ‘NextChange’, next_change# from v$log_history where recid= (select max(recid) from v$log_history); SQL> alter database backup controlfile to trace resetlogs;





5. アーカイブ・ログを格納するコンシステンシ・グループが Synchronized（同期）または

Consistent（コンシステント）状態（ステップ 2 を参照）であることを確認したら、コンシステンシ・グ

ループのフラクチャを開始します。

naviseccli –h primary_array mirror –sync –fracturegroup -name consistency_groupname –o

例： naviseccli –h CX4-1202b mirror –sync –fracturegroup -name mirrorARCH_CGroup –o

この Navisphere CLI コマンドを実行すると、コンシステンシ・グループ mirrorARCH_CGroup内のすべてのミラー・イメージがフラクチャされます。このコンシステンシ・グループのメンバーにな

るのは、ソース LUN 15 と、セカンダリ・ストレージ・システム上の対応するミラーされた LUN（ASM ディスク・グループ ARCH_DGRP のメンバー・ディスク）です。このコンシステンシ・グルー

プ内のセカンダリ・ミラー・イメージにはアーカイブ・ログが含まれるため、Oracle の Flashback Database 機能を使用して、再起動後のデータベースをステップ 1 のリストア・ポイント「at3pm」でキャプチャされた既知の SCN にフラッシュバックし、さらに、アーカイブ・ログを使用してロー

ル・フォーワードすることができます。


のファイルがセカンダリ・ストレージ・アレイでキャプチャされました。これで、SnapView スナップショッ

トまたはクローンを使用して、セカンダリ・ストレージ・アレイ上のセカンダリ・ミラー・イメージのレプリカ

をすばやく作成できます。どちらの方法でも高いレベルの保護が提供されますが、クローンの場合、さ

らに高いディスク保護を提供し、スナップショットよりパフォーマンス・インパクトが抑えられます。

SnapView の処理が完了すると、ミラーリング関係が再度確立されます。

MirrorView/S コンシステンシ・グループでの SnapView の使用 SnapView スナップショットおよび SnapView クローンをセカンダリ・ストレージ上で MirrorView/S と

連携して使用すると、セカンダリ・イメージのローカル・レプリカが利用できます。これにより、セカンダ

リ・イメージをプロモートしなくても、セカンダリ・ストレージでセカンダリ・サーバがデータにアクセスでき

るようになります。SnapView の整合処理は、コンシステンシ・グループ・レベルでは実行できず、コン

システンシ・グループの各メンバーに対して実行する必要があります。



ミラーされたセカンダリ・イメージの SnapView スナップショット・コンシステント・セッションを開始する

には、次の手順に従います。

1. セカンダリ・サーバで、データベース・ファイル、REDO ログ・ファイル、フラッシュバック・ログを

格納した LUN のスナップショット・コンシステント・セッションを開始します。

naviseccli –h CX4-1203a snapview –startsession 4pmDataSession –lun 20 21 22 23 24 –consistent

2. セカンダリ・サーバで、アーカイブ・ログを格納した LUN のスナップショット・コンシステント・

セッションを開始します。

naviseccli –h CX4-1203b snapview –startsession 4pmArchSession –lun 25 –consistent

ミラーされたセカンダリ・イメージの SnapView クローン・コンシステント・セッションを開始するには、

次の手順に従います。

1. セカンダリ・サーバで、データベース・ファイル、REDO ログ・ファイル、フラッシュバック・ログを

格納した LUN のクローン・コンシステント・フラクチャを開始します。

naviseccli –h CX4-1,203a snapview –consistentfractureclones -CloneGroupNameCloneID Data1CGroup 0100000000000000 Data2CGroup 0100000000000000 Redo1CGroup 0100000000000000 Redo2CGroup 0100000000000000 RecovrCGroup 0100000000000000 –o

2. セカンダリ・サーバで、アーカイブ・ログを格納した LUN のコンシステント・セッションを開始し

ます。

naviseccli –h CX4-1203b snapview –fractureclone –name ArchCGroup –cloneid 0100000000000000 –o

次の「Oracle 11gR2 の Flashback Database 機能を使用したリカバリ」のセクションでは、有効な

Oracle バックアップを作成するためにデータベース LUN のレプリケーション・セットをリカバリして使

用する手順について説明しています。

Oracle 11gR2 の Flashback Database 機能を使用したリカバリセカンダリ・サーバからスナップショットやフラクチャ後のクローンにアクセスするためには、それらがセ

カンダリ・サーバに接続されたストレージ・グループに属していることが必要です。さらに、スナップ

ショットが SnapView セッションでアクティブ化され、セカンダリ・サーバにマウントされている必要があ

ります。フラクチャ・クローンについては、セカンダリ・サーバにマウントする操作のみ必要です。スト

レージ・グループの設定とスナップショットのアクティブ化の詳細については、「EMC Unisphere Help 6.30」を参照してください。このセクションでは、ストレージ・ベースの整合性機能を使用してキャプ

チャされた LUN のレプリケーション・セットから、データベースをマウント、起動、およびリカバリするた

めに必要なステップについて説明します。

LUN のレプリケーション・セットをキャプチャした手段が SnapView スナップショット、SnapView ク

ローン、または MirrorView/S コンシステンシ・グループのいずれであっても、Oracle の起動およびリ

カバリのプロセスは同じです。このプロセスでは、以下の条件を前提とします。

• セカンダリ・サーバは、本番サーバと OS が同じで、同じバージョンの Oracle 11gR2 を実行して

いる。 • LUN のレプリケーション・セットは、セカンダリ・サーバへのアクセスが可能である。 • セカンダリ・サーバで ASM インスタンスが開始されている。

ストレージ・レプリケーションした LUN のセットは、対応するソース LUN とビット・レベルで同一です。

また、ASM ディスクのシグネチャ情報が同じであるため、同じ ASM ディスク・グループに属していま

す。これらの LUN をセカンダリ・サーバにアクセス可能にした後、以下の SQL コマンド例を使用して、

これらの LUN を ASM インスタンスによりマウントする必要があります。



$sqlplus /nolog SQL> connect / as sysdba SQL> alter diskgroup DATA_DGRP mount; SQL> alter diskgroup REDO_DGRP mount; SQL> alter diskgroup RECOVR_DGRP mount; SQL> alter diskgroup ARCH_DGRP mount;

ASM インスタンスで LUN のレプリケーション・セットがマウントされると、論理的には、ASM ディスク・

グループが最後に使用してからオープンされたままの状態であるものと見なされます。このため、

ASM は、変更途中だった ASM メタデータをリカバリするために必要なステップを実行します。ディス

ク・グループがマウントされると、Oracle Database のインスタンスを再起動したり、LUN がレプリケー

トされる前にキャプチャされたリストア・ポイントにデータベースをフラッシュバックしたりすることができ

ます。

$sqlplus /nolog SQL> connect / as sysdba SQL> startup mount; SQL> flashback database to restore point at3pm;

フラッシュバック・コマンドが正常に実行されると、データベースはマウントされた状態で、指定したリス

トア・ポイントにリカバリされます。データベースが指定したポイント・イン・タイムに復旧されたことを確

認するには、データベースを読み取り専用モードで開き、データベースのコンテンツを検査するクエ

リーを実行します。

この時点で、レプリケーション・プロセス中にキャプチャされたアーカイブ・ログのセットを使用し、デー

タベースをどれだけ先に進めるか（チェンジ・ナンバーまたは特定のポイント・イン・タイムまで）を指示

することにより、データベースをリカバリしてロール・フォーワードすることができます。その後、Oracle Database を更新可能な状態にすることができます。次の例では、SQL コマンドの「recover」を実行

することにより、「SnapView スナップショット・コンシステント・セッション開始の使用」セクション

のステップ 3 でキャプチャされた変更番号までデータベースが復旧されます。

SQL> recover automatic database until change 70760 using backup controlfile; SQL> shutdown SQL> startup mount; SQL> alter database open resetlogs; レプリケートされた Oracle Database は、転用または耐久性の高いメディアへのバックアップに適し

た、完全に使用可能なデータベースになります。



整合性テストの表と結果以下に示すすべてのテスト・ケースは、従来の LUN とシン LUN の両方を使用して実施されました。

テスト結果

実行

回数スナップ・セッ

ション開始クローン・フラク

チャ MV/S フラクチャ

フラッシュバック有効データベースはホット・バックアップ・

モードではない

正常に再起動、

フラッシュバッ

ク、ロール・

フォーワード

正常に再起動、フ

ラッシュバック、

ロール・フォー

ワード



ク、ロール・

フォーワード

5

フラッシュバック有効データベースはホット・バックアップ・

モードではないディスク・グループのリバランス実

行中



ク、ロール・

フォーワード

正常に再起動、フ

ラッシュバック、

ロール・フォー

ワード



ク、ロール・

フォーワード 5

フラッシュバック無効データベースはホット・バックアップ・

モードではないディスク・グループのリバランス実

行中

正常に再起動正常に再起動正常に再起動

5



まとめ SnapView および MirrorView/S の整合性機能は、データベースのレプリケーションを必要とする

Oracle 環境を合理化します。レプリケーション・プロセスの間に Oracle Database をホット・バックアッ

プ・モードに切り替える必要がないため、ホスト側のパフォーマンスへのインパクトが最小限に抑えら

れます。これにより、使いやすいデータベースのレプリカをより頻繁に作成することが、運用上可能に

なります。ASM 管理ファイルを使用した Oracle Database のレプリケーションも、簡略化されます。

SnapView または MirrorView の整合性機能を使用して ASM ディスク・メンバーをセットでレプリ

ケートする場合、ASM が再起動のために必要なメタデータも同時にレプリケートされます。ASM メタ

データの整合性を確保するための手動操作は不要です。ASM は、ASM インスタンスをクラッシュ・リ

スタートし、ASM ディスク・グループを再マウントすることができます。Oracle Database に対する

CLARiX ストレージ・ベースのコンシステント・レプリケーションでは、ソースのポイント・イン・タイムのレ

プリカ作成と書き込み順序の整合性が保証されます。このレプリケーション・セットは、一貫性のある再

起動可能な Oracle イメージです。これらを Oracle 11gR2 ファスト・リカバリ領域および Flashback Database 機能と連携させることにより、キャプチャされたアーカイブ・ログを使用してデータベースを

ロール・フォーワードすることができます。ストレージ・ベースのコンシステント・レプリケーションと

Oracle 11gR2 のフラッシュバック機能を組み合わせて使用すると、本番サーバにインパクトを与えず

に、有効かつ適正な Oracle バックアップを作成することができます。

関連資料

製品資料 • 「Oracle Database バックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース 1（11.1）」

• 「Oracle Database 概念 11g リリース 1（11.1）」

• 「EMC Unisphere Help 6.30」

• 「EMC SnapView Command Line Interfaces（CLI）Reference」

• 「EMC MirrorView/Synchronous Command Line Interface（CLI）Reference」

• 「Oracle Database 概念 11g リリース 2（11.2）」

ホワイト・ペーパー • 「MirrorView Knowledgebook - Applied Technology」

• 「Enterprise Flash Drives and Unified Storage – Technology Concepts and Business Considerations」

• 「EMC CLARiiON Virtual Provisioning – Applied Technology」

• 「EMC FAST for CLARiiON」

• 「EMC CLARiiON and Celerra Unified FAST Cache」

emc clarix ストレージ・ソリューション： oracle … clarix...

Documents