| Oracle® Real Application Clustersインストレーション・ガイド 12c リリース1 (12.1) for Linux and UNIX Systems B71325-07 |
|
 前 |
 次 |
| Oracle® Real Application Clustersインストレーション・ガイド 12c リリース1 (12.1) for Linux and UNIX Systems B71325-07 |
|
前 |
次 |
この章では、Oracle Real Application Clusters(Oracle RAC)用にインストールされた構成について説明します。この章の内容は次のとおりです。
Oracle Net Configuration Assistant(NetCA)およびDatabase Configuration Assistant(DBCA)は、Oracle RACデータベースの作成およびOracle Enterprise Manager検出に必要な要件を満たすように環境を構成します。
|
注意: 構成ファイルは、クラスタ・データベースの各ノードに作成されます。 |
Oracle RACのインストールの完了後は、ホスト名を変更しないようにしてください(ドメイン修飾の追加または削除を含む)。ノード名はOracle Clusterwareのインストール中にホスト名から作成され、データベース・プロセスで広範に使用されます。ホスト名が変更されているノードは、クラスタから削除して新しいホスト名で追加しなおす必要があります。
管理者は、多くの場合、データベースの停止または起動、記憶域の構成などの特別な操作を実行します。これらの管理決定を担当する一人の管理者のみがこれらの操作を実行する必要があるため、Oracle DatabaseまたはOracle Automatic Storage Management (ASM)管理のシステム権限には、セキュアな認証スキームが必要です。
特別なオペレーティング・システム・グループのメンバーシップを使用すると、管理者は、ユーザー名とパスワードを使用するのではなく、オペレーティング・システムを通してOracle DatabaseまたはOracle ASMを認証できます。このことはオペレーティング・システム認証と呼ばれます。クラスタ内のOracle Databaseはそれぞれが独自のオペレーティング・システム権限グループを持つことができるため、オペレーティング・システム認証は、クラスタ上のOracle Databaseごとに分離できます。クラスタ上に配置できるOracle Grid Infrastructureインストールは1つだけであるため、Oracle ASM用のオペレーティング・システム権限グループのセットは1つしか存在できません。
Oracle Grid InfrastructureとOracle Databaseのインストール中に、オペレーティング・システムのグループのグループ名を入力します。これらのオペレーティング・システム・グループには、Oracle DatabaseおよびOracle ASMに対して、管理システム権限のオペレーティング・システム・グループ認証を付与する論理ロールが指定されます。
Oracle RACクラスタでは、システム権限グループのグループID番号(GID)は、各クラスタ・メンバー・ノード上で同一である必要があります。1つのオペレーティング・システム・グループを論理グループ(メンバーにOracle DatabaseおよびOracle ASMのすべてのシステム権限(インストール所有者のOINSTALLシステム権限を含む)が付与されている)に指定できます。また、2つ以上の実際のオペレーティング・システム・グループに論理システム権限を委任できます。論理システム権限ごとに、異なるオペレーティング・システム・グループを作成することをお薦めします。これにより、データベース管理者に1つ以上の管理者システム権限のサブセットを付与できるようになります。これらのデータベース管理者は、その後、SYSDBAシステム権限なしで標準のデータベース管理タスクを実行できるようになります。
表7-1にシステム権限グループをリストします。
表7-1 ロールが割り当てられたOracleシステム権限のオペレーティング・システム・グループ
| 論理オペレーティング・システム・グループ名 | デフォルトの実際のUNIXまたはLinuxグループ名 | グループ･メンバーシップにより認証されるシステム権限 |
|---|---|---|
|
OINSTALL |
|
各サーバーの中央oraInventoryディレクトリに対する書込み権限、およびOracleバイナリのインストール所有者ユーザーに付与されるその他の権限を含む、インストール所有者のインストール・システム権限。 |
|
OSDBA |
|
データベースのすべてのシステム権限を含む、Oracle Database用のSYSDBAシステム権限。 |
|
OSOPER |
|
Oracle Database用の起動および停止を行うSYSOPERシステム権限。 |
|
OSBACKUPDBA |
|
Oracle Database用のバックアップとリカバリを行うSYSBACKUPシステム権限。 |
|
OSDGDBA |
|
Oracle Data Guardの管理と監視を行うSYSDGシステム権限。 |
|
OSKMDBA |
|
Oracle Wallet Managerなどのアプリケーションの暗号化鍵管理に使用するSYSKMシステム権限。 |
|
OSASM |
|
Oracle ASM記憶域用のすべてのシステム権限を含む、クラスタのOracle ASM用のSYSASMシステム権限。 |
|
OSOPER for ASM |
|
クラスタのOracle ASM用の起動および停止を行うSYSOPERシステム権限。 |
|
OSDBA for ASM |
|
Oracle ASMにより管理されているファイルに対する読取りおよび書込みアクセス権を取得するASM用のSYSDBAシステム権限(すべてのOracle Databaseソフトウェア所有者は、このグループのメンバーである必要があります)。 |
|
関連項目:
|
Oracle RACでは、すべてのクラスタ・ノードのタイムゾーン設定が同じである必要があります。クラスタにOracle Grid Infrastructureをインストールする際、インストール・プロセスによってOracle Universal Installer (OUI)が実行されているノードのGridインストール所有者のタイム・ゾーン設定が判別されます。OUIでは、Oracle Clusterwareが管理するすべてのプロセスのデフォルトのタイム・ゾーン設定としてそのタイム・ゾーン値をすべてのノードで使用します。このデフォルト設定は、データベース、Oracle ASMおよびその他の管理対象プロセスで使用されます。ただし、SQL*Plusでインスタンスを起動する場合、Oracle RACが使用するタイムゾーン値がOracle Clusterwareタイムゾーンと同じであることを確認する必要があります。コマンドsrvctl setenv database -env 'TZ=time zone'を実行すると、Oracle Clusterwareがデータベースに使用するタイムゾーンを変更できます。
データベースを作成すると、指定したファイルの位置にSPFILEが作成されます。Oracle ASMディスク・グループまたはクラスタ・ファイル・システムをこの場所に指定できます。
クラスタ・データベース内のすべてのインスタンスは、起動時に同じSPFILEを使用します。SPFILEはバイナリ・ファイルであるため、エディタを使用して直接編集しないでください。かわりに、Oracle Enterprise ManagerまたはSQL文ALTER SYSTEMを使用して、SPFILEパラメータ設定を変更します。
|
関連項目: SPFILEの作成および変更の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
Oracleは、oratab構成ファイルに各Oracle RACデータベースのエントリを作成します。oratabファイルは、インストール時にroot.shスクリプトによって作成され、データベースの作成時または削除時にDatabase Configuration Assistantによって更新されます。oratabファイルのエントリも、データベースをまだ実行したことのないノード上で初めて起動したときDatabase Agentによって自動的に作成されます。Oracle ASM Agentは、Oracle ASMのoratabエントリを作成します。
Oracle Enterprise Managerは、サービスの検出時にoratabファイルを使用して、Oracle RACデータベースの名前の確認と、そのデータベースをシステム再起動時に自動起動するかどうかを確認します。
データベースのエントリの構文は、次のとおりです。
$DB_UNIQUE_NAME:$ORACLE_HOME:N
コロン(:)はフィールドの終了記号として使用されます。改行は、エントリの終了を示します。シャープ記号(#)で始まる行はコメントです。Oracle RACデータベースのすべてのインスタンスは同じDB_UNIQUE_NAMEを持ちますが、各インスタンスにはそれぞれ専用のORACLE_SIDがあるため、oratabファイルの$DB_UNIQUE_NAME環境変数をデータベース・エントリとして使用します。
Oracle RACデータベースの$DB_UNIQUE_NAME識別子は企業内で一意である必要があります。$ORACLE_HOMEは、データベースへのディレクトリ・パス、Nは、システムの再起動時にデータベースを起動しないことを示します。たとえば、データベース名salesのエントリは、次のとおりです。
sales:/u01/app/oracle/sales:N
この項では、DBCAによって作成されたデータベース・コンポーネントについて説明します。内容は次のとおりです。
シングル・インスタンスおよびクラスタ・データベースの両方の環境では、Oracle Databaseは表領域という小さな論理領域に分割されています。各表領域は、共有記憶域にある1つ以上のデータ・ファイルに対応しています。表7-2に、Oracle RACデータベースで使用する表領域名、およびその表領域に含まれるデータの種類を示します。
表7-2 Oracle Real Application Clustersデータベースで使用する表領域名
| 表領域名 | 内容 |
|---|---|
|
|
補助システム表領域で、 |
|
データベースに必要な表、ビューおよびストアド・プロシージャの定義を含む、データ・ディクショナリで構成されます。この表領域内の情報は自動的にメンテナンスされます。 |
|
|
SQL文の処理時に作成された一時表および索引が含まれます。非常に大規模な表に対する |
|
|
DBCAが自動UNDO管理用に作成する、インスタンスごとのUNDO表領域が含まれます。 |
|
|
アプリケーション・データで構成されます。表を作成しデータを入力するにつれて、この領域にデータが書き込まれます。 |
|
|
データベースの作成時に含めることを選択した場合は、サンプル・スキーマを保存します。 |
OUIで事前構成済データベース構成オプションを使用する場合、これらの表領域名は変更できません。ただし、詳細なデータベース作成方法を使用する場合は、表領域名を変更できます。
前述のとおり、各表領域には、共有ファイル・システムに存在する1つ以上のデータ・ファイルがあります。事前定義済データベース構成オプションによって作成されるデータ・ファイル名は、記憶域タイプ(Oracle ASM、クラスタ・ファイル・システムなど)によって異なります。
データベースは、共有記憶域に格納されている2つの制御ファイルを使用して構成されています。各データベースには、一意の制御ファイルが1つ必要であり、データベースに構成されているその他の制御ファイルは、元の制御ファイルと同一のコピーです。
制御ファイルが使用できなくなった場合、その破損した制御ファイルにアクセスしようとするデータベース・インスタンスは失敗します。様々なディスクに制御ファイルを多重化する(多重コピーを作成する)ことによって、データベースは冗長性を実現でき、それによってシングル・ポイント障害を避けることができます。
|
関連項目:
|
各データベース・インスタンスには、2つ以上のオンラインREDOログ・ファイルが必要です。データベース・インスタンスのオンラインREDOログ・ファイルは、REDOスレッドと呼ばれます。オンラインREDOログ・ファイルの単一セットの競合を避けるために、各Oracle RACデータベース・インスタンスには、それぞれ固有のREDOスレッドがあります。インスタンス障害が発生しても、障害が発生していないインスタンスは、オンラインREDOログ・ファイルにアクセスできる必要があります。したがって、Oracle RACデータベースのオンラインREDOログ・ファイルは、共有記憶域またはOracle ASMに配置される必要があります。記憶域としてファイル・システムを使用する場合、ファイル・システムは共有またはクラスタ・ファイル・システムである必要があります。
事前構成済データベース構成オプションによって作成されるREDOログ・ファイルのファイル名は、記憶域タイプによって異なります。
|
関連項目:
|
Oracle Databaseは、UNDO表領域に、ロールバック情報やUNDO情報を格納します。UNDO表領域を管理するには、自動UNDO管理を使用することをお薦めします。自動UNDO管理は、手動UNDO管理より簡単に管理できる、自動化されたUNDO表領域の管理モードです。
Oracle ASMおよびOracle Managed Filesを自動UNDO管理とともに使用する場合、初めて起動されたインスタンスはUNDO表領域を持ちませんが、別のインスタンスによって自動的に作成されたそのインスタンス用のUNDO表領域を持つことになります。これは、REDOログについても同じです。
|
関連項目:
|
Oracle Databaseの初期化パラメータの保存には、サーバー・パラメータ・ファイル(SPFILE)を使用することをお薦めします。Oracle ASM SPFILEを含む、Oracle ASMのすべてのSPFILEを保存することをお薦めします。SPFILEは共有記憶域に置いて、クラスタ・データベースのすべてのインスタンスがこのパラメータ・ファイルにアクセスできるようにする必要があります。
|
関連項目: パラメータ・ファイルの作成および使用の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
ユーザーは、クライアント/サーバー構成を使用するか、または接続プーリングを任意に使用し、1つ以上の中間層を介してOracle RACデータベースにアクセスします。Oracle Databaseに接続するときは、接続記述子またはネット・サービス名を使用できます。Oracle RACデータベースの場合、単一クライアント・アクセス名(SCAN)を使用して、Oracle RACデータベースの使用可能な任意のインスタンスに接続することもできます。
この項には次のトピックが含まれます:
|
関連項目: Oracle Net Servicesの概念の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
各データベースは、1つ以上のサービスで表されます。サービスは、サービス名(sales.example.comなど)によって識別されます。クライアントはサービス名を使用して、自身がアクセスする必要があるデータベースを識別します。インストール中に、Oracle RACデータベースは、データベースと同じ名前を持つデフォルトのデータベース・サービスを使用して構成されます。このサービスは、データベース管理タスクの実行に使用できます。クライアントおよびアプリケーションのデータベースへの接続用に、追加のサービスを作成する必要があります。
サービス名は複数のデータベース・インスタンスに関連付けることができ、インスタンスは複数のサービスに関連付けることができます。リスナーはクライアントとデータベース・インスタンスとの間の仲介役を果し、接続要求を適切なインスタンスに渡します。サービスに接続するクライアントは、接続先のインスタンスを指定する必要がありません。
各ネット・サービス名は、接続記述子に関連付けられます。接続記述子は、データベースの場所とデータベース・サービスの名前を提供します。接続記述子は、リスナーの1つ以上のプロトコル・アドレスと、接続先サービスの接続情報で構成されています。
データベース接続の作成にサービス名を使用する際に必要な情報はリポジトリに格納することができ、1つ以上のネーミング・メソッドで表されます。ネーミング・メソッドとは、クライアント・アプリケーションがサービス名を接続記述子に解決するために使用する解決方法です。Oracle Net Servicesは、いくつかの種類のネーミング・メソッドを提供しています。これらは、各クライアント上のローカル構成またはネットワーク上のすべてのクライアントがアクセスできる集中化された構成をサポートしています。
簡易接続ネーミング・メソッドを使用すると、TCP/IP環境でtnsnames.oraファイルまたはその他のリポジトリ内をサービス名で検索する必要がなくなります。簡易接続では、クライアントはホスト名と、オプションのポートおよびサービス名で構成される単純なTCP/IPアドレスの接続文字列を使用します。このメソッドを使用する場合、ネーミングまたはディレクトリ・システムは必要ありません。例については、例7-1「簡易接続ネーミング・メソッドを使用したOracle RACへの接続」を参照してください。
ほとんどの環境に対応するように、Oracle Databaseサーバーとクライアントのネットワーク要素が事前構成されています。デフォルトでは、簡易接続ネーミング・メソッドが有効化され、リポジトリは不要です。簡易接続以外のネーミング・メソッドを使用する場合は、Oracle Net Servicesの追加の構成が必要となる場合があります。
この項には次のトピックが含まれます:
SCANは、ドメイン・ネーム・サービス(DNS)またはグリッド・ネーミング・サービス(GNS)のいずれかにある、1つ以上3つ以下のIPアドレスに登録されたドメイン名です。Oracle Grid Infrastructureのインストール時に、いくつかのOracle ClusterwareリソースがSCAN用に作成されます。
SCAN仮想IP (VIP)は、SCANが解決するIPアドレスごとに作成されます
SCANリスナーは、SCAN VIPごとに作成されます
SCAN VIPへの依存性は、SCANリスナー用に構成されます
SCANは、次の2つのオプションのうち1つを使用して定義されます。
SCANをDNSで定義
SCANを手動で構成し、名前解決にDNSを使用する場合、ネットワーク管理者は、クラスタのパブリック・ネットワークと同じネットワーク上の3つのIPアドレスに解決される単一の名前をSCANに作成する必要があります。SCAN名は、ドメインの接尾辞を使用せずに解決できる必要があります(たとえば、アドレスsales1-scan.example.comは、sales1-scanを使用して解決できる必要があります)。Oracle ClusterwareはSCANを解決するため、SCANをネットワーク・インタフェースに割り当てることはできません。
デフォルトのSCANは、cluster_name-scan.domain_nameです。たとえば、GNSを使用しないクラスタでは、クラスタ名がsales1で、ドメインがexample.comである場合、デフォルトのSCANアドレスはsales1-scan.example.com:1521です。
SCANをGNSで定義
GNSおよびDHCPを使用している場合、Oracle Clusterwareでは、クラスタの構成時に指定されるSCAN名のVIPアドレスが構成されます。ノードVIPおよび3つのSCAN VIPは、GNSを使用時している場合、DHCPサーバーから取得されます。新しいサーバーがクラスタに追加されると、Oracle Clusterwareでは、必要なVIPアドレスはDHCPサーバーから動的に取得されてクラスタ・リソースが更新され、GNSを介してサーバーにアクセスできるようになります。
クラスタに接続するクライアントが、Oracle Grid Infrastructure 11gリリース2 (11.2)より前のリリースで使用されていたノードVIPではなく、SCAN名を使用するように構成することをお薦めします。SCANを使用してOracle RACデータベースに接続するクライアントは、特定のデータベースまたはデータベース・インスタンスをホストする各ノードのアドレスで構成する必要がありません。たとえば、クラスタにポリシー管理型のサーバー・プールを構成した場合、サーバー・プールにどのノードが割り当てられているかにかかわらず、SCANを使用してデータベースへ接続することによって、そのデータベースのサーバー・プールに接続できます。データベースに接続しているクライアントを再構成することなく、データベースに対してノードの追加または削除を行うことができます。
|
関連項目: SCANの構成および要件の詳細は、ご使用のプラットフォーム用の『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。 |
SCANの仮想IPアドレス(VIP)は、ノードのVIPと同様に機能します。ただし、ノードVIPとは異なり、SCAN VIPはクラスタ内の任意のノードで実行できます。ノードVIPの名前やアドレスではなくSCANを使用して接続するクライアント(ユーザーまたはアプリケーション)は、クラスタに対してノードが追加または削除されたとき、あるいはデータベース・インスタンスが別のノードで実行されたときに、そのローカルのtnsnames.oraファイルのノードの名前やアドレスのリストを更新する必要はありません。
|
注意: DNSに3つのSCAN VIPを構成しても、それだけでは接続のフェイルオーバーは保証されません。Oracleクライアントは、かわりに、接続リクエストを別のSCANリスナーにフェイルオーバーさせるために返されたSCAN VIPを使用します。SCAN VIPへの接続の試行が失敗すると、クライアントは次に返されたSCAN VIPアドレスを使用して接続します。そのため、SCANを使用する接続では、Oracle Client 11g リリース2以上のクライアントを使用することをお薦めします。 |
名前解決にGNSを使用する場合、インストール時にはSCAN名のみを提供します(sales1-scanなど)。GNSは、3つのIPアドレスのDHCPアドレス・リースを取得し、これらのアドレスをSCANに解決します。GNSデーモンは登録をリスニングします。SCAN VIPは、ノードで使用が開始された際に自身のアドレスをGNSに登録します。
GNSによって管理されるクラスタ・ドメインへのサービス要求はGNSのVIPアドレスにルーティングされ、そこで要求はクラスタのGNSデーモンへとルーティングされます。GNSが、DNSからSCAN用の要求を受信すると、SCANリスナーの登録アドレスがDNSに返されます。その後、DNSはクライアントに3つのSCAN VIPアドレスを返します。
|
関連項目: SCANの名前、リスナーおよびクライアント・サービス要求の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Grid Infrastructureのインストールでは、SCANを解決するために割り当てられるSCAN VIPアドレスと同数のSCANリスナーが作成されます。高可用性とスケーラビリティのため、SCANは3つのVIPアドレスに解決することをお薦めします。SCANを3つのアドレスに解決する場合は、3つのSCAN VIPと3つのSCANリスナーが作成されます。
各SCANリスナーは、対応するSCAN VIPに依存します。SCANリスナーは、ノードでSCAN VIPが有効になるまで起動できません。
SCANリスナーのアドレスは、外部のドメイン・ネーム・サービス(DNS)、またはクラスタ内のグリッド・ネーミング・サービス(GNS)のいずれかを介して解決されます。SCANリスナーおよびSCAN VIPは、クラスタ内の任意のノードで実行できます。SCAN VIPを実行しているノードに障害がある場合、SCAN VIPおよび関連付けられているリスナーは、クラスタ内の別のノードにフェイルオーバーされます。クラスタ内の使用可能なノード数が3未満になった場合、1つのサーバーが2つのSCAN VIPとSCANリスナーをホストします。
|
関連項目: SCANリスナーの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
tnsnames.oraファイルを構成するかわりに、SCANおよび簡易接続ネーミング・メソッドを使用してデータベースに接続するようにOracle RACデータベース・クライアントを構成することをお薦めします。
Oracle Database 11g リリース2より前のOracle RACリリースのノードVIPアドレスを使用してクラスタに接続するように構成されたクライアントは、既存の接続アドレスを引き続き使用できるため、SCANを使用する必要はありません。以前のリリースのOracle Databaseをアップグレードすると、データベースはローカル・リスナーだけではなく、SCANリスナーにも登録されるので、クライアントがSCANを使用してそのデータベースに接続できるようになります。
例7-1 簡易接続ネーミング・メソッドを使用したOracle RACへの接続
SCANがsales1-scan.mycluster.example.comであるクラスタでOracle RACデータベースが実行されている場合は、次のような接続記述子を使用して、データベース・サービスoltp.example.comに対する接続要求を送信できます。
sqlplus system/manager@sales1-scan.mycluster.example.com:1521/oltp
SCANがDNSで解決される場合、DNSはクライアントに対してラウンドロビンの順で3つのSCAN VIPアドレスをすべて返します。SCANがGNSで解決される場合、DNSゾーン委任によってGNSに参照リクエストが送信され、その後クライアントに対してラウンドロビンの順で3つのSCAN VIPアドレスがすべて返されます。
その後、クライアントでは、返された1つのSCAN VIPアドレスを使用してSCANリスナーに問い合せます。SCANリスナーがクライアントから接続要求を受け取ると、SCANリスナーはクラスタ内で最もロードされていない、要求されたサービスを提供しているインスタンスを識別します。次に、最もロードされていないインスタンスが実行中のノードのローカル・リスナーに接続要求をリダイレクトし、クライアントにローカル・リスナーのアドレスを付与します。次に、ローカル・リスナーは、データベース・インスタンスへの接続を作成します。
Oracle Databaseは、ローカル・リスナーを介して接続要求を受け取ります。ローカル・リスナーはクライアント要求を仲介して、サーバーに渡します。リスナーはプロトコル・アドレスで構成されており、同じプロトコル・アドレスで構成されたクライアントは、そのリスナーに接続要求を送信できます。接続が確立されると、クライアントとOracle Databaseは互いに直接通信します。
ローカル・リスナー(デフォルトのリスナー)は、Oracle Grid Infrastructureのインストール時にGridホームに配置されます。ローカル・リスナーは、データベース接続要求と、外部プロシージャやOracle XML Database (XDB)要求などのデータベース接続以外の要求に応答するように構成されています。データベースが起動されると、データベース・エージェント・プロセス(oraagent (以前のracgimon))は、LOCAL_LISTENERパラメータにOracle Netサービス名を必要としない接続記述子を設定します。GridホームのリスナーのエンドポイントとなるLOCAL_LISTENERの値が計算されます。
1つのlistener.oraファイルには、それぞれが一意の名前を持つ複数のOracle Databaseリスナーを構成できます。データベース・リスナーに対して複数のリスナーを構成できるのは、トップレベルの各構成パラメータにリスナー名の接尾辞があるか、または構成パラメータがリスナー名そのものであるためです。データベースを複数のローカル・リスナーに登録されるように構成するには、LOCAL_LISTENERパラメータを手動で変更する必要があります。
|
注意: ほとんどのユーザーの環境では、ノードごとに1つのリスナーのみを実行することをお薦めします。 |
Oracle RACデータベースでは、データベース・パラメータREMOTE_LISTENERがSCANリスナーを識別します。データベースは、これらのパラメータに含まれる接続記述情報を使用して、ローカル・リスナーとSCANリスナーに登録されます。Oracle Database 11g リリース2以降のインスタンスは、リモート・リスナーとしてはSCANリスナーにのみ登録されます。アップグレードしたデータベースは、リモート・リスナーとしてSCANリスナーに登録されるとともに、引き続きすべてのノード・リスナーにも登録されています。
Oracle RACデータベースのREMOTE_LISTENERパラメータは常にSCANアドレスに設定されます。たとえば、クラスタのSCANがmyscanで、クラスタのGNSサブドメインがmycluster.example.comである場合、REMOTE_LISTENERパラメータには次の値が保持されます。
myscan.mycluster.example.com:1521
|
注意: Oracle RACデータベースのREMOTE_LISTENERパラメータは、SCANをホスト名(HOST=scan)に使用する単一アドレスを持つOracle Netエイリアスには設定しないでください。 |
Oracle Database 12c リリース1 (12.1)のデータベース・サービスは、データベース初期化パラメータLOCAL_LISTENERおよびREMOTE_LISTENERに指定されたリスナーに自動的に登録されます。登録時に、リスナー登録(LREG)プロセスは情報(サービス名、インスタンス名、ワークロード情報など)をリスナーに送信します。この機能は、サービス登録と呼ばれます。
Oracleインスタンスの起動後にリスナーが起動し、リスナーがサービス登録に使用可能になると、次回にOracle Database LREGプロセスが検出ルーチンを起動するまで登録は行われません。デフォルトでは、LREG検出ルーチンは60秒ごとに起動されます。60秒の遅延を変更するには、SQL文ALTER SYSTEM REGISTERを使用します。この文によって、LREGはすぐにサービスを登録します。
|
注意: リスナーの起動直後にALTER SYSTEM REGISTER文を実行するスクリプトを作成することをお薦めします。インスタンスが登録されているときにこの文を実行すると、すべてのサービスが現在登録されている場合、またはリスナーが停止している場合、何も処理されません。 |
|
関連項目: サービス登録の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
サービス名を使用しているOracle RACデータベースにSCANを使用して接続する場合は、環境に基づいて次のアクションが発生します。番号が付けられたアクションは、図7-1に示されている矢印に相当します。
各インスタンスのLREGプロセスは、ローカル・ノード上のデフォルトのリスナーと、REMOTE_LISTENERデータベース・パラメータで指定された各SCANリスナーにデータベース・サービスを登録します。リスナーは、インスタンスとディスパッチャによって処理されている作業の量に基づいて動的に更新されます。
クライアントは、次の書式の接続記述子を使用して、データベース接続要求を発行します。
orausr/@scan_name:1521/webapp
|
注意: 簡易接続ネーミング・メソッドを使用する場合は、クライアントのsqlnet.oraファイルに、NAMES.DIRECTORY_PATHパラメータで指定されたネーミング・メソッドのリストのEZCONNECTが含まれていることを確認します。 |
クライアントは、DNSを使用してscan_nameを解決します。SCANに割り当てられる3つのアドレスがDNSから戻された後、クライアントは1番目のIPアドレスに接続要求を送信します。接続要求が失敗すると、クライアントは次のIPアドレスを使用して接続を試行します。
接続要求が成功すると、クライアントは、salesデータベースをホストし、webappサービスを提供するインスタンスを持つクラスタのSCANリスナーに接続します(この例ではsales1とsales2です)。SCANリスナーは、インスタンスsales1およびsales2のワークロードと、これらが実行されているノードのワークロードを比較します。SCANリスナーがnode2はnode1よりも負荷が小さいと判断すると、SCANリスナーはnode2を選択し、そのノードのリスナーのアドレスをクライアントに送信します。
クライアントは、node2のローカル・リスナーに接続します。ローカル・リスナーは、データベース接続のための専用サーバー・プロセスを起動します。
クライアントは、node2の専用サーバー・プロセスに直接接続し、sales2データベース・インスタンスにアクセスします。
Oracle RACデータベースは、接続時ロード・バランシング機能とフェイルオーバー機能に重要なメリットを提供します。
サービスは、そのワークロード(現在処理している作業の量)をローカル・リスナーとSCANリスナーに登録することで、自身のセッションを調整します。クライアントはSCANリスナーによって、特定のサービスのインスタンスを実行する、負荷が最も低いノードのローカル・リスナーへとリダイレクトされます。この機能は、ロード・バランシングと呼ばれます。ローカル・リスナーは、クライアントをディスパッチャ・プロセスに送るか(データベースが共有サーバーを使用するよう構成されていた場合)、またはクライアントを専用サーバー・プロセスに送ります。
Oracle RACデータベースには、2つのタイプのロード・バランシング(クライアント側およびサーバー側のロード・バランシング)を実装できます。クライアント側のロード・バランシングは、リスナー全体で接続要求のバランスをとります。サーバー側のロード・バランシングの場合、SCANリスナーはロード・バランシング・アドバイザを使用して、現在サービスを提供している最適なインスタンスに接続要求を送ります。
|
関連項目:
|
クライアントがSCANを使用して接続要求を発行すると、3つのSCANアドレスがクライアントに戻されます。1番目のアドレスに障害がある場合は、SCANへの接続要求が次のアドレスにフェイルオーバーされます。複数のアドレスを使用することによって、最初のインスタンスに障害があっても、クライアントはデータベースのインスタンスに接続できます。
Oracle RACはノードVIPアドレスを使用したフェイルオーバーを提供します。これは、同じデータベース・サービスに対するクライアント接続要求を管理するために、複数のノードで複数のリスナーを構成することで実現します。ノードで障害が発生すると、VIPへのサービス接続は動作可能なノードに透過的に再接続されるため、VIPを介して接続するクライアントに障害を迅速に通知できます。アプリケーションおよびクライアントが透過的アプリケーション・フェイルオーバー・オプションを使用して構成されている場合、そのクライアントは動作可能なノードに再接続されます。
スタンドアロンのOracle Databaseは、共有サーバー・ディスパッチャ・プロセス間で接続を分散することでロード・バランシングを実現します。DBCAは、デフォルトで、Oracle RACデータベースを共有サーバーではなく専用サーバーで構成します。ただし、DBCAの使用時に共有サーバー・オプションを選択すると、DBCAは共有サーバーを構成します。共有サーバーが構成されていると、Oracle RACでは、専用サーバーと共有サーバーの両方の処理が使用されます。
|
関連項目: 共有サーバーと専用サーバーの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
ほとんどの環境に対応するように、Oracle Databaseサーバーとクライアントのネットワーク要素が事前構成されています。デフォルトでは、簡易接続ネーミング・メソッドが有効化され、リポジトリは不要です。簡易接続以外のネーミング・メソッドを使用する場合は、Oracle Net Servicesの追加の構成が必要となる場合があります。
次の項では、Oracle RACデータベース用のOracle Net Servicesの構成ファイルおよびパラメータについて説明します。
Oracle Database 12c リリース1 (12.1)のデータベース・サービスは、LOCAL_LISTENERとREMOTE_LISTENERパラメータに指定されたリスナーに自動的に登録されます。登録時に、リスナー登録(LREG)プロセスは情報(サービス名、インスタンス名、ワークロード情報など)をリスナーに送信します。
Oracleインスタンスの起動後にリスナーが起動し、リスナーがサービス登録に使用可能になると、次回にOracle Database LREGプロセスが検出ルーチンを起動するまで登録は行われません。デフォルトでは、LREG検出ルーチンは60秒ごとに起動されます。60秒の遅延を変更するには、SQL文ALTER SYSTEM REGISTERを使用します。この文によって、LREGはすぐにサービスを登録します。
|
注意: リスナーの起動直後にALTER SYSTEM REGISTER文を実行するスクリプトを作成することをお薦めします。インスタンスが登録されているときにこの文を実行すると、すべてのサービスが現在登録されている場合、またはリスナーが停止している場合、何も処理されません。 |
|
関連項目: サービス登録の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。 |
インストール・プロセスによって各ノードにtnsnames.oraファイルが作成されます。このファイルは、ネット・サービス名のリポジトリとして機能します。各ネット・サービス名は、接続識別子に関連付けられています。接続識別子は、ユーザー定義の名前を接続記述子にマップする識別子です。接続記述子には、次の情報が含まれます。
プロトコル・アドレスを介するリスナーの位置を含む、サービスへのネットワーク・ルート
データベース・サービスの名前に設定される値を持つ、SERVICE_NAMEパラメータ
|
注意: 指定できるサービス名は1つのみであるため、tnsnames.oraファイルで使用するSERVICE_NAMEパラメータは1つです。SERVICE_NAMEパラメータは、service_namesデータベース初期化パラメータとは別です。service_namesデータベース・パラメータにはデフォルトで、初期化パラメータ・ファイルのdb_nameとdb_domainパラメータからなるグローバル・データベース名が設定されています。SRVCTLまたはOracle Enterprise Manager Cloud Controlを使用してサービス名を追加すると、データベースに対して追加されたクラスタ管理サービスがリストされます。 |
tnsnames.oraファイルは、Grid_home/network/adminとOracle_home/network/adminの両方のディレクトリにあります。Oracle Grid Infrastructureがインストールされている場合、デフォルトでは、Gridホームからtnsnames.oraファイルが読み取られます。
Oracle Clusterware 11g リリース2以上では、リスナーの対応付けにtnsnames.oraファイルのエントリは必要ありません。リスナー対応付けは、次のように構成されます。
DBCAでは、LOCAL_LISTENERパラメータは設定されなくなりました。データベースを起動するOracle Clusterwareエージェントは、LOCAL_LISTENERパラメータを動的に設定し、このパラメータに別名ではなく実際の値を設定します。そのため、tnsnames.oraファイルのlistener_aliasエントリは不要になります。
REMOTE_LISTENERパラメータは、DBCAによって、SCANとSCANポートを参照するように構成され、tnsnames.oraのエントリは不要です。Oracle Clusterwareではscanname:scanportに簡易接続ネーミング・メソッドを使用するため、tnsnames.oraファイルにREMOTE_LISTENERパラメータに対するリスナーの関連付けは不要です。
たとえば、データベースを作成した後に、ポート2012をリスニングする2番目のリスナーを追加する場合は、次のコマンドと類似したコマンドを使用してデータベースを両方のリスナーに起動時に登録します。
SQL> alter system set local_listener='(DESCRIPTION= (ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.61)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.0.61)(PORT=2012))))' scope=BOTH SID='OCRL1';
|
関連項目:
|
DBCAは、次の項で説明するように、接続用のネット・サービス名を作成します。
Oracle RACのインスタンスに接続するクライアントは、接続記述子のSCANを使用します。ネット・サービス名を使用して、Oracle RACに接続することもできます。DBCAで作成されるデフォルトのデータベース・サービスによって、Oracle Enterprise ManagerがOracle RACデータベースを検出できるようになりますが、このサービスはクライアント接続には使用できません。
DBCAを使用してマルチテナント・コンテナ・データベース(CDB)のOracle RACデータベースを作成する場合は、DBCAはデータベースと同じ名前のデータベース・サービスを作成します。このデータベース・サービスを使用するクライアントは、Oracle RACのCDBの任意のデータベース・インスタンスに接続できます。ただし、既存のCDBにプラガブル・データベース(PDB)を追加するためにDBCAを使用する場合は、DBCAでは新しいPDB用のデータベース・サービスは作成しません。
例7-2 データベース接続用のネット・サービス名エントリの例
この例は、tnsnames.oraファイルで使用される接続記述子を示しています。この場合の接続識別子は、クラスタ・ドメインmycluster.example.comと同じです。個々のサーバーのアドレス、仮想インターネット・プロトコル(VIP)・アドレスまたはクラスタ・ノード名を指定するかわりに、接続記述子はSCAN (myscan.mycluster.example.com)を使用します。
mycluster.example.com =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = host=myscan.mycluster.example.com)
(PORT = 1522))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = myApp)
)
)
Oracle Clusterwareは、ネット・サービス名mycluster.example.comを使用する接続リクエストをmyAppデータベース・サービスを実行するmyclusterの任意のデータベース・インスタンスに解決します。インスタンスが実行されている特定のクラスタ・ノードは、クライアントに対して非表示です。
ネット・サービス名は、データベース、データベース・インスタンスまたはリスナーが実行されるサーバーの完全修飾ドメイン名を必要としません。SCANはDNSまたはGNSによって解決され、クライアントに3つのアドレスが戻されます。次に、クライアントは、接続が確立されるまで各アドレスに接続要求を連続して送信します。
データベースの特定のインスタンスに接続するクライアントは、そのインスタンスのネット・サービス名を使用します。
例7-3 インスタンス接続用のネット・サービス名エントリの例
この例では、接続識別子は、インスタンス名mycluster1.example.comと同じです。接続記述子は、SCANを使用してクラスタのインスタンスを特定します。ネット・サービス名mycluster1.example.comに接続するクライアントは、myclusterデータベースのmycluster1データベース・インスタンスに接続されます。Oracle Clusterwareは、その接続をインスタンスが実行されているクラスタ･ノードに解決します。インスタンスが実行されている特定のクラスタ・ノードは、クライアントに対して非表示です。
mycluster1.example.com=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=myscan.mycluster.example.com)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=mycluster.example.com)
(INSTANCE_NAME=mycluster1)
)
)
Oracle RAC環境では、Oracle AgentでOracle DatabaseのOracleリスナーを管理することをお薦めします。次の項では、Oracle Net Listenerの構成について説明します。
|
注意: GNSを有効にした場合、リスナーを手動で構成する必要はありません。 |
ローカル・リスナー(デフォルトのリスナー)は、Oracle Grid Infrastructureのインストール時にGridホームに配置されます。listener.oraファイルは、Grid_home/network/adminディレクトリにあります。必要に応じて、Gridホーム・リスナーのlistener.oraファイルを編集して、ノードおよびSCANリスナーのリスナー・パラメータを定義できます。リスナー・エージェントが自動的に管理するので、エンドポイントは変更しないでください。
Oracle Databaseの作成時、LOCAL_LISTENERパラメータは、データベースのローカル・リスナーを指すように自動的に構成されます。LOCAL_LISTENERには手動で値を設定できます。LOCAL_LISTENERパラメータの値を変更すると、データベース・エージェント・プロセスはこの値を自動更新しません。このパラメータは設定せずに、データベース・エージェント・プロセスで自動的にメンテナンスできるようにすることをお薦めします。LOCAL_LISTENERを設定しなければ、Database Agentプロセスによって、リスナーのポートまたはIPアドレスが変更された場合でも、Gridホームのローカル・リスナーとデータベースの関連付けは自動的に更新されます。
|
関連項目:
|
リモート・リスナーとは、あるコンピュータ上にあるリスナーのことで、別のコンピュータ上にあるデータベース・インスタンスに接続をリダイレクトします。たとえば、SCANリスナーはリモート・リスナーです。Oracle RAC環境では、Oracle AgentでデータベースのOracleリスナーを管理することをお薦めします。
|
関連項目:
|
lsnrctlコマンドを使用してOracle Database 12c リリース1 (12.1)のローカル・リスナーおよびSCANリスナーを管理するには、ORACLE_HOME環境変数にGridホームのパスを設定します。以前のリリースで使用していたOracleホームの位置からlsnrctlコマンドを使用しないでください(この位置はOracle Database 12c リリース1 (12.1)では使用できません)。
Oracle Clusterwareによって管理されていないリスナーの場合、Oracle Net Services構成ファイルを含むディレクトリを指すようにTNS_ADMIN環境変数またはレジストリ値を設定することによって、listener.oraファイルにデフォルト以外の場所を使用できます。Oracle Clusterwareが管理しているリスナーにデフォルト以外の場所を使用する場合、SRVCTLおよびsetenvコマンドを使用して、各リスナーのTNS_ADMINの値を変更する必要があります。
listener.oraファイルは、リスナーの構成ファイルです。これには、接続要求を受け入れるプロトコル・アドレス、リスニングするデータベース・サービスとその他のサービスのリストおよびリスナーにより使用される制御パラメータを含めることができます。Oracle ClusterwareおよびOracle RACにより使用されるリスナーの構成は、サーバー制御ユーティリティ(SRVCTL)コマンドまたはNETCAを使用して変更できます。listener.oraファイルを手動で編集する必要はありません。
各リスナーは、リスニングするエンドポイントを指定する1つ以上のプロトコル・アドレスで構成されます。リスナー・エージェントはエンドポイントをリスナーで動的に更新します。Oracle Database 11g リリース2からは、listener.oraファイルにIPCキーおよび次の情報のみが含まれるようになりました。
(ADDRESS = (PROTOCOL=TCP)(HOST=)(PORT=1521))
前述の例で、プロトコルADDRESSは、暗黙的にローカル・ノードのHOSTエンドポイントとなります。Oracle RACデータベースの場合、listener.oraファイルはすべてのノードで同じです。ポート番号など、リスニングしているエンドポイントは、リスナーに動的に登録されます。
Oracle RACをインストールする前の、Oracle Grid Infrastructureのインストール中、NETCAはGridホームにLISTENERと呼ばれるデフォルトのリスナーを作成して起動します。このリスナーは、デフォルトのプロトコル・リスニング・アドレスで構成されます。このリスナーは、インストール中に指定した1つのプロトコル・アドレスに送信された接続要求に応答するように構成されます。
Oracle RACのインストール中に、Oracle RACデータベースはGridホームのリスナーを使用して、Oracle RACデータベースに関するサービス情報を構成します。データベース・サービスは、その情報(サービス名、インスタンス名、ロード情報など)をリスナーに自動的に登録します。動的なサービス登録よって、データベース・サービスの静的な構成が不要になります。ただし、Oracle Enterprise Managerを使用する予定の場合は、静的なサービス構成が必要です。
例7-4 Oracle RACノードのlistener.oraファイルの例
次は、インストール後の状態のlistener.oraファイルの例で、node1というノードとSCANリスナーに関するエントリが記述されています。
LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_
SCAN1)))) # line added by Agent
LISTENER_NODE1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC) (KEY=LISTENER))))
# line added by Agent
# listener.ora.mycluster Network Configuration File:
/u01/app/oracle/product/12.1.0/dbhome_1/network/admin/listener.ora.mycluster
# Generated by Oracle configuration tools.
LISTENER_NODE1 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_NODE1=ON # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN2=ON # line added by Agent
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER_SCAN1=ON # line added by Agent
Oracle Universal Installerは、データベース・ソフトウェアのインストール後にOracle Net Configuration Assistant (NETCA)を起動します。NETCAは、Oracle Net Servicesプロファイルまたはsqlnet.oraファイルを作成します。Oracle Grid Infrastructureインストールでは、sqlnet.oraファイルは、デフォルトで次のディレクトリにあります。
Grid_home/network/admin
Oracle RACデータベース・インスタンスのローカル・リスナーの場合、sqlnet.oraファイルのデフォルトの場所は$ORACLE_HOME/network/adminディレクトリです。このディレクトリには、デフォルトのsqlnet.oraファイルがあります。また、サブディレクトリsampleには、サンプルsqlnet.oraファイルがあります。
Oracle RACソフトウェアのインストール時、NETCAによって、sqlnet.oraファイルに次のエントリが作成されます($ORACLE_BASEは、Oracle RACインストールのOracleベース・ディレクトリへのパスです)。
NAMES.DIRECTORY_PATH=(TNSNAMES, EZCONNECT) ADR_BASE =$ORACLE_BASE
NAMES.DIRECTORY_PATHパラメータは、接続識別子を接続記述子に解決するために使用するネーミング・メソッドの優先順序を指定します。
ADR_BASEパラメータは、自動診断リポジトリ(ADR)がデータベースで有効である場合に、トレーシング・インシデントとロギング・インシデントが格納されるベース・ディレクトリを指定します。
|
関連項目:
|
