EMC CLARiiON Storage Solutions: Oracle Database 10g/11g/11gR2 with CLARiiON Storage Replication Consistency

Transcription

1 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 月

2 Copyright 2006, 2008, 2010 EMC Corporation. All rights reserved. このドキュメントに記載されている情報は ドキュメントの出版日現時点の情報です この情報は予告なく変更されることがあります 本文書に記載される情報は 現状有姿 (AS IS) の条件で提供されています EMC Corporation は この資料に記載される情報に関する どのような内容についても表明保証条項を設けず 特に 商品性や特定の目的に対する適応性に対する黙示の保証はいたしません 本書に記載された EMC ソフトウェアの使用 複製 配布については 適用されるソフトウェアライセンスを必要とします 最新の EMC 製品名リストについては にある EMC Corporation の商標 を参照してください 他のすべての名称ならびに製品についての商標は それぞれの所有者の商標または登録商標です パーツ番号 :H J Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 2

3 目次 エグゼクティブ サマリー... 5 概要... 5 対象者... 5 用語... 6 CLARiX データ レプリケーション テクノロジー... 6 CLARiX ストレージ システム... 7 CLARiX レイヤード ソフトウェア... 8 SnapView の概要... 8 SnapView スナップショット... 9 SnapView クローン MV/S(MirrorView/Synchronous) の概要 SnapView と MirrorView/S における整合性 SnapView スナップショットの整合性 SnapView クローン (BCV) の整合性 MirrorView/S コンシステンシ グループ Oracle 環境におけるレプリケーションのアプリケーション ベースの整合性とストレージ ベースの整合性 アプリケーション ベースの整合性 ストレージ ベースの整合性 ストレージ ベースのコンシステンシ レプリケーションにおける Oracle フラッシュバック テクノロジーの活用 Oracle Database 11gR2 のバックアップ / リカバリ ファスト ( フラッシュ ) リカバリ領域 フラッシュバック ログ Flashback Database ASM(Automatic Storage Management) ストレージ ベースのコンシステンシ レプリケーションを使用したオンライン Oracle 11gR2 データベースのレプリケーションとリカバリ データベース ファイルのレイアウト ASM インスタンスのパラメータ ファイル データベース インスタンスのパラメータ ファイル SnapView の整合性機能を使用したレプリケーション SnapView スナップショット コンシステント セッション開始の使用 SnapView クローンのコンシステント フラクチャの使用 MirrorView/S コンシステンシ グループを使用したレプリケーション MirrorView/S コンシステンシ グループの作成 MirrorView/S コンシステンシ グループの使用 MirrorView/S コンシステンシ グループでの SnapView の使用 Oracle 11gR2 の Flashback Database 機能を使用したリカバリ 整合性テストの表と結果 まとめ Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 3

4 関連資料 製品資料 ホワイト ペーパー Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 4

5 エグゼクティブ サマリー 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 レプリケーション テクノロジーに関する知識が必要となります Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 5

6 用語 FAST FAST ストレージ プール FC LUN プール ベースの LUN SATA SSD ストレージプールシン (Thin)LUN Fully Automated Storage Tiering の略語 ストレージ システムによる自動管理 SSD FC SATA など 複数のディスク タイプの物理ドライブを含むストレージ プール ファイバ チャネル 論理ユニット番号 ホスト アプリケーションから参照および操作できる 外部ストレージ システムのストレージ オブジェクトストレージ プール内の利用可能な領域から作成された LUN シリアル ATA 半導体ディスク使用可能なディスク スペースのプールを形成するために指定された CLARiX システムに内蔵される物理ドライブのグループ 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 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 6

7 能な 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 の機能の組み合わせにより 企業は ミッドレンジ ストレージ プラットフォームには従来なかった新たな Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 7

8 ストレージ階層を手に入れることができます フラッシュ ドライブ テクノロジーを採用した 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 のスナップショットとクローン イメージがあることで セカンダリ サーバから Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 8

9 の確実で迅速なデータ アクセスが保証されます さらに スナップショット イメージやクローン データは ソース 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. クローンの例 Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 9

10 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 以降 ) を作成できます 作成されたスナップショットまたはクローンは 検証を実行したり バックアップ レポート テストなどの並行処理プロセスを実行するために使用したりできます これにより ローカルおよびリモート サイトのどちらかでデータが破損した場合の保護レベルが一段と強化されます Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 10

11 図 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 のセットになります このクローン Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 11

12 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 の間で相互に依存した書き込み順序の整合性が維持さ Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 12

13 れます 図 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 Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 13

14 ナンバーまでロール フォーワードすることができます 一方で データベースをホット バックアップ モードに切り替えなければならないため そのプロセスの一環として 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 機能を使用すると この再起動可能なデータベースをフラッシュバックして 既知の整合性のとれたポイント イン タイムに戻すことができます データベースが整合性のある状態にフラッシュバックされると このデータベースに適切なアーカイブ ログを適用し Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 14

15 ロール フォーワードすることができます この方法では 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 データベース パ Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 15

16 ラメータ ) と指定された保存期間 (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 のメタデータとデータベース データの両方を ポイント イン タイムの整合性のとれ Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 16

17 たセットとしてストレージにレプリケートできます 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 のす Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 17

18 べてのテスト ステップはまったく同じです 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 で説明されています 非コンシステント レプリケーションとコンシステント レプリケーションの主な相違点は イメージのキャプチャ方法にあります このセクションでは Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 18

19 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 consistent Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 19

20 この Navisphere CLI コマンドを実行すると 3pmArchSession という名前のコンシステント セッションが LUN および 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 すべてのアクティブな 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 のイメージです キャプチャされたアーカイブ ログを使用してこの再起動可能なイメージをロール フォーワードするには クローン セットをフラクチャする前後に特定の準備作業が必要となります これには フラクチャする前の リストア ポイント の作成や フラクチャが正常に完了した後に行う アクティブな Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 20

21 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 が Synchronized( 同期 ) または Consistent( コンシステント ) 状態にあることを確認します naviseccli h primary_array snapview listclone name clone_groupname cloneid id CloneState 例 : naviseccli h CX4-1202a snapview listclone name Data1CGroup cloneid CloneState naviseccli h CX4-1202a snapview listclone name Redo1CGroup cloneid CloneState naviseccli h CX4-1202a snapview listclone name RecovrCGroup cloneid 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 Data2CGroup Redo1CGroup Redo2CGroup RecovrCGroup o この Navisphere CLI コマンドを実行すると クローン ID が のクローン LUN をクローン グループ Data1CGroup Data2CGroup Redo1CGroup Redo2CGroup および RecovrCGroup からフラクチャします これらの LUN は および 14 の各ソース LUN(ASM ディスク グループ DATA_DGRP REDO_DGRP および RECOVR_DGRP のメンバー ディスク ) のクローンです フラクチャが完了すると 選択したクローン セットが整合性のあるポイント イン タイムの再起動可能なデータベース イメージとなり セカンダリ サーバで使用可能になります 4. アーカイブされていないすべてのログをアーカイブします sqlplus /nolog Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 21

22 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 すべてのアクティブな REDO ログは ASM ディスク グループの ARCH_DGRP にアーカイブされます これらのアーカイブ ログは ステップ 3 でキャプチャされたポイント イン タイムのデータベース イメージをリカバリする際に必要となります 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 o この Navisphere CLI コマンドを実行すると クローン ID が のクローン LUN がクローン グループ ArchCGroup からフラクチャされます この LUN は ソース LUN 15 (ASM ディスク グループ ARCH_DGRP のメンバー ディスク ) のクローンです このレプリケートされた LUN にはアーカイブ ログが含まれるため Oracle の Flashback Database 機能を使用して 再起動後のデータベースをステップ 1 のリストア ポイント at3pm でキャプチャされた既知の SCN にフラッシュバックし さらに アーカイブ ログを使用してロール フォーワードすることができます この時点で ログの適用が可能となる 有効な Oracle バックアップを生成するために必要な すべてのファイルがキャプチャされました 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 のすべての例では 以下を前提とします Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 22

23 アーカイブ REDO ログ フラッシュバック ログなどの本番データベース ファイルは ASM 管理ファイルとして構成され 6 つの LUN の間で分散される ストレージ システム間に MirrorView 接続が確立されている セカンダリ イメージを含むリモート ミラー (LUN ) が正しく作成および設定されている 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 は セカンダリ システム システムで同じ名前とコンテンツを持つコンシステンシ グループを自動的に作成します Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 23

24 ミラーがコンシステンシ グループに追加された後は ミラーを個別に管理することはできなくなります コンシステンシ グループ コマンドを使用して グループとして管理する必要があります MirrorView/S コンシステンシ グループの使用 MirrorView/S コンシステンシ グループのフラクチャを実行するには コンシステンシ グループの名前を Navisphere CLI の mirror sync fracturegroup コマンドに指定します コンシステンシ グループは フラクチャを実行する前に Synchronized( 同期 ) または Consistent( コンシステント ) 状態である必要があります フラクチャの実行後は セカンダリ イメージへの I/O アクセスが可能になるように セカンダリ ストレージ システム上の対応するコンシステンシ グループをプロモート スナップ またはクローン フラクチャできます セカンダリ ストレージ システム上のこのミラー セットは 一貫性のある再起動可能な 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 ログ ファイル フラッシュバック ログを含むコンシステンシ グループが 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 ですべてのミラー イメージがフラクチャされます このコンシステンシ グループのメンバーとなる Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 24

25 のは ソース LUN と セカンダリ ストレージ システム上の対応するミラーされた LUN(ASM ディスク グループ DATA_DGRP REDO_DGRP RECOVR_DGRP のメンバー ディスク ) です フラクチャが完了すると セカンダリ ストレージ上の対応するイメージが整合性のあるポイント イン タイムの再起動可能なデータベース イメージとなり セカンダリ サーバで使用可能になります 4. アーカイブされていないすべてのログをアーカイブします 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 すべてのアクティブな REDO ログは ASM ディスク グループの ARCH_DGRP にアーカイブされます これらのアーカイブ ログは ステップ 3 でキャプチャされたポイント イン タイムのデータベース イメージをリカバリする際に必要となります 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 にフラッシュバックし さらに アーカイブ ログを使用してロール フォーワードすることができます この時点で ログの適用が可能となる 有効な Oracle バックアップを生成するために必要な すべてのファイルがセカンダリ ストレージ アレイでキャプチャされました これで SnapView スナップショットまたはクローンを使用して セカンダリ ストレージ アレイ上のセカンダリ ミラー イメージのレプリカをすばやく作成できます どちらの方法でも高いレベルの保護が提供されますが クローンの場合 さらに高いディスク保護を提供し スナップショットよりパフォーマンス インパクトが抑えられます SnapView の処理が完了すると ミラーリング関係が再度確立されます MirrorView/S コンシステンシ グループでの SnapView の使用 SnapView スナップショットおよび SnapView クローンをセカンダリ ストレージ上で MirrorView/S と連携して使用すると セカンダリ イメージのローカル レプリカが利用できます これにより セカンダリ イメージをプロモートしなくても セカンダリ ストレージでセカンダリ サーバがデータにアクセスできるようになります SnapView の整合処理は コンシステンシ グループ レベルでは実行できず コンシステンシ グループの各メンバーに対して実行する必要があります Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 25

26 ミラーされたセカンダリ イメージの SnapView スナップショット コンシステント セッションを開始するには 次の手順に従います 1. セカンダリ サーバで データベース ファイル REDO ログ ファイル フラッシュバック ログを格納した LUN のスナップショット コンシステント セッションを開始します naviseccli h CX4-1203a snapview startsession 4pmDataSession lun 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 Data2CGroup Redo1CGroup Redo2CGroup RecovrCGroup o 2. セカンダリ サーバで アーカイブ ログを格納した LUN のコンシステント セッションを開始します naviseccli h CX4-1203b snapview fractureclone name ArchCGroup cloneid 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 インスタンスによりマウントする必要があります Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 26

27 $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 using backup controlfile; SQL> shutdown SQL> startup mount; SQL> alter database open resetlogs; レプリケートされた Oracle Database は 転用または耐久性の高いメディアへのバックアップに適した 完全に使用可能なデータベースになります Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 27

28 整合性テストの表と結果 以下に示すすべてのテスト ケースは 従来の LUN とシン LUN の両方を使用して実施されました テスト フラッシュバック有効データベースはホット バックアップ モードではない フラッシュバック有効データベースはホット バックアップ モードではないディスク グループのリバランス実行中フラッシュバック無効データベースはホット バックアップ モードではないディスク グループのリバランス実行中 スナップ セッション開始 正常に再起動 フラッシュバック ロール フォーワード正常に再起動 フラッシュバック ロール フォーワード 結果 クローン フラクチャ正常に再起動 フラッシュバック ロール フォーワード正常に再起動 フラッシュバック ロール フォーワード MV/S フラクチャ 正常に再起動 フラッシュバック ロール フォーワード正常に再起動 フラッシュバック ロール フォーワード 正常に再起動正常に再起動正常に再起動 実行回数 Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 28

29 まとめ 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 Oracle Database 10g/11g/11gR2 と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 29