| Oracle Streams概要および管理 11g リリース1（11.1） E05775-02 |
|
 前へ |
 次へ |
この章では、Oracle Streams高可用性環境について説明します。
高可用性ソリューションの構成には、念入りな計画と障害発生時の使用例の分析が必要です。データベース・バックアップとフィジカル・スタンバイ・データベースでは、フェイルオーバー保護用にソース・データベースの物理コピーが提供されます。Oracle Data Guardには、SQL Applyモードの場合、高可用性環境にロジカル・スタンバイ・データベースが実装されます。Oracle Data Guardは高可用性環境用に設計されているため、ほとんどの障害発生例に対応します。ただし、一部の環境で、Oracle Streamsによって実現された柔軟性が必要になる場合には、Oracle Streamsによって提供される拡張機能セットが使用可能です。
この章では、Oracle Streamsベースのソリューションが適している使用例と、高可用性環境で発生するOracle Streams固有の問題を説明します。
|
関連項目:
|
インスタンスまたはシステム障害から保護するには、Oracle Real Application Clusters（Oracle RAC）が適しています。障害が発生すると、クラスタ内にある障害の発生していない方のノードによってサービスが提供されます。ただし、クラスタ化では、ユーザー・エラー、メディア障害および障害からは保護されません。このような障害には、データベースの重複コピーが必要です。データベースの物理コピーと論理コピーの両方を作成できます。
物理コピーはブロック単位でソース・データベースと同一になるように行われるもので、データ保護に適した方法です。物理コピーにはデータベース・バックアップ、ミラー化または多重データベース・ファイル、フィジカル・スタンバイ・データベースの3タイプがあります。
論理コピーにはソース・データベースと同じ情報が含まれますが、情報はデータベース内に異なる形式で格納できます。データベースの論理コピーを作成することには、多くのメリットがあります。 ただし、論理コピーの作成は、常に物理コピーも作成したうえで行う必要があります。物理コピーの代替として作成しないでください。
論理コピーには、次のメリットがあります。
更新中に論理コピーを開くことができます。このため、論理コピーはほぼリアルタイムのレポートに役立ちます。
論理コピーに様々な物理レイアウトを指定し、目的に応じて最適化できます。たとえば、追加の索引を含めることができ、その結果として論理コピーを利用したレポート・アプリケーションのパフォーマンスが改善されます。
論理コピーによって、破損からの保護が強化されます。データは論理的に取得および適用されるため、物理的な破損がデータベースの論理コピーに伝播することはほとんど考えられません。
データベースの論理コピーには3タイプあります。
ロジカル・スタンバイ・データベース
Oracle Streamsレプリカ・データベース
アプリケーションによるコピーのメンテナンス
ロジカル・スタンバイ・データベースは、SQL ApplyモードのOracle Data Guardを使用した場合に最適な状態でメンテナンスされます。この章の後半では、Oracle Streamsレプリカ・データベースとアプリケーションによるコピーのメンテナンスを説明します。
|
関連項目:
|
SQL ApplyモードのOracle Data Guardと同様に、Oracle Streamsを使用して、データベース変更を取得して宛先に伝播し、変更をこれらの宛先に適用できます。Oracle Streamsは、データのレプリケートのために最適化されます。Oracle Streamsでは、ソース・データベースの変更が取得され、取得された変更がレプリカ・データベースへ非同期に伝播できます。この最適化によって待機時間を短縮し、レプリカのプライマリ・データベースからの遅れを数秒以内に抑えることができます。
それでもなお、本番データベースの論理コピーの構成およびメンテナンスにOracle Streamsの使用を選択する場合があります。Oracle Streamsを使用すると追加の作業が必要になりますが、固有のビジネス要件を満たすために必要な優れた柔軟性が提供されます。Oracle Streamsを使用して構成およびメンテナンスされる論理コピーでは、通常定義のスタンバイ・データベースの範囲を超える多くの機能が提供されるため、ロジカル・スタンバイではなくレプリカと呼ばれます。Oracle Streamsレプリカの使用が適した要件の一部を次の項に示します。
|
関連項目: Oracle Streamsを使用してデータベース変更をレプリケートする方法の詳細は、Oracle Streamsレプリケーション管理者ガイドを参照 |
レプリカ・データベースとスタンバイ・データベースの最大の違いは、レプリカ・データベースが更新可能であるのに対し、スタンバイ・データベースは更新不可である点です。ジョブや、レポート・アクティビティをログに記録するレポート・アプリケーションなど、データの更新が必要なアプリケーションをレプリカに対して実行できます。また、レプリカ・データベースでは、ローカル・アプリケーションをWANの障害から保護し、データベース操作の待機時間を減少させながら、自律的に実行できます。
本番データベースとレプリカ・データベースは、同じプラットフォーム上で稼働している必要はありません。そのため、コンピュータ資産の使用が柔軟になり、プラットフォーム間の移行が容易になります。
Oracle Streamsレプリカでは、本番データベースとは異なるキャラクタ・セットを使用できます。データは、適用される前に、1つのキャラクタ・セットから別のキャラクタ・セットに自動的に変換されます。グローバル操作を使用していて、データを複数の国に配布する必要がある場合に、この機能はきわめて重要です。
レプリカをほぼリアルタイムのレポートに使用すると、Oracle Streamsの本番データベースからの遅れが数秒以内に抑えられ、最新で正確な問合せが提供できます。変更は、アーカイブ後のREDOログからではなく、記録中のオンラインREDOログから読取り可能です。
Oracle Streamsでは、無制限の数のレプリカがサポートされます。その柔軟なルーティング・アーキテクチャではハブ・アンド・スポーク構成が考慮されおり、データを何百ものレプリカに効率的に伝播できます。組織の多くのローカル・オフィスで自律型運用を行う必要がある場合、この機能が重要になることがあります。これに対して、Oracle Data Guardによって構成されるスタンバイ・データベースではLOG_ARCHIVE_DEST_n 初期化パラメータを使用して宛先を指定するため、Oracle Data Guardを使用するとコピーの数が10に制限されます。
|
関連項目:
|
前述のように、一部の高可用性の要件を満たすためにOracle Streamsの使用を選択する使用例があります。高可用性のルールの1つは、単純さの保持です。Oracle Data Guardは高可用性のために設計されており、Oracle Streamsベースの高可用性ソリューションよりも実装が容易です。Oracle Streamsによって提供される柔軟性を利用する場合は、Oracle Streamsベースのソリューションを強固にするために必要な専門技術と計画に投資する準備が必要です。つまり、Oracle Data Guardで提供される自動化および管理ツールのほとんどを、スクリプトを作成して実装する必要があります。
データの論理コピーのメンテナンスをアプリケーションで直接実行するように設計すると、可用性を最大限にできます。重要なデータやデータ消失を防ぐためオフサイトに即時移動する必要のあるデータは、アプリケーションで認識されています。また、重要なデータは同期式にレプリケートでき、それほど重要でないデータは非同期式にレプリケートできます。アプリケーションでは、別のデータの論理コピーを管理する他のアプリケーションにデータを同期式または非同期式に送信することによって、データのコピーがメンテナンスされます。同期操作は、分散SQLまたはデータベースのリモート・プロシージャ機能を使用して実行されます。非同期操作は、アドバンスト・キューイングを使用して実行されます。アドバンスト・キューイングは、Oracle Streamsに備えられているデータベース・メッセージ・キューイング機能です。
アプリケーションによるデータ・コピーのメンテナンスでは、最高レベルの可用性が実現可能ですが、最大限の注意が必要です。通常、多くのカスタム開発が必要になります。Oracle Data GuardやOracle Streamsレプリケーションなどのソリューションによって分析および解決されてきた難しい境界条件の多くを、カスタム・アプリケーションの開発者が再分析し解決する必要があります。 また、Oracle Data GuardやOracle Streamsレプリケーションのような標準ソリューションは、オラクル社と顧客の両方による厳密なテストを通過しています。カスタム開発のソリューションが同じ程度の完成度を示すまでには、大変な労力が必要です。これらの理由から、アプリケーションによるコピーのメンテナンス機能を持つ高可用性ソリューションの構築は、時間と専門技術が十分にある組織のみが行うようにします。
|
関連項目: アドバンスト・キューイングを使用したアプリケーション開発の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照 |
高可用性環境にOracle Streamsを実装するには、発生する可能性のある障害とリカバリでの使用例を考慮し、障害発生後にもOracle Streamsで引き続き変更を取得、伝播および適用できるプロシージャを実装する必要があります。次の項目を確認します。
Oracle Streamsを使用したソリューションを構成する場合、障害を予想し、アーキテクチャ内に可用性を組み込んで設計することが重要です。分散システム内の各データベースを調べ、そのデータベースに障害が発生した場合のリカバリ・プランを設計する必要があります。データベース障害の影響する対象が、そのデータベースのデータにアクセスするサービスのみの場合もあれば、 他のデータベースにも影響して、障害が拡大する場合もあります。
この項の内容は次のとおりです。
分散システム内の各データベースがその他すべてのデータベースと個々に直接接続した構成では、1つのデータベースに障害が発生しても他のデータベースでの操作または通信を妨げないため、障害に対して最も耐性があります。すべてのデータがレプリケートされていれば、障害の発生したデータベースを使用していたサービスは、障害の発生していないレプリカに接続できます。
各データベースがその他すべてのデータベースと個々に直接接続された構成では、最高の高可用性特性が提供されますが、データベースの数が増加すると管理が困難になります。この管理上の問題は、ハブ・アンド・スポーク構成で、多くのデータベースからの変更をハブ・データベースを介してから他のハブ・データベースまたは他のスポーク・データベースに伝播することによって解決されます。新規ソースまたは宛先の追加は、データベースごとに接続を確立するのではなく、ハブ・データベースへの接続を行うのみです。
ただし、ハブは分散環境において非常に重要なノードになります。それに障害が発生すると、ハブを介して行われるすべての通信に障害が発生します。ハブを介して伝播するメッセージは非同期な性質を持つため、あるハブから別のハブにストリームをリダイレクトすることは非常に困難です。適切なアプローチとは、ハブを障害に対して耐性がある状態にすることです。
単一データベースを障害に対して耐性がある状態にするために使用した手法は、分散ハブ・データベースにも適用されます。インスタンスおよびノードの障害からの保護には、Oracle Real Application Clusters（Oracle RAC）を使用することをお薦めします。障害とデータ・エラーから保護するためには、この構成を損失のないフィジカル・スタンバイ・データベースと結合する必要があります。障害とデータ・エラーからの保護方法としてOracle Streamsレプリカのみを使用することは、お薦めしません。
|
関連項目:
|
Oracle Streamsの取得プロセスを使用して、ローカル・ソース・データベース、または異なるサイトのダウンストリーム・データベースに存在するREDOログ内の変更を取得できます。ローカル取得またはダウンストリーム取得の選択は、可用性に影響を及ぼします。ソース・データベースに障害が発生した場合、一部の変更は取得されていない場合があります。ローカル取得の場合、それらの変更はソース・データベースがリカバリされるまで取得できない場合があります。突発的な障害が発生した場合、変更が失われる場合があります。
リモート・データベースでダウンストリーム取得を実行すると、障害発生時のデータ消失の可能性が減少します。構成によっては、ダウンストリーム取得を使用して、ソース・データベースでコミットされたすべての変更が安全にリモート・サイトにコピーされることを保証できます。リモート・サイトでは、それらの変更を他のデータベースやアプリケーションに取得および伝播できます。Oracle Streamsは、Oracle Data Guardと同じメカニズムを使用してリモートの宛先にREDOデータまたはログ・ファイルをコピーし、最大限の保護、最大の可用性、最大限のパフォーマンスなどの、同じ操作モードをサポートします。
|
注意: 同期取得は常に、ソース・データベースで構成されます。 |
ここでは、障害からのリカバリのベスト・プラクティスを説明します。
この項の内容は次のとおりです。
障害発生後に単一ノードのデータベースが再起動されるか、または障害発生後にコールド・フェイルオーバー・クラスタ内の別のノード上にあるデータベースが再起動されると、取得プロセスは障害発生時の状態に自動的に戻ります。つまり、障害発生時に取得プロセスが実行中であった場合は、自動的に再起動されます。
宛先データベースのインスタンスで障害が発生した後も、伝播が引き続き機能することは重要です。障害発生後、伝播ジョブでは接続が再確立されるまでデータベース・リンクが16回再試行されます（再試行と次の再試行との間隔は徐々に長くなります）。16回目の再試行後も接続が再確立されない場合、伝播スケジュールは無効になります。
データベースが同じノード、またはコールド・フェイルオーバー・クラスタ内の別のノードで再起動された場合、接続の再確立が必要になります。状況によってはデータベース・リンクが読取りまたは書込みを待機している場合があり、冗長なタイムアウトが期限切れになるまで、障害は検出されません。タイムアウトは、TCP_KEEPALIVE_INTERVAL TCP/IPパラメータによって制御されます。このような場合は、データベース・リンクを一度削除してから再作成し、通信が迅速に再確立されるようにする必要があります。
高可用性環境では、必要なデータベース・リンクすべてを削除および再作成するスクリプトを準備することが考えられます。フェイルオーバー後、これらのスクリプトを実行し、Oracle Streamsで伝播を再開できます。
|
関連項目:
|
メッセージをソース・キューから宛先キューに伝播させるには、ソース・キューを所有しているインスタンス上で伝播ジョブを実行する必要があります。単一ノードのデータベースまたはコールド・フェイルオーバー・クラスタでは、単一データベース・インスタンスが再起動されると伝播が再開されます。
障害発生後に単一ノードのデータベースが再起動されるか、または障害発生後にコールド・フェイルオーバー・クラスタ内の別のノード上にあるデータベースが再起動されると、適用プロセスは障害発生時の状態に自動的に戻ります。つまり、障害発生時に適用プロセスが実行中であった場合は、自動的に再起動されます。
