Oracle Database 12c Release 2とOracle Real Application ......Oracle RACのスケーリングはノードの数には左右されず、シャーディングとは違いアプリケーションの変更は必要

Oracle Database 12c Release 2とOracle Real Application Clusters – 新機能の概要 Oracle ホワイト・ペーパー | 2017 年 3 月

1 | ORACLE REAL APPLICATION CLUSTERS 12C RELEASE 2 – 新機能の概要

目次はじめに ........................................................................................................................................................... 2

Real Application Clusters は、スケーラビリティ、可用性、そして効率的な管理のためのテクノロジーといえます。 ................................................................... 2

Oracle Database 12cRelease 2 Real Application Clusters ................................................................... 3

数多くの RAC データベース導入から生まれた特別な挑戦 ............................................... 3

より優れたスケーラビリティ ..................................................................................................................... 4

スマート・マスタリング ..................................................................................................................... 4

Oracle RAC 環境におけるマルチテナント（さらなる最適化）。 ............................................. 5

プラガブル・データベースとサービスの独立性 ............................................................... 5

PDB 環境のサービス独立性によるフェイルオーバー時間の短縮 .................................... 5

Flex Cluster - スケーラビリティに優れたアーキテクチャ ........................................................... 7

ユースケース 1：RAC リーダー・ノード ........................................................................... 7

ユースケース 2：大規模なパラレル問合せ RAC ................................................................ 7

データベース可用性のさらなる向上 ......................................................................................................... 8

Application Continuity ........................................................................................................................ 8

Node-Weighting によるインテリジェント・フェンシング ....................................................... 9

プラガブル・データベースとサービスの独立性 ......................................................................... 10

Recovery Buddy .................................................................................................................................. 10

より効率的でインテリジェントな管理 ................................................................................................... 11

クラスタ・ドメインおよびドメイン・サービス・クラスタ（DSC）..................................... 11

クラスタ・ドメイン .......................................................................................................... 11

メンバー・クラスタ .......................................................................................................... 12

一元化された ASM サービス ............................................................................................ 13

クラスタ・ドメイン・アーキテクチャの利点 ................................................................ 14

Oracle Autonomous Health Framework（Oracle AHF） .......................................................... 15

Oracle Machine Learning により強化された Cluster Health Advisor の導入 ............. 16

Quality of Service Management - 管理者管理データベースのサポート ...................... 17

Cluster Activity Log .......................................................................................................... 17

高速ホーム・プロビジョニング（RHP） ........................................................................ 18

結論 ................................................................................................................................................................. 19


はじめに

Oracle Real Application Clusters（RAC）は 2001 年に登場し、数多くの組織のミッション・クリティカルなシステムにおいて、ローカル・データベースの高可用性を実現し、短い期間で事実上の標準テクノロジーとなりました。Oracle は、Real Application Clusters の 8 番目のバージョンをリリースするに至り、RAC は Oracle Database にとってもっとも有名なデータベース・オプションへと成長しています。

Real Application Clustersは、スケーラビリティ、可用性、そして効率的

な管理のためのテクノロジーといえます。

Oracle Real Application Clusters が成熟していくのに伴い、スケーラビリティの向上、より優れたデータベース可用性、そして Oracle RAC 資産のより効率的な管理に対する市場の要求に応えることに開発の焦点が置かれてきました。

Oracle Real Application Clusters 12c Release 2 は以下の要件に対応しています。

• スケーラビリティおよびパフォーマンスの向上

• より優れたデータベース可用性

• より効率的な管理

o 大規模な Oracle RAC システム構築

o Oracle Machine Learning により強化された、予測分析を含む診断機能の向上

Oracle RAC は、オンプレミス環境に適したクリティカル・テクノロジーです。RAC は、パブリック・クラウド環境向けのクリティカル・テクノロジーでもあります。Oracle Real Application Clusters 12c Release 2 は当初、オンプレミス・バージョンが提供されるよりも先に、Oracle Public Cloud の Database Cloud Service としてリリースされました。Oracle のパブリック・クラウドは、データベースの高可用性を確保するため、標準で、サポート済みであり、構築しやすく、展開しやすい Oracle RAC ソリューションを提供するただ 1 つのパブリック・クラウドです。

Oracle Database 12c Release 2 において、Real Application Clusters は、Oracle RAC とクラスタリングの専門知識を有する大規模エンタープライズだけでなく、Oracle RAC の経験がまだ無い可能性のある小規模組織の両方に対応するための改善に重点を置いています。


Oracle Database 12cRelease 2

Real Application Clusters

8 番目のメジャー・リリースとなる Oracle Real Application Clusters は、大規模な IT 企業から小規模な事業所に至るまであらゆるお客様に改善点を提供します。

数多くのRACデータベース導入から生まれた特別な挑戦

Oracle RAC は、世界各地に存在する、ローカル・データベースの高可用性を求める何万もの Oracle のお客様にとって事実上の標準となっています。これらお客様の多くが、何千ものデータベースをサポートする組織内で何百ものスタンドアロン・クラスタを展開しています。それぞれのクラスタやデータベースでは、保守、パッチ適用、アップグレードが必要となる監視ツールおよび管理ツールの導入が増加しています。管理オーバーヘッドの増加、とりわけ大規模なデータベース資産における管理オーバーヘッドの増加により、管理ツールの追加導入を回避しようとするお客様も現れ、重大な状況における管理能力や診断機能データの不足に見舞われることも少なくありません。

Oracle Real Application Clusters 12c Release 2 では、以下の点の向上によりこのような問題が大幅に削減されています。

• スケーラビリティおよびパフォーマンスの向上

• データベース可用性のさらなる向上

• 大規模クラスタ資産におけるより効率的でインテリジェントな管理

現在の何千もの Oracle RAC のお客様にとって、管理しなければならない何百ものクラスタと千個単位規模のデータベースからなる RAC 資産を対象とする管理性を今回のリリースは大幅に向上します。このペーパーでは、こうした向上を可能にする新しい機能を紹介します。

Real Application Clusters とは

Oracle Real Application Clusters は、2 台以上の物理サーバーまたは仮想サーバー上で同時に Oracle Database を実行できるソフトウェアです。プライベート・ネットワーク経由でクラスタ化されたサーバーは、Oracle Clusterware と呼ばれる別のソフトウェア要素を通じて調整されます。Oracle Clusterwareは、Oracle RAC ライセンスに含まれており、Oracle または Veritas、HP、IBMといったサード・パーティが提供しています。Oracle RAC はおもに、データベースの可用性を確保する手段として使用されます。つまり、Oracle RACは、アプリケーションがデータベースにアクセスできる状態を継続し、エンドユーザーがアプリケーションを使用し続けられるようにして、物理的なハードウェアの停止だけでなく、ソフトウェアの停止からも保護します。

21 世紀の初め、独特なアクティブ-アクティブ・アーキテクチャを備えた RACには、直接競合する相手は存在していませんでした。データベース・インスタンスまたはハードウェア障害から 30秒未満でのリカバリを提供する、ただ1 つのデータベース・ソリューションでした。

Application Continuity、透過的アプリケーション・フェイルオーバー（TAF）、高速アプリケーション通知（FAN）といった補完的テクノロジーと組み合わせた場合、データベース層に障害が発生してもエンドユーザーが気付かないようその影響に対処することができます。2001 年以降、Oracle RAC は、実装した何千ものお客様にとって待機時間の短いデータ保護の標準となりました。

他に肩を並べるもののない Oracle RACのクラスタ化機能は、Linux-x86 マシン


RAC の新規、または導入を検討されているお客様にとって、今回のリリースは、RAC の実装と問題発生時の検出をより容易にする方法を提供します。すべてのお客様が、シンプルさ（簡単）と迅速さ、そして効率と向上した生産性を望んでいます。こうしたものを提供するよう改善が図られているのが、Oracle Real Application Clusters、Oracle Clusterware 、および Automatic Storage Management の今回のリリースです。

より優れたスケーラビリティ

Oracle Real Application Clusters 12c Release 2 では、普及している"全ハブ・ノード"スタンドアロン・クラスタ（ほとんどのお客様が実装しているタイプのクラスタ）、そして Oracle Real Application Clusters 12c Release 1 から導入された新しい"Flex Cluster"構成におけるスケーリングが改善されています。

Oracle RAC のスケーリングはノードの数には左右されず、シャーディングとは違いアプリケーションの変更は必要ありません。Oracle RAC 12c Release 2 には、スケーラビリティの点で多くの点が改善されています。特に、クラスタのみからなる 1 台のノード上の 1 個のインスタンスだけでデータベース・サービスが実行されている（統合データベース環境で普及している構成）シングルトン・ワークロードにおけるスケーラビリティが改善されています。

スケーラビリティについて、以下の点が改善されています。

• スマート・マスタリング

• Real Application Clusters におけるマルチテナ

ント最適化およびサービス独立性

• 非常に優れたスケーラビリティをもたらす Flex

Clusters

スマート・マスタリング

サービス指向のバッファ・キャッシュ・アクセスである"スマート・マスタリング"は、オブジェクトを参照しているサービスをデータベースが判別できるようにする機能です。キャッシュ・フュージョンは、行がバッファ・キャッシュに読み込まれる原因であるサービスを追跡する“Service-to-Buffer-Cache”リレーションシップを維持します。この統計は、サービスがアクティブであるノード

で構成されるクラスタ上に複数のデータベースをホストすることを可能にし、より高い水準のデータベース統合を実現できる、ということを IT 企業は徐々に気付いています。マシン、ソフトウェア・ライセンス、スタッフで構成される独立したサイロは、少なくともデータベース層については共有環境へと主役の座を譲っています。共有により、コストが削減され、複数のデータベースとアプリケーションにおけるハードウェア、設備、スタッフのコストが効率的に活用されます。Oracle Real Application Clusters はこのような利点をもたらす鍵となるテクノロジーです。RAC により複数のデータベースおよび複数のデータベース・インスタンスが安全にリソースを共有することができます。その結果、満たすことが要求されるサービス・レベル目標を維持するためのもっとも重要な作業においてリソースを確保できます。

データベース資産全体では、多くのお客様がプラチナ層 1 またはミッション・クリティカルなシステムのために Oracle RAC を導入しているだけでなく、RAC によりデータベースの高い可用性を確保しながらデータベースの統合が可能となることを理解しています。結果的に、データベース資産全体に対し、お客様の多くが Oracle RAC をゴールド、シルバー、そしてブロンズの層にまでも展開しています。


上のみでリソース（データ・ブロック）をマスタリングするために使用します。その結果、データへのアクセスまたはデータの修正がリクエストされると、当該データを含むデータ・ブロックが、そのサービスをリクエストしているノード上で利用可能になります。キャッシュ・フュージョンの中心である Global Cache Service（GCS）は、データ・ブロックがすでにクラスタ・ノード上にあるため、クラスタ・ノードでデータ・ブロックの検出、ロック、配信を行う必要はありません。アクセスはさらに高速になります。このため、ノード間のクラスタにおけるキャッシュ・フュージョンの通信が削減され、大規模クラスタの実行が実用的になり、複数データベースをホストして大規模の統合が可能になります。

この情報をデータベースに格納することで、次回起動時に Dynamic Re-mastering（DRM）を使用した再マスタリングを行うことなく、以前に確立したアフィニティをリストアすることができます。アクセス・パターンが大幅に変化しない限り、起動直後のシステムの動作が一貫し、スムーズになります。

最適化された"リソース・マスター"分散による、計画停止時のキャッシュ準備。

この追跡には、指定したサービスがどのオブジェクトにアクセスするかをサービス開始前に判断でき、それによりバッファ・キャッシュに格納すべきデータがわかるというさらなる利点があります。たとえば、メンテナンスのためサービスを移行する場合、サービスを受信するインスタンスは、サービス移行前にインテリジェントにキャッシュを準備することができます。これにより、コールド・キャッシュに関連付けられている"初回アクセス"パフォーマンス・ヒットが除外され、エンドユーザーが被る再配置の影響による中断がなくなります。

Oracle RAC環境におけるマルチテナント（さらなる最適化）。

プラガブル・データベースとサービスの独立性

Oracle Database 12c Release 1 において、Oracle は Oracle Multitenant という新たなデータベース・オプションを導入しました。このオプションにより、お客様はコンテナ・データベース（CDB）内に複数のプラガブル・データベース（PDB）をホストすることが可能となります。Oracle Multitenant データベース・オプションおよびプラガブル・データベース（PDB）の使用は、RAC データベースにワークロードを統合する優れた方法です。

CDB の役割は、おもにデータベース統合をサポートし、実行するデータベースを増やしながら、同じ、またはより少ないハードウェア・フットプリントでより良いパフォーマンスを実現することです。この効率性をもたらす方法の 1 つが、コンテナ・データベース（CDB）に"プラグイン"されたすべての PDB について、すべての REDO ログ・ファイル書き込みを 1 つの CDB に処理させるというものです。これにより、ハードウェア面とソフトウェア面の両方において、データベース・ログ書き込みの効率が向上します。そして、データベースの移植性も向上します。

Oracle Database 12c Release 2 では、Oracle RAC データベースで実行されるマルチテナント・オプションがさらに最適化されており、Real Application Clusters とともに実行される初期バージョンのマルチテナントよりも高いパフォーマンスとスケーラビリティがもたらされます。

PDB環境のサービス独立性によるフェイルオーバー時間の短縮

最新のサーバーにおける CPU やメモリの性能向上に伴い、1 つのデータベース・インスタンスだけでもワークロードを簡単に実行できるため、シングルトン PDB またはシングルトン・サービスを利


用するお客様が増えています。シングルトン PDB とは、Real Application Cluster 環境に導入されたマルチテナント環境における単一のプラガブル・データベースまたは単一のテナントのことです。こうした環境は、単一のデータベースとデータベース・インスタンスのみ、そしてデータベースで定義され実行されている単一のサービスで構成されています。そして、シングルトン PDB とシングルトン・サービスの可用性、およびスケール・アウトする潜在的能力については、依然としてOracle RAC に依存しています。ノード上またはシングルトン・データベースで障害が発生すると、そのデータベースとサービスは、RAC クラスタ内の別のノードで起動します。これは、Oracle Real Application Clusters 12c Release 2 を使用しているという点を除けば、"コールド・フェイルオーバー"によく似ていますが、RAC ではフェイルオーバーまでの時間が短縮され、よりインテリジェントな形でフェイルオーバーが実行されるよう改善されています。

プラガブル・データベースおよびサービス独立性は、すべての PDB インスタンスで提供されていないサービスの分散ロック・マネージャ（DLM）のオペレーションを減らすことでパフォーマンスを改善します。プラガブル・データベースおよびサービス独立性は、シングルトン PDB をホストしているだけのインスタンスでの障害が、同じ Oracle RAC ベースの CDB のインスタンスに影響が及ばないようにすることで可用性を改善します。

Oracle Database 12c Release 2 のマルチテナント・オプションおよび Oracle RAC オプションにより、クラスタは対応する PDB の実行先となるノード上のサービスを自動的にロケーティングします。このため、マルチテナントまたは RAC の導入シナリオは、マルチテナントの高い統合機能とスケーラビリティだけでなく、RAC の高可用性をも望む DBA とアーキテクトにとって非常に魅力的なものとなります。

シングルトン PDB の使用は、Oracle RAC 12c Release 2 ではプラガブル・データベース独立性の恩恵を受けるため、非常に魅力的です。シングルトン PDB またはシングルトン・サービスは一度につき 1 つのインスタンス上でのみ提供されるため、複数インスタンスにまたがる指定のシングルトンPDB についてロック情報を共有する必要はありません。PDB に関連付けられているデータベース・ブロックは、PDB が存在するノード上でのみマスタリングされ、それ以外のノードではマスタリングされません。PDB ブロック管理はよりインテリジェントになっており、ブロックを参照またはブロックにアクセスするインスタンスにおいてのみブロックがマスタリングされるため、マスタリングはインテリジェントに行われます。

図1：プラガブル・データベースとサービスの独立性による可用性の向上

さらに、プラガブル・データベース独立性により、分散ロック管理のオペレーションは、それぞれの PDB がオープンになっているインスタンス間でのみ実行されます（上記の図 1 の例では、オレンジ色の PDB が 4 個のインスタンスの内 2 個でのみオープン）。これにより、ノード間での不要なやりとりが減り、クラスタ全体およびクラスタ内で実行されているすべてのデータベースのパフォーマンスとスケーラビリティが向上します。


同様に可用性も向上します。インスタンス障害の発生後、障害が発生したインスタンスがマスタリングしたロックは、クラスタ内の別のインスタンスで再マスタリングする必要があります。障害の発生したノードでマスタリングされたロックのデータにアクセスしようとする、存続しているノードで実行されているインスタンスは、関連するロックが再マスタリングされている間、一時停止しなければなりません。シングルトン PDB に対するロックはローカルでマスタリングされるため、他のインスタンスの障害の影響は受けません。再マスタリングしなければならないロックで影響を受けるロックはなく、すべてローカルでマスタリングされるため、障害の発生したノードでは何もマスタリングされません。

Flex Cluster - スケーラビリティに優れたアーキテクチャ

ユースケース1：RACリーダー・ノード

Flex Cluster、そしてハブ・ノードとリーフ・ノードの概念は、Oracle Real Application Clusters 12c Release 1 から導入されました。ハブ・ノードは、プライベート・ネットワーク経由で相互接続される従来のクラスタ・ノードのことで、共有ストレージにダイレクトにアクセスします。リーフ・ノードは、ハブ・ノードに接続された疎結合ノードのことです。Oracle RAC 12c Release 2 からは、リーフ・ノード上で実行されるインスタンスに対し、読み取り専用のワークロードを実行できるようになりました。こうしたノードを"リーダー・ノード"と呼びます。リーダー・ノードの障害は、データベース・アクティビティ全体には影響を与えないため、数百単位のノードのスケーリングが容易になります。お客様はこの導入オプションを利用して、非定型データ分析のためほとんどの読取りがリーフ・ノード・インスタンスで実行される読取り専用ワークロードを処理します。読取り専用作業では何千ものノードに及ぶスケーリングが可能であり、更新されたデータへのアクセス遅延につながることも、ハブ・ノードで実行される OLTP パフォーマンス作業に悪影響を及ぼすこともありません。大量の読取りアクティビティをサポートするリーフ・ノードは、ノードやインスタンスで障害が発生しても、Oracle RAC が通常提供する高可用性のメリットを享受できます。

結論として、Flex Cluster アーキテクチャは、OLTP およびビジネス分析ワークロードが同じデータへアクセスしたり、同一の物理インフラストラクチャで実行する必要がある場合に、非常に優れたスケーラビリティと大幅なパフォーマンス向上をもたらす、ということが言えます。

ユースケース2：大規模なパラレル問合せRAC

現在、多くのお客様が大規模なデータ分析で Hadoop Cluster を利用、展開しています。下の図 2に示すように、SQL 経由で Hadoop のデータにアクセスしたり、標準インタフェースを使用して非定型分析を実行したりするため、Oracle Real Application Clusters 12c Release 2 は、Oracle Flex Cluster とともに HDFS を使用する Hadoop Cluster のオーバーレイをサポートしています。これは実質的には、従来からあるよく知られた SQL とリレーショナル・データベースのモデルを Hadoopクラスタ・モデルに組み合わせることで、非常に大きなデータセットに対する分析をサポートしているということです。基本的に、RAC と Hadoop の共生リレーションシップが作成され、それにより、Hadoop データセットからデータを取得し、RAC クラスタのリーフ・ノード・インスタンスで実行される分析作業を可能にする RAC 環境をサポートします。


図2：Hadoop HDFSとOracle Flex Clusterの組み合わせによる大規模データセット分析のサポート。RACによる高可用性も確保。

データベース可用性のさらなる向上

Oracle RAC は、常に最良のデータベース可用性の提供に取り組んできました。2001 年に登場して以来、ローカル・データベースの高可用性を提供するために用いられる、事実上の業界標準として成功を収めました。Real Application Clusters 12c Release 2 は可用性を向上するため、以下の機能を含む大きな進化を果たしています。

• Application Continuity

• Node Weighting

• プラガブル・データベースとサービスの独立性

• Recovery Buddy

プロセッサの性能が大幅に向上するのに伴い、複数サーバーにまたがるワークロードのスケーリングだけでなく、多数のシングル・インスタンス・データベース・ワークロードを管理しやすい高可用性プラットフォームに統合することを目的に Oracle RAC を始めとするソリューションを導入するお客様が増えています。今回の最新リリースでは、障害発生後の再構成の時間を短縮することで可用性を改善しています。

Application Continuity

Application Continuity（AC）は、Oracle Real Application Clusters 12c Release 1 から導入された機能です。Application Continuity では、トランザクションがコミットされる前にデータベース・インスタンスの障害が発生した場合でも、データベース・トランザクションが失敗せずに完了するよう考慮されています。この機能は、データベース・クライアント、クライアント・ドライバ、そしてOracle データベースが連携し、停止の影響を受けたデータベース・セッションの実行中の処理をリカバリし、完了させることで、エンドユーザーとアプリケーションから停止がマスクされます。Application Continuity はこのリカバリをアプリケーションの後方で実行するため、アプリケーションにとってこの停止はわずかな実行遅延のように見えます。アプリケーションまたはエンドユー


ザーは、基盤となるデータベース・インスタンスまたはノード障害からは完全に保護されます。アプリケーションはトランザクションを再実行する必要が無く、Oracle データベースまたは Oracle Real Application Clusters 環境が透過的にトランザクション完了を処理します。

Application Continuity は、リカバリ可能なエラー（一般的には下層のソフトウェア、ハードウェア、ネットワーク、またはストレージの各レイヤーに関連するエラー）につながる停止に対して起動されます。Application Continuity がない場合、アプリケーションが手順に沿って安全に停止をマスクすることがほぼ不可能になる場合があります。AC は、アプリケーション開発者がエラーチェックやトランザクション再現という複雑なロジックのコードを作成しなくても、データベース関連の停止をマスクすることで開発者の生産性を向上します。

計画外停止と計画メンテナンスの両方を扱う場合、AC によりユーザー・エクスペリエンスが大幅に改善されます。Oracle データベースを利用するシステムおよびアプリケーションのフォルト・トレランスを強化するという点が Application Continuity の重要なメリットです。

Oracle Database 12c Release 2 では、Java JDBC、OCI、ODP.NET の非マネージド・プロバイダを使ったアプリケーションで Application Continuity を利用することができます。

Node-Weightingによるインテリジェント・フェンシング

Oracle Real Application Clusters 12c Release 2 以前では、ノード削除の結果は予測可能でしたが、必ずしも望む結果になるとは限りませんでした。たとえば、"途中で中断"が発生した 2 ノード・クラスタの場合、ノードはインターコネクトと投票ディスクを使用して他のノードと通信できなくなり、もっとも小さいノード番号のノードが存続することを意味します。これは予測可能な結果である一方、まったく問題の無いノードが排除され、存続ノードは 2 つめの障害に見舞われたり、Oracle RAC One Node データベースの場合のように、何の作業も実行しない可能性があることを意味します。実際、除外されたノードは、より多くの作業を実行していたり、より重要な作業を実行していたりしても、最小番号が存続するというシンプルなクラスタ・ノード・ロジックにより除外されてしまうことがあります。

Node Weighting は、Oracle Real Application Clusters 12c Release 2 で導入された新機能で、フェンシング時にクラスタ内でホストされるワークロードを考慮する機能です。ノード間の通信が中断された 2 ノードからなるクラスタの例で言うと、（フェンシング時に）サービスの大半をホストしているノードが存続することになります。このアイデアは、他がすべて等しい場合に、作業の多い方を存続させるというものです。

CSS_CRITICAL という新しいタグが作成され、さまざまなレベルやコンポーネントを"クリティカル"であると設定することができ、クラスタは障害発生時にそれらを保持しようとします。Oracle Clusterware はスプリット・ブレイン時に除外するノードを決断する際、障害発生時点で少なくとも 1 つのクリティカルなコンポーネントを保持するノードの存続を妨げる技術的理由がなければ、CSS_CRITICAL を尊重します。


その結果、クラスタで実行している作業を保護することができ、クリティカルな作業における可用性が保持されます。これは、Oracle Real Application Clusters 12c Release 2 が提供する"可用性の向上"をサポートする重要な機能の 1 つです。

プラガブル・データベースとサービスの独立性

プラガブル・データベースとサービスの独立性は、上記では、マルチテナント環境における RAC のスケーラビリティの向上のためのものとして取り上げていました。しかし、プラガブル・データベース（PDB）およびサービス独立性は、シングルトン PDB をホストするだけのインスタンスでのインスタンス障害が、同じ Oracle RAC ベースの CDB のインスタンスに影響が及ばないようにすることにより、可用性も改善します。

インスタンス障害の発生後、障害が発生したインスタンスがマスタリングしたロックは、クラスタ内の別のインスタンスで再マスタリングする必要があります。これまでの RAC リリースでは、障害の発生したノードでマスタリングされたロックのデータへのアクセスが必要となる、存続しているノードで実行されているインスタンスは、影響を受けたロックが再マスタリングされている間、一時停止しなければなりませんでした。Oracle Real Application Clusters 12c Release 2 では、シングルトン PDB に対するロックはローカルでマスタリングされるため、他のインスタンスの障害の影響は受けません。再マスタリングしなければならないロックで影響を受けるロックはなく、すべてローカルでマスタリングされるため、障害の発生したノードでは何もマスタリングされません。このため、RAC Database Member Cluster はリジリエンスと可用性が大幅に向上し、インスタンスやノードのクラッシュの分離性と抱合性が高まり、影響のないリソースの可用性が高く維持されます。

Recovery Buddy

インスタンス障害を避けることは不可能です。インスタンス障害が発生した場合、クラスタ内のインスタンス障害からリカバリするための時間は、障害を検出し、障害からリカバリするまでに要した（インスタンス・リカバリ）時間で決まります。RAC クラスタにおける障害の検出は、ほぼ瞬間的に行われます。しかし、障害からのリカバリは、インスタンス・リカバリ時間によって決まります。この時間は、Oracle Real Application Clusters 12c Release 2 で利用可能になった Recovery Buddy 機能によって大幅に短縮することができます。

インスタンスに障害が発生すると、そのインスタンスによって最近修正されたブロックはディスク上で一貫性のない状態になる可能性があり、リカバリしなければなりません。存続するインスタンスが REDO ログをスキャンしてこれらのブロックをリカバリしなければ、新しいトランザクションがデータを修正することはできません。Oracle Real Application Clusters 12c Release 2 の Recovery Buddy 機能は、Buddy Instance を作成し、"バディ"ノード上の修正済みデータ・ブロックを追跡します。ノードに障害が発生した場合、Buddy Instance はリカバリが必要なブロックを素早く特定することができ、影響のないブロックで新しいトランザクションが迅速に処理され、リカバリの判断を待つ必要がなくなります。

この機能は特に、大量の更新アクティビティが発生するクラスタでのリカバリ時間を大幅に短縮します。


より効率的でインテリジェントな管理

ワークロードをより少ないシステムに統合する傾向がある一方、監視、管理、保守が必要なシステムとデータベースの増加という課題が依然として存在しています。初心者レベルの DBA は、可用性とパフォーマンスのため、管理する複数のシステムに 40 ものデータベースを割り当てる場合があります。新しいクラスタ・アーキテクチャおよび 2 つの新しい管理機能が導入され、Oracle RAC ベースのクラスタの大規模な資産に対する管理性が大幅に向上しました。具体的には次のとおりです。

• クラスタ・ドメインおよびドメイン・サービス・クラスタ

• Oracle Machine Learning により強化された Oracle Autonomous Health Framework（AHF）

• 高速ホーム・プロビジョニング

クラスタ・ドメインおよびドメイン・サービス・クラスタ（DSC）

Oracle Real Application Clusters 12c Release 2 より前は、RAC クラスタが Oracle Standalone Clusterとして知られていました。各スタンドアロン・クラスタは、すべてが独自の Oracle Grid Infrastructure サービスと Oracle ASM をローカルにホストし、共有ストレージへの直接アクセスを必要としていました。スタンドアロン・クラスタは現在もサポートされています。

図3：クラスタ・ドメイン・アーキテクチャ

クラスタ・ドメイン

Oracle Real Application Clusters 12c Release 2 では、"クラスタ・ドメイン"（図 3 参照）と呼ばれる新しいエンティティが導入されました。クラスタ・ドメインは、複数のクラスタにまたがる共通サービスを一元化する、クラスタ向けの新たなアーキテクチャで、オーバーヘッドが削減され、管理性が効率化されます。クラスタ・ドメインはメンバー・クラスタのコレクションで、すべてのメンバー・クラスタが単一のドメイン・サービス・クラスタ（DSC）を共有しています。すべてのクラスタが、同じ標準的な Oracle Clusterware を使用し、Oracle Universal Installer を使用して展開されます。


クラスタ・ドメインの利点は、メンバー・クラスタの管理がより効率的になり、各クラスタのストレージのプロビジョニングにおける柔軟性が高まることにあります。そしてもう一つの効率化として、これまでは各クラスタで実行しなければならなかったデータベースである管理リポジトリが、ドメイン・サービス・クラスタで一元化されるようになったことです。メンバー・クラスタには、複数の Management Repository データベース（メンバー・クラスタごとに 1 つずつ）を実行し管理するオーバーヘッドが加わることはなくなります。このため、同じパフォーマンスと SLA を維持するために必要なプロセッサのライセンス数が少なくなる可能性があります。その結果、Oracle Database および RAC 全体のライセンス・コストが削減される可能性があります。

この機能は特に、何百ものクラスタを抱える大規模 IT 企業にとって魅力的です。たとえば、ヨーロッパの大規模電気通信会社では、千単位のデータベースをサポートする 5 か所のデータセンターに展開される数百のクラスタに対してクラスタ・ドメインを活用しています。クラスタ・ドメイン・アーキテクチャおよびこのアーキテクチャが提供する一元化されたサービスにより、こうした大規模環境を管理する効率が向上します。そして、スプロールの減少、および多数の分離クラスタや管理データベースを維持する場合に生じるおそれのあるヒューマン・エラーの低減により、クラスタ資産全体の信頼性と可用性が向上します。この新しいクラスタ・ドメイン・アーキテクチャとともに、Oracle は、プロビジョニング、パッチ適用、問題診断を簡素化しながら標準化を可能にするツールを導入しました。

メンバー・クラスタ

メンバー・クラスタには、Oracle Member Clusters for Oracle Databases および Oracle Member Clusters for Applications の 2 種類があります。各メンバー・クラスタは、クラスタ・ドメインに属している単一の Oracle のドメイン・サービス・クラスタ（DSC）から一元化されたサービスを使用します。

Oracle のドメイン・サービス・クラスタにより、Oracle Real Application Clusters 環境における標準化、一元化、最適化が可能となります。DSC は、クラスタ・ドメインを管理する中心部分で、一元化された Grid Infrastructure Management Repository（GIMR）データベースをホストします。このデータベースは、Cluster Health Monitor（CHM）が収集するリアルタイム・パフォーマンス・データや高速ホーム・プロビジョニングで必要となるメタデータなど、個々のメンバー・クラスタに関する重要な統計情報と診断用データを収集します。旧バージョンの Oracle Grid Infrastructure では、Grid Infrastructure Management Repository は各クラスタで実行されるスタンドアロンのデータベースでした。最新バージョンでは、データ収集先となるメンバー・クラスタごとに別々のプラガブル・データベース（PDB）を実行するコンテナ・データベースである GIMR を DSC がホストします。Oracle Member Cluster for Oracle Database は、ドメイン・サービス・クラスタから、リモートの Grid Infrastructure Management Repository（GIMR）を常に使用します。これは、クラスタ・ドメイン・アーキテクチャおよびドメイン・サービス・クラスタの主要な利点の 1 つです。この利点は重要です。

はじめに、ドメイン・サービス・クラスタとしてのみ機能している限りにおいてライセンスが不要なドメイン・サービス・クラスタへ GIMR が再配置されるようになったため、クラスタ内で GIMRをサポートするために必要な物理リソースが不要となります。それにより、メンバー・クラスタで実行される RAC Database をサポートするために必要となる、全体の CPU 数（および関連のライセンス料金）を削減できる可能性があります。2 つめは、問題が発生して分析が必要な場合に、必要なログと監視ツール・データの大半またはすべてが中央の管理リポジトリに保持されるようになったため、分析作業をより効率よく迅速に行うことができます。


メンバー・クラスタは、DSC 上で実行される、次に示すような構成済みサービスを使用します。

• 一元的な監視と管理のための Autonomous Health Framework（AHF）サービス。すべてのDSC にインストールし、必要となる機能。

• オプションでインストール、構成される他の 2 つのサービス。

o ストレージの統合および管理を簡単にし、高速化する、一元化された ASM サービス。これにより、ドメイン内のすべてのクラスタ上で ASM と共有ストレージ、またはそのいずれかを利用可能にする必要がなくなります。

o Oracle Database のホーム作成とパッチ適用を通じてソフトウェアの管理と標準化を向上させる高速ホーム・プロビジョニング（RHP）サービス。

データベース・メンバー・クラスタは、ストレージのアクセス形式に応じて 3 種類の方法で構成することができます。どの構成の場合でも、管理リポジトリは Domain Management Repository に格納されます。データベース・メンバー・クラスタのストレージ・アクセスにおける 3 種類の構成は次のとおりです。

• ローカルに構成された共有ストレージ。データベース・メンバー・クラスタ上のローカルの Oracle ASM インスタンスあり。

• DSC 上のリモートの Oracle ASM を通じて管理されるストレージへのダイレクト・アクセス（図 4 参照）。

• DSC 上の Oracle ASM IO サービスを通じての、Oracle ASM ストレージに対する間接アクセス。

一元化されたASMサービス

Oracle Database 12c Release 2 で提供される ASM サービスにより、ドメイン・サービス・クラスタ（DSC）の一元化された ASM ディスク・グループ環境のデータにメンバー・クラスタがアクセスすることができます。DSC 内で ASM サービスを使用する場合、DSC に存在する共有ディスク・グループにどのメンバー・クラスタがアクセス可能かによって 2 種類の接続オプションがあります。1 つは、DSC ストレージへの共有 SAN アタッチメントをメンバー・クラスタが保有するという方法です（図 4 参照）。メンバー・クラスタ内のデータベース・インスタンスは、SAN 経由のアクセスを調整するため、DSC 内の ASM インスタンスに依存します。

図4：DSC内のASMサービスを経由してASMにアクセスするメンバー・クラスタ


2 つめは、ASM ストレージ・ネットワークを使用する ASM IO サービスを経由して、DSC のディスク・グループにメンバー・クラスタがアクセスできるようにする方法です。これを示しているのが図 5 です。

図5：ASM IOサービス経由でストレージにアクセスするメンバー・クラスタ。

このモードでは、メンバー・クラスタと DSC の間において、ストレージの物理 SAN 接続はありません。メンバー・クラスタには、共有ディスクへの直接接続は必要ありません。DSC で実行される共有 ASM サービスを使用することで、メンバー・クラスタは IO サービスへのネットワーク接続を使用し、中央で管理されているストレージ・プールにアクセスすることができます。メンバー・クラスタは、プライベート・ネットワークを経由して、ASM が管理するデータにアクセスします。このプライベート・ネットワークは、Grid Infrastructure が使用するのと同じプライベート・ネットワーク、または独立した専用の ASM プライベート・ネットワークです。このデータ・アクセス・モデルは、DSC 経由で共有される本番データやテスト・データにアクセスする場合に、メンバー・クラスタで稼働するテスト構成および開発構成に有用です。ASM ストレージ・ネットワークは、ファイバ・チャネル・スイッチ・ネットワークのような高価なストレージ・アタッチメントよりは、ネットワークに接続されて使用するストレージのコストを削減します。

DSC で稼働する一元化された ASM 環境を使用することで、メンバー・クラスタは ASM データを共有し、共有ディスク・グループにアクセスすることが可能となります。特別なインフラストラクチャや専用のインフラストラクチャを用意しなくても、多くのテスト・クラスタをすばやく簡単に作成することが可能です。これにより、作成するクラスタごとに独立した共有ストレージ環境をプロビジョニングしようとして多くの企業が直面する、費用と時間のかかる従来の障害が取り除かれます。

クラスタ・ドメイン・アーキテクチャの利点

クラスタ・ドメイン・アーキテクチャおよびドメイン・サービス・クラスタにより、テスト環境と開発環境の短時間での作成、そして大規模クラスタ資産の迅速で効率的な管理が可能となり、DBAおよびシステム管理者の生産性が向上します。たとえば、DSC 内の ASM が管理する本番データベースは、ASM シャドー・コピー機能を使用してクローンを作成することができます。さらには、高速ホーム・プロビジョニングを使用することで、テストと開発用のメンバー・クラスタおよびデータベース・ホームを作成することができます。追加の共有ストレージは必要なく、DSC のストレージ I/O サービスを使用して、新たに作成されたクローン・データベースをネットワーク経由でマウントできます。

クラスタ・ドメイン・アーキテクチャとドメイン・サービス・クラスタは、以下を含め、大規模クラスタ資産を管理する IT 企業に多くのメリットをもたらします。


• 新規メンバー・クラスタの導入とプロビジョニングのしやすさ

• 共有サービスを一度構成するだけで、何度も再利用が可能

• 各メンバー・クラスタごとに共有ストレージをプロビジョニングして構成する必要がない

• 共有ストレージ管理サービス（DSC で実行）またはローカルに構成されたストレージのいずれかとともにデータベース・メンバー・クラスタを展開する場合における柔軟性の提供

• リソースの消費が少なく、ローカル共有ストレージを必要としないデータベースのサポートが不要で、アプリケーション・メンバー・クラスタを高いコスト効率で展開可能

• 一元化された共有サービスなど、ストレージ領域や管理上の負担を抑える複数クラスタの管理と保守において、スケーラビリティによる効率性を提供

Oracle Autonomous Health Framework（Oracle AHF）

Oracle Autonomous Health Framework（Oracle AHF）により、さまざまな次世代ツールが、全体論的監視・管理フレームワーク（図 6 参照）を構成する自律型のコンポーネントとして提供されます。これらのコンポーネントが 24 時間 365 日体制で稼働することで、データベース・システムの健全な稼働が維持され、同時に人的な対応時間が最小限に抑えられます。これらのコンポーネントには、既存のツールに加え、以下の新ツールが含まれます。

• ORAchk

• Cluster Verification Utility

• Trace File Analyzer

• Cluster Health Monitor

• Quality of Service Management および Memory Guard

• Hang Manager

• Cluster Health Advisor（Oracle Real Application Clusters 12c Release 2 の新機能)

Oracle Autonomous Health Framework の各種コンポーネントは、デーモン・モードで連携して機能することで、データベース管理者やシステム管理者が直面する可用性やパフォーマンスの問題に対処します。

Oracle Real Application Clusters 12c Release 2 で導入された、Oracle の Autonomous Health Framework（AHF）により、データセンター内のすべてのデータベースを継続的に監視、分析し、注意を払っていなくてもデータベースやシステムに関するアラートを送出する環境が可能となり、DBA はより重要な作業に集中することができます。AHF は、ドメイン・サービス・クラスタ環境においてより効率的に機能します。これは、継続的な分析ワークロードとデータ管理がなくなり、前述の一元化された Grid Infrastructure Management Repository をホストするドメイン・サービス・クラスタに本番メンバー・クラスタが移動するためです。


図6：Autonomous Health Frameworkは、数多くのツールで構成。個々のツールは、統合され、クラスタ化された

データベース環境の監視と管理における特定の側面に対処するよう作成

図 6 に示す機能はすべて、RAC 環境の管理に DBA およびシステム管理者が使用するツールです。これらすべての機能が、管理情報のデータ・リポジトリとして Grid Infrastructure Management Repository に依存します。Grid Infrastructure Management Repository をホストする一元化されたドメイン・サービス・クラスタにより、大規模な RAC 導入において、より効率的で管理しやすい環境が提供されます。この機能とツールの詳細については、ホワイト・ペーパー『Oracle Database 12c Release 2 Autonomous Health Framework』を参照してください。

Oracle Machine Learningにより強化されたCluster Health Advisorの導入

Oracle Real Application Cluster 12c Release 2 では、新たに Autonomous Health Framework がCluster Health Advisor（CHA）となりました。CHA は、ともに導入された Machine Learning 機能を通じ、RAC クラスタ・データベース環境の"通常の"オペレーションを"学習"し、そのオペレーションを監視することができます。Machine Learning のエンジンを使用して"通常"からの逸脱を分析し、一定の逸脱がある場合は、障害の兆候のあるインスタンスまたはノード障害の可能性を示すフラグが設定されます。DBA およびシステム管理者は、障害を回避するか、または少なくとも障害による影響を最小限に抑えるよう事前に措置を講じることができます。これは、データベースの可用性に影響する、避けることのできないデータベース・インスタンス障害やハードウェア障害を予測し、対処するのに役立つため、お客様から非常に大きい関心が寄せられています。

Oracle Autonomous Health Framework コンポーネントである Cluster Health Advisor（CHA）は、Oracle RAC データベースおよびクラスタ・ノードについて、差し迫ったパフォーマンス問題の事前警告、根本原因、修正措置をシステム管理者とデータベース管理者に提供します。CHA は、デフォルトのモデル（ターゲット・システムの通常の稼働期間に基づいて、強化、調整されたモデル）に基づく、観察によって得られた入力の期待値を予測しています。さらに Oracle Cluster Health Advisor は、観察した値と予測した値との差に基づき、各入力について異常を検出します。特定の問題に関連付けられている十分な入力に異常が見られれば、Oracle Cluster Health Advisor は警告を送出し、直ちに対象の診断と修正措置を生成します。


Oracle Cluster Health Advisor は、後のトリアージのため、診断情報、修正措置、計測データとともに分析結果を Grid Infrastructure Management Repository（GIMR）に格納します。Oracle Cluster Health Advisor は、Oracle Clusterware イベント通知プロトコルを使用して Enterprise Manager Cloud Control への警告メッセージの送信も行います。

Grid Infrastructure（GI）が RAC または RAC One Node データベースにインストールされている場合、Cluster Health Advisor は、デフォルトでは自動的に有効になります。

デフォルトでは、Cluster Health Advisor モデルは、誤った警告通知を避けるため、慎重に判断するよう設計されています。ただし、デフォルトの構成は、クリティカルな本番システムにとって判断基準の厳しさが十分でない場合があります。そのため、Cluster Health Advisor は、デフォルト設定のベースを形成するため実際の本番ワークロード・データを使用して、ノードおよびデータベース・モデルの精度と感度を高めるオンサイト・モデル調整機能を備えています。ワークロードは、個々のクラスタ・ノードや Oracle RAC データベースによって変化する可能性があるため、Cluster Health Advisor は、自らの具体的な調整データを持つ複数のモデルを作成、格納、およびアクティブ化する機能も備えています。

Quality of Service Management - 管理者管理データベースのサポート

Oracle Database 11g Release 2 では、監視と管理のための高度な機能である Quality of Service Management が Real Application Clusters 環境に導入されました。この機能により、同じクラスタで実行されるさまざまなワークロードに対し、パフォーマンス上の目標（応答時間目標）を設定することが可能になりました。目標が達成されなかった場合、QoS Management 機能はクラスタ・リソースの割当変更を推奨し、重要度の低い作業から高い作業にリソースを移動してパフォーマンス目標を再び達成できるようにします。ただし、この機能には、以前からあるデフォルトの"管理者管理"構成ではなく、"ポリシー管理"のデータベース構成が必要でした。Oracle Databases の大半は、“管理者管理”です。Oracle Database 12c Release 2 では、Quality of Service Management により“管理者管理”データベースを操作できるようになり、より重要な作業（お客様が定義）へ戻すようクラスタ・リソースの再割り当てについて推奨事項を示し、パフォーマンス目標を達成できるようにします。

Cluster Activity Log

Cluster Activity Log には、クラスタにおけるリソース・アクティビティに関する情報が含まれています。Cluster Activity Log データは、クラスタ内のリソースの動きを追跡し、各リソースの計画内再配置または計画外再配置によって生じた連鎖反応を理解するために使用することができます。この一元化されたログにより、イベントの検索と分析が容易になり、メンバー・クラスタ上のオーバーヘッドが削減されます。Cluster Activity Log は、「何が起きたか。どのイベントが原因でクラスタが再構成され、クラスタ内のサービスが再配置されたのか」という疑問に答えてくれます。Cluster Activity Log は、Autonomous Health Framework および診断に有用な情報も提供します。


高速ホーム・プロビジョニング（RHP）

高速ホーム・プロビジョニングは、Oracle Real Application Clusters 12c Release 1 から導入され、Release 2 で大幅に改善された機能です。RHP は、数多くの RAC データベースとシングル・インスタンス・データベースおよび基盤となるインフラストラクチャの導入とパッチ適用をさらに容易にします。ソフトウェア（データベース・バイナリやパッチ・セットなど）のインストールは一度だけ必要で、その後 RHP サーバーに格納され、必要になった場合にそこから、データセンター内の任意のノードまたはクラスタにプロビジョニングすることができます。これにより、大規模エンタープライズにおける Oracle データベース・ソフトウェアの導入とパッチ適用の方法において、生産性、効率、標準化、セキュリティが大幅に向上します。

ORACLE REAL APPLICATION CLUSTERS 12C RELEASE 2のおもな機能のまとめ

メリット基盤テクノロジー説明

スケーラビリティの向上 • スマート・マスタリング • プラガブル・データベースとサービスの独立性

• ブロックは使用される割合の高いノードにマスタリング

• RAC環境におけるマルチテナントの最適化により、リカバリ時間が最適化

より優れた可用性 • Application Continuity • Node Weighting • Recovery Buddy

• ノードまたはインスタンスの障害時における透過的なトランザクション完了

• スプリット・ブレイン・クラスタ再構成時の場合、存続ノードがより多くの作業および"critica"と指定された作業を実行

• インスタンス・リカバリは、影響したブロックをマスタリングしないインスタンスには非破壊的

効率的な管理 • クラスタ・ドメイン、ドメイン・サービス・クラスタ

• Autonomous Health Framework o Cluster Health Advisor

• 高速ホーム・プロビジョニング • Cluster Activity Log

• 多数のクラスタの効率的な管理、サービス（ストレージ、分析）の一元化

• サーバーまたはデータベースの潜在的な停止を事前予防的に学習し、対処

• ソフトウェアの一元化された導入と保守を提供 • クラスタ・アクティビティ・データの一元化。

検索イベントと分析イベントを容易に。メン

バー・クラスタ上のオーバーヘッドを削減


結論

Oracle Real Application Clusters 12c Release 2 は、以下の新機能を提供します。

• スマート・マスタリング、プラガブル・データベース、およびサービスの独立性によるスケーラビリティの向上

• アプリケーション・コンティニュイティ、Node Weighting、Recovery Buddy などの新機能や改善された機能による可用性の向上

• クラスタ・ドメイン、ドメイン・サービス・クラスタ、Autonomous Health Framework、高速ホーム・プロビジョニング、一元化された Cluster Activity Log などの機能による、大規模環境での管理効率の向上

数多くの Real Application Clusters 環境にこれまで投資してきたお客様にとって、これらの機能は管理面および運用面でのコストと時間の大幅な削減をもたらします。Real Application Clusters を初めて検討しているお客様または既存の環境のさらなる拡張を考えているお客様にとって、実装と管理における最初のエクスペリエンスでの負担を軽減すると同時に、データベースのより高速でより透過的な高可用性を実現します。

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 © 2017, 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 の登録商標です。0116

Oracle Real Application Clusters 12c Release 2 – 新機能の概要 2017 年 3 月

はじめにReal Application Clustersは、スケーラビリティ、可用性、そして効率的な管理のためのテクノロジーといえます。Oracle Database 12cRelease 2 Real Application Clusters数多くのRACデータベース導入から生まれた特別な挑戦

より優れたスケーラビリティスマート・マスタリングOracle RAC環境におけるマルチテナント（さらなる最適化）。プラガブル・データベースとサービスの独立性PDB環境のサービス独立性によるフェイルオーバー時間の短縮

Flex Cluster - スケーラビリティに優れたアーキテクチャユースケース1：RACリーダー・ノードユースケース2：大規模なパラレル問合せRAC

データベース可用性のさらなる向上Application ContinuityNode-Weightingによるインテリジェント・フェンシングプラガブル・データベースとサービスの独立性Recovery Buddy

より効率的でインテリジェントな管理クラスタ・ドメインおよびドメイン・サービス・クラスタ（DSC）クラスタ・ドメインメンバー・クラスタ一元化されたASMサービスクラスタ・ドメイン・アーキテクチャの利点

Oracle Autonomous Health Framework（Oracle AHF）Oracle Machine Learningにより強化されたCluster Health Advisorの導入Quality of Service Management - 管理者管理データベースのサポートCluster Activity Log高速ホーム・プロビジョニング（RHP）

結論

Documents

Oracle Database 12c Release 2とOracle Real Application ......Oracle RACのスケーリングはノードの数には左右されず、 シャーディングとは違いアプリケーションの変更は必要

Oracle Database 12c Release 2とOracle Real Application ......Oracle RACのスケーリングはノードの数には左右されず、シャーディングとは違いアプリケーションの変更は必要