1 Oracle Data Guardの概要
Oracle Data Guardは、企業データの高可用性、データ保護および障害時リカバリを保証します。
Oracle Data Guardは、1つ以上のスタンバイ・データベースの作成、メンテナンス、管理および監視など、一連の包括的なサービスを提供し、本番のOracleデータベースを障害およびデータ破損から保護します。Oracle Data Guardでは、これらのスタンバイ・データベースを本番データベースのコピーとしてメンテナンスします。したがって、本番データベースが計画的または計画外の停止によって使用不可能になった場合は、スタンバイ・データベースを本番ロールに切り替えて、停止時間を最小限にできます。Oracle Data Guardを従来のバックアップ、リストアおよびクラスタ化の技法と連携して使用すると、高いレベルのデータ保護とデータ可用性を実現できます。Oracle Data Guard転送サービスは、ソース・データベースから1つ以上のリモートの宛先への効率的で信頼性の高いREDO転送のため、Oracle StreamsやOracle GoldenGateなどの他のOracleの機能によっても使用されます。
Oracle Data Guardを使用すると、リソース集中型のバックアップおよびレポート生成操作をスタンバイ・システムにオフロードすることで、管理者は本番データベースのパフォーマンスをオプションで改善できます。
Oracle Data Guardの概要を説明する次の項を参照してください。
1.1 Oracle Data Guardの構成
Oracle Data Guard構成には、1つのプライマリ・データベースと最大30の宛先が含まれます。
Oracle Data Guard構成内のメンバーはOracle Netで接続され、地理的に散在していてもかまいません。Oracle Data Guard構成内のメンバーの配置場所に制限はありませんが、相互に通信できる必要があります。たとえば、1つのスタンバイ・データベースをプライマリ・データベースと同じデータ・センターに、2つのスタンバイ・データベースを別のデータ・センターに配置できます。
プライマリ・データベースとスタンバイ・データベースはSQLコマンドライン・インタフェースまたはOracle Data Guard Brokerインタフェースを使用して管理できます。ブローカでは、コマンドライン・インタフェース(DGMGRL)や、Oracle Enterprise Manager Cloud Controlに統合されたグラフィカル・ユーザー・インタフェースが提供されます。
1.1.2 スタンバイ・データベース
スタンバイ・データベースは、トランザクション上の一貫性を持つ、プライマリ・データベースのコピーです。
プライマリ・データベースのバックアップ・コピーを使用すると、最大30個のスタンバイ・データベースを作成して、Oracle Data Guard構成に組み込むことができます。Oracle Data Guardでは、プライマリ・データベースからスタンバイ・データベースにREDOデータを転送し、スタンバイ・データベースにREDOを適用することによって、各スタンバイ・データベースを自動的にメンテナンスします
プライマリ・データベースと同様に、スタンバイ・データベースは、単一インスタンスOracleデータベースまたはOracle RACデータベースのいずれかになります。
スタンバイ・データベースのタイプは、次のとおりです。
-
フィジカル・スタンバイ・データベース
プライマリ・データベースと物理的に同一のコピーを提供します。これはプライマリ・データベースとブロック単位で同じディスク・データベース構造です。データベース・スキーマ(インデックスを含む)は同一です。フィジカル・スタンバイ・データベースは、REDO Applyによってプライマリ・データベースとの同期が保たれます。REDO Applyでは、プライマリ・データベースから受け取ったREDOデータがリカバリされ、このREDOがフィジカル・スタンバイ・データベースに適用されます。
Oracle Database 11gリリース1 (11.1)現在、フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンしている間はREDOを受信および適用できます。そのため、フィジカル・スタンバイ・データベースは、データ保護とレポート生成に同時に使用できます。
さらにOracle Database 11gリリース2 (11.2.0.1)現在、フィジカル・スタンバイ・データベースを使用して、適格な個別パッチ、パッチ・セット更新(PSU)およびクリティカル・パッチ・アップデート(CPU)をローリングという方法でインストールできます。この機能の詳細は、
http://support.oracle.comのMy Oracle Supportノート1265700.1を参照してください。 -
ロジカル・スタンバイ・データベース
本番データベースと同じ論理情報が格納されますが、データの物理的な構成と構造は異なる場合があります。ロジカル・スタンバイ・データベースでは、プライマリ・データベースから受信したREDOデータをSQL文に変換し、スタンバイ・データベースでそのSQL文を実行するSQL Applyによって、プライマリ・データベースとの同期を維持します。
ロジカル・スタンバイ・データベースの柔軟性の高さにより、ローリング方式でほとんど停止時間なく、Oracle Databaseソフトウェア(パッチ・セットおよび新しいOracle Databaseリリース)をアップグレードし、その他のデータベースのメンテナンスを実行することができます。Oracle Database 11g以降から、一時ロジカル・データベースのローリング・アップグレード・プロセスを、既存のフィジカル・スタンバイ・データベースとともに使用することもできます。
-
スナップショット・スタンバイ・データベース
スナップショット・スタンバイ・データベースは完全に更新可能なスタンバイ・データベースです。
フィジカルまたはロジカル・スタンバイ・データベースと同様に、スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信し、アーカイブします。フィジカルまたはロジカル・スタンバイ・データベースとは異なり、スナップショット・スタンバイ・データベースは、受信したREDOデータを適用しません。スナップショット・スタンバイ・データベースが受信したREDOデータは、スナップショット・スタンバイが元のフィジカル・スタンバイ・データベースに変換され、スナップショット・スタンバイ・データベースに対するすべてのローカルな更新が破棄された後に適用されます。
スナップショット・スタンバイ・データベースの最適な使用例は、更新可能なフィジカル・スタンバイ・データベースのスナップショットが一時的に必要な場合です。たとえば、Oracle Real Application Testingのオプションを使用してプライマリ上のデータベース・ワークロードを取得して、スナップショット・スタンバイでのテストの目的でそれに応答できます。スナップショット・スタンバイ・データベースで受信されたREDOデータは、フィジカル・スタンバイに変換されて戻るまで適用されないため、プライマリ・データベースの障害からリカバリするのに必要な時間は、適用する必要があるREDOデータの量に正比例します。
関連項目:
-
Oracle Real Application Testingおよびその使用に必要なライセンスの詳細は、Oracle Database Testingガイドを参照してください
1.1.3 遠隔同期インスタンス
Oracle Data Guard遠隔同期インスタンスは、プライマリ・データベースからREDOを受け取り、それをOracle Data Guard構成の他のメンバーに送信する、リモートのOracle Data Guardの宛先です。
遠隔同期インスタンスは、制御ファイルを管理し、REDOをスタンバイREDOログ(SRL)に受信し、それらのSRLをローカルのアーカイブREDOログにアーカイブしますが、スタンバイとの類似はそこまでです。遠隔同期インスタンスにはユーザー・データファイルは含まれず、アクセスのために開くことも、REDO Applyを実行することもできず、プライマリ・ロールで機能することも、スタンバイ・データベースの任意のタイプに変換することもできません。
遠隔同期インスタンスはOracle Active Data Guard遠隔同期機能の一部で、Oracle Active Data Guardのライセンスが必要です。
関連項目:
1.1.4 Zero Data Loss Recovery Appliance。
Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)は、すべてのOracleデータベースのバックアップに対して単一のリポジトリを提供するエンタプライズレベルのバックアップ・ソリューションです。
リカバリ・アプライアンスは、ほとんどのOracleデータベースのバックアップおよびリストア処理を一元化されたバックアップ・システムにオフロードします。ストレージ使用率、パフォーマンスおよびバックアップ管理の容易性において著しい効率化を実現できます。
1.1.5 構成の例
図1-1は、REDOデータをスタンバイ・データベースに転送するプライマリ・データベースが含まれる一般的なOracle Data Guard構成を示しています。スタンバイ・データベースは、障害時リカバリ操作とバックアップ操作に備えて、プライマリ・データベースから離れた位置に配置されます。スタンバイ・データベースはプライマリ・データベースと同じ位置にも構成できます。ただし、障害時リカバリに使用する場合は、スタンバイ・データベースを離れた位置に構成することをお薦めします。
1.2 Oracle Data Guardのサービス
Oracle Data Guardでは、REDO転送サービスおよび適用サービスを使用してREDOデータの転送、REDOデータの適用、およびデータベース・ロールの変更が管理されます。
-
本番データベースから1つ以上のアーカイブ先に対するREDOデータの自動転送を制御します。
-
REDOデータは、リアルタイム適用を使用して書き込まれると同時に、スタンバイREDOログ・ファイルから直接適用されます。REDOログ・ファイルが構成されていない場合、REDOデータは適用される前に、最初にスタンバイ・データベースでアーカイブされる必要があります。
-
データベースのロールを、スイッチオーバー操作またはフェイルオーバー操作を使用して、スタンバイ・データベースからプライマリ・データベースに、またはプライマリ・データベースからスタンバイ・データベースに変更します。
1.2.2 適用サービス
適用サービスによって、スタンバイ・データベースにREDOデータを自動的に適用し、プライマリ・データベースとの一貫性を維持します。
REDOデータは、プライマリ・データベースから送信され、スタンバイ・データベース上のスタンバイREDOログに書き込まれます。適用サービスでは、そのデータへの読取り専用アクセスも可能です。
フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの主な相違点は、適用サービスによるアーカイブREDOデータの適用方法にあります。
-
フィジカル・スタンバイ・データベースの場合、Oracle Data GuardではREDO Applyテクノロジを使用します。このテクノロジでは、図1-2に示すように、Oracleデータベースの標準リカバリ技法を使用してREDOデータがスタンバイ・データベースに適用されます。
-
ロジカル・スタンバイ・データベースの場合、Oracle Data GuardではSQL Applyテクノロジを使用します。このテクノロジでは、図1-3に示すように、まず、受信したREDOデータがSQL文に変換されてから、生成されたSQL文がロジカル・スタンバイ・データベース上で実行されます。
1.2.3 ロールの推移
Oracle Data Guardでは、スイッチオーバー操作またはフェイルオーバー操作のいずれかを使用してデータベースのロールを変更できます。
Oracleデータベースは、プライマリ・ロールまたはスタンバイ・ロールのいずれかで実行されます。
スイッチオーバーとは、プライマリ・データベースとそのスタンバイ・データベースの1つとの間でロールを可逆的に推移させる操作です。スイッチオーバーにより、データ消失のない状態が保証されます。この操作は通常、プライマリ・システムの計画的なメンテナンスに対して実行します。スイッチオーバー中は、プライマリ・データベースがスタンバイ・ロールに遷移し、スタンバイ・データベースがプライマリ・ロールに遷移します。
フェイルオーバーは、プライマリ・データベースが使用不可能な場合に発生します。フェイルオーバーは、プライマリ・データベースで障害が発生したときのみに実行され、スタンバイ・データベースをプライマリ・ロールに推移させます。データベース管理者は、データ損失がないようにOracle Data Guardを構成できます。
このマニュアルで説明しているロールの推移は、SQL文を使用して手動で行います。また、「Oracle Data Guard Broker」で説明しているように、Oracle Data Guard Brokerを使用してロールの推移を単純化し、Oracle Enterprise Manager Cloud ControlまたはDGMGRLコマンドライン・インタフェースを使用してフェイルオーバーを自動化することもできます。
1.3 『Oracle Data Guard Broker』
Oracle Data Guard Brokerは、Oracle Data Guard構成の作成、メンテナンス、監視を自動化する分散管理フレームワークです。
Oracle Enterprise Manager Cloud Controlのグラフィカル・ユーザー・インタフェース(GUI)またはOracle Data Guardコマンドライン・インタフェース(DGMGRL)を使用すると、次の操作が自動化および単純化されます。
-
REDO転送サービスや適用サービスの設定など、Oracle Data Guard構成の作成と有効化
-
Oracle Data Guard構成全体を、構成内の任意のシステムから管理
-
Oracle RACのプライマリ・データベースまたはスタンバイ・データベースが含まれるOracle Data Guard構成の管理と監視
-
スイッチオーバーおよびフェイルオーバーを単純化して、Oracle Enterprise Manager Cloud Controlでキー・クリックを1回する、あるいはDGMGRLコマンドライン・インタフェースで単一のコマンドを使用すると起動できるようにします。
-
プライマリ・データベースが使用できなくなった場合に、Oracle Data Guardのファスト・スタート・フェイルオーバーを有効化し、すぐにフェイルオーバーを自動的に行います。ファスト・スタート・フェイルオーバーが有効化されている場合、Oracle Data Guardブローカによってフェイルオーバーの必要性が判断され、指定されたターゲット・スタンバイ・データベースへのフェイルオーバーが自動的に開始されます。DBAによる操作は不要です。
さらに、Oracle Enterprise Manager Cloud Controlを使用すると、次の操作が自動化および単純化されます。
-
プライマリ・データベースのバックアップ・コピーからのフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースの作成
-
ログ適用レートの監視、診断情報の獲得、および集中化したモニタリング・ツール、テスト・ツール、パフォーマンス・ツールなどを使用した問題の早期検出
関連項目:
詳細は、『Oracle Data Guard Broker』を参照してください。
1.3.1 Oracle Enterprise Manager Cloud Controlの使用
Oracle Enterprise Manager Cloud Controlは、Oracle Data Guard構成内のプライマリ・データベースおよびスタンバイ・データベースを表示、監視および管理するための、Webベースのインタフェースを提供します。
Oracle Enterprise Manager Cloud Controlは、単にCloud Controlと呼ばれることもあります。
Enterprise Managerの使いやすいインタフェースに、ブローカによる一元的な管理と、Oracle Data Guard構成の監視を組み合せることで、高可用性、サイト保護、企業のデータ保護に必要なOracle Data Guardソリューションが強化されます。
Enterprise Managerを使用して、すべての管理操作をローカルまたはリモートで実行できます。プライマリ・データベースとスタンバイ・データベース、およびプライマリ・インスタンスとスタンバイ・インスタンスを含む、Oracleデータベースのホーム・ページの表示、既存のスタンバイ・データベースの作成または追加、インスタンスの開始および停止、インスタンスのパフォーマンスの監視、イベントの表示、ジョブのスケジュール、バックアップ操作およびリカバリ操作の実行が可能です。
1.3.2 Oracle Data Guardコマンドライン・インタフェースの使用
Oracle Data Guardコマンドライン・インタフェース(DGMGRL)では、Oracle Data Guard構成をDGMGRLプロンプトまたはスクリプト内から制御および監視できます。
DGMGRLを使用すると、構成でデータベースを管理および監視するために必要なアクティビティのほとんどを実行できます。DGMGRLの詳細な参照情報と例は、『Oracle Data Guard Broker』を参照してください。
1.4 Oracle Data Guardの保護モード
Oracle Data Guardには、データ保護の3種類のモードがあります。
場合によっては、状況に関係なくデータの消失が許されないビジネスがあります。また、起こりそうにない多重障害の場合に起こりうるデータの消失よりデータベースの可用性の方が重要な場合もあります。アプリケーションの中には、常に最大のデータベース・パフォーマンスが必要であるため、コンポーネントに障害が発生した場合に少量のデータの消失ならば許容できるものがあります。これらの各状況で使用可能な保護モードの簡単な説明は、次のとおりです。
最大可用性
この保護モードは、プライマリ・データベースの可用性を低下させない範囲で可能な最高レベルのデータ保護を提供します。Oracle Data Guardを使用して、トランザクションのリカバリに必要なすべてのREDOデータがメモリーに書き込まれるまで、または1つ以上の同期スタンバイ・データベース上のスタンバイREDOログに書き込まれるまで(構成による)、トランザクションはコミットされません。プライマリ・データベースは、REDOストリームを少なくとも1つの同期化されたスタンバイ・データベースに書き込むことができない場合、REDOストリームを同期化されたスタンバイ・データベースに再び書き込めるようになるまで、最大パフォーマンス・モードにあるかのように動作してプライマリ・データベースの可用性を維持します。
この保護モードは、特定の二重障害の場合(スタンバイ・データベースの障害が発生した後にプライマリ・データベースの障害が発生した場合など)を除いて、データ消失がないことを保証します。
最大パフォーマンス
これはデフォルトの保護モードです。プライマリ・データベースのパフォーマンスに影響を与えずに、最大レベルのデータ保護を実現します。これは、トランザクションによって生成されたすべてのREDOデータがオンライン・ログに書き込まれた直後に、そのトランザクションのコミットを可能にすることで実現されます。REDOデータは、1つ以上のスタンバイ・データベースにも書き込まれますが、トランザクション・コミットについて非同期で行われるため、プライマリ・データベースのパフォーマンスは、スタンバイ・データベースへのREDOデータの書込み遅延による影響を受けません。
この保護モードは、最大可用性モードに比べてデータ保護が若干弱く、プライマリ・データベースのパフォーマンスへの影響を最小限に抑えます。
最大保護
この保護モードは、プライマリ・データベースに障害が発生した場合でも、データ消失がないことを保証します。このレベルの保護を提供するには、トランザクションがコミットされる前に、トランザクションのリカバリに必要なREDOデータを、オンラインREDOログおよび少なくとも1つの同期化されたスタンバイ・データベース上のスタンバイREDOログに書き込む必要があります。データの消失が起こり得ないようにするため、1つ以上の同期スタンバイ・データベースにREDOストリームを書き込めない場合、プライマリ・データベースは停止し、トランザクション処理を継続しません。
3つの保護モードはいずれも、特定のREDO転送オプションを使用して、REDOデータが少なくとも1つのスタンバイ・データベースに送信されるようにする必要があります。
関連項目:
-
「Oracle Data Guardの保護モード」にはこのモードの詳細な説明と、プライマリ・データベースの保護モードの設定に関する情報が記載されています。
1.5 クライアント・フェイルオーバー
高可用性アーキテクチャには、データベースおよびデータベース・クライアントに対する高速フェイルオーバー機能が必要です。クライアント・フェイルオーバーには、障害の通知、失効した接続のクリーンアップおよび新しいプライマリ・データベースへの透過的な再接続が含まれます。
Oracle Databaseには、データベース・フェイルオーバーとフェイルオーバー・プロシージャを統合する機能があるため、クライアントは、データベース・フェイルオーバーから数秒以内に新しいプライマリ・データベースに自動的にリダイレクトされます。
関連項目:
-
Oracle Data GuardのFast Application Notification(FAN)およびFast Connection Failover(FCF)に特有な構成要件、ならびにロール特有のデータベース・サービスの詳細は、『Oracle Data Guard Broker』を参照してください。
-
次の場所にアクセスし、Maximum Availability Architectureのクライアント・フェイルオーバーのベスト・プラクティスに関するホワイト・ペーパーを参照してください。
1.5.1 アプリケーション・コンティニュイティ
アプリケーション・コンティニュイティは、データベース・セッションを使用不可にするリカバリ可能なエラーの後に、データベースに対するリクエストを中断せず、迅速な方法でリプレイできるようにするOracle Databaseの機能です。
Oracle Data Guardのフィジカル・スタンバイ・データベースへのスイッチオーバーに対し、アプリケーション・コンティニュイティがサポートされます。また、最大可用性データ保護モードのフィジカル・スタンバイに対するファスト・スタート・フェイルオーバーもサポートされます。アプリケーション・コンティニュイティを使用するには、プライマリ・データベースおよびスタンバイ・データベースにOracle Real Application Clusters (Oracle RAC)またはOracle Active Data Guardのライセンスが必要です。
関連項目:
-
アプリケーション・コンティニュイティの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。
1.6 Oracle Data Guardと補完テクノロジ
Oracle Databaseでは、Oracle Data Guardを補完する複数の固有のテクノロジを提供して、ビジネスに不可欠なシステムが、1つのソリューションのみを利用する場合に比べ、はるかに高い可用性とデータ保護を実現しながら稼働できるようにします。
Oracleの高可用性テクノロジには、次のものがあります。
-
Oracle Real Application Clusters(Oracle RAC)
Oracle RACを使用すると、インターコネクトによってリンクされた複数の独立型サーバーで、Oracleデータベースへのアクセスを共有し、障害の発生時に、高可用性、スケーラビリティおよび冗長性を実現できます。Oracle RACとOracle Data Guardを一緒に使用すると、システムレベル、サイトレベルおよびデータレベルのそれぞれの保護にメリットがあるため、データを消失することなく、高い可用性と障害時リカバリが実現します。
-
Oracle RACは、ノード障害やインスタンス・クラッシュなどの障害から迅速に、自動的にリカバリすることで、システム障害に対処します。アプリケーションに対するスケーラビリティも向上します。
-
Oracle Data Guardでは、トランザクション的に一貫性のある、ディスクを共有しないプライマリ・データベースとスタンバイ・データベースを介して、サイト内の問題やデータ保護に対処し、サイトの障害やデータ破損からリカバリできるようにします。
ローカル・サイトとリモート・サイトの使用、ロジカル・スタンバイ・データベースとフィジカル・スタンバイ・データベースの組合せとノードの使用によって、Oracle RACおよびOracle Data Guardを使用した様々なアーキテクチャを実現できます。Oracle RACとOracle Data Guardの統合については、「Oracle Data GuardおよびOracle Real Application Clusters」、および「Oracle Database高可用性概要」を参照してください。
-
-
Oracle Real Application Clusters One Node(Oracle RAC One Node)
Oracle RAC One Nodeは、強化された高可用性を非クラスタ・データベースに提供し、データベースを計画済停止時間および計画外停止時間の両方から保護します。Oracle RAC One Nodeでは次のことが提供されます。
-
常にオン状態の非クラスタ・データベース・サービス
-
データベース・サーバーの優れた統合
-
強化されたサーバーの仮想化
-
完全Oracle RACの開発およびテスト・プラットフォームのコストの低減
さらに、Oracle RAC One Nodeは、データベース記憶域の統合を容易にし、データベース環境を標準化します。必要に応じて、停止時間や中断を発生させることなく、完全な複数ノードOracle RACデータベースにアップグレードできます。
Oracle Database 11gリリース2(11.2.0.2)では、Oracle Data GuardとOracle Data Guard BrokerがOracle Real Application Clusters One Node (Oracle RAC One Node)と完全に統合されました。
-
-
フラッシュバック・データベース
フラッシュバック・データベース機能により、論理データの破損やユーザー・エラーから迅速にリカバリできます。適切なときにフラッシュバックを許可することで、誤って変更または削除された可能性のある以前のバージョンのビジネス情報に再度アクセスできるようになります。この機能により、次のことが実現します。
-
バックアップをリストアして、エラーや破損が発生した時点までロールフォワード変更を行う必要がなくなります。かわりに、フラッシュバック・データベースでは、データファイルをリストアせずに、以前の時点までOracleデータベースをロールバックできます。
-
REDOの適用を遅延してユーザー・エラーや論理的な破損から保護するための、代替手段を提供します。したがって、スタンバイ・データベースは、プライマリ・データベースとより密接に同期できるため、フェイルオーバーおよびスイッチオーバーの回数が少なくなります。
-
フェイルオーバー後に、元のプライマリ・データベースを完全に作成しなおす必要がなくなります。障害が発生したプライマリ・データベースを、フェイルオーバー前の時点にフラッシュバックして、新しいプライマリ・データベースのスタンバイ・データベースになるように変換できます。
データベースのフラッシュバックの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を、REDOデータの適用の詳細は、「アーカイブREDOログ・ファイルの適用に対する遅延時間の指定」を参照してください。
-
-
Recovery Manager (RMAN)
RMANは、データベース・ファイルのバックアップ、リストアおよびリカバリを単純化するOracleユーティリティです。Oracle Data Guardと同様に、RMANはOracleデータベースの機能の1つであるため、個別にインストールする必要はありません。Oracle Data GuardとRMANは密接に統合されているため、次のことが実現されます。
-
Recovery Managerの
DUPLICATEコマンドを使用して、プライマリ・データベースのバックアップからスタンバイ・データベースを作成できます。 -
本番データベースではなくフィジカル・スタンバイ・データベースからバックアップを取得して、本番データベースの負荷を軽減し、スタンバイ・サイトのシステム・リソースを効率的に使用できます。また、フィジカル・スタンバイ・データベースがREDOを適用しているときに、バックアップを取得することもできます。
-
バックアップの実行後、入力に使用されたアーカイブREDOログ・ファイルを自動的に削除することで、アーカイブREDOログ・ファイルの管理を容易にします。
「Recovery Managerを使用したスタンバイ・データベースの作成」を参照してください。
-
-
Oracle Global Data Services (GDS)
Oracle Global Data Services (GDS) はOracle RACサービス・モデルをグローバル分散データベースのプールに適用して、共通サービスを提供するレプリケートされたデータベースのセットに対し、動的なロード・バランシング、フェイルオーバー、および集中サービス管理を提供します。データベースのセットには、Oracle RACと、Oracle Data Guard、Oracle GoldenGate、またはその他のレプリケーション技術で相互接続された単一インスタンスのOracleデータベースが含まれます。
GDSは、Oracle Data Guard Brokerに統合されています。これにより、ロールの推移がOracle Data Guard Broker構成内で発生すると、必要に応じてロール特有のグローバル・サービスを自動的に開始および停止できます。
GDSにより、グローバル・サービスに対するレプリケーションのラグ制限を指定できます。指定したレプリカでラグ制限が超過した場合、そのレプリカでのグローバル・サービスは一時的に停止し、新しいクライアント・リクエストが、ラグ制限を満たすレプリカにルーティングされます。グローバル・サービスは、レプリケーション・ラグがラグ制限を下回ると、元のレプリカで自動的に再開します。
1.7 Oracle Active Data GuardのOracle Shardingサポート
Oracle Shardingにより、複数の独立したOracle Database間でデータを水平に分割し、データベース接続リクエストを適切なデータを含むデータベースにルーティングできます。Oracle Data GuardとOracle Shardingは統合されたテクノロジです。
シャーディングでは、物理リソースを共有しない複数の独立したデータベース(シャード)にデータを分割します。シャーディングは通常、データ・レプリケーション(Oracle Data Guardによって提供されたものなど)と組み合せられています。Oracle Data Guardでは、Oracle Database全体の迅速な単一マスター・レプリケーションが可能です。Oracle Data Guard構成には、更新可能なプライマリ・データベースと、読取り専用アクセスで開くことのできる1つ以上のスタンバイ・データベースが含まれています。レプリケーションによって、シャードされたデータベースのパフォーマンスと拡張性が向上し、高可用性が実現し、障害回復が可能になります。シャードされたデータベースのレプリケーション・トポロジは、GDSCTL create shardcatalogコマンドで-replオプションを使用して指定されます。デフォルトのレプリケーション・トポロジはOracle Data Guardです。
Oracle Shardingでは、システム管理および複合の2つのシャーディング方法をサポートしています。シャーディング方法は、GDSCTLコマンドCREATE SHARDCATALOGで指定されます。
シャードグループに属するシャードは通常、同じデータ・センターにあります。シャードグループ全体を、同じまたは異なるデータ・センターの1つ以上のシャードグループに完全にレプリケートできます。
Oracle Data Guardレプリケーションによるシステム管理シャーディング
システム管理シャーディングでは、レプリケーションの論理単位は、シャードグループと呼ばれるシャードのグループです。システム管理シャーディングでは、シャードグループに、シャードされたデータベースに格納されているすべてのデータが含まれます。データは、コンシステント・ハッシュによるパーティション化を使用してシャード間に自動的に分散されます(コンシステント・ハッシュは、スケーラブルな分散システムで一般的に使用されるパーティション化方法です)。パーティション化アルゴリズムにより、データがシャード間に均一およびランダムに分散されます。次の図は、システム管理シャーディングとともにOracle Data Guardレプリケーションが使用される方法を示しています。プライマリ・シャードグループ(シャードグループ1)と2つのスタンバイ・シャードグループ(シャードグループ2とシャードグループ3)があります。
シャードグループ1はOracle Data Guardプライマリ・データベース(シャード1、2、3)で構成されます。シャードグループ2は、同じデータセンターにあり同期レプリケーションを行うように構成されたスタンドバイ・データベース(シャード4、5、6)で構成されます。また、シャードグループ3は、別のデータセンターにあり非同期レプリケーションを行うように構成されたリモート・スタンドバイ(シャード7、8、9)で構成されます。デフォルトのレプリケーション・トポロジはOracle Data Guardです。構成内の各スタンバイを読取り専用モードでオープンするには、Oracle Active Data Guardを有効化する必要があります。これは、GDSCTL add shardgroupコマンドで-deploy_as ACTIVE_STANDBYオプションを使用して実行されます。
前の図に示されたシャードされたデータベースは、レプリケートされた3つのシャードのセット({1, 4, 7}、{2, 5, 8}および{3, 6, 9})で構成されます。レプリケートされた各シャードのセットは、ファスト・スタート・フェイルオーバーが有効なOracle Data Guard Broker構成として管理されます。
レプリケーションをデプロイするには、シャードグループのプロパティ(リージョン、ロールなど)を指定して、シャードを追加するだけで済みます。Oracle Shardingは自動的にOracle Data Guardを構成し、レプリケートされたシャードのセットごとにファスト・スタート・フェイルオーバー・オブザーバを起動します。また、読取り専用ワークロードのロード・バランシング、ロールベースのグローバル・サービスおよびレプリケーション・ラグとローカリティベースのルーティングを提供します。
前の図に示す構成をデプロイするには、次のGDSCTLコマンドを実行します。
CREATE SHARDCATALOG –database host00:1521:shardcat –region dc1, dc2
ADD GSM -gsm gsm1 -listener 1571 –catalog host00:1521:shardcat –region dc1
ADD GSM -gsm gsm2 -listener 1571 –catalog host00:1521:shardcat –region dc2
ADD SHARDGROUP -shardgroup shardgroup1 -region dc1 -deploy_as primary
ADD SHARDGROUP -shardgroup shardgroup2 -region dc1 -deploy_as standby
ADD SHARDGROUP -shardgroup shardgroup3 -region dc2 -deploy_as standby
CREATE SHARD -shardgroup shardgroup1 -destination host01 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp
CREATE SHARD -shardgroup shardgroup1 -destination host02 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp
CREATE SHARD -shardgroup shardgroup1 -destination host03 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp
……
CREATE SHARD -shardgroup shardgroup3 -destination host09 -credential oracle_cred -netparamfile /home/oracle/netca_dbhome.rsp
DEPLOY
複合シャーディングとOracle Data Guardレプリケーション
複合シャーディングでは、システム管理シャーディングの機能とユーザー定義シャーディングの機能が組み合されています。複合シャーディングでは、レプリケーションの論理単位は、(システム管理シャーディングと同様に)シャードグループと呼ばれるシャードのグループです。また、複合シャーディングでは、シャードされたデータベースは複数のシャードスペースで構成されますが(システム管理シャーディングと同様に)、各シャードスペース(レプリケートされたシャードではなく)には次の図に示すようにレプリケートされたシャードグループが含まれます。
前の図に示す構成をデプロイするには、次のGDSCTLコマンドを実行します。
CREATE SHARDCATALOG -sharding composite –database host00:1521:cat –region dc1, dc2, dc3
ADD GSM -gsm gsm1 -listener 1571 –catalog host00:1521:cat –region dc1
ADD GSM -gsm gsm2 -listener 1571 –catalog host00:1521:cat –region dc2
ADD GSM -gsm gsm3 -listener 1571 –catalog host00:1521:cat –region dc3
ADD SHARDSPACE -shardspace shardspace_a
ADD SHARDSPACE -shardspace shardspace_b
ADD SHARDGROUP -shardgroup shardgroup_a1 –shardspace shardspace_a -region dc1
-deploy_as primary
ADD SHARDGROUP -shardgroup shardgroup_a2 –shardspace shardspace_a -region dc1 -deploy_as standby
ADD SHARDGROUP -shardgroup shardgroup_a3 –shardspace shardspace_a -region dc3 -deploy_as standby
ADD SHARDGROUP -shardgroup shardgroup_b1 –shardspace shardspace_a -region dc1
-deploy_as primary
ADD SHARDGROUP -shardgroup shardgroup_b2 –shardspace shardspace_a -region dc1 -deploy_as standby
ADD SHARDGROUP -shardgroup shardgroup_b3 –shardspace shardspace_a -region dc2 -deploy_as standby
CREATE SHARD -shardgroup shardgroup_a1 -destination host01 –credential orcl_cred -netparamfile /home/oracle/netca_dbhome.rsp
……
CREATE SHARD -shardgroup shardgroup_b3 -destination host09 -credential orcl_cred -netparamfile /home/oracle/netca_dbhome.rsp
DEPLOY
1.8 Oracle Data Guardのメリットの要約
Oracle Data Guardは、効率のよい包括的な障害時リカバリおよび高可用性ソリューションを提供します。
Oracle Data Guardには次のようなメリットがあります。
-
高可用性
管理が容易なOracle Data Guardスイッチオーバー機能とフェイルオーバー機能を使用すると、プライマリ・データベースとスタンバイ・データベース間でロールを可逆的に推移できるため、計画的および計画外の停止によるプライマリ・データベースの停止時間が最小限になります。
-
完全なデータ保護
Oracle Data Guardでは、予期しない障害が発生した場合でもデータ消失がないことを保証します。スタンバイ・データベースにより、データ破損や管理エラーを含む、あらゆる種類の計画外停止を防ぎます。プライマリ・データベースから受信したREDOデータはスタンバイ・データベースで検証されるため、プライマリ・データベースで発生する可能性のある物理破損は、スタンバイ・データベースに伝播しません。スタンバイ・データベースで実行される追加の検証も、論理ブロック内破損や書込みの欠落がスタンバイに伝播するのを防ぎます。同様に、記憶域管理者による偶然のファイル削除などの管理エラーも、スタンバイ・データベースに伝播しません。フィジカル・スタンバイ・データベースを使用して、Redo Applyの遅延、またはスタンバイを巻き戻してデータの正しいコピーを抽出するためのフラッシュバック・データベースの使用によるユーザー・エラーを防ぐこともできます。
-
システム・リソースの効率的な使用
プライマリ・データベースから受信したREDOデータで更新されたスタンバイ・データベース表は、バックアップ、レポート生成、要約および問合せなどの他のタスクにも使用できます。したがって、これらのタスクの実行に必要なプライマリ・データベースのワークロードを低減し、貴重なCPUとI/Oのサイクルを節約できます。
-
可用性とパフォーマンス要件とのバランスを保つことができるデータ保護の柔軟性
Oracle Data Guardには、各企業がデータ可用性とシステム・パフォーマンス要件とのバランスを保つことができるように、最大保護、最大可用性および最大パフォーマンスの3つのモードが用意されています。
-
自動ギャップ検出および解決
ネットワークの問題などで、プライマリ・データベースと1つ以上のスタンバイ・データベースとの間の接続が失われた場合、プライマリ・データベース上に生成されるREDOデータは、宛先のスタンバイ・データベースに送信できません。接続が再度確立された後、Oracle Data Guardによって、欠落しているアーカイブREDOログ・ファイル(ギャップと呼ばれます)が自動的に検出され、それらのファイルがスタンバイ・データベースに自動的に転送されます。スタンバイ・データベースはプライマリ・データベースと同期化されるため、DBAによる手動操作は不要です。
-
集中化された単純な管理
Oracle Data Guard Brokerにはグラフィカル・ユーザー・インタフェースとコマンドライン・インタフェースがあり、Oracle Data Guard構成の複数のデータベースにまたがる管理タスクや運用タスクが自動化されます。また、ブローカは、単一のOracle Data Guard構成内のすべてのシステムを監視します。
-
Oracle Databaseとの統合
Oracle Data GuardではOracle Database Enterprise Editionの機能の1つであるため、個別にインストールする必要はありません。
-
自動的なロールの推移
ファスト・スタート・フェイルオーバーが有効になると、プライマリ・サイトで障害が発生した場合、Oracle Data Guard Brokerにより、DBAによる操作の必要なしに同期化されたスタンバイ・サイトにフェイルオーバーされます。また、アプリケーションにロールの推移が自動的に通知されます。