| Oracle Database高可用性ベスト・プラクティス 11gリリース2(11.2) B65088-05 |
|
 前 |
 次 |
スイッチオーバーやフェイルオーバー後にすべてのスタンバイ・データベースが適切に動作し、必要なサービス・レベルの範囲内でそのロールを実行するには、Oracle Data Guardの適切な構成が不可欠です。
Oracle Data Guardのベスト・プラクティスは、第5章「Oracle Databaseの構成」に説明されているベスト・プラクティスを基盤としています。
この章には、次の項目が含まれます。
Data Guardは、データの可用性および保護のために最適化されたOracleソリューションです。このソリューションは、高可用性および障害回復を提供するための、完全なOracleデータベースの簡潔かつ高速で信頼性も高い一方向のレプリケーションに優れています。Data Guardは、計画外の停止、本番前のテスト、および計画済のメンテナンスなどに対応する各種のデプロイメント・オプションを備えています。Active Data Guardは、Data Guard基本機能に対する拡張機能で、同期化されたフィジカル・スタンバイ・データベースへの読取り専用ワークロードの本番オフロード、破損ブロックの自動修復、および高速増分バックアップのオフロードが可能になります。
Data Guardの中心機能は高可用性とデータ回復です。Data Guardの設計原則は簡潔性、高パフォーマンスおよびアプリケーション透過性です。
Data Guardはレプリケーション・ソリューションとして全機能を備えているわけではありません。マルチマスター・レプリケーション、データベースのサブセットの詳細レプリケーション、多対1レプリケーション・トポロジ、およびデータ統合などの高度なレプリケーション要件については、Oracle GoldenGateが推奨されるソリューションです。Oracle GoldenGateは、計画済のメンテナンスに伴う停止時間の短縮や、異機種プラットフォームの移行などの追加オプションも備えています。
ユーザー要件によって最も効率的に使用できるソリューションは異なり、Data Guardの単独使用、Oracle GoldenGateを補助的に利用したData Guardの使用、あるいはOracle GoldenGateの単独使用となります。
Data GuardとOracle GoldenGateの詳細は、次のWebサイトでOracle Active Data GuardとOracle GoldenGateに関する製品の技術資料を参照してください。
http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html
表9-1に、ユーザー要件に適したData Guardデプロイメント・オプションの概要を示します。複数の要件に対応するため、オプションを2つ以上組み合せて使用する場合もあります。この章では、各オプションを実装するためのベスト・プラクティスも示します。
表9-1 要件とData Guardデプロイメント・オプション
| 要件 | Data Guardデプロイメント・オプション |
|---|---|
|
データ消失ゼロの保護とOracleデータベースの可用性 |
Data Guardの「最大保護」または「最大可用性」(SYNC転送)とREDO Apply(フィジカル・スタンバイ) |
|
ほとんどゼロのデータ消失(一桁の秒数)とOracleデータベースの可用性 |
Data Guardの「最大パフォーマンス」(ASYNC転送)とREDO Apply(フィジカル・スタンバイ) |
|
HAに対するローカルのデータ損失ゼロのスタンバイによるトポロジと、Oracleデータベースに対する地理的災害の回復用のリモート非同期スタンバイを含む、マルチサイトの保護 |
マルチスタンバイData Guard構成とREDO Apply |
|
可能なかぎり最速のデータベース・フェイルオーバー |
自動的な障害検出およびデータベース・フェイルオーバーのための、Data Guardファスト・スタート・フェイルオーバーとOracle Data Guardブローカの併用。新規本番データベースに付属するクライアント・アプリケーションの自動フェイルオーバーは、Oracle Fast Application Notification (FAN)およびOracleクライアント・フェイルオーバーのベスト・プラクティスを使用して実装されます。 詳細は、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Data Guard 11gリリース2のクライアント・フェイルオーバーのベスト・プラクティス』を参照してください。 |
|
同期化されたスタンバイ・データベースへの、読取り専用問合せのオフロードおよび高速増分バックアップ。アプリケーションおよびユーザーに透過的な、スタンバイ・データベースの使用による破損ブロックの自動修復 |
Active Data Guard。Active Data Guardは、(1) Oracle Database Enterprise Editionのオプション・ライセンスとしてスタンドアロンで、または(2) Oracle GoldenGateライセンスへの同梱として、購入できます。 |
|
本番前のテスト |
スナップショット・スタンバイ。スナップショット・スタンバイは、プライマリ・データベース・トランザクションとは別に、テストおよびその他の読取り/書込み操作のために一時的に読取り/書込みがオープンされているフィジカル・スタンバイ・データベースです。スナップショット・スタンバイは、テストが終了すると、同期化されたスタンバイ・データベースに簡単に変換して戻されます。スナップショット・スタンバイは、Data Guard Redo Applyに組み込まれている機能で、Oracle Real Application Testingの理想的な補完機能です。 |
|
計画済のメンテナンス: WindowsからLinuxなどの特定のプラットフォーム移行、データ・センターの移動、システム・ソフトウェアまたはOracleデータベースのパッチ適用およびアップグレード |
Data Guardスイッチオーバー、計画済のロール移行、REDO Applyの使用。11.2.0.1以降のパッチを認定するためのRedo ApplyおよびStandby-First Patch Apply。SQL ApplyおよびData Guardのデータベース・ローリング・アップグレード(10.1以降)。11.1.0.7以降からのData GuardのTransient Logical Standby (Upgrades Made Easy)。 詳細は、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Data Guardのフィジカル・スタンバイ・データベースの使用によって容易になるデータベース・ローリング・アップグレード』を参照してください。 |
|
Oracleデータベース外部に存在するデータのデータ保護 |
実用では、Oracle Database File System (DBFS)を使用してOracleデータベースにオペレーティング・システムのファイル・システム・データを移動します。Data Guardは、他のOracleデータと同じ方法でDBFSデータを保護します。 オペレーティング・システム・ファイル内の格納が必要なデータは、Oracle ASM Cluster File System (Oracle ACFS)またはストレージのミラー化、およびData Guardを使用して、保護できます。 |
|
注意: Standby-First Patchを使用すると、プライマリ・データベースは以前のソフトウェア・リリースのまま、パッチを最初にフィジカル・スタンバイ・データベースに適用できます(この適用対象は特定のパッチ・タイプで、Oracleパッチ・セットおよびメジャー・リリース・アップグレードには適用されません。パッチ・セットおよびメジャー・リリースにはData GuardのTransient Logical Standbyメソッドを使用してください)。変更作業が終了したら、スタンバイ・データベースへのスイッチオーバーを実行します。フォールバックは必要な場合にスイッチオーバーすることです。詳細は、次のWebサイトのMy Oracle Support Note 1265700.1の『Oracle Patchの保証 - Data Guard Standby-First Patch適用』を参照してください。
|
|
関連項目:
|
Oracle Data GuardのZero Data Loss保護では、データが保護されている保証と最も簡潔なリカバリの両方が提供されます。この理由により、Zero Data Loss保護モードで、Oracle Data Guardの最大保護または最大可用性のどちらかが推奨されます。両方のモードがOracle Data Guardの同期REDO転送をデフォルトで使用しますが、フェイルオーバー時の動作の制御に使用されるルールセットには、考慮が必要な次のような差異があります。ただし、プライマリ・データベースとスタンバイ・データベース間のラウンドトリップ・ネットワーク待機時間が長すぎる場合、Oracle Data Guard同期REDO転送はプライマリ・データベースのパフォーマンスに影響を与える可能性があります(待機時間は距離とネットワークの正常な状態を測る機能です)。これが当てはまる場合(テストの実行は簡単です。DBAが保護モードおよび転送方法を動的に変更している可能性があります)は、Oracle Data Guardの最大パフォーマンス・モードを使用します。最大パフォーマンス・モードではOracle Data Guardの非同期転送サービスが使用され、ネットワーク待機時間に関係なく、プライマリ・データベースのパフォーマンスには影響を与えません。REDOボリュームに対応する十分な帯域幅がある環境では、最大パフォーマンス・モードの使用時、可能性のあるデータ損失は一桁の秒数内で測定されます。
現在のアプリケーションに適したデータ保護モードを決定するには、『Oracle Data Guard概要および管理』を参照してください。
保護モードのベスト・プラクティスは次のとおりです。
最大保護モード: このモードでは、プライマリ・データベースの障害発生時に、それが複数の障害(たとえば、プライマリとスタンバイ間のネットワークに障害が発生し、しばらくしてからプライマリに障害が発生する場合)であっても、データの損失がないことが保証されます。これを実施するため、REDOがディスクに固定されたことを少なくとも1つのData Guardスタンバイが確認応答するまで、プライマリ・データベース・トランザクションのコミット成功は伝達されません。このような確認応答がない場合、プライマリ・データベースでは保護されていないトランザクションのコミットは不可能で、データベースは一時停止して最終的にはシャットダウンします。プライマリ・データベースは操作可能でスタンバイ・データベースは操作不可能な場合に可用性を保つためのベスト・プラクティスは、最大保護構成で同期化されたスタンバイ・データベースを常に2つ以上保持することです。プライマリ・データベースの可用性は、少なくとも1つの同期化されたスタンバイ・データベースから確認応答を受け取っていれば、影響されません。
最大可用性モード: このモードでは、プライマリ・データベースで構成に影響を与える最初の障害が発生した場合に、データ損失は起こらないことが保証されます。 前述の保護モードとは異なり、最大可用性モードはスタンバイ・データベースからの確認応答に対してNET_TIMEOUTの最大秒数を待機します。その後、コミット成功をアプリケーションに伝達して、次のトランザクションに移動します。プライマリ・データベースの可用性(つまり保護モードの名前と同じ)は、スタンバイとの通信ができない場合(たとえば、スタンバイまたはネットワークの停止が原因の場合)でも、影響を受けません。Oracle Data Guardは引き続きスタンバイにpingを送信し、可能になったら自動的に接続を再確立して、スタンバイ・データベースを再同期化します。ただし、プライマリとスタンバイが分岐した期間中にデータ損失が発生し、これはプライマリ・データベースに影響を与える二次障害になります。このような理由から、保護レベルを監視(Enterprise Manager Grid Controlの使用が最適)して、プライマリとスタンバイ間の通信の遮断は、二次障害が発生する前に迅速に解決することがベスト・プラクティスとなります。
最大パフォーマンス・モード(デフォルト・モード): このモードでは、プライマリ・データベースのパフォーマンスまたは可用性に影響を与えない範囲で最高レベルのデータ保護が提供されます。このモードでは、トランザクションのリカバリに必要なREDOデータがプライマリ・データベースにあるローカルのオンラインREDOログに書き込まれると、即座にそのトランザクションのコミットが許可されます(スタンバイ・データベースが存在しなかった場合と同じ動作)。Oracle Data Guardは、ローカルのオンラインREDOログ書込みと非同期的なプライマリ・ログ・バッファからスタンバイ・データベースに直接、REDOを転送します。スタンバイの確認応答を待機することはありません。最大可用性モードと同様、保護レベルを監視(Enterprise Manager Grid Controlの使用が最適)して、プライマリとスタンバイ間の通信の遮断は、二次障害が発生する前に迅速に解決することがベスト・プラクティスとなります。
|
関連項目: Data Guardの保護モードの詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
Oracle Data GuardのREDO転送サービスを計画および実装するための、上位レベルにおけるREDO転送ベスト・プラクティスは次のようになります。
プライマリ・データベースおよびスタンバイ・データベース間の同期の程度を高くする場合は、SYNC REDO転送モードを使用します。データ損失ゼロの保護にはSYNC REDO転送を使用します。ここではネットワーク待機時間によって引き起こされた影響をパフォーマンス・サービス・レベルが許容できます。
プライマリ・データベースへの影響は最小限に抑えながらも、同期の程度を低くする場合は、ASYNC REDO転送モードを使用します。データ損失ゼロの保護が不要なときや、ネットワーク待機時間によって引き起こされたパフォーマンスの影響でSYNCの使用が非現実的になったときに、ASYNC REDO転送を使用します。
9.2.2項「ネットワーク構成案に関するパフォーマンスの評価」に記述されているベスト・プラクティスに従って、ネットワーク・スループットを最適化します。
ネットワーク構成案と現在、または将来のピークREDO速度に関するパフォーマンス評価を実行することをお薦めします。プライマリ・データベースとスタンバイ・データベース間のネットワークに対する影響と、プライマリ・データベースのスループットに対する影響を把握する必要があります。プライマリ・データベースとスタンバイ・データベース間のネットワークは2つのデータベースの同期を維持するのに不可欠の要素であるため、そのインフラストラクチャは次の特徴を有している必要があります。
最大のREDO生成速度に対応できる十分な帯域幅
SYNC転送を使用する場合、プライマリ・データベースのパフォーマンスへの影響を減らすために、待機時間が最小限であること
ネットワーク冗長性のための複数のネットワーク・パス
専用のネットワーク接続を使用する構成では、必要な帯域幅は、プライマリ・データベースの最大REDO速度とネットワーク効率により決定されます。データ保護モードによっては、他の推奨プラクティスとパフォーマンス上の考慮事項があります。最大保護モードと最大可用性モードでは、SYNC転送を使用する必要があります。
最大パフォーマンス保護モードでは、ASYNC REDO転送を使用します。データ損失が許容できるときや、ネットワーク待機時間によって引き起こされたパフォーマンスの影響でSYNCの使用が非現実的になったとき(データ損失ゼロの保護にはSYNC REDO転送を使用)に、ASYNC REDO転送を使用します。
ASYNC転送モードと異なり、SYNC転送モードでは、発生するネットワーク待機時間のために、プライマリ・データベースのパフォーマンスに影響が出る可能性があります。距離とネットワーク構成は、待機時間に直接影響します。待機時間が長いと、潜在的なトランザクション・スループットが低下し、レスポンス時間が迅速化する可能性があります。ネットワーク構成、リピータの数、プロトコル変換のオーバーヘッド、およびルーターの数も、ネットワーク待機時間とトランザクション・レスポンス時間に全体的な影響を与えます。
Data Guardには、次の構成ベスト・プラクティスを使用します。
Data Guard構成の作成、管理および監視には、Oracle Data Guardブローカを使用します。Oracle Data Guardブローカの使いやすいインタフェースである、Oracle Enterprise ManagerのData Guard管理ページ(ブローカのGUI)およびDGMGRLと呼ばれる Data Guardコマンドライン・インタフェースを使用すると、すべてのData Guard管理操作をローカルまたはリモートで実行できます。
ブローカのインタフェースによって利便性が向上し、Data Guard構成の管理と監視が集中化されます。ブローカはOracle DatabaseのEnterprise EditionおよびPersonal Editionの機能として選択可能で、OracleデータベースおよびOracle Enterprise Managerとも統合されます。
Oracle Data Guardブローカを使用するメリットは、次のとおりです。
障害時の保護の強化。
Oracle Real Application Clusters (Oracle RAC)データベースでの高可用性とスケーラビリティ。
Data Guard構成の自動作成。
追加のスタンバイ・データベースの簡単な構成。
管理の簡素化、集中化および拡張。
スイッチオーバー操作とフェイルオーバー操作の簡略化。
組込みの監視、アラートおよび制御メカニズム。
アプリケーションに対する透過性。
|
関連項目: Data Guard Brokerの構成要件の詳細は、『Oracle Data Guard Broker』を参照してください。 |
Recovery Manager(RMAN)ユーティリティを使用して、フィジカル・スタンバイ・データベースの作成プロセスを簡略化することをお薦めします。
スタンバイ・データベースは、プライマリ・データベースのバックアップから作成することも、ネットワーク経由で作成することもできます。
プライマリ・データベースのバックアップからスタンバイ・データベースを作成するには、RMANのDUPLICATE TARGET DATABASE FOR STANDBYコマンドを使用します。
スタンバイ・ホスト上のサーバー・セッションから、データベースを完全にリカバリするのに必要なアーカイブREDOログ・ファイルにアクセスできる場合、プライマリ・データベースの任意のバックアップ・コピーを使用してフィジカル・スタンバイ・データベースを作成できます。SET UNTILコマンドを実行する場合を除いて、RMANは最新のデータファイルをリストアします。
既存のデータベース・バックアップがスタンバイ・システムにアクセスできない場合は、RMANのFROM ACTIVE DATABASEオプションを使用して、ネットワーク経由でスタンバイ・データベースを作成します。
RMANは、プライマリ・データベースからスタンバイ・データベースへ直接データファイルをコピーします。プライマリ・データベースはマウントまたはオープンされている必要があります。
アクティブ複製とバックアップ・ベース複製のいずれかを選択する必要があります。FROM ACTIVE DATABASEオプションを指定しなかった場合、RMANはバックアップ・ベースの複製を実行します。ネットワーク経由でのスタンバイ・データベース作成には、次の利点があります。
最初にプライマリ・データベース上でバックアップを実行する手順を終えていなくても、ネットワーク経由で直接、REDOデータをリモート・ホストに転送できます。(リストアには、プライマリ・データベースへのバックアップのローカル保存、ネットワーク経由でのバックアップの転送、スタンバイ・データベースへのバックアップのローカル保存、およびスタンバイ・データベース上でのバックアップのリストアなど、複数の手順が必要です。)
アクティブ複製では、Oracle ASMから実行中のデータベースをバックアップし、そのバックアップをネットワーク経由でホストにリストアし、Oracle ASMに直接ファイルを配置することができます。
この機能以前のリストアでは、プライマリをバックアップしてそのバックアップ・ファイルをプライマリ・ホスト・ファイル・システムにコピーし、そのバックアップ・ファイルをネットワーク経由で転送し、バックアップ・ファイルをスタンバイ・ホスト・ファイル・システムに配置してから、Oracle ASMにファイルをリストアする手順が必要でした。
|
関連項目:
|
プライマリ・データベースとスタンバイ・データベースの両方でフラッシュバック・データベースを有効化すると、元のプライマリ・データベースが損害を受けていなかった場合に、フェイルオーバー後に元のプライマリ・データベースを新しいスタンバイ・データベースとして復元できます。フラッシュバック・データベースが有効であれば、スイッチオーバー・プロセスで障害が発生した場合でも、そのプロセスを簡単に元に戻すことができます。詳細は、5.1.4項「フラッシュバック・データベースの有効化」を参照してください。
プライマリ・データベースをFORCE LOGGINGモードで運用すると、データベースのすべてのデータ変更がログに記録されます。FORCE LOGGINGモードにより、スタンバイ・データベースとプライマリ・データベースとの一貫性が維持されます。NOLOGGING操作によるロード・パフォーマンスが必要なためにこの設定を使用できない場合は、対応するフィジカル・スタンバイ・データファイルを後で確実に同期する必要があります。フィジカル・スタンバイ・データファイルを同期するには、プライマリ・データベースから作成された増分バックアップを適用するか、NOLOGGING操作後に取得されたプライマリ・データファイルのバックアップを使用して関連するスタンバイ・データファイルを置き換えます。ファイル転送の前に、フィジカル・スタンバイ・データベースでREDO Applyを停止する必要があります。
ALTER DATABASE FORCE LOGGING文を発行すると、強制ロギングを即座に有効化できます。FORCE LOGGINGを指定した場合、Oracleは、ログに記録されていない進行中のすべての操作が終了するまで待機します。
|
関連項目:
|
各データベースは高速リカバリ領域を使用します。
プライマリ・データベース・インスタンスは、リモートのただ1つの適用インスタンスにアーカイブされること。
表9-2に、SQL*Plusを通じてData Guard構成を管理する際の堅牢なアーカイブ計画の推奨事項を示します。Oracle Data Guardブローカで構成を管理する場合、次のすべての項目が自動的に処理されます。
表9-2 アーカイブの推奨事項
次に、フィジカル・スタンバイ・データベースと通信するプライマリ・データベースに推奨される初期化パラメータを示します。最大保護モードで稼働する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
高速リカバリ領域は、クラスタ内の任意のノードにアクセス可能である必要があります。また、自動ストレージ管理(Oracle ASM)、クラスタ・ファイル・システム、グローバル・ファイル・システム、高可用性ネットワーク・ファイル・システム(HA NFS)などの共有ファイル・システム・テクノロジを使用する必要があります。クラスタ内の任意のノードに手動でファイル・システムをマウントすることも簡単にできます。すべてのアーカイブREDOログ・ファイルにすべてのノードからアクセスできる必要があるため、これはリカバリにとって必須の設定です。
スタンバイ・データベース・ノードでは、REDOを適用しているノードに障害が発生して適用サービスを再起動できない場合、異なるノードからリカバリを実行する必要があります。この場合、異なるノードに存在する既存のスタンバイ・インスタンスのいずれかを使用して、管理リカバリを開始できます。スタンバイ・アーカイブREDOログ・ファイルにアクセスできない場合は、異なるノードの新規管理リカバリ・プロセス(MRP)により、プライマリ・ノードからの直接取得を行うFALサーバーを通じてアーカイブREDOログ・ファイルがフェッチされます。
ハードウェア・ベンダーの共有ファイル・システム・テクノロジを構成する場合は、パフォーマンスと可用性に対する影響を確認してください。この計画を採用する前に、次の項目を調査します。
ノード障害の数にかかわらず、任意のノードから共有ファイル・システムにアクセスできますか。
共有ファイル・システムを実装することによるパフォーマンスへの影響はどの程度ですか。
インターコネクト・トラフィックに対する影響はありませんか。
スタンバイREDOログは、可用性とパフォーマンスを向上するために、すべてのプライマリ・データベースとスタンバイ・データベースで構成する必要があります。
各REDOログ・スレッド(OracleRACデータベース・インスタンスと関連付けられているスレッド)、スタンバイREDOログ数 = REDOログ・グループ数 + 1
追加のスタンバイREDOログにより、スタンバイ・データベースがスタンバイREDOログを待機する可能性がなくなります。たとえば、プライマリ・データベースが2つのインスタンス(スレッド)を持ち、各スレッドが3つのオンライン・ログ・グループを持つ場合、プライマリ・データベースおよび各スタンバイ・データベースに8つのスタンバイREDOログを事前構成する必要があります。さらに、プライマリ・データベースまたはスタンバイ・データベースが対称なReal Application Clusterでない場合(たとえば、2ノードのスタンバイOracle RACクラスタに対して8ノードのプライマリOracle RACクラスタ)であっても、プライマリ・データベースおよびスタンバイ・データベースで同数のスタンバイREDOログを持つ必要があり、すべてのスレッドを示す必要があります。
例9-1の文では、スレッド当たり3つのスタンバイ・ログを作成します。
例9-1 スタンバイ・ログ・メンバーの作成
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 1G;SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 SIZE 1G;
スタンバイREDOログを作成する際には、次の追加のガイドラインを考慮してください。
プライマリ・データベース上とスタンバイ・データベース上に、同じ数のスタンバイREDOログを作成します。
プライマリ・データベースとスタンバイ・データベースの両方で、すべてのオンラインREDOログとスタンバイREDOログのサイズが同じになるように作成します。
最初に使用できるASM高冗長性ディスク・グループにスタンバイREDOログを作成するか、ログが外部ストレージ冗長性を使用して保護されていることを確認します。
Oracle RAC環境では、スタンバイREDOログは共有ディスクに作成します。
Oracle RAC環境では、スタンバイREDOログが例9-1のように作成されたときにスレッドを割り当てます。
スタンバイREDOログは多重化しないでください。
REDOログの数およびグループ番号を確認するには、次のようにV$LOGビューを問い合せます。
SQL> SELECT * FROM V$LOG;
ALTER DATABASE ADD STANDBY LOGFILE THREAD文の結果を確認するには、次のようにV$STANDBY_LOGビューを問い合せます。
SQL> SELECT * FROM V$STANDBY_LOG;
|
関連項目: スタンバイREDOログの管理については、『Oracle Data Guard概要および管理』を参照してください。 |
Data Guard転送とネットワーク構成のベスト・プラクティスには次のようなものがあります。
ほとんどの場合、LOG_ARCHIVE_MAX_PROCESSESのデフォルトで対応できます。ただし、複数のスタンバイ・データベースが存在するData Guard構成では、アーカイブ・プロセスの数を増やすことが必要な場合があります。LOG_ARCHIVE_MAX_PROCESSES初期化パラメータの値は、すべてのリモート宛先数より少なくとも1大きくする必要があります。高可用性環境でLOG_ARCHIVE_MAX_PROCESSESパラメータを設定する場合は、次の式を使用します。
LOG_ARCHIVE_MAX_PROCESSES = sum(remote_destinations) + count(threads)
これらのパラメータ設定は、本番環境での初期設定の評価およびテスト後に、状況に応じて調整できます。
|
関連項目: アーカイブ・プロセスの数の調整の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
ネットワーク構成と最大ネットワークREDO速度を設定するには、次のことを行います。
TCP送信/受信バッファ・サイズの適切な構成
特に待機時間が長い高帯域のネットワークで、高いネットワーク・スループットを達成する場合、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より大きい値を設定する必要があります。
送信および受信バッファ・サイズは、計算した値か10MB(10,485,760バイト)のどちらか大きい方の値に設定します。たとえば、帯域幅が622Mビットで待機時間が30ミリ秒の場合、RECV_BUF_SIZEおよびSEND_BUF_SIZEパラメータの最小サイズは、622,000,000 / 8 x 0.030 = 2,332,500バイトのように計算します。次に、BDPを2,332,500 x 3のように乗算すると合計は6,997,500になります。
この例では、初期化パラメータを次のように設定します。
RECV_BUF_SIZE=10485760
SEND_BUF_SIZE=10485760
SDUサイズの増加
Oracle Net Servicesでは、セッション・データ・ユニット(SDU)に関するOracle Net設定を調整することでデータ転送を制御できます。オラクル社の内部テストによれば、SDUを最大値の65535に設定すると、SYNC転送のパフォーマンスが向上する可能性があります。SDUは、ローカル・ネーミング構成ファイル(TNSNAMES.ORA)およびリスナー構成ファイル(LISTENER.ORA)のSDUパラメータを使用して接続単位ごとに設定するか、SQLNET.ORAファイルのDEFAULT_SDU_SIZEプロファイル・パラメータですべてのOracle Net接続を対象に設定します。
ASYNC転送では新規ストリーミング・プロトコルが使用されるため、SDUサイズをデフォルトから増やしてもパフォーマンス上の利点はないので注意してください。
|
関連項目: SDUおよびDEFAULT_SDU_SIZEパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。 |
TCP.NODELAYのYESの設定
TCPプロトコル・スタックでのバッファ・フラッシングによる遅延を回避するため、プライマリ・システムとスタンバイ・システムの両方でSQLNET.ORAファイルのTCP.NODELAYをYESに設定してTCP Nagleアルゴリズムを無効化します。
|
関連項目: TCP.NODELAYパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。 |
REDO転送圧縮を使用する場合の決定
Oracle Database 11gリリース2 (11.2.0.2)のREDO転送圧縮は、REDOギャップを解消中の際にREDOデータのみを圧縮することに制限されなくなりました。転送先で圧縮が有効になっている場合は、その宛先に送信されるすべてのREDOデータが圧縮されます。
一般に、圧縮のメリットがきわだつのは、 低帯域ネットワーク経由で使用する場合です。ネットワーク帯域幅が増大すると、メリットは減少します。Data Guard環境でREDOを圧縮すると、次の場合にメリットがあります。
圧縮処理に十分なCPUリソースを利用できる場合
データベースREDO速度が、低帯域ネットワークのために制限されている場合
圧縮を有効にする前に、利用できるCPUリソースを評価し、圧縮を有効にできるかどうか判断します。圧縮の有効化の詳細は、次のWebサイトのMy Oracle Support Note 729551.1の『Data Guard環境のREDO転送圧縮』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=729551.1
フィジカル・スタンバイ・データベース(およびメディア・リカバリ)のREDO Apply割合を改善するには、次のことを行います。
|
関連項目: 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Active Data Guard 11gのベスト・プラクティス(Redo Applyのベスト・プラクティスを含む)』を参照してください。 |
スタンバイREDOログ・ディレクトリとアーカイブREDOログ・ディレクトリのI/Oレートを測定します。転送されたREDOがスタンバイ・データベースに同時に書き込まれると、I/Oが飽和状態となってREDO読取り速度が低下する可能性があります。リカバリ速度全体はREDOを読み取ることのできる速度によって常に制限されるため、REDO読取り速度が必要とされるリカバリ速度を超えていることを確認します。
リカバリ速度の履歴を取得するには、次の問合せを使用してリカバリ進行状況の履歴を表示します。
SELECT * FROM V$RECOVERY_PROGRESS;
ACTIVE APPLY RATEがプライマリ・データベースでの最大REDO生成速度を超えているか、プライマリ・データベースでの平均生成速度の2倍を超えている場合、チューニングは必要ありません。それ以外の場合は、次のチューニング・ヒントに従ってください。プライマリ・データベースのREDO生成速度は、Enterprise Managerで監視するか、REDO SIZE統計のAWRレポートから抽出することが可能です。CHECKPOINT TIME PER LOGが10秒を超えている場合は、I/Oとチェックポイントのチューニングを調査します。
DB_BLOCK_CHECKSUM=FULLおよびDB_BLOCK_CHECKING=MEDIUMまたはFULLの設定Redo Applyのパフォーマンスは、ほとんどのアプリケーションのREDO生成速度に対応するために十分な速度である必要がありますが、DB_BLOCK_CHECKINGを一時的に無効化して、リカバリを高速化することができます。DB_BLOCK_CHECKINGを無効化する場合、My Oracle Supportのノート1302539.1の説明に従って、メモリー内ブロックのセマンティク・チェックを無効化します。
|
注意: DB_BLOCK_CHECKINGパラメータで保護できなかったブロック破損をチェックするには、次の方法を使用します。
|
スタンバイ・データベースでDB_LOST_WRITE_PROTECTパラメータをFULLに設定し、I/Oサブシステムで失われた書込みをOracleで検出できるようにします。OLTPアプリケーションにおいてRedo Applyに対する影響はごくわずかであり、通常は5%未満です。
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のインストールおよび使用方法の詳細は、次のWebサイトのMy Oracle Support Note 454848.1の『11gでのStandby Statspackのインストールおよび使用』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=454848.1
Active Data Guardオプションのライセンスがない場合、スタンバイ・データベースのV$SYSTEM_EVENT、V$SESSION_WAITおよびV$EVENT_HISTOGRAMを問い合せて、最大のTIME_WAITED値を調べることで、上位のシステムおよびセッション待機イベントを特定できます。場合によっては、ある一定期間を正確に評価するため、問合せ結果の複数のスナップショットを取得して手動で差異を抽出する必要があります。
リカバリで多くのREDOデータを効率的に適用する場合、システムはI/Oバウンドとなるため、I/O待機が発生することはシステムにとって妥当な動作です。パラレル・リカバリ・コーディネータおよびスレーブに関連する待機イベントの大部分は、コーディネータに適用されます。スレーブは、変更を適用するか(CPUでのクロッキング)、コーディネータから変更が渡されるのを待機します。
通常、適切にチューニングされたシステムでは、上位の待機イベントは、db file parallel writeの後にcheckpoint completedが続きます。db file parallel writeが上位の待機イベントではない場合のチューニング・アドバイスは、後述の表を参照してください。表9-3と表9-4に、データベースの待機イベントを示します。
表9-3 パラレル・リカバリ・コーディネータの待機イベント
| 待機名 | 説明 | チューニング |
|---|---|---|
|
|
パラレル・リカバリ・コーディネータは、オンラインREDOログまたはアーカイブREDOログからのI/Oを待機しています。 |
アーカイブ・ログまたはオンラインREDOログが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。 |
|
|
このイベントは、すべての読取りバッファがスレーブによって使用されていることを示し、通常はリカバリ・スレーブがコーディネータに遅れていることを示します。 |
データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。 |
|
|
パラレル・リカバリ・コーディネータは、リカバリ・スレーブがバッファを解放するのを待機しています。このイベントも、リカバリ・スレーブがコーディネータに遅れていることを示します。 |
データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。 |
|
|
パラレル・リカバリ・コーディネータは、ファイルの自動拡張などによるファイルのサイズ変更が終了するのを待機しています。 |
データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。 |
|
|
コーディネータは、同期制御メッセージをすべてのスレーブに送信済で、すべてのスレーブからの応答を待機しています。 |
これはチューニング不可能なイベントです。 |
リカバリ・スレーブ・イベントを処理する場合、起動しているスレーブの数を把握することが重要です。任意のリカバリ・スレーブ・イベントの待機時間をスレーブの数で割ります。表9-4に、パラレル・リカバリ・スレーブの待機イベントを示します。
表9-4 パラレル・リカバリ・スレーブの待機イベント
| 待機名 | 説明 | チューニング |
|---|---|---|
|
|
パラレル・リカバリ・スレーブは、コーディネータから変更が転送されるのを待機しています。このイベントは、実質的にはリカバリ・スレーブのアイドル・イベントです。リカバリ・スレーブが使用するCPU時間を特定するには、このイベントの経過時間を起動済スレーブの数で割り、その値を合計経過時間から引きます。この値には、多少の待機時間も含まれるため、近似値となります。 |
アーカイブ・ログまたはオンラインREDOログが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。 |
|
|
パラレル・リカバリ・スレーブ(またはシリアル・リカバリ・プロセス)は、同期データ・ブロックのバッチ読取りが完了するのを待機しています。 |
データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。 |
|
|
リカバリは、チェックポイントの完了を待機しており、REDO Applyは現時点で変更を適用していません。 |
データファイルが存在するASMディスク・グループのI/O帯域幅をチューニングするか、拡大します。 また、 |
|
|
パラレル・リカバリ・スレーブは、バッチ・データ・ブロックI/Oを待機しています。 |
データファイルが存在するASMディスク・グループの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帯域幅にある場合、関連するOracle ASMディスク・グループに別のディスクを追加します。この原因がバスやコントローラのボトルネック、またはその他のI/Oボトルネックではないことを確認します。スタンバイREDOログからの読取りI/Oレートは、期待されるリカバリ速度を超えている必要があります。
過剰なスワッピングまたはメモリー・ページングが発生していないかどうかをチェックします。
リカバリ中にリカバリ・コーディネータまたはMRPがCPUバウンド状態にならないことを確認します。
次のいずれかの目的がある場合は、スタンバイ・データベースを複数デプロイすることをお薦めします。必要に応じて複数のスタンバイ・データベースをそのような目的に使用する場合も、プライマリ・フェイルオーバー・ターゲットの役割を果すスタンバイ・データベースを1つ以上確保しておきます。
フェイルオーバー後に継続保護を提供する場合
複数スタンバイ構成で、ロール移行のターゲットでないスタンバイ・データベース(バイスタンダ・スタンバイ・データベース)は、新しいプライマリ・データベースから受信したREDOデータを自動適用します。
同期通信限界を超える広範囲の地理的災害に対する保護も提供しつつ、データ損失ゼロの保護を実現する場合
たとえば、同期的にREDOデータを受信するスタンバイ・データベースがプライマリから200マイル遠方、非同期でREDOデータを受信する2番目のスタンバイ・データベースが1,500マイル遠方に位置する場合です。
ローリング・アップグレード・プロセスによって障害保護を維持しつつ、ローリング・データベース・アップグレードを実行する場合
障害時リカバリ保護を維持しつつ、テストなどの非定型作業を実行する場合
複数のスタンバイ・データベースのベスト・プラクティスの使用
『Oracle Database高可用性概要』には、複数のスタンバイ・データベースのアーキテクチャが、実質的にどの程度単一のスタンバイ・データベースのアーキテクチャと同じであるかが記載されています。したがって、この項で説明する複数のスタンバイ・データベースの実装における構成ガイドラインは、フィジカルおよびロジカル・スタンバイ・データベースの既存のベスト・プラクティスを補完するものです。
複数のスタンバイ・データベースをデプロイする場合、次のベスト・プラクティスを使用します。
Oracle Data Guardブローカ(第12章「高可用性の監視」で説明)を使用して、構成を管理し、ロール移行を実行します。ただし、SQL*Plus文を使用する場合のベスト・プラクティスは、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『複数のスタンバイ・データベースのベスト・プラクティス』を参照してください。
フェイルオーバー後にデータベースを復元することを唯一の目的としてフラッシュバック・データベースを使用する場合、DB_FLASHBACK_RETENTION_TARGETの最低限の推奨値は120分です。フェイルオーバー後、バックアップまたはプライマリ・データベース(ファスト・スタート・フェイルオーバーの使用時)からスタンバイ・データベース全体を再作成するかわりに、フラッシュバック・データベースを使用して旧プライマリをスタンバイとして迅速に復元する場合は、UNDO_RETENTIONおよびDB_FLASHBACK_RETENTION_TARGET初期化パラメータを必ず120以上に設定して、長時間の停止後も復元が可能であるようにします。スタンバイでは、フラッシュバック・バリアが30分ごとに発行されることは保証されません。これはプライマリ上にあるためです。したがって、フラッシュバック・データベースをスタンバイで有効化する際、DB_FLASHBACK_RETENTION_TARGETは120以上に設定する必要があります。プライマリとスタンバイは一致する必要があるため、プライマリにも同じことが適用されます。
ロジカル・スタンバイ・データベースが含まれる構成でサプリメンタル・ロギングを有効化します。フィジカル・スタンバイ・データベースとロジカル・スタンバイ・データベースの両方を含んだ構成を作成する場合、次の状況では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属性を使用します。
|
関連項目:
|
適切な計画と実行に基づいたData Guardのロール移行により、効果的に停止時間を最小化し、ビジネスへの影響を最小限に抑えながらデータベース環境をリストアすることが可能になります。フィジカル・スタンバイ・データベースを使用する場合、MAAのテスト結果では、Oracle Data Guard 11gによるスイッチオーバーとフェイルオーバーの時間は数秒間に短縮されました。この項では、スイッチオーバーとフェイルオーバーのベスト・プラクティスについて説明します。
Oracle Data Guardにより実行されるデータベース・スイッチオーバーは、スタンバイ・データベースとプライマリ・データベースの間でロールを切り替えるための一連の手順を含む計画された移行操作です。スイッチオーバー操作に成功すると、スタンバイ・データベースがプライマリ・ロールを引き継ぎ、プライマリ・データベースがスタンバイ・データベースとなります。通常、スイッチオーバーはわずか数秒から数分で完了します。データベースのロール管理の分野では、スイッチバックという用語も使用されることがあります。スイッチバックは、スイッチオーバー操作の後にデータベースのロールを元の状態に戻す操作です。
Data Guardでは、次の方法により動的にロールを変更できます。
Oracle Enterprise Managerの使用
Oracle Data GuardブローカのDGMGRLコマンドライン・インタフェースの使用
SQL文の発行(14.2.1.3項「Data Guardスイッチオーバーの実行方法」を参照)
|
関連項目: Oracle Enterprise ManagerまたはOracle Data GuardブローカのDGMGRLコマンドライン・インタフェースを使用してデータベース・スイッチオーバーを実行する方法の詳細は、『Oracle Data Guard Broker』を参照してください。 |
スイッチオーバー処理を最適化するには、スイッチオーバーを実行する前に次の手順を実行します。
ALTER SYSTEM KILL SESSION SQL*Plusコマンドを使用して、切断可能なすべてのセッションを切断します。
NODELAYキーワードを使用してスタンバイ・データベースのログ適用サービスを停止および再起動し、指定されている適用遅延をすべて取り消します。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE NODELAY;
V$ARCHIVE_DESTビューのDELAY_MINS列を問い合せることによって、プライマリ・データベース上の現在の遅延設定を表示することができます。
Oracle RAC環境のフィジカル・スタンバイ・データベースについては、各プライマリ・データベースおよびスタンバイ・データベースに対して、必ず、アクティブなインスタンスが1つのみ存在するようにします。
スイッチオーバー処理を最適化するには、リアルタイム適用を使用するようにスタンバイ・データベースを構成し、可能な場合は、スイッチオーバー操作の前にデータベースが確実に同期されるようにします。
スイッチオーバーを可能なかぎり高速化するには、受信と同時にREDOデータがスタンバイ・データベースに適用されるように、リアルタイム適用を使用します。この場合、スタンバイ・データベースが、スイッチオーバー操作の前にプライマリ・データベースと同期化されて、スイッチオーバー時間が最小限に抑えられます。リアルタイム適用を有効化するには次のSQL*Plus文を使用します。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT USING CURRENT LOGFILE;
フィジカル・スタンバイ・データベースの場合は、アーカイバ・プロセス(ARCn)の数を、リモート・アーカイブとローカル・アーカイブの両方に必要な最小の値に減らします。追加のアーカイバ・プロセスは、停止時間を増加させる可能性があり、その結果スイッチオーバーの実行にかかる合計時間も増加します。スイッチオーバーが完了したら、追加のアーカイバ・プロセスを再有効化できます。
LOG_FILE_NAME_CONVERT初期化パラメータをその環境で有効な任意の値に設定するか、不要な場合はNULLに設定します。
スイッチオーバーの一環として、スタンバイ・データベースでは、プライマリ・データベースとしてオープンする前にスタンバイ・データベース上のオンラインREDOログ・ファイルを消去する必要があります。I/Oの完了に要する時間により、スイッチオーバーの合計時間が大幅に増加する可能性があります。LOG_FILE_NAME_CONVERTパラメータを設定すると、MRPプロセスの最初の起動時に、スタンバイ・データベースからオンラインREDOログを事前に作成することができます。スタンバイ・データベース上でSQL*PlusのALTER DATABASE CLEAR LOGFILE文を発行することで、空のオンラインREDOログを事前に作成することもできます。
|
関連項目: Data Guard Physical Standby (11.2.0.2)のスイッチオーバー・ベスト・プラクティス用のサポート・ノートは次のとおりです。
|
フェイルオーバーは通常、プライマリ・データベースが利用できなくなって、妥当な期間内でサービスに復帰させる可能性がない場合にのみ使用されます。フェイルオーバーの際、1つのサイトのプライマリ・データベースがオフラインにされ、スタンバイ・データベースがプライマリ・データベースとしてオンラインにされます。
Data Guardのフェイルオーバー・プロセスは、ファスト・スタート・フェイルオーバーを使用して完全に自動化するか、ユーザーが手動で起動します。ファスト・スタート・フェイルオーバーを使用して、手動操作を必要とするプロセスに固有の不確実性を排除することをお薦めします。ファスト・スタート・フェイルオーバーでは、システム停止が検出されてから数秒以内にフェイルオーバーが自動的に実行されます。
Data Guardフェイルオーバー・ベスト・プラクティスの詳細は、次のトピックを参照してください。
|
関連項目: Oracle Data Guardフェイルオーバー・ベスト・プラクティスの総合レビューは、次を参照してください。
|
フェイルオーバーには、手動フェイルオーバーとファスト・スタート・フェイルオーバーという2つの異なるタイプがあります。プライマリ・データベースに障害が発生した場合、管理者は手動フェイルオーバーを開始します。一方、Data Guardでは、一定の期間にわたり(ファスト・スタート・フェイルオーバーしきい値)プライマリ・データベースが使用不可能になると、ユーザーの操作なしで自動的にファスト・スタート・フェイルオーバーが開始されます。
表9-5にファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較を示します。
表9-5 ファスト・スタート・フェイルオーバーと手動フェイルオーバーの比較
| 比較ポイント | ファスト・スタート・フェイルオーバー | 手動フェイルオーバー |
|---|---|---|
|
メリット |
手動操作を極力使用せずに可用性を向上し、管理コストを削減できます。 |
フェイルオーバーの発生時期とターゲット・スタンバイ・データベースをユーザーが正確に制御できます。 |
|
フェイルオーバー・トリガー |
ファスト・スタート・フェイルオーバーが自動的に起動されるのは、次の場合です。
|
手動フェイルオーバーは、ユーザーによって開始され、スタンバイ・データベースをプライマリ・データベースに変換するための一連の手順を実行します。手動フェイルオーバーは、次のような計画外の停止が発生した場合に実行します。
|
|
管理 |
ファスト・スタート・フェイルオーバーの管理には、次のツールを使用します。
14.2.1.3項「Data Guardスイッチオーバーを実行する方法」を参照してください。 |
手動フェイルオーバーの実行には、次のツールを使用します。
13.2.2.3項「手動フェイルオーバー実行のベスト・プラクティス」を参照してください。 |
|
フェイルオーバー後の元のプライマリ・データベースのリストア |
ファスト・スタート・フェイルオーバーの後、Oracle Data Guardブローカは、構成への再接続時に元のプライマリ・データベースをスタンバイ・データベースとして自動的に再構成できます( |
手動フェイルオーバーの後、フォルト・トレランスを回復するために元のプライマリ・データベースをスタンバイ・データベースとして復元する必要があります。 |
|
フェイルオーバー後のバイスタンダ・スタンバイ・データベースのリストア |
Oracle Data Guardブローカにより、構成内のすべてのデータベースのロール移行が調整されます。 復元を必要としないバイスタンダは、新しいプライマリになれるスタンバイ・データベースとして利用できます。復元を必要とするバイスタンダは、オブザーバによって自動復元されます。 |
Oracle Data Guardブローカを使用する利点は、バイスタンダ・データベースのステータスが提供され、データベースを復元する必要があるかどうかが示されることです。SQL*Plus文を使用してフェイルオーバーを管理する場合、ステータス情報はすぐには利用できません。 13.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。 |
|
アプリケーション・フェイルオーバー |
Oracle Data Guardブローカは、フェイルオーバー後に、FAN/AQ (アドバンスト・キューイング)およびFAN/ONS (Oracle Notification Service)の通知を自動的に発行します。高速接続フェイルオーバーも構成されているクライアントは、それらの通知を使用して新しいプライマリ・データベースに接続することができます。 |
Oracle Data Guardブローカは、フェイルオーバー後に、FAN/AQ (アドバンスト・キューイング)およびFAN/ONS (Oracle Notification Service)の通知を自動的に発行します。高速接続フェイルオーバーも構成されているクライアントは、それらの通知を使用して新しいプライマリ・データベースに接続することができます。DB_ROLE_CHANGEシステム・イベントを使用して、ユーザー・アプリケーションによるプライマリ・データベース上のサービスの検索も支援できます。(これらのイベントは、ブローカが実行する手動フェイルオーバーでも利用できます。『Oracle Data Guard Broker』を参照してください。 |
フェイルオーバー処理を最適化するには、次のことを行います。
フェイルオーバー操作の完了後に障害が発生したプライマリ・データベースを復元するため、フラッシュバック・データベースを有効化します。必要な場合、フラッシュバック・データベースはポイント・イン・タイム・リカバリを容易にします。
ユーザー・エラーや論理破損が検出されたときに、受信と同時にREDOデータをスタンバイ・データベースに適用してデータベースを迅速に復元するため、フラッシュバック・データベースと組み合せてリアルタイム適用を使用します。
フェイルオーバー後もデータ保護を維持するために、複数のスタンバイ・データベースを構成することを検討します。
LOG_FILE_NAME_CONVERTパラメータを設定します。フェイルオーバーの一環として、スタンバイ・データベースでは、プライマリ・データベースとしてオープンする前にオンラインREDOログを消去する必要があります。このI/Oの完了に要する時間により、フェイルオーバーの合計時間が大幅に増加する可能性があります。LOG_FILE_NAME_CONVERTパラメータを設定すると、MRPプロセスの最初の起動時に、スタンバイによってオンラインREDOログが事前作成されます。スタンバイ・データベース上でSQL*PlusのALTER DATABASE CLEAR LOGFILE文を発行することで、空のオンラインREDOログを事前に作成することもできます。
ファスト・スタート・フェイルオーバーを使用します。Oracle Database 11gの稼働する環境で行ったMAAテストでは、Oracle Data Guardブローカとファスト・スタート・フェイルオーバーを使用したフェイルオーバーの実行により、可用性が大幅に向上しました。詳細は、9.4.2.3項「ファスト・スタート・フェイルオーバーのベスト・プラクティス」を参照してください。
フィジカル・スタンバイ・データベースの場合、次の作業を実行します。
読取り専用モードからREDO Apply(リカバリ)モードに移行する場合、データベースを再起動します。
(Oracle Database 11gリリース2より前のリリースで要求されたように)スタンバイ・データベースを再起動するのではなく、MOUNTED状態からOPEN状態に直接移行します。
REDO Applyのメディア・リカバリの最適化については、次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Oracle Data GuardのREDO Applyとメディア・リカバリ』を参照してください。
プライマリ・データベースで障害が発生した場合、ファスト・スタート・フェイルオーバーにより、指定されたスタンバイ・データベースに対して自動的に迅速で信頼性の高いフェイルオーバーが実行されるため、手動操作でフェイルオーバーを実行する必要はありません。ファスト・スタート・フェイルオーバーは、Oracle Data Guardブローカが管理するOracle Data Guard構成でのみ使用できます。
ファスト・スタート・フェイルオーバーを使用したOracle Data Guard構成は、最大可用性モードまたは最大パフォーマンス・モードで稼働します。ファスト・スタート・フェイルオーバーを有効化した場合、構成済のデータ損失保証を維持できる場合にのみファスト・スタート・フェイルオーバーを実行できるように、ブローカにより保証されます。最大可用性モードでは、データ損失の発生しないことが保証された自動フェイルオーバー環境が提供されます。最大パフォーマンス・モードでは、FastStartFailoverLagLimit構成プロパティで指定されたデータ量(秒単位)を超える損失は発生しないことが保証された自動フェイルオーバー環境が提供されます。
9.4.2.2項「フェイルオーバーのベスト・プラクティス(手動フェイルオーバーとファスト・スタート・フェイルオーバー)」に記載された汎用のベスト・プラクティスに加え、次のファスト・スタート・フェイルオーバーのベスト・プラクティスを使用してください。
ファスト・スタート・フェイルオーバーのオブザーバ・プロセスは、プライマリ・データベースまたはスタンバイ・データベースとは別の場所にあるデータ・センターのホストで実行します。
オブザーバは、プライマリ・データベースおよびスタンバイ・データベースから等距離の場所にあるシステムで実行してください。オブザーバは、任意のエンド・ユーザー・クライアントと同じネットワークを使用してこれら2つのデータベースに接続する必要があります。指定したオブザーバに障害が発生した場合、Oracle Enterprise Managerがそれを検出し、自動的にオブザーバを再起動することができます。オブザーバを第3のサイトで実行できない場合は、アプリケーションと同じネットワークにインストールしてください。第3の独立した場所を使用できない場合、スタンバイ・データ・センター内の別個のホストにオブザーバを配置し、スタンバイ・データベースに影響を与える障害からできるかぎり離してください。
Oracle Enterprise Managerを使用してオブザーバの可用性を高め、データベースへの接続が再確立されたら、元のプライマリ・データベースがスタンバイ・データベースとして自動的に復元されるように構成します。また、Oracle Enterprise Managerを使用すると、オブザーバを再起動する代替ホストを定義できます。
フェイルオーバーの完了後、FastStartFailoverAutoReinstate構成プロパティをTRUEに設定すると、接続が再確立されたときに、元のプライマリ・データベースがスタンバイ・データベースとして自動的に復元されます。
現在の構成上の特性に従って、FastStartFailoverThresholdプロパティの値を表9-6のとおりに設定します。
表9-6に示す設定を使用する構成をテストして、ファスト・スタート・フェイルオーバーのしきい値が、間違ってフェイルオーバーが起動されるほど極端に小さくないか、またはフェイルオーバー要件を満たさないほど大きくないかどうかを確認してください。
ユーザーが起動する手動フェイルオーバーは、緊急時にのみ使用し、次のような計画外の停止が発生した場合に開始する必要があります。
プライマリ・データベースが使用不可能となるサイト障害
一定の時間内に修復できないユーザー・エラー
広範囲の破損を含む、本番アプリケーションに影響を及ぼすデータ障害
9.4.2.2項「フェイルオーバーのベスト・プラクティス(手動フェイルオーバーとファスト・スタート・フェイルオーバー)」に記載された汎用のベスト・プラクティスに加え、次の手動フェイルオーバーのベスト・プラクティスを使用してください。
元のプライマリ・データベースをスタンバイ・データベースとして復元し、現在の環境にフォルト・トレランスを回復する必要があります。スタンバイ・データベースは、フラッシュバック・データベースを使用して迅速に復元できます。13.3.2項「フェイルオーバー後のスタンバイ・データベースのリストア」を参照してください。
Oracle Active Data Guardオプションのライセンスがある場合、スタンバイ・データベース上のREDO Applyがプライマリ・データベースから受信したREDOデータを継続して適用している状態で、フィジカル・スタンバイ・データベースを読取り専用アクセスで開くことができます。フィジカル・スタンバイ・データベースから読み取る問合せはすべてリアルタイムで実行され、現在の結果を戻すため、データ保護が不完全になったり、フェイルオーバーが必要な場合にリカバリ時間が長くなったりすることなく、システム資源をより効率的に利用してスタンバイが正常な状態であることを再確認できます。このため、この機能はリアルタイム問合せと呼ばれます。
|
注意: Oracle Active Data Guardオプションのライセンスを購入すると、REDO Applyをアクティブにしたままフィジカル・スタンバイ・データベースを読取り専用アクセスでオープンできます。リアルタイム問合せとも呼ばれるこの機能を使用すると、スタンバイ・データベース上でブロック変更トラッキングが可能になり、それによりスタンバイ上で増分バックアップを実行できます。 |
リアルタイム問合せをデプロイするには、次のことを行います。
Active Data Guardが有効であることを確認します。
Oracle Active Data Guardのステータスを参照する簡単かつ最適な方法は、Oracle Enterprise ManagerからのData Guardの概要ページの参照です。
もしくは、スタンバイ・データベースでv$databaseビューの問合せを行い、READ ONLY WITH APPLYのステータスを確認することもできます。
SQL> SELECT open_mode FROM V$DATABASE; OPEN_MODE -------------------- READ ONLY WITH APPLY
REDOデータの受信と同時に変更が適用されるように、スタンバイ・データベースにリアルタイム適用を使用します。
Oracle Data Guardブローカは、構成が作成されるとリアルタイム適用を自動的に有効化します。構成の作成にSQL*Plusコマンドラインを使用している場合は、リアルタイム適用を次のように有効化します。
次の文を発行します。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
スタンバイ・データベースでフラッシュバック・データベースを有効化して、論理破損の停止時間を最小化します。
Standby Statspackを使用してスタンバイ・データベースのパフォーマンスを監視します。Standby Statspackのインストールおよび使用方法の詳細は、次のWebサイトのMy Oracle Support Note 454848.1の『11gでのStandby Statspackのインストールおよび使用』を参照してください。
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=454848.1
リアルタイム問合せをデプロイして、プライマリ・データベースからフィジカル・スタンバイ・データベースに問合せをオフロードしている場合、適用ラグを監視して許容範囲内かどうかを確認します。リアルタイム問合せ環境での適用ラグの監視の詳細は、『Oracle Data Guard概要および管理』を参照してください。
Oracle Data Guardブローカ構成を作成することで、管理を簡素化し、Oracle RACスタンバイ・データベースでの自動適用インスタンス・フェイルオーバーを有効化します。
|
関連項目: 次のWebサイトでOracle DatabaseのMAAベスト・プラクティスのエリアから、MAAホワイト・ペーパー『Active Data Guard 11gのベスト・プラクティス(Redo Applyのベスト・プラクティスを含む)』を参照してください。 |
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を再起動します。
スナップショット・スタンバイ・データベースを作成および管理するには、次のことを行います。
Oracle Data Guardブローカは、スナップショット・スタンバイ・データベースの管理を簡素化するため、これを使用してOracle Data Guard構成を管理します。ブローカではフェイルオーバー操作の一環として、スナップショット・スタンバイ・データベースがフィジカル・スタンバイ・データベースに変換されます。ブローカがない場合、この変換はフェイルオーバーの開始前に手動で実行する必要があります。
リカバリ時間目標(RTO)が要求される業務の場合、複数のスタンバイ・データベースを作成します。
スナップショット・スタンバイに変換するフィジカル・スタンバイ・データベースが、プライマリ・データベースに追随しているか、適用ラグが最小であることを確認します。メディア・リカバリのチューニングの詳細は、9.3.8項「Data Guard Redo Applyのベスト・プラクティスの使用」を参照してください。
高速リカバリ領域を構成し、十分なI/O帯域幅を利用できることを確認します。確認が必要なのは、スナップショット・スタンバイ・データベースが保証付きリストア・ポイントを使用するためです。
|
関連項目: スナップショット・スタンバイ・データベースの作成方法の詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
Data Guardスタンバイ・データベースの追加後におけるプライマリ・データベースのパフォーマンスを正確に評価するには、同じアプリケーション・プロファイルおよび負荷を伴うOracle 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プロセスによるコミット時間の増加は、特に小規模な時間依存型のトランザクションにおいて、レスポンス時間の増加とスループット低下の原因となる場合があります。ただし、ログ・ライターのローカル書込み(Log File Parallel Write待機イベント)や、LGWR wait on SENDREQ待機イベントを構成する各種の構成要素をチューニングすることで、これらの問題を十分に改善できる可能性があります。
ディスク書込みI/O(ログ・ファイル・パラレル書込みまたはRFS I/O)をチューニングするには、より多くのスピンドルを追加するか、I/O帯域幅を拡張します。
ネットワーク時間を短縮するには、次のようにします。
Oracle Netの送信および受信バッファ・サイズをチューニングします。
SDU=65535に設定します(詳細は9.3.7.2項「ネットワーク構成と最大ネットワークREDO速度の設定」を参照してください)。
飽和状態にある場合、ネットワーク帯域幅を拡張します。
より近距離のサイトを探してネットワーク待機時間を短縮します。
ASYNC転送では、LGWRプロセスは、ネットワーク・サーバー・プロセスが戻るのを待機せずにCOMMITレコードを現在のログ・ファイルに書き込みます。ただし、ネットワーク・サーバー・プロセスが遅延し、転送予定のREDOがログ・バッファからフラッシュされている場合、ネットワーク・サーバー・プロセスはオンラインREDOログからデータを読み取ります。これにより、I/Oの競合が増加し、状況によってはログ・ライター・プロセスの書込み(ログ・ファイル・パラレル書込み)の待機時間が増加します。I/O帯域幅と十分なスピンドルが割り当てられていない場合、ログ・ファイル・パラレル書込みおよびログ・ファイル順次読取りによる待機が増加し、スループットやレスポンス時間に影響を与える可能性があります。通常は、十分なスピンドルを追加することでI/O待機時間を削減できます。
|
関連項目:
|
