1. 管理およびデプロイメント・ガイド
  2. Oracle RACの概要

1 Oracle RACの概要

Oracle Real Application Clusters (Oracle RAC)のインストールと管理、および各種コンポーネントと機能についての概要を説明します。

この章の内容は次のとおりです。

1.1 Oracle RACの概要

Oracle RACとその機能について紹介します。

非クラスタのOracle Databaseには、Oracle Databaseとインスタンス間に1対1関係があります。しかし、Oracle RAC環境では、データベースとインスタンス間に1対多の関係があります。Oracle RACデータベースには最大100のインスタンスが存在でき、Foot 1それらすべてが1つのデータベースにアクセスします。すべてのデータベース・インスタンスは同じインターコネクトを使用する必要があり、Oracle Clusterwareもこれを使用します。

各Oracle RACデータベース・インスタンスには次のものも存在するため、Oracle RACデータベースは、非クラスタのOracle Databaseとアーキテクチャが異なります。

  • 各インスタンスの1つ以上の追加REDOスレッド

  • インスタンス固有のUNDO表領域

複数のサーバーの処理能力を組み合せることによって、単一のサーバーの場合よりも優れたスループットおよびOracle RACスケーラビリティを実現できます。

クラスタは、相互に接続された複数のコンピュータまたはサーバーで構成され、エンド・ユーザーおよびアプリケーションからは1つのサーバーとして認識されます。Oracle DatabaseとともにOracle RACオプションを使用すると、Oracle Databaseをクラスタ化できます。Oracle RACでは、インフラストラクチャとしてOracle Clusterwareを使用し、複数のサーバーを関連付けてそれらが単一のシステムとして動作するように構成します。

Oracle Clusterwareは、Oracle Databaseと統合された、ポータブルなクラスタ管理ソリューションです。Oracle Clusterwareは、Oracle RACの実行に必要なインフラストラクチャを提供するOracle RACを使用するために必要なコンポーネントです。Oracle Clusterwareでは、仮想インターネット・プロトコル(VIP)・アドレス、データベース、リスナー、サービスなどのリソースも管理します。さらに、Oracle Clusterwareによって、非クラスタのOracle DatabaseとOracle RACデータベースの両方で、Oracle高可用性インフラストラクチャを使用できます。Oracle ClusterwareとOracle Automatic Storage Management(Oracle ASM) (この2つは一緒になってOracle Grid Infrastructureを構成します)が一緒になることによって、非クラスタとOracle RACデータベースの任意の組合せで使用されるストレージのクラスタ化プールを作成できます。

Oracle RACが動作するほとんどのプラットフォームにおいて、必要なクラスタウェアはOracle Clusterwareのみです。データベース・アプリケーションでベンダー・クラスタウェアが必要とされている場合、このベンダー・クラスタウェアがOracle RAC用に認証されていれば、このクラスタウェアはOracle Clusterwareとともに使用できます。

図1-1に、Oracle DatabaseのオプションであるOracle RACにより、複数のサーバーが1つのOracle Databaseにアクセスするための単一のシステム・イメージが提供される方法を示します。Oracle RACでは、各Oracleインスタンスは異なるサーバー上で実行する必要があります。

図1-1 Oracle RACアーキテクチャでのOracle Database

図1-1の説明が続きます
「図1-1 Oracle RACアーキテクチャでのOracle Database」の説明

従来、Oracle RAC環境は、1つのデータ・センターにあります。ただし、Oracle RACはOracle拡張クラスタ上に構成できます。このアーキテクチャでは、サイト障害からの非常に高速なリカバリを実現し、すべてのサイトのすべてのノードで単一のデータベース・クラスタの一部としてアクティブにトランザクションを処理できます。拡張クラスタでは、クラスタ内のノードは通常、2つのファイア・セルの間、2つの部屋や建物の間、2つの異なるデータ・センターや都市の間など、地理的に分散されます。可用性の理由から、データを両方のサイトに配置する必要があり、これにより、記憶域に対してディスク・ミラーリング技術の実装が必要になります。

このアーキテクチャの実装を選択する場合、特に距離、待機時間および提供される保護の程度を考慮し、このアーキテクチャがビジネスに対してよい解決策となるかどうかを評価する必要があります。拡張クラスタ上のOracle RACは、ローカルのOracle RACクラスタで可能となるよりも優れた高可用性を実現しますが、組織の障害時リカバリ要件を満たすとはかぎりません。適切な分離は一部の災害(局所的停電、サーバー室の冠水など)に対する有効な保護策となりますが、あらゆる種類の障害に効果があるわけではありません。破損や地域災害に対する防御を含む災害に対する包括的な保護策として、『Oracle Data Guard概要および管理』および次のMaximum Availability Architecture(MAA) Webサイトで説明するように、Oracle RACとともにOracle Data Guardを使用することをお薦めします。

Oracle RACは、すべてのタイプのアプリケーションに対して高可用性および高スケーラビリティを提供する特殊な技術です。また、Oracle RACインフラストラクチャは、Oracleエンタープライズ・グリッド・コンピューティング・アーキテクチャを実装するための主要なコンポーネントです。複数のインスタンスが単一のデータベースにアクセスすることで、サーバーがシングル・ポイント障害になることを防止できます。Oracle RACを使用すると、小規模な汎用サーバーをクラスタに組み込んで、ミッション・クリティカルなビジネス・アプリケーションをサポートするスケーラブルな環境を構築できます。Oracle RACデータベースにデプロイするアプリケーションは、コードを変更せずに使用できます。

関連項目

1.2 Oracle RACのインストールの概要

Oracle Universal Installerを使用してOracle Grid InfrastructureおよびOracle Databaseソフトウェアをインストールし、Database Configuration Assistant (DBCA)を使用してデータベースを作成します。

データベースの作成によって、Oracle RAC環境のネットワーク構成、データベース構造およびパラメータ設定が、選択された環境に最適なものになります。

また、Oracle RACのインストールに高速ホーム・プロビジョニングを使用することもできます。これにより、Oracle Universal Installerと以前に指定したDBCAを完全に活用できます。さらに、高速ホーム・プロビジョニングにより、標準化と自動化が可能になります。

この項では、Oracle RACのインストール・プロセスについて説明します。内容は次のとおりです。

関連項目

1.2.1 Oracle RAC環境の互換性

同じクラスタ内で様々なバージョンのOracle Databaseを備えた構成でOracle RACを実行するには、まずOracle Grid Infrastructureをインストールする必要があります。これは、クラスタ内にデプロイする最高バージョンのOracle Databaseと同じバージョン以上にする必要があります。たとえば、Oracle RAC 11gリリース2 (11.2)データベースおよびOracle RAC 12cデータベースを同じクラスタ内で実行するには、Oracle Grid Infrastructure 12cをインストールする必要があります。Oracle RAC環境におけるバージョンの互換性の詳細は、My Oracle Supportに問い合せてください。

注意:

Oracle9iクラスタのOracle Grid Infrastructure 12c環境へのデプロイはサポートされません。

1.2.2 Oracle RACデータベース管理スタイルおよびデータベースのインストレーション

Oracle RACデータベース・ソフトウェアをインストールし、それぞれのデータベースを作成する前に、「サーバー・プールおよびポリシー管理データベースの概要」で説明するとおり、Oracle RACデータベースに適用する管理スタイルについて決めます。

選択する管理スタイルは、ソフトウェアのデプロイメントおよびデータベースの作成に影響を与えます。管理者管理データベース・デプロイメント・モデルを選択し、ソフトウェアのノード単位のインストレーションを使用する場合、Oracle Databaseを実行する予定のノードにのみOracle Databaseソフトウェア(データベース・ホーム)をデプロイすれば十分です。

ソフトウェアのノード単位のインストレーションを使用して、ポリシー管理デプロイメント・モデルを選択した場合、クラスタ内のすべてのノードにソフトウェアをデプロイする必要があります。サーバー・プールへのサーバーの動的割当ては原則的に、データベース・インスタンスが実行される可能性のあるサーバーを予測しないためです。それぞれのデータベース・ホームをホストしないサーバーでのインスタンスの起動障害を避けるには、クラスタ内のすべてのノードにデータベース・ソフトウェアをデプロイすることを強くお薦めします。共有Oracle Databaseホームを使用する場合、クラスタ内のすべてのノードからこのホームへのアクセシビリティが想定されるため、設定では、必要に応じてすべてのサーバーにそれぞれのファイル・システムがマウントされるようにする必要があります。

クラスタ用にOracle Grid Infrastructureをすでにインストールして構成した場合、Oracle Universal Installerでは、クラスタ内のノードにわたってOracle Databaseホームをデプロイすることのみできます。Oracle Universal Installerで、クラスタ内のすべてのノードにわたってデータベース・ホームをデプロイするオプションが得られない場合は、Oracle Universal Installerに表示される前提条件を確認してください。

インストール中は、データベース・ホームのインストール時にデータベースの作成を選択できます。Oracle Universal InstallerはDBCAを実行し、選択したオプションに従ってOracle RACデータベースを作成します。

関連項目:

このオプションを選択する場合の詳細は、「Oracle RACデータベース管理スタイルおよびデータベースの作成」を参照してください

注意:

データベースを作成する前に、Oracle Grid Infrastructureホームでデフォルトのリスナーを実行しておく必要があります。デフォルトのリスナーがOracle Grid Infrastructureホームに存在しない場合は、デフォルトのリスナーを作成するためにOracle Grid InfrastructureホームからNETCAを実行することを指示したエラーがDBCAから返されます。

Oracle RACソフトウェアは、Oracle Databaseインストール・メディアの一部として配布されます。Oracle Databaseソフトウェアのインストール・プロセスでは、クラスタ上でインストールを実行していることが認識されると、デフォルトでOracle RACオプションもインストールされます。Oracle Universal Installerでは、Oracle RACがOracleホームと呼ばれるディレクトリ構造にインストールされます(これは、システムで実行中の他のOracleソフトウェアのOracleホーム・ディレクトリとは別のものです)。Oracle Universal Installerは、クラスタに対応しているため、クラスタの一部として定義したすべてのノードにOracle RACソフトウェアをインストールします。

関連項目

1.2.3 Oracle RACデータベース管理スタイルおよびデータベースの作成

Oracle Databaseのデプロイメントの一部は、データベースの作成です。

「Oracle RACデータベース管理スタイルおよびデータベースのインストール」で説明するとおり、データベース・ソフトウェア・デプロイメントの一部としてデータベースを作成することを選択したり、まずデータベース・ソフトウェアのみをデプロイして、その後にDBCAを使用して、新しく作成されたOracleホームの外側で実行するつもりのデータベースを作成することを選択することができます。いずれの場合も、Oracle RACデータベースに使用する予定の管理スタイルを考慮する必要があります。

管理者管理データベースの場合、それぞれのデータベース・インスタンスを実行する予定のノードにデータベース・ソフトウェアをデプロイする必要があります。これらのノードが、データベース・ファイルを格納する記憶域にアクセスできるようにする必要もあります。記憶域の管理を簡略化するために、データベースのインストール時にOracle ASMを選択することをお薦めします。Oracle ASMは、ディスク・グループ内のすべてのデータベース・ファイルの記憶域を自動的に管理します。Oracle Standard Editionを使用してOracle RACデータベースを作成する場合は、Oracle ASMを使用してすべてのデータベース・ファイルを格納する必要があります。

ポリシー管理データベースの場合、アクティブなサーバー・プール設定を考慮に入れると、データベース・インスタンスを実行する可能性のあるすべてのノードにデータベース・ソフトウェアをデプロイする必要があります。これらのノードが、データベース・ファイルを格納する記憶域にアクセスできるようにする必要もあります。管理者管理データベースのところですでに説明したとおり、Oracle ASMを使用することをお薦めします。

サーバー・プールは、Oracle Grid Infrastructure (特にOracle Clusterware)の機能です。Oracle Clusterwareレベルでサーバー・プールを設定するには様々な方法がありますが、それぞれのデータベースを作成する前に、データベース管理用のサーバー・プールを作成することをお薦めします。ただし、ポリシー管理データベースを作成する場合は、事前に作成されたサーバー・プールを使用するか、新しいサーバー・プールを作成するかの選択肢がDBCAによって提示されます。データベースの作成時に新しいサーバー・プールを作成できるかどうかは、そのときにアクティブになっているサーバー・プールの構成によって決まります。

デフォルトでは、DBCAによって1つのサービスがOracle RACインストール用に作成されます。これはデフォルトのデータベース・サービスで、ユーザーの接続用には使用しないでください。デフォルトのデータベース・サービスは、通常、DB_NAMEおよびDB_DOMAIN初期化パラメータの組合せdb_name.db_domainを使用して識別されます。データベースが制限モードになっていないかぎり、このデフォルトのサービスはOracle RAC環境のすべてのインスタンスで使用できます。

注意:

SRVCTLまたはOracle Enterprise Managerを使用して、メンテナンス操作用にデフォルトのデータベース・サービスを確保し、データベース作成後の手順として、ユーザーまたはアプリケーションの接続用に動的データベース・サービスを作成することをお薦めします。DBCAでは、Oracle RACデータベース用の動的データベース・サービス作成オプションを提供していません。Oracle RAC One Nodeデータベースの場合、少なくとも1つの動的データベース・サービスを作成する必要があります。

関連項目

1.2.4 Oracle RACクラスタの拡張の概要

初期デプロイメント後に、Oracle RACクラスタ(クローニングとも呼ばれます)を拡張し、既存の環境にノードを追加する場合は、クラスタ内で現在使用している管理スタイルを考慮して、複数のレイヤーでこれを行う必要があります。

Oracle RACクラスタを拡張するための様々な手段が用意されています。原則として、現在の環境を拡張するために次のアプローチから選択できます。

  • 新しいOracle RACデータベースとその他のソフトウェアをプロビジョニングするための高速ホーム・プロビジョニング

  • クローニング・スクリプトを使用したクローニング

  • addnode.sh (Windowsの場合はaddnode.bat)スクリプトを使用したノードの追加

環境の初期のデプロイ方法にかかわらず、どちらのアプローチも適用できます。どちらのアプローチも、クラスタを追加する予定のノードに、必要なOracleソフトウェアをコピーします。ノードにコピーされるソフトウェアには、Oracle Grid InfrastructureソフトウェアおよびOracle Databaseホームがあります。

Oracle Databaseホームの場合、クラスタにデプロイされている管理スタイルを考慮する必要があります。管理者管理データベースの場合、それぞれのデータベース・インスタンスを実行する予定のノードにデータベース・ソフトウェアをデプロイする必要があります。ポリシー管理データベースの場合、アクティブなサーバー・プール設定を考慮に入れると、データベース・インスタンスを実行する可能性のあるすべてのノードにデータベース・ソフトウェアをデプロイする必要があります。いずれの場合も、クラスタの一部にするつもりのすべてのノードにまずOracle Grid Infrastructureをデプロイする必要があります。

注意:

Oracleクローニングは、Provisioning Packの一部であるOracle Enterprise Managerを使用したクローニングにかわるものではありません。Oracle Enterprise Managerを使用してOracle RACをクローニングする場合、プロビジョニング・プロセスには、取得するホーム、デプロイする場所、および収集される他の様々なパラメータに関する詳細情報が記述された一連の手順が含まれています。

新規インストールの場合、または1つのOracle RACデータベースのみをインストールする場合は、従来の自動化された対話式インストール方法を使用します(Oracle Universal Installer、高速ホーム・プロビジョニング、Oracle Enterprise ManagerのProvisioning Pack機能など)。クラスタ内のノードにOracle RACを追加したりノードから削除することが目的の場合は、「LinuxおよびUNIXシステムのノードでのOracle RACの追加と削除」に説明されている手順を使用できます。

クローニングのプロセスは、Oracle ClusterwareホームおよびOracle RACを含むOracleホームが1つ以上のノードに正常にインストールされていることを前提としています。さらに、クラスタ・データベースの拡張元となるノードですべてのルート・スクリプトが正常に実行されている必要があります。

関連項目

関連項目:

  • 高速ホーム・プロビジョニングの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

  • Provisioning Packの詳細は、Oracle Enterprise Managerオンライン・ヘルプ・システムを参照してください。

1.3 Oracle Real Application Clusters One Nodeの概要

Oracle Real Application Clusters One Node (Oracle RAC One Node)はOracle Database 11gリリース2 (11.2)以降に使用可能なOracle Database Enterprise Editionのオプションです。

Oracle RAC One Nodeは、クラスタ内の1つのノードで通常の操作のみで実行されるOracle RAC対応データベースの単一インスタンスです。このオプションにより、企業内にOracle Databases用の標準デプロイメントを提供することで管理オーバーヘッドを削減しながら、オラクル社がデータベースの統合に対して提供する柔軟性が向上します。Oracle RAC One Nodeデータベースには、Oracle Grid Infrastructureが必要なため、Oracle RACデータベースと同じハードウェア設定が必要になります。

Oracle RACが認証されているすべてのプラットフォームでOracle RAC One Nodeがサポートされています。Oracle RACと同様に、Oracle Virtual Machine(Oracle VM)でのOracle RAC One Nodeの動作が保証されます。Oracle RACまたはOracle RAC One NodeをOracle VMで使用すると、Oracle RACの高可用性およびスケーラビリティによってOracle VMのメリットが大きくなります。

Oracle RAC One Nodeでは、サーバーのスケーラビリティは無制限で、アプリケーションが増大して単一ノードで提供できるリソース以上のリソースを必要とする場合には、アプリケーションをOracle RACにオンラインでアップグレードできます。Oracle RAC One Nodeが実行されているノードがオーバーロードになった場合は、インスタンスをクラスタ内の別のインスタンスに再配置できます。Oracle RAC One Nodeでは、オンライン・データベース再配置機能を使用して、アプリケーション・ユーザーには停止時間なしでデータベース・インスタンスを再配置できます。あるいは、リソース・マネージャ・インスタンス・ケージングを使用して、クラスタ内のサーバーごとに個々のデータベース・インスタンスのCPU使用率を制限でき、必要な場合は要求シナリオに応じてこの制限を動的に変更できます。

単一クライアント・アクセス名(SCAN)を使用してデータベースに接続すると、クライアントは、データベースが実行されているノードのサービスを独自に特定できます。したがって、クライアント接続によっては、Oracle RAC One Nodeインスタンスの再配置がクライアントに対してほとんど透過的になります。クライアントでの再配置の影響を最小限に抑えるために、アプリケーション・コンティニュイティとOracleの高速アプリケーション通知または透過的アプリケーション・フェイルオーバーを使用することをお薦めします。

Oracle RAC One Nodeデータベースの管理は、Oracle RACデータベースまたは非クラスタ・データベースとは若干異なります。管理者管理Oracle RAC One Nodeデータベースの場合は、候補ノード・リストを監視し、可能であればサーバーがいつでもフェイルオーバーに使用できるようにしておく必要があります。候補サーバーは汎用サーバー・プールに存在し、データベースとそのサービスは、いずれかの候補サーバーにフェイルオーバーします。

ポリシー管理Oracle RAC One Nodeデータベースの場合、現在のノードが使用できなくなった場合にサーバーがデータベースのフェイルオーバーに使用できるように、サーバー・プールが構成されていることを確認する必要があります。この場合、オンライン・データベース再配置用の宛先ノードは、データベースが配置されているサーバー・プールに配置される必要があります。または、サイズが1(サーバー・プール内に1つのサーバー)のサーバー・プールを使用して、最小サイズを1に設定し、クラスタ内で使用されている他のすべてのサーバー・プールに対して重要性を十分に高く設定することで、このサーバー・プールで使用されている1つのサーバーで障害が発生した場合に、そのサーバー・プールに必要に応じて別のサーバー・プールまたは空きサーバー・プールから新しいサーバーが確実に再配置されるようにする方法もあります。

注意:

  • Oracle RAC One Nodeは、クライアントのフェイルオーバー用に、トランザクション・ガードおよびアプリケーション・コンティニュイティをサポートしています。

  • すべての障害の可能性に準備するために、少なくとも1つの動的データベース・サービス(Oracle Clusterware管理データベース・サービス)をOracle RAC One Nodeデータベースに追加する必要があります。

関連項目

1.4 Oracle ClusterwareおよびOracle RACの概要

Oracle Clusterwareは、すべてのOracle Databaseプラットフォームを対象とした完全な統合クラスタウェア管理ソリューションです。

このクラスタウェア機能は、クラスタ・データベースの管理に必要なすべての機能(ノードのメンバーシップ、グループ・サービス、グローバル・リソース管理および高可用性機能)を提供します。

Oracle Clusterwareは、単独でインストールすることも、Oracle RACインストール・プロセスの前提条件としてインストールすることもできます。サービスなどのOracle Database機能は、基盤となるOracle Clusterwareメカニズムを使用して高度な機能を提供します。特定のプラットフォームについては、一部のサード・パーティ製クラスタウェア製品も引き続きサポートされます。

Oracle Clusterwareは、Oracle RACのために設計され、Oracle RACに密接に統合されています。Oracle Clusterwareを使用して、クラスタで高可用性操作を管理できます。任意の管理ツールを使用してOracle RACデータベースを作成する場合、データベースは、VIPアドレス、単一クライアント・アクセス名(SCAN) (SCAN VIPおよびSCANリスナーを含みます)、Oracle Notification Service、Oracle Netリスナーなど他の必須コンポーネントとともにOracle Clusterwareに登録され、これによって管理されます。ノードが起動されるとこれらのリソースは自動的に起動され、リソースに障害が発生すると自動的に再起動されます。Oracle Clusterwareデーモンは各ノードで実行されます。

Oracle Clusterwareが管理するものはすべてCRSリソースと呼ばれます。CRSリソースには、データベース、インスタンス、サービス、リスナー、VIPアドレス、アプリケーション・プロセスがあります。Oracle Clusterwareは、Oracle Cluster Registry(OCR)に格納されているリソースの構成情報に基づいてCRSリソースを管理します。SRVCTLコマンドを使用して、すべてのOracle定義のCRSリソースを管理できます。Oracle Clusterwareは、クラスタ内のOracleによって事前定義されていないサーバー上で動作するすべてのプロセスを管理するためのCRSリソースを作成できるフレームワークを提供します。Oracle Clusterwareは、これらのコンポーネントの構成を説明する情報を管理可能なOCRに保存します。

Oracle Flex Clusterには、ハブ・ノードをリーフ・ノードに(またはその逆に)変換できるという利点もあります。また、1つのリーフ・ノードは停止時間なしでハブ・ノードに変換できます。

この項には次のトピックが含まれます:

関連項目

1.4.1 Oracle Flex Clusterの概要

Oracle Flex Clusterは、多数のノードを持つOracle RACデータベースなどの各種アプリケーションにプラットフォームを提供します。

Oracle Flex Clusterでは、高可用性のために調整および自動化が必要な他のサービス・デプロイメントのプラットフォームも提供されます。

Oracle Flex Cluster内のすべてのノードは、単一のOracle Grid Infrastructureクラスタに属します。このアーキテクチャでは、様々なサービス・レベル、負荷、障害のレスポンス、およびリカバリに対処するために、アプリケーション・ニーズに基づいてリソースのデプロイメントに対するポリシー決定が集中管理されます。

Oracle Flex Clusterには、ハブおよびスポーク・アーキテクチャに配置される2つのタイプのノード(ハブ・ノードおよびリーフ・ノード)が含まれます。Oracle Flex Cluster内のハブ・ノードの最大数は64です。リーフ・ノードの数は、さらに多くできます。ハブ・ノードおよびリーフ・ノードでは、様々なタイプのアプリケーションをホストできます。

関連項目

1.4.2 リーダー・ノードの概要

リーダー・ノードは、Oracle Flex Clusterのリーフ・ノードで実行するOracle RACデータベースのインスタンスです。これは、Oracle Clusterwareの以前のリリースでは使用できなかった機能です。

リーダー・ノードの使用の利点は、ハブ・ノードの再構成が必要になったときに、該当するインスタンスに影響を与えないことです。リーダー・ノードで実行するパラレル問合せジョブは、ハブ・ノードの再構成時に発生することがあるブラウンアウト時間に影響されなくなり、リーダー・ノードの接続先のハブ・ノードがクラスタから削除されないかぎり、そのリーダー・ノードに接続しているクライアントにサービスを続行できます。リーダー・ノードは、ハブ・ノードごとに64個までスケール・アップできます。また、リーダー・ノードは大規模なデータ・セットに対する操作を高速化するために大量のパラレル問合せを使用できます。

リーダー・ノードで実行するデータベース・インスタンスは、ハブ・ノードで実行するデータベース・インスタンスとは異なる特性があります。ハブ・ノードのインスタンスは、以前のバージョンのOracle RACデータベース・インスタンスと同じですが、リーダー・ノードで実行するインスタンスには、次に示す重要な相違点があります。

  • データベース・インスタンスは、読取り専用モードで実行します。

  • データベース・インスタンスは、ハブ・ノード・クラスタウェアを再構成する場合にも影響を受けません。リーダー・ノードで実行するデータベース・インスタンスは、ブラウンアウト時間に影響されなくなり、リーダー・ノードの接続先のハブ・ノードがクラスタから削除されないかぎり、そのリーダー・ノードに接続しているクライアントにサービスを続行できます。リーダー・ノードを使用すると、ハブごとに最大64個のリーダー・ノードまでスケール・アップできます。

  • リーダー・ノードで実行しているデータベースは読取り専用であるため、DDL操作またはDML操作を実行しようとするとエラーが返されます。

リーダー・ノードで実行する読取り専用のインスタンスに問合せを転送するサービスを作成できます。このようなサービスでは、さらにパフォーマンスを向上するためにパラレル問合せを使用できます。これらのリーダー・ノードのメモリーのサイズは、できるかぎり大きくして、パラレル問合せが最高のパフォーマンスを発揮するためのメモリーを使用できるようにします。

1.4.3 ローカル一時表領域の概要

I/O操作を強化するために、Oracle Database 12c リリース2 (12.2)にはローカル一時表領域が導入されています。これにより、スピル・オーバーはリーダー・ノードのローカル・ディスクに書き込まれるようになります。

ハッシュ集約、ソート、ハッシュ結合、WITH句のカーソル持続期間一時表の作成、ディスク(具体的には共有ディスク上のグローバル一時表領域)へのスピル・オーバーのためのスター型変換などのSQL操作は引き続き可能です。ローカル一時表領域の管理は、既存の一時表領域の管理と同じです。

ローカル一時表領域は、次の点で読取り専用インスタンスでの一時表領域管理を向上します。

  • リーダー・ノードのプライベート記憶域に一時ファイルを保存することで、ローカル記憶域のI/Oのメリットを活用します。

  • コストの高いインスタンス間の一時表領域管理を回避します。

  • 一時表領域のアクセス性が向上されます。

  • ディスク上の領域メタデータ管理の排除により、インスタンスのウォームアップ・パフォーマンスが向上します。

注意:

ローカル一時表領域は、データベース・オブジェクト(表や索引など)の保存には使用できません。これと同じ制限がOracleグローバル一時表にも適用されます。

この項には次のトピックが含まれます:

カーソル持続期間一時表領域のパラレル実行のサポート

WITH句およびスター型変換のために作成された一時表領域は、共有ディスク上の一時表領域に存続します。パラレル問合せの子プロセスのセットは、このような一時表領域に問合せの中間結果をロードします。この結果は、後から別の子プロセスのセットによって読み込まれます。こうした結果を読み取る子プロセスの割当て方法には制限はありません。これは、任意のインスタンス上の任意のパラレル問合せ子プロセスが、共有ディスク上に存在する一時表領域を読み取ることができるためです。

読取り/書込みおよび読取り専用インスタンス・アーキテクチャの場合、パラレル問合せ子プロセスは、これらのインスタンスのローカル一時表領域に中間結果をロードするため、中間結果が保存されているインスタンスに属しているパラレル問合せ子プロセスは、中間結果の読取りをアフィニティと共有するため、中間結果を読み取れるようになります。

ローカル一時表領域の編成

ローカル一時表領域は、次に示すように、{FOR_RIM | FOR ALL}拡張を使用して作成できます。 

CREATE LOCAL TEMPORARY TABLESPACE FOR RIM local_temp_ts_for_rim TEMPFILE\
   '/u01/app/oracle/database/12.2.0.1/dbs/temp_file_rim'\
   EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M AUTOEXTEND ON;

  • ローカル一時表領域を作成すると、単一のファイルではなく、インスタンスごとにローカル一時ファイルを作成することになります。これは、現時点では、共有グローバル一時表領域にも当てはまります。

  • ローカル一時表領域は、読取り専用インスタンスと読取り/書込みインスタンスの両方に作成できます。LOCAL FOR RIMオプションを使用すると、読取り専用インスタンスのローカル・ディスクにファイルが存在するローカル一時表領域が作成されます。LOCAL FOR ALLオプションを使用すると、読取り専用インスタンスと読取り/書込みインスタンスの両方のローカル・ディスクにファイルが存在するローカル一時表領域が作成されます。次に例を示します。 

    CREATE LOCAL TEMPORARY TABLESPACE FOR ALL temp_ts_for_all  TEMPFILE\
  ‘/u01/app/oracle/database/12.2.0.1/dbs/temp_file_all’\
  EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M AUTOEXTEND ON;

一時表領域の階層

ローカル一時表領域と共有(既存の)一時表領域を定義するときに、それらが使用する階層が存在します。この階層を理解するために、データベース用のデフォルト共有一時表領域と個別のユーザーに割り当てられる複数の一時表領域のように、1つのデータベース内に複数の共有一時表領域が存在することに注意してください。ユーザーに共有一時表領域が割り当てられている場合は、その表領域が最初に使用されます。それ以外の場合は、デフォルトの一時表領域が使用されます。

問合せの処理時に書出し用の表領域が選択されると、別の表領域に切り替えられることはなくなります。たとえば、ユーザーに共有一時表領域が割り当てられていて、その領域が書出し中に使い果たされても、代替の表領域に切り替えられることはありません。その場合は、書出しによるエラーが発生します。さらに、共有一時表領域はインスタンス間で共有されることに注意してください。

ローカル一時表領域への書出し用の一時領域の割当ては、読取り専用インスタンスと読取り/書込みインスタンスでは異なります。読取り専用インスタンスの場合、書出しに使用する一時的な場所を選択する際の優先順位は次のようになります。

  1. ユーザーのローカル一時表領域からの割当て。

  2. データベースのデフォルト・ローカル一時表領域からの割当て。

  3. ユーザーの一時表領域からの割当て。

  4. データベースのデフォルト一時表領域からの割当て。

注意:

データベースにローカル一時表領域が存在しない場合、読取り専用インスタンスは共有一時表領域に書出しするようになります。

読取り/書込みインスタンスの場合、割当ての優先順位は前述の割当て順序と異なります。これは、次に示すように、共有一時表領域に優先順位が与えられているためです。

  1. ユーザーの共有一時表領域からの割当て。

  2. ユーザーのローカル一時表領域からの割当て。

  3. データベースのデフォルト共有一時表領域からの割当て。

  4. データベースのデフォルト・ローカル一時表領域からの割当て。

注意:

ローカル一時表領域を使用する読取り/書込みインスタンスの場合、その一時表領域はLOCAL...FOR ALLオプションを指定して作成されている必要があります。

ローカル一時表領域の機能

インスタンスはローカル一時表領域を共有できないため、あるインスタンスが別のインスタンスからローカル一時表領域を取得することはできません。あるインスタンスが書出し中に一時表領域を使い果たすと、その文によってエラーが発生します。

  • ローカル一時表領域は、表領域ごとに1つのBIGFILEのみをサポートします。

  • BIGFILEベースのローカル一時表領域が1つしかないために発生する競合の問題に対処するために、それぞれのユーザーにデフォルトとして複数のローカル一時表領域を割当てできます。

  • データベース管理者は、ALTER USER構文を使用して、デフォルトの一時表領域をユーザーに指定できます。次に例を示します。 

    ALTER USER MAYNARD LOCAL TEMPORARY TABLESPACE temp_ts_for_rim;

  • ユーザーは、2つのデフォルト一時表領域で構成できます。

    • 1つのローカル一時(FOR RIMオプションを指定して作成): ユーザーがリーダー・ノードで実行している読取り専用インスタンスに接続する場合。

    • 1つの共有一時表領域: 同じユーザーがハブ・ノードで実行している読取り/書込みインスタンスに接続したときに使用されます。

ローカル一時ファイルのメタデータ管理

現時点では、一時ファイルの情報(ファイル名、作成サイズ、作成SCN、一時ブロック・サイズ、ファイル・ステータスなど)は、自動エクステントの属性および初期ファイルと最大ファイルとともに制御ファイルに保存されます。ただし、制御ファイルのローカル一時ファイルに関する情報は、適用可能なすべてインスタンスに共通のものになります(LOCAL...FOR ALLの場合は読取り/書込みおよび読取り専用、およびLOCAL...FOR RIMの場合は読取り専用)。

インスタンス固有の情報(割当てのビットマップ、一時ファイルの現在のサイズ、ファイル・ステータスなど)は、インスタンスのSGAに保存され、制御ファイルには保存されません。これは、この情報がインスタンスごとに異なることがあるためです。インスタスは、起動時に制御ファイルの情報を読み取って、そのインスタンスのローカル一時表領域を構成する一時ファイルを作成します。1つのノードで実行しているインスタンスが複数存在する場合、それぞれのインスタンスが専用のローカル一時ファイルを持つようになります。

ローカル一時表領域の場合は、関連するインスタンスごとに個別のファイルが存在します。LOCAL...FOR RIMオプションを使用してローカル一時表領域を作成すると、読取り専用インスタンスにのみファイルが作成されます。LOCAL...FOR ALLオプションを使用してローカル一時表領域を作成すると、すべてのインスタンスにファイルが作成されます。ローカル一時ファイルの名前は、ローカル一時表領域の作成時に指定した一時ファイルの名前にインスタンス番号が付加されるというネーミング規則に従います。

たとえば、読取り専用ノードN1で番号3および4の2つの読取り専用Oracleデータベース・インスタンスを実行していると仮定します。次に示すDDLコマンドにより、ノードN1に2つのファイル/temp/temp_file_rim_3と/temp/temp_file_rim_4が、それぞれインスタンス3と4に作成されます。 

CREATE LOCAL TEMPORARY TABLESPACE FOR RIM temp_ts_for_rim TEMPFILE  '/temp/temp_file_rim'\
   EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M AUTOEXTEND ON;

2つの読取り/書込みインスタンス(インスタンス番号1および2)と、2つの読取り専用インスタンス(インスタンス番号3および4)があるとします。次に示すDDLコマンドにより、4つのファイルが作成されます。インスタンス1と2には、それぞれ/temp/temp_file_all_1と/temp/temp_file_all_2が作成され、インスタンス3と4には、それぞれ/temp/temp_file_all_3と/temp/temp_file_all_4が作成されます。 

CREATE LOCAL TEMPORARY TABLESPACE FOR ALL  temp_ts_for_all TEMPFILE  '/temp/temp_file_all'\
   EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M AUTOEXTEND ON;

ローカル一時表領域のDDLサポート

ローカル一時表領域と一時ファイルの管理には、ALTER TABLESPACEとALTER DATABASEのどちらか、または両方のDDLコマンドを使用します。ローカル一時表領域の管理と作成に関連するすべてのDDLコマンドは、読取り/書込みインスタンスから実行します。その他すべてのDDLコマンドの実行は、すべてのインスタンスに同様に作用します。

たとえば、次のコマンドは、一時ファイルとすべての読取り専用インスタンスのサイズを変更します。

ALTER TABLESPACE temp_ts_for_rim RESIZE 1G;

ローカル一時表領域の場合は、現時点で一時ファイルに対してアクティブな割当てオプションとその制限がサポートされます。

読取り専用インスタンスのローカル一時表領域にのみDDLコマンド(特に、CREATE LOCAL TABLESPACE...FOR RIMまたはALTER TABLESPACE LOCAL TABLESPACE...FOR RIM)を実行するには、クラスタ内に少なくとも1つの読取り専用インスタンスが必要です。この制限は、ローカル一時表領域FOR ALLの作成時または変更時には適用されません。ユーザーは、ALTER DATABASEコマンドにDEFAULT LOCAL TEMPORARY TABLESPACE句を追加することで、デフォルト一時表領域をデータベースに割り当てることができます。

注意:

注釈のFOR RIMは、表領域の名前で暗示されているため必要ありません。

次に例を示します。

ALTER DATABASE DEFAULT LOCAL TEMPORARY TABLESPACE temp_ts_for_rim;

データベース管理者は、次に示すように、データベースの作成時にデフォルト一時表領域を指定できます。

CREATE DATABASE .. DEFAULT TEMPORARY TABLESPACE temp_ts_for_dbtemp_ts_for_rim TEMPFILE\
   '/temp/temp_file_for_dbrim' EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M AUTOEXTEND ON;

CREATE DATABASEコマンドを使用して、デフォルト一時表領域を指定することはできません。データベースの作成時、そのデータベースのデフォルト・ローカル一時表領域はデフォルト共有一時表領域を指すようになります。データベース管理者は、ALTER DATABASEコマンドを実行して、既存のローカル一時表領域をデータベースのデフォルトとして割り当てる必要があります。

ユーザー用のローカル一時表領域

ユーザーの作成時に、共有またはローカルの一時表領域を指定しないと、そのユーザーは対応するデフォルトの一時表領域から共有またはローカルの一時表領域を継承します。ユーザー用のローカル一時表領域は、次のように指定できます。

CREATE USER new_user IDENTIFIED BY new_user LOCAL TEMPORARY TABLESPACE temp_ts_for_all;

ユーザー用のローカル一時表領域は、次に示すようにALTER USERコマンドを使用して変更できます。 

ALTER USER maynard LOCAL TEMPORARY TABLESPACE temp_ts_for_rim;

前述したように、デフォルトのユーザー・ローカル一時表領域は、一時領域で共有されることがあります。ALTER USER...TEMPORARY TABLESPACEコマンドでは、次の事項について考慮します。

  • ユーザーのデフォルト・ローカル一時表領域は、任意のローカル一時表領域に変更できます。

  • ユーザーのデフォルト・ローカル一時表領域を共有一時表領域Tに設定する場合、Tはデフォルト共有一時表領域と同じであることが必要です。

  • デフォルトのユーザー・ローカル一時表領域が共有一時表領域を指しているときに、ユーザーのデフォルト共有一時表領域を変更する場合は、デフォルトのローカル一時表領域も、その表領域に変更します。

次に、ALTERコマンドを使用してローカル一時領域を管理するいくつかの例を示します。

  • ローカル一時表領域をオフラインにするには:

    ALTER DATABASE TEMPFILE ‘/temp/temp_file_rim’ OFFLINE;

  • ローカル一時表領域のサイズを縮小するには:

    ALTER TABLESPACE temp_ts_for_rim SHRINK SPACE KEEP 20M

  • ローカル一時ファイルの自動拡張の属性を変更するには:

    ALTER TABLESPACE temp_ts_for_rim AUTOEXTEND ON NEXT 20G

  • ローカル一時ファイルのサイズを変更するには:

    ALTER TABLESPACE temp_ts_for_rim RESIZE 10G

    注意:

    ローカル一時ファイルのサイズを変更すると、そのサイズは個別のファイルに適用されます。

前述のいずれかのコマンドを実行すると、一部の読取り専用インスタンスは停止することがあります。これによって、コマンドの正常な実行が妨げられることはありません。その理由は、その後の起動時に、読取り専用インスタンスは制御ファイルの情報に基づいて新しい一時ファイルを作成するためです。作成は短時間で完了します。これは、一時ファイルのヘッダー・ブロック(特に、ファイル・サイズに関する情報を記録するブロック)のみがリフォーマットされるためです。一時ファイルのいずれかが作成できな場合は、読取り専用インスタンスが停止したままになっています。読取り/書込みインスタンスか発行したコマンドは、オープンしているすべての読取り専用インスタンスで即座にリプレイされます。

コマンドの原子性要件

読取り/書込みインスタンスから実行するすべてのコマンドは、原子的な方法で実行されます。つまり、コマンドは、すべてのライブ・インスタンスで成功した場合にのみ成功するということです。

ローカル一時表領域とディクショナリのビュー

ディクショナリのビューは、ローカル一時表領域に関する情報を表示するように拡張されています。次に示す変更が行われています。

  • AWRやSQLモニタなどのユーティリティを通じて公開される一時表領域と一時ファイルに関連する診断可能なすべての情報は、ローカル一時表領域とローカル一時ファイルについても使用できます。この情報は、一時表領域と一時ファイルの既存ディクショナリ・ビュー(DBA_TEMP_FILES、DBA_TEMP_FREE_SPACE)で得られます。

  • ディクショナリ・ビューのUSER_TABLESPACESとDBA_TABLESPACESは、SHAREDという列によって拡張されています。この列は、一時ファイルがローカル(FOR RIMまたはFOR ALL)と共有のどちらであるかを示します。

  • DBA_TEMP_FILESディクショナリ・ビューは、2つの列SHAREDとINST_IDによって拡張されています。SHARED列は、一時ファイルがローカル(FOR RIMまたはFOR ALL)と共有のどちらであるかを示します。INST_ID列には、インスタンス番号が格納されます。共有一時ファイルの場合、ファイルごとに1つの行が存在し、INST_IDはnullになります。ローカル一時ファイルの場合、この列には、バイト単位のファイル・サイズ(BYTES列)など、インスタンスごとの一時ファイルに関する情報が格納されます。

    注意:

    LOCAL...FOR RIMは、ファイルごとの読取り専用インスタンスのみを示します。

  • DBA_TEMP_FREE_SPACEディクショナリ・ビューは、2つの列SHAREDとINST_IDによって拡張されています。SHARED列は、一時ファイルがローカル(FOR RIMまたはFOR ALL)と共有のどちらであるかを示します。INST_ID列には、インスタンス番号が格納されます。共有一時ファイルの場合、ファイルごとに1つの行が存在し、INST_IDはnullになります。ローカル一時ファイルの場合、この列には、使用可能な合計空き領域(FREE_SPACE列)など、インスタンスごとの一時ファイルに関する情報が格納されます。

    注意:

    LOCAL...FOR RIMは、ファイルごとの読取り専用インスタンスのみを示します。

  • DBA_TABLESPACESなどのディクショナリ・ビューでは、次の値を含むSHARED列を使用して表領域のタイプが区別されます。

    • SHARED: 共有一時表領域の場合

    • LOCAL_ON_ALL: すべてのインスタンス上のローカル一時表領域の場合

    • LOCAL_ON_RIM: 読取り専用インスタンス上のローカル一時表領域の場合

    注意:

    現時点では、問合せの一時表領域への書出し(ソートやハッシュ結合の書出しなど)は、自動的に暗号化されます。これは、ローカル一時表領域への書出しにも当てはまります。

関連項目

1.5 Oracle RACのアーキテクチャおよび処理の概要

Oracle RACの最小要件として、Oracle Clusterwareソフトウェア・インフラストラクチャが満たしている必要があるのは、同じ記憶域および同じ一連のデータ・ファイルにクラスタ内のすべてのノードから同時にアクセスできること、クラスタ内のノード同士でプロセス間通信(IPC)ができる通信プロトコルが用意されていること、論理的に結合された単一のキャッシュ上にデータが存在するかのように、複数のデータベース・インスタンスでデータを処理できること、およびクラスタ内のノードのステータスを監視して通信するメカニズムが用意されていることです。

詳細は、次の項を参照してください。

1.5.1 クラスタを認識する記憶域ソリューション

Oracle RACデータベースは、Shared Everythingデータベースです。Oracle RAC環境のすべてのデータ・ファイル、制御ファイル、SPFILEおよびREDOログ・ファイルは、すべてのクラスタ・データベース・インスタンスがこれらの記憶域コンポーネントにアクセスできるように、クラスタ対応共有ディスクに存在している必要があります。Oracle RACデータベースはShared Everythingアーキテクチャを使用するため、Oracle RACでは、すべてのデータベース・ファイルに対して、クラスタで認識される記憶域が必要です。

Oracle RACでは、Oracle Databaseソフトウェアによってディスク・アクセスが管理され、様々な記憶域アーキテクチャでの使用が保証されています。記憶域の構成方法は自由に選択できますが、サポートされているクラスタを認識する記憶域ソリューションを使用する必要があります。Oracle Databaseでは、次のようなOracle RAC用の記憶域オプションが用意されています。

  • Oracle Automatic Storage Management(Oracle ASM)

    記憶域の管理にはこのソリューションをお薦めします。

  • 認定されたクラスタ・ファイル・システム

    • Oracle Automatic Storage Management Cluster File System (Oracle ACFS)をお薦めします。

    • クラスタ対応ボリューム・マネージャ上の、Oracle RAC用に認定されているサード・パーティのクラスタ・ファイル・システム。次に例を示します。

      • Oracle OCFS2 (Linuxのみ)

      • IBM GPFS (IBM AIXのみ)

  • 認定されたネットワーク・ファイル・システム(NFS)・ソリューション

1.5.2 Oracle RACおよびネットワーク接続性

Oracle RAC環境内のすべてのノードは、ユーザーおよびアプリケーションがデータベースにアクセスできるようにするために、少なくとも1つのLocal Area Network (LAN) (一般にパブリック・ネットワークと呼ばれます)に接続する必要があります。

Oracle RACでは、パブリック・ネットワークに加えて、ノードとこのノード上で動作するインスタンスの間の通信専用に使用するプライベート・ネットワーク接続が必要になります。このネットワークは、一般にインターコネクトと呼ばれます。

インターコネクト・ネットワークは、クラスタ内のすべてのサーバーに接続するプライベート・ネットワークです。インターコネクト・ネットワークは、1つ以上のスイッチと1つのギガビット・イーサネット・アダプタを使用する必要があります。

注意:

  • より大きい帯域幅とのインタフェースはサポートされていますが、インターコネクトとの間のクロスオーバー・ケーブルの使用はサポートされていません。

  • キャッシュ・フュージョンによってインターコネクトがインスタンス間通信で使用されるため、ユーザー通信でインターコネクト(プライベート・ネットワーク)を使用しないでください。

インターコネクト上のインスタンス間通信用にユーザー・データグラム・プロトコル(UDP)またはリライアブル・データ・ソケット(RDS)・プロトコルのいずれかを使用するようにOracle RACを構成できます。Oracle Clusterwareは、UDPプロトコルを使用して同じインターコネクトを使用しますが、RDSを使用するように構成することはできません。

ネットワーク接続ストレージ(NAS)を使用する場合、追加のネットワーク接続が必要になります。ネットワーク接続ストレージは、NFSファイラなどの通常のNASデバイスに、またはFibre Channel over IPなどを使用して接続されるストレージにできます。この追加のネットワーク通信チャネルは、Oracle RAC (パブリックおよびプライベート・ネットワーク通信)で使用されている他の通信チャネルとは独立させる必要があります。他のネットワーク通信チャネルの1つを使用してストレージ・ネットワーク通信を収束する必要がある場合は、ストレージ関連の通信が1番目の優先順位を得るようにする必要があります。

1.5.3 Oracle Databasesに接続するための動的データベース・サービスの使用の概要

アプリケーションは、動的データベース・サービス機能を使用して、パブリック・ネットワークを介してOracle Databaseに接続する必要があります。

動的データベース・サービスでは、規則および特性を定義して、ユーザーおよびアプリケーションからデータベース・インスタンスへの接続方法を制御できます。これらの特性には、一意の名前、ワークロード・バランシング、フェイルオーバー・オプションおよび高可用性特性が含まれます。

ユーザーは、クライアント/サーバー構成を使用するか、または接続プーリングを任意に使用し、1つ以上の中間層を介してOracle RACデータベースにアクセスします。デフォルトでは、Oracle RACデータベースへのユーザー接続は、TCP/IPプロトコルを使用して確立されますが、他のプロトコルもサポートされています。Oracle RACデータベース・インスタンスには、クラスタのSCANを使用してアクセスする必要があります。

関連項目

1.5.4 仮想IPアドレスの概要

Oracle Clusterwareは、パブリック・ネットワーク上のノードの仮想IP (VIP)アドレスをホストします。クライアントがOracle RACデータベースにアクセスするために使用するノードのVIPおよびVIPアドレスです。データベース・クライアントからOracle RACデータベース・インスタンスへの通常の接続試行は、次のようにまとめることができます。

  1. データベース・クライアントは、SCAN (パブリック・ネットワーク上のSCAN VIPを含む)に接続して、有効なサービス名をSCANリスナーに提供します。

  2. 次にSCANリスナーは、このサービスをホストするデータベース・インスタンスを判別し、それぞれのノード上のローカル・リスナーまたはノード・リスナーにクライアントをルーティングします。

  3. ノード・リスナーは、ノードVIPおよび特定のポートでリスニングして、接続リクエストを取得し、クライアントをローカル・ノードのインスタンスに接続します。

クラスタ上で複数のパブリック・ネットワークを使用して、複数のサブネットを介したクライアント接続をサポートする場合、サブネット内で前述の操作を実行します。

ノードで障害が発生した場合、VIPアドレスは、VIPアドレスがTCP接続を受け入れることができる別のノードにフェイルオーバーされますが、このノードはOracle Databaseへの接続は受け入れません。ホーム・ノードに存在しないVIPアドレスに接続を試行するクライアントは、TCP接続タイムアウト・メッセージを待機するかわりにrapid connection refusedエラーを受け取ります。VIPが構成されたネットワークがオンラインに戻ると、Oracle Clusterwareは、接続が受け入れられたホーム・ノードにVIPをフェイルバックします。通常、VIPアドレスは次の場合にフェイルオーバーされます。

  • VIPアドレスが実行されているノードで障害が発生した場合

  • VIPアドレスのすべてのインタフェースに障害が発生した場合

  • VIPアドレスのすべてのインタフェースがネットワークから切断された場合

Oracle RAC 12cでは、様々なサブネットを介してクラスタへのアクセスを可能にするために、複数のパブリック・ネットワークがサポートされています。各ネットワーク・リソースは専用のサブネットを表し、各データベース・サービスは特定のネットワークを使用してOracle RACデータベースにアクセスします。各ネットワーク・リソースは、Oracle Clusterwareで管理されるリソースで、これにより、すでに説明したVIPの動作が可能になります。

SCANは、組織のドメイン・ネーム・サーバー(DNS)に、または3つのIPアドレスにラウンド・ロビンするグリッド・ネーミング・サービス(GNS)に定義された単一ネットワーク名です。Oracle RACデータベースへのすべての接続で、クライアント接続文字列にSCANを使用することをお薦めします。受信する接続は、3つのSCANリスナーを介して、要求されたサービスを提供するアクティブなインスタンス間でロード・バランシングされます。SCANを使用すると、クラスタの構成を変更(ノードの追加や削除)した場合にも、クライアント接続を変更する必要はありません。以前のリリースとは異なり、Oracle RAC 12cのSCANは、複数のサブネットをサポートし、これは、クラスタを動作させるサブネットごとに1つのSCANを作成できるという意味になります。

1.5.5 Oracle RACのサービス登録の制限

有効なノードの確認機能により、登録要求がリスナーにより許可される一連のIPアドレスまたはサブネットを構成および動的に更新する機能が提供されます。

リスナーへのデータベース・インスタンスの登録は、リクエスト元が有効なノードである場合にのみ成功します。ネットワーク管理者は、有効なノードおよび除外ノードのリストを指定したり、有効なノードの確認を無効にすることができます。有効なノードのリストでは、データベースに登録できるノードやサブネットを明示的にリストします。除外ノードのリストでは、データベースに登録できないノードを明示的にリストします。動的登録を制御することによって、Oracle RACデプロイメントの管理性およびセキュリティが向上します。

登録のための有効なノードの確認(VNCR)はデフォルトで有効になっています。デフォルト構成では、SCANリスナーのサブネット内のすべてのノードからの登録要求をリスナーに登録できます。非SCANリスナーでは、ローカル・ノード上のインスタンスからの登録のみが受け入れられます。リモート・ノードまたはSCANリスナーのサブネット外のノードは、listener.oraファイルのregistration_invited_nodes_aliasパラメータを使用して、またはSRVCTLによってSCANリスナーを変更して、有効なノードのリストに含める必要があります。

1.5.6 Oracle RACソフトウェア・コンポーネント

通常、Oracle RACデータベースには、それぞれにメモリー構造およびバックグラウンド・プロセスが含まれる複数のデータベース・インスタンスがあります。Oracle RACデータベースには、非クラスタOracle Databaseと同じプロセスおよびメモリー構造があり、さらに、Oracle RAC固有の追加プロセスおよびメモリー構造があります。1つのインスタンスのデータベース・ビューは、同じOracle RACデータベース内の他のインスタンスのビューとほぼ同じで、ビューはその環境の単一のシステム・イメージです。

各インスタンスのシステム・グローバル領域(SGA)には、バッファ・キャッシュが存在します。キャッシュ・フュージョンの使用によって、Oracle RAC環境で各インスタンスのバッファ・キャッシュが論理的に結合され、論理的に結合された単一のキャッシュにデータが存在する場合と同様に、インスタンスでデータを処理できます。

注意:

  • インメモリー・トランザクション・マネージャはキャッシュ・フュージョン・プロトコルと統合しています。

  • キャッシュ・フュージョンによって、Oracle RACでのSGAのサイズ要件は、非クラスタOracle DatabaseでのSGAのサイズ要件より大きくなります。

問合せまたはトランザクションを正しく処理するために必要なブロックを、各Oracle RACデータベース・インスタンスが確実に取得できるようにするために、Oracle RACインスタンスでは、グローバル・キャッシュ・サービス(GCS)およびグローバル・エンキュー・サービス(GES)の2つのプロセスが使用されます。GCSおよびGESは、グローバル・リソース・ディレクトリ(GRD)を使用して、各データ・ファイルおよび各キャッシュ・ブロックのステータスのレコードをメンテナンスします。GRDの内容はすべてのアクティブ・インスタンス間で分散され、Oracle RACインスタンスのSGAのサイズが実質的に増加します。

1つのインスタンスがデータをキャッシュした後は、同じクラスタ・データベース内の他のインスタンスは、ディスクからブロックを読み取るよりも高速に、同じデータベース内の別のインスタンスからブロック・イメージを取得できるようになります。そのため、キャッシュ・フュージョンは、ディスクからブロックを再読取りするのではなく、現行のブロックをインスタンス間で移動します。一貫性のあるブロックや変更されたブロックが別のインスタンスで必要な場合、キャッシュ・フュージョンは、影響を受けるインスタンス間でブロック・イメージを直接転送します。Oracle RACは、インスタンス間通信およびブロック転送にプライベート・インターコネクトを使用します。GES Monitorおよびインスタンス・エンキュー・プロセスは、キャッシュ・フュージョン・リソースへのアクセスおよびエンキューのリカバリ・プロセスを管理します。

関連項目

1.5.7 Oracle RACバックグラウンド・プロセス

GCSプロセス、GESプロセスおよびGRDが連係してキャッシュ・フュージョンを実現しています。Oracle RACプロセスおよびその識別子は次のとおりです。

  • ACMS: メモリー・サービスへのアトミック制御ファイル(ACMS)

    Oracle RAC環境では、ACMSのインスタンスごとのプロセスは、分散SGAメモリー更新が成功時にグローバルにコミットされるようにしたり、障害発生時にグローバルに強制終了されるようにするエージェントです。

  • GTX0-j: グローバル・トランザクション・プロセス

    GTX0-jプロセスは、Oracle RAC環境でXAグローバル・トランザクションを透過的にサポートします。これらのプロセスの数は、データベースによって、XAグローバル・トランザクションのワークロードに基づいて自動調整されます。

  • LMON: グローバル・エンキュー・サービス・モニター

    LMONプロセスでは、グローバル・エンキューおよびクラスタ全体のリソースが監視され、グローバル・エンキュー・リカバリ操作が実行されます。

  • LMD: グローバル・エンキュー・サービス・デーモン

    LMDプロセスでは、各インスタンス内の受信リモート・リソース要求が管理されます。

  • LMS: グローバル・キャッシュ・サービス・プロセス

    LMSプロセスでは、情報をグローバル・リソース・ディレクトリ(GRD)に記録することにより、データファイルのステータスおよび各キャッシュ・ブロックのレコードがメンテナンスされます。LMSプロセスでは、リモート・インスタンスへのメッセージ・フローの制御、グローバル・データ・ブロック・アクセスの管理、異なるインスタンスのバッファ・キャッシュ間のブロック・イメージの送信も行われます。この処理は、キャッシュ・フュージョン機能の一部です。

  • LCK0: インスタンス・エンキュー・プロセス

    LCK0プロセスでは、ライブラリや行キャッシュ要求などの非キャッシュ・フュージョン・リソース要求が管理されます。

  • RMSn: Oracle RAC管理プロセス(RMSn)

    RMSnプロセスでは、Oracle RACの管理性タスクが実行されます。RMSnプロセスによって実行されるタスクには、新規インスタンスがクラスタに追加された際のOracle RAC関連リソースの作成があります。

  • RSMN: リモート・スレーブ・モニターは、リモート・インスタンスでのバックグラウンド・スレーブ・プロセスの作成と通信を管理します。これらのバックグラウンド・スレーブ・プロセスでは、別のインスタンスで実行されている調整プロセスのためのタスクが実行されます。

注意:

この項で説明する多くのOracle Databaseコンポーネントは、『Oracle Database概要』で説明する非クラスタOracle Databaseの追加コンポーネントです

関連項目

1.6 動的データベース・サービスによる自動ワークロード管理の概要

サービスは、共通の属性、パフォーマンスしきい値および優先度を持つアプリケーションのグループを表します。

アプリケーション機能は、サービスによって識別されるワークロードに分割できます。たとえば、Oracle E-Business Suiteでは、総勘定元帳、売掛金勘定、受注など、職務ごとにサービスを定義できます。サービスはOracle Databaseの1つ以上のインスタンス、グローバル・クラスタ内の複数のデータベースにわたることができ、単一インスタンスで複数のサービスをサポートできます。サービスを提供するインスタンスの数は、アプリケーションに対して透過的です。サービスは、競合するアプリケーションを管理する単一のシステム・イメージを提供し、各ワークロードを1つの単位として管理できるようにします。

中間層アプリケーションおよびクライアントでは、サービス名をTNS接続文字列内の接続の一部として指定することで、サービスを選択します。たとえば、Oracle WebLogic Serverのデータ・ソースは、サービスにルーティングするように設定されます。Net Easy*Connectionを使用する場合、この接続は、user_name/password@SCAN/service_nameのように、サービス名とネットワーク・アドレスだけで構成されます。Oracle Scheduler、パラレル問合せ、Oracle Streamsキューなどのサーバー側の作業では、ワークロード定義の一部としてサービス名を設定します。Oracle Schedulerの場合、ジョブがジョブ・クラスに割り当てられ、サービス内で複数のジョブ・クラスを実行できます。パラレル問合せとパラレルDMLの場合、問合せコーディネータはサービスに接続し、パラレル問合せスレーブはパラレル実行中そのサービスを継承します。Oracle Streamsの場合、ストリーム・キューはサービスを使用してアクセスされます。サービス下で実行される作業は、そのサービスのしきい値および属性を継承し、サービスの一部として測定されます。

Oracle Database Resource Managerでは、サービスをコンシューマ・グループおよび優先度にバインドします。これによって、データベースはサービスをその重要性の順に管理できます。たとえば、DBAでは、優先度の高いオンライン・ユーザー向けと、優先度の低い内部レポート・アプリケーション向けのサービスを個別に定義できます。同様に、DBAでGold、SilverおよびBronzeのサービスを定義して、同じアプリケーションの要求に対してサービスを提供する順番に優先度を付けることができます。システムのサービスを計画する場合、その計画には、他のサービスに対する相対的な各サービスの優先度が含まれている必要があります。このようにして、Oracle Database Resource Managerは優先度が1位のサービス、次に優先度2位のサービス、というように対処できます。

ユーザーまたはアプリケーションがデータベースに接続するときは、接続文字列のCONNECT_DATA部分に指定されたサービスを使用することをお薦めします。Oracle Databaseでは、データベースが作成されると自動的に1つのデータベース・サービスが作成されますが、このサービスの動作は、その後自分で作成するデータベース・サービスの動作とは異なります。データベースを使用したワークロード管理の柔軟性を高めるために、Oracle Databaseでは、複数のサービスを作成し、どのインスタンス(またはサービス・プール)でサービスが起動されるかを指定できます。より柔軟なワークロード管理が必要な場合は、この章を読み進めると、サービスで使用できる追加機能を理解できます。

注意:

この章で説明する機能は、デフォルトのデータベース・サービス(DB_NAME、DB_UNIQUE_NAME、PDB_NAME、SYS$BACKGROUNDおよびSYS$USERS)では機能しません。これらのサービスを、データベースに接続するアプリケーションに使用しないことをお薦めします。このような機能を活用するには、クラスタ管理サービスを作成する必要があります。自分が作成したサービスのみ管理できます。データベースによって自動的に作成されたサービスはデータベース・サーバーによって管理されます。

動的データベース・サービス

動的データベース・サービスによってワークロードの分散を管理し、ユーザーおよびアプリケーションに対してパフォーマンスを最適化できます。動的データベース・サービスは、次の機能を提供します。

  • サービス: 企業のグリッド構想を可能にするために、Oracle Databaseでは、サービスと呼ばれる強力な自動ワークロード管理機能が導入されています。サービスは、Oracle RACデータベースで定義できるエンティティで、これを使用してデータベース・ワークロードをグループ化し、サービスの提供を割り当てられている最適なインスタンスに作業をルーティングし、計画済および計画外のアクションの高可用性を実現できます。

  • 高可用性フレームワーク: Oracle Databaseでコンポーネントを常に稼働状態に維持できるOracle RACコンポーネント。

  • 高速アプリケーション通知(FAN): インスタンス、サービスまたはノードのUPやDOWNイベントなどのクラスタ状態の変更およびロード・バランシング・アドバイザのイベントについての情報をOracle RACアプリケーションおよびクライアントに提供します。FANには、クライアントにイベントを発行する方法が2つあり、1つは、Oracle Notification Serviceデーモンで、Oracle Application Serverを含むJava Database Connectivity (JDBC)クライアントによって使用され、もう1つは、Oracle Streamsアドバンスト・キューイングで、以前のリリースのOracle Call Interface (OCI)およびOracle Data Provider for .NET (ODP.NET)クライアントによってのみ使用されます。

    注意:

    Oracle Database 12c リリース2 (12.2)からは、すべてのクライアントがOracle Notification Serviceを使用します。

  • トランザクション・ガード: 計画外停止および重複送信の場合に、トランザクションの実行を1回以下にするためのプロトコルおよびAPIを提供するツール。

  • アプリケーション・コンティニュイティ: リカバリ可能なエラーが発生した場合に、多くのシステム、通信、記憶域の停止およびハードウェア障害をマスクして、処理中の要求をリプレイする汎用インフラストラクチャを提供します。既存のリカバリ・テクノロジとは異なり、この機能では、アプリケーション下でトランザクションおよび非トランザクション・セッション状態をリカバリしようとするため、停止はアプリケーションにとって実行の遅延のように見えます。

  • コネクション・ロード・バランシング: 要求されたデータベース・サービスを提供するすべてのインスタンスで、受信する接続を均等に分散するOracle Net Servicesの機能。

  • ロード・バランシング・アドバイザ: データベースとそのインスタンスが提供する現在のサービス・レベルについてアプリケーションに情報を提供します。ロード・バランシング・アドバイザは、サービス用に定義した管理ポリシーに基づいて最適なサービスを得るために、アプリケーション・リクエストの宛先に関する推奨事項をアプリケーションに提供します。ロード・バランシング・アドバイザのイベントは、Oracle Notification Serviceを介してパブリッシュされます。

  • 自動ワークロード・リポジトリ(AWR): サービス・レベルの統計をメトリックとして追跡します。サーバーによって生成されるアラートは、特定のしきい値を超えたり、必要なしきい値に達しない場合、これらのメトリックに対して作成されます。

  • 高速接続フェイルオーバー(FCF): これは、FANイベントをサブスクライブすることによって、高速な接続のフェイルオーバーを提供する、Oracleクライアントの機能です。

  • ランタイム接続ロード・バランシング: アプリケーションが接続にいくつかの作業を完了するように要求すると、データベース・インスタンスによって提供されている現在のサービス・レベルに基づいて、接続プールで高度な接続の割当てを行うOracleクライアントの機能です。

  • 単一クライアント・アクセス名(SCAN): Oracle RACに接続しているクライアントに単一の名前を提供し、この名前は、クラスタのノードを追加または削除しても、クラスタの存続期間中は変更されません。SCANに接続しているクライアントでは、Thin JDBC URLやEZConnectなどの単一の接続文字列を使用でき、ロード・バランシングおよびクライアントの接続フェイルオーバーが実現されます。

Oracle RACおよび非クラスタOracle Database環境をデプロイして、多くの異なる方法で動的データベース・サービス機能を使用できます。ノード数および使用環境の使用目的と複雑さによって異なりますが、最適な自動ワークロード管理および高可用性構成は、この章で説明する考慮事項を検討して決定してください。

関連項目

1.7 サーバー・プールおよびポリシー管理データベースの概要

サーバー・プールは、ポリシー管理データベースの基盤です。

次のデプロイメント・モデルを使用すると、マルチノードであれ、Oracle Real Application Clusters One Node (Oracle RAC One Node)であれ、Oracle RACデータベースを作成できます。

  • 管理者管理デプロイメントは、Oracle Database 11gリリース2 (11.2)の前に存在していたOracle RACデプロイメント・タイプに基づき、クラスタ内の特定のノードで実行されるように各データベース・インスタンスを静的に構成する必要があり、また、preferredおよびavailable宛先を使用して、特定のデータベースに属する特定のインスタンスで実行されるようにデータベース・サービスを構成する必要があります。

  • ポリシー管理デプロイメントは、サーバー・プールに基づき、この場合、データベース・サービスは、サーバー・プール内でシングルトンまたは均一として、サーバー・プール内のすべてのサーバーにわたって実行されます。データベースは1つ以上のサーバー・プールにデプロイされ、サーバー・プールのサイズによってデプロイメント内のデータベース・インスタンスの数が決まります。

関連項目

1.7.1 サーバー・プールの概要

サーバー・プールは、データベース・サービスまたはアプリケーション・サービスを提供するサーバーのグループにクラスタを論理的に割り当てます。

サーバー・プールのプロパティは、これらのデータベースおよびアプリケーションのスケーラビリティおよび可用性を制御します。各サーバー・プールは最小サイズおよび最大サイズを使用して構成でき、これによって、スケーラビリティが決まります。Oracle Clusterwareは、サーバー・プール間の可用性を管理し、個々のサーバー・プールの重要度の値を構成することによって可用性をさらに調整できます。

サーバーは名前によってサーバー・プールに割り当てられるのではなく、番号によって割り当てられます。したがって、任意のデータベースを実行するように任意のサーバーを構成する必要があります。たとえば、異機種サーバーやストレージ接続のためにサーバーを構成できない場合は、サーバー・カテゴリ定義を使用してサーバー・プールのメンバーシップ適格性を判別することによってサーバーを制限できます。

関連項目

1.7.1.1 サーバー・プールの使用例

この項では、次のサーバー・プールの使用例を示します。

サーバーの最小数および最大数

onlineとbackofficeという2つのサーバー・プールに4ノード・クラスタが構成されているとします。onlineサーバー・プールではdbsalesというデータベースが実行され、browse、searchおよびsalescartサービスを提供しています。backofficeサーバー・プールではdberpというデータベースが実行され、図1-2に示すとおり、inventoryおよびshippingサービスを提供しています。通常の営業時間中、企業は通常の要求に対応するために、dbsalesデータベースの最低2つのインスタンスと、dberpデータベースの1つのインスタンスを必要とします。

図1-2 最小数および最大数によるサーバーの配置

図1-2の説明が続きます。
「図1-2 最小数および最大数によるサーバーの配置」の説明

このポリシー管理デプロイメントでは、onlineサーバー・プールのMIN_SIZEサーバー・プール属性の値は2で、backofficeサーバー・プールのMIN_SIZEサーバー・プール属性の値は1です。このように構成されたOracle Clusterwareでは、常にonlineサーバー・プールに2つのサーバーがあり、backofficeサーバー・プールに1つのサーバーがあります。これは4ノード・クラスタであるため、いずれのサーバー・プールにも割り当てられていないサーバーが1つ残ります。最後のサーバーがデプロイされる場所は、各サーバー・プールのMAX_SIZEサーバー・プール・パラメータによって決まります。各サーバー・プールのMAX_SIZEサーバー・プール属性の値の合計がクラスタ内のサーバーの総数より小さい場合、残りのサーバーは、デプロイされたノードの障害を待つ空きサーバー・プールにとどまります。

MAX_SIZEの値がMIN_SIZEの値より大きい場合、図1-2で示すとおり、また、次の項で詳細に説明するとおり、残りのサーバーは、重要度の値が最大のサーバー・プールにデプロイされます。この場合、サーバーは、サーバーが必要とされるサーバー・プールを結合するためにオンラインで再配置できる共有可能なリソースになります。たとえば、営業時間中は、サーバーをonlineサーバー・プールに与えて、dbsalesデータベースのインスタンスを追加できますが、営業時間後は、backofficeサーバー・プールに再配置して、dberpデータベース・インスタンスを追加できます。このような動作はすべてオンラインであり、インスタンスはトランザクション的に停止されます。

これらの2つのポリシー管理データベースは、必要とされるインスタンスのみを実行し、要求またはビジネス要件を満たすように動的に増減できます。

サーバー・プールのIMPORTANCE属性

IMPORTANCEサーバー・プール属性は、クラスタの起動時、およびノードの障害または削除に応じて使用されます。管理者管理データベースとは対照的に、最初に起動するデータベースを決めるように、また、マルチノードの停止時にオンラインのままにしておくデータベースを決めるように、様々な重要度でサーバー・プールを構成できます。

salesおよびbackofficeという2つのサーバー・プール内で、dbappsというデータベースをホストする4ノード・クラスタを考えてみます。図1-3に示すとおり、2つのサービスorderentryおよびbillingは、salesサーバー・プールで実行され、他の2つのサービスerpおよびreportsは、backofficeサーバー・プールで実行されます。backofficeサーバー・プールの値より大きいsalesサーバー・プールのIMPORTANCEサーバー・プール属性の値を構成することによって、マルチノードの障害の後に残って実行されているサーバーが1つのみでも、クラスタが起動すると、salesのサービスは最初に起動して常に使用可能になります。IMPORTANCEサーバー・プール属性を使用すると、サービスをランク付けすることができ、常に使用可能にするためにクラスタ内のすべてのノードでサービスを実行する必要もなくなります。

図1-3 サーバー・プールの重要度

図1-3の説明が続きます
「図1-3 サーバー・プールの重要度」の説明

データベースの統合

いくつかの様々なアプローチを個別にまたは組み合せて使用すると、Oracle Databasesを統合できます。ポリシー管理デプロイメントでは統合は容易です。スキーマ統合の場合、複数のアプリケーションは、個別スキーマまたはプラガブル・データベース(PDB)に分離された単一データベースによってホストされているため、サーバー・プールを使用して必要な容量を満たすことができます。サーバー・プールの動的スケーリング・プロパティのため、現在の要求またはビジネス要件に合うようにデータベース・インスタンスの数を増減できます。サーバー・プールによって、一緒にまたは別個に実行されるサービスも決定されるため、必要なアフィニティまたは分離を構成および維持できます。

たとえば、バージョン要件のためにスキーマ統合を使用できない場合、単一セットのサーバー上で複数のデータベースをホストできます。ポリシー管理データベースを使用すると、ポリシー管理データベースはインスタンス・ケージングを利用することによって同じサーバー・プールを共有できるため、このデータベース統合が容易になります。これにより、要求またはビジネス・ポリシーとスケジュールに合うように、水平方向(サーバー・プール・サイズを使用)と垂直方向(CPU_COUNTサーバー構成属性を使用)の両方にデータベースを動的に増減できます。

対照的に、管理者管理データベースでは、データベース・インスタンスまたはサーバーに障害が発生した場合、ワークロードのフェイルオーバーを吸収するために各サーバーに容量を確保する必要があります。ただし、ポリシー管理データベースの場合、MIN_SIZE、MAX_SIZEおよびIMPORTANCEサーバー・プール属性を使用して、実行中のワークロードのビジネスの必要性別にサーバー・プールを効果的にランク付けできます。

サーバーの障害によってサーバー・プールがサーバーの構成済最小数を下回ると、重要性の少ないサーバー・プールからの別のサーバーがそのかわりにるため、サーバーの数は構成済最小数に戻ります。これにより、残りのサーバーのオーバーロードによるカスケード障害のリスクがなくなり、処理障害のために容量を確保する必要性を大幅に減らしたり、その必要性をなくすことさえできます。

ポリシー管理データベースに移行または変換すると、クラスタの統合も可能になり、より大きなクラスタを作成することで、データベースのホストおよび拡張に使用可能なサーバー数が増加するため可用性およびスケーラビリティの向上が実現されます。ポリシー管理データベースでは、インスタンス名を特定のサーバーにバインディングすること、およびサービスを特定のインスタンスにバインディングすることが不要なため、大きなクラスタを構成および管理する際の複雑さが大幅に軽減されます。

図1-4に、デプロイメント例を示します。ここでは、前の2つのクラスタ例(図1-2および図1-3)は、単一クラスタに統合され、構成されたデータベース統合(インスタンス・ケージングを使用)とクラスタ統合(サーバー・プールを使用)の両方を利用して、ワークロードのサイズ設定および優先度付けが適切に行われるようにします。

図1-4 データベースの統合

図1-4の説明が続きます
「図1-4 データベースの統合」の説明

1.7.2 ポリシー管理データベースのデプロイ

ポリシー管理データベースをデプロイする場合、サービスはサーバー・プールにわたらないことを考慮に入れて、まずサービスとその必要なサイズ設定を決定する必要があります。

このデータベースを他のデータベースと同じ場所に配置する場合、ホストされている他のデータベースに関するCPU要件を考慮する必要があり、インスタンス・ケージングのCPU_COUNT属性の値も考慮する必要があります。これにより、1つ以上のサーバー・プールで垂直方向と水平方向の両方にデータベースのサイズを指定できます。

このデータベースのサーバー・プールを他のサーバー・プールと同じ場所に配置する場合、会議の要求およびビジネス要件を最適化するためにカレンダまたはイベントに基づいてサーバー・プール・サイズを調整するようにサーバー・プールを構成することを検討します。サーバー・プールのサイズを決定し、MIN_SIZEおよびMAX_SIZEサーバー・プール属性の適切な値を構成したら、各サーバー・プールの相対的な重要度を決定できます。

クラスタ管理者として、srvctl add serverpoolコマンドを使用してポリシー管理データベース・サーバー・プールを作成します。Oracle Grid Infrastructureホームで、srvctl modify serverpoolコマンドを使用すると、サーバー・プールのプロパティを変更できます。

DBCAを使用してサーバー・プールを作成できる間は、小さい単一サーバー・プールのデプロイメント用のもののみをお薦めします。サーバーがすでに他のサーバー・プールに割り当てられている場合、DBCAに障害が発生するためです。また、クラスタが、古いサーバーや新しいサーバーなど、異なる容量のサーバーで構成されている場合、各サーバー・プールを結合するためのサーバーの最小サーバー要件を定義するサーバー・カテゴリ定義を設定することをお薦めします。

サーバー・プールの作成後、適切なデータベース・ホームからDBCAを実行できます。データベースのタイプおよびタスクに応じて、様々なデフォルト・オプションが提示されます。コンテナ・データベース(CDB)を含め、すべての新しいOracle RACおよびOracle RAC One Nodeデータベースの場合、ポリシー管理オプションはデフォルトで、これがお薦めするオプションです。

管理者管理データベースから、またはOracle Database 11gリリース2 (11.2)より前のデータベースからデータベースをアップグレードする場合、ポリシー管理データベースに直接アップグレードするオプションはありません。ただし、アップグレード後、srvctl modify databaseコマンドを使用して、データベースをポリシー管理に変換できます。

管理者管理データベースからポリシー管理データベースに変換する場合、インスタンス名は、アンダースコアを含むように自動的に更新されます(例: orcl1はorcl_1になります)。サーバー・プールのサイズが大きくなるときデータベースが自動的にインスタンスを作成できるようにするためには、アンダースコアが必要です。

関連項目

1.7.3 ポリシー管理データベースの管理

ポリシー管理データベースの管理では、作成、サイズ設定、パッチ適用およびロード・バランシングに関して、管理者管理データベースより構成および再構成の手順が少なくて済みます。

また、クラスタ内のサーバー・プールのサーバーはどのデータベースでも実行できるため、データベース・インスタンスとノード名のマッピングを作成して維持する必要はありません。ただし、データベースが特定のノードで実行するときには必ず特定のインスタンス名を使用するようにする場合は、srvctl modify instance -db db_unique_name -instance inst_name -node node_nameコマンドを使用して、インスタンスからノード名へのマッピングを作成できます。これは、特定のノードのスクリプトで固定のORACLE_SID値を使用してデータベースに接続する場合に役立ちます。

サーバーを空きプールに再配置することによって、またはサーバー・プールの最小サイズと最大サイズを調整することによって、パッチ適用などのメンテナンス・タスクを実行できるため、必要な可用性が維持されます。

ポリシー管理データベースでは、サービスの管理も容易になります。ポリシー管理データベースは、単一サーバー・プールに割り当てられ、プール内のすべてのサーバーにわたってシングルトンまたは均一として実行されるためです。サービスごとに明示的に優先かつ使用可能なデータベース・インスタンス・リストを作成または維持する必要はなくなりました。手動による再配置または高可用性イベントのためサーバーをサーバー・プールに移動すると、統一されたすべてのサービスおよびその依存データベース・インスタンスは自動的に起動します。1つ以上のシングルトン・サービスをホストしているサーバーがダウンした場合、これらのサービスは、サーバー・プール内の残りの1つ以上のサーバーで自動的に起動します。Oracle RAC One Nodeの場合、対応するデータベース・インスタンスも自動的に起動します。

相互に関連するサービスの管理は、各サーバー・プールの重要度属性を利用することによって向上します。サーバー・プールで実行される各サービスは、クラスタ内で他のサーバー・プールにホストされているサービスに関連するサーバー・プールの重要度を継承します。最も重要なサーバー・プールの最小サイズが0(ゼロ)より大きい場合、このサーバー・プール内のサービスおよび関連のデータベース・インスタンスは、クラスタの起動時に最初に起動し、クラスタ内に1つのサーバーが実行されているかぎり、実行されている最後のサービスおよびデータベース・インスタンスになります。重要でないサービスは最も重要でないサーバー・プールのビジネスに提供でき、要求または障害のために十分なリソースが使用できない場合、これらのサービスは最終的に停止され、よりビジネスクリティカルなサービスが使用可能なまま存続するようにできます。

数多くの管理タスクは、統合環境内の複数のデータベース、サービスまたはサーバー・プールに影響を与える可能性のある変更を伴うことがあるため、特定のSRVCTLコマンドの評価モードを使用して、コマンドのリソース影響のレポートを取得できます。

サーバー・プールを変更するシステムに対する影響を評価する次の例を考えてください。

$ srvctl modify srvpool -l 3 -g online -eval

Service erp1 will be stopped on node test3
Service reports will be stopped on node test3
Service inventory will be stopped on node test3
Service shipping will be stopped on node test3
Database dbsales will be started on node test3
Service orderentry will be started on node test3
Service billing will be started on node test3
Service browse will be started on node test3
Service search will be started on node test3
Service salescart will be started on node test3
Server test3 will be moved from pool backoffice to pool online

前述の例に示すとおり、サーバー・プールを変更すると、数多くのリソース状態の変更を招くことがあります。Oracle ClusterwareまたはOracle Database Quality of Service Managementを介してポリシー・セットを使用できます。

関連項目

1.7.4 ポリシーベースのクラスタ管理

Oracle Clusterwareでは、ネイティブなOracle Clusterware機能としてクラスタ構成ポリシー・セットの管理をサポートします。

クラスタ構成ポリシーには、システム内で定義された、サーバー・プールごとに1つの定義が含まれます。また、クラスタ構成ポリシーでは、リソース配置およびクラスタ・ノードの可用性についても指定します。クラスタ構成ポリシー・セットでは、クラスタ内に構成されるすべてのサーバー・プール名が定義され、1つ以上の構成ポリシーが含まれます。

一度に1つの構成ポリシーのみが常に有効になります。ただし、管理者は通常、カレンダ日付または時間パラメータに基づいて様々なビジネス・ニーズおよび要求を反映させるために、いくつかの構成ポリシーを作成します。たとえば、一般的に、就業日の午前中は多くのユーザーがログインし、電子メールをダウンロードしますが、夜間や週末は電子メール関連のワークロードが通常は少なくなります。このような場合、クラスタ構成ポリシーを使用して、予想される需要に基づいてサーバー割当てを定義します。より具体的には、この例の場合、より多くのサーバーをOLTPワークロードに割り当てる構成ポリシーを就業日の午前中に有効にし、週末および就業日の夜には、別の構成ポリシーで、より多くのサーバーをバッチ・ワークロードに割り当てます。

クラスタ構成ポリシーを使用すると、様々なコンピュータやメモリー・サイズ(異機種)など、様々な機能のサーバーを構成するクラスタの管理に役立てることもできます。異機種サーバー・タイプで構成されるクラスタ用に管理および可用性ポリシーを作成するために、クラスタ管理者は、サーバー属性に基づいてサーバー・カテゴリを作成できます。これらの属性によって、どのサーバーをどのサーバー・プールに割り当てることができるかを制限できます。たとえば、古いハードウェアを実行するサーバーがクラスタ内に存在する場合に、それらのサーバーを、オンライン販売やその他の業務上重要なアプリケーションに使用されるサーバー・プールではなく、バッチ・ジョブやテストをサポートするサーバー・プールにのみ割り当てるように指定する属性を使用できます。

関連項目

1.8 Oracle Database Quality of Service Managementの概要

Oracle Database Quality of Service Management (Oracle Database QoS Management)は、システム全体のワークロード・リクエストを監視する自動化されたポリシーベースの製品です。

Oracle Database QoS Managementは、アプリケーション間で共有されるリソースを管理し、システム構成を調整して、アプリケーションの実行をビジネスに必要なパフォーマンス・レベルに維持します。Oracle Database QoS Managementは、システム構成および要求で発生した変更に対応し、アプリケーションのパフォーマンス・レベルがそれ以上変動することを回避します。

Oracle Database QoS Managementは、Oracle RACデータベースのワークロード・パフォーマンスの目標を監視および管理します。そのために、この目標に影響を与えているボトルネック・リソースを特定し、パフォーマンスをリストアするためのアクション推奨して実施します。管理者管理デプロイメントでは、データベース・インスタンスをノードにバインドしますが、ポリシー管理デプロイメントでは、このようなバインドは実施しません。そのため、Oracle Database QoS Managementサーバー・プール・サイズのリソース制御は後者でのみ使用できます。その他すべてのリソース管理制御は、どちらのデプロイメントでも使用できます。

Oracle Database QoS Managementは、測定のみ、モニター、および管理の各モードによって、管理者管理Oracle RACデータベースとOracle RAC One Nodeデータベースをサポートします。これにより、データベースで実行中のパフォーマンス・クラスのCPU共有を調整することで、管理者管理Oracle RACデータベース内でのスキーマ統合のサポートが可能になります。さらに、同じ物理サーバーでホストされているデータベースのCPU数を調整することで、データベース統合がサポートされています。

管理者管理データベースはサーバー・プールで実行しないため、サーバー・プール・サイズを変更することでインスタンスの数を増減する機能は、ポリシー管理データベースのデプロイメントでサポートではサポートされていますが、管理者管理データベースでは利用できません。この新しいデプロイメントのサポートは、Oracle Enterprise Manager Cloud ControlのOracle QoS管理のページに統合されています。

関連項目

1.9 ハング・マネージャの概要

ハング・マネージャは、システムのハングアップを自動的に検出して解決するOracle Databaseの機能です。

ハング・マネージャは、Oracle Database 11g リリース1 (11.1)で初めて使用できるようになりました。当初は、システムのハングを識別して、ハングについての関連情報をトレース・ファイルにダンプしていました。Oracle Database 12c リリース2 (12.2)では、ハング・マネージャはシステム・ハングに対処できるようになり、その解決を試行します。ハング・マネージャは、単一インスタンスとOracle RACデータベース・インスタンスのどちらでも実行します。

注意:

ハング・マネージャは、デッドロックを解決しません。デッドロックの検出は、いくつか前のリリースのOracle Databaseから使用できます。

ハング・マネージャの機能は、次のとおりです。

  • 最初にシステム・ハングを検出し、そのハングを分析してから、ハングの原因を確認します。その後、ハングを解決するための対処方針を決定するためにヒューリスティックを適用します。

  • My Oracle Supportにトレース・ファイルを提出してハングの原因の特定を依頼するために、DBAによる手動の手順が必要だったタスクを自動化し、データベースとアプリケーションのダウンタイムを最小化または排除します。

  • すべてのプロセスを定期的にスキャンして、連続するスキャンでリソースを保持しているプロセスの小さなサブセットを分析します。ハング・マネージャは、リソースを待機しているものがない場合はプロセスを無視します。

  • インスタンス間のハング(Oracle ASMインスタンスからの応答を待機しているデータベース・プロセスがホルダーの場合のハング)を考慮します。

  • リーダー・ノード・インスタンスで実行しているプロセスを認識して、それらのプロセスのいずれかがハブ・ノードの進行をブロックしているかどうかをチェックして、可能な場合は処置を実施します。

  • ホルダーのOracle Database Quality of Service Management設定を考慮します。

  • ホルダー・プロセスを終了して、そのリソースを待機している次のプロセスの進行を可能にしてハングを防止します。

  • アラート・ログのORA-32701エラー・メッセージでDBAに通知します。

関連項目:

Oracle Autonomous Health Frameworkユーザーズ・ガイド

1.10 Oracle RACを含むOracle Multitenantの概要

Oracle MultitenantはOracle Database 12cのオプションで、統合、プロビジョニング、アップグレードなどを簡略化します。

これは、マルチテナント・コンテナ・データベース(CDB)に複数のプラガブル・データベース(PDB)を保持することができるアーキテクチャに基づいています。アプリケーション層を変更することなく、既存のデータベースをPDBとして採用できます。このアーキテクチャでは、1つのシステム上で様々なビジネスで重要なアプリケーションを統合するときに必要なローカルの高可用性を、Oracle RACが提供します。

Oracle RACでPDBを使用する場合、マルチテナントCDBはOracle RACに基づきます。各PDBをOracle RAC CDBの各インスタンスまたはインスタンスのサブセットで使用可能にすることができます。いずれの場合も、PDBへのアクセスおよび管理は、動的データベース・サービスを使用して調整されます。これは接続にOracle Net Servicesを使用する1つのインスタンスOracleデータベース内なので、アプリケーションにより使用されて各PDBに接続することもあります。

同じOracle RACデータベースまたはデータベース・インスタンスを共有している別のPDBを妨害する可能性のある、特定のPDBでの特定の操作が実行されないようにするために、PDBを分離できます。PDBの分離により、Oracle Multitenantを使用した高度な統合が可能になります。

Oracle RACデータベースをCDBとして作成し、そのCDBに1つ以上のPDBを接続する場合、Oracle RACのCDBのどのインスタンスでもPDBはデフォルトで自動起動されません。PDBに(データベース名と同じ名前のデフォルトのデータベース・サービス以外の)最初の動的なデータベース・サービスが割り当てられると、PDBはサービスが実行されるインスタンスで有効になります。

Oracle RACの1つ以上のインスタンスでPDBが有効かどうかにかかわらず、CDBは通常、PDBで実行されるサービスで管理されます。インスタンス上でPDBを手動で起動することによって、Oracle RAC CDBの各インスタンス上でPDBアクセスを手動で有効化できます。

1.11 Database In-MemoryおよびOracle RACの概要

Oracle RAC環境内の各ノードには、固有のインメモリー(IM)列格納があります。デフォルトでは、移入オブジェクトはクラスタ内のすべてのIM列ストアにわたって分散されます。

Oracle RAC環境内の各ノードには、固有のインメモリー(IM)列格納があります。各Oracle RACノードのIM列格納は同じサイズにすることをお薦めします。IM列格納を必要としないOracle RACノードの場合、INMEMORY_SIZEパラメータを0に設定します。

完全に異なるオブジェクトを各ノードに移入させたり、より大きなオブジェクトをクラスタ内のすべてのIM列格納間で分散させることが可能です。同じオブジェクトを各ノード(エンジニアド・システム上のみ)のIM列格納に表示させることも可能です。クラスタ内のIM列格納間のオブジェクトの分散は、INMEMORY属性への2つの追加の副句(DISTRIBUTEおよびDUPLICATE)により制御されます。

Oracle RAC環境では、指定されたINMEMORY属性のみを含むオブジェクトが、クラスタ内のIM列格納間で自動的に分散されます。DISTRIBUTE句を使用して、クラスタ間でのオブジェクトの分散方法を指定することができます。デフォルトで、使用されるパーティション化のタイプ(ある場合)によりオブジェクトの分散方法が決定されます。オブジェクトがパーティション化されないと、ROWID範囲に分散されます。あるいは、DISTRIBUTE句を指定して、デフォルトの動作をオーバーライドすることができます。

エンジニアド・システムでは、クラスタ内のIM列格納間でメモリーに移入されたオブジェクトを複製またはミラー化することができます。これにより最高レベルの冗長性が提供されます。DUPLICATE句を使用して、クラスタ内のIM列格納間でのオブジェクトの複製方法を制御することができます。DUPLICATEを指定する場合、データのミラー化されたコピーが1つ、クラスタ内のIM列格納間で分散されます。クラスタ内の各IM列格納内のすべてのオブジェクトを複製する場合は、DUPLICATE ALLを指定します。

注意:

非エンジニアド・システムでOracle RACにデプロイする場合、DUPLICATE句はNO DUPLICATEとして扱われます。

関連項目

1.12 Oracle RAC環境の管理の概要

この項では、Oracle RAC環境の管理について説明します。内容は次のとおりです。

1.12.1 Oracle RAC環境の設計およびデプロイ

Oracle RACによる高可用性計画を設計および実装しているすべての企業は、高可用性を必要とするビジネス要因を綿密に分析することから始める必要があります。

高可用性を実現するためのビジネス要件を分析し、様々な高可用性ソリューションの実装に必要な投資レベルについて理解しておくことによって、ビジネスと技術の両方の目的を達成する高可用性アーキテクチャの開発が可能になります。

関連項目

関連項目:

可用性の要件に最適なアーキテクチャを選択および実装するには、次の情報が役立ちます。

  • 「設計およびデプロイ方法」では、ビジネスの高可用性要件を評価する場合に使用できる高水準の概要を示しています。

  • 『Oracle Database高可用性概要』では、組織に最適なアーキテクチャを選択する方法および複数の高可用性アーキテクチャについて説明し、要件を満たす最適なアーキテクチャを選択するためのガイドラインを示し、Oracle Maximum Availability Architectureの情報も示します

1.12.2 Oracle RAC環境の管理ツール

管理者は、サーバー制御ユーティリティ(SRVCTL)、Oracle Enterprise Manager、SQL*Plus、およびその他のユーティリティを使用して、クラスタ・データベースを単一システム・イメージとして管理します。

  • サーバー制御ユーティリティ(SRVCTL): シングル・ポイントからOracle RACデータベースを管理するためのコマンドライン・インタフェース。SRVCTLを使用して、データベースおよびインスタンスの起動と停止、インスタンスおよびサービスの削除または移動を実行できます。SRVCTLを使用して、構成情報、Oracle Real Application Clusters One Node(Oracle RAC One Node)Oracle ClusterwareおよびOracle ASMの管理もできます。

  • 高速ホーム・プロビジョニング: 高速ホーム・プロビジョニングは、Oracle RACデータベースのパッチ適用、アップグレード、およびプロビジョニングに使用します。

  • Oracle Enterprise Manager: 非クラスタ・データベースおよびOracle RACデータベース環境を管理するOracle Enterprise Manager Cloud Control GUIインタフェース。可能な場合は、Oracle Enterprise Managerを使用して管理タスクを実行することをお薦めします。

    Oracle Enterprise Manager Cloud Controlを使用して、Oracle RAC One Nodeデータベースを管理することもできます。

  • SQL*Plus: SQL*Plusコマンドは、現行のインスタンスで動作します。現行のインスタンスは、SQL*Plusセッションを開始したローカルのデフォルト・インスタンスまたはOracle Net Servicesの接続先リモート・インスタンスです。

  • クラスタ検証ユーティリティ(CVU): クラスタとOracle RACの様々なコンポーネント(共有ストレージ・デバイスなど)、ネットワーク構成、システム要件、Oracle Clusterware、およびオペレーティング・システムのグループやユーザーの検証に使用するコマンドライン・ツール。インストール前およびインストール後のクラスタ環境のチェックにもCVUを使用できます。CVUは、Oracle ClusterwareおよびOracle RACコンポーネントのインストール前およびインストール時に特に役立ちます。Oracle ClusterwareおよびOracle Databaseのインストール後に、CVUを実行して環境を検証します。

    Oracle RACをインストールする前にCVUをインストールして、構成がOracle RACのインストールの最小要件を満たしていることを確認します。また、CVUを使用して、ノードの追加や削除などの管理タスクの完了を検証できます。

  • DBCA: Oracle RAC、Oracle RAC One NodeおよびOracleの非クラスタ・データベースを作成し、最初に構成する場合の推奨ユーティリティ。

  • NETCA: Oracle RAC環境のネットワークを構成します。

関連項目

関連項目:

  • SRVCTL、Oracle Enterprise ManagerおよびSQL*Plusを使用したOracle RAC管理の概要は、「データベース・インスタンスおよびクラスタ・データベースの管理」を参照してください

  • 「Oracle RACおよびOracle Clusterwareの監視」

  • SRVCTLの参照情報については、「サーバー制御ユーティリティのリファレンス」を参照してください

  • クラスタ検証ユーティリティ(CVU)、およびOIFCFGツール(ネットワーク・インタフェースの割当てと割当て解除)やOCRCONFIGコマンドライン・ツール(OCRの管理)などのその他のOracle Clusterwareツールの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

  • NETCAの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

1.12.3 Oracle RAC環境の監視

WebベースのOracle Enterprise Manager Cloud Controlを使用すると、Oracle RACデータベースを監視できます。

Oracle Enterprise Manager Cloud Controlは、グラフィカル・ユーザー・インタフェース(GUI)を介してアクセスするOracle環境を集中的に制御します。Oracle Enterprise Managerを使用したOracle RAC環境の監視の詳細は、「Oracle RACおよびOracle Clusterwareの監視」および『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

Oracle RAC環境を監視する場合の推奨事項は次のとおりです。

  • Oracle Enterprise Manager Cloud Controlを使用して、クラスタ・データベース管理タスクを開始します。

  • Oracle Enterprise Manager Cloud Controlを使用して、複数または個々のOracle RACデータベースを管理します。

  • V$ビューに基づいたグローバル・ビュー(GV$ビュー)を使用します。GV$ビューは、catclustdb.sqlスクリプトによって作成されます。データベースの作成にDBCAを使用しない場合は、このスクリプトを実行します。それ以外の場合は、DBCAによってこのスクリプトが実行されます。

    ほとんどのV$ビューに対して、対応するGV$グローバル・ビューが存在します。V$情報に加えて、各GV$ビューにはINST_IDという名前の追加の列があり、ここにインスタンス番号が表示され、この番号に基づいて関連するV$ビュー情報が取得されます。

  • Automatic Database Diagnostic Monitor (ADDM)および自動ワークロード・リポジトリ(AWR)を含む、Oracle Enterprise ManagerのOracle Database Diagnostic and Tuningパックの高度な管理および監視機能を使用します。

    注意:

    Statspackは下位互換性に使用できますが、Statspackで実行できるのはレポートのみです。ブロック競合およびセグメント・ブロックの待機に関連する統計を収集するには、Statspackをレベル7で実行する必要があります。

関連項目

関連項目:

ADDMなど、パフォーマンスの診断およびチューニング用のOracle Databaseの自動機能の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

1.12.4 Oracle RAC環境でのパフォーマンス評価

Oracle RACに対して特別なチューニングは必要ありません。Oracle RACは特別な構成変更がなくてもスケーラビリティが向上します。アプリケーションが非クラスタOracle RACデータベースで正常に動作する場合は、Oracle RAC環境でも正常に動作します。非クラスタOracle Databaseで実行する多くのチューニング・タスクによって、Oracle RACデータベースのパフォーマンスも向上できます。これは、より多くのCPUをまたいだスケーラビリティが必要な環境にとって特に当てはまることです。

Oracle RAC固有のパフォーマンス機能には、次のものがあります。

  • 動的リソース割当て

    • 必要に応じて、キャッシュ・フュージョン・リソースが動的に割り当てられます。

    • リソースを動的にマスター化すると、リソースをデータ・ブロックに対してローカルなままに保持できるため、パフォーマンスが向上します。

  • キャッシュ・フュージョンによる簡素化されたチューニング方法

    • キャッシュ・フュージョン用にパラメータをチューニングする必要はありません。

    • アプリケーション・レベルのチューニングは必要ありません。

    • 既存のアプリケーションに対してほとんど影響を及ぼすことなく、ボトムアップ・チューニングを実行できます。

  • 詳細なパフォーマンス統計

    • Oracle RACパフォーマンスを監視するために様々なビューを使用できます。

    • Oracle Enterprise ManagerのOracle RAC固有のパフォーマンス・ビュー


脚注の凡例

脚注1:

Oracle Database 10gリリース2 (10.2)以上の場合、Oracle Clusterwareは、Oracle Clusterware標準クラスタ内で100のノードをサポートし、これらのノード上の1つの本番データベースに属する100のデータベース・インスタンスを実行するオプションを備えています。