EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性 高度なテクノロジー US ホワイトペーパー翻訳版 要約 このホワイトペーパーでは EMC CLARiX ストレージ レプリケーションのコンシステンシ機能である SnapView および MirrorView /Synchronous が Oracle のフラッシュバック機能との組み合わせにより UNIX および Windows 環境におけるオンラインの Oracle 10g リリース 2 または Oracle 11g データベースのバックアップをどのようにサポートするかを説明します 2008 年 3 月
Copyright 2006, 2008 EMC Corporation. 不許複製 EMC Corporation は この資料に記載される情報が 発効日時点で正確であるとみなします 情報は予告なく変更されることがあります この資料に記載されている情報は 現状有姿 の条件で提供されます EMC Corporation は この資料に記載される情報に関する どのような内容についても表明保証条項を設けず 特に 商品性や特定の目的に対する適応性に対するいかなる保証もいたしません この資料に記載される いかなる EMC ソフトウェアの使用 複製 頒布も 当該ソフトウェア ライセンスが必要です 最新の EMC 製品名については EMC.com で EMC Corporation の商標を参照してください 他のすべての名称ならびに製品についての商標は それぞれの所有者の商標または登録商標です パーツ番号 H2104.1-J EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 2
目次 T T高度なテクノロジー...0 エグゼクティブ サマリー...4 はじめに...4 対象読者... 5 CLARiX ストレージ システム...5 CLARiX レイヤード ソフトウェア...6 SnapView と MirrorView/S における整合性... 8 Oracle 環境におけるアプリケーション ベースの整合性とストレージ ベースの整合性のレプリケーション...11 アプリケーション ベースの整合性... 12 ストレージ ベースの整合性... 13 ストレージ ベースのコンシステント レプリケーションにおける Oracle のフラッシュバック テクノロジーの活用...13 Oracle データベース 11g のバックアップ / リカバリ... 13 自動ストレージ管理... 15 ストレージ ベースのコンシステント レプリケーションを使用したオンライン Oracle11g データベースの複製...16 データベース ファイルのレイアウト... 17 ASM インスタンス パラメータ ファイル... 17 データベース インスタンス パラメータ ファイル... 18 SnapView 整合性を使用したレプリケーション... 18 MirrorView/S コンシステンシ グループを使用したレプリケーション... 22 Oracle 11g フラッシュバック データベースを使用したリカバリ... 26 整合性テストの表と結果...27 結論...28 関連資料...28 製品ドキュメント... 28 ホワイト ペーパー... 28 EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 3
エグゼクティブ サマリー Oracle データベースは 通常 複数の論理ユニット (LUN) 上に置かれ データの間には論理関係および相互に依存した書き込み I/O が存在します このようなデータベースを複製するには この相互に依存した書き込みの整合性を保持することが必須です これは レプリケーション プロセスを開始する前に データベースをシャットダウンするか またはホット バックアップ モードにすることによって実現できます どちらの場合も データベースの使用者に対して ホット バックアップ中のダウンタイムとパフォーマンス低下という面でマイナスの影響があります リリース 19 以降の EMC CLARiX レプリケーション ソフトウェアの一部であるコンシステンシ機能を使用すると Oracle データベースを複製する前にシャットダウンしたりホット バックアップ モードにしたりする必要がありません EMC CLARiX SnapView および MV/S (MirrorView /Synchronous) ストレージ ベース ソフトウェアのコンシステンシ機能と Oracle のデータベース フラッシュバック機能の組み合わせにより Oracle データベースの複製を簡素化する新しいオプションが提供されました このホワイトペーパーでは SnapView および MirrorView/Synchronous コンシステント ストレージ レプリケーション テクノロジー Oracle の Flash Recovery Area およびデータベース フラッシュ機能 および Oracle ASM( 自動ストレージ管理 ) 機能により オンライン Oracle データベースのバックアップがどのようにサポートされるかを説明します ASM 環境で EMC レプリケーション テクノロジーを使用して Oracle 11g データベースをホット バックアップする例も示します はじめに EMC SnapView スナップショット SnapView クローン および MirrorView/Synchronous は CLARiX ストレージ システムにオプションで付属する常駐ソフトウェアであり ローカルおよびリモートのアレイ ベースのデータ レプリケーション機能を提供します この機能は シングル ポイント イン タイムのバックアップ コピーの作成から 災害保護用の複数のレプリカ作成まで すべてホストのリソースを使用することなく 幅広い処理を実行できます SnapView クローン スナップショット イメージ および MV/S コピーは システム バックアップ DSS( 意思決定支援システム ) リビジョン テストの基盤として また 整合性があり再現可能なデータ イメージが必要とされるすべての場面で使用できます 通常 Oracle データベースは複数の LUN にまたがって存在し 複製の際には LUN に対する書き込み I/O の順番が維持される必要があります SnapView および MirrorView を使用してこれらの LUN を複製するには数秒しかかかりませんが それでも各 LUN が個別に複製されると LUN の内容が他の LUN とコンテンツの整合性を保てない時間帯が生じる可能性があります この問題に対応するには レプリケーション プロセスを開始する前に Oracle データベースをシャットダウンするか またはホット バックアップ モードにするか どちらかの操作を実行します 現在の IT で広く求められる ダウンタイムなしという要件の下では Oracle データベースのバックアップにはシャットダウン モードよりもホット バックアップ モードが適しています Oracle データベースがホット バックアップ状態である限り すべてのファイルの相互に依存した書き込み順序の整合性が保たれることを Oracle は保証しています 多数のファイルが複数の LUN に分散している大規模データベースの場合 データベースをホット バックアップ モードにし すべての LUN を複製し データベースをホット バックアップ モードから戻すためには かなりの時間が必要になります ホット バックアップ モードの間 データベースに対する読み書きは可能ですが Oracle が処理しなければならない記録が増えるので ホスト側のパフォーマンスは影響を受けます EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 4
しかし SnapView および MV/S にストレージ ベースのコンシステンシ機能が追加されたことで レプリケーションの際にデータベースをシャットダウンしたりホット バックアップ モードにしたりする必要がなくなりました コンシステント レプリケーションが実行されると データベースを構成している LUN セットに送られた変更は ストレージ システムによって短時間ブロックされて 複製されたセットでも 相互に依存した書き込み順序の整合性が維持されます この複製されたセットは 電源が突然遮断されたサーバやクラッシュしたサーバと同様の状態 すなわち一貫性があり再起動可能な Oracle データベース イメージになります この再起動可能なイメージは Oracle の Flash Recovery Area および Flashback Database 機能と組み合わせて使用することにより キャプチャされたアーカイブ ログを使用して 後からロール フォワードすることができます さらに SnapView および MV/S はサーバ アプリケーションのレベルではなくストレージ システムのレベルで機能するため 分散または連合データベース環境で さまざまなアプリケーション間の書き込み順序に相互依存性がある場合に このモデルを使用することによってトランザクションの整合性を確保することができます Oracle から提供されている現在のテスト キットは 整合性に対応していません オンラインで Oracle データベースを複製する際のデータの整合性と動作の正確性を確かなものとするために スナップショット テスト キット中のホット バックアップ テストを CLARiX コンシステント レプリケーションを用いて行うよう変更しました このスナップショット テスト キットは Oracle が OSCP(Oracle Storage Compatibility Program) の一部として提供しているものです Oracle 10g リリース以降の主要な機能である ASM( 自動ストレージ管理 ) は Oracle データベースを格納するために実装されました ASM により Oracle データの管理 配置 制御が簡素化されたことで パフォーマンスや可用性で妥協することなく総所有コストを下げることができます 対象読者 このホワイトペーパーは UNIX および Windows プラットフォームで EMC CLARiX レプリケーション ソフトウェアのコンシステンシ機能を使用した Oracle データベースのバックアップおよびリモート災害保護計画の実装を検討している データベース管理者およびシステム管理者を対象にしています 読者は Oracle データベース ソフトウェア および EMC CLARiX のストレージ システムとレプリケーション ソフトウェアについての知識を持っている必要があります CLARiX ストレージ システム EMC CLARiX ストレージ システムは 高可用性を目的として設計されています デュアル SP ( ストレージ プロセッサ ) デュアル バックエンド ファイバ チャネル (FC) ループ デュアル ポート ディスク ドライブなどの冗長コンポーネントを備えた CLARiX ストレージ システムでは 単一点障害は発生しません CLARiX では RAID 1 1/0 3 5 のデータ保護オプションが用意されています これらの構成は 単一ディスク障害に対する保護を提供します さらに リリース 26 では CLARiX RAID 6 1 テクノロジーが導入されました RAID 6 では 1 つの RAID グループにおいて 最大 2 件のディスク障害から保護されます CLARiX システムのデュアル SP を使用して SP 間で LUN のバランスを取ることによってパフォーマンスを向上させることができます 1 つの SP が使用できなくなると その SP への I/O リクエストの処理をもう 1 つの SP が引き継ぎます SP の障害は サービスの目立った中断が発生することなく 自動的に処理されます 障害が修正されると PowerPath の定期的な自動復旧機能が有効 1 ホワイトペーパー EMC CLARiiON RAID 6 Technology - A Detailed Review に RAID 6 の詳細が説明されています EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 5
になっている場合 サービスはフェイルバックにより元々割り当てられていた SP に自動的に復帰します 有効になっていない場合は 手動で戻す必要があります EMC Navisphere ファミリ ソフトウェア製品の一部である Navisphere Manager と Navisphere CLI は ネットワーク上のホストに接続された CLARiX ストレージ システムを構成および管理するための管理ツールです Navisphere Manager は Web ベースのユーザー インタフェースであり 管理者は一般的なブラウザを使用して 安全に CLARiX ストレージ システムを管理することができます Navisphere CLI は Navisphere Manager を補完するために またはその代替として使用できる コマンド ライン インタフェースです これらの管理ツールを使用することにより 物理ディスク ドライブが RAID グループに体系化されます 各 RAID グループ内にはさまざまなサイズの LUN があり グループの RAID 特性を引き継ぎます この LUN は CLARiX ストレージ システムに接続されている 1 つまたは複数の 2 ホストに関連づけられたストレージ グループに割り当てられます このホワイトペーパーで後述する SnapView および MV/S 向けの管理機能は Navisphere の CLI コマンドを使用することにより シェル スクリプトとバッチ ファイルで自動化することができます SnapView スナップショットおよびクローンは Navisphere の CLI インタフェース以外に サーバ ベースのユーティリティである admsnap を使用して管理することもできます admsnap ユーティリティは SnapView ソフトウェアがインストールされ有効になっているストレージ システムに接続された任意のサーバにインストールできます admsnap を使用して SnapView をセットアップすることはできません 進行中の SnapView 操作の管理のみが可能です CLARiX レイヤード ソフトウェア CLARiX レイヤード ソフトウェアは オプションとして提供されるストレージ ベースのアプリケーションで ローカルおよびリモートのアレイ ベースのデータ レプリケーション機能を提供します この機能は シングル ポイント イン タイムのバックアップ コピーの作成から 災害保護用の複数のレプリカ作成まで 幅広い処理を実行できます レイヤード アプリケーションは CLARiX ストレージ システム上で実行されるので データを複製するためのホスト リソースは必要ありません これらのアプリケーションのうち SnapView と MirrorView/Synchronous の 2 つとそのコンシステンシ機能については このホワイトペーパーで後述します SnapView を使用すると 本番データのローカルのポイント イン タイム スナップショットおよびフルコピー クローンを作成でき 無停止バックアップを実行することができます このスナップショット イメージおよびソース LUN から切り離されたクローンは バックアップ 意思決定支援 テストなど 他の使用目的でセカンダリ サーバにマウントすることができます 本番データベースへのアクセスが中断された場合は SnapView のスナップショットおよびクローン イメージにより データに対する信頼性の高い 高速なアクセスが可能です さらに スナップショット イメージまたはクローンのデータは ソース LUN でデータ破損が発生した際 ソース LUN にリストアすることができます 図 1 に示すように スナップショットは ソース LUN の変更されていないデータと SP の予約済み LUN プール内の予約済み LUN に保存されているデータとを合わせたものです スナップショットは読み取りと書き込みのどちらも可能なので セカンダリ サーバからのすべてのスナップショット書き込みは 予約済み LUN にも保存されます 2 1 つのストレージ グループに複数のホストを接続できるのは クラスタ環境の場合だけです EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 6
図 1: スナップショットの例 図 2: クローンの例 クローンを使用してポイント イン タイム コピーを保存するには クローンがそのソース LUN から分離される必要があります 分離され セカンダリ ホストにマウントされたクローンには I/O を行うことができます ソース LUN と分離されたクローン LUN はそれぞれのサーバによって変更される毎に クローン プライベート LUN は クローンが分離された後に変更されたソースとクローンの領域を記録します 図 2 に これを示します MirrorView/S は クリティカルなビジネス データのリモート レプリケーションを行う同期型の製品です MV/S は 災害復旧のために 離れた場所にあるストレージ システムの LUN の間でリアルタイムにデータをミラーリングし 同期させます 同期モードでは ローカル / プライマリ ストレージ システムに対するサーバ書き込みが完了するのは リモート / セカンダリ ストレージ システムへのデータ転送が成功した後になります 同期モードでは リモート イメージがソース イメージの完全かつ正確な複製であることが保証されます 図 3 に サンプルのリモート ミラー構成を示します SnapView を MV/S と組み合わせて使用することにより (FLARE リリース 24 以降の場合 ) プライマリまたはセカンダリのミラー イメージのスナップショットまたはクローンを作成し それを使用して検証を実行したり バックアップ レポート テストなどの並行処理プロセスを実行したりすることができます これにより ローカルとリモートの両方のサイトに新たなレベルの保護が追加され どちらかに障害が発生した際に備えることができます EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 7
図 3:MirrorView/Synchronous の例 SnapView と MirrorView/S における整合性 ストレージ システム ベースの SnapView および MV/S のコンシステンシ機能は Oracle アプリケーションとは独立して動作します Oracle データベースを構成する LUN のセットに対してコンシステント レプリケーション プロセスが起動されると ストレージ システムは レプリケーション プロセスが完了するまで一時的に セット内の各ソース LUN に対する書き込みを保留します コンシステント レプリケーションでは データベースをシャットダウンする または ホット バックアップ モード にする必要はありません SnapView または MV/S のコンシステンシ操作で作成されるレプリカは 事前にアプリケーションを停止または終了させることなく作成可能で 再開可能な本番データのポイント イン タイム レプリカで 相互に依存した書き込みの整合性があることが保証されます コンシステント レプリケーションは 1 つのセットになった複数の LUN に対して動作し セット内の 1 つの LUN に対してレプリケーション動作が失敗すると 他のすべての LUN のレプリケーションがキャンセルまたは停止されます したがって セットとして複製されたすべての LUN は そのソースの同一ポイント イン タイムのレプリカであり 相互に依存した書き込みの整合性が維持されていることが保証されます この LUN のセットは 単一のストレージ システム上に存在する必要があります 複数のストレージ システム上に分散させることはできません SnapView スナップショットの整合性スナップショットは LUN の仮想的なポイント イン タイム イメージであり 数秒で作成できます ソース LUN に比べて わずかなディスク領域しか使用しません スナップショットは セカンダリ サーバでは通常の LUN と同じように表示され バックアップ テストなど 他の目的に使用できます スナップショット セッションが開始されると LUN のポイント イン タイム イメージがキャプチャされます このセッションでは特定のポイント イン タイムでのソース LUN のデータが保持されます ソース LUN へのすべての書き込み毎に SnapView はオリジナル データのコピーを予約済み LUN プール内の LUN に格納します この動作は COFW(Copy on First Write) と呼ばれ ソース LUN ブロックへの最初の書き込み時にのみ発生します すでに変更されたソース LUN ブロックへのその後の書き込みは すでにオリジ EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 8
ナルのブロックが予約済み LUN プール内に存在するため 予約済み LUN プールへはコピーされません スナップショットにアクセスすると ソース LUN 上の未変更のデータと予約済み LUN プール内に保存されているデータから データが組み立てられます SnapView スナップショット セッションは パーシステント モードのみ またはパーシステント モードとコンシステント モードの両方で実行できます FLARE リリース 24 から すべての SnapView セッションはデフォルトでパーシステント セッションとして構成されます パーシステント スナップショット セッションには新たなレベルでの保護が提供されていて SP の再起動や障害 ストレージ システムの再起動や電源障害 またはピア トレスパスなどの後でスナップショットを引き続き使用できます さらに ロールバックできるのはパーシステント スナップショット セッションのみです SnapView のロールバック機能を使用すると ソース LUN に障害が発生した場合や スナップショット セッションのポイント イン タイム データをソースとして使用したい場合に ソース LUN のコンテンツをスナップショット セッションのポイント イン タイム データに置き換えることができます ロールバック動作が確認されるとすぐに 本番サーバはスナップショット セッションのポイント イン タイム データにアクセスできます データからソース LUN への実際のコピー動作は バックグラウンドで続行されます スナップショット セッションが起動され スナップショットに対してデータの変更が加えられているとき セッションが開始されたポイント イン タイムにソース LUN をリストアしたい場合には ロールバックの前にセッションを無効にする必要があります セッションをパーシステント モードとコンシステント モードの両方で実行するには セッションの開始時にコンシステント モード オプションを指定する必要があります コンシステント スナップショット セッションは 複数の LUN を 1 つのセットとして動作します 各スナップショット セッションの開始時に この LUN のセットが動的に選択されます 開始されたコンシステント セッションに LUN を追加することはできません Oracle データベースの場合 これは データベースを構成し相互に関連する内容を持つファイルを含む LUN のセットです このセットのソース LUN に対するすべての I/O リクエストは セット内のすべての LUN に対してセッションが開始されるまでの間 わずかながら遅延します これは 相互に依存した書き込み順序の整合性を持つ データベースの再起動可能なポイント イン タイム コピーが 確実に複製されるようにするためです 個別の LUN メンバーについてコンシステント スナップショット セッションを停止することは可能ですが 実行しないように強く推奨します ほとんどの場合 メンバーを除外するとセットの完全性が失われて 整合性を保てなくなるためです BCV(SnapView クローン ) の整合性 クローンは ソース LUN 全体の正確なバイナリ コピーです クローンはソース LUN の完全なコピーなので 作成には時間がかかります 初回の作成にかかる時間は クローンするソース LUN のサイズに依存します 各クローン LUN は ソース LUN と同じサイズでなければなりません クローンを使用することにより LUN の完全なコピーを同一のストレージ アレイ内に作成することができます LUN のクローンを作成するには 最初にその LUN のクローン グループを作成する必要があります クローン グループが作成されると そこにクローン LUN を追加することができます クローン グループには ソース LUN とそのすべてのクローンが含まれます クローンがクローン グループの一部であり 分離さていない状態では ソース LUN へのホスト書き込みは クローンにも同時にコピーされます 分離されたクローンは セカンダリ サーバで I/O の処理に使用できます 分離されたクローンは サーバからの書き込みリクエストを受け付けますが 変更されてソース LUN の正確なコピーでなくなったことを示すために ダーティとマークされます クローンが分離された後でソース LUN に対して行われるサーバ書き込みは クローンへはコピーされません どちらの場合も SnapView ソフトウェアは ソースと クローン プライベート LUN プール内の分離されたクローン LUN の両方について 変更されたデータ ブロックを識別する情報の記録を開始します この記録により クロー EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 9
ンとそのソース LUN の間の同期またはリバース同期は差分処理され つまり 変更されたブロックだけがコピーされるので 時間が大幅に削減されます コンシステント クローン フラクチャとは ポイント イン タイムの再起動可能なコピーをクローン セット内にまたがってキャプチャするために 複数のクローンを同時に分離することです Oracle データベースの場合 これは データ ファイルやログ ファイルのように データベースを構成し相互に関連するコンテンツを持ったファイルを含む クローン LUN のセットです このクローン LUN のセットは フラクチャが開始されると動的に選択されます これらセット内のクローンはそれぞれ別のクローン グループに属する必要があります つまり 同じソース LUN に属する複数のクローンに対して コンシステント フラクチャを行うことはできません 選択されたクローンのソース LUN に対するすべての I/O リクエストは すべてのクローンのフラクチャが完了するまでの間 SnapView ドライバによって遅延されます これは 相互に依存した書き込み順序の整合性を持つ データベースの再起動可能なポイント イン タイム コピーが 確実に複製されるようにするためです コンシステント フラクチャが完了すると セット内のクローン間における関連性はなくなります つまり その後で実行される同期 リバース同期 削除などのアクションは 個別のクローンに対して行われます 関連するクローン間でポイント イン タイム コピーの整合性を維持するために 1 つのクローンに対するすべてのアクションは 同じセット内のすべてのクローンに対して実行することを推奨します コンシステント フラクチャが行われたクローンは バックアップ 意思決定支援 テストなどに使用することができます ソース LUN でデータ破損が生じた場合は SnapView クローンの差分リバース同期機能を使用して クローン セットが分離されたポイント イン タイムにソース LUN のコンテンツを直ちにリストアすることができます ただし これはクローンに変更が加えられていないことが条件です 変更されている場合は リバース同期の際にクローンの状態がソースに反映されます 新たなレベルの保護として リバース同期を開始する前に Protected Restore 機能を選択することにより 保護された形でリバース同期を実行することができます ソース LUN は 各 LUN に対してリバース同期が開始されるとすぐにオンラインに戻すことができます その際 Protected Restore を選択すると ソース LUN に対して行われるすべてのサーバ書き込みは リバース同期プロセスの間 そのクローンにコピーされませんし クローンはリバース同期が完了すると自動的に分離されます この機能の本質的な目的は テストやリカバリのために同じクローン セットから何回もリストア操作を実行できる 本番データベースの ゴールド バックアップ コピーを作成することです Protected Restore 機能は デフォルトで有効になっています この機能は クローン グループ単位ではなくクローン単位で有効にする必要があり リバース同期の開始前に指定しなければなりません MirrorView/S コンシステンシ グループミラーは CLARiX ストレージ アレイ上のソース LUN の完全なバイナリ コピーを 別の CLARiX ストレージ アレイ上のターゲット LUN に作成したものです MV/S は 同期書き込みを使用して変更を反映させます 同期ミラーリングでは サーバ書き込みが確認されるのは すべてのセカンダリ ストレージ システムにデータのコピーが作成された後でのみになります そのため 常にデータの正確なコピーが存在します 同期ミラーリングを使用するには まず 物理的に接続されたストレージ システム間に論理接続を確立する必要があります 次に プライマリ ストレージ上のミラーリング対象のソース LUN が セカンダリ ストレージ上の対応する LUN と同期ミラーリングされたペアとして構成されます MV/S には コンシステンシ グループ機能のサポートが含まれています コンシステンシ グループは 同期ミラーリングされる LUN のペアのセットで そのデータが Oracle データベースなど 内容に関連性があり 相互に依存した書き込み順序の整合性を持つことが分かっていて 使用するためにはセットとして複製する必要があるものです これらのミラーは コンシステン EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 10
シ グループのメンバーになると個別に分離 同期 プロモートすることはできません これらのアクションは グループのすべてのメンバー ミラーに対してまとめて実行する必要があります グループ内の LUN に対する書き込みをセカンダリ アレイ内の対応する LUN に正しくミラーリングできない場合は グループが分離されます フラクチャは 1 つまたは両方の SP のミラーリング パスに障害が発生することで自動的に行われるか または手動で実行します どちらの場合も MirrorView はコンシステンシ グループ内のすべてのメンバーを分離します ミラーリングされていない書き込みは グループのすべてのメンバーについてフラクチャが完了するまでホストに確認されません これにより セカンダリ イメージのセット全体でデータの整合性が確実に保持されます セカンダリ サイト上の分離されたイメージの内容は 本番サイトのものよりも多少古い可能性がありますが あるポイント イン タイムにおける相互に依存した書き込み順序の整合性を持った 再起動可能なデータベースを表していることは確実です コンシステンシ グループが分離されると プライマリ イメージに対するすべての変更は セカンダリ イメージがアクセス不可能である限り フラクチャ ログに記録されます フラクチャ ログは ストレージ プロセッサのメモリ上で維持されるビットマップです このビットマップ すなわちフラクチャ ログにより 分離されたコンシステンシ グループを同期するのにかかる時間を短縮できます プライマリ サイトのサーバまたはストレージ システム またはその両方に障害が発生すると セカンダリのイメージ セットが直ちにプロモートされてプライマリの役割を引き継ぐため 引き続き本番データにアクセスすることができます セカンダリ イメージが正常にプロモートされた後で リモート サイトでアプリケーションをオンラインにするために アプリケーション リカバリ処理が必要になることがあります Oracle データベースの場合は Oracle インスタンスの再起動が必要になります データベースが正常な方法でシャットダウンされていないため Oracle でデータベースを正常に開くためには クラッシュのリカバリを実行する必要があります Oracle 環境におけるアプリケーション ベースの整合性とストレージ ベースの整合性のレプリケーション SnapView および MV/S の新しいコンシステンシ機能により 現在 Oracle 環境を実行しているサイトには オンライン Oracle データベースを複製する際に アプリケーション ベースの整合性かストレージ ベースの整合性を選択するオプションが与えられます 方法は異なりますが どちらの場合も 相互に依存した書き込み順序の整合性は 関連するターゲット LUN の間で維持されます 図 4 に示すように Oracle ベース整合性では Oracle データベースの有効なバックアップが作成され ストレージ ベース整合性では一貫性があり再起動可能な Oracle データベースが作成されます この再起動可能なイメージは Oracle 11g の Flash Recovery Area および Flashback Database 機能と組み合わせて使用することにより キャプチャされたアーカイブ ログを使用して 後からロール フォワードすることができます EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 11
Oracle データベースのバックアップリケーション SnapView コンシステント レプ 図 4: アプリケーション ベースおよびストレージ ベースのデータベース レプリカの作成 アプリケーション ベースの整合性 リリース R19 よりも前の SnapView および MV/S コンシステンシ機能では 広範なテストと Oracle の OSCP プログラムにより どちらのアプリケーションも ダウンタイムとパフォーマンスへの影響を最小限に抑えて Oracle データベースをバックアップするための効果的な方法であることが証明されていました ストレージ ベースのコンシステンシ機能がない場合は ストレージ システムが複製するものが間違いなく Oracle データベースの有効なバックアップであることを保証するために Oracle ベースの整合性が必要でした つまり オンライン Oracle データベースのバックアップを作成するには ストレージ ベースの複製コマンドを実行する前に データベースをホット バックアップ モードにする必要があります Oracle データベースがホット バックアップ モードになった後では その LUN に対する I/O 変更は Oracle レベルで管理されます Oracle のホット バックアップ モードを終了して I/O が復旧するまでの間 関連するすべての LUN を安全に複製することができます 複製されたこのコピーを使用して Oracle データベースを再起動し バックアップが作成された後の一貫性のあるポイント イン タイムに復旧することができます ( リカバリ モデル ) 整合性を実現するための Oracle による方法を使用したホット バックアップでは Oracle データベースの有効なバックアップが作成されます リカバリ モデルでは 一般的により高い精度が実現できます これは 必要に応じてトランザクション ログをデータベースに適用して 整合性のとれたポイント イン タイムにデータベースを復旧させることができるためです その後 整合性のあるデータベースを 特定のポイント イン タイムまたは追加のアーカイブ ログ変更の変更回数までロール フォワードできます 一方で データベースをホット バックアップ モードにすると それに伴って Oracle が処 EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 12
理しなければならないチェック ポイント作成 ログ記録 ログ切り替えといった追加の作業により ホスト側のパフォーマンスが影響を受けます ストレージ ベースの整合性 ストレージ ベースの整合性は サーバ上の Oracle アプリケーションとは無関係に機能するため データベースをホット バックアップ モードにする必要はありません 関係する Oracle データベースの LUN を識別するという必要ステップが完了している場合 ストレージ システムはセット内のいずれかの LUN に対する書き込みを受信すると 相互に依存した書き込み順序の整合性を持つデータベース イメージを作成するために その書き込みを短時間保留します LUN セットに対する通常の I/O は レプリケーションが完了すると復旧します この複製されたコピーを使用して Oracle はデータベースを再起動できますが ( 再起動モデル ) データベースをロール フォワードすることはできません 整合性を実現するストレージ ベース方式のみを使用したホット バックアップでは 一貫性があり再起動可能な Oracle データベースが作成されます 再起動モデルは 精度は劣りますが 復旧の操作がシンプルです 複製されたセットの状態は 突然発生した電源障害やシステム クラッシュによってクラッシュした本番データベースと同等の状態になります したがって 運用を再開するためのプロセスも オリジナルの本番サイトで予期しない中断の後に運用を再開する場合と同じです データベースをホット バックアップ モードにする必要がないため レプリケーション プロセスの間 ホスト側のパフォーマンスはほとんど影響を受けません ストレージ ベースのコンシステント レプリケーションにおける Oracle のフラッシュバック テクノロジーの活用 Oracle のフラッシュバック テクノロジーは 時間を前後に移動してデータを表示するための一連の機能です Oracle のフラッシュバック テクノロジーの 2 つの中心を構成するのは Flashback Database と Flash Recovery Area です Flashback Database は Flash Recovery Area のフラッシュバック ログを使用して Oracle データベース全体を過去のポイント イン タイムに戻します Flash Recovery Area は 制御ファイル オンライン ログ ファイル アーカイブされた REDO ログ ファイル フラッシュバック ログなど Oracle データベースのバックアップおよびリカバリに関連するすべてのファイルを格納するために Oracle が使用する 一元化された領域です Oracle は ASM( 自動ストレージ管理 ) を使用して Flash Recovery Area をセットアップするように推奨しています これは 新しいバックアップのために領域が必要になった場合 不要なファイルが自動的に削除されるというメリットがあるためです Oracle データベース 11g のバックアップ / リカバリ Flashback Database を使用すると 論理データ破損やユーザー エラーなどによる問題の修復のために データベースを以前の整合性のとれたポイント イン タイムに戻すことができます Oracle は フラッシュバック ログに記録された過去のブロック イメージを使用することでこれを実行し データベースへの変更を元に戻します この機能は Flash Recovery Area が設定され フラッシュバック機能が有効になっている場合にのみ使用できます すでに説明したように CLARiX のストレージ ベース整合性を使用して ホット バックアップ モードになっていないオンライン Oracle データベースをキャプチャした場合 作成されるのは 単に一貫性があり再起動可能な Oracle データベースであり 整合性のあるバックアップ データベースではありません しかし Oracle の Flashback Database 機能を使用すると この再起動可能なデータベースをフラッシュバックして 既知の整合性のとれたポイント イン タイム EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 13
に戻すことができます データベースが Consistent( コンシステント ) 状態にフラッシュバックされると 適切なアーカイブ ログをそのデータベースに適用することにより ロール フォワードできます この方法により CLARiX の MV/S または SnapView ストレージ ベースのバックアップを使用して 整合性の取れた Oracle イメージを生成できます これにアーカイブされたログを適用することにより データベースをホット バックアップ モードにすることなくロール フォワードすることができます Flash Recovery Area Flash Recovery Area は Oracle が管理するディスク ストレージ上の場所で 制御ファイル アーカイブされたログ フラッシュバック ログなど バックアップおよびリカバリに関係するファイルが置かれます Flash Recovery Area を使用すると Oracle データベースの継続的な管理が簡素化されます Oracle は リカバリ ファイルに割り当てられたディスク領域を自動的に管理して それらがリストアおよびリカバリのために必要である限りは保持し Oracle データベースのリストアにとって不要になれば削除します Flash Recovery Area の最大サイズ およびリカバリのためにバックアップとアーカイブされたログを保持する必要がある期間を決定する保持ポリシーは ユーザーが定義します Flash Recovery Area で使用される領域が指定された限度に到達すると Oracle は Flash Recovery Area 内の既存のファイルで使用されなくなったものの中から 最小限のセットを自動的に削除します Flash Recovery Area に十分な領域を割り当てると Oracle データベースを短時間で簡単かつ自動的に復旧することができます Oracle が推奨するディスクの上限は データベース サイズ 差分バックアップのサイズ および第 3 のストレージにバックアップされていないすべてのアーカイブ ログのサイズの合計です また メディアに障害が発生した際に本番データベース ファイルとバックアップの両方が失われることを避けるために Flash Recovery Area は本番データベース ファイルから切り離されたディスクに置く必要があります Flash Recovery Area の最大サイズと場所を指定するには それぞれ SQL ステートメント DB_RECOVERY_FILE_DEST_SIZE DB_RECOVERY_FILE_DEST を使用します フラッシュバック ログフラッシュバック ログは Flash Recovery Area に格納され データベースのフラッシュバック動作をサポートするために Oracle が生成するログです Oracle がデータベースの変更ページをフラッシュバック ログに収集するためには フラッシュバック機能が有効になっている必要があります Oracle はこのログを使用して 短時間でデータベースを過去のポイント イン タイムにリストアします ログを有効にするには SQL ステートメント ALTER DATABASE FLASHBACK ON を発行します Flashback Database Flashback Database プロセスでは Flash Recovery Area のフラッシュバック ログを使用して バックアップによってデータベースをリストアすることなく 短時間で Oracle データベースを以前のポイント イン タイムに戻すことができます Flashback Database では Flash Recovery Area が構成されている必要があります Oracle 10g リリース 2 よりも前は Flashback Database でサポートされていたのは 以前の TIME または SCN へのフラッシュバックだけでした Oracle 10g リリース 2 では リカバリ プロセスを簡素化するためにリストア ポイントが追加されました リストア ポイントは データベース エンジンが既知のコミット済み SCN を内部的にマップするために使用するユーザー定義の名前で これによって SCN やトランザクションの時間を知る必要がなくなります リストア ポイント名と SCN のこのマッピングは 制御ファイルに格 EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 14
納されます 通常のリストア ポイントまたは保証されたリストア ポイントは 次の SQL コマンドを使用していつでも作成できます CREATE RESTORE POINT restore_point [GUARANTEE FLASHBACK DATABASE] 通常のリストア ポイントは 手動で削除しなくても 時間の経過とともに制御ファイルから削除されます フラッシュバック ログが時間の経過によって Flash Recovery Area からなくなる際の判断は Flash Recovery Area のサイズ (DB_RECOVERY_FILE_DEST_SIZE データベース パラメータ ) および指定された保存期間 (DB_FLASHBACK_RETENTION_TARGET データベース パラメータ ) に基づきます 一方 保証されたリストア ポイントは 時間が経過しても制御ファイルから削除されることはありませんので 明示的に削除する必要があります 保証されたリストア ポイントを使用すると そのリストア ポイントへの復旧を可能にするフラッシュバック ログが常に維持されます そのため 保証されたリストア ポイントは Flash Recovery Area の領域を大量に使用します Flash Recovery Area のサイズの決定方法については Oracle Database Backup and Recovery User s Guide を参照してください データベースをあるリストア ポイントに戻すには そのリストア ポイントの名前を次の SQL コマンドで使用します FLASHBACK DATABASE TO RESTORE POINT restore_point 自動ストレージ管理 ASM( 自動ストレージ管理 ) は Oracle データベース ファイルのために構築された Oracle のファイル システムおよびボリュームのマネージャです ASM では 使用可能なすべてのストレージを ASM ディスク グループとして統合することにより データベース管理を簡素化します 1 つの ASM ディスク グループは 1 つまたは複数のディスク デバイスから構成され ASM はそれらを 1 つの論理単位としてまとめて管理します 数千個に達する可能性もあるデータベース ファイルを直接管理するのではなく ファイルをグループにまとめることで ストレージ管理をディスク グループのレベルにまで下げることができます テーブルスペース 制御ファイル REDO ログ アーカイブ ログを作成する際は これらのファイルを置く場所をディスク グループ単位で指定します ASM は ファイルの命名を管理し そのディスク グループで使用可能なすべてのストレージ全体にわたってデータベース ファイルを配置します ストレージ配置は データベースをシャットダウンすることなく変更 調整できます つまり データベースを実行したまま ディスクを追加 または削除することが可能です ASM は I/O 負荷が平準化し パフォーマンスが最適化されるように ディスク グループ内のすべてのディスクにわたってデータを自動的に再配置 ( リバランス ) します ASM インスタンスは データベース インスタンスからは独立しており ASM ディスク グループ内のディスクを管理する際に必要です 1 つの ASM インスタンスは 1 つまたは複数のデータベース インスタンスに対応することができます この ASM インスタンスは データベース インスタンスがいずれかの ASM ファイルにアクセスする前に設定が完了し 実行されている必要があります 論理ボリューム マネージャである ASM インスタンスは ディスク グループ内の各メンバー ディスクに関して変更を追跡する ASM メタデータを更新する必要があります ASM メタデータ自体も ディスク グループのメンバー ディスク上に置かれます ASM メタデータがデータベース ファイルと同じメンバー ディスクのセット上に格納され ASM は自動的に動的なリバランシングを行うため メタデータの内容は ユーザーがデータベースの内容を変更していないときにも変更される可能性があります ASM が管理する Oracle データベースを複製するときは レプリカを他の用途で使用できるようにするために ASM メタデータとデータベース データの両方を レプリケーションの間 EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 15
Consistent( コンシステント ) 状態にしておく必要があります つまり ディスク グループのすべてのメンバー ディスクは その内容が途中で変更されることは許されません 現在 ASM インスタンスには すべてのディスク メンバーがストレージ ベースの複製を使用して正しく複製されるようにするために メタデータを含め ASM ディスク グループを静止状態にする固有の機能はありません データベース データは Oracle データベースをホット バックアップ モードにすることによって静止状態にすることができますが ASM メタデータを静止状態にする簡単な手段はありません この状況の下で ASM ファイルを含むデータベースのバックアップを安定的に実行する唯一の方法は Oracle の RMAN(Recovery Manager) ユーティリティを使用することでした R19 以降における SnapView および MV/S のコンシステント レプリケーションのサポートでは ASM メタデータとデータベース データの両方を 整合性のとれたポイント イン タイムのセットとしてストレージ複製することができます SnapView スナップショットのコンシステント セッション SnapView クローン セットのコンシステント フラクチャ または MV/S コンシステンシ グループのフラクチャを使用して ASM ディスク メンバーをセットとして複製する場合 ASM メタデータを静止状態にする必要はありません ASM ディスク メンバーが整合性のとれたポイント イン タイムのセットとしてストレージ複製されている限り ASM はクラッシュ時に ASM インスタンスを再起動して ASM ディスク グループを正しくマウントできます ストレージ ベースのコンシステント レプリケーションを使用したオンライン Oracle11g データベースの複製 このセクションでは ASM が管理する Oracle 11g データベースを SnapView スナップショット SnapView クローン MV/S といったコンシステンシ機能を使用して複製する際に データの整合性と動作の正確性を確保するために実行するテストについて説明します ここで取り上げている Oracle 11g および CLARiX レプリケーション ソフトウェアの詳細については 関連資料 セクションにまとめられているそれぞれのドキュメントを参照してください すべてのテスト シナリオで コンシステント レプリケーション プロセスの間 Oracle データベースがホット バックアップ モードにされることはありません ASM リバランシングがある状態およびない状態でのレプリケーションと Flashback Database を使用したリカバリについても説明します すべてのテストは Linux x86 上の RHEL 4.0 update 3 と Windows Server 2003 バージョン 5.2 SP1 で実行されました 図 5 に ストレージ ベース コンシステント レプリケーションと Oracle フラッシュバック テクノロジーの Flashback Database 機能を使用して Oracle 11g データベースを複製し その後リカバリするために必要なステップの高レベルの概要を示します EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 16
Oracle Database 11g RAC production service 4. Restart DB on backup host 3. Mount consistent replica set to backup host 1. Create flashback restore point 2. Generate PIT consistent SnapView replica 5. Oracle DB flashback to restore point to create a database with known transaction content DBdata LUNs RedologLUN(s) 11g flash_recovery_area LUN(s) 図 5: ストレージ ベースのコンシステント レプリケーションおよびリカバリ データベース ファイルのレイアウト ASM が管理する Oracle の本番データベース ファイルが CX3-80 CLARiX ストレージ アレイに置かれています すべてのテスト ケースで 6 つの 4+1 RAID 5 LUN が作成されました SnapView クローンの場合は 同じ数の LUN が同じストレージ アレイ上にバインドされ 対応する本番 LUN と同期されます MirrorView の場合は 本番 LUN が 独立した CX3-80 CLARiX ストレージ アレイ上の対応する 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 インスタンス パラメータ ファイル ASM が管理するファイルを使用した Oracle 11g データベースは 通常のデータベース インスタンス以外に ASM インスタンスを必要とします 通常のデータベース インスタンスと同様に EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 17
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 データベースを複製するように SnapView スナップショットまたは SnapView クローンを設定するために必要なステップは コンシステント レプリケーションの場合も非コンシステント レプリケーションの場合も同じです 設定の詳細は EMC SnapView for Navisphere Administrator's Guide で説明されています コンシステント レプリケーションと非コンシステント レプリケーションの重要な違いは イメージが取得される方法です このセクションでは SnapView スナップショットおよび SnapView クローンを使用してオンライン データベースのコンシステント レプリケーションをキャプチャするために必要なステップについて説明します すべてのスナップショットおよびクローンの例では 以下が前提です アーカイブ REDO ログ フラッシュバック ログなどの本番データベース ファイルは 6 つの LUN にわたって分散され ASM 管理ファイルとして構成される SnapView スナップショット クローン グループ およびクローンが適切に作成 設定される ASM インスタンスが実行中である データベースは archivelog モードで実行され Flash Recovery Area およびフラッシュバック ログが有効になっている 本番ホスト上のデータベースは 現在開いていてアクティブである レプリケーションの間 Oracle データベースはホット バックアップ モードではない データベース ファイル REDO ログ ファイル フラッシュバック ログを保持する LUN は 1 つのセットとして複製される アーカイブされたログを保持する LUN は 1 つの独立したセットとして複製される SnapView スナップショット コンシステント セッション開始の使用 SnapView スナップショットのコンシステント セッション開始を実行するには 希望するすべてのソース LUN を選択し これらに対して Navisphere CLI で snapview startsession コマンド EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 18
を -consistent スイッチを指定して実行します この複製されたセットは 一貫性があり再起動可能な Oracle データベースのイメージになります キャプチャしたアーカイブ ログを使用して この再起動可能なイメージをロール フォワードするには スナップ セッションを開始する前後に準備のためのステップが必要です 具体的には セッション開始前に リストア ポイント を作成することと セッション開始後に有効な REDO ログがアーカイブされ キャプチャされたことを確認することです 1. 新しいフラッシュバック リストア ポイントを作成します sqlplus /nolog SQL> connect sys/manager as sysdba SQL> drop restore point at3pm SQL> create restore point at3pm; これにより 通常のリストア ポイントが at3pm という名前で作成されます この名前は この時点におけるデータベースの SCN のエイリアスです 前述したように 通常のリストア ポイントは Flash Recovery Area のサイズと指定された保存期間 ( デフォルトは 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 CX3801a snapview startsession 4pmDataSession lun 10 11 12 13 14 consistent この Navisphere CLI コマンドにより 4pmDataSession という名前のコンシステント セッションが 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 EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 19
有効なすべての REDO ログが ASM ディスク グループ ARCH_DGRP にアーカイブされます アーカイブされたこれらのログは ステップ 2 でキャプチャされたデータベースのポイント イン タイム イメージを復旧するために必要です 4. 本番ホストで アーカイブされたログを保持する LUN の SnapView スナップショット コンシステント セッションを開始します naviseccli h primary_array snapview startsession sessionname lun luns -consistent 例 : naviseccli h CX3801b snapview startsession 4pmArchSession lun 15 consistent この Navisphere CLI コマンドにより 4pmArchSession という名前のコンシステント セッションが LUN 15 に対して開始されます この LUN は ASM ディスク グループ ARCH_DGRP 内にあります アーカイブされたログを含むこの複製された LUN があるため Oracle のデータベース フラッシュバック機能を利用することにより 再起動されたデータベースをステップ 1 で "at3pm" リストア ポイントとしてキャプチャされた既知の SCN にフラッシュバックし その後 アーカイブされたログを使用してロール フォワードできます この時点で ログの適用対象となる使いやすく有効な Oracle バックアップを生成するために必要な すべてのファイルがキャプチャされました セクション Oracle 11g フラッシュバック データベースを使用したリカバリ で この複製されたデータベース LUN のセットを復旧し 有効な Oracle バックアップを生成するために使用するプロセスを説明しています SnapView クローンのコンシステント フラクチャの使用 SnapView コンシステント クローン フラクチャは 1 つのセットとして分離する必要があるすべてのクローン LUN を識別し それらに対して Navisphere CLI の snapview consistentfractureclones コマンドを実行して このクローン全体についてポイント イン タイムの再起動可能なコピーを保持することによって行われます このクローンのセットは 同じストレージ システム内の別のクローン グループに属している必要があります この複製されたクローンは 一貫性があり再起動可能な Oracle データベースのイメージになります キャプチャしたアーカイブ ログを使用して この再起動可能なイメージをロール フォワードするには クローン セットを分離する前後に準備のためのステップが必要です 具体的には フラクチャ前に リストア ポイント を作成することと フラクチャが正常に完了した後に有効な REDO ログがアーカイブされ キャプチャされたことを確認することです 1. 新しいフラッシュバック リストア ポイントを作成します sqlplus /nolog SQL> connect sys/manager as sysdba SQL> drop restore point at3pm; SQL> create restore point at3pm; これにより 通常のリストア ポイントが at3pm という名前で作成されます この名前は この時点におけるデータベースの SCN のエイリアスです 前述したように 通常のリストア ポイントは Flash Recovery Area のサイズと指定された保存期間 ( デフォルトは 1,440 分 ) に応じて時間とともに消滅します 指定されたリストア ポイントに対応するフラッシュバック ログが消滅しないようにするには 代わりに次の SQL コマンドを使用して 保証されたリストア ポイントを作成します SQL> create restore point at3pm guarantee flashback database; EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 20
2. 本番ホストで データベース ファイル REDO ログ ファイル フラッシュバック ログを含む各クローン LUN の状態が Synchronized( 同期 ) または Consistent( コンシステント ) であることを確認します naviseccli h primary_array snapview listclone name clone_groupname cloneid id CloneState 例 : naviseccli h CX3801a snapview listclone name Data1CGroup cloneid 0100000000000000 CloneState naviseccli h CX3801a snapview listclone name Redo1CGroup cloneid 0100000000000000 CloneState 3. 前述のステップでクローンの状態が Synchronized( 同期 ) または Consistent( コンシステント ) であることが確認されたら 本番ホストで このクローン LUN セットについて単一の SnapView コンシステント クローン フラクチャを実行します naviseccli h primary_array snapview consistentfractureclones CloneGroupNameCloneID name1 cloneid1... namen cloneidn o 例 : naviseccli h CX3801a snapview consistentfractureclones -CloneGroupNameCloneID Data1CGroup 0100000000000000 Data2CGroup 0100000000000000 Redo1CGroup 0100000000000000 Redo2CGroup 0100000000000000 FlashCGroup 0100000000000000 o consistentfractureclones コマンドにより クローン LUN がクローン ID 0100000000000000 でクローン グループ Data1CGroup Data2CGroup Redo1CGroup Redo2CGroup FlashCGroup から分離されます これらの LUN は それぞれソース LUN10 11 12 13 14 のクローン (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 81260 有効なすべての REDO ログが ASM ディスク グループ ARCH_DGRP にアーカイブされます アーカイブされたこれらのログは ステップ 3 でキャプチャされたデータベースのポイント イン タイム イメージを復旧するために必要です 5. 本番ホストで アーカイブされたログを保持するクローン LUN の状態が Synchronized ( 同期 ) または Consistent( コンシステント ) であることを確認してから このクローン LUN の SnapView フラクチャを実行します アーカイブされたログが複数の LUN にまた EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 21
がって置かれている場合は ステップ 3 で説明している consistentfractureclones コマンドを使用したコンシステント クローン フラクチャを実行する必要があります naviseccli h primary_array snapview fractureclones name clone_groupname cloneid id o 例 : naviseccli h CX3801b snapview fractureclone name ArchCGroup cloneid 0100000000000000 o この fractureclones コマンドにより クローン LUN がクローン ID 0100000000000000 でクローン グループ ArchCGroup から分離されます この LUN は ソース LUN15(ASM ディスク グループ ARCH_DGRP のメンバー ディスク ) のクローンです アーカイブされたログを含む この複製された LUN があると Oracle のデータベース フラッシュバック機能を利用することにより 再起動されたデータベースをステップ 1 で "at3pm" リストア ポイントとしてキャプチャされた既知の SCN にフラッシュバックし その後 アーカイブされたログを使用してロール フォワードできます この時点で ログの適用対象となる使いやすく有効な Oracle バックアップを生成するために必要な すべてのファイルがキャプチャされました セクション Oracle 11g フラッシュバック データベースを使用したリカバリ で この複製されたデータベース LUN のセットを復旧し 有効な Oracle バックアップを生成するために使用するプロセスを説明しています MirrorView/S コンシステンシ グループを使用したレプリケーション 相互に依存した書き込み順序の整合性を維持するように 複数の LUN にまたがる Oracle データベースのミラーされたイメージをキャプチャするには MirrorView のコンシステンシ グループ機能が必要です コンシステンシ グループは 1 つのエンティティとして管理されるミラーのセットで 常に相互の整合性を保つ必要があります MirrorView のプライマリおよびセカンダリのイメージを設定するために必要なステップ 3 に加えて Oracle データベースを独立したストレージ システムにミラーリングするには コンシステンシ グループを作成し 設定する必要があります このセクションでは コンシステンシ グループを設定するためのステップを説明します MirrorView/S コンシステンシ グループ フラクチャを使用して Oracle データベースのコンシステント レプリケーションを行い セカンダリ ストレージに対して SnapView を使用することでセカンダリ イメージのローカル レプリカを作成します MV/S のすべての例では 以下が前提です アーカイブ REDO ログ フラッシュバック ログなどの本番データベース ファイルは 6 つの LUN にわたって分散され ASM 管理ファイルとして構成される ストレージ システム間に MirrorView 接続が確立されている セカンダリ イメージ (LUN 20 21 22 23 24 25) とのリモート ミラーが適切に作成 設定されている ASM インスタンスが実行中である データベースは archivelog モードで実行され Flash Recovery Area およびフラッシュバック ログが有効になっている 本番ホスト上のデータベースは 現在開いていてアクティブである レプリケーションの間 Oracle データベースはホット バックアップ モードではない 3 ミラー イメージの設定の詳細については EMC MirrorView/Synchronous Command Line Interface (CLI) Reference で説明されています EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 22
データベース ファイル REDO ログ ファイル フラッシュバック ログを保持する LUN は 1 つのコンシステンシ グループになる アーカイブされたログを保持する LUN は 1 つの独立したコンシステンシ グループになる MirrorView/S コンシステンシ グループの作成 SnapView スナップショット開始セッションの場合 およびコンシステント クローン フラクチャの場合と同じように コンシステンシ グループ作成の最初のステップは 関連する LUN 間での書き込み順序の整合性を保つために 1 つのセットとしてミラーリングする必要があるデータベース ソース LUN を決定することです それにより 作成するコンシステンシ グループの数が決まります 次の例では 2 つのコンシステンシ グループを作成しています 1 つはデータベース ファイル REDO ログ ファイル フラッシュバック ログを保持する LUN 用 もう 1 つはアーカイブされたログを保持する LUN 用です 6. 本番ホストで 本番 ( プライマリ ) ストレージ システムに 2 つの MV/S コンシステンシ グループを作成します naviseccli h primary_array mirror sync creategroup -name consistency_groupname o 例 : naviseccli h CX3801a mirror sync creategroup -name mirrordb_cgroup -o naviseccli h CX3801b mirror sync creategroup -name mirrorarch_cgroup o この creategroup コマンドにより mirrordb_cgroup と mirrorarch_cgroup という 2 つのコンシステンシ グループがプライマリ ストレージ システムに作成されます 7. 本番ホストで 作成されたコンシステンシ グループにミラーリングを追加します naviseccli h primary_array mirror sync addtogroup -name consistency_groupname mirrorname mirror_name 例 : naviseccli h CX3801a mirror sync addtogroup -name mirrordb_cgroup -mirrorname Data1_mirror naviseccli h CX3801b mirror sync addtogroup -name mirrorarch_cgroup mirrorname Arch_mirror addtogroup コマンドでは 1 つのコンシステンシ グループに同時に 1 つのリモート ミラーのみを追加できます リモート ミラー Data1_mirror Data2_mirror Redo1_mirror Redo2_mirror Flash_mirror がすべてコンシステンシ グループ mirrordb_cgroup のメンバーである場合などは この addtogroup コマンドを繰り返します コンシステンシ グループが作成され そこに 1 つまたは複数のミラーが追加されると MV/S は自動的に同じ名前のコンシステンシ グループとその内容をセカンダリ ストレージ システム上に作成します コンシステンシ グループ内にミラーが作成されると そのミラーを個別に管理することはできません コンシステンシ グループ コマンドを使用して グループとして管理する必要があります MirrorView/S コンシステンシ グループの使用 MirrorView/S コンシステンシ グループ フラクチャは コンシステンシ グループの名前を Navisphere CLI の mirror sync fracturegroup コマンドに指定することによって実行されます コンシステンシ グループは フラクチャの前に Synchronized( 同期 ) または Consistent( コンシステント ) 状態になっている必要があります 分離されると セカンダリ ストレージ シス EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 23
テム上の対応するコンシステンシ グループをプロモート スナップ またはクローン分離でき セカンダリ イメージへの I/O アクセスが可能になります セカンダリ ストレージ システム上のこのミラー セットは 一貫性があり再起動可能な Oracle データベースです キャプチャしたアーカイブ ログを使用して この再起動可能なイメージをロール フォワードするには コンシステンシ グループを分離する前後に準備のためのステップが必要です 具体的には フラクチャ前に リストア ポイント を作成することと フラクチャが正常に完了した後に有効な REDO ログがアーカイブされ キャプチャされたことを確認することです 8. 新しいフラッシュバック リストア ポイントを作成します sqlplus /nolog SQL> connect sys/manager as sysdba SQL> drop restore point at3pm; SQL> create restore point at3pm; これにより 通常のリストア ポイントが at3pm という名前で作成されます この名前は この時点におけるデータベースの SCN のエイリアスです 前述したように 通常のリストア ポイントは Flash Recovery Area のサイズと指定された保存期間 ( デフォルトは 1,440 分 ) に応じて時間とともに消滅します 指定されたリストア ポイントに対応するフラッシュバック ログが消滅しないようにするには 代わりに次の SQL コマンドを使用して 保証されたリストア ポイントを作成します SQL> create restore point at3pm guarantee flashback database; 9. 本番ホストで データベース ファイル REDO ログ ファイル フラッシュバック ログを含むコンシステンシ グループの状態が Synchronized( 同期 ) または Consistent( コンシステント ) であることを確認します naviseccli h primary_array mirror -sync listgroups name consistency_groupname state 例 : naviseccli h CX3801a mirror -sync listgroups name mirrordb_cgroup state 10. 前述のステップでコンシステンシ グループの状態が Synchronized( 同期 ) または Consistent ( コンシステント ) であることが確認されたら 本番ホストでコンシステント クローン フラクチャを実行します naviseccli h primary_array mirror -sync fracturegroup -name consistency_groupname o 例 : naviseccli h CX3801a mirror -sync fracturegroup -name mirrordb_cgroup o この fracturegroup コマンドにより コンシステンシ グループ mirrordb_cgroup 内のすべてのミラー イメージが分離されます このコンシステンシ グループのメンバーは ソース LUN 10 11 12 13 14 と セカンダリ ストレージ システム (ASM ディスク グループ DATA_DGRP REDO_DGRP RECOVR_DGRP のメンバー ディスク ) 上でそれに対応するミラーされた LUN です フラクチャが完了すると セカンダリ ストレージ上の対応するイメージは 整合性のとれたポイント イン タイムにおける データベースの再起動可能なイメージになっており これをセカンダリ サーバで使用することができます 11. アーカイブされていないすべてのログをアーカイブします sqlplus /nolog SQL> connect / as sysdba SQL> alter system archive log current; EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 24
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 81750 有効なすべての REDO ログが ASM ディスク グループ ARCH_DGRP にアーカイブされます アーカイブされたこれらのログは ステップ 3 でキャプチャされたデータベースのポイント イン タイム イメージを復旧するために必要です 12. 本番ホストで アーカイブされたログを保持するコンシステンシ グループの状態が Synchronized( 同期 ) または Consistent( コンシステント ) であることを確認 ( ステップ 2 を参照 ) してから コンシステンシ グループのフラクチャを実行します naviseccli h primary_array mirror sync fracturegroup -name consistency_groupname o 例 : naviseccli h CX3801b mirror sync fracturegroup -name mirrorarch_cgroup o この fracturegroup コマンドにより コンシステンシ グループ mirrordb_cgroup 内のすべてのミラー イメージが分離されます このコンシステンシ グループのメンバーは ソース LUN 15 と セカンダリ ストレージ システム (ASM ディスク グループ ARCH_DGRP のメンバー ディスク ) 上でそれに対応するミラーされた LUN です アーカイブされたログを含むこのコンシステンシ グループ内にセカンダリ ミラー イメージがあるため Oracle のデータベース フラッシュバック機能を利用することにより セカンダリ サーバから 再起動されたデータベースをステップ 1 で "at3pm" リストア ポイントとしてキャプチャされた既知の SCN にフラッシュバックし その後 アーカイブされたログを使用してロール フォワードできます この時点で ログの適用対象となる使いやすく有効な Oracle バックアップを生成するために必要な すべてのファイルがセカンダリ ストレージ アレイ上でキャプチャされました これで SnapView スナップショットまたはクローンを使用して セカンダリ ストレージ アレイ上にセカンダリ ミラー イメージのレプリカをすばやく作成することができます どちらの場合も 高いレベルの保護が提供されますが クローンではディスクの保護があり スナップショットよりもパフォーマンスへの影響が軽度です SnapView 操作が完了すると ミラーリングの関係を再確立できます MirrorView/S コンシステンシ グループにおける SnapView の使用セカンダリ ストレージで SnapView を MirrorView/S と組み合わせて使用すると セカンダリ イメージのローカル レプリカを取得することができます これにより セカンダリ イメージをプロモートしなくても セカンダリ サーバからセカンダリ ストレージ上のデータにアクセスできます SnapView のコンシステンシ操作は コンシステンシ グループ レベルでは実行できません コンシステンシ グループの個別のメンバーに対して実行する必要があります セカンダリ ミラー イメージの SnapView スナップショット コンシステント セッションを開始するには 次の手順に従います 1. セカンダリ サーバから データベース ファイル REDO ログ ファイル およびフラッシュバック ログを保持する LUN のコンシステント スナップショット セッションを開始します EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 25
naviseccli h CX3802a snapview startsession 4pmDataSession lun 20 21 22 23 24 consistent 2. セカンダリ サーバで アーカイブされたログを保持する LUN のコンシステント スナップショット セッションを開始します naviseccli h CX3802b snapview startsession 4pmArchSession lun 15 consistent セカンダリ ミラー イメージについて SnapView クローンのコンシステント フラクチャを開始するには 次の手順に従います 1. セカンダリ サーバから データベース ファイル REDO ログ ファイル およびフラッシュバック ログを保持する LUN のコンシステント クローン フラクチャを開始します naviseccli h CX3802a snapview consistentfractureclones -CloneGroupNameCloneID Data1CGroup 0100000000000000 Data2CGroup 0100000000000000 Redo1CGroup 0100000000000000 Redo2CGroup 0100000000000000 FlashCGroup 0100000000000000 o 2. セカンダリ サーバで アーカイブされたログを保持する LUN のコンシステント セッションを開始します naviseccli h CX3802b snapview fractureclone name ArchCGroup cloneid 0100000000000000 o 次のセクション Oracle 11g フラッシュバック データベースを使用したリカバリ で この複製されたデータベース LUN のセットを復旧し 有効な Oracle バックアップを生成するために使用するプロセスを説明しています Oracle 11g フラッシュバック データベースを使用したリカバリ 複製された LUN のセットをセカンダリ サーバで使用可能にするために必要なステップは 実行するレプリケーションがコンシステント レプリケーションであるかどうかに関係なく同じです セカンダリ サーバがスナップショット セッションまたは分離されたクローンにアクセスするためには それらが属するストレージ グループがセカンダリ サーバに接続され セカンダリ サーバで有効化およびマウントされていることが必要です 設定と有効化の詳細については 関連資料 セクションを参照してください このセクションでは ストレージ ベースのコンシステンシ機能を使用してキャプチャされた LUN の複製されたセットから データベースをマウント 開始 および復旧するために必要なステップについて説明します LUN の複製されたセットをキャプチャした手段がスナップショット クローン コンシステンシ グループのいずれであっても Oracle の起動およびリカバリのプロセスは同じです 以下の前提が考慮されます セカンダリ サーバは本番サーバと OS が同じであり 同じバージョンの Oracle 11g が実行されている LUN の複製されたセットがセカンダリ サーバで適切に有効化され アクセス可能になっている セカンダリ サーバで ASM インスタンスが起動している ストレージ複製された LUN のセットは 対応するソース LUN とビット レベルで同一です 同じ ASM ディスク シグネチャ情報を持ち したがって 同じ ASM ディスク グループに属します これらの LUN は セカンダリ サーバからアクセス可能になったら 次のような SQL コマンドを使用して ASM インスタンスによってマウントする必要があります EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 26
$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 データベース インスタンスを再起動し LUN が複製される前にキャプチャされたリストア ポイントにデータベースをフラッシュバックすることができます $sqlplus /nolog SQL> connect / as sysdba SQL> startup mount; SQL> flashback database to restore point at3pm; フラッシュバック コマンドが正常に完了した後 データベースはそのままマウントされた状態で 指定されたリストア ポイントに復旧されます データベースが目的のポイント イン タイムに戻ったことを確認するには データベースを読み取り専用モードで開き データベースの内容を調べるクエリーをいくつか実行します この時点で データベースを復旧し ロール フォワードすることができます それには レプリケーション プロセスでキャプチャされた アーカイブされたログのセットを利用し データベースをどれだけ進めるかを指定 ( 変更番号によって または特定のポイント イン タイムまで ) します これで Oracle データベースを更新できるようになります 次の 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 データベースは完全に使用可能なデータベースになり 他の目的に使用したり 耐久性の高いメディアにバックアップしたりすることができます 整合性テストの表と結果 テスト フラッシュバック有効データベース非ホット バックアップ フラッシュバック有効データベース非ホット バックアップディスク グループ リバランス進行中 スナップ セッション開始正常に再起動 フラッシュバック ロール フォワード正常に再起動 フラッシュバック ロール フォワード 結果クローン フラクチャ正常に再起動 フラッシュバック ロール フォワード正常に再起動 フラッシュバック ロール フォワード MV/S フラクチャ正常に再起動 フラッシュバック ロール フォワード正常に再起動 フラッシュバック ロール フォワード 実行回数 10 10 EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 27
フラッシュバック無効データベース非ホット バックアップディスク グループ リバランス進行中 正常に再起動正常に再起動正常に再起動 10 結論 SnapView および MirrorView/S の新しいコンシステンシ機能は データベース レプリケーションを必要とする Oracle 環境を簡素化する新しいオプションを提供します レプリケーション プロセスの間 Oracle データベースをホット バックアップ モードにする必要がないため ホスト側のパフォーマンスはほとんど影響を受けません そのため この方法は 使いやすいデータベース レプリカを頻繁に作成する場合に 運用面で実用性に優れています ASM が管理するファイルを使用した Oracle データベースの複製も簡素化されます SnapView または MirrorView のコンシステンシ機能を使用して ASM ディスク メンバーがセットとして複製される場合は ASM が再起動のために利用するメタデータも複製されます ASM メタデータの整合性を確保するための手動操作は不要です ASM は クラッシュ時に ASM インスタンスを再起動して ASM ディスク グループを再マウントできます CLARiX における Oracle データベースにおけるストレージ ベースのコンシステント レプリケーションは ソースのポイント イン タイム レプリカであることと 書き込み順序の整合性が保証されます この複製されたセットは 一貫性があり再起動可能な Oracle イメージで Oracle 11g の Flash Recovery Area および Flashback Database 機能と組み合わせて使用することにより キャプチャされたアーカイブ ログを使用してデータベースを復旧し ロール フォワードすることができます ストレージ ベースのコンシステント レプリケーションと Oracle 11g のフラッシュバック機能を組み合わせることで 本番環境に影響を与えることなく 使いやすく有効な Oracle バックアップを作成する手段が得られます 関連資料 製品ドキュメント Oracle Database Backup and Recovery User s Guide 11g Release 1 (11.1) Oracle Database Concepts 11g Release 1 (11.1) EMC Navisphere Manager Administrator's Guide EMC Navisphere Command Line Interface (CLI) Reference EMC SnapView for Navisphere Administrator's Guide EMC SnapView Command Line Interfaces (CLI) Reference EMC MirrorView/Synchronous for Navisphere Administrator s Guide EMC MirrorView/Synchronous Command Line Interface (CLI) Reference ホワイト ペーパー EMC CLARiiON SnapView and MirrorView for Oracle Database 10g Automatic Storage Management Best Practices Planning MirrorView Knowledgebook: FLARE 26 - Applied Technology EMC CLARiiON RAID 6 Technology - A Detailed Review EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 28
EMC CLARiX データベース ストレージ ソリューション :Oracle 10g および Oracle 11g と CLARiX の組み合わせにおけるストレージ レプリケーションの整合性高度なテクノロジー 29