EMC CLARiXデータベース・ストレージ・ソリューション：Oracle 10gおよびOracle 11gとCLARiXの組み合わせにおけるストレージ・レプリケーションの整合性

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

目次

T高度なテクノロジー ... 0

T

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

エグゼクティブ・サマリー

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 が処理しなければならない記録が増えるので、ホスト側のパ フォーマンスは影響を受けます。

しかし、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 61_{テクノロジーが導入されました。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 の詳細 が説明されています。

になっている場合、サービスはフェイルバックにより元々割り当てられていた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 つのストレージ・グループに複数のホストを接続できるのは、クラスタ環境の場合だけです。

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

クローンを使用してポイント・イン・タイム・コピーを保存するには、クローンがそのソース LUN から分離される必要があります。分離され、セカンダリ・ホストにマウントされたクロー ンには、I/O を行うことができます。ソース LUN と分離されたクローン LUN はそれぞれのサー バによって変更される毎に、クローン・プライベート LUN は、クローンが分離された後に変更 されたソースとクローンの領域を記録します。図 2 に、これを示します。 MirrorView/S は、クリティカルなビジネス・データのリモート・レプリケーションを行う同期型 の製品です。MV/S は、災害復旧のために、離れた場所にあるストレージ・システムの LUN の間 でリアルタイムにデータをミラーリングし、同期させます。同期モードでは、ローカル/プライ マリ・ストレージ・システムに対するサーバ書き込みが完了するのは、リモート/セカンダリ・ ストレージ・システムへのデータ転送が成功した後になります。同期モードでは、リモート・イ メージがソース・イメージの完全かつ正確な複製であることが保証されます。 図 3 に、サンプルのリモート・ミラー構成を示します。SnapViewをMV/Sと組み合わせて使用す ることにより（FLARE®_{リリース 24 以降の場合）、プライマリまたはセカンダリのミラー・イメ} ージのスナップショットまたはクローンを作成し、それを使用して検証を実行したり、バックア ップ、レポート、テストなどの並行処理プロセスを実行したりすることができます。これにより、 ローカルとリモートの両方のサイトに新たなレベルの保護が追加され、どちらかに障害が発生し た際に備えることができます。

図 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 ブロックへのその後の書き込みは、すでにオリジ

ナルのブロックが予約済み 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 の両方につい て、変更されたデータ・ブロックを識別する情報の記録を開始します。この記録により、クロー

ンとそのソース 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 データベース など、内容に関連性があり、相互に依存した書き込み順序の整合性を持つことが分かっていて、 使用するためにはセットとして複製する必要があるものです。これらのミラーは、コンシステン

シ・グループのメンバーになると個別に分離、同期、プロモートすることはできません。これら のアクションは、グループのすべてのメンバー・ミラーに対してまとめて実行する必要がありま す。グループ内の 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 機能と組み合わせて使用することにより、キャプチャされたアーカイブ・ログを使用し て、後からロール・フォワードすることができます。

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 が処

理しなければならないチェック・ポイント作成、ログ記録、ログ切り替えといった追加の作業に より、ホスト側のパフォーマンスが影響を受けます。

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

ストレージ・ベースの整合性は、サーバ上の 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 機能を使用すると、この再起 動可能なデータベースをフラッシュバックして、既知の整合性のとれたポイント・イン・タイム

に戻すことができます。データベースが 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 のこのマッピングは、制御ファイルに格

納されます。通常のリストア・ポイントまたは保証されたリストア・ポイントは、次の 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 メタデータとデータベース・データの両方を、レプリケーションの間

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 データベースを複製し、その後リ カバリするために必要なステップの高レベルの概要を示します。

D DBBddaattaaLLUUNNss R ReeddoollooggLLUUNN((ss)) 1 111ggffllaasshh__rreeccoovveerryy__aarreeaaLLUUNN((ss)) Oracle Database 11g RAC production service

2. Generate PIT consistent SnapView replica 1. Create flashback restore point 4. Restart DB on backup host

5. Oracle DB flashback to restore point to create a database with known transaction

content

3. Mount consistent replica set to backup host

図 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 インスタンスを必要とします。通常のデータベース・インスタンスと同様に、

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」コマンド

を「-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

有効なすべての 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 コマンドを使用して、保証 されたリストア・ポイントを作成します。