oracle exadata cloud at customerとoracle … exadata cloud at customerとoracle exadata cloud...
TRANSCRIPT
Oracle Exadata Cloud at Customerと Oracle Exadata Cloud Serviceを使用した Oracle Maximum Availability Architecture Oracle ホワイト・ペーパー | 2017 年 11 月
Oracle Exadata Cloud at CustomerとOracle Exadata Cloud Serviceを使用したOracle Maximum Availability Architecture
目次 概要 ................................................................................................................................................................ 1
Oracle ExaCS と Oracle ExaCC の管理 ..................................................................................................... 3
Oracle ExaCS と Oracle ExaCC の MAA リファレンス・アーキテクチャ ......................................... 4
SILVER ................................................................................................................................................... 4
GOLD..................................................................................................................................................... 5
PLATINUM ............................................................................................................................................ 6
アプリケーション・スタックの保護 ....................................................................................................... 8
Oracle ExaCC と Oracle ExaCS の高可用性の利点 ................................................................................ 9
ハードウェア・コンポーネント ...................................................................................................... 9
冗長データベース・サーバー ........................................................................................... 9
冗長ストレージ ............................................................................................................... 10
冗長接続 .......................................................................................................................... 11
冗長電源 .......................................................................................................................... 11
ソフトウェア・コンポーネント： ............................................................................................... 11
ファームウェアとオペレーティング・システム ........................................................... 11
データベース・サーバー層 ............................................................................................. 12
ストレージ層 ................................................................................................................... 12
計画外停止への対応 ................................................................................................................................ 12
計画メンテナンスへの対応 .................................................................................................................... 13
Oracle ExaCC および Oracle ExaCS のバックアップとリカバリのオプション ............................. 14
テスト環境の重要性 ................................................................................................................................ 15
結論 ............................................................................................................................................................. 16
付録 A：その他の Exadata 独自の高可用性機能と利点 ................................................................... 17
付録 B：計画メンテナンスへの対応 .................................................................................................... 20
1 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
概要
Oracle Exadata Database Machine は、Oracle データベースで継承される高可用性機能によって、パフォーマンスとコスト効率を大幅に改善できるように設計されています。Exadata は、スケーラブルな高パフォーマンス・データベース・サーバー、最先端の PCI フラッシュを搭載したスケーラブルなインテリジェント・ストレージ・サーバー、およびすべてのサーバーとストレージを接続する超高速 InfiniBand 内蔵ファブリックを備えた、最新のクラウドベース・アーキテクチャです。Exadata 独自のソフトウェア・アルゴリズムによって、ストレージ、コンピューティング、InfiniBand ネットワーキングにデータベース・インテリジェント機能を実装することで、他のプラットフォームよりも低コストで高パフォーマンスと大容量を実現しています。
Exadata のすべての利点を利用する Oracle Database Exadata Cloud Service（Oracle ExaCS）は現在、パブリック・クラウドでミッション・クリティカルなデータベースを実行し、クラウドのオフサイトの特性をディザスタ・リカバリに利用したい顧客向けに、Oracle Public Cloud で提供されています。クラウドのメリットはほしいけれども、データベースをデータセンター内にローカルに配置する必要がある場合は、Oracle Database Exadata Cloud at Customer（Oracle ExaCC）を選択できます。Oracle ExaCC は世界でもっとも高度なデータベースを顧客に提供し、国の法律、業界規制、企業方針のためにデータベースをパブリック・クラウドに移動できない顧客、または緊密に統合された他のオンプレミス IT インフラストラクチャからデータベースを移動することが困難な企業に最適です。
Oracle ExaCS または Oracle ExaCC にデプロイされるデータベースは、既存のオンプレミス・データベース、またはオラクルのパブリック・クラウドにデプロイされているデータベースと100 %互換性があります。
Oracle Maximum Availability Architecture（Oracle MAA）は、Oracle の高可用性（HA）テクノロジーを統合して使用するための一連のベスト・プラクティス構想です（図 1 を参照）。Oracle MAA のベスト・プラクティスは、Oracle Database 高可用性機能の統合された使用を継続的に検証している Oracle 開発者のチームによって作成および保守されています。また、Oracle MAA チームによって実行される検証には実際のカスタマー・エクスペリエンスも統合されるため、習得した教訓が他の顧客にも広まります。
2 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
図1：Maximum Availability Architecture
Oracle Maximum Availability Architecture（Oracle MAA）と Oracle ExaCS および Oracle ExaCCを統合すると、クラウド環境内の Oracle Database 向けの、非常に包括的な高可用性ソリューションが実現します。実際に MAA 構成の Exadata は、IDC（アナリスト企業）によって99.999 %以上の可用性を実現するシステムと認められており、IDC の AL4 フォルト・トレラント市場セグメントに分類されています。
Exadata はソフトウェア、サーバー、ストレージ、ネットワークを統合した成熟したシステムです。これらすべての要素が Oracle MAA のベスト・プラクティスに基づき、データベースとアプリケーションの非常に高い可用性とパフォーマンスを実現できるように事前構成されています。あらゆる業界のパブリック・セクターおよびプライベート・セクターのミッション・クリティカル・アプリケーションが、Exadata MAA を利用しています。すべての Exadata システムは、オラクル社内および全世界のミッション・クリティカルな顧客によって、さまざまな可用性テストを受けています。グローバルな Exadata コミュニティの成長が、あらゆるExadata システムの利益となる将来的な機能向上につながります。
本書では、Oracle ExaCC および Oracle ExaCS の固有の高可用性機能と、オラクルの MAA リファレンス・アーキテクチャおよびベスト・プラクティスによってこの機能を拡張し、さらに可用性を向上させる方法を説明します。Oracle Real Application Cluster、Oracle Active Data Guard、Oracle Multitenant などのデータベース高可用性オプションは、Oracle ExaCC とOracle ExaCS のサブスクリプションに含まれています。
3 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
本書のおもな内容は次のとおりです。
» Oracle ExaCC と Oracle ExaCS の MAA リファレンス・アーキテクチャ
» Oracle ExaCC と Oracle ExaCS の HA の利点
» 計画外停止への対応
» 計画メンテナンスへの対応
» クラウドのバックアップとリカバリのオプション
このホワイト・ペーパーは、CIO、エンタープライズ・アーキテクト、データベース・アーキテクト、データベース管理者、技術マネージャー、ソリューション・アーキテクト、アプリケーション・アーキテクト、およびその他のデータベース・アーキテクチャの全体的な設計に影響力のある読者を対象としています。
Oracle ExaCS とOracle ExaCCの管理
Oracle MAA のベスト・プラクティスの詳細を説明する前に、Oracle ExaCS または Oracle ExaCC で顧客が実行できる操作と、オラクルが管理する操作について理解しておくことが重要です。
顧客は Oracle Database と OS のすべての機能にアクセスできるため、オンプレミスの Oracle デプロイメントから Oracle ExaCC または Oracle ExaCS にスムーズかつ簡単に移行できます。各データベ ー ス・ インス タ ンス は、Exadata シ ス テ ム の デ ー タ ベ ー ス ・ サ ー バ ー ご と に 仮 想 マ シ ン（DomU）で構成されており、この仮想マシンは顧客によって所有されています。顧客は、DomUの root 権限と Oracle データベースの DBA 権限を持ちます。システムを自由に構成し、Exadataデータベース・サーバーにエージェント・ソフトウェアをさらにロードして、ビジネス基準やセキュリティ監視の要件を満たすことができます。
また、バックアップ、パッチ適用、アップグレードのクラウド自動化による支援を受けながら、通常のデータベースと OS の管理作業を実行できます。データベースと OS の更新は、顧客が任意のスケジュールで開始します。Oracle ExaCS モデルでは、オラクルが Exadata インフラストラクチャをデプロイ、管理します。Oracle ExaCC モデルでは、Oracle Exadata Cloud at Customer の基盤となるインフラストラクチャをオラクルがデプロイし、管理します。インフラストラクチャには、Exadata InfiniBand ネットワーク、Oracle Exadata Database と Oracle Exadata Storage の物理サーバー、ファームウェア、Dom0、Exadata Storage Server Software が含まれます。顧客のデータセンターにデプロイされるので、電力、スペース、冷却、ネットワーク・インフラストラクチャは顧客が用意します。このモデルにより、顧客はデータベース・インフラストラクチャの管理ではなく、ビジネス・アプリケーションの要件に集中できます。
4 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
Oracle ExaCS とOracle ExaCCのMAAリファレンス・アーキテクチャ
Oracle MAA のベスト・プラクティスでは、あらゆる規模と業種の企業に必要な、あらゆる可用性とデータ保護に対応する Exadata プラットフォームに適用できる、3 つの高可用性リファレンス・アーキテクチャを定義しています。MAA アーキテクチャ（または層）は、Platinum、Gold、Silverと定義されています。これらのサービス・レベルは図 2 のとおりです。
図2：MAAリファレンス・アーキテクチャ
各層はさまざまな MAA リファレンス・アーキテクチャを使用して、最適な Oracle 高可用性機能をデプロイします。このため、最小限のコストで簡単かつ確実に所定のサービス・レベルを達成できます。これらの層では、あらゆる種類の計画外停止（データ破損、コンポーネント障害、システムやサイトの停止など）、および（メンテンス、移行などによる）計画停止に明示的に対応します。
MAA リファレンス・アーキテクチャを Oracle ExaCC および Oracle ExaCS と統合することで、他のプラットフォームより大幅に少ない管理作業とコストでより高いレベルの可用性を実現できます。MAA リファレンス・アーキテクチャは"Bronze"レベルから始まりますが、Exadata ベースのシステムにリファレンス・アーキテクチャの Bronze 層はありません。各 Exadata システムには、局所的な停止に対する高可用性が組み込まれているためです。
注：ここで説明する MAA リファレンス・アーキテクチャは、特に明記されていないかぎり、Oracle ExaCS と Oracle ExaCC の両方に適用できます。
SILVER
Silver レベルの MAA アーキテクチャでは、バックアップとリカバリによって簡単にディザスタ・リカバリを実行できます。Oracle Real Application Clusters（Oracle RAC）または Oracle RAC One1を
1 Oracle RAC One には Oracle ExaCC を手動で構成でき、将来的に Oracle ExaCS でサポートされます。リストアおよびリカバリするデータ量によって
は、リカバリ時間が長くなる可能性があります。データ損失の可能性は、最終バックアップの実行時間によって変わります。図 3 に、SILVER リファ
レンス・アーキテクチャを示します。
5 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
使用してクラスタ化されたデータベースをデプロイすることで、高可用性を実現できます。Oracle RAC によって、計画停止と計画外停止のいずれの場合もサーバー・レベルで保護できます。ローカル・サイトでバックアップが定期的に実行され、このバックアップがディザスタ・リカバリ用にリモート・サイトでレプリケートされます。非常に高い密度と ROI でデータベースを統合するには、コンテナ・データベースとよりプラガブルなデータベースを使用する Oracle Multitenant アーキテクチャを推奨します。Oracle ExaCC のバックアップでは、Zero Data Loss Recovery Appliance（ZDLRA または Recovery Appliance）の使用を推奨します。NFS ストレージを使ってバックアップするための自動ツールが用意されています。ディザスタ・リカバリに対応するため、ストレージをリモート・サイトにレプリケートされるように構成します。Oracle ExaCS では、Oracle Database Backup Cloud Service がバックアップ先として構成されています。Oracle ExaCS と Oracle ExaCC には、日単位と週単位のバックアップを実行する自動ツールが用意されています。
図3：SILVERリファレンス・アーキテクチャ
GOLD
Gold では、Oracle Active Data Guard を使ってリアルタイムなデータベース・レプリケーションを他のデータセンターに追加することで、Silver 層を拡張します。このアーキテクチャを使用すると、サイト障害に対してデータベースを保護できるだけでなく、（通常はリカバリが不要なため）フェイルオーバーが高速になり、データ損失をゼロにできる可能性があります。ローカル・データセンターに Oracle ExaCC をもう 1 つ追加することで、ローカル・フェイルオーバー用に追加のデータ・コピーを用意できます。2 つのデータセンター間の距離が長くネットワークの待機時間が長い状況でフェイルオーバー時のデータ損失をゼロにしたい場合は、Active Data Guard Far Sync 機能をデプロイします。Oracle ExaCS では、コンピュートまたは DBCS インスタンスを使用して、Far Sync をデプロイできます。Oracle ExaCC は、どの x86 Linux-x86 64 ビット・サーバーにもデプロイできます。
Oracle ExaCC では、Oracle Data Guard レプリケーションの SYNC モードを使用して、ローカル・スタンバイを Oracle Data Guard のファスト・スタート・フェイルオーバー、統合型アプリケーション・フェイルオーバーと一緒にデプロイして、ゼータ損失ゼロを実現できます。すべてのデータベースのローカル・バックアップが構成されます。この構成によって、完全な分離と保護が実現します。Active Data Guard を使用すると、分析問合せ、レポート作成、バックアップ、テストなどの読取り専用操作をスタンバイ・データベースにオフロードできます。フェイルオーバー時に同じ品質保証契約（SLA）を達成するには、対称または同等の Exadata 構成を推奨します。
6 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
Oracle ExaCC のディザスタ・リカバリをデータセンターにデプロイしている場合に、顧客の 2 つのデータセンター間のネットワーク待機時間が十分に短ければ（1 桁台）、両方の Oracle ExaCC の管理には 1 つのコントロール・プレーンで十分です。ネットワーク待機時間が長い場合、各サイトで1 つのコントロール・プレーンを使用することを推奨します。障害を隔離するため、Far Sync インスタンスとオブザーバは、データベースとは別の可用性ドメイン（物理的に別個の場所、電力など）にデプロイされます。図 4 に、Gold MAA リファレンス・アーキテクチャを示します。
図4：GOLDリファレンス・アーキテクチャ
PLATINUM
計画停止時間と計画外停止時間の両方でアプリケーション停止ゼロとデータ損失ゼロという完全なデータ保護を達成するため、Oracle GoldenGate、Oracle 12c のアプリケーション・コンティニュイティ、エディション・ベースの再定義、Oracle 12c Far Sync Data Guard などの追加コンポーネントが構成に追加されます。Oracle Active Data Guard により、データは SYNC モードで他の可用性ドメインにローカルにレプリケートされ、別のデータセンターのリモート・サイトにもレプリケートされます。データ損失ゼロを達成するため、Far Sync Active Data Guard がデプロイされます。サイトごとに独自のバックアップ戦略を立てる必要があります。アプリケーション・アップグレード時の停止時間をゼロにするため、Oracle GoldenGate とエディション・ベースの再定義がデプロイされます。Platinumデプロイメントは通常、非常に高い可用性要件を満たせるようにカスタム構成されます。
7 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
図5：PLATINUMリファレンス・アーキテクチャ
つまり、停止時間やデータ損失の可能性に対する保護レベルは、リファレンス・アーキテクチャごとに異なります。各データベースの SLA に基づき、これらのアーキテクチャを組み合わせてデプロイできます。たとえば通常、ミッション・クリティカルな本番データベースは Gold またはPlatinum レベルのデータ保護でデプロイされますが、テスト・データベースは Silver レベルのデータ保護でデプロイできます。
8 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
表 1 は、Exadata MAA の各リファレンス・アーキテクチャで達成可能な高可用性品質保証契約（SLA）の概要を示しています。すべてのケースで、Exadata テスト・システムを使用することを推奨します。詳しくは、本書の「テスト環境の重要性」を参照してください。
表1：MAAリファレンス・アーキテクチャの要約
MAA アーキテクチャ
デプロイメント・モデル 停止時間の可能性 （RTO）
データ損失の可能
性（RPO） 高可用性 ディザスタ・
リカバリ
Silver（Oracle RAC/Oracle RAC Oneを使用）
データセンター内のOracle ExaCC/ExaCSプライマリ + バックアップ・ストレー
ジを、別のデータセンター
へのレプリケーションを使
用して構成。 Multitenantにより非常に高
密度な統合を実現。
ローカル障害の場合、
数秒 災害の場合、数時間
数時間～1日 Oracle ExaCC:リカ
バリ・アプライア
ンスを使用した場
合は数秒
Oracle RACまたはOracle RAC One サーバー、ネットワー
ク、ストレージの障害に
対応するExadata固有のHA
リモート・バック
アップ/リストア
Gold（Silver + Oracle Active Data Guard DRを使用）
データセンター内のOracle ExaCC/ExaCSプライマリ
を、別のデータセンター内
のOracle ExaCS/ExaCCに
レプリケートする。Oracle ExaCCでは同じデータセ
ンター内の別のOracle ExaCCにデータをレプリ
ケートできるが、独立性を
確保しデータ損失ゼロの高
速フェイルオーバーを実現
するため、電源などは別に
する。 両方のサイトでのローカ
ル・バックアップ。
数秒 ゼロ（0）*～数秒 Oracle RAC Oracle Active Data Guard（SYNC） ネットワークおよびスト
レージに関するExadata固有のHA
Oracle Active Data Guard
Platinum（Gold + Oracle GoldenGate + アプリケーショ
ン・コンティニュイ
ティ + エディショ
ン・ベースの再定義
を使用）
データセンター内のOracle ExaCC/ExaCSプライマリ
を、リモート・データセン
ター内のOracle ExaCS/ExaCCにレプリ
ケートする。Oracle ExaCCプライマリはロー
カルのOracle ExaCCにも
レプリケートされる。
Oracle GoldenGateやエ
ディション・ベースの再定
義などの機能によって、停
止時間ゼロのアプリケー
ション・アップグレードが
可能。アプリケーション・
コンティニュイティによ
り、アプリケーションへの
影響がゼロ。 両方のサイトでのローカ
ル・バックアップ。
アプリケーションへの
影響がゼロ 0（ゼロ） Oracle RACまたは
Oracle Active Data GuardとFSFO ネットワークおよびスト
レージに関するExadata固有のHA
Oracle Active Data Guard および Oracle GoldenGate
アプリケーション・スタックの保護
MAA リファレンス・アーキテクチャはデータベース・レイヤーの保護に対応します。アプリケーション・レイヤーの保護も等しく重要ですが、アプリケーション・レイヤーの保護の詳細は本書の対象外です。どのアプリケーションも他とは異なり、データベースでさまざまな I/O 特性を示すからです。ただし、アプリケーションをデータベース層に併置することを推奨します。データベース層は、Data Guard レプリケーションを使って保護されます。次のいずれかの方法で、フェイルオーバーおよびスイッチオーバー中にアプリケーションをデータベース層に併置できます。
1. アプリケーション・バイナリを事前にインストールした状態で、プライマリ・サイトとスタンバイ・サイトでアプリケーションのホスト用に対称のコンピュート・ノードを使用します。データベースでデータベース・ファイル・システム（DBFS）を使用すると、RSYNC
9 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
ユーティリティを使用してアプリケーション・データを定期的に DBFS にコピーできます。その後、アプリケーション・データは Oracle Active Data Guard レプリケーションの一部としてスタンバイ・サイトにレプリケートされます。このため、DBFS からコンピュート・ノードにアプリケーション・データを RSYNC できます。
2. アプリケーション・データの同期のため、コンピュート・ノード間の定期的または連続的な RSYNC を使用します。この方法では、フェイルオーバー時やスイッチオーバー時にタイミングの調整が必要です。
3. Oracle ExaCC 環境で Oracle Enterprise Manager Grid Control をすでに使用している場合は、Oracle Site Guard を手動で構成して、サイト間のフェイルオーバーとスイッチオーバーを調整できます。ZFS レプリケーションなどのストレージ・レプリケーションの RSYNC を使用して、アプリケーション・スタックのレプリケーションを実行できます。
Oracle ExaCCとOracle ExaCSの高可用性の利点
FAN、PDU、バッテリ、スイッチ、ディスク、フラッシュ、データベース・サーバー、マザーボード、DIMM などのハードウェアの障害に対してエンド・ツー・エンドの可用性を達成するように設計および事前構成された Exadata Database Machine のすべての高可用性の利点が、Oracle ExaCCと Oracle ExaCS に継承されます。Exadata システムに対する広範なエンジニアリング・テストと統合テストが継続的に実施されています。次の項では、Exadata 固有の高可用性特性について説明します。これらの内容は、Oracle ExaCC と Oracle ExaCS にもすべて当てはまります。Oracle ExaCCと Oracle ExaCS 固有の拡張機能も具体的に示します。
ハードウェア・コンポーネント
冗長データベース・サーバー
Oracle Exadata には、Oracle Database 12c Release 1 または Release 2（12.1、12.2）、またはOracle Database 11g Release 2（11.2）を実行する業界標準の Oracle Database サーバーが事前構成されています。オラクルのエンジニアリング・チームとテスト・チームが、高可用性とスケーラビリティ、一時停止の最短化を実現できるようにファームウェア、ソフトウェア、ハードウェアの構成をチューニングし、事前構成しています。データベース・サーバーはクラスタ化されており、高帯域幅で待機時間が短い InfiniBand ネットワーク経由で各サーバーと通信します。この構成により、データベース・サーバーや Oracle RAC インスタンスの障害による影響を最小限に抑えられるため、アプリケーションの障害耐性が強くなっています。
たとえば、データベース・サーバー障害による一般的な非 Exadata データベース・サーバー排除では、データベース・サーバー停止の宣言前であっても、CSS misscount（ほとんどのシステムではデフォルトで 30～60 秒）を待機します。その間はクラスタ全体がフリーズし、アプリケーションが一時停止します。アプリケーションの停止時間は 30～60 秒になり、アプリケーションが安定した処理状態に戻るまでの一時停止時間が数分になる場合があります。それとは対照的に、Exadataではノード停止の高速検出が事前構成されており、一時停止時間が 2 秒以内に短縮されるため、アプリケーションの一時停止時間も 2 秒以内になります。データベース・サーバー障害後のアプリケーション停止の例については、図 6 を参照してください。
10 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
ま た 、 Exadata は 帯 域 幅 が 広 く 待 機 時 間 が 短 い た め 、 デ ー タ ベ ー ス 初 期 化 パ ラ メ ー タFAST_START_MTTR_TARGET を短く設定して、インスタンス障害やノード障害が発生した場合のアプリケーションの一時停止時間を短縮できます。データベース・パラメータを変更する場合も、本番システムの変更前に同等のテスト・システムでパフォーマンスへの影響を評価することを推奨します。
図6：データベース・サーバーの電源障害
冗長ストレージ
データベース・サーバー・ディスク・ドライブ、Exadata Storage Server ディスク・ドライブ、フラッシュ・ドライブ、Oracle Exadata Storage Server など、Exadata のストレージ・コンポーネントにはすべて冗長性があります。Oracle ExaCS モデルと Oracle ExaCC モデルでは、ストレージ・サーバーをオラクルが完全に管理します。Exadata Storage Server は、ハード・ディスク、フラッシュ・ディスク、フラッシュ・カード、およびストレージ・サーバー全体の障害に対応できるように構成されています。Oracle ExaCS と Oracle ExaCC では、DATA ディスク・グループと RECO ディスク・グループが Oracle Automatic Storage Management（Oracle ASM）の高冗長性で事前構成されており、データの冗長性とストレージの保護機能が非常に優れています。データベースのデータ・ブロックはストレージ・サーバー間でミラーリングされるため、Exadata ディスクや Exadata ストレージ・サーバーで障害が発生しても、データや可用性が失われることはありません。また、ディスク・ドライブはホット・プラグ可能です。
Exadata ストレージのハードウェアとソフトウェアは、ストレージ障害時のアプリケーションの一時停止時間が非常に短く、Exadata HARD と Exadata ディスク・スクラビングでデータを確実に保護できるように設計されています。他のプラットフォームでのストレージ障害と比べて、Exadataではディスク、フラッシュ、ストレージ・サーバーの障害時のアプリケーションへの影響が非常に軽微です。たとえば、Exadata のストレージ障害時のアプリケーションの停止および一時停止時間は 1 秒未満ですが、Oracle データベースや Oracle アプリケーションを実行する他のストレージでは数分～数秒です。
11 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
図7：ストレージ障害
冗長接続
Oracle ExaCC と Oracle ExaCS の InfiniBand ネットワークおよびスイッチは、オラクルがすべて管理します。デュアルポートの Quad Data Rate（QDR）、Host Channel Adapter（HCA）を使用した冗長な InfiniBand ネットワーク接続と冗長スイッチがすべて事前構成されています。
Exadata システム内でネットワーク障害が発生した場合、アプリケーションの一時停止時間は通常0 秒から 10 秒未満です。
冗長電源
Exadata には、高可用性を実現するために冗長型の配電盤（PDU）が搭載されています。これらのPDU はすべてオラクルが管理します。PDU では個別の電源を使用でき、次の機器に対する冗長電源を提供します。
» Exadata データベース・サーバー
» Exadata Storage Server
» InfiniBand スイッチ
» イーサネット・ネットワーク・スイッチ
ソフトウェア・コンポーネント：
次の標準 Oracle ソフトウェア・コンポーネントは、Oracle ExaCS と Oracle ExaCC 向けに明示的に最適化および検証されています。ストレージ・サーバーへの更新の適用と障害のあるコンポーネントの交換は、オラクルが管理します。データベースの更新、Oracle Grid Infrastructure、O/S の更新は顧客が担当します。
ファームウェアとオペレーティング・システム
すべてのデータベースと Exadata ストレージ・サーバーには、データベース・サーバーの Dom0 を含め、検証済みのファームウェアとオペレーティング・システムがパッケージ化されて事前にインストールされています。これらはオラクルが管理します。
12 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
データベース・サーバー層
Grid Infrastructure（Oracle Clusterware と Oracle ASM）および Oracle RAC ソフトウェアがインストールされており、導入時に推奨されるソフトウェア・バージョンまでのパッチが適用されているため、アプリケーションの障害耐性が実現し、インスタンス障害やノード障害時に自動的に対応し、アプリケーションの一時停止がほとんど、またはまったく発生しません。Grid Infrastructure のすべての更新とデータベースのほとんどの更新は、Oracle Database Cloud Service Console または付属のクラウドの exadbcpatchmulti コマンドを使用して、ローリング方式で適用できます。DomU内のデータベース、Grid Infrastructure、O/S は顧客が更新します。
ストレージ層
Exadata ストレージ・サーバーには Oracle Hardware Assisted Resilient Data（Oracle HARD）が搭載されているため、データ・ブロック・アドレス、チェックサム、マジック・ナンバーなどの Oracleブロック・データ構造の物理ディスクへの書込みが許可される前に、非常に高いレベルの検証が実施されます。Exadata による HARD 検証は自動的に実行されます。HARD チェックによって、Oracle ASM ディスクのリバランス操作やディスク障害を含むすべての IO 障害のケースが透過的に処理されます。Exadata 独自のその他の高可用性機能と利点については、付録 A を参照してください。ストレージ層の更新と管理はオラクルが担当します。
計画外停止への対応
表 2 は、計画外停止時間を最小限にするために、停止のタイプごとに Oracle MAA で推奨されるソリューションと、アプリケーションのリカバリ時間（RTO）の予想値です。これらはアプリケーションのパフォーマンス SLA を満たすのに十分なシステム・リソースがあり、使用可能なサービスへの透過的なフェイルオーバーがアプリケーションで構成されていることを前提とします。運用の準備状況と、アプリケーションのパフォーマンス SLA が満たされているかどうかを評価するには、Oracle ExaCC または Oracle ExaCS のテスト・システムに対して実際のワークロードを（Oracle Real Application Testing と Database Replay を使って）実行しながら、主要な障害（インスタンス障害、ノード障害、ディスク障害、セル障害、論理障害、ハングなど）についてシミュレートすることを推奨します。ほとんどの停止でデータベース停止時間はゼロとなり、あらゆる接続に関するアプリケーションの一時停止も最小限で済みます。Exadata によってエンド・ツー・エンドのアプリケーション可用性を達成する方法と、さまざまなハードウェアとソフトウェアの機能停止による停止時間 を ほ ぼ ゼ ロ に す る 方 法 の 実 例 に つ い て は 、 Exadata MAA の ビ デ オ（http://vimeo.com/esgmedia/exadata-maa-tests）を参照してください。
手動または自動のいずれのフェイルオーバーをデプロイする場合でも、個々のコンポーネントがデータベースの可用性に与える影響を理解し、エンド・ツー・エンド・アプリケーションのフェイルオーバー時間や一時停止を評価します。次の表には、Oracle Database の 11g の高可用性のベスト・プラクティス 2の第 13 章『"Recovering from Unscheduled Outages" i 計画外停止からのリカバリ』へのリンクがあります。Oracle Database 12c を使用している場合は、Oracle 12c の高可用性のベスト・プラクティスで公開されている停止のマトリックス 3を参照してください。
2 https://docs.oracle.com/cd/E16338_01/server.112/b65088/outage.htm#i1005910 3 https://docs.oracle.com/cd/E57425_01/121/HABPT/outage.htm#i1005910
13 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
表2：計画外停止とソリューションのマトリックス
計画外停止 Oracle ExaCSとOracle ExaCCのMAA
RTO RPO
サイト障害、クラスタ全体
障害、Oracle ExaCCまた
はOracle ExaCSの本番環
境の障害
SILVER バックアップからのリストアと リカバリ GOLDとPLATINUM スタンバイ・データベースでのデータ
ベース・フェイルオーバー サイト・フェイルオーバーの完了 アプリケーション・フェイルオーバー
時間 Gold： 数秒〜1分 Platinum： アプリケーションの 停止時間ゼロ
最終バックアップ以降 Recovery Applianceを 使った場合は数秒 Gold： 0（ゼロ）～数秒 Platinum：0（ゼロ）
コンピュータ障害（Oracle RACデータベース・サー
バー障害）またはデータ
ベース・インスタンス障害
（Oracle RACデータベー
ス・インスタンス障害）
SILVER、GOLD、PLATINUM 計画外停止からのOracle RACリカバリ
による透過的フェイルオーバー
0（ゼロ） 影響を受ける接続の場合は
数秒。Platinumの場合は アプリケーションへの影響
ゼロ。
0（ゼロ）
Exadata Storage Serverの障害 ストレージ・セル全
体、ディスク、またはフ
ラッシュの障害を含む
SILVER、GOLD、PLATINUM 組込みの冗長性とフェイルオーバー
DBの停止時間ゼロ 最悪の場合、アプリケー
ションが数秒間一時停止。
0（ゼロ）
コンピュータ またはExadataセル・スト
レージ・サーバー の電源障害、PDU障害、ま
たは電源供給喪失
SILVER、GOLD、PLATINUM 冗長電源障害によるアプリケーション
一時停止なし。
0（ゼロ） 0（ゼロ）
人為的エラー < 30分4
人為的エラーからの リカバリ
状況による 状況による
注：計画外停止の後に十分なシステム・リソースがある場合は、表 2 のとおり、アプリケーションへの影響は非常に軽微です。
計画メンテナンスへの対応
オラクルは、ソフトウェア更新（セキュリティ、ネットワーク、インフラストラクチャの更新など）を、定期的かつ自動的に Oracle ExaCC と Oracle ExaCS のハードウェアとソフトウェアに適用します。この際、停止時間は発生しません。検証済みリリースのリストから Exadata データベース・サーバーに更新を適用する作業は、顧客が担当します。計画メンテナンスへの対応について詳しくは、付録 B を参照してください。
4 人為的エラーからのリカバリ時間は、おもに検出時間によって決まります。DML や DLL の悪意のあるトランザクションを数秒で検出できる場合、
適切にリハーサルしていれば、通常は適切なトランザクションを数秒でフラッシュ・バックできます。参照や整合性に関する制限事項も考慮する必
要があります。
14 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
Oracle ExaCCおよびOracle ExaCSのバックアップとリカバリのオプション
Oracle ExaCS と Oracle ExaCC の両方に自動ツールが搭載されており、バックアップとリカバリの管理を容易にします。Oracle ExaCS はパブリック・クラウドに、Oracle ExaCC は顧客のデータセンターにデプロイされているため、ツールにはやや違いがあります。
サービスの作成およびデプロイメント中の Oracle ExaCS のバックアップ・オプションは次のとおりです。
1. Both Remote Storage and Exadata Storage - 週単位の全体バックアップ（RMAN レベルがゼロ（0））と日単位の増分バックアップを含む 2 つの個別のバックアップ・セットが可能です。Exadata ストレージへのバックアップでは、増分的に更新されるバックアップ方法（イメージ・コピー）を使用する RECO ディスク・グループ内の領域と、Oracle Database Backup Cloud Service によってデフォルトで 30 日間保存されるオブジェクト・ストレージへのバックアップが使用されます。このオプションでは、Oracle Database Backup Cloud Service へのサブスクリプションが必要です。
2. Remote Storage Only - リモート・ストレージは Oracle Database Backup Cloud Service を使ったクラウド・バックアップです。デフォルト設定は週単位の全体バックアップと日単位の増分バックアップで、保存期間は 30 日間です。このオプションでは、Oracle Database Backup Cloud Service へのサブスクリプションが必要です。
3. None - 自動バックアップは構成されません。ユーザーはオンデマンド・バックアップを実行できます。
図8：EXA用にバックアップを構成するためのユーザー・インタフェースのサンプル
15 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
Oracle ExaCC は顧客のデータセンターにデプロイされているため、ネットワーク・ファイル・システム（NFS）の保存場所にバックアップを作成するためのツールが用意されています。ただし、オンプレミスの Zero Data Loss Recovery Appliance や Database Backup Cloud Service など、他のバックアップ先に対してバックアップを実行することもできます。これらの非 NFS バックアップ構成は、少しの簡単な手動ステップで行います。ディザスタ・リカバリ用にデータを保護するには、バックアップ・データを外部にレプリケートまたはコピーすることを推奨します。Oracle MAA は、Oracle ExaCC や顧客のデータセンター内にあるその他の Oracle データベースをバックアップする手順を、Recovery Appliance を基に標準化することを推奨します。Oracle サービスは、自動化されていない部分の手動構成をサポート可能です。
図 9 は Oracle ExaCS と Oracle ExaCC で可能なすべてのバックアップ構成を示しています。10GigE接続を使用する Oracle ExaCC の場合、GUI または CLI を使用して、ローカルの NFS をバックアップ先として構成できます。
図9：Oracle ExaCSとOracle EXACCのバックアップ構成
テスト環境の重要性
オンプレミス Exadata の場合と同様に、十分な能力を備えたテスト・システム・インフラストラクチャへの投資は、Oracle ExaCS と Oracle ExaCC の最大限の可用性を実現するために不可欠です。Exadata のテスト・システムのデプロイに関する各種戦略の利点とトレードオフについては、表 3を参照してください。
16 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
表3：さまざまなテスト環境とQA環境のトレードオフ
テスト環境 利点とトレードオフ 本番環境のOracle ExaCCまたはOracle ExaCSのフル・レプリカ
Exadataデータベース・サーバーの更新とソフトウェアの変更
がすべて検証されます。すべての機能テストが検証されます。 本番規模での完全なパフォーマンス検証が実施されます。 特にレプリカにスタンバイ・システムが含まれる場合、完全なHA検証が実施
されます。 スタンバイのExadata、Oracle ExaCC、 またはOracle ExaCS
Exadataデータベース・サーバーの更新とソフトウェアの変更が検証されま
す。すべての機能テストが検証されます。 Data Guardスナップショット・スタンバイを使用している場合は完全な
パフォーマンス検証が実施されますが、フェイルオーバーが必要な場合
はリカバリ時間が長くなります。 ロール移行の検証。 リソースの管理とスケジューリングが必要です。
共有Exadata、Oracle ExaCC、Oracle ExaCS
Exadataデータベース・サーバーの更新とソフトウェアの変更が検
証されます。すべての機能テストが検証されます。 本番環境と同様の十分なシステム・リソースを割り当てられる場合は、この
環境がパフォーマンス・テストに適している可能性があります。 ただし通常は、パフォーマンスのテスト/検証に適さない本番システム・リ
ソースのサブセットです。 リソース・スケジューリングが必要です。
小規模なExadataシステムまたは Exadataスナップショットを備えたExadata
Exadataデータベース・サーバーの更新とソフトウェアの変更が検
証されます。すべての機能テストが検証されます。 本番規模でのパフォーマンス・テストが
実施されません。フルスケールの高可用
性評価が制限されます。 Exadataスナップショットのストレージ効率は非常に優れています。
古いExadataシステム Exadataデータベース・サーバーの更新とソフトウェアの変更が検
証されます。ファームウェアのパッチ・テストが制限されます。 一部の新しいハードウェア機能によって制限される場合を除き、すべて
の機能テストが検証されます。本番規模のパフォーマンス・テストが制
限されます。 フルスケールの高可用性評価が制限されます。
Exadata以外のシステム データベースとグリッド・インフラストラクチャのソフトウェアお
よび更新のみが検証されます。データベースの汎用的な機能テスト
が検証されます。 Exadata固有のソフトウェア機能（HCC、IORM、ストレージ索引など）のテ
ストが制限されます。 本番規模のパフォーマンス・テストが大幅に制限されます。 高可用性評価が制限されます。
結論
Exadata MAA は、クラウド内の Oracle Database にパフォーマンスと可用性が非常に高いプラットフォームを提供するための統合型ソリューションです。本書では、すべての Oracle ExaCC およびExaCS システムで事前構成されている高可用性機能について、重点的に説明してきました。また、Exadata MAA リファレンス・アーキテクチャによってプラットフォームを機能強化し、あらゆる障害に対して保護し、計画的メンテナンス作業による停止時間を短縮する方法についても説明してきました。
17 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
付録A：その他のExadata独自の高可用性機能と利点
Exadata のその他の高可用性機能と利点については、次の表 4 を参照してください。これらの機能の詳細については、『Oracle Exadata Database Machine System Overview』、『Exadata Machine Maintenance Guide』、『Oracle Exadata Storage Server Software User’s Guide』などの Exadata のドキュメントを参照してください。
注：本文書は、情報提供のみを目的として提供されています。ここに記載されている機能は、Exadata 内で自動的に処理されるか、オラクルが実行する機能です。
表4：HAの機能と利点
分野 機能 HAの利点 HAの一時停止時間
の短縮 高速なノード停止検出と
フェイルオーバー ノード障害の検出時間が60秒から2秒以下に短縮されます。
アプリケーションへの影
響が少ないExadataスト
レージ障害の自動検出
自動検出とリバランスが実行されます。アプリケーションへの影響は1〜2秒の遅延です。
アプリケーションへの影
響が少ないExadataネッ
トワーク障害の自動検出
自動検出とフェイルオーバーが実行されます。 アプリケーションへの影響は0〜5秒の遅延です。
インスタンス障害時の一
時停止の短縮 ExadataのフラッシュとストレージGRIDは帯域幅が広く待機時間が短いため、データベース初
期化パラメータFAST_START_MTTR_TARGETを短く設定し、アプリケーションに影響を与えず
に、インスタンス障害やノード障害が発生した場合のアプリケーションの一時停止時間を 短縮できます。
3台以上のストレージ・
サーバーによる、Oracleファイルおよびクラスタ
ウェア投票ファイル用の
高冗長性の利点
5台未満のストレージ・サーバーでOracle投票ファイルを高冗長性ディスク・グループに配置し、
OracleデータベースとOracleクラスタの両方でデータ保護と冗長性の利点を活用できます。高冗長性
ディスク・グループを作成すると、Oracle Exadataデプロイメントによって自動的に実行されます。
データ保護 ハード・ディスクの自動
的なスクラブと修復 ハード・ディスクがアイドル状態のときに、ハード・ディスクの検査と修復が自動的かつ定期
的に実行されます。ハード・ディスクで問題のあるセクターが見つかると、Exadataから
Oracle ASMに対して自動的にリクエストが送信され、別のミラー・コピーからのデータ読込み
によって問題のあるセクターが修復されます。ハード・ディスク・スクラブはデフォルトで2週おきに実行されます。 アダプティブ・スクラビングによって、問題のあるセクターが検出された場合のディスク・スク
ラビングの頻度を自動的に変更できます。現在のスクラビング・ジョブでハード・ディスクに問
題のあるセクターが見つかった場合は、Oracle Exadata Storage Serverソフトウェアによって、
そのディスクのフォローアップ・スクラビング・ジョブが1週間以内にスケジューリングされま
す。そのディスクのスクラビング・ジョブで問題のあるセクターが見つからない場合は、
hardDiskScrubInterval属性で指定されているスクラビング・スケジュールにスケジュールが
フォールバックされます。 Exadata H.A.R.D. Exadata Hardware Assisted Resilient Data（HARD）によって、データ・ブロック・アドレス、
チェックサム、マジック・ナンバーなどのOracleブロック・データ構造の物理ディスクへの書込
みが許可される前に、非常に高レベルの検証が実施されます。Exadataによる検証は自動的に実
行されます。HARDチェックによって、Oracle ASMディスクのリバランス操作やディスク障害を
含むすべてのケースが透過的に処理されます。 サービス品質 読取り操作のI/O待機
時間の制限 読取りI/Oの待機時間が予想より長い場合に、読取りI/O操作が別のセルにリダイ
レクトされます。このため、デバイス・ドライバ、コントローラ、ファームウェ
アの問題、障害がある（または停止している） ディスクやフラッシュ、問題のあるストレージ・セクターなどによる、読取りI/Oのハングや大幅な速度低下に対応できます。
書込み操作のI/O待機
時間の制限 待機時間の長い書込みI/O操作が、別の正常なフラッシュ・デバイスにリダイレク
トされます。このため、書込みI/Oのハングや大幅な速度低下に対応できます。 ExadataセルのI/Oタイ
ムアウトのしきい値 I/Oタイムアウトのしきい値を設定できるため、長時間実行されているI/Oをキャ
ンセルして別の有効なミラー・コピーにリダイレクトできます。 予測障害のあるディ
スク・ドロップによ
るヘルス要素
Exadataセルでハード・ディスクが予測障害状態になると、Exadataによって
Oracle ASMリバランスが自動的にトリガーされ、ディスクからデータが再配置さ
れます。Oracle ASMではまず正常なミラーからの読取りをリバランスして、冗長
性をリストアします。他のすべてのミラーが使用できない状態の場合は、Oracle ASMリバランスによって、障害発生が予測されたディスクからデータが読み取ら
れます。このため、障害発生が予測されたディスクからのリバランス読取りをで
きるだけ防ぎ、リバランスを最適な状態で実行して、リバランス・プロセス中の
データ冗長性を最大化できます。
18 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
分野 機能 HAの利点 低パフォーマンス・
ディスクの識別と自
動除去
作業はすべてのディスクに対して均等に分散されるため、低パフォーマンス・
ディスクはすべてのディスクのパフォーマンスに影響します。低パフォーマンス
のディスクが検出された場合は、アクティブな構成から除外されます。Exadataによって、内部パフォーマンス・テストが実行されます。ディスクの問題が一時
的なものでありテストに合格した場合は、ディスクが構成に戻されます。ディス
クがテストに合格せず、低パフォーマンスのマークが付けられた場合は、ディス
ク交換のため、自動サービス・リクエスト（ASR）のサービス・リクエストが開
始されます。この機能は、ハード・ディスク とフラッシュ・ディスクの両方に適用されます。交換はすべて、Oracle Cloud ServicesまたはACSが担当します。
I/Oリソース管理 I/Oリソース管理（IORM）によって、ディスクおよびフラッシュのIOPSと、プラ
ガブル・データベースまたは物理データベースごとの最小/最大フラッシュ・
キャッシュ・サイズが管理されます。顧客は、Oracle Database Cloud Service ConsoleでI/Oリソース・プランを有効化または調整したり、サービス・リクエス
トのロギングによってカスタムIORMポリシーを作成したりできます。 ネットワーク・
リソース管理 ネットワーク・リソース管理によって、InfiniBandファブリック経由の重要なデー
タベース・ネットワーク・メッセージの優先順位が自動的かつ透過的に決定されま
す。このため、待機時間が重要な操作の応答時間が短縮されます。優先順位付けは
データベース、データベースのInfiniBandアダプタ、Exadataソフトウェア、
Exadata InfiniBandアダプタ、InfiniBandスイッチに実装されているため、InfiniBandファブリック全体で優先順位付けできます。 Oracle RAC Cache Fusionメッセージなどの待機時間が重要なメッセージは、バッ
チ、レポート、バックアップのメッセージより優先されます。ログ・ファイルの書
込み操作は、トランザクション処理の待機時間の短縮のため、最優先されます。 セル間のリバランスに
よるフラッシュ・
キャッシュ設定の保持
ハード・ディスクで予測障害または実際の障害が見つかり、ディスクからデータ
をリバランスする必要がある場合は、このハード・ディスクにあるデータの一部
をフラッシュ・ディスクにキャッシュして、このデータの待機時間を短縮し、ア
クセス用の帯域幅を増やすことができます。アプリケーションの現在のパフォー
マンスSLAを維持するには、セル間でオフロードされたリバランスの間に、ハー
ド・ディスク上の各種領域のキャッシング・ステータスを維持しながらデータを
リバランスすることが重要です。 このセル間のリバランス機能によって、ディスク障害やディスク交換によるリバ
ランス中のアプリケーション・パフォーマンスが、以前のリリースより大幅に向
上しています。 パフォーマンス Exadata Smart Flash
Logging Exadata Smart Flash LoggingによってREDO書込みの待機時間が短くなります。これはデータ
ベース・パフォーマンス（特にOLTPワークロード）にとって重要です。Exadata Smart Flash Loggingではハード・ディスクとフラッシュにREDOが書き込まれます。フラッシュをREDOロ
グ・データ用の一時ストア（キャッシュ）として使用することで書込み時間が常に短くなり、
書込みの外れ値が小さくなります。Exadata Smart Flash LoggingはExtreme Flash（EF）構成
にも必要です。フラッシュ・デバイスの速度が低下する場合があるためです。EFの外れ値を防
ぐため、複数の フラッシュ・ドライブを選択して書き込む際のREDO書込みは非常に選択的です。
アクティブ・ボンディン
グ・ネットワーク Exadataサーバーでは、InfiniBandカードの両方のポートにアクティブ・ボンディングが構成さ
れています。アクティブ・ボンディングでは、以前のリリースのアクティブ・パッシブ・ボン
ディングよりネットワーク帯域幅がずっと広くなります。両方のInfiniBandポートが 同時にネットワーク・トラフィックの送信に使用されるためです。
Exadata Smart Write Back Flash Cache セルの再起動後の永続性
Exadata Smart Flash Cacheによって、高速なソリッドステート・ストレージにアクセス頻度の
高いデータが透過的かつインテリジェントにキャッシュされるため、データベースの問合せと
書込みの応答時間およびスループットが向上します。フラッシュ・キャッシュに問題がある場
合は、フラッシュ上のミラー化されたコピーに操作が透過的にフェイルオーバーされます。
ユーザーによる操作は不要です。Exadata Smart Flash Cacheは電源停止、シャットダウン操
作、セルの再起動などの間も継続します。フラッシュ・キャッシュ中のデータは、セルの再起
動後にディスクから読み込んでも再設定されません。サーバーからの書込み操作は、直接フ
ラッシュ・キャッシュに対して実行されます。このため、ディスクに対する データベースのI/O操作数が減ります。
Data Guard の REDO Applyのパフォーマンス
が6倍以上向上
Data GuardのREDO Applyのパフォーマンスは、Exadata Smart Flash Cacheと全体のI/Oおよ
びネットワーク帯域幅を利用しているため、REDO Apply速度がOLTPワークロードの場合は最
大300 MB/秒、バッチおよびロード・ワークロードの場合は最大800 MB/秒になります。従来の
ストレージでは、ネットワークやストレージのIO帯域幅がボトルネックとなるため、REDO Applyの通常のパフォーマンスは50 MB/秒未満でした。
管理 Exadata Storage Server、Exadataデータベース・
サーバー、InfiniBandスイッチのパッチ適用
patchmgrユーティリティ（およびdbnodeupdate.sh）を使用すると、Exadata Storage Server、Exadataデータベース・サーバー、InfiniBandスイッチのパッチ適用を（オンラインとオフライ
ンの両方で）調整および自動化できます。Exadata Storage ServerやInfiniBandスイッチなどの
Exadataインフラストラクチャは、オラクルが完全に管理します。Oracle Database CloudのControl PlaneのexadbcpatchmultiコマンドとREST APIで、Exadataデータベース・サーバーに
パッチを適用できます。 Storage Serverソフト
ウェアの更新パフォーマ
ンスの向上
Oracle Exadata Storage Serverソフトウェアの更新時間が大幅に短縮されています。内部処理
をさらに最適化することで、セル更新プロセスが以前のリリースより最大で3倍以上高速化され
ています。Exadataの ほとんどのパッチ適用はアプリケーションがオンラインの状態で実行されますが、この機能強
化によってパッチ適用時間が大幅に短縮されています。パッチ適用時間が大幅に短縮されてい
ます。この作業はOracle Advanced Customer Service（Oracle ACS）が担当します。
19 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
分野 機能 HAの利点 フラッシュとディスクの
ライフ・サイクル管理の
アラート
ディスクの障害や交換によるOracle ASMのリバランス操作を監視します。リバランス操作が正
常に完了するかエラーが発生すると、管理サーバーからアラートが送信されます。ステータス
管理が簡素化されます。 ストレージ・サーバー・
ディスクの取外しに関す
るLED通知
ストレージ・サーバー・ディスクの取外しが必要な場合は、サーバーの青色のLEDライトが点
灯します。青色のライトによって、メンテナンスが必要なサーバー・ディスクを簡単に特定で
きます。 ハード・ディスクのド
ロップと交換 管理者がExadataセルからハード・ディスクを取り外すためのシンプルなコマンドがありま
す。このコマンドによって、ディスク・グループが強制的にマウント解除されることなく、
ハード・ディスク上のグリッド・ディスクをOracle ASMから安全にオフラインにできるように
なります。問題がなければ、 ディスク上のサービスLEDが点灯して簡単に交換できます。
BBUのドロップと交換 管理者がオンラインのBBU（バッテリ・バックアップ・ユニット）の交換を開始するためのシ
ンプルなコマンドがあります。このコマンドを実行するとコントローラがライトスルー・
キャッシングに変更され、電源喪失時のBBU交換の際にデータ損失が発生することがありませ
ん。 ディスク障害の誤検知の
最少化または解消 I/Oが自動的に正常なドライブにリダイレクトされます。異常のある対象ディスクの電源が入れ
なおされます。ドライブが正常な状態に戻ると、再有効化および再同期されます。電源を入れ
なおしてもドライブの障害が解決しない場合は、ドライブがドロップされます。ディスク障害
の誤検知をなくし、データの冗長性を維持し、運用管理作業を減らしてドロップのリバランス
を回避します。 ExadataのAWRおよびア
クティブ・レポート AWRレポートのExadata Flash Cache Performance Statisticsセクションが機能強化されまし
た。1）列のフラッシュ・キャッシュとKeepキャッシュのサポートが追加されました。2）フ
ラッシュ・キャッシュのパフォーマンス・サマリーにセクションが追加され、Exadataスト
レージ・セルとデータベースの統計情報の概要を把握できるようになりました。 AWRレポートのExadata Flash Log Statisticsセクションに、ディスクとフラッシュへの初回書
込みの統計情報が追加されました。
20 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
付録B：計画メンテナンスへの対応
表 5 に、テストおよびパッチ適用のベスト・プラクティスに従ってから Exadata の計画メンテナンスを実行するための適切な方法を示します。Oracle ExaCS と Oracle ExaCC の場合は、オラクルが計画メンテナンスを管理します。この情報は、オラクルと連係して計画メンテナンス中の停止時間を短縮するのに役立ちます。
運用の準備状況と、アプリケーションのパフォーマンス SLA が満たされているかどうかを評価するには、Exadata MAA テスト・システムで実際のワークロードを（Real Application Testing とDatabase Replay を使用して）実行しながら、主要な計画メンテナンス・イベント（Oracle Database または Grid Infrastructure のメンテナンス・アップグレード、Exadata プラットフォーム・ソフトウェアのアップグレードなど）に重点を置いて作業することを推奨します。予想停止時間の列には、テストおよびリハーサル済みのメンテナンス作業における、プライマリ・データベースへの一般的な影響が表示されます。通常は、まずテスト環境ですべての計画メンテナンス作業を検証します。
Standby-First Patch - Data Guard によるリスクの軽減と停止時間の短縮
（Exadata プラットフォーム、Oracle Grid Infrastructure、Oracle Database の）ソフトウェア更新やパッチ適用などのすべての計画メンテナンス操作では、まず Standby-First Patch のガイドラインと適格性評価を使用して、Data Guard スタンバイ・システムへの更新を実行することを推奨します。詳しくは、My Oracle Support Note 1265700.1 を参照してください。ソフトウェア更新をこの方法で実行すれば、プライマリ・データベースへの影響はありません。
計画メンテナンス後に十分なシステム・リソースがあれば、次の表のとおり、アプリケーションへの影響は非常に軽微です。
表5：プライマリ・サイトでの計画停止時間用のソリューション
計画メンテナンス 推奨されるOracleソリューション プライマリ・データベー
スの予想停止時間 頻度
Oracle Grid Infrastructure（Oracle GI）の
パッチ・セット、メンテナンス、またはメ
ジャー・リリース・アップグレード
Oracle Grid Infrastructureのローリング・パッチ・
アップグレード （詳しくは、プラットフォーム別のOracle Clusterwareインストレーション・ ガイドを参照）
データベースの 1年以上 停止時間なし、 サービスの再配置により、
アプリケーションへの影響 はゼロまたは最小限
参考資料： • Oracle DatabaseおよびGrid Infrastructureの
パッチ適用 • システム・メンテナンスのための自動
ワークロード管理 • Oracle ExaCSまたはOracle ExaCCのドキュメ
ントを参照してください。
Oracle Databaseパッチ・セット、 メンテナンス、または メジャー・リリース・アップグレード
Data Guard（一時ロジカル・スタンバイ）または
GoldenGateを使用したOracle Databaseのローリン
グ・アップグレード Data Guardが該当しない場合や、アクティブ-アク
ティブ・レプリケーションを使って停止時間を短縮
することが必要な場合は、Oracle GoldenGateを検
討してください。
5分未満 1年以上 （Data Guardの場合）
停止時間なし
（GoldenGateの場合）
参考資料：
• データベースのアップグレード
21 | Exadata Database Machineを使用したOracle Maximum Availability Architectureのデプロイ
計画メンテナンス 推奨されるOracleソリューション プライマリ・データベー
スの予想停止時間 頻度
四半期ごとのExadataデータベースOracle Grid InfrastructureやOracle Databaseに対す
る四半期ごとのExadataデータベース・バン
ドル・パッチ（Oracle Database 12cのエン
ジニアド・システムおよびDatabase In-Memory用のデータベース・パッチ、または
Exadata for Oracle Database 11gの四半期ご
とのデータベース・パッチなど）の適用
opatchおよびアウトオブプレース・パッチ適用を使っ
たOracle RACローリング・パッチ・インストール 参考資料： • Oracle DatabaseおよびGrid Infrastructureの
パッチ適用 • Automatic Workload Management for System
システム・メンテナンスのための自動ワーク
ロード管理 • Oracle ExaCSまたはOracle ExaCCのドキュメ
ントを参照してください。
データベースの停止時間な
し、サービスの再配置によ
り、アプリケーションへの
影響はゼロまたは最小限
3～12か月
Oracle Grid InfrastructureまたはOracle DatabaseへのOracle暫定パッチまたは診断
パッチの適用
opatchまたはオンライン・パッチを使ったOracle RACローリング・パッチ・インストール 参考資料： • Oracle DatabaseおよびGrid Infrastructureの
パッチ適用、およびオンライン・パッチ • システム・メンテナンスのための自動ワーク
ロード管理 • Oracle ExaCSまたはOracle ExaCCのドキュメ
ントを参照してください。
データベースの停止時間な
し、サービスの再配置によ
りアプリケーションへの影
響はゼロまたは最小限
必要に応じて
データベース・サーバー・ソフトウェアの
四半期ごとの更新または新規リリース Oracle RACのローリング・アップグレードとサー
ビスの再配置 参考資料： • システム・メンテナンスのための自動ワーク
ロード管理 • Exadata Maintenance Guide • Oracle Exadata Software Planned
Maintenanceのプレゼンテーション • Oracle ExaCSまたはOracle ExaCCのドキュメ
ントを参照してください。
データベースの停止時間な
し、サービスの再配置によ
りアプリケーションへの影
響はゼロまたは最小限
四半期ごとの更
新：3～12か月 新規リリース：
1～2年
ストレージ・サーバー・ソフトウェア
の四半期ごとの更新または 新規リリース - オラクルが担当
patchmgrによるExadata Storage Serverソフトウェアのローリング更新 参考資料： • Exadata Maintenance Guide
停止時間なし 四半期ごとの 更新：3～12か月 新規リリース：
～2年 InfiniBandスイッチ・ソフトウェア - オラクルが担当
patchmgrによるExadata InfiniBand スイッチ・ソフトウェアのローリング更新 参考資料： • Exadata Maintenance Guideを参照
データベースの停止時
間なし、アプリケー
ションの一時停止は短
時間
1～2年
配電盤（PDU） キーボード、 ビデオ、マウス（KVM） - オラクルが担当
Exadata Maintenance Guideを参照 データベースの停止時
間なし、アプリケー
ションへの影響なし
1～2年 （必要な場
合）
サイト・メンテナンス - ハードウェア・メンテナンスは オラクルが担当
データベース・スイッチオーバーを使用し
たサイト、ハードウェアおよびソフトウェ
アのメンテナンス サイト・フェイルオーバーの完了、 アプリケーション・フェイルオーバー
5分未満 必要に応じて
データベース・オブジェクトの再編成
または再定義 DBMS_REDEFINITIONを使用したオンライ
ンのオブジェクト再編成（データの再編成
と再定義を参照）
停止時間なし 必要に応じて
データベース・プラットフォームまた
は場所のメンテナンス データベースのプラットフォームまたは ロケーションの移行
5分未満 必要に応じて
Oracle Corporation, World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065, USA
海外からのお問い合わせ窓口
電話：+1.650.506.7000
ファクシミリ：+1.650.506.7200
C O N N E C T W I T H U S
blogs.oracle.com/oracle
facebook.com/oracle
twitter.com/oracle
oracle.com
Copyright © 2016, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載されている内容
は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙
示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありませ
ん。オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとしま
す。本文書はオラクルの書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっ
ても再作成または送信することはできません。
Oracle および Java は Oracle およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。
Intel および Intel Xeon は Intel Corporation の商標または登録商標です。すべての SPARC 商標はライセンスに基づいて使用される SPARC
International, Inc.の商標または登録商標です。AMD、Opteron、AMD ロゴおよび AMD Opteron ロゴは、Advanced Micro Devices の商標または
登録商標です。UNIX は、The Open Group の登録商標です。0615
Oracle Exadata Cloud at Customer と Oracle Exadata Cloud Service を使用した Oracle Maximum Availability Architecture のデプロイ
2017 年 11 月