| Oracle Database高可用性ベスト・プラクティス 11gリリース1（11.1） B54839-01 |
|
 戻る |
 次へ |
スイッチオーバーやフェイルオーバー後にすべてのスタンバイ・データベースが適切に動作し、必要なサービス・レベルの範囲内でそのロールを実行するには、Oracle Data GuardのREDO ApplyおよびSQL Applyの適切な構成が不可欠です。
Oracle Data Guardのベスト・プラクティスは、2.2項「Oracle Database 11gの構成」に説明されているベスト・プラクティスを基盤としています。Oracle Data Guardの大部分の設定は、Oracle Enterprise Managerおよびブローカを使用して構成できます。使用頻度の低い高度な構成パラメータを設定するには、DGMGRLのコマンドライン・インタフェースまたはSQL*Plus文を使用できます。
Oracle Data Guardでは、フィジカル・スタンバイ・データベース（REDO Apply）、スナップショット・スタンバイ・データベース、Active Data Guardオプション（リアルタイム問合せ）、ロジカル・スタンバイ・データベース（SQL Apply）、リアルタイム適用のいずれか、またはこれらの組合せを使用できます。
フィジカル・スタンバイ・データベースでは、プライマリ・データベースと物理的に同一のコピーが提供されます。フィジカル・スタンバイ・データベースのディスク上のデータベース構造は、ブロック単位でプライマリ・データベースと同じです。索引などのデータベース・スキーマも同じです。フィジカル・スタンバイ・データベースとプライマリ・データベースとの同期は、メディア・リカバリを通じてプライマリ・データベースから取得されたREDOデータを適用することで維持されます。さらに、フィジカル・スタンバイ・データベースには次の特長があります。
Oracle Active Data Guardオプションのライセンスを購入すると、REDO Applyをアクティブにしたまま読取り専用アクセスでオープンできます（リアルタイム問合せ）。
スナップショット・スタンバイ・データベースに変換してデータベースのテストまたはクローニングで使用し、後で逆方向に変換してフィジカル・スタンバイ・データベース・ロールで実行することができます。
一時的に一時ロジカル・スタンバイ・データベースに変換し、最低限の停止時間でローリング・アップグレードを実行できます。
ロジカル・スタンバイ・データベースには、プライマリ・データベースと同じ論理情報が含まれますが、データの物理的な編成と構造は異なる場合があります。SQL Applyはロジカル・スタンバイ・データベースをプライマリ・データベースと同期した状態に維持し、プライマリ・データベースから受信したREDOデータをSQL文に変換してスタンバイ・データベース上で実行することによって保持します。ロジカル・スタンバイ・データベースは、障害時のリカバリ要件を満たす以外に、他のビジネス目的にも使用できます。
|
関連項目:
|
この項では、ビジネス要件に最適のソリューションを判別できるように、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの相違について説明します。
フィジカル・スタンバイ・データベースを使用するのは次の場合です。
フィジカル・レプリカの簡潔性と信頼性が必要な場合
プライマリ・データベースのREDO生成率が非常に高い場合
破損に対する最高水準の保護が必要とされる場合
読取り専用でオープンされた最新のスタンバイ・データベースが、スタンバイ・ロールで動作している間も、スタンバイ・データベースの計画済の使用に対処できる場合（Oracle Active Data Guardオプションのライセンスが必要です）。
スタンバイ・データベースに高速増分バックアップの負荷を軽減する場合（Oracle Active Data Guardオプションのライセンスが必要です）。
スナップショット・スタンバイ・データベースを、品質保証テストなど、読み書き可能でオープンされたデータベースを必要とする用途で使用する場合
一時ロジカル・スタンバイ・データベースを使用してローリング・データベース・アップグレードを実行する場合
ロジカル・スタンバイ・データベースを使用するのは次の場合です。
スタンバイ・データベースへの読み書き可能アクセスを必要とするレポート・アプリケーションを実行する場合
注意: ロジカル・スタンバイ・データベースが維持しているデータを変更することはできません。
プライマリ・データベースに存在しないスタンバイ・データベースに表、追加スキーマ、索引およびマテリアライズド・ビューを追加する場合
現在Oracle Database 10gのリリースを実行しているデータベースからのローリング・データベース・アップグレードを実行する場合
注意: データベースがOracle Database 11gをすでに実行している場合は、フィジカル・スタンバイ・データベースと一時ロジカル・スタンバイ・データベースによるローリング・アップグレード・プロセスを使用します。
また、前の要件のいずれかに加えて、次の特性のいずれかがある場合は、ロジカル・スタンバイ・データベースを使用します。
ビジネスには、絶対にデータを失うことのできない状況があります。別の状況では、データの保護よりデータベースの可用性の方が重要になります。一部のアプリケーションでは、最大限のデータベース・パフォーマンスが必要とされ、障害が発生した場合のデータ損失の可能性は許容されます。
現状のビジネス要件に基づいて、次の保護モードのいずれかを選択します。
最大保護モード: このモードでは、プライマリ・データベースに障害が発生しても、データ損失は起こらないことが保証されます。データ損失を確実に防ぐため、障害により1つ以上のスタンバイ・データベースにREDOストリームを書き込むことができない場合、プライマリ・データベースは停止されます。
最大可用性モード: このモードでは、プライマリ・データベースの可用性に影響を与えない範囲で最高レベルのデータ保護が提供されます。
最大パフォーマンス・モード（デフォルト・モード）: このモードでは、プライマリ・データベースのパフォーマンスに影響を与えない範囲で最高レベルのデータ保護が提供されます。このモードでは、トランザクションのリカバリに必要なREDOデータがローカルのオンラインREDOログに書き込まれると、即座にそのトランザクションのコミットが許可されます。
プライマリ・データベースのREDOデータ・ストリームは、1つ以上のスタンバイ・データベースにも書き込まれますが、REDOデータを生成するトランザクションのコミットとは同期せずに書き込まれます。十分な帯域幅のあるネットワーク・リンクを使用している場合、このモードでは、プライマリ・データベースのパフォーマンスに対する影響を最小限に抑えながら、最大可用性モードに匹敵するデータ保護レベルを得ることができます。
|
関連項目: 『Oracle Data Guard概要および管理』 |
現在のアプリケーションに適したデータ保護モードを決定するには、次の手順を実行します。
表2-2で、必要なビジネス要件とデータ損失シナリオを比較します。
アプリケーション・スループットに対する待機時間の影響を検討します。
最大保護モードまたは最大可用性モードを使用する場合、アプリケーション・スループットに対して待機時間がどの程度の影響を及ぼすか検討します。サイト間の距離およびネットワーク・インフラストラクチャによってネットワークの待機時間が確定するため、使用可能な保護モードも決定します。一般的に、距離とともに待機時間は増加し、帯域幅は低下します。
待機時間が短く、帯域幅が大きいネットワークでは、最大保護モードまたは最大可用性保護モードを使用します。
この場合、パフォーマンスへの影響は最小限で、ゼロ・データ損失を実現できます。
待機時間が長いネットワークでは、ASYNC転送で最大パフォーマンス・モードを使用します。
この場合、プライマリ・データベースのパフォーマンスへの影響は最小限で、通常、データ損失を秒単位に制限できます。SYNC転送で最大可用性モードや最大保護モードを使用することも可能ですが、COMMITによる追加の待機時間がアプリケーション・パフォーマンス要件を超えることがないかどうかを評価する必要があります。状況によっては、レスポンス時間またはスループットのオーバーヘッドがまったくないか、許容範囲内に収まります。待機時間が長いネットワークでもSYNCによる最大可用性モードを使用できる例として、大規模なバッチ・アプリケーションやメッセージ・キューイング・アプリケーションなどがあげられます。
帯域幅は、最大のREDO生成速度を超えている必要があります。双方向通信のガイドラインは、帯域幅の場合規定のネットワーク容量の50%ですが、他のアプリケーションによるネットワークの使用も考慮する必要があります。ASYNC REDO転送を使用した最大パフォーマンス・モードにより、パフォーマンスへの影響を緩和できます。
次のいずれかの目的がある場合は、スタンバイ・データベースを複数デプロイすることをお薦めします。
フェイルオーバー後に継続保護を提供する場合
複数スタンバイ構成で、ロール移行のターゲットでないスタンバイ・データベース（バイスタンダ・スタンバイ・データベース）は、新しいプライマリ・データベースから受信したREDOデータを自動適用します。
同期通信限界を超える広範囲の地理的災害に対する保護も提供しつつ、データ損失ゼロの保護を実現する場合
たとえば、同期的にREDOデータを受信するスタンバイ・データベースがプライマリから200マイル遠方、非同期でREDOデータを受信する2番目のスタンバイ・データベースが1,500マイル遠方に位置する場合です。
ローリング・アップグレード・プロセスによって障害保護を維持しつつ、ローリング・データベース・アップグレードを実行する場合
障害時リカバリ保護を維持しつつ、テストなどの非定型作業を実行する場合
必要に応じて複数のスタンバイ・データベースをそのような目的に使用する場合も、プライマリ・フェイルオーバー・ターゲットの役割を果すスタンバイ・データベースを1つ以上確保しておきます。
|
関連項目:
|
Data Guardには、次の構成ベスト・プラクティスを使用します。
|
関連項目: SPFILEのサンプルやOracle Net構成ファイルを含む初期化パラメータ設定の詳細な例は、付録A「データベースSPFILEおよびOracle Net構成ファイルのサンプル」を参照してください。 |
Recovery Manager（RMAN）ユーティリティを使用して、フィジカル・スタンバイ・データベースの作成プロセスを簡略化することをお薦めします。
スタンバイ・データベースは、プライマリ・データベースのバックアップから作成することも、ネットワーク経由で作成することもできます。
プライマリ・データベースのバックアップからスタンバイ・データベースを作成するには、RMANのDUPLICATE TARGET DATABASE FOR STANDBYコマンドを使用します。
スタンバイ・ホスト上のサーバー・セッションから、データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルにアクセスできる場合、プライマリ・データベースの任意のバックアップ・コピーを使用してフィジカル・スタンバイ・データベースを作成できます。SET UNTILコマンドを実行する場合を除いて、RMANは最も日付の近いデータファイルをリストアします。
既存のデータベース・バックアップがスタンバイ・システムにアクセスできない場合は、RMANのFROM ACTIVE DATABASEオプションを使用して、ネットワーク経由でスタンバイ・データベースを作成します。
RMANは、プライマリ・データベースからスタンバイ・データベースへ直接データファイルをコピーします。プライマリ・データベースはマウントまたはオープンされている必要があります。
アクティブ複製とバックアップ・ベース複製のいずれかを選択する必要があります。FROM ACTIVE DATABASEオプションを指定しなかった場合、RMANはバックアップ・ベースの複製を実行します。ネットワーク経由でのスタンバイ・データベース作成には、次の利点があります。
あらかじめプライマリ・データベース上でバックアップを実行する手順を完了する必要なく、ネットワーク経由で直接、REDOデータをリモート・ホストから転送することができます（リストアには、プライマリ・データベースへのバックアップのローカル保存、ネットワーク経由でのバックアップの転送、スタンバイ・データベースへのバックアップのローカル保存、およびスタンバイ・データベース上でのバックアップのリストアなど、複数の手順が必要です）。
アクティブ複製では、ASMから実行中のデータベースをバックアップし、そのバックアップをネットワーク経由でホストにリストアし、ASMに直接ファイルを配置することができます。
この機能以前のリストアでは、プライマリをバックアップしてそのバックアップ・ファイルをプライマリ・ホスト・ファイル・システムにコピーし、そのバックアップ・ファイルをネットワーク経由で転送し、バックアップ・ファイルをスタンバイ・ホスト・ファイル・システムに配置してから、ASMにファイルをリストアする手順が必要でした。
|
関連項目:
|
プライマリ・データベースとスタンバイ・データベースの両方でフラッシュバック・データベースを有効化すると、元のプライマリ・データベースが損害を受けていなかった場合に、フェイルオーバー後に元のプライマリ・データベースを新しいスタンバイ・データベースとして復元できます。フラッシュバック・データベースが有効であれば、スイッチオーバー・プロセスで障害が発生した場合でも、そのプロセスを簡単に元に戻すことができます。
プライマリ・データベースをFORCE LOGGINGモードで運用すると、データベースのすべてのデータ変更がログに記録されます。FORCE LOGGINGモードにより、スタンバイ・データベースとプライマリ・データベースとの一貫性が維持されます。NOLOGGING操作によるロード・パフォーマンスが必要なためにこの設定を使用できない場合は、対応するフィジカル・スタンバイ・データファイルを後で確実に同期する必要があります。フィジカル・スタンバイ・データファイルを同期するには、プライマリ・データベースから作成された増分バックアップを適用するか、NOLOGGING操作後に取得されたプライマリ・データファイルのバックアップを使用して関連するスタンバイ・データファイルを置き換えます。ファイル転送の前に、フィジカル・スタンバイ・データベースでREDO Applyを停止する必要があります。
ロジカル・スタンバイ・データベースでは、SQL Applyの処理中にNOLOGGING句付きで実行された操作のREDOレコードが出現すると、そのレコードはスキップされて、それ以降のレコードから変更が適用されます。後で、NOLOGGINGが有効な状態で更新されたレコードに対するアクセスが発生すると、「ORA-01403: データが見つかりません。」というエラーが戻されます。NOLOGGING句の指定後にロジカル・スタンバイ・データベースでリカバリを行うには、『Oracle Data Guard概要および管理』のロジカル・スタンバイ・データベースでの表の追加または再作成に関する項の説明に従って、プライマリ・データベースから1つ以上の表を再作成します。
ALTER DATABASE FORCE LOGGING文を発行すると、強制ロギングを即座に有効化できます。FORCE LOGGINGを指定した場合、Oracleは、ログに記録されていない進行中のすべての操作が終了するまで待機します。
|
関連項目:
|
Data Guard構成の作成、管理および監視には、ブローカを使用します。ブローカを使用するメリットは、次のとおりです。
Oracle RACとの統合
ブローカは、データベースのロール変更がスムーズかつシームレスに発生するようにCluster Ready Services（CRS）脚注9と統合されています。このことは、計画的なロール・スイッチオーバーを実行する際に特に有利です（たとえば、フィジカル・スタンバイ・データベースにプライマリ・ロールを引き継がせ、元のプライマリ・データベースにスタンバイ・ロールを割り当てる場合です）。ブローカとCRSは、連携してプライマリ・データベースのサービス可用性を一時的に停止し、両方のデータベースの実際のロールを変更します。その間に、CRSはブローカとともに必要に応じて適切なインスタンスを再起動し、新しいプライマリ・データベースでサービス可用性を再開します。ブローカは基礎となるData Guard構成とそのデータベース・ロールを管理し、CRSはそれらのロールに依存するサービス可用性を管理します。サービス可用性の管理をCRSに依存するアプリケーションでは、Data Guard構成でロール変更が発生したときに一時的にサービスの停止を認識するだけです。
Data Guard構成の自動作成
Oracle Enterprise Managerには、次のようなブローカ構成の作成に伴う複雑なタスクを自動化するウィザードが付属しています。
既存のスタンバイ・データベースの追加、またはEnterprise Managerを通じて取得された既存のバックアップからの新規スタンバイ・データベースの作成
スタンバイ制御ファイル、サーバー・パラメータ・ファイルおよびデータファイルの構成
スタンバイ・データベースとの通信の初期化
スタンバイREDOログ・ファイルの作成
フラッシュバック・データベースの有効化（ファスト・スタート・フェイルオーバーを使用する場合）
Data Guardコマンドライン・インタフェース（DGMGRL）では、スタンバイ・データベースを自動的に作成できませんが、DGMGRLコマンドを使用して既存のスタンバイ・データベース（Enterprise Managerを使用して作成されたデータベースを含む）を構成および監視できます。
スイッチオーバー操作とフェイルオーバー操作の簡略化
ブローカでは、Oracle Enterprise Managerのボタン・クリック1つ、またはDGMGRLコマンドライン・インタフェースの単一のコマンドを使用して、簡単にスイッチオーバーまたはフェイルオーバーを起動できます（このマニュアルでは、DGMGRLを使用する方法を、手動フェイルオーバーと呼びます）。完全自動管理の場合、ファスト・スタート・フェイルオーバーを有効化してブローカにフェイルオーバーが必要であるかどうかの判断を任せ、事前に指定したターゲット・スタンバイ・データベースに対するフェイルオーバーを自動的に起動できます。この場合、DBAによる手動操作は必要なく、データ損失もほとんど、またはまったく発生しません。
ファスト・スタート・フェイルオーバーを使用すると、手動操作を極力使用せずに可用性を向上し、管理コストを削減できます。手動フェイルオーバーでは、フェイルオーバーの発生時期とターゲット・スタンバイ・データベースを正確に制御できます。どちらの方法を選択しても、ブローカにより、構成内のすべてのデータベースのロール移行が調整されます。
ブローカは、フェイルオーバー後に、FAN/AQ（アドバンスト・キューイング）通知を自動的に発行します。高速接続フェイルオーバーも構成されている、適切構成のクライアントは、その通知を使用して、新しいプライマリ・データベースに接続してアプリケーション処理を再開することができます。
組込みの監視、アラートおよび制御メカニズム
ブローカには、構成内のすべてのデータベース状態を監視する組込みの検証機能があります。任意のデータベースに接続された構成内のシステムから診断情報を取得し、監視、テストおよびパフォーマンス用の一元管理されたツールで大小様々な問題を迅速に検出できます。Enterprise ManagerとDGMGRLの両方で、プライマリ・データベースにおけるREDO転送サービスの進行状況と、スタンバイ・データベースにおけるREDO ApplyまたはSQL Applyの進行状況の詳細な構成ビューを取得できます。
ローカルおよびリモートのデータベースを監視してイベントに応答する機能は、ブローカのヘルス・チェック・メカニズムと、Enterprise Managerイベント管理システムとData Guard Brokerの緊密な統合により大幅に拡張されています。
各データベースでは、フラッシュ・リカバリ領域を使用していること。
プライマリ・データベース・インスタンスは、リモートのただ1つの適用インスタンスにアーカイブされること。
表2-3に、SQL*Plusを通じてData Guard構成を管理する際の堅牢なアーカイブ計画の推奨事項を示します。ブローカで構成を管理する場合、次のすべての項目が自動的に処理されます。
表2-3 アーカイブの推奨事項
次に、フィジカル・スタンバイ・データベースと通信するプライマリ・データベースに推奨される初期化パラメータを示します。最大保護モードで稼働するSALES1およびSALES2という2つのインスタンスがあります。
*.DB_RECOVERY_FILE_DEST=+RECO
*.LOG_ARCHIVE_DEST_1='SERVICE=SALES_stby SYNC AFFIRM NET_TIMEOUT=30
REOPEN=300 VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME=SALES_stby'
*.LOG_ARCHIVE_DEST_STATE_1=ENABLE
フラッシュ・リカバリ領域は、クラスタ内の任意のノードからアクセス可能である必要があります。また、フラッシュ・リカバリ領域では、自動ストレージ管理（ASM）、クラスタ・ファイル・システム、グローバル・ファイル・システム、高可用性ネットワーク・ファイル・システム（HA NFS）などの共有ファイル・システム・テクノロジを使用する必要があります。クラスタ内の任意のノードに手動でファイル・システムをマウントすることも簡単にできます。すべてのアーカイブREDOログ・ファイルにすべてのノードからアクセスできる必要があるため、これはリカバリにとって必須の設定です。
スタンバイ・データベース・ノードでは、REDOを適用しているノードに障害が発生して適用サービスを再起動できない場合、異なるノードからリカバリを実行する必要があります。この場合、異なるノードに存在する既存のスタンバイ・インスタンスのいずれかを使用して、管理リカバリを開始できます。スタンバイ・アーカイブREDOログ・ファイルにアクセスできない場合は、異なるノードの新規管理リカバリ・プロセス（MRP）またはロジカル・スタンバイ・プロセス（LSP）により、プライマリ・ノードからの直接取得を行うFALサーバーを通じてアーカイブREDOログ・ファイルがフェッチされます。
ハードウェア・ベンダーの共有ファイル・システム・テクノロジを構成する場合は、パフォーマンスと可用性に対する影響を確認してください。この計画を採用する前に、次の項目を調査します。
ノード障害の数にかかわらず、任意のノードから共有ファイル・システムにアクセスできますか。
共有ファイル・システムを実装することによるパフォーマンスへの影響はどの程度ですか。
インターコネクト・トラフィックに対する影響はありませんか。
スタンバイREDOログは、可用性とパフォーマンスを向上するために両方のサイトで構成する必要があります。スタンバイREDOログに推奨される数を決定するには、次の式を使用します。
(ログ・ファイル・グループの最大数 + 1) * スレッドの最大数
たとえば、プライマリ・データベースに2つのインスタンス（スレッド）があり、スレッドごとに2つのオンライン・ログ・グループがある場合、必要なスタンバイREDOログの数は6になります（(2 + 1) * 2 = 6）。各スレッドに対してスタンバイ・ログ・グループの数を1つ多くしておくと（つまり、プライマリ・データベースのオンラインREDOログ・グループの数より1つ多くすると）、1つのスタンバイREDOログがスタンバイ・データベースに割り当てられないため、プライマリ・インスタンスのログ・ライター・プロセスがブロックされる可能性を減らすことができます。
次の文では、グループごとに2つのスタンバイ・ログ・メンバーを作成します（各メンバーは10MB）。1つのメンバーはDB_CREATE_FILE_DEST初期化パラメータで指定されたディレクトリに作成され、もう1つのメンバーはDB_RECOVERY_FILE_DEST初期化パラメータで指定されたディレクトリに作成されます。この例では、2つのスレッドに2つのオンラインREDOログ・グループがあると仮定しているため、次のグループはグループ5です。
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 5 SIZE 10M, GROUP 6 SIZE 10M, GROUP 7 SIZE 10M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 8 SIZE 10M, GROUP 9 SIZE 10M, GROUP 10 SIZE 10M;
スタンバイREDOログを作成する際には、次の追加のガイドラインを考慮してください。
プライマリ・データベース上とスタンバイ・データベース上に、同じ数のスタンバイREDOログを作成します。
プライマリ・データベースとスタンバイ・データベースの両方で、すべてのオンラインREDOログとスタンバイREDOログのサイズが同じになるように作成します。
スタンバイREDOログは、ASMまたは外部冗長性を通じて保護されたデータ領域に作成します。
Oracle RAC環境では、スタンバイREDOログは共有ディスクに作成します。
Oracle RAC環境では、スタンバイREDOログの作成時にそのスタンバイREDOログをスレッドに割り当てます。前述の例では、各スレッドに3つのスタンバイREDOログを割り当てます。
スタンバイREDOログは多重化しないでください。
REDOログの数およびグループ番号を確認するには、次のようにV$LOGビューを問い合せます。
SQL> SELECT * FROM V$LOG;
ALTER DATABASE ADD STANDBY LOGFILE THREAD文の結果を確認するには、次のようにV$STANDBY_LOGビューを問い合せます。
SQL> SELECT * FROM V$STANDBY_LOG;
次のようにV$LOGFILEビューを問い合せて、作成されたメンバーを表示することもできます。
SQL> SELECT * FROM V$LOGFILE;
|
関連項目: 『Oracle Data Guard概要および管理』のREDOデータを受信するためのOracleデータベースの構成に関する項 |
この項では、Data GuardのREDO転送サービスを計画および実装するためのベスト・プラクティスについて説明します。
ネットワーク構成案と現在（または将来）のピークREDO速度に関するパフォーマンス評価を実行することをお薦めします。プライマリ・データベースとスタンバイ・データベース間のネットワークに対する影響と、プライマリ・データベースのスループットに対する影響を把握する必要があります。プライマリ・データベースとスタンバイ・データベース間のネットワークは2つのデータベースの同期を維持するのに不可欠の要素であるため、そのインフラストラクチャは次の特徴を有している必要があります。
最大のREDO生成速度に対応できる十分な帯域幅
SYNC転送を使用する場合、プライマリ・データベースのパフォーマンスへの影響を減らすために、待機時間が最小限であること
ネットワーク冗長性のための複数のネットワーク・パス
専用のネットワーク接続を使用する構成では、必要な帯域幅は、プライマリ・データベースの最大REDO速度とネットワーク効率により決定されます。データ保護モードによっては、他の推奨プラクティスとパフォーマンス上の考慮事項があります。最大保護モードと最大可用性モードでは、SYNC転送を使用する必要があります。最大パフォーマンス保護モードでは、ASYNC転送オプションを使用します。
ASYNC転送モードと異なり、SYNC転送モードでは、発生するネットワーク待機時間のために、プライマリ・データベースのパフォーマンスに影響が出る可能性があります。距離とネットワーク構成は、待機時間に直接影響します。待機時間が長いと、潜在的なトランザクション・スループットが低下し、レスポンス時間が迅速化する可能性があります。ネットワーク構成、リピータの数、プロトコル変換のオーバーヘッド、およびルーターの数も、ネットワーク待機時間とトランザクション・レスポンス時間に全体的な影響を与えます。
次の各項では、プライマリ・データベース・スループットへのSYNC転送モードとASYNC転送モードの影響、およびLOG_ARCHIVE_MAX_PROCESSESパラメータの設定について説明します。
プライマリ・データベースとスタンバイ・データベース間の高度な同期化を実現するには、SYNC REDO転送を構成します。SYNC属性を使用してスタンバイ・データベースにREDOデータを送信する場合、プライマリ・データベースのトランザクションは、そのトランザクションに関連するREDOがローカルとリモートの両方に書き込まれるまでフォアグラウンド・プロセスにコミット完了メッセージを戻しません。
SYNC使用時のコミット時間は、スタンバイ・データベースのI/O容量以外に、ネットワークの待機時間と帯域幅に直接的な影響を受けます。合計コミット時間は、プライマリ・データベースのローカル書込み（ログ・ファイル・パラレル書込み）時間と、SENDREQでのLNS待機イベントによる所要時間（ネットワーク時間 + スタンバイ書込み（スタンバイ・データベースのV$SYSTEM_EVENTビューから取得されるRFS書込みI/O） + ネットワーク確認応答）で構成されます。
SYNC転送のプライマリ・データベースへの影響: プライマリ・データベースへの影響は、アプリケーション・プロファイルにより異なります。一般的に、不定期のコミットを伴うバッチ更新と、メッセージ・キューイング・アプリケーションでは、目立った違いはありません。
プライマリ・データベースへの影響を最小限に抑えるためには、ASYNC REDO転送を構成します。ただし同期化の程度は低くなります。ASYNC属性を使用してスタンバイ・データベースにREDOデータを送信する場合、プライマリ・データベース上のトランザクションは、リクエストを完了するためにネットワークI/Oを待機することなく、継続して処理されます。
ネットワーク待機時間が増加しても、プライマリ・データベースのスループット（1秒当たりのREDOバイト）にはほとんど影響がありません。ログ・ライター・プロセスがローカルのオンラインREDOログ・ファイルに書込みを行う一方で、（宛先ごとに1つ存在する）ネットワーク・サーバー・プロセスがログ・バッファからREDOを読み取り、それをリモート宛先に非同期的に転送します。REDO転送サービスが複数のリモート宛先にREDOを送信する場合、ネットワーク・サーバー・プロセスは、すべての宛先に対するネットワークI/Oをパラレルに開始します。
ASYNC転送のプライマリ・データベースへの影響: ASYNC REDO転送の動作は真の意味で非同期的であるため、プライマリ・データベースのスループットに対する影響は最小限に抑えられます。
|
注意: ネットワーク・サーバー・プロセスは、REDOデータがログ・バッファからフラッシュされていないかぎり、ログ・バッファからREDOデータを読み取ります。フラッシュされている場合は、オンラインREDOログからREDOデータを読み取ります。ログ・バッファで変更が検出されない場合、ネットワーク・サーバー・プロセスは、オンラインREDOログからのみデータを読み取ります。 |
複数のストリームで使用されるネットワーク接続は、アーカイバ・プロセスによって開始されるため、LOG_ARCHIVE_MAX_PROCESSES初期化パラメータを設定する場合は注意してください。LOG_ARCHIVE_MAX_PROCESSES初期化パラメータの値は、すべてのリモート宛先数より少なくとも1大きくする必要があります。高可用性環境でLOG_ARCHIVE_MAX_PROCESSESパラメータを設定する場合は、次の式を使用します。
LOG_ARCHIVE_MAX_PROCESSES = sum(remote_destinations) + count(threads)
これらのパラメータ設定は、本番環境での初期設定の評価およびテスト後に、状況に応じて調整できます。
次の各項には、ネットワーク構成と最大ネットワークREDO速度のベスト・プラクティスが含まれます。
|
関連項目: MAAホワイト・ペーパー『Data Guard Redo Transport & Network Configuration』（http://www.otn.oracle.com/goto/maa） |
特に待機時間が長い高帯域のネットワークで、高いネットワーク・スループットを達成する場合、TCP送受信ソケット・バッファ・サイズの最小推奨設定は、プライマリ・システムとスタンバイ・システム間のネットワーク・リンクの帯域幅遅延積（BDP）です。BDPより高い値を設定すると、多少改善されることがあります。たとえば、MAA Linuxテスト・ラボで、TCP送受信ソケット・バッファ設定をBDPの最大3倍にすると、待機時間が長く高帯域という条件でシミュレートされたネットワークで、スループットが多少向上します。
BDPは、ネットワーク帯域幅と待機時間の積です。ソケット・バッファ・サイズは、Oracle NetパラメータのRECV_BUF_SIZEとSEND_BUF_SIZEを使用して設定するため、ソケット・バッファ・サイズの設定はOracle TCP接続にのみ有効です。ソケット・バッファ・サイズがオペレーティング・システムにより制限されている場合、Oracleでより大きい値を使用できるよう調整する必要があります。たとえば、Linuxでは、net.core.rmem_maxおよびnet.core.wmem_maxパラメータでソケット・バッファ・サイズを制限しているため、これらのパラメータにRECV_BUF_SIZEとSEND_BUF_SIZEより大きい値を設定する必要があります。
たとえば、帯域幅が622Mビットで待機時間が30ミリ秒の場合、RECV_BUF_SIZEおよびSEND_BUF_SIZEパラメータの最小サイズは、622,000,000 / 8 x 0.030 = 2,332,500バイトのように計算します。
この例では、初期化パラメータを次のように設定します。
RECV_BUF_SIZE=2,332,500
SEND_BUF_SIZE=2,332,500
Oracle Net Servicesでは、セッション・データ・ユニット（SDU）に関するOracle Net設定を調整することでデータ転送を制御できます。オラクル社の内部テストによれば、SDUを最大値の32767に設定すると、パフォーマンスが向上する可能性があります。SDUは、ローカル・ネーミング構成ファイル（TNSNAMES.ORA）およびリスナー構成ファイル（LISTENER.ORA）のSDUパラメータを使用して接続単位ごとに設定するか、SQLNET.ORAファイルのDEFAULT_SDU_SIZEプロファイル・パラメータですべてのOracle Net接続を対象に設定します。
|
関連項目: SDUおよびDEFAULT_SDU_SIZEパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。 |
Oracle Database 11g以上のOracle Data Guardには、ネットワーク経由で送信されるREDOデータを圧縮する機能があります。この圧縮は、アーカイブのARCnプロセスでのREDOギャップ解消中、または実行時にLGWR ASYNC転送を使用してREDOデータを送信する際に実行できます。一部の環境では、REDOデータの圧縮を有効にすると、次のことが可能になります。
ネットワーク使用の減少
アーカイブREDOログ・ファイルのギャップの短時間での解消
REDO転送時間の短縮
REDO転送圧縮はOracle Advanced Compressionオプションの機能で、REDO転送圧縮機能を使用する前にライセンスを購入する必要があります。
圧縮を使用する場合
一般に、圧縮のメリットがきわだつのは、低帯域ネットワーク経由で使用する場合です。ネットワーク帯域幅が増大すると、メリットは減少します。Data Guard環境でREDOを圧縮すると、次の場合にメリットがあります。
圧縮処理に十分なCPUリソースを利用できる場合
データベースREDO速度が、低帯域ネットワークのために制限されている場合
圧縮を有効にする前に、利用できるCPUリソースを評価し、圧縮を有効にできるかどうか判断します。ギャップ解消とLGWR ASYNC転送モードのための圧縮有効化の詳細は、サポート・ノート729551.1を参照してください（http://metalink.oracle.com/）。
この項では、フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースにおけるData Guardログ適用サービスのベスト・プラクティスについて説明します。
フィジカル・スタンバイ・データベースにREDO Applyを使用するか、任意のメディア・リカバリ操作を効率的に実行するには、次のベスト・プラクティスに従ってデータベース・リカバリをチューニングする必要があります。
スタンバイREDOログとアーカイブREDOログのI/Oレートを最大化します。
スタンバイREDOログ・ディレクトリとアーカイブREDOログ・ディレクトリのI/Oレートを測定します。転送されたREDOがスタンバイ・データベースに同時に書き込まれると、I/Oが飽和状態となってREDO読取り速度が低下する可能性があります。リカバリ速度全体はREDOを読み取ることのできる速度によって常に制限されるため、REDO読取り速度が必要とされるリカバリ速度を超えていることを確認します。
リカバリ速度を評価します。
リカバリ速度の履歴を取得するには、次の問合せを使用してリカバリ進行状況の履歴を表示します。
SELECT * FROM V$RECOVERY_PROGRESS;
ACTIVE APPLY RATEがプライマリ・データベースでの最大REDO生成速度を超えているか、プライマリ・データベースでの平均生成速度の2倍を超えている場合、チューニングは必要ありません。それ以外の場合は、次のチューニング・ヒントに従ってください。プライマリ・データベースのREDO生成速度は、Grid Controlで監視するか、REDO SIZE統計のAWRレポートから抽出することが可能です。CHECKPOINT TIME PER LOGが10秒を超えている場合は、I/Oとチェックポイントのチューニングを調査します。
DB_BLOCK_CHECKINGはデフォルトを使用し、DB_BLOCK_CHECKSUM=FULLに設定します。
DB_BLOCK_CHECKSUMを、TYPICAL（デフォルト設定）からFULLに変更します。ブロック・チェックは、プライマリ・データベースでは常に推奨されます。スタンバイ・データベースでは、リカバリ速度が期待どおりであれば有効化できます。
|
注意: DB_BLOCK_CHECKINGパラメータで保護できなかったブロック破損をチェックするには、次のいずれかの方法を使用します。
|
DB_BLOCK_CHECKSUMのデフォルト設定は、TYPICALです。ブロック・チェックサムは、プライマリ・データベースとスタンバイ・データベースの両方で常に有効化する必要があります。これにより、ごくわずかなオーバーヘッドが発生しますが、ほとんどのブロック破損を検出できます。
スタンバイ・データベースでDB_LOST_WRITE_PROTECTパラメータをFULLに設定し、I/Oサブシステムで失われた書込みをOracleで検出できるようにします。メディア・リカバリに対する影響はごくわずかであり、通常は2%未満です。
DB_CACHE_SIZEを、プライマリ・データベースの同じパラメータより大きい値に設定します。DB_KEEP_CACHE_SIZEとDB_RECYCLE_CACHE_SIZEを0に設定します。
データベース・キャッシュ・サイズを大きくすると、物理データ・ブロックの読取り量が減少するため、メディア・リカバリのパフォーマンスが向上する可能性があります。メディア・リカバリでは、DB_KEEP_CACHE_SIZEやDB_RECYCLE_CACHE_SIZEを必要としないか、または大きいサイズのSHARED_POOL_SIZEを必要としないため、DB_CACHE_SIZEにメモリーを再度割り当てることができます。
これらのパラメータは、スタンバイ・データベースをプライマリ・データベースに変換する前に、プライマリ・データベースの設定にリセットしてください。
データベース待機イベントを評価します。
Active Data Guardオプションとリアルタイム問合せによって、プライマリ・データベースのStatspackを使用して、読取り専用でオープンされてリカバリを実行するスタンバイ・データベースからデータを収集できます。すべてのチューニングまたはトラブルシューティング作業は、Standby Statspackレポートを収集することから開始します。Standby Statspackのインストールおよび使用方法の詳細は、サポート・ノート454848.1を参照してください（http://metalink.oracle.com/）。
Active Data Guardオプションのライセンスがない場合、スタンバイ・データベースのV$SYSTEM_EVENTS、V$SESSION_WAITSおよびV$EVENT_HISTOGRAMを問い合せて、最大のTIME_WAITED値を調べることで、上位のシステムおよびセッション待機イベントを特定できます。場合によっては、ある一定期間を正確に評価するため、問合せ結果の複数のスナップショットを取得して手動で差異を抽出する必要があります。
リカバリで多くのREDOデータを効率的に適用する場合、システムはI/Oバウンドとなるため、I/O待機が発生することはシステムにとって妥当な動作です。パラレル・リカバリ・コーディネータおよびスレーブに関連する待機イベントの大部分は、コーディネータに適用されます。スレーブは、変更を適用するか（CPUでのクロッキング）、コーディネータから変更が渡されるのを待機します。表2-4と表2-5に、データベースの待機イベントを示します。
表2-4 パラレル・リカバリ・コーディネータの待機イベント
| 待機名 | 説明 |
|---|---|
|
|
パラレル・リカバリ・コーディネータは、オンラインREDOログまたはアーカイブREDOログからのI/Oを待機しています。 |
|
|
このイベントは、すべての読取りバッファがスレーブによって使用されていることを示し、通常はリカバリ・スレーブがコーディネータに遅れていることを示します。 |
|
|
パラレル・リカバリ・コーディネータは、リカバリ・スレーブがバッファを解放するのを待機しています。このイベントも、リカバリ・スレーブがコーディネータに遅れていることを示します。 |
|
|
パラレル・リカバリ・コーディネータは、ファイルの自動拡張などによるファイルのサイズ変更が終了するのを待機しています。 |
|
|
コーディネータは、同期制御メッセージをすべてのスレーブに送信済で、すべてのスレーブからの応答を待機しています。 |
リカバリ・スレーブ・イベントを処理する場合、起動しているスレーブの数を把握することが重要です。任意のリカバリ・スレーブ・イベントの待機時間をスレーブの数で割ります。表2-5に、パラレル・リカバリ・スレーブの待機イベントを示します。
表2-5 パラレル・リカバリ・スレーブの待機イベント
| 待機名 | 説明 |
|---|---|
|
|
パラレル・リカバリ・スレーブは、コーディネータから変更が転送されるのを待機しています。このイベントは、実質的にはリカバリ・スレーブのアイドル・イベントです。リカバリ・スレーブが使用するCPU時間を特定するには、このイベントの経過時間を起動済スレーブの数で割り、その値を合計経過時間から引きます。この値には、多少の待機時間も含まれるため、近似値となります。 |
|
|
パラレル・リカバリ・スレーブ（またはシリアル・リカバリ・プロセス）は、同期データ・ブロックのバッチ読取りが完了するのを待機しています。 |
|
|
リカバリは、チェックポイントの完了を待機しており、REDO Applyは現時点で変更を適用していません。 |
|
|
パラレル・リカバリ・スレーブは、バッチ・データ・ブロックI/Oを待機しています。 |
DBWRでは、変更されたブロックをバッファ・キャッシュからデータファイルに書き出す必要があります。DISK_ASYNCH_IOをTRUEに設定して（デフォルト）、ネイティブの非同期I/Oを常に使用します。めったにないことですが、非同期I/Oが使用できない場合は、DBWR_IO_SLAVESを使用すると同期I/Oで有効なデータ・ブロック書込み速度を向上できます。
基本的なI/Oテストの実行、プライマリ・データベースとのI/O統計の比較、またはいくつかのI/O履歴メトリックの調査により、十分なI/O帯域幅が確保されており、I/Oレスポンス時間が現在のシステムにとって適切であることを確認します。Storage Area Network（SAN）やNetwork Attached Storage（NAS）などの同じストレージ・インフラストラクチャを多くのアプリケーションで共有している場合、I/Oレスポンス時間は変化する可能性があることに注意してください。
UNIXのsarコマンドやvmstatコマンドなどのシステム・コマンド、またはシステム・モニタリング・ツールを使用してシステム・リソースを評価します。別の方法として、Oracle Enterprise Manager、AWRレポート、またはV$SYSTEM_EVENT、V$ASM_DISK、V$OSSTATなどのパフォーマンス・ビューを使用して監視できます。
I/Oボトルネックや過剰な待機I/O操作が存在する場合、I/O容量を増加させている操作またはアプリケーションの変更を調査します。長い待機時間の原因が不十分なI/O帯域幅にある場合、関連するASMディスク・グループに別のディスクを追加します。この原因がバスやコントローラのボトルネック、またはその他のI/Oボトルネックではないことを確認します。スタンバイREDOログからの読取りI/Oレートは、期待されるリカバリ速度を超えている必要があります。
過剰なスワッピングまたはメモリー・ページングが発生していないかどうかをチェックします。
リカバリ中にリカバリ・コーディネータまたはMRPがCPUバウンド状態にならないことを確認します。
プライマリ・データベースとスタンバイ・データベースのREDOログ・サイズを増加します。
プライマリ・データベースのオンラインREDOログ・サイズとスタンバイ・データベースのスタンバイREDOログ・サイズを最低1GBに増加します。Oracleデータベースは、メディア・リカバリ中にログ・ファイル境界ごとに（最適化された方法で）完全チェックポイント処理を実行し、すべてのファイル・ヘッダーを更新します。データベースの完全チェックポイント処理とファイル・ヘッダー更新の頻度を抑制するには、負荷の高いシステムでログ・スイッチが最低20分間隔で発生するようREDOログ・サイズを増加します。これ以外の場合、1時間に1回で十分です。
REDOログ・サイズを非常に大きくした場合でも、プライマリ・データベースのクラッシュ・リカバリ時間を最小限に抑えるために、FAST_START_MTTR_TARGET初期化パラメータに0（ゼロ）以外の値を設定してファスト・スタート・リカバリを有効化します。パラメータが設定されていない場合は、3600に設定します。この初期化パラメータは、プライマリ・データベースにのみ有効です。
異なるリカバリ並列度を試します。
パラレル・リカバリは、使用可能なCPUの数に設定されたデフォルトの並列度に基づいて、メディア・リカバリとクラッシュ・リカバリに対してデフォルトで有効化されています。ほとんどの場合、これが最適な設定となります。ただし、一部の環境では、デフォルトとは異なる（多いかまたは少ない）並列度を使用した方がリカバリ速度が向上します。デフォルト設定を上書きするには、次のSQL*Plus文を使用して、明示的にパラレル・リカバリを指定します。
RECOVER MANAGED STANDBY DATABASE PARALLEL number_of_CPUs;
この項では、Data Guard SQL Applyとロジカル・スタンバイ・データベースの推奨事項について説明します。
この項には、次の各項目が含まれます。
MAX_SERVERSパラメータの初期値を、CPU数の8倍に設定します。たとえば、次のようになります。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SERVERS', <8 x CPUs>);
SQL Applyは、自動的にサーバー・プロセスを分散します。READER、BUILDER、ANALYZERの各ロールのプロセスは常に1つですが、通常、PREPARERプロセスとAPPLIERプロセスの必要数は様々です。MAX_SERVERSパラメータをデフォルト設定（CPU数の8倍）に設定することによって、多くの初期チューニングの実行を避けることができます。以前のデフォルトである9は、大規模トランザクションや多数の同時トランザクションを持つアプリケーションに対しては、非常に低すぎました。デフォルト設定が高くなると、PGAメモリー使用率も高くなります。
PRESERVE_COMMIT_ORDERパラメータは、スタンバイ・データベースにトランザクションが適用される順序を制御します。TRUE（デフォルト）に設定されると、関連付けられていないトランザクションは、プライマリ・データベース上でコミットされたのと同じ順序で適用されます。依存トランザクションは、設定に関係なく、常に正しい順序でコミットされます。
PRESERVE_COMMIT_ORDERパラメータの設定では、次のガイドラインに従ってください。
ロジカル・スタンバイ・データベースの使用目的が障害回復のみであるか、または、スタンバイ・データベースを使用するレポート・アプリケーションが、正しくない順序で適用されるトランザクションに対応できる場合は、PRESERVE_COMMIT_ORDERをFALSEに設定します。
大部分のサード・パーティのレプリケーション・ソリューションでは、この緩いCOMMIT処理が許容されます。OLTPアプリケーションの場合、パラメータをFALSEに設定すると、SQL Apply速度が2倍になる可能性があります。MAAテストでは、PRESERVE_COMMIT_ORDERがFALSEに設定されると、OLTPワークロード・パフォーマンスが40%以上改善されることが示されました。
レポート・システムまたは意思決定支援システムでは、PRESERVE_COMMIT_ORDERをTRUEに設定します。
ただし、スタンバイ・データベースがプライマリ・データベースよりも遅れていて、ロジカル・スタンバイ・データベースがプライマリ・データベースにすぐに追いつくのが好ましい場合、一時的にPRESERVE_COMMIT_ORDERパラメータをFALSEに設定することができます。たとえば、次のようになります。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER', 'FALSE');
ギャップが解消されたら、パラメータをTRUEに再設定します。
|
関連項目: 様々な状況でのPRESERVE_COMMIT_ORDERパラメータの設定の影響を示す例は、MAAホワイト・ペーパー『SQL Apply Best Practices: Oracle Data Guard 11g Release 1』を参照してください。 |
適切な計画と実行に基づいたData Guardのロール移行により、効果的に停止時間を最小化し、ビジネスへの影響を最小限に抑えながらデータベース環境をリストアすることが可能になります。フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースのどちらを使用するかにかかわらず、MAAのテスト結果では、Oracle Data Guard 11gによるスイッチオーバーとフェイルオーバーの時間は数秒間に短縮されました。この項では、スイッチオーバーとフェイルオーバーのベスト・プラクティスについて説明します。
Oracle Data Guardにより実行されるデータベース・スイッチオーバーは、スタンバイ・データベースとプライマリ・データベースの間でロールを切り替えるための一連の手順を含む計画された移行操作です。スイッチオーバー操作に成功すると、スタンバイ・データベースがプライマリ・ロールを引き継ぎ、プライマリ・データベースがスタンバイ・データベースとなります。通常、スイッチオーバーはわずか数秒から数分で完了します脚注10。
Data Guardでは、次の方法により動的にロールを変更できます。
Oracle Enterprise Managerの使用
ブローカのDGMGRLコマンドライン・インタフェースの使用
SQL文の発行（5.2.1.3.1項「SQL*Plusを使用したフィジカル・スタンバイ・データベースへのData Guardスイッチオーバー」および5.2.1.3.2項「SQL*Plusを使用したロジカル・スタンバイ・データベースへのData Guardスイッチオーバー」を参照）
|
関連項目: Enterprise ManagerまたはブローカのDGMGRLコマンドライン・インタフェースを使用してデータベース・スイッチオーバーを実行する方法の詳細は、『Oracle Data Guard Broker』を参照してください。 |
スイッチオーバー処理を最適化するには、スイッチオーバーを実行する前に、次のベスト・プラクティスを実行します。
ALTER SYSTEM KILL SESSION SQL*Plusコマンドを使用して、切断可能なすべてのセッションを切断します。
AQ_TM_PROCESSESパラメータを0に設定してジョブ処理を停止します。
NODELAYキーワードを使用してスタンバイ・データベースのログ適用サービスを停止および再起動し、指定されている適用遅延をすべて取り消します。
フィジカル・スタンバイ・データベースの場合、次のように実行します。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE NODELAY;
ロジカル・スタンバイ・データベースの場合、次のように実行します。
ALTER DATABASE STOP LOGICAL STANDBY APPLY; ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NODELAY;
V$ARCHIVE_DESTビューのDELAY_MINS列を問い合せることによって、プライマリ・データベース上の現在の遅延設定を表示することができます。
ロジカル・スタンバイ・データベースの場合:
『SQL Apply Best Practices』ホワイト・ペーパー（http://www.otn.oracle.com/goto/maa）を参照して、最適SQL Apply速度を決定します。
SQL*Plus文を使用してスイッチオーバーを実行する場合、ALTER DATABASE PREPARE TO SWITCHOVER SQL*Plus文を発行して、先にLogMinerデータ・ディクショナリを構築することをお薦めします。
プライマリ・データベースのV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せて、LogMinerデータ・ディクショナリがプライマリ・データベースに受信されたことを確認します。問合せによりTO LOGICAL STANDBYという値が戻された場合、スイッチオーバー操作を継続できます。詳細は、『Oracle Data Guard概要および管理』のロジカル・スタンバイ・データベースが関与するスイッチオーバーに関する項を参照してください。
Oracle RAC環境のフィジカル・スタンバイ・データベースについては、各プライマリ・データベースおよびスタンバイ・データベースに対して、必ず、アクティブなインスタンスが1つのみ存在するようにします（ロジカル・スタンバイ・データベースが関係するスイッチオーバーでは、アクティブなインスタンスが1つだけである必要はありません）。
スイッチオーバー処理を最適化するには、リアルタイム適用を使用するようにスタンバイ・データベースを構成し、可能な場合は、スイッチオーバー操作の前にデータベースが確実に同期されるようにします。
スイッチオーバーを可能なかぎり高速化するには、受信と同時にREDOデータがスタンバイ・データベースに適用されるように、リアルタイム適用を使用します。この場合、スタンバイ・データベースが、スイッチオーバー操作の前にプライマリ・データベースと同期化されて、スイッチオーバー時間が最小限に抑えられます。リアルタイム適用を有効化する手順:
フィジカル・スタンバイ・データベースの場合は、次のSQL*Plus文を使用します。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT USING CURRENT LOGFILE;
ロジカル・スタンバイ・データベースの場合は、次のSQL*Plus文を使用します。
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
フィジカル・スタンバイ・データベースの場合は、アーカイバ・プロセス（ARCn）の数を、リモート・アーカイブとローカル・アーカイブの両方に必要な最小の値に減らします。追加のアーカイバ・プロセスは、停止時間を増加させる可能性があり、その結果スイッチオーバーの実行にかかる合計時間も増加します。スイッチオーバーが完了したら、追加のアーカイバ・プロセスを再有効化できます。
LOG_FILE_NAME_CONVERT初期化パラメータをその環境で有効な任意の値に設定するか、不要な場合はNULLに設定します。
スイッチオーバーの一環として、スタンバイ・データベースでは、プライマリ・データベースとしてオープンする前にスタンバイ・データベース上のオンラインREDOログ・ファイルを消去する必要があります。I/Oの完了に要する時間により、スイッチオーバーの合計時間が大幅に増加する可能性があります。LOG_FILE_NAME_CONVERTパラメータを設定すると、MRPプロセスの最初の起動時に、スタンバイ・データベースからオンラインREDOログを事前に作成することができます。スタンバイ・データベース上でSQL*PlusのALTER DATABASE CLEAR LOGFILE文を発行することで、空のオンラインREDOログを事前に作成することもできます。
フェイルオーバーは通常、プライマリ・データベースが利用できなくなって、妥当な期間内でサービスに復帰させる可能性がない場合にのみ使用されます。フェイルオーバーの際、1つのサイトのプライマリ・データベースがオフラインにされ、スタンバイ・データベースがプライマリ・データベースとしてオンラインにされます。
Data Guardのフェイルオーバー・プロセスは、ファスト・スタート・フェイルオーバー機能を使用して完全自動で実行するか、ユーザーが手動で起動します。ファスト・スタート・フェイルオーバーを使用して、手動操作を必要とするプロセスに固有の不確実性を排除することをお薦めします。この機能を使用すると、システム停止が検出されてから数秒以内にフェイルオーバーを自動的に実行できます。
フェイルオーバーには、手動フェイルオーバーとファスト・スタート・フェイルオーバーという2つの異なるタイプがあります。プライマリ・データベースに障害が発生した場合、管理者は手動フェイルオーバーを開始します。一方、Data Guardでは、一定の期間にわたり（ファスト・スタート・フェイルオーバーしきい値）プライマリ・データベースが使用不可能になると、ユーザーの操作なしで自動的にファスト・スタート・フェイルオーバーが開始されます。
表2-6に、ファスト・スタート・フェイルオーバーと手動フェイルオーバーの特徴を比較して示します。
表2-6 ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較
| 比較ポイント | ファスト・スタート・フェイルオーバー | 手動フェイルオーバー |
|---|---|---|
|
メリット |
手動操作を極力使用せずに可用性を向上し、管理コストを削減できます。 |
フェイルオーバーの発生時期とターゲット・スタンバイ・データベースをユーザーが正確に制御できます。 |
|
フェイルオーバー・トリガー |
ファスト・スタート・フェイルオーバーが自動的に起動されるのは、次の場合です。
|
手動フェイルオーバーは、ユーザーによって開始され、スタンバイ・データベースをプライマリ・データベースに変換するための一連の手順を実行します。手動フェイルオーバーは、次のような計画外の停止が発生した場合に実行します。
|
|
管理 |
ファスト・スタート・フェイルオーバーの管理には、次のツールを使用します。
5.2.1.3項「Data Guardスイッチオーバーを実行する方法」を参照してください。 |
手動フェイルオーバーの実行には、次のツールを使用します。
項4.2.2.3「手動フェイルオーバー実行のベスト・プラクティス」を参照してください。 |
|
フェイルオーバー後の元のプライマリ・データベースのリストア |
ファスト・スタート・フェイルオーバーの後、ブローカは、構成への再接続時に元のプライマリ・データベースをスタンバイ・データベースとして自動的に再構成できます（ |
手動フェイルオーバーの後、フォルト・トレランスを回復するために元のプライマリ・データベースをスタンバイ・データベースとして復元する必要があります。 |
|
フェイルオーバー後のバイスタンダ・スタンバイ・データベースのリストア |
ブローカにより、構成内のすべてのデータベースのロール移行が調整されます。 復元を必要としないバイスタンダは、新しいプライマリになれるスタンバイ・データベースとして利用できます。復元を必要とするバイスタンダは、オブザーバによって自動復元されます。 |
ブローカを使用する利点は、バイスタンダ・データベースのステータスが提供され、データベースを復元する必要があるかどうかが示されることです。SQL*Plus文を使用してフェイルオーバーを管理する場合、ステータス情報はすぐには利用できません。 4.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。 |
|
アプリケーション・フェイルオーバー |
ブローカは、フェイルオーバー後に、FAN/AQ（アドバンスト・キューイング）通知を自動的に発行します。高速接続フェイルオーバーも構成されているクライアントは、それらの通知を使用して新しいプライマリ・データベースに接続することができます。 |
フェイルオーバー後にアプリケーションを業務で利用できるようにファスト・クライアント・フェイルオーバーを構成するには、2.9項「高速接続フェイルオーバーの構成」を参照してください。クライアントを、手動フェイルオーバー後に高速接続フェイルオーバーを行うように構成することもできます。 |
フェイルオーバー処理を最適化するには、次のベスト・プラクティスを使用します。
ファスト・スタート・フェイルオーバーを使用します。
Oracle Database 11gの稼働する環境で行ったMAAテストでは、ブローカとファスト・スタート・フェイルオーバーを使用したフェイルオーバーの実行により、可用性が大幅に向上しました。Oracle Data Guardフェイルオーバー・ベスト・プラクティスの総合レビューは、次を参照してください。
MAAホワイト・ペーパー『Data Guard Fast-Start Failover』（http://www.otn.oracle.com/goto/maa）
フェイルオーバー操作の完了後に障害が発生したプライマリ・データベースを復元するため、フラッシュバック・データベースを有効化します。必要な場合、フラッシュバック・データベースはポイント・イン・タイム・リカバリを容易にします。
ユーザー・エラーや論理破損が検出されたときに、受信と同時にREDOデータをスタンバイ・データベースに適用してデータベースを迅速に復元するため、フラッシュバック・データベースと組み合せてリアルタイム適用を使用します。
フェイルオーバー後もデータ保護を維持するために、複数のスタンバイ・データベースを構成することを検討します。
ロジカル・スタンバイ・データベースでは、MAAホワイト・ペーパー『SQL Apply Best Practices』を参照して、最適なSQL Apply速度を確認します。
フィジカル・スタンバイ・データベースの場合:
MAA Webサイト（http://www.otn.oracle.com/goto/maa）のMAAホワイト・ペーパー『Oracle Data Guard Redo Apply and Media Recovery』を参照して、REDO Applyのメディア・リカバリを最適化します。
（以前のリリースで要求されたように）スタンバイ・データベースを再起動するのではなく、MOUNTED状態からOPEN状態に直接移行します。
読取り専用モードからREDO Apply（リカバリ）モードに移行する場合、データベースを再起動します。
LOG_FILE_NAME_CONVERTパラメータを設定します。フェイルオーバーの一環として、スタンバイ・データベースでは、プライマリ・データベースとしてオープンする前にオンラインREDOログを消去する必要があります。このI/Oの完了に要する時間により、フェイルオーバーの合計時間が大幅に増加する可能性があります。LOG_FILE_NAME_CONVERTパラメータを設定すると、MRPプロセスの最初の起動時に、スタンバイによってオンラインREDOログが事前作成されます。スタンバイ・データベース上でSQL*PlusのALTER DATABASE CLEAR LOGFILE文を発行することで、空のオンラインREDOログを事前に作成することもできます。
プライマリ・データベースで障害が発生すると、ファスト・スタート・フェイルオーバーにより、指定されたスタンバイ・データベースに対して自動的に迅速で信頼性の高いフェイルオーバーが実行されるため、手動操作でフェイルオーバーを実行する必要はありません。ファスト・スタート・フェイルオーバーは、ブローカが管理するOracle Data Guard構成でのみ使用できます。
ファスト・スタート・フェイルオーバーを使用したOracle Data Guard構成は、最大可用性モードまたは最大パフォーマンス・モードで稼働します。ファスト・スタート・フェイルオーバーを有効化した場合、構成済のデータ損失保証を維持できる場合にのみファスト・スタート・フェイルオーバーを実行できるように、ブローカにより保証されます。最大可用性モードでは、データ損失の発生しないことが保証された自動フェイルオーバー環境が提供されます。最大パフォーマンス・モードでは、FastStartFailoverLagLimit構成プロパティで指定されたデータ量（秒単位）を超える損失は発生しないことが保証された自動フェイルオーバー環境が提供されます。
「フェイルオーバーの一般的なベスト・プラクティス」に記載された汎用のベスト・プラクティスに加え、次のファスト・スタート・フェイルオーバーのベスト・プラクティスを使用してください。
ファスト・スタート・フェイルオーバーのオブザーバ・プロセスは、プライマリ・データベースまたはスタンバイ・データベースとは別の場所にあるデータ・センターのホストで実行します。
オブザーバは、プライマリ・データベースおよびスタンバイ・データベースから等距離の場所にあるシステムで実行してください。オブザーバは、任意のエンド・ユーザー・クライアントと同じネットワークを使用してこれら2つのデータベースに接続する必要があります。指定したオブザーバに障害が発生した場合、Enterprise Managerがそれを検出し、自動的にオブザーバを再起動することができます。オブザーバを第3のサイトで実行できない場合は、アプリケーションと同じネットワークにインストールしてください。第3の独立した場所を使用できない場合、スタンバイ・データ・センター内の別個のホストにオブザーバを配置し、スタンバイ・データベースに影響を与える障害からできるかぎり離してください。
Oracle Enterprise Managerを使用してオブザーバの可用性を高め、データベースへの接続が再確立されたら、元のプライマリ・データベースがスタンバイ・データベースとして自動的に復元されるように構成します。また、Enterprise Managerを使用すると、オブザーバを再起動する代替ホストを定義できます。
フェイルオーバーの完了後、FastStartFailoverAutoReinstate構成プロパティをTRUEに設定すると、接続が再確立されたときに、元のプライマリ・データベースがスタンバイ・データベースとして自動的に復元されます。
現在の構成上の特性に従って、FastStartFailoverThresholdプロパティの値を表2-7のとおりに設定します。
表2-7 FastStartFailoverThresholdの最小値の推奨設定
| 構成 | 最小値の推奨設定 |
|---|---|
|
単一インスタンスのプライマリ、短い待機時間、信頼性の高いネットワーク |
15秒 |
|
単一インスタンスのプライマリ、WANを介した待機時間の長いネットワーク |
30秒 |
|
Oracle RACのプライマリ |
再構成時間 + 30秒 脚注1 |
脚注1 リリース10.2.0.3より前のOracleデータベース・ソフトウェアを実行する構成では、最小限の再構成時間を、「Oracle RACミスカウント + 再構成時間 + 30秒」という式で計算します。
表2-7に示す設定を使用する構成をテストして、ファスト・スタート・フェイルオーバーのしきい値が、間違ってフェイルオーバーが起動されるほど極端に小さくないか、またはフェイルオーバー要件を満たさないほど大きくないかどうかを確認してください。
ユーザーが起動する手動フェイルオーバーは、緊急時にのみ使用し、次のような計画外の停止が発生した場合に開始する必要があります。
プライマリ・データベースが使用不可能となるサイト障害
一定の時間内に修復できないユーザー・エラー
広範囲の破損を含む、本番アプリケーションに影響を及ぼすデータ障害
「フェイルオーバーの一般的なベスト・プラクティス」に記載された汎用のベスト・プラクティスに加え、次の手動フェイルオーバーのベスト・プラクティスを使用してください。
元のプライマリ・データベースをスタンバイ・データベースとして復元し、現在の環境にフォルト・トレランスを回復する必要があります。スタンバイ・データベースは、フラッシュバック・データベースを使用して迅速に復元できます。4.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。
Oracle RACに関連する手動フェイルオーバーでは、フェイルオーバーを実行する前にスタンバイ・データベースのすべてのセカンダリOracle RACインスタンスにSHUTDOWN ABORT文を発行します。
フィジカル・スタンバイ・データベースについては、MAAホワイト・ペーパー『Oracle Data Guard Redo Apply and Media Recovery』を参照してください（http://www.otn.oracle.com/goto/maa）。
Oracle Data Guardのリリース11g以上では、フィジカル・スタンバイ・データベースを、スナップショット・スタンバイ・データベースと呼ばれる完全に更新可能なスタンバイ・データベースに変換することができます。
フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換するには、SQL*PlusのALTER DATABASE CONVERT TO SNAPSHOT STANDBY文を発行します。このコマンドを使用すると、Oracle Data Guardが次のアクションを実行します。
利用できるすべてのREDOデータを回復します。
保証付きリストア・ポイントを作成します。
スタンバイ・データベースを、プライマリ・データベースとしてアクティブ化します。
データベースを、スナップショット・スタンバイ・データベースとしてオープンします。
スナップショット・スタンバイを元のフィジカル・スタンバイに変換するには、ALTER DATABASE CONVERT TO PHYSICAL STANDBY文を発行します。このコマンドを使用すると、フィジカル・スタンバイ・データベースは、ALTER DATABASE CONVERT TO SNAPSHOT STANDBY文が発行される前に作成された保証付きリストア・ポイントにフラッシュバックされます。次に、次のアクションを実行する必要があります。
フィジカル・スタンバイ・データベースを再起動します。
フィジカル・スタンバイ・データベース上でREDO Applyを再起動します。
スナップショット・スタンバイ・データベースの作成および管理にあたっては、次のベスト・プラクティスに従ってください。
ブローカを使用して変換手順を自動化し、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベース・ロールに戻すプロセスを促進します。これが有効なのは、先にフィジカル・スタンバイに戻すことによってのみ、スナップショット・スタンバイ・データベースをスイッチオーバーまたはフェイルオーバーに使用できるためです。
目標リカバリ時間（RTO）が要求される業務の場合、複数のスタンバイ・データベースを作成します。
スナップショット・スタンバイに変換するフィジカル・スタンバイ・データベースが、プライマリ・データベースに追随しているか、適用ラグが最小であることを確認します。メディア・リカバリのチューニングの詳細は、2.6.6.1項「フィジカル・スタンバイ・データベースにおけるREDO Applyのベスト・プラクティス」を参照してください。
フラッシュ・リカバリ領域を構成し、十分なI/O帯域幅を利用できることを確認します。確認が必要なのは、スナップショット・スタンバイ・データベースが保証付きリストア・ポイントを使用するためです。
|
関連項目: スナップショット・スタンバイ・データベースの作成方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
『Oracle Database高可用性概要』には、複数のスタンバイ・データベースのアーキテクチャが、実質的にどの程度単一のスタンバイ・データベースのアーキテクチャと同じであるかが記載されています。したがって、この項で説明する複数のスタンバイ・データベースの実装における構成ガイドラインは、フィジカルおよびロジカル・スタンバイ・データベースの既存のベスト・プラクティスを補完するものです。
複数のスタンバイ・データベースをデプロイする場合、次のベスト・プラクティスを使用します。
ブローカ（第3章「Oracle Grid Controlを使用した監視」で説明）を使用して、構成を管理し、ロール移行を実行します。ただし、SQL*Plus文を使用する場合のベスト・プラクティスは、MAAホワイト・ペーパー『Multiple Standby Databases Best Practices』を参照してください。
フェイルオーバー後、バックアップまたはプライマリ・データベースからスタンバイ・データベース全体を再作成するかわりに、フラッシュバック・データベースを使用して旧プライマリをスタンバイとして迅速に復元します。DB_FLASHBACK_RETENTION_TARGET初期化パラメータを構成内のすべてのデータベースで同じ値に設定します。フェイルオーバー後にデータベースを復元することを唯一の目的としてフラッシュバック・データベースを使用する場合、DB_FLASHBACK_RETENTION_TARGETの最低限の推奨値は60分です。
ロジカル・スタンバイ・データベースが含まれる構成でサプリメンタル・ロギングを有効化します。フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方を含んだ構成を作成する場合、次の状況ではALTER DATABASE ADD SUPPLEMENTAL LOG DATA文を発行してサプリメンタル・ロギングを有効化します。
すべてのフィジカル・スタンバイ・データベースが含まれる既存の構成にロジカル・スタンバイ・データベースを追加する場合、構成内のすべての既存のフィジカル・スタンバイ・データベースでサプリメンタル・ロギングを有効化する必要があります。
ロジカル・スタンバイ・データベースを含んだ既存の構成にフィジカル・スタンバイ・データベースを追加する場合、作成時にフィジカル・スタンバイ・データベースでサプリメンタル・ロギングを有効化する必要があります。
サプリメンタル・ロギングは、ロジカル・スタンバイ・ディクショナリのビルド時にプライマリ・データベースで有効化されます。サプリメンタル・ロギングを有効化すると、制御ファイルが変更されるため、その変更は各フィジカル・スタンバイ・データベースに伝播されません。サプリメンタル・ロギングは、ディクショナリ・ビルド・プロセスの一環としてデータベースがフィジカル・スタンバイ・データベースからロジカル・スタンバイ・データベースに最初に変換されたときに、ロジカル・スタンバイ・データベースで自動的に有効化されます。サプリメンタル・ロギングを有効化するには、フィジカル・スタンバイ・データベースへの接続時に次のSQL*Plus文を発行します。
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;
ロジカル・スタンバイ・データベースがリアルタイム問合せを実行するように構成されていない場合、SQL Applyを構成して、ロジカル・スタンバイ・データベースへのREDOデータの適用を遅延することを検討してください。REDOの適用を遅延することで、フィジカル・スタンバイ・データベースへのフェイルオーバー後にロジカル・スタンバイ・データベースを手動で復元する必要性を最小限に抑えることができます。
遅延時間を設定するには、LOG_ARCHIVE_DEST_n初期化パラメータのDELAY=minutes属性を使用します。
|
関連項目: 複数のスタンバイ・データベースを使用するメリットおよび実装例の詳細は、『Oracle Database高可用性概要』を参照してください。 |
Oracle Active Data Guardオプション（Oracle Database 11gリリース1以上で利用可能）のライセンスがある場合、スタンバイ・データベース上のREDO Applyがプライマリ・データベースから受信したREDOデータを継続して適用している状態で、フィジカル・スタンバイ・データベースを読取り専用アクセスで開くことができます。フィジカル・スタンバイ・データベースから読み取る問合せはすべてリアルタイムで実行され、現在の結果を戻すため、データ保護が不完全になったり、フェイルオーバーが必要な場合にリカバリ時間が長くなったりすることなく、システム資源をより効率的に利用できます。このため、この機能はリアルタイム問合せと呼ばれます。
この項では、リアルタイム問合せをデプロイするためのベスト・プラクティスについて説明します。
以前に説明した、次の一般的なベスト・プラクティスを使用します。
2.6.5項「REDO転送サービスのベスト・プラクティス」で説明したガイドラインに従って、ネットワークをチューニングします。
REDOデータの受信と同時に変更が適用されるように、スタンバイ・データベースにリアルタイム適用を使用します。
Oracle Database 11gリリース11.1.0.6を実行する構成の場合は、再起動時に読取り専用モードでスタンバイ・データベースを直接オープンできるように、スタンバイ・インスタンスとREDO Applyを正常に停止します。
クライアントに効率的なフェイルオーバーを構成します。
ADDRESS_LISTのすべてのホスト（プライマリとスタンバイの両方）を含むOracle Net別名を使用して、プライマリ・データベースとレポート・アプリケーションを接続します。
ロール固有のサービスを使用してプライマリ・データベースとレポート・アプリケーションを接続します。
スタンバイ・データベースに接続するレポート・アプリケーションと、プライマリ・データベースに接続するプライマリ・アプリケーションは、正しいデータベース・ロールでデータベースに接続する必要があります。
データベース・ロールに基づいてサービスを起動および停止します。
たとえば、次の例は、データベース・ロールをチェックして、適切なサービスを起動するafter startupトリガーを使用して、サービスの起動と停止を自動化しています。
CREATE OR REPLACE TRIGGER manage_service
after startup on database
DECLARE
role VARCHAR(30);
BEGIN
SELECT DATABASE_ROLE INTO role FROM V$DATABASE;
IF role = 'PRIMARY' THEN
DBMS_SERVICE.START_SERVICE('sales_rw');
ELSE
DBMS_SERVICE.START_SERVICE('sales_ro');
END IF;
END;
Standby Statspackを使用してスタンバイ・データベースのパフォーマンスを監視します。
Standby Statspackのインストールおよび使用方法の詳細は、サポート・ノート454848.1を参照してください（http://metalink.oracle.com/）。
スタンバイ・データベース上のREDO Applyがプライマリ・データベースに対してどの程度遅れているかを監視するには、V$DATABASEビューのCURRENT_SCN列を問い合せます。詳細は、2.6.10.2項「リアルタイム問合せの監視」を参照してください。
|
関連項目: MAAホワイト・ペーパー『Oracle Active Data Guard: Oracle Data Guard 11g Release 1』
|
次の手順では、トランザクション的にプライマリ・データベースと一貫性のあるスタンバイ・データベースでリアルタイム問合せを有効化する方法について説明します。
|
注意: 一貫性のないスタンバイ・データベースの場合は、スタンバイを読取り専用アクセスでオープンする前に、スタンバイをプライマリ・データベースと一貫しているようにする必要があります。手順説明は、MAAホワイト・ペーパー『Oracle Active Data Guard 11g Release 1』を参照してください。 |
スタンバイ・データベース・インスタンスとREDO Applyを正常に停止していれば、スタンバイ・データベースを読取り専用状態で直接オープンできます。オープン後に、REDO Applyを開始してリアルタイム問合せを有効化できます。
一貫性のあるフィジカル・スタンバイ・データベースを有効化するには、次の手順を実行します。
スタンバイ・インスタンスを読取り専用で起動します。
SQL> STARTUP
スタンバイ・データベースでOPENコマンドを発行する場合、READ ONLYキーワード（デフォルトの起動状態）は暗黙的に含まれるため、STARTUPコマンドにこのキーワードを含める必要はありません。
注意: スタンバイ・データベースがOracle RACデータベースの場合、最初に1つのスタンバイ・インスタンスを読取り専用でオープンしてREDO Applyを開始してから追加のスタンバイ・インスタンスを読取り専用モードでオープンしてください。
データベースがオープンしたら、REDO Applyを開始します。
SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT USING CURRENT LOGFILE;
ブローカを使用してData Guard構成を管理している場合、スタンバイ・データベースのデフォルト状態はAPPLY ONであり、REDO Applyは自動的に開始します。このデフォルトが変更されている場合、次のコマンドを発行してREDO Applyを開始します。
DGMGRL> EDIT DATABASE 'RTQ' SET STATE='APPLY-ON'
スタンバイ・データベースがマウントされてREDO Applyが実行中の場合、REDO Applyを停止してスタンバイ・データベースを読取り専用アクセスでオープンし、REDO Applyを再起動します。
リアルタイム問合せを使用すると、スタンバイ・データベースへのデータ適用時にそのデータの問合せが可能であり、その際、トランザクション的に一貫したデータのビューが保証されます。データの読取り一貫性ビューは、QUERY SCNにより実現されています。スタンバイ・データベース上のQUERY SCNは、従属的なすべての変更が適用された後、リカバリ・プロセスにより拡張されています。拡張された新しいQUERY SCNは、Oracle RACスタンバイのすべてのインスタンスに伝播されます。QUERY SCNは、すべてのスタンバイ・インスタンスに公開された後、スタンバイ・データベース上の、V$DATABASEビューのCURRENT_SCN列を通じてユーザーに公開されます。
スタンバイ・データベース上のQUERY SCNは、プライマリ・データベース上のCURRENT_SCNと等価です。これにより、スタンバイ・データベース・インスタンスに接続しているアプリケーションは、QUERY SCNを、データがプライマリ・データベースとの関連で存在する場所のスナップショットとして使用できます。プライマリ・データベース上の問合せとスタンバイ・データベース上の問合せは、特定のCURRENT SCNの時点での同一の結果を戻します。スタンバイ・データベース上の問合せ結果がプライマリ・データベースに対してどの程度遅れているかを決定するには、プライマリ・データベースのCURRENT SCN列と、スタンバイ・データベースのCURRENT SCN列を比較します。たとえば、RTQ_STBYと呼ばれるスタンバイ・データベースを参照しているプライマリ・データベース上にdblinkがある構成では、プライマリ・データベース上で次の問合せを発行します。
SQL> SELECT SCN_TO_TIMESTAMP((SELECT CURRENT_SCN FROM V$DATABASE)) -SCN_TO_TIMESTAMP((SELECT CURRENT_SCN FROM V$DATABASE@RTQ_STBY)) FROM DUAL;
問合せから戻される値は、スタンバイ・データベース上のデータがプライマリ・データベースの現在の位置より遅れている秒数を示します。プライマリ・データベースに接続したり、プライマリ・データベースを使用したりすることなく、スタンバイ上のだいたいの問合せラグを決定するには、V$DATAGUARD_STATSビューからAPPLY LAGメトリックを使用します。APPLY LAGメトリックは、V$DATAGUAD_STATSビューに対する問合せが発行された時点ではなく、メトリックが計算された時点でのみ有効であることに注意してください。適用ラグを最後に決定した時刻を決定するには、COMPUTED_TIME列を使用します。
|
関連項目: MAAホワイト・ペーパー『Oracle Active Data Guard: Oracle Data Guard 11g Release 1』 |
高可用性環境では、データベース以外のファイルもデータベース・ファイルとともに保護する必要があります。Oracle Secure Backupは、UNIX、Linux、Windows、Network Attached Storage（NAS）などの異機種環境にデータ保護を提供します。また、障害時リカバリ目的では、複数のサード・パーティ・ツールを使用してローカル・ファイルとリモート・ファイルのセット間でリモート同期を実行できます。たとえば、リモート同期用としてrsync、csync2、DRDBなどのツールを使用できます。これらのツールは、インターネットからダウンロードできます。これらのツールに関する推奨事項を次のリストに示します。
ソフトウェアの更新用としては、プライマリ・システムのソフトウェアの変更とスタンバイ・システムを同期するためにrsyncを使用します。
構成ファイル用としては、rsyncを毎日または更新後に使用するか、csync2を使用します。
重要なログ・ファイル、トレース・ファイルまたはデバッグ・ファイル用としては、rsyncを毎日または1時間ごとに使用するか、ファイル・システム全体を同期するためにDRDBを使用します。ただし、既存のスタンバイ・ログやトレース・ディレクトリを上書きしないでください。
データベースと同期する必要のあるトランザクション・ログまたはメタデータ・ファイル用としては、rsyncまたはcsync2を頻繁に使用するか、DRDB、サード・パーティ製のミラー化ユーティリティ、リモート同期ツールなどのブロック同期ツールを使用します。
|
関連項目: 『Oracle Secure Backup管理者ガイド』 |
Data Guardスタンバイ・データベースの追加後におけるプライマリ・データベースのパフォーマンスを正確に評価するには、同じアプリケーション・プロファイルおよび負荷を伴うData Guardのデプロイ前後に、V$SYSMETRIC_SUMMARYビューまたは自動ワークロード・リポジトリ（AWR）のスナップショットから統計履歴を取得します。
アプリケーション・プロファイルを評価するには、次の統計を比較します。
1トランザクション当たりの物理読取り
1トランザクション当たりの物理書込み
1トランザクション当たりのCPU使用率
1トランザクション当たりのREDO生成
アプリケーション・パフォーマンスを評価するには、次の統計を比較します。
1秒当たりのREDO生成（またはREDO速度）
1秒当たりのユーザー・コミット（または1秒当たりのトランザクション）
1秒当たりのデータベース処理時間
1トランザクション当たりのレスポンス時間
SQLサービス・レスポンス時間
アプリケーション・プロファイルが2つの使用例で変化していると、正確に比較できません。『Oracle Databaseパフォーマンス・チューニング・ガイド』に記載された一般的な原則に従って、データベースまたはシステムでテストとチューニングを繰り返してください。
アプリケーション・プロファイルがほぼ同じ状態で、プライマリ・データベースのアプリケーション・パフォーマンスにスループットの低下やレスポンス時間の増大といった変化が認められる場合、次の一般的な問題領域を確認します。
CPU使用率
システム負荷が高い場合（90%を超える過剰なCPU使用率、ページングおよびスワッピング）、Data Guardでの操作を続ける前にシステムをチューニングする必要があります。オペレーティング・システムの使用統計を監視するには、V$OSSTATビューまたはV$SYSMETRIC_HISTORYビューを使用します。
I/O待機イベントの増加
ログ・ライター・プロセスまたはデータベース・ライター・プロセスのI/O待機が増加すると、I/Oの低下によりスループットとレスポンス時間が影響を受けます。I/Oへの影響は、次の待機イベントの履歴データを参照することで確認できます。
ログ・ファイル・パラレル書込み
ログ・ファイル順次読取り
ログ・ファイル・パラレル読取り
データファイル・パラレル書込み
データファイル順次読取り
SYNC転送では、より多くのコミット時間を必要とします。これは、フォアグラウンド・プロセスがログ・ライター（LGWR）・バックグラウンド・プロセスからコミット完了の確認応答を受信する前に、スタンバイ・データベースでREDOデータが使用可能であることを保証する必要があるためです。LGWRプロセスのコミットには、次の待機イベントが含まれます。
ログ・ファイル・パラレル書込み（LGWRプロセスのローカル書込み）
SENDREQでのLGWR待機
この待機イベントには、次の時間が含まれます。
パケットをネットワークに送信する時間
パケットをスタンバイ・データベースに送信する時間
スタンバイREDOログにRFS書込みまたはスタンバイ書込みを行う時間（RFSのI/O待機イベントとチェックサムのための追加オーバーヘッドを含む）
プライマリ・データベースにネットワーク確認応答を送信する時間（シングル・トリップの待機時間など）
LGWRプロセスによるコミット時間の増加は、特に小規模な時間依存型のトランザクションにおいて、レスポンス時間の増加とスループット低下の原因となる場合があります。ただし、ログ・ライターのローカル書込み（ログ・ファイル・パラレル書込み待機イベント）や、SENDREQ待機イベント上でLGWR待機を構成する各種の構成要素をチューニングすることで、これらの問題を十分に改善できる可能性があります。
ディスク書込みI/O（ログ・ファイル・パラレル書込みまたはRFS I/O）をチューニングするには、より多くのスピンドルを追加するか、I/O帯域幅を拡張します。
ネットワーク時間を短縮するには、次のようにします。
Oracle Netの送信および受信バッファ・サイズをチューニングします。
SDU=32Kに設定します。
飽和状態にある場合、ネットワーク帯域幅を拡張します。
より近距離のサイトを探してネットワーク待機時間を短縮します。
ASYNC転送では、LGWRプロセスは、ネットワーク・サーバー・プロセスが戻るのを待機せずにCOMMITレコードを現在のログ・ファイルに書き込みます。ただし、ネットワーク・サーバー・プロセスが遅延し、転送予定のREDOがログ・バッファからフラッシュされている場合、ネットワーク・サーバー・プロセスはオンラインREDOログからデータを読み取ります。これにより、I/Oの競合が増加し、状況によってはログ・ライター・プロセスの書込み（ログ・ファイル・パラレル書込み）の待機時間が増加します。I/O帯域幅と十分なスピンドルが割り当てられていない場合、ログ・ファイル・パラレル書込みおよびログ・ファイル順次読取りによる待機が増加し、スループットやレスポンス時間に影響を与える可能性があります。通常は、十分なスピンドルを追加することでI/O待機時間を削減できます。
|
注意: 統計収集機能とアドバイザの大部分を有効化するには、STATISTICS_LEVEL初期化パラメータをTYPICAL（推奨）またはALLに設定します。 |
|
関連項目:
|
脚注の説明
脚注8: Extended Datatype Support（EDS）を使用すると、他のいくつかの高度なデータ型に対応することができます。詳細は、MAAホワイト・ペーパー『Extended Datatype Support: SQL Apply and Streams』（http://www.oracle.com/technology/deploy/availability/pdf/maa_edtsoverview.pdf）を参照してください。