Oracle Cloud Infrastructure（OCI）のデプロイメント向け ......1 | Oracle Cloud Infrastructure（OCI）のデプロイメント向けOracle MAA ブループリント免責事項

Oracle Cloud Infrastructure（OCI）のデプロイメント向け Oracle MAAブループリントクラウドでのOracle Databaseの高可用性 Oracle ホワイト・ペーパー | 2018 年 12 月

1 | Oracle Cloud Infrastructure（OCI）のデプロイメント向け Oracle MAA ブループリント

免責事項

下記事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。マテリアルやコード、機能の提供をコミットメント（確約）するものではなく、購買を決定する際の判断材料になさらないで下さい。オラクルの製品に関して記載されている機能の開発、リリース、および時期については、弊社の裁量により決定されます。


目次

はじめに ....................................................................................................................................................4

MAA のための Oracle Cloud Infrastructure .........................................................................................5

可用性ドメインの独立性 ..............................................................................................................5

高可用性リファレンス・アーキテクチャ – Oracle Cloud Infrastructure - Database ...................6

Bronze：開発、テスト、本番用のデータベース ............................................................................. 10

Bronze のまとめ ......................................................................................................................... 12

Silver：部門のデータベース ............................................................................................................... 13

Silver アーキテクチャにおける RAC のまとめ ....................................................................... 14

Silver アーキテクチャにおける

Active Data Guard ファスト・スタート・フェイルオーバーのまとめ .............................. 15

Gold：ビジネス・クリティカルおよびミッション・クリティカルなデータベース ................. 16

Oracle Data Guard と Oracle Active Data Guard ................................................................... 17

Gold のまとめ ............................................................................................................................. 20

Platinum：非常にクリティカルなデータベース ............................................................................. 20

Oracle GoldenGate ..................................................................................................................... 21

エディションベースの再定義 ................................................................................................... 22

Platinum のまとめ ...................................................................................................................... 23

Oracle Cloud Infrastructure – MAA の概念実証および構成プラクティス ................................... 24

破損の防止、検出、自動修復 ................................................................................................... 24

OCI クラウド・バックアップおよび Object Storage を使用したリカバリ........................ 26

Data Guard ファスト・スタート・フェイルオーバー .......................................................... 28

ファスト・スタート・フェイルオーバーの構成 ............................................................ 28

ファスト・スタート・フェイルオーバーにおける

オブザーバ配置のベスト・プラクティス ........................................................................ 31

Far Sync によるファスト・スタート・フェイルオーバー .................................................... 34

ファスト・スタート・フェイルオーバーのパフォーマンス ................................................ 35

（Active）Data Guard SYNC または ASYNC の評価.............................................................. 36


Data Guard スイッチオーバーによる停止時間の短縮 .......................................................... 37

Oracle Data Guard の構成の監視 ............................................................................................. 38

Data Guard ブローカによる転送遅延または適用遅延の検出 ....................................... 40

OCI における Data Guard の操作 ............................................................................................. 42

Oracle GoldenGate ..................................................................................................................... 42

まとめ ..................................................................................................................................................... 43


はじめに

企業は、少ないリソースやコストでより多くの成果を上げ、リスクを低減し、俊敏性、柔軟性、セキュリティを向上させなければならない厳しい圧力にさらされています。多くの企業は、そのような目標を達成するための戦略として、IT インフラストラクチャをアグレッシブに移行し、DBaaS（Database as a Service）をパブリック・クラウドとプライベート・クラウドにデプロイしています。

データベースのクラウド変革により、システムの使用効率が大幅に改善され、管理上のオーバーヘッドが軽減されるため、コストの削減が促進されます。DBaaS をデプロイすると、IT インフラストラクチャとプロセスが標準化されるため、コストの削減と俊敏性の向上が促進されます。さらにクラウドを使用することで、より効率的なコンピューティング・ユーティリティ・モデルが実現するため、これらの利点が向上します。

ただし、上記のすべての取組みには、停止時間とデータ損失の影響が増大することによるビジネス・リスクも伴います。1 人の開発者、または小規模な作業グループが使用するスタンドアロン環境に障害が発生しても、影響は通常は限定的です。従来型のスタンドアロン環境で実行されている重要なアプリケーションに障害が発生した場合は、ビジネスにただちに影響が及びますが、他のアプリケーションは引き続き影響を受けずに実行できるでしょう。これに対して、企業のすべての開発スタッフや多数の部門が使用する複数アプリケーションをサポートしている統合環境が停止すると、ビジネスに極めて深刻な影響が及びます。そのようなアプリケーションが実行されているクラウド・プロバイダのサービスが停止した場合も、同様に深刻な影響が発生します。

Oracle Maximum Availability Architecture（Oracle MAA）および MAA リファレンス・アーキテクチャにより、より高い安定性、より短い停止時間、より優れたデータ保護が重要となる、あらゆるデータベースと Database-as-a-Service（DBaaS）において要求される水準の標準化が可能となります。MAA リファレンス・アーキテクチャは、あらゆる規模や業種の企業に必要な幅広い可用性とデータ保護に対応しています。すべてのリファレンス・アーキテクチャは、オンプレミスまたはクラウドにデプロイできる一般的なプラットフォームを基盤としています。このアプローチにより、Oracle MAA は簡素化され、クラウドへの移行リスクが軽減されます。

このホワイト・ペーパーでは、Oracle MAA リファレンス・アーキテクチャと、このアーキテクチャが Oracle Cloud Infrastructure（OCI） Service を使用して対応するサービス・レベル要件について説明します。さらに、既存の OCI リソースを利用することによる、パフォーマンスと可用性の面での効果について取り上げます。このホワイト・ペーパーは、DBaaS の設計と実装、およびクラウドへの実装移行を担当するアーキテクト、IT ディレクター、データベース管理者などの技術者を対象としています。


MAAのためのOracle Cloud Infrastructure

OCI は、もっとも要求水準の高いエンタープライズ顧客を含む、Oracle Database のすべての顧客を支えるデータベース MAA のあらゆる構成要素を備えた、オラクルのもっとも高度なクラウド・インフラストラクチャです。おもな構成要素は以下のとおりです。

• 再起動機能と冗長ローカル・ストレージを備えた Bare Metal Single Instance データベース・システム

• 再起動機能と三重ミラー化ブロック・ストレージを備えた Virtual Machine シングル・ンスタンス・データベース・システム

• Virtual Machine 2 ノード Real Application Clusters システム • Exadata システム（クォーター・ラック、ハーフ・ラック、フル・ラックを含むさまざま

な構成） – 最良のデータベース・プラットフォーム

• 停止時の分離をもたらすリージョン、可用性ドメイン（AD）、障害ドメイン（FD） • 世界クラスのスケーラブル・ネットワーク

o パブリック・サブネットおよび完全なプライベート・サブネットを使用した Virtual Cloud（VCN）ピアリングによる、各 AD 内および AD 全体での高セキュリティ、高帯域幅、短い待機時間

o VCN ピアリングが行われているリージョン全体での高セキュリティ、高帯域幅

• オブジェクト・ストレージを備えたスケーラブルなバックアップ・インフラストラクチャ詳細および OCI インフラストラクチャの最新情報については、OCI のドキュメントを参照してください。

図1：OCIデータベース・インフラストラクチャおよび主要なMAAコンポーネントのまとめ

可用性ドメインの独立性

Oracle Cloud Infrastructure 内の物理インフラストラクチャとソフトウェア・スタックは、可用性ドメイン（AD）内、および AD 全体で障害分離を実現するように一から設計されています。Oracle Cloud Infrastructure Service は、リージョンでホストされます。さらに、複数の可用性ドメイン（AD）でホストされる場合もあります。リージョンはローカライズされた地理的領域であり、可用性ドメインはリージョン内にある 1 つまたは複数のデータセンターです。1 つのリージョンは、3 つの可用性ドメインによって構成できます。

https://docs.oracle.com/cd/E83857_01/iaas/index.html


リージョン内のすべての可用性ドメインは、待機時間の短い高帯域幅ネットワークで相互に接続されているため、インターネットや顧客の拠点への高可用性接続が可能であり、複数の可用性ドメインに複製システムを構築して高可用性とディザスタ・リカバリを実現できます。可用性ドメインには障害ドメインが含まれます。障害ドメイン（FD）は、可用性ドメイン（AD）内に存在する、ハードウェアとインフラストラクチャからなるグループです。1 つの AD には、3 つの FD ドメインが含まれます。障害ドメインは、Oracle Real Application Clusters（Oracle RAC）データベースのノードとインスタンスを分散させ、これらが 1 つの可用性ドメイン内で同一の物理ハードウェア上に存在しないようにして、障害時の分離レベルを向上させます。ある障害ドメインに影響を与えるハードウェア障害またはコンピューティング・ハードウェアの保守は、別の障害ドメインのインスタンスには影響しません。

図2：Oracle Cloud Infrastructureのリージョン、可用性ドメイン、障害ドメイン

オラクルでは VCN ピアリングの使用を推奨しています。VCN ピアリングとは、リージョンをまたいで Oracle Data Guard を構成する場合に、異なるリージョンに属している 2 つの VCN を接続するプロセスです。VCN ピアリングにより、VCN のリソースはプライベート IP アドレスを使用して通信することができ、インターネット経由またはオンプレミス・ネットワークを通してトラフィックをルーティングする必要がありません。ピアリングを行わない VCN では、インターネット・ゲートウェイと追加のパブリック IP アドレスが必要となります。リモート VCN ピアリングをサポートするリージョンの最新情報については、OCI のドキュメントを参照してください。

高可用性リファレンス・アーキテクチャ –

Oracle Cloud Infrastructure - Database

Oracle MAA のベスト・プラクティスでは、あらゆる規模や業種の企業に必要な幅広い可用性とデータ保護に対応した 4 つの高可用性（HA）リファレンス・アーキテクチャを定義しています。これらのリファレンス・アーキテクチャは、図 3 で示すとおり、Platinum、Gold、Silver、Bronze と呼ばれます。

各アーキテクチャは、最適な Oracle HA 機能一式を使用して、最小限のコストと複雑性で所定のサービス・レベルを確実に達成します。これらのアーキテクチャは、データ破損、コンポーネント障害、システムやサイトの停止といったあらゆる種類の計画外停止と、メンテナンス、移行などを目的とする計画停止時間に対応しています。MAA は、Oracle Sharding を使用するアプリケーショ

https://docs.oracle.com/cd/E97706_01/Content/Network/Tasks/remoteVCNpeering.htm


ン向けのリファレンス・アーキテクチャも提供しており、アプリケーションがシャード・アーキテクチャ向けに設計、カスタマイズされている場合、OCI 内において制限のないスケーラビリティと他に類をみない可用性を提供できます。MAA Oracle Sharding アーキテクチャについては、別のドキュメントで解説しています。

図3：Oracle Databaseの高可用性リファレンス・アーキテクチャ

MAA リファレンス・アーキテクチャは、Oracle Database 向けに最適化された一般的なインフラストラクチャを基盤としており、顧客はさまざまなサービス・レベル要件にふさわしいレベルの HAを選択できるようになっています。そのため、ビジネス要件が変更された場合に、データベースをある HA 層から別の層に、あるハードウェア・プラットフォームから別のハードウェア・プラットフォームに、あるいはオンプレミスから Oracle Cloud に容易に移行できます。

Bronze リファレンス・アーキテクチャは、データベースのインスタンス、ノード、VM の単純な再起動およびバックアップからのリストアが'十分に HA で DR'であるデータベースに適しています。Bronze は、サーバーや Oracle Clusterware 監視などの HA 機能、そして OCI、Oracle Standard Edition および Oracle Enterprise Edition に含まれる再起動機能を使用します。Bronze は、単一インスタンスの Oracle 11g データベース、または単一インスタンスの Oracle 12c（またはそれ以降）のマルチテナント・データベースで、統合性、シンプルさ、プラガブル・データベースの俊敏性が向上します。Multitenant データベースとプラガブル・データベースを使用することで、PDB Relocateによる PDB の再配置、および PDB Hot Cloning による PDB のリフレッシュが可能です。Oracle Multitenant は、データベース統合のための 1 つの選択肢です。単一のコンテナに複数のプラガブル・データベースが存在するアーキテクチャであり、多数のデータベースを 1 つのデータベースとして管理することで運用コストが抑えられ、統合密度を上げることで資本コストが抑えられます。Bronze では、Oracle Recovery Manager（RMAN）を使用してオラクル向けに最適化された OCI オブジェクト・ストレージへのバックアップに依存することにより、同じリージョン内のデータ保護を実現します。バックアップは別の可用性ドメインに自動的に複製され、分離とデータ保護が強化されます。


Silver リファレンス・アーキテクチャは、リカバリ不能なデータベース・サーバーの停止が発生した場合に、コールド・リスタートやバックアップからのリストアを待つことができないデータベース向けに設計されています。Silver は、Bronze アーキテクチャと同じ機能を基盤とし、可用性を向上させるための 2 つの異なるパターンを選択できる機能が追加されています。

1. 主要パターンは、Oracle RAC を使用するものです。Oracle RAC は、データベース・インスタンスやサーバーの障害時に停止時間を最低限またはゼロにするため、またごく一般的なソフトウェア・アップデート（オペレーティング・システム、DB/GI ソフトウェアの定期アップデート）での停止時間をゼロにするための、アクティブ-アクティブのクラスタリング・テクノロジーです。Silver は、アプリケーション・サービスのフェイルオーバーを確実にするベスト・プラクティスを実装しています。Bronze と同じく、Recovery Manager によってデータベース向けに最適化されたバックアップが提供されるため、データベースまたはクラスタが完全に停止した場合は、データが保護され、可用性がリストアされます。2 ノードのOracle RAC 構成は、VM データベース・システムで利用できます。オラクルの優れた Exadata Database Machine では、クォーター、ハーフおよびフルの Exadata ラック・オプションが用意されています。ある可用性ドメインに複数の障害ドメインが存在している場合、2 ノードRAC VM の障害時における分離性を高めるため、Oracle RAC コンピュート・ノードはそれぞれ別々の障害ドメインに配置されます。Exadata は現在においても、Oracle RAC とともにオラクルで最良の MAA データベース・プラットフォームであり、優れた HA、データ保護、HA サービス品質、そして管理上のメリットは、OCI RAC VM には見られないものです。詳細については、https://www.oracle.com/technetwork/jp/database/features/availability/exadata-maa-best-practices-355203-ja.html を参照してください。

2. 代替パターンでは、Data Guard ファスト・スタート・フェイルオーバーを使用して、本番データベースの同期コピーをローカルでありながら別個に保持し、可用性ドメイン全体、または可用性ドメインが 1 つだけの場合は障害ドメイン全体で HA を実現します。各可用性ドメインは、フォルト・トレラントであり、独立性があり、分離されています。Data Guard、または分離されたスタンバイ・データベースのコピーにより、データ破損、人為的エラー、クラスタ停止、ネットワーク障害、データベース・アップグレードなど、幅広いデータベース停止に対して HA が提供されます。Data Guard の同期レプリケーションとデータベースの自動フェイルオーバーも、さらなるレベルのデータ保護を実現します。Data Guard は、Oracle Database Enterprise Edition に含まれる機能です。Bronze データベースで使用されるライセンス製品やクラウド・サービスのほかに、追加のライセンス製品やクラウド・サービスは必要ありません。この代替の Silver リファレンス・アーキテクチャは、ごく一般的なソフトウェア・アップデートにおいてシンプル、最小限、またはゼロの停止時間を実現できません。そのため、Oracle RAC を使用するパターンが MAA Silver リファレンス・アーキテクチャ・ソリューションとして推奨されます。

Gold リファレンス・アーキテクチャは、データベース、クラスタ、データ破損、サイトなどの障害およびデータベースのメジャー・アップグレードに起因する停止時間を許容できないサービス・レベル要件に適しています。Gold リファレンス・アーキテクチャは、Silver リファレンス・アーキテクチャの Oracle RAC パターンを基盤に、可用性ドメイン全体、または DR のためにリージョン保護が必要な場合はリージョン全体に Oracle Active Data Guard によってスタンバイ・データベースを追加したものです。プライマリおよびスタンバイのデータベース・システムは、Data Guard のロール移行後も同等のパフォーマンス・サービス・レベルが確保されるよう、対称的に構成します。お客

https://www.oracle.com/technetwork/jp/database/features/availability/exadata-maa-best-practices-355203-ja.htmlhttps://www.oracle.com/technetwork/jp/database/features/availability/exadata-maa-best-practices-355203-ja.html


様によっては、最初はリカバリ時のスタンバイ・データベース・システムにおけるライセンス・コア数を少なめにし、ロール移行後に一気に増やす場合もありますが、その分パフォーマンスに関する SLA への適合が遅れることになります。Data Guard ファスト・スタート・フェイルオーバーは、もっとも低いリカバリ時間目標（RTO）が保たれるよう構成しなければなりません。Data Guardファスト・スタート・フェイルオーバーは、可用性ドメイン全体でのデータ損失ゼロ、またはSYNC 転送や Far SYNC 転送の使用によるリージョン全体でのデータ損失ゼロを構成できます。あるいは、ASYNC 転送および Data Guard の Max Performance 保護モードでは、データ損失が最小限に抑えられます。

可用性ドメインまたはリージョンをまたぐ Oracle Active Data Guard は現在存在しています。Oracle RAC のプライマリおよびスタンバイは、Oracle RAC VM または Oracle Exadata Database Machine を使用して構成できます。ローカルおよびリモートの VCN（Virtual Connection Network）ピアリングにより、可用性ドメイン全体およびリージョン全体にセキュアで高帯域幅のネットワークが提供されます。可用性ドメイン、障害ドメイン、リージョン、およびこれらに関連する VCN ピアリングのサポートの最新情報については、OCI のドキュメントを参照してください。リモート VCN ピアリング・オプションが利用できない場合は、公共のインターネット・バックボーンを Oracle Net およびTDE 暗号化といっしょに使用できます。ただし、すべてのリージョンでこの機能をただちに、またはできるだけ早く使用できるようにする必要があります。

Platinum リファレンス・アーキテクチャには、既存の Gold アーキテクチャに加え、停止時間ゼロのアップグレードと移行を実現する Oracle GoldenGate、そして停止時間ゼロのアプリケーション・アップグレードを実現するエディションベースの再定義が含まれます。Platinum リファレンス・アーキテクチャは、停止時間が許容されないもっとも重要なアプリケーションに極めて大きな価値をもたらします。Platinum には、Gold と同じオンプレミスの機能と製品に加え、エディションベースの再定義と Oracle GoldenGate が必要です。

以下のセクションでは、Oracle Cloud Infrastructure 固有のすべてのリファレンス・アーキテクチャについて説明します。


Bronze：開発、テスト、本番用のデータベース

Bronze アーキテクチャ（図 4 参照）では、基本的なデータベース・サービス保護が必要最低限のコストで提供されます。コストと実装の複雑性が軽減されている代わりに、HA とデータ保護のレベルが低減されています。

図4：BronzeのHAリファレンス・アーキテクチャ

Bronze は、データベース・サーバーとデータベース・インスタンスの再起動機能を備えた、シングル・インスタンスの Oracle Database を基盤としています。OCI の場合は、ベア・メタル物理サーバーまたはシングル・インスタンス VM が基盤です。データベースの各インストールでは、Oracle Clusterware がインストールされます。サーバーまたは VM に障害が発生すると、自動的に再起動が試みられます。データベース・サーバーが再起動すると、Oracle Clusterware が Oracle のインスタンス、リスナーおよび関連サービスを再起動します。マシンを使用できなくなった場合や、データベースをリカバリできなくなった場合に、いかに迅速に代替システムをプロビジョニングできるか、およびバックアップをリストアできるかを示す機能がリカバリ時間目標（RTO）です。可用性ドメインの完全な停止という最悪のシナリオでは、このようなタスクを実行してリモート・ロケーションにリストアするには、さらに時間が必要です。

Oracle Recovery Manager（RMAN）は、OCI オブジェクト・ストレージから Oracle Database の定期的なバックアップを実行するために使用されます。データベースのバックアップは、可用性ドメインをまたいで自動的に複製されます。リカバリ不能な停止が発生した場合の潜在的データ損失（リカバリ・ポイント目標（RPO）とも呼ばれます）は、リカバリに必要となる利用可能な連続するアーカイブ・セットにいたるまでの、最新の利用可能なバックアップと同じです。クラウド・オブジェクト・ストレージに対して毎日のバックアップと頻繁なアーカイブ・バックアップを行うことで、RPO を減らすことができます。災害により既存の可用性ドメインが影響を受けた場合は、Oracle Cloud へのデータベース・バックアップを活用できます。


Bronze では、Oracle Database Enterprise Edition に含まれる以下の機能が利用されます。

» Oracle Clusterware は、ハードウェアやソフトウェアの障害が発生した後、およびデータベースのホスト・コンピュータが再起動されるたびに、データベース、リスナー、その他の Oracle コンポーネントを自動的に再起動します。Oracle Clusterware は、すべての OCIデータベース・インスタンスにあらかじめインストールされています。MAA では、Oracle Clusterware マネージド・サービスを使用するデータベースに接続するすべてのアプリケーションに対し、Oracle Clusterware マネージド・サービスの使用を推奨します。

» オラクルの破損保護は、物理的な破損と論理的なブロック内破損の有無を確認します。メモリ内破損が検出されると、ディスクへの書込みが防止され、多くの場合は自動的に修復されます。詳しくは、『Preventing, Detecting, and Repairing Block Corruption for the Oracle Database』を参照してください。OCI の場合、デフォルトのデータベース構成ではDB_BLOCK_CHECKSUM=FULL が有効になっています。MAA では、パフォーマンスへの影響が最小であれば、DB_BLOCK_CHECKING を MED または FULL に設定して有効にすることを推奨しています。

» Automatic Storage Management（ASM）は、ディスク障害から保護するためのローカル・ミラー化を備えた、オラクルの統合ファイル・システム兼ボリューム・マネージャです。MAA では、すべてのベア・メタル・デプロイメントと Exadata Database Machine が高冗長性ディスク・グループを使用することを推奨しています。Exadata システムでは、ASM が唯一のオプションです。VM データベース・システムの場合、ブロック・ストレージ上の三重ミラー化による外部冗長性を確保しつつ、ASM が自動的にデプロイされます。

» Oracle Flashback Technology は、個々のトランザクション、表、またはデータベース全体を修復するのに適した粒度レベルで、高速なエラー修正を実行します。OCI データベース構成の場合、フラッシュバック・データベースは、デフォルトでは、数時間分のフラッシュバック保持で有効化されています。より長いフラッシュバック・ウィンドウで論理的破損からフラッシュバックする必要のある場合は、DB_FLASHBACK_RETENTION_TARGETの値を増やすことができます。

» Oracle Recovery Manager（RMAN）は、信頼性の高いバックアップとリカバリを低コストで提供します。OCI の場合、OCI オブジェクト・ストレージへのバックアップを有効にできます。バックアップ API には、適度なバックアップ/リストア速度が有効になるデフォルト値が設定されています。パフォーマンス観測については、後述の MAA における観測のセクションで取り上げます。

» オンライン・メンテナンスには、データベース・メンテナンスのためのオンライン再定義と再編成、オンライン・ファイル移動、およびオンライン・パッチ適用が含まれます。これらの操作は手動で実行できます。


» 継続的可用性 / アプリケーション・コンティニュイティのベスト・プラクティスはアプリケーションの設計および構成プロセスの初期段階で確立する必要があります。そうすることにより、小規模な停止後または計画メンテナンス・アクティビティ後のサービス継続性が向上します。以下を取り上げているドキュメント『Application Checklist for Continuous Service on the Autonomous Database MAA』を参照してください。

• Clusterware によって管理される Oracle サービスおよび高速アプリケーション通知の使用

• 計画メンテナンス時のセッションのドレイニングとリバランシング • 透過的アプリケーション・フェイルオーバー（TAF） • アプリケーション・コンティニュイティ（AC） • 透過的アプリケーション・コンティニュイティ（TAC）

上記のプラクティスは、より高いサービス・レベルの MAA リファレンス・アーキテクチャ、特に Oracle RAC またはデータ損失ゼロの Data Guard ファスト・スタート・フェイルオーバーを含むアーキテクチャにおいて関連が深くなります。

Bronzeのまとめ

表 1 では、Bronze リファレンス・アーキテクチャの RTO および RPO サービス・レベル要件を要約しています。

表1：Bronzeのリカバリ時間目標（RTO）および潜在的データ損失（RPO）

イベント停止時間（RTO）潜在的データ損失（RPO）

ディスク障害 0（ゼロ） 0（ゼロ）

リカバリ可能なデータベース・インスタンス障害数分 0（ゼロ）

リカバリ可能なデータベース・サーバー障害数分～1時間 0（ゼロ）

データ破損、リカバリ不能なインスタンス、サーバー、データベース、またはサイトの障害

数時間～1日最後のバックアップ以降

オンライン・ファイル移動、データベース再編成または再定義、対象となるワンオフ・パッチのためのオンライン・パッチ適用

0（ゼロ） 0（ゼロ）

ハードウェアおよびソフトウェアのメンテナンスとパッチ適用数分～1時間 0（ゼロ）

データベース・アップグレード（パッチ・セットとフル・リリース）

数分～1時間 0（ゼロ）

プラットフォームの移行数時間～1日 0（ゼロ）

バックエンド・データベース・オブジェクトを変更するアプリケーション・アップグレード

数時間～1日 0（ゼロ）


Bronze の要件：クラウド・デプロイメントには、Oracle Enterprise DBaaS（PaaS）と OCI Object Storage が最低限必要です。Oracle Multitenant を使用してデータベース統合を行う場合、オンプレミス・デプロイメントには Oracle Multitenant のライセンスが、クラウド・デプロイメントには最低でも Oracle Cloud Infrastructure - Database の Oracle High Performance オプションのサブスクリプションが必要です。

Silver：部門のデータベース

Silver リファレンス・アーキテクチャ（図 5）は、リカバリ不能なデータベース停止が発生した場合に、コールド・リスタートやバックアップからのリストアを待つことができないデータベース向けに設計されています。Silver には、Bronze と同じ機能が用意されているほか、HA を追加する 2 つの異なるパターンを選択できる機能が追加されています。

MAA での推奨は、Silver パターンにおいて、HA のために Oracle RAC を使用して 2 つめのアクティブな Oracle インスタンスへの自動フェイルオーバーを有効にし、ごく一般的なソフトウェア・アップデートにおける停止時間ゼロの可能性を提供するというものです。Oracle RAC は、Oracle RAC VM および Exadata を使用する OCI で利用できます。

代替パターンでは、Data Guard データベース・レプリケーションを使用するとともに、異なる可用性ドメインにある本番データベースの完全な同期コピーに自動フェイルオーバーすることで、HAを確保します。Bronze と同様、バックアップはローカルの OCI オブジェクト・ストレージに送られ、自動的に別の AD オブジェクト・ストレージに複製されます。

図5：SilverのHAリファレンス・アーキテクチャオプション1


Silver は、Bronze の機能に加え、Oracle Database Enterprise Edition に含まれる以下の機能を使用します。

• Oracle RAC を使用すると、Oracle データベースはサーバーのクラスタ全体で動作し、アプリケーションを変更する必要なく、フォルト・トレランス、パフォーマンス、およびスケーラビリティを提供できます。インスタンスまたはノードに障害が発生しても、データベースの停止時間は基本的にゼロです。さらに、障害の発生した Oracle RAC インスタンスおよびマネージド・リソース（Oracle リスナーなど）を Oracle Clusterware が自動的に再起動します。OCI では、Oracle RAC は、2 ノードの Oracle RAC VM として、または Exadata とともに利用できます。

• Oracle RAC によって、ユーザーによる中断なしに計画メンテナンスを管理したり、インスタンスやノードの障害によるサービス一時停止を減らしたりすることができます。詳細については、「Application Checklist for Continuous Service」を参照してください。

SilverアーキテクチャにおけるRACのまとめ

表 2 では、Silver リファレンス・アーキテクチャの RTO および RPO サービス・レベル要件を要約しています。強調表示されている箇所は、Bronze アーキテクチャと比較した場合の優位な点です。

表2：SilverアーキテクチャにおけるRACのリカバリ時間目標（RTO）および潜在的データ損失（RPO）



リカバリ可能またはリカバリ不能なRACインスタンス障害数秒 0（ゼロ）

リカバリ可能またはリカバリ不能なRACサーバー障害数秒 0（ゼロ）

データ破損、リカバリ不能なデータベース、可用性ドメインやリージョンの障害

数時間～1日最後のバックアップ以降

障害ドメインの障害（RACノードは可用性ドメイン内の別の障害ドメインに構成可能）

数秒 0（ゼロ）

オンライン・ファイル移動、データベース再編成または再定義、

対象となるワンオフ・パッチのためのオンライン・パッチ適用 0（ゼロ） 0（ゼロ）

ハードウェアおよびソフトウェアのメンテナンスとパッチ適用 0（ゼロ） 0（ゼロ）


数分～1時間 0（ゼロ）

プラットフォームの移行数時間～1日 0（ゼロ）



Silver の要件（Oracle RAC：クラウド・デプロイメントには、Oracle Enterprise DBaaS（PaaS）とOracle Cloud Infrastructure Object Storage が最低限必要です。Bronze と同様に、Oracle Multitenantを使用してデータベース統合を行う場合、オンプレミス・デプロイメントには Oracle Multitenantのライセンスが、クラウド・デプロイメントには最低でも Oracle High Performance DBaaS（PaaS）が必要です。


Silver MAA の代替パターンでは、Data Guard ファスト・スタート・フェイルオーバーを使用して、本番データベースの同期コピーをローカルでありながら別個に保持し、可用性ドメイン全体、または可用性ドメインが 1 つだけの場合は障害ドメイン全体で HA を実現します。

図6：SilverのHAリファレンス・アーキテクチャ

各可用性ドメインは、フォルト・トレラントであり、独立性があり、分離されています。Data Guard、または分離されたスタンバイ・データベースのコピーにより、データ破損、人為的エラー、クラスタ停止、ネットワーク障害、データベース・アップグレードなど、幅広いデータベース停止に対して HA が提供されます。Data Guard の同期レプリケーションとデータベースの自動フェイルオーバーも、さらなるレベルのデータ保護を実現します。

SilverアーキテクチャにおけるActive Data Guardファスト・スタート・フェイルオーバー

のまとめ

表 3 では、Silver リファレンス・アーキテクチャの RTO および RPO サービス・レベル要件を要約しています。強調表示されている箇所は、Bronze の表と比較した場合の優位な点です。MAA では、Data Guard ファスト・スタート・フェイルオーバーを最大可用性保護モードで設定することを推奨しています。AD をまたぐ SYNC 転送の使用は、AD 間が高帯域幅のネットワークで接続され、待機時間がごくわずかであるためパフォーマンス上の影響は最小です。後述する MAA における観測のセクションを参照してください。表 3 からすると、Data Guard は独立したデータベースであるため、停止が多ければ、保護が向上する可能性があります。ただし、ハードウェアとソフトウェアのメンテナンスは四半期ごとに行われ、ゼロでもなく、ほぼゼロでもありません。


表3：Active Data Guardファスト・スタート・フェイルオーバーを使用するSilver代替パターンのリカバリ時間目標（RTO）および潜在的データ損失（RPO）



リカバリ可能またはリカバリ不能なRACインスタンス障害数秒〜1分 0（ゼロ、SYNC使用）

リカバリ可能またはリカバリ不能なRACサーバー障害数秒〜1分 0（ゼロ、SYNC使用）

データ破損、リカバリ不能なデータベース、可用性ドメインやリージョンの障害（スタンバイが別のリージョンにあるかどうかで変化）

数秒〜1分 0（ゼロ、SYNC使用）



ハードウェアおよびソフトウェアのメンテナンスとパッチ適用数分～1時間 0（ゼロ）


数秒〜1分 0（ゼロ）

プラットフォームの移行数秒〜1分 0（ゼロ）



Silver 代替パターンの要件（Data Guard ファスト・スタート・フェイルオーバー）：クラウド・デプロイメントには、Oracle Enterprise DBaaS（PaaS）と Oracle Cloud Infrastructure Object Storageが最低限必要です。Bronze と同様に、Oracle Multitenant を使用してデータベース統合を行う場合、オンプレミス・デプロイメントには Oracle Multitenant のライセンスが、クラウド・デプロイメントには最低でも Oracle High Performance DBaaS（PaaS）が必要です。

Gold：ビジネス・クリティカルおよびミッション・クリティカルな

データベース

Gold リファレンス・アーキテクチャは、データセンター障害を許容できない、または場合によってはリージョン規模のサイト障害も許容できないサービス・レベル要件の場合に理想的です。Oracle RAC を使用する Silver を基盤としていますが、Oracle Active Data Guard のスタンバイ・データベースが必要です。このデータベースでは、物理データ破損の自動ブロック修正、およびデータベース、クラスタ、データセンターの完全な停止に対応するリモート・スタンバイによって、より優れたデータ保護が実現します。


図7：GoldのMAAリファレンス・アーキテクチャ

Oracle Data GuardとOracle Active Data Guard

Oracle Data Guard は、1 つまたは複数の物理コピー（スタンバイ・データベース）を同期することにより、本番データベース（プライマリ・データベース）のシングル・ポイント障害を排除します。Oracle RAC（利用可能な場合）では、（別々のコンピュート・ノードで実行されている）複数のOracle インスタンスが、同じ Oracle Database へのアクセスを共有できます。Data Guard では、それぞれが独自の Oracle インスタンスを持つ完全に別個の Oracle Database の同期が維持されます。

Data Guard では、次の機能が提供されます。

• Data Guard の同期レプリケーションと最大可用性保護モードを使用することで、HA ソリューションに必要なデータ損失ゼロの保護が実現します。Data Guard は、プライマリ・データベースに対して行われた変更を、スタンバイ・データベースにリアルタイムに送信します。変更はプライマリのログ・バッファから直接送信されます。伝播の遅延とオーバーヘッドを最小限に抑えるとともに、本番データベースの I/O スタック内で発生する可能性のある破損からスタンバイ・データベースを完全に分離するためです。

• プライマリ・データベースとそのスタンバイ・コピーは、同じリージョン内の異なる可用性ドメイン内または異なるデータセンター内にローカルにデプロイできます。各可用性ドメインは、独自の電源、冷却機能、ネットワーク、サーバー、ストレージを備えています。

• Data Guard は、データベース、ストレージ、または可用性ドメインに障害が発生した場合に備えてフェイルオーバーの選択肢を提供するほか、継続的にオラクルの検証機能を実行して、破損がプライマリ・データベースからスタンバイ・データベースに伝播されないようにします。また、プライマリ・データベースまたはスタンバイ・データベースで独立して発生する可能性のある物理的および論理的なブロック内破損を検出します。さらに、独自の方法で、発見されにくい書込み損失破損（I/O サブシステムによって正常と認識された書込み損失や余分な書込み）の実行時検出を行うことができます。詳しくは、My Oracle Support Note 1302539.1『Best Practices for Corruption Detection, Prevention, and Automatic Repair』を参照してください。

https://support.oracle.com/rs?type=doc&id=1302539.1https://support.oracle.com/rs?type=doc&id=1302539.1


• Data Guard ファスト・スタート・フェイルオーバーにより、自動データベース・フェイルオーバーが提供されます。Data Guard スタンバイは実行中の Oracle データベースであり、プライマリ・ロールに移行するための再起動は必要ありません。自動データベース・フェイルオーバーは、負荷の高いシステムでも 60 秒未満で完了します。ファスト・スタート・フェイルオーバーにより、管理者が通知を受けて停止に対応することで発生する遅延がなくなるため、HA が実現します。

• Data Guard は、ロール固有のデータベース・サービスと、Oracle RAC が使用するものと同じ Oracle クライアント通知フレームワークを使用して、アプリケーションが障害の発生したデータベースへの接続を素早く切断し、新しいプライマリ・データベースに自動的に再接続されるようにします。ロール移行は、コマンドライン・インタフェースを使用するか、またはクラウド・コンソールにおいて、手動で実行することもできます。統合された透過的なクライアント・フェイルオーバーを最短のロール移行時間で達成するには、『Application Checklist for Continuous Service』および『Role Transition Best Practices: Data Guard and Active Data Guard』を参照してください。

• Data Guard では、Oracle Database の完全な一方向物理レプリケーションが実行され、パフォーマンスが高く、管理が容易で、あらゆるデータタイプ、アプリケーション、およびワークロード（DML、DDL、OLTP、バッチ処理、データウェアハウス、統合データベースなど）がサポートされるという特徴があります。Data Guard は、Oracle RAC、ASM、Recovery Manager、Oracle Flashback テクノロジーと緊密に統合されています。

• プライマリ・システムとスタンバイ・システムは正確な物理レプリカであるため、バックアップを（今後）プライマリ・データベースからスタンバイ・データベースにオフロードできます。スタンバイで作成されたバックアップは、プライマリまたはスタンバイ・データベースのどちらのリストアにも使用できます。そのため管理者は、バックアップを実行するというオーバーヘッドを本番システムに課すことのない、柔軟なリカバリ・オプションを手にします。OCIバックアップは現在、スタンバイ上では実行できません。

• スタンバイ・データベースを使用して、新しい Oracle パッチ・セットに（たとえば、パッチ・リリース 12.1.0.2.180417 から 12.2.01.180417 に）、または新しい Oracle リリースに（たとえば、リリース 12.2 から 18.1 に）、ローリング方式でアップグレードできます。これを行うには、まずスタンバイをアップグレードし、次に新しいバージョンで実行されるように本番データベースを切り替えます。合計の停止時間は、メンテナンスの完了後に、スタンバイ・データベースをプライマリの本番ロールに切り替え、ユーザーを新しいプライマリ・データベースに移行するために必要な時間のみです。新たに最適化された一時的な論理スタンバイの自動プロセスでは、15 秒未満の停止時間が発生します。12.2 以降のデータベース・バージョンについては、『Oracle Database ローリング・アップグレード Oracle Data Guard フィジカル・スタンバイ・データベースの使用』または『Automated Database Upgrades using Oracle Active Data Guard and DBMS_ROLLING』を参照してください。

オラクルがデータベース・レプリケーションにストレージベースのリモート・ミラー化ソリューション（SRDF、Hitachi TrueCopy など）ではなく、Data Guard または Active Data Guard の使用を推奨している背景について詳しくは、『Oracle Active Data Guard とストレージのリモート・ミラー化の比較』における詳細な説明を参照してください。


Oracle Active Data Guard は、Oracle Data Guard が提供している機能のスーパーセットです。Goldリファレンス・アーキテクチャでは、以下に挙げる Oracle Active Data Guard の高度な機能が使用されます。

• データ損失ゼロまたはデータ損失ほぼゼロの保護を選択できます。フェイルオーバー後のデータ損失ゼロが必須でない場合、リモート VCN Peering を使用するリモート DR サイトへの非同期レプリケーションと併せて Oracle Active Data Guard をデプロイできます。データ損失ゼロが必須の場合は、Oracle Active Data Guard Far Sync インスタンスをデプロイできます。Far Sync インスタンスは、軽量の転送メカニズムを使用することで、プライマリ・データベースとスタンバイ・データベースが数百マイルや数千マイル離れている場合でも、プライマリ・データベースのパフォーマンスに影響を与えずに、データ損失ゼロのフェイルオーバーを実現します。Far Sync インスタンスはデプロイが容易であり、透過的に運用できます。また、Far Sync インスタンスを Oracle Advanced Compression オプションと組み合わせて使用すると、オフ・ホストでの転送圧縮によるネットワーク帯域幅の節約、および RPO の減少が可能となります。

• レプリケーションがアクティブになっている間、オープンな読取り専用の Oracle Active Data Guard スタンバイ・データベースに読取り専用ワークロードをオフロードします。最新のアクティブ・スタンバイ・データベースは、本番データベースから非定型の問合せやレポート作成ワークロードをオフロードするのに最適です。これにより、スタンバイ・システムの ROI が向上するだけでなく、通常であればアイドル状態である容量が活用されるため、すべてのワークロードのパフォーマンスが向上します。また、障害が発生した場合にスタンバイ・データベースが本番ワークロードをサポートする準備ができていることを確認する、継続的なアプリケーション検証も可能になります。

• Recovery Manager ブロック・チェンジ・トラッキング・ファイルを使用して、スタンバイ・データベースから高速増分バックアップを実行します。高速増分バックアップは、従来の増分バックアップよりも最大で 20 倍高速に完了します。OCI バックアップは現在、スタンバイ上では実行できません。

• プライマリ・データベースまたはスタンバイ・データベースで個別に発生し得る断続的なランダム I/O エラーが引き起こす、ブロックレベルの破損を自動的に修復します。Oracle Active Data Guard は、もう一方のデータベースから適切なブロック・コピーを取得して修復を実行します。アプリケーションを変更する必要はなく、ユーザーは破損の影響を認識しません。


Goldのまとめ

Gold が対応する RTO および RPO サービス・レベル要件を表 4 に要約します。Gold では、Oracle RAC および Oracle Active Data Guard のメリットを享受することができ、アプリケーションのアップグレードを除くすべての停止に対し、包括的なデータ保護および短い RTO と RPO が可能となります。

表4：Goldのリカバリ時間目標（RTO）および潜在的データ損失（RPO）



リカバリ可能またはリカバリ不能なRACインスタンス障害数秒 0（ゼロ）

リカバリ可能またはリカバリ不能なRACサーバー障害数秒 0（ゼロ）


数秒〜1分 0（ゼロ、SYNC使用）





数秒 0（ゼロ）

プラットフォームの移行数秒〜1分 0（ゼロ）



Gold の要件：DR サイトとしてのオンプレミス・デプロイメントには、Oracle Enterprise Edition、Oracle Active Data Guard、Oracle Multitenant（データベース統合のためのオプション）、およびOracle Enterprise Manager のライフサイクル管理、診断、チューニング・パックが必要です。クラウド・デプロイメントには、Oracle Extreme Performance DBaaS（PaaS）または Exadata Cloud Service が最低限必要です。Gold では、Oracle Database Backup Cloud Service も使用します。

Platinum：非常にクリティカルなデータベース

Platinum リファレンス・アーキテクチャ（図 7 参照）は、Gold アーキテクチャを基盤に構築され、さらなるレベルの冗長性と複数の高度な HA 機能がデプロイされます。Platinum は、停止時間やデータ損失を許容できる場合でも、その許容度が極めて低いアプリケーションに最適です。このアーキテクチャでは、『Continuous Availability - Application Checklist for Continuous Service on the Autonomous Database』に示すように、アプリケーションに関するすべてのベスト・プラクティスを前提条件として組み込まなければなりません。


図8：PlatinumのHAリファレンス・アーキテクチャ

Platinum では、Oracle GoldenGate およびエディションベースの再定義を使用して、停止時間ゼロのメンテナンス、移行、アプリケーション・アップグレードを実現できます。

Oracle GoldenGate

Oracle GoldenGate では、論理レプリケーションによって本番データベース（ソース・データベース）の同期コピー（ターゲット・データベース）を維持できます。ターゲット・データベースはソースと同じデータを保持しますが、ソースとは異なるデータベースです（たとえば、バックアップを相互に使用することはできません）。Oracle GoldenGate の論理レプリケーションは、より高度なプロセスであり、Data Guard の物理レプリケーションには適用されない複数の前提条件があります。Oracle GoldenGate では、これらの前提条件の代わりに、独自の機能を提供して、高度なレプリケーション要件に対処しています。各レプリケーション・テクノロジーのトレードオフ、およびどちらか一方を使用することが求められる場合、または両方のテクノロジーを補完的に使用することが求められる場合について詳しくは、『MAA Best Practices:Oracle Active Data Guard and Oracle GoldenGate』を参照してください。

Platinum リファレンス・アーキテクチャでは、Oracle GoldenGate の双方向レプリケーションを使用して、停止時間ゼロのメンテナンスと移行が実装されます。このようなシナリオには、次のような特徴があります。

• メンテナンスが最初にターゲット・データベースで実施されます。 • ソースとターゲットが、Oracle GoldenGate のレプリケーションを使用して、複数のバージョン

にまたがって同期されます。

• 新しいバージョンまたはプラットフォームが同期されて安定すると、ユーザーは双方向レプリケーションを使用して、新しいプラットフォームに停止時間ゼロで徐々に移行できます。ユーザーは、処理が完了し、新しいバージョンを実行するデータベースに新しい接続が転送されたら、古いバージョンで動作するデータベースへの接続を自然に終了させます。双方向レプリケーションでは、移行プロセスの間、古いバージョンと新しいバージョンの同期が維持されます。同期を維持することで、ワークロードの増加中に、新しいバージョンで予期せぬ問題が発生した場合に、高速フォールバック・オプションを利用できます。

簡単な手順ではありませんが、バックエンドのデータベース・オブジェクトを変更するアプリケーション・アップグレードにも、Oracle GoldenGate の双方向レプリケーションを使用できます。Oracle GoldenGate を使用して複数のバージョンにまたがってレプリケートを実行するには、新し


いリリースで変更または追加されるデータベース・オブジェクトについての、開発者レベルの知識が必要となります。さらに、アプリケーションの新しいリリースごとに、Oracle GoldenGate のレプリケーションを使用してバージョン間マッピングを実装する必要があります。

また、同じデータの複数コピーに対して読取り/書込み接続が常時必要な場合に、双方向レプリケーションを使用して可用性サービス・レベルを向上させることもできます。双方向レプリケーションは、アプリケーションに対して透過的ではありません。複数のデータベース内で同じレコードが同時に変更される場合は、競合の検出と解決が必要になります。さまざまな障害状態やレプリケーション遅延の影響を慎重に考慮することも必要です。

また、Oracle GoldenGate のレプリケーションは非同期プロセスであるため、Data Guard や Oracle Active Data Guard と同じデータ損失ゼロの保護は提供されません。そのため、Silver、Gold、Platinum の各リファレンス・アーキテクチャでは、Data Guard および Oracle Active Data Guard を使用して計画外停止時に HA を提供します。HA イベントが発生してもデータ損失はゼロでなければならないという前提があるためです。データ損失ゼロの保護が必要ない場合は、Data Guard またはOracle Active Data Guard の代わりに、Oracle GoldenGate のレプリケーションを使用できます。

Platinum MAA の顧客の多くは、Data Guard ファスト・スタート・フェイルオーバーと GoldenGateの両方を補完的に使用し、アップグレードおよび移行のソリューションを停止時間ゼロで達成しつつ、なおデータベース障害時のデータ損失ゼロを維持しています。詳しくは、『Oracle Data Guardと Oracle GoldenGate による透過的なロール移行』を参照してください。

データベースの本番コピーが Data Guard スタンバイによって保護されている限り、Oracle GoldenGate を使用する場合に、計画メンテナンス時のデータ損失を懸念する必要はありません。

エディションベースの再定義

エディションベースの再定義では、データベースをオフラインにすることなく、データベース・オブジェクトの変更を必要とするオンラインのアプリケーション・アップグレードを実行できます。古いバージョンのアプリケーションとデータベースをオンラインにしたままで、すべての変更を実装できます。アップグレードのプロセスが完了したら、Oracle データベースの同じコピーに対して、アップグレード前のアプリケーションとアップグレード後のアプリケーションを同時に使用できます。既存のセッションは、ユーザーがセッションを終了するまでは、アップグレード前のバージョンを引き続き使用でき、新しいセッションは、アップグレード後のバージョンを使用できます。アップグレード前のバージョンのアプリケーションは、アップグレード前のバージョンを使用するセッションがなくなった時点で廃止できます。

EBR では、次の方法でオンライン・アプリケーション・アップグレードが行われます。

• コード変更は、新しいエディションに内部的にインストールされます。 • データ変更を安全に実行するために、旧エディションでは表示されない新しい列や表にのみ変

更を書き込みます。エディションごとに異なる表示で表を公開するエディション・ビューにより、各エディションに固有の列のみが表示されます。

• クロスエディション・トリガーにより、古いエディションで行われたデータ変更が、新しいエディションの列に伝播され、逆方向にも同様に伝播されます。


EBR を使用するには、Oracle GoldenGate の停止時間ゼロのアプリケーション・アップグレードと同じく、EBR を組み込む開発者にアプリケーションに関する深い知識が必要であり、手間もかかります。Oracle GoldenGate とは異なり、1 回の作業で EBR を実装できます。その作業を行っておけば、後続の新規リリースのアプリケーションで EBR を使用するために必要な作業は最小限で済みます。EBR は、非常に複雑なアプリケーションでも使用できることが示されており、たとえば Oracle E-Business Suite 12.2 では、オンライン・パッチ適用で EBR を使用しています。EBRは Oracle Databaseに含まれている機能であり、追加のコストはかかりません。

Platinumのまとめ

Platinum リファレンス・アーキテクチャが対応する RTO および RPO サービス・レベル要件を表 5に要約します。前提条件は、アプリケーション・コンティニュイティが必須で、停止をマスクできることです。さらに、アプリケーション停止時間をゼロにするために Oracle GoldenGate およびエディションベースの再定義が活用されていることも前提です。

表5：Platinumのリカバリ時間目標（RTO）および潜在的データ損失（RPO）



リカバリ可能またはリカバリ不能なRACインスタンス障害 0（ゼロ）または数秒 0（ゼロ）

リカバリ可能またはリカバリ不能なRACサーバー障害 0（ゼロ）または数秒 0（ゼロ）


0（ゼロ）または数秒 0（ゼロ、SYNC使用）





0（ゼロ）または数秒 0（ゼロ）

プラットフォームの移行 0（ゼロ） 0（ゼロ）


0（ゼロ） 0（ゼロ）

Platinum の要件：DR サイトとしてのオンプレミス・デプロイメントには、Oracle Enterprise Edition、Oracle RAC、Oracle Active Data Guard、Oracle GoldenGate、Oracle Multitenant（データベース統合のためのオプション）、および Oracle Enterprise Manager のライフサイクル管理、診断、チューニング・パックが必要です。クラウド・デプロイメントには、Oracle Extreme Performance DBaaS（PaaS）または Exadata Cloud Service および Oracle GoldenGate Cloud Service が最低限必要です。Platinum では、Oracle Database Backup Cloud Service も使用します。


Oracle Cloud Infrastructure – MAAの概念実証および構成プラクティス

このセクションでは、すでに確認および検証されているパフォーマンスと HA の期待できる利点を一部ご紹介します。

破損の防止、検出、自動修復

データ破損を防止、検出、および自動的に修復する Oracle Database の機能は、すべての MAA リファレンス・アーキテクチャに共通しています。各チェックは、Oracle データ・ブロックや REDO構造に関する特定の知識を使用した、Oracle Database 独自のものです。メモリ内で、または I/O スタックの障害が原因で発生する可能性があるデータ破損の広がりを防止することにより、HA を向上し、データを保護します。これらの機能の概要を表 6 に示します。表 6 の"タイプ"列は、物理的な破損と論理的な破損の検証がいつ実行されるかを示しています。

• 手動チェックは、管理者によって開始されるか、定期的なチェックを実行するスケジュールされたジョブによって一定の間隔で開始されます。

• 実行時チェックは、データベースが開いている間に、バックグラウンド・プロセスによって常時自動的に実行されます。

• バックグラウンド・チェックは、通常であればリソースがアイドル状態になる間にのみ、定期的にスケジュールされた間隔で実行されます。


表6：破損の防止、検出、自動修復

タイプリファレンス・アーキテクチャ

機能物理的なブロック破損論理的なブロック破損

手動すべて Dbverify、Analyze 物理的なブロック・チェック

ブロック内およびオブジェ

クト間の整合性に関する論

理チェック

自動（OCI バックアップ

API使用）

すべて RMAN バックアップおよびリストア中の物理的なブロック・チェック

ブロック内の論理チェック

実行時 Silver – パターン2、 Gold、 Platinum

Data Guard、 Active Data Guard

スタンバイでの物理的なブロック・チェック

プライマリとスタンバイの

間の強力な分離によってシ

ングル・ポイント障害を解消

自動データベース・フェイルオーバー

書込み損失破損の検出、自

動シャットダウン、フェイ

ルオーバー

スタンバイでのブロック内

論理チェック

実行時 GoldおよびPlatinum Oracle Active Data Guard

物理的な破損の自動修復

実行時すべて Oracleブロック・チェックサムおよびブロッ

ク・チェック

OCI Data Guardのすべてのデプロイ済みシス

テムについてデフォル

トで有効。

インメモリのブロックおよびREDOチェックサム

インメモリのブロック内論理チェック

実行時すべて ASM ローカル・エクステント・ペアを使用した自動的な破損検出と修復（外部冗長

性（RAC VM）の代わりにASMソフトウェア冗長性（Exadata）を使用している場合）

実行時すべて – Exadataのみ1

Exadata1 書込み時のハード・チェック

書込み時のハード・チェック

バックグラウンド

すべて – Exadataのみ1

Exadata1 ディスクの自動的なスクラブと修復

ハード検証と、ディスクの自動的なスクラブと修復は、Exadata ストレージ固有の機能です。ハード検証によって、Oracle Database が物理的に破損したブロックをディスクに書き込むことが回避されます。ハード・ディスクの自動的なスクラブと修復は、アイドル・リソースが存在する場合に、破損または摩耗したディスク・セクター（ストレージのクラスタ）や物理的または論理的な欠陥があるハード・ディスクを定期的に検査して修復します。Exadata は、別のミラー・コピーからデータを読み取ることで不良セクターを修復するよう、ASM にリクエストを送信します。デフォルトでは、ハード・ディスク・スクラブは 2 週間おきに実行されます。


OCIクラウド・バックアップおよびObject Storageを使用したリカバリ

以下では、Object Storage を使用する Oracle Cloud Backup Service との間におけるバックアップとリカバリのベスト・プラクティスについて説明します。別途説明する場合を除き、MAA で推奨される設定は、2018 年 11 月のデータベース・インフラストラクチャ・ソフトウェア以降の OCI クラウド・バックアップ API が使用するデフォルト設定です。

• OTN から Oracle Database Cloud Backup Module をインストールし、Oracle RMAN 環境を適切に構成しておく必要があります。自動バックアップに関して、この点はバックアップ・エージェントが対処済みです。

RMAN>CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS

'SBT_LIBRARY=/home/oracle/OPC/lib/libopc.so,

ENV=(OPC_PFILE=/u01/products/db/12.1/dbs/opcodbs.ora)';

• CPU オーバーヘッドを最小限にしながらデータ転送を最適化するために、MAA では以下のデフォルト設定を推奨しています。

a. RMAN COMPRESSION を LOW に設定します（ただし、関連する表領域がすでに OLTP 圧縮または HCC 圧縮を使用している場合を除く）。RMAN COMPRESSION を MED に設定すると、圧縮率は上昇しますが、CPU 利用率も増えます。

RMAN> CONFIGURE COMPRESSION ALGORITHM ‘LOW’;

RMAN>BACKUP DEVICE TYPE SBT AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG

FORMAT '%d_%U';

b. RMAN PARALLELISM をデータベース・サーバーの台数 x4 の数値に設定します。2 ノードの Oracle RAC の場合、PARALLELISM を 8 に設定します。

RMAN> CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 8 BACKUP TYPE TO BACKUPSET;

• MULTISECTION はデフォルト設定の 64 GB を使用します。マルチセクション・バックアップ（Oracle Database 11g 以降導入）の目的は、Oracle RMANチャネルでサイズの大きな単一ファイルをパラレルでバックアップできるようにすることです。Oracle RMAN では、処理を複数のチャネル間で分割し、各チャネルで 1 つのファイル内の 1 つのファイル・セクションをバックアップします。別々のセクションでファイルをバックアップすることにより、大きなデータファイルのバックアップにおけるパフォーマンスを向上させることができます。たとえば、表領域に 800 MB のデータファイルが 1 つ存在し、4 つの SBT チャネルが構成されており、SBT デバイスの PARALLELISM 設定が 4 に設定されているとします。この場合、この表領域にあるデータファイルは、以下に示すようなファイル・セクションに分割することができます。小規模データファイルの場合、SECTIONSIZE の設定は無視されます。


• "毎週の全体バックアップと毎日の増分バックアップ"戦略の使用増分バックアップの目標は、前回のバックアップ以降に変更されたデータ・ブロックのみをバックアップすることです。これには多くの利点がありますが、この標準的アプローチに移行する前に、RTO の要件を満たすことができるかどうか評価する必要があります。この戦略には次のような利点があります。

a. 毎日のバックアップに必要な時間が削減されます。バックアップ時間が短くなるため、バックアップの頻度も上げて RPO を減らすことが可能になります。

b. ネットワーク上でバックアップする場合に必要とされるネットワーク使用量とネットワーク帯域幅が削減されます。

c. バックアップのオーバーヘッドと読取り I/O の回数が削減されます。

トレードオフは、前回の累積バックアップおよびその後の増分と REDO をリストアしてデータベースをリカバリしなければならないため、リストアとリカバリの時間が長くなることです。

• アーカイブを 1 時間ごとにバックアップし、RPO やデータ損失を削減アーカイブ・バックアップは、それまでバックアップされていないどのアーカイブに対しても、1 時間ごとに自動的に実行されます。アーカイブはファスト・リカバリ領域が自動的に管理するため、アーカイブの管理や消去をユーザーが実行することはありません。

Cloud OCI バックアップ/リストアについて詳しく取り上げたドキュメントは後日公開予定です。図8 は、MAA パフォーマンス観測の例です。OCI バックアップ/リストア API は、MAA のデフォルトの推奨事項を使用するように変更中です。パフォーマンスに関する数値のほとんどは、OCI 上のExadata に基づいています。より小規模な OCI コンピュートまたは Oracle RAC VM シェイプには、ネットワークおよびオブジェクト・ストレージのリソース管理コントロールが含まれる可能性のあることが示されています。これは、一部のバックアップ/リストア速度が低下する可能性があることを意味します。


図9：バックアップ/リストアのパフォーマンス観測

Data Guardファスト・スタート・フェイルオーバー

Oracle MAA ベスト・プラクティスでは、短いリカバリ時間目標が要求されるすべての Data Guardクラウド・デプロイメントに対し、Data Guard ファスト・スタート・フェイルオーバーをデプロイする必要があります。OCI におけるファスト・スタート・フェイルオーバーのデプロイは、以下の手順を使用して手動で構成できます。

ファスト・スタート・フェイルオーバーの構成

1. 構成がまだ存在しない場合、プライマリおよびスタンバイ・データベースに接続する Oracle Netエイリアスを作成します。これが Oracle RAC 構成の場合、エイリアスは SCAN 名を使用して接続します。

chicago = (DESCRIPTION = (ADDRESS_LIST =

(ADDRESS=(PROTOCOL= TCP) (HOST=prmy-scan)(PORT=1521)))

(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = chicago)))

boston = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS=(PROTOCOL= TCP) (HOST=stby-scan)(PORT=1521)))

(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = boston)))


2. プライマリとスタンバイの両方のリスナーについて静的 SID エントリを作成します。Oracle Clusterware がインストールされている場合、構成内の全ホストのグリッド・インフラストラクチャ・ホームにある、ローカル・ノードの listener.ora に静的 SID エントリを追加します。Oracle Data Guard Broker では Oracle Clusterware または Oracle Restart を使用してインスタンスを再起動するため、Oracle Restart、Oracle RAC One Node、または Oracle RAC によって管理されるOracle Data Guard Broker 構成では、Oracle Database 12.1.0.2 以降、静的な"_DGMGRL"エントリは不要になっている点に注意してください（詳細については、MOS ノート 1387859.1 を参照）。

LISTENER = (DESCRIPTION =

(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=host_name) (PORT=port_num))))

SID_LIST_LISTENER=(SID_LIST=(SID_DESC=(SID_NAME=sid_name) (GLOBAL_DBNAME=db_unique_name_DGMGRL.db_domain) (ORACLE_HOME=oracle_home) (ENVS="TNS_ADMIN=oracle_home/network/admin"))

Oracle Clusterware 環境では、以下に示す追加の考慮事項にも注意してください。

• 静的サービスは、すべてのノードの GRID_HOME で、listener.ora ファイルに設定しなければなりません。

• 静的サービス定義の ORACLE_HOME listener.ora パラメータは、GRID_HOME ではなく、インスタンスの ORACLE_HOME に設定しなければなりません。

• ENVS listener.ora パラメータは、静的サービス定義において、TNS_ADMIN 環境変数を適切な network admin ディレクトリ（通常、Oracle Database の Oracle Home のnetwork admin ディレクトリ）を明示的に設定するために使用しなければなりません。

• Oracle RAC One Node またはポリシー管理 Oracle RAC 環境では、可能なインスタンスそれぞれの SID_NAME を SID_LIST で指定する必要があります。各インスタンスのSID_NAME は、そのインスタンスの INSTANCE_NAME データベース初期化パラメータと一致しなければなりません。

3. 上記の変更が加えられたすべてのリスナーを再起動または再ロードします（プライマリ・ノードおよびスタンバイ・ノード）。

4. プライマリ・ホスト上で、DGMGRL を使用して接続し、構成を作成します。

[oracle@exa503 /etc]$ dgmgrl sys/password DGMGRL> create configuration 'dg_config' as primary database is 'chicago' connect identifier is chicago;

Configuration "dg_config" created with primary database "chicago"

DGMGRL> add database 'boston' as connect identifier is boston;

Database "boston" added

DGMGRL> enable configuration; Enabled.


5. SHOW CONFIGURATION コマンドを使用して、構成が問題なく作成されたことを確認します。

DGMGRL> show configuration; Configuration - dg_config Protection Mode:MaxPerformance Databases: chicago - Primary database boston - Physical standby database

Fast-Start Failover:DISABLED

Configuration Status: SUCCESS

6. 障害となったプライマリをフェイルオーバーのロール移行後に復旧するにはフラッシュバック・データベースが必要です。プライマリとスタンバイの両方でフラッシュバックを有効化します。

DGMGRL> CONNECT sys/@chicago DGMGRL> SQL "ALTER DATABASE FLASHBACK ON"; DGMGRL> CONNECT sys/@boston DGMGRL> EDIT DATABASE boston SET STATE=APPLY-OFF; DGMGRL> SQL "ALTER DATABASE FLASHBACK ON"; DGMGRL> EDIT DATABASE boston SET STATE=APPLY-ON;

Oracle の推奨事項に従�

Documents

Oracle Cloud Infrastructure（OCI）のデプロイメント向け ......1 | Oracle Cloud Infrastructure（OCI）のデプロイメント向けOracle MAA ブループリント 免責事項

Oracle Cloud Infrastructure（OCI）のデプロイメント向け ......1 | Oracle Cloud Infrastructure（OCI）のデプロイメント向けOracle MAA ブループリント免責事項