3 データベース・インスタンスおよびクラスタ・データベースの管理

この章では、Oracle Real Application Clusters(Oracle RAC)データベースおよびデータベース・インスタンスの管理方法について説明します。

内容は次のとおりです。

• Oracle RACデータベースの管理の概要

• インスタンスおよびOracle RACデータベースの起動および停止

• Oracle RACでのPDBの起動および停止

• インスタンスの実行の確認

• 特定のクラスタ・インスタンス上でのセッションの終了

• Oracle RACでの初期化パラメータ・ファイルの概要

• Oracle RACでの初期化パラメータの使用

• 管理者管理データベースのポリシー管理データベースへの変換

• データベース・サーバーのメモリー不足の管理

• Oracle RACデータベースの静止

• LinuxおよびUNIXプラットフォームでの複数のクラスタ・インターコネクトの管理

• Oracle ClusterwareでのOracle RACデータベースの管理方法のカスタマイズ

• Oracle Enterprise Managerの高度な管理

関連項目:

Oracle Enterprise Manager Cloud Controlの詳細は、Oracle Enterprise Manager Cloud Controlのオンライン・ヘルプを参照してください。

3.1 Oracle RACデータベースの管理の概要

Oracle RACデータベースの管理には、特定の権限が必要になり、ポリシー管理または管理者管理のどちらかのデプロイメント・モデルが必要になります。

Oracle RACデータベースの管理に必要な権限

セキュリティの強化と管理業務の分離を進めるために、Oracle RACデータベースの管理者はOracle RACデータベースをSYSRAC管理権限で管理します。SYSDBA管理権限は必要ではなくなりました。SYSRAC管理権限は、SRVCTLなどのOracle RACユーティリティのかわりに、Oracle Clusterwareエージェントでデータベースに接続する際のデフォルト・モードです。つまり、Oracle RACクラスタの日常管理作業には、データベースへのSYSDBA接続が不要になったということです。

Oracle RACデータベースのデプロイメント・モデル

Oracle RACデータベースは、異なる2つの管理スタイルおよびデプロイメント・モデルをサポートしています。

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

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

同じコマンドまたは方法(DBCAやOracle Enterprise Managerなど)を使用して、管理者管理またはポリシー管理デプロイメント・モデルでデータベースを管理できます。すべてのコマンドおよびユーティリティは、管理者ベース管理(Oracle Database 11gリリース2 (11.2)より前のOracle Databases)のみをサポートしているOracle Databaseの管理をサポートするために下位互換性を維持しています。

一般にデータベースは、Oracle Clusterwareのリソースとして定義されます。データベース・リソースは、DBCAでデータベースを作成したとき、または高速ホーム・プロビジョニングを使用してデータベースをプロビジョニングしたときに自動的に作成されます。また、SRVCTLでデータベースを追加することで、データベース・リソースを手動で作成することもできます。データベース・リソースには、Oracleホーム、SPFILE、1つ以上のサーバー・プール、およびデータベースの起動に必要な1つ以上のOracle ASMディスク・グループが含まれます。Oracle ASMディスク・グループの指定には、srvctl add databaseコマンドまたはsrvctl modify databaseコマンドのどちらかを使用します。また、このリストに登録されていないディスク・グループのデータ・ファイルをデータベースが開くときに、ディスク・グループがリストに追加されます。

また、データベース・リソースにはリスナー・タイプに弱い起動依存性があり、これは、データベース・インスタンスの起動時にリソースがノードのすべてのリスナーを起動しようとすることを意味しています。Oracle Clusterwareは、データベース・インスタンスが起動するノードのリスナーを起動しようとします。リスナーを順に起動すると、ノードのVIPが起動します。

管理者管理データベースのデータベース・リソースを確認すると、そのOracle Databaseと同じ名前で定義されたサーバー・プールが表示されます。このサーバー・プールは、Oracleで定義される特別なサーバー・プールの一部で、Genericと呼ばれます。Oracle RACは、Genericサーバー・プールを管理して管理者管理データベースをサポートします。SRVCTLまたはDBCAのいずれかを使用して管理者管理データベースを追加または削除すると、Genericのメンバーであるサーバー・プールがOracle RACによって作成または削除されます。Genericサーバー・プールの変更に、SRVCTLまたはCRSCTLコマンドを使用することはできません。

ポリシー管理データベースを使用して、動的システムの管理を簡素化します。ポリシー管理により、クラスタおよびデータベースは、要件の変更に応じて拡張または縮小できます。ポリシー管理データベースを使用する場合は、クラスタ内のすべてのノードにOracleホーム・ソフトウェアをインストールする必要があります。ポリシー管理データベースは、Oracle Database 11gリリース2 (11.2)以上のソフトウェアを使用する必要があり、管理者管理データベースと同じサーバーに共存させることはできません。

注意:

同じノードで同じデータベースの複数のインスタンスを実行することはできません。

ポリシー管理データベースは、カーディナリティ(通常の操作で実行する必要があるデータベース・インスタンス数)で定義されます。ポリシー管理データベースは、クラスタ管理者がクラスタに作成した1つ以上のデータベース・サーバー・プールで実行することも、別のサーバーで異なるタイミングで実行することもできます。ポリシー管理データベースの各サーバー・プールは、少なくとも1つのデータベース・サービスを持つ必要があります。データベース・インスタンスは、データベースに定義されたサーバー・プール内のサーバーで起動します。データベース記憶域に、Oracle Automatic Storage Management(Oracle ASM)およびOracle Managed Filesを使用していて、かつインスタンスの起動時に使用可能なREDOスレッドがない場合、Oracle RACは自動的にREDOスレッドを使用可能にし、必要なREDOログ・ファイルとUNDO表領域を作成します。クライアントは、その時点で実行されているサーバーに関係なく、同じSCANベース接続文字列を使用してポリシー管理データベースに接続することができます。

ポリシー管理データベースには、db_unique_name_cardinalityという名前が付けられます。cardinalityは、サーバー・プール内のサーバーのカーディナリティIDです。ローカル・ノード上のインスタンス名を取得するには、srvctl status database -sidコマンドを使用します。また、srvctl modify instanceコマンドを使用すると、ノードからインスタンス名への固定マッピングを作成することもできます。

管理者管理データベースとポリシー管理データベースへの同じクラスタの使用

すでにポリシー管理データベースがホストされているクラスタに管理者管理データベースを作成する場合、管理者管理データベース用のノードは慎重に選択する必要があります。これは、管理者管理データベース用に選択したノードはポリシー管理サーバー・プールにあり、このプロセスの一部としてGenericサーバー・プールに移動されるためです。

すでに他のポリシー管理データベース・インスタンスを実行しているノードを選択した場合、DBCAが管理者管理データベースを作成する際に停止されるインスタンスおよびサービスがリストされたメッセージがDBCAによって表示されます。DBCAによって「続行しますか。」と尋ねられ、そのダイアログ・ボックスで「はい」を選択すると、ポリシー管理データベースのインスタンスおよびサービスは、管理者管理データベース作成プロセスのために停止されます。

注意:

srvctl add instanceコマンドを使用した場合も同様で、データベースが停止されるという内容の同様のメッセージが返されます。srvctl add instanceコマンドで強制オプション(-f)を使用した場合も、DBCAダイアログで「はい」を選択するのと同じです。これにより、ノードをGenericサーバー・プールに移動する前に、そのノードで実行中の一部のポリシー管理データベースが停止されます。

3.1.1 Oracle RACの管理ツール

次の項では、Oracle RACデータベースおよびインスタンスを管理するために一般に使用する3つのツール(SRVCTLユーティリティ、Oracle Enterprise ManagerおよびSQL*Plus)を使用したOracle RAC管理について説明します。多くの場合、これらのツールを使用してOracle RAC環境を管理する方法は、非クラスタのOracle Databaseを管理する場合と同様です。

• SRVCTLを使用したOracle RACの管理

• Oracle Enterprise Managerを使用したOracle RACの管理

• SQL*Plusを使用したOracle RACの管理

3.1.1.1 SRVCTLを使用したOracle RACの管理

サーバー制御ユーティリティ(SRVCTL)は、集中管理的にOracle Databasesを管理するために使用できるコマンドライン・インタフェースです。

Oracleは、クラスタ用のOracle Grid Infrastructureに基づいて、非クラスタ環境とOracle RACデータベースの両方向けのOracle Grid InfrastructureのOracle ASMを使用して、単一インスタンスOracle Databases用のOracle Database 11gリリース2 (11.2)で中央集中型のSRVCTLベースのデータベース管理を使用できるようにしました。これにより、SRVCTLを使用した、すべてのOracle Databaseタイプの同機種管理が可能になります。SRVCTLを使用して、データベースおよびインスタンスの起動と停止、インスタンスおよびサービスの削除または移動を実行できます。また、SRVCTLを使用すると、クラスタ内の他のリソースに加え、サービスの追加および構成情報の管理を行うこともできます。

SRVCTLを使用してクラスタに構成操作を実行すると、SRVCTLは、クラスタ内のOracle Cluster Registry (OCR)に、またはOracle Restart環境内のOracle Local Registry (OLR)に構成データを格納します。SRVCTLは、Oracle Clusterwareリソース(Oracle Call Interface APIを使用してデータベースの起動および停止操作を実行するエージェントを定義)を構成および管理することによって、インスタンスの起動および停止のようなその他の操作を実行します。

注意:

特定の環境変数を使用してデータベース(またはデータベース・インスタンス)を起動する必要がある場合は、srvctl setenvコマンドを使用して、SRVCTLの使用によってデータベース用に維持されているデータベース・プロファイルに対してこれらの変数を設定します。ORACLE_HOMEおよびORACLE_SID環境変数を設定する必要はありません。SRVCTLが自動的にこれらのパラメータを維持および設定するためです。

3.1.1.2 Oracle Enterprise Managerを使用したOracle RACの管理

Oracle Enterprise Managerでは、Oracle RAC環境を集中的に制御し、複数のクラスタ・データベースで同時に管理タスクを実行できます。

Oracle Enterprise Manager Cloud Control (Oracle Enterprise Manager 11gではGrid Control)グラフィカル・ユーザー・インタフェース(GUI)に基づいて、非クラスタ環境とOracle RAC環境の両方を管理できます。

Oracle Enterprise Managerでは、通常、Oracle RAC固有の管理タスクは、クラスタ・データベース全体に関係するタスクおよび特定のインスタンスに関係するタスクの2つのレベルが中心です。たとえば、Oracle Enterprise Managerでは、ジョブのスケジュールやメトリックのアラートしきい値の設定に加え、データベース、クラスタ・データベース・インスタンスおよびそのリスナーを起動、停止および監視できます。または、パラメータの設定やリソース・プランの作成のようなインスタンス固有のコマンドを実行できます。また、Oracle Enterprise Managerを使用して、スキーマ、セキュリティおよびクラスタ・データベースの記憶域機能を管理できます。

3.1.1.3 SQL*Plusを使用したOracle RACの管理

SRVCTLまたはOracle Enterprise Managerとは異なり、SQL*Plusはインスタンス指向の管理ツールです。

SQL*Plusコマンドは、現行のインスタンスで動作します。現行のインスタンスは、SQL*Plusセッションを開始したローカルのデフォルト・インスタンスまたはOracle Net Servicesの接続先リモート・インスタンスです。1つのデータベースで複数のインスタンスを同時に実行するOracle RAC環境の場合、これは、このインスタンス上でSQL*Plusが動作できる範囲を考慮する必要があることを意味しています。これらの制限のため、ポリシー管理データベースを管理する場合はSQL*Plusを使用しないでください。

たとえば、プラガブル・データベース(PDB)が管理者管理スタイルとポリシー管理スタイルのいずれで管理されているかにかかわらず、これらのデータベースを使用する場合、SQL*Plus接続を使用してPDBに実行される変更は、デフォルトで現行のインスタンスにのみ影響することを考慮する必要があります。PDBに属するすべてのインスタンスに影響するような変更を行うには、ALTER PLUGGABLE DATABASEコマンドとinstance=allを使用する必要があります。PDBを使用する場合、動的データベース・サービス(net_service_name)を使用してインスタンスに接続する必要があります。PDBは、自らを、Oracle RACデータベースの1つ以上のインスタンスに関連付けられた動的データベース・サービスとして表しているためです。

デフォルトでは、SQL*Plusのプロンプトで現行のインスタンスが識別されないため、正しいインスタンスにコマンドを発行する必要があります。SQL*Plusセッションを開始して、インスタンスを指定せずにデータベースに接続すると、すべてのSQL*Plusコマンドはローカル・インスタンスで処理されます。この場合も、デフォルト・インスタンスが現行のインスタンスです。

デフォルトでは、SQL*Plusのプロンプトでは現行のインスタンスが識別されないため、正しいインスタンスにコマンドを発行する必要があります。SQL*Plusセッションを開始して、インスタンスを指定せずにデータベースに接続すると、すべてのSQL*Plusコマンドはローカル・インスタンスで処理されます。この場合も、デフォルト・インスタンスが現行のインスタンスです。SQL*Plusで別のインスタンスに接続するには、次の例のように、新しいCONNECTコマンドを発行し、リモート・インスタンスのネット・サービス名を指定します(passwordはパスワードです)。

CONNECT user_name@net_service_name
Enter password: password

SYSOPERまたはSYSRACとして接続すると、インスタンスの起動や停止などの権限が必要になる操作を実行できます。複数のSQL*Plusセッションが、同時に同じインスタンスに接続できます。他のインスタンスに接続すると、SQL*Plusによって最初のインスタンスとの接続が自動的に切断されます。

注意:

Oracle ASMインスタンスに接続して管理するには、SYSRAC権限ではなく、SYSASM権限を使用します。SYSRAC権限を使用してASMインスタンスで実行されるコマンドは非推奨であるため、Oracle ASMインスタンスへの接続にSYSRAC権限を使用すると、Oracle Databaseはアラート・ログ・ファイルに警告を書き込みます。

3.1.1.3.1 インスタンスへのSQL*Plusコマンドの適用方法

ほとんどのSQL文は、現行のインスタンスに適用されます。Oracle RACデータベースでのインスタンスの起動と停止に、SQL*Plusを使用できます。SQL*Plusコマンドを、LinuxおよびUNIXシステムのrootとして、またはWindowsシステムのAdministratorとして実行する必要はありません。非クラスタのOracle Databaseで通常使用する権限を持つ適切なデータベース・アカウントのみが必要です。SQL*Plusコマンドのインスタンスへの適用方法の例を示します。

• ALTER SYSTEM CHECKPOINT LOCALは、デフォルトのインスタンスまたはすべてのインスタンスではなく、現在接続しているインスタンスにのみ適用されます。

• ALTER SYSTEM CHECKPOINTまたはALTER SYSTEM CHECKPOINT GLOBALは、クラスタ・データベースのすべてのインスタンスに適用されます。

• ALTER SYSTEM SWITCH LOGFILEは、現行のインスタンスにのみ適用されます。

  • グローバル・ログ・スイッチを強制するには、ALTER SYSTEM ARCHIVE LOG CURRENT文を使用します。

  • ALTER SYSTEM ARCHIVE LOGのINSTANCEオプションにより、特定のインスタンスについて各オンラインREDOログ・ファイルをアーカイブできます。

表3-1に、SQL*Plusコマンドのインスタンスへの適用方法を示します。

表3-1 インスタンスへのSQL*Plusコマンドの適用方法

SQL*Plusコマンド	関連するインスタンス
ARCHIVE LOG	常に現行のインスタンスに対して適用されます。
CONNECT	CONNECTコマンドにインスタンスが指定されていない場合は、デフォルト・インスタンスに適用されます。
HOST	現行のインスタンスおよびデフォルト・インスタンスの位置に関係なく、SQL*Plusセッションを実行しているノードに適用されます。
RECOVER	特定のインスタンスではなく、データベースに適用されます。
SHOW INSTANCE	現行のインスタンスに関する情報を表示します。リモート・インスタンスにコマンドをリダイレクトしている場合、現行のインスタンスはデフォルトのローカル・インスタンスではない場合があります。
SHOW PARAMETER および SHOW SGA	現行のインスタンスからパラメータおよびSGA情報を表示します。
STARTUP および SHUTDOWN	常に現行のインスタンスに対して適用されます。権限付きのSQL*Plusコマンドです。

3.2 インスタンスおよびOracle RACデータベースの起動および停止

Oracle Enterprise Manager、SQL*PlusまたはSRVCTLを使用して、インスタンスを起動および停止できます。

Oracle Enterprise ManagerおよびSRVCTLでは、Oracle RACデータベースのすべてのインスタンスの起動および停止を1つの手順で行うオプションを提供しています。

任意のツールを使用して、データベースを起動する起動状態を選択できます。データベースおよびデータベース・インスタンスの状態によって、実行できる操作が決まります。データベースがMOUNT (NOMOUNT)状態にある場合のみ特定の操作を実行できます。他の操作を実行するには、データベースがOPEN状態である必要があります。

注意:

同じノードで同じデータベースの複数のインスタンスを実行することはできません。

クラスタ内のノードでOracle RACデータベース・インスタンスを起動するには、まずノードでOracle Grid Infrastructureスタックを起動する必要があります。Oracle Grid Infrastructureスタックが実行されていないサーバーでは、Oracle RACデータベース・インスタンスは起動しません。

Oracle Database QoS Managementポリシー・ワークロードの重要性によるデータベースの起動順序の決定

ユーザー作成のOracle Database Quality of Service Management (Oracle Database QoS Management)ポリシーがアクティブな場合、パフォーマンス・クラスのランク付けされた順序により、関連するOracle RACデータベースの開始順序またはリクエスト・リアルタイムLMSプロセス・スロットが決定されます。パフォーマンス・クラス・ランキングの使用により、統合環境で実行しているミッションクリティカルなデータベースに、リアルタイムで実行するLMSプロセスが確実に含まれることになるので、ノード間通信でのリソースのボトルネックが解消されます。Oracle Database QoS Managementポリシーでは各ワークロードのランクを指定するので、各データベースにMax(Ranks)の値を使用することにより、各データベースのビジネスの重要度を一貫性のある表現で示すことができます。

次の各項の手順では、Oracle RACデータベース・インスタンスの起動および停止について説明します。

• SRVCTLを使用した1つ以上のインスタンスおよびOracle RACデータベースの起動

• SRVCTLを使用した1つ以上のインスタンスおよびOracle RACデータベースの停止

• CRSCTLを使用したすべてのデータベースおよびインスタンスの停止

• SQL*Plusを使用した個々のインスタンスの起動と停止

3.2.1 SRVCTLを使用した1つ以上のインスタンスおよびOracle RACデータベースの起動

SRVCTLを使用して、Oracle RACデータベースおよびインスタンスを起動します。

注意:

この項では、データベースにSPFILEを使用していることを前提にしています。

次のSRVCTL構文をコマンドラインから入力し、必要なデータベース名およびインスタンス名を提供するか、または複数のインスタンス名を指定して、複数の特定のインスタンスを起動します。

• クラスタ・データベース全体(すべてのインスタンスおよび使用可能なサービス)を起動または停止するには、次のSRVCTLコマンドを入力します。

  $ srvctl start database -db db_unique_name [-startoption start_options]

  $ srvctl stop database -db db_unique_name [-o stop_options]

  たとえば、次のSRVCTLコマンドは、Oracle RACデータベースの実行中でないすべてのインスタンスをマウントします。

  $ srvctl start database -db orcl -startoption mount

• 管理者管理データベースを起動する場合は、インスタンス名のカンマ区切りリストを入力します。

  $ srvctl start instance -db db_unique_name -instance instance_name_list
    [-startoption start_options]

  Windowsでは、カンマ区切りリストを二重引用符("")で囲む必要があります。

• ポリシー管理データベースを起動する場合は、単一のノード名を入力します。

  $ srvctl start instance -db db_unique_name -node node_name
    [-startoption start_options]

  また、このコマンドでは、使用可能で実行されていないすべてのサービスが開始されます。そのサービスには、AUTOMATIC管理ポリシーが設定され、サービスのいずれかのロールがデータベース・ロールと一致します。

• 1つ以上のインスタンスを停止するには、コマンドラインから次のSRVCTL構文を入力します。

  $ srvctl stop instance -db db_unique_name [-instance "instance_name_list" | 
    -node node_name] [-stopoption stop_options]

  複数のインスタンス名のカンマ区切りリストを指定して複数のインスタンスを停止することも、1つのノード名を指定して1つのインスタンスを停止することもできます。Windowsでは、カンマ区切りリストを二重引用符("")で囲む必要があります。

このコマンドにより、インスタンスが実行されていたノード上で終了したインスタンスと関連するサービスも停止します。例のとおり、次のコマンドで、immediate stopオプションを使用してorclデータベースの2つのインスタンス(orcl3およびorcl4)を停止することができます。

$ srvctl stop instance -db orcl -instance "orcl3,orcl4" -stopoption immediate

3.2.2 SRVCTLを使用した1つ以上のインスタンスおよびOracle RACデータベースの停止

SRVCTLを使用して、インスタンスとOracle RACデータベースを停止します。

Oracle RACインスタンスの停止手順は、次に説明する例外を除いて、非クラスタのOracle Databaseのインスタンスの停止と同じです。

• Oracle RACでは、1つのインスタンスを停止しても、実行中の他のインスタンスの操作を妨げることはありません。

• Oracle RACデータベースを完全に停止するには、データベースがオープン状態またはマウントされた状態となっているすべてのインスタンスを停止します。

• NORMALまたはIMMEDIATEでの停止後は、インスタンスのリカバリは不要です。ただし、SHUTDOWN ABORTコマンドを発行した後、またはインスタンスが異常終了した後は、リカバリが必要です。まだ実行中のインスタンスが、停止したインスタンスに対してインスタンス・リカバリを実行します。他に実行中のインスタンスがない場合は、次にデータベースをオープンするインスタンスが、リカバリが必要なすべてのインスタンスのリカバリを実行します。

• SHUTDOWN TRANSACTIONALコマンドとともにLOCALオプションを使用すると、特定のOracle RACデータベース・インスタンスを停止する場合に有用です。他のインスタンス上のトランザクションがこの操作を妨げることはありません。LOCALオプションを省略した場合、この操作は、SHUTDOWNコマンドを実行する前に起動した他のすべてのインスタンスのトランザクションがコミットまたはロールバックされるまで待機します。これは、Oracle RACデータベースのすべてのインスタンスを停止する場合は有効なアプローチです。

  注意:

  SHUTDOWN TRANSACTIONALとSHUTDOWN TRANSACTIONAL LOCALの両方は、非クラスタ化データベースに対して同じアクションを実行しますが、この2つのコマンドは、Oracle RACデータベースでは異なっています。

SRVCTLを使用してOracle RACデータベースまたはデータベース・インスタンスを停止します。それぞれのSRVCTLコマンド(srvctl stop databaseまたはsrvctl stop instance)は、最適化されたトランザクションの停止を実行するための停止オプションを備えています。TRANSACTIONAL停止オプションはsrvctl stop databaseコマンドとともに、TRANSACTIONAL LOCAL停止オプションはsrvctl stop instanceコマンドとともに使用します。

3.2.3 CRSCTLを使用したすべてのデータベースおよびインスタンスの停止

ノード全体またはクラスタ全体を停止する場合(たとえばメンテナンス目的など)、必要なクラスタ権限があるときは、ノードでcrsctl stop crsコマンドを実行するか、crsctl stop cluster -allコマンドを実行します。これらのコマンドによって、サーバー上またはクラスタ内で実行されているすべてのデータベース・インスタンスは停止し、クラスタを再起動した後でその状態は確実にリカバリされます。CRSCTLを使用すると、Oracle Clusterwareは、他の場所で実行できるサービスおよび他のリソースを再配置することもできます。

これらのCRSCTLコマンドのいずれかを使用してサーバー上またはクラスタ内のすべてのデータベース・インスタンスを停止すると、shutdown abortと同様にデータベース・インスタンスが停止される可能性があり、起動時にインスタンスのリカバリが必要になります。クラスタを停止する前にSRVCTLを使用してデータベース・インスタンスを手動で停止する場合は、shutdown abortを回避できますが、この場合は、Oracle Clusterwareの再起動後にデータベース・インスタンスを手動で再起動する必要があります。

3.2.4 SQL*Plusを使用した個々のインスタンスの起動と停止

ローカル・ノードに接続された状態で、1つのインスタンスのみを起動または停止するには、まず、現行の環境にローカル・インスタンスのSIDが含まれていることを確認する必要があります。

SQL*Plusセッションかどうかに関係なく、セッション内の後続のすべてのコマンドは、そのSIDに対応付けられます。

注意:

この項では、SPFILEを使用していることを前提にしています。

ローカル・インスタンスを起動または停止するには、SQL*Plusセッションを開始し、SYSRACまたはSYSOPER権限で接続した後に、必要なコマンドを発行します。たとえば、ローカル・ノード上でインスタンスを起動しマウントする場合は、SQL*Plusセッション内で次のコマンドを実行します。

   CONNECT / AS SYSRAC
   STARTUP MOUNT

注意:

Oracle ASMディスク・グループを使用する場合、Oracle ASMインスタンスへの接続と管理には、SYSRAC権限ではなくSYSASM権限を使用します。

Oracle RAC環境でOracle ASMインスタンスを管理する場合は、SQL*Plusを使用しないことをお薦めします。Oracle Clusterwareは、必要に応じてOracle ASMインスタンスを自動的に管理します。手動操作が必要な場合は、それぞれのSRVCTLコマンドを使用します。

Oracle Net Servicesを使用して、単一のSQL*Plusセッションから複数のインスタンスを起動できます。Net Services接続文字列(通常は、tnsnames.oraファイルからのインスタンス固有の別名)を使用して、各インスタンスに順次接続します。

たとえば、ローカル・ノード上でSQL*Plusセッションを使用すると、インスタンスの個々の別名を使用して、各インスタンスに順次接続し、リモート・ノード上の2つのインスタンスのトランザクションの停止を実行できます。最初のインスタンスの別名をdb1、2つ目のインスタンスの別名をdb2と仮定します。次のコマンドを入力して、最初のインスタンスに接続してから停止します。

   CONNECT /@db1 AS SYSRAC
   SHUTDOWN TRANSACTIONAL

注意:

正しいインスタンスに接続するには、接続文字列で1つのインスタンスにのみ対応付けられた別名を使用する必要があります。サービスに接続するTNS別名を使用する接続文字列、または複数のIPアドレスを表示するOracle Netアドレスを使用する場合、停止する特定のインスタンスに接続できないことがあります。

次のコマンドを入力して、SQL*Plusセッションから2つ目のインスタンスに接続した後、停止します。

   CONNECT /@db2 AS SYSRAC 
   SHUTDOWN TRANSACTIONAL

SQL*Plusでは複数のインスタンスを同時に起動または停止することはできないため、単一のSQL*Plusコマンドでクラスタ・データベースのすべてのインスタンスを起動または停止することはできません。各インスタンスに順次接続し、起動および停止するスクリプトを作成することができます。ただし、インスタンスの追加または削除を行う場合は、このスクリプトを手動でメンテナンスする必要があります。

3.3 Oracle RACでのPDBの起動および停止

プラガブル・データベース(PDB)の管理には、非CDBを管理するために必要なタスクのごく一部が必要です。

Oracle RACベースのマルチテナント・コンテナ・データベース(CDB)の管理は、非CDBの管理にある程度似ています。違いは、ある管理タスクはCDB全体に適用され、ある管理タスクはrootにのみ適用され、ある管理タスクは特定のプラガブル・データベース(PDB)に適用されるということのみです。この一部のタスクでは、ほとんどがPDBおよび非CDBに対して同じです。ただし、PDBのオープン・モードを変更する場合など、いくつかの違いがあります。また、PDB管理者は、単一PDBの管理のみを行い、CDB内の他のPDBによる影響は受けません。

関連項目:

CDBおよびPDBの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

PDBがポリシー管理または管理者管理のいずれであるにもかかわらず、サービスを管理することによって、Oracle RACベースのCDB内のPDBを管理します。1つの動的データベース・サービスを各PDBに割り当てて、クラスタ化コンテナ・データベース内のインスタンスにわたってPDBの起動、停止および配置を調整します。

たとえば、prodというサーバー・プールにsparkというポリシー管理PDBを備えたraccontというCDBを所有している場合、次のコマンドを使用してplugというサービスをこのデータベースに割り当てます。

srvctl add service –db raccont –pdb spark –service plug –serverpool prod

サービスplugは、サーバー・プール内のすべてのノードにわたって均一に管理されます。同じサーバー・プールでこのサービスをシングルトン・サービスとして実行する場合は、前述のコマンドとともに-cardinality singletonパラメータを使用します。

PDB sparkを開くには、次のように、それぞれのサービスplugを起動する必要があります。

srvctl start service -db raccont -service plug

サービスを停止するには、plug:

srvctl stop service -db raccont -service plug

PDB sparkは、SQLコマンドALTER PLUGGABLE DATABASE PDB_NAME CLOSE IMMEDIATE;を使用してPDBを閉じるまで開いたままです。srvctl status serviceコマンドを使用すると、データベースのステータスを確認できます。

PDBは動的データベース・サービスを使用して管理されるため、通常のOracle RACベースの管理プラクティスが適用されます。したがって、サービスplugがONLINE状態で、このサービスをホストしているサーバー上でOracle Clusterwareが停止している場合、このサーバー上のOracle Clusterwareの再起動後に、サービスは元の状態にリストアされます。このようにして、PDBの起動は、他のOracle RACデータベースと同様に自動化されます。

注意:

SQL*Plusとは異なり、SRVCTLは全体としてクラスタ・データベース上で動作します。したがって、サービスが同時に複数のサーバー上で実行されるように定義され、クラスタの現行のステータスがこの配置を可能にしている場合、サービスを使用したPDBの起動は、クラスタ化されたCDBの複数のインスタンスに同時に適用されます。

3.4 インスタンスの実行の確認

データベース・インスタンスが使用可能であることを確認するには、Oracle Enterprise Manager、SRVCTLまたはSQL*Plusを使用します。

• インスタンスが実行中であることを確認するためのSRVCTLの使用

• インスタンスが実行中であることを確認するためのSQL*Plusの使用

関連項目:

Oracle Enterprise Managerを使用してOracle RACデータベース・インスタンスのステータスを表示する方法の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。

3.4.1 インスタンスが実行中であることを確認するためのSRVCTLの使用

SRVCTLを使用すると、特定のデータベースでインスタンスが実行中であることを確認できます。

次のコマンドは、mailというOracle RACデータベースのデータベース・インスタンスのステータスを確認するためのSRVCTLの使用例を示しています。

$ srvctl status database -db mail

このコマンドによって、次のような出力が返されます。

Instance mail1 is running on node betal011Instance mail2 is running on node betal010

また、次のようにして、割り当てられたサービスの可用性を確認することによって、クラスタ内でPDBが実行されているかどうかを確認できます。

$ srvctl status service -db db_unique_name -service service_name

3.4.2 インスタンスが実行中であることを確認するためのSQL*Plusの使用

SQL*Plusを使用すると、データベース・インスタンスが実行中であることを確認できます。

1. 任意のノードで、SQL*Plusプロンプトから、Net Services接続文字列(通常はtnsnames.oraファイルからのインスタンス固有の別名)を使用することによって、データベース・インスタンスに接続します。

   CONNECT /@db1 as SYSRAC
   

2. 次の文を使用して、V$ACTIVE_INSTANCESビューを問い合せます。

   CONNECT SYS/as SYSRAC
   Enter password: password
   SELECT * FROM V$ACTIVE_INSTANCES;

   次のような出力が表示されます。

   INST_NUMBER INST_NAME    
   -----------  ----------------- 
   1            db1-sun:db1  
   2            db2-sun:db2  
   3            db3-sun:db3  

次の表に、この例で出力される列を示します。

表3-2 V$ACTIVE_INSTANCES列の説明

列	説明
INST_NUMBER	インスタンス番号を識別します。
INST_NAME	ホスト名およびインスタンス名をhost_name:instance_nameとして識別します。

3.5 特定のクラスタ・インスタンス上でのセッションの終了

ALTER SYSTEM KILL SESSION文を使用して、特定のインスタンスのセッションを終了できます。

セッションが停止すると、セッションのアクティブ・トランザクションがロールバックされ、そのセッションが保持していたリソース(ロックやメモリー領域など)がただちに解放されて、他のセッションで使用可能になります。

ALTER SYSTEM KILL SESSION文を使用すると、Oracle RAC環境で厳密なアプリケーション品質保証契約を維持できます。多くの場合、品質保証契約は、指定された期限内にトランザクションを実行することを目的としています。Oracle RAC環境では、このためには、指定された期限内にインスタンスでトランザクションを終了し、別のインスタンスでトランザクションを再試行することが必要な場合があります。

注意:

当初アプリケーションがアプリケーション・コンティニュイティ対応の動的データベース・サービスを使用してデータベース・インスタンスに接続する場合、アプリケーション・コンティニュイティを使用して、トランザクションの取消しをユーザーから隠すことができます。

サービス・レベル管理に対してよりきめ細かいアプローチを求める場合、すべてのOracle RACベースのデータベースに対して、Oracle Database Quality of Service Management (Oracle Database QoS Management)を使用することをお薦めします。

セッションを終了するには、次の手順に従います。

1. GV$SESSION動的パフォーマンス・ビューのINST_ID列の値を問い合せ、どのセッションを終了するかを特定します。

2. ALTER SYSTEM KILL SESSIONを発行し、GV$SESSION動的パフォーマンス・ビューを使用して特定したセッションのセッション索引番号(SID)とシリアル番号を指定します。

   KILL SESSION 'integer1, integer2[, @integer3]'

   • integer1には、SID列の値を指定します。

   • integer2には、SERIAL#列の値を指定します。

   • オプションのinteger3には、強制終了するセッションが存在するインスタンスのIDを指定します。GV$表を問い合せると、インスタンスIDを見つけることができます。

   この文を使用するには、インスタンスでデータベースがオープン状態であり、integer3を指定しない場合には、セッションと終了するセッションが同じインスタンスにある必要があります。

完了する必要があるアクティビティ(リモート・データベースからの応答の待機やトランザクションのロールバックなど)がセッションで実行されている場合、Oracle Databaseはそのアクティビティが完了するのを待機し、セッションに終了のマークを付けてから、ユーザーに制御を戻します。待機が数分間続く場合、セッションに終了予定のマークが付けられ、セッションに終了予定のマークを付けたというメッセージとともにユーザーに制御が戻されます。アクティビティが完了すると、PMONバックグラウンド・プロセスによってセッションに終了のマークが付けられます。

セッションの特定および終了の例

次の例に、ユーザーが特定のセッションを特定し、終了する3つのシナリオを示します。各例で、SYSDBAは、まずSCOTTユーザーのセッションのGV$SESSIONビューを問い合せて終了するセッションを特定し、次に、ALTER SYSTEM KILL SESSION文を実行してインスタンスでセッションを終了します。

例3-1 ビジー状態のインスタンスでのセッションの特定および終了

この例で、実行しているセッションがインスタンスINST_ID=1のSYSDBAであるとします。一部のアクティビティを完了してからセッションを終了する必要があるため、ORA-00031メッセージが戻されます。

SQL> SELECT SID, SERIAL#, INST_ID FROM GV$SESSION WHERE USERNAME='SCOTT';

       SID    SERIAL#    INST_ID
---------- ---------- ----------
        80          4          2

SQL> ALTER SYSTEM KILL SESSION '80, 4, @2';
alter system kill session '80, 4, @2'
*
ERROR at line 1:
ORA-00031: session marked for kill
SQL>

例3-2 アイドル状態のインスタンスでのセッションの特定および終了

この例で、実行しているセッションがインスタンスINST_ID=1のSYSDBAであるとします。インスタンスINST_ID=2のセッションは、Oracle Databaseが60秒以内に文を実行すると、ただちに終了されます。

SQL> SELECT SID, SERIAL#, INST_ID FROM GV$SESSION WHERE USERNAME='SCOTT';
 
       SID    SERIAL#    INST_ID
---------- ---------- ----------
        80          6          2
 
SQL> ALTER SYSTEM KILL SESSION '80, 6, @2';

System altered.

SQL> 

例3-3 IMMEDIATEパラメータの使用

次の例には、未完了のアクティビティが完了するのを待機せずにただちにセッションを終了する、オプションのIMMEDIATE句が含まれています。

SQL> SELECT SID, SERIAL#, INST_ID FROM GV$SESSION WHERE USERNAME='SCOTT';
 
       SID    SERIAL#    INST_ID
---------- ---------- ----------
        80          8          2
 
SQL> ALTER SYSTEM KILL SESSION '80, 8, @2' IMMEDIATE;
 
System altered.
 
SQL> 

3.6 Oracle RACでの初期化パラメータ・ファイルの概要

データベースを作成すると、指定したファイルの位置にSPFILEが作成されます。Oracle ASMディスク・グループまたはクラスタ・ファイル・システムをこの場所に指定できます。手動でデータベースを作成する場合は、初期化パラメータ・ファイル(PFILE)からSPFILEを作成することをお薦めします。

注意:

Oracle RACで従来のPFILEが使用されるのは、SPFILEが存在しないか、STARTUPコマンドでPFILEを指定した場合のみです。管理の単純化、パラメータ設定の一貫性の維持、データベースの停止および起動イベント全体にわたるパラメータ設定の永続性の保証のために、SPFILEを使用することをお薦めします。さらにRMANを構成してSPFILEをバックアップできます。

クラスタ・データベース内のインスタンスはすべて、起動時に同じSPFILEを使用します。SPFILEはバイナリ・ファイルであるため、エディタを使用して直接編集しないでください。かわりに、Oracle Enterprise ManagerまたはSQL文ALTER SYSTEMを使用して、SPFILEパラメータ設定を変更します。

SPFILEの作成時に、FROM MEMORY句(CREATE PFILE FROM MEMORYやCREATE SPFILE FROM MEMORYなど)を含める場合、CREATE文では、現行のシステム全体のパラメータ設定を使用して、PFILEまたはSPFILEが作成されます。Oracle RAC環境では、作成されたファイルには各インスタンスからのパラメータ設定が含まれています。FROM MEMORY句では、パラメータ・ファイルを作成しようとしているインスタンスに他のすべてのインスタンスがパラメータ設定を送信する必要があるため、合計実行時間は、インスタンスの数、各インスタンスのパラメータ設定の数およびそれらの設定のデータ量によって異なります。

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

• Oracle RACのSPFILEパラメータ値の設定

• Oracle RACでのパラメータ・ファイルの検索順序

• サーバー・パラメータ・ファイルのバックアップ

3.6.1 Oracle RACのSPFILEパラメータ値の設定

SPFILEの設定は、Oracle Enterprise ManagerまたはALTER SYSTEM文のSET句を使用して変更できます。

注意:

Oracle Enterprise ManagerまたはSQL*Plus以外のツールでSPFILEを変更すると、ファイルが破損してデータベースを起動できなくなる可能性があります。ファイルを修復するにはPFILEを作成し、SPFILEを再生成する必要があります。

SPFILEはバイナリ・ファイルですが、この項の例では、ASCIIテキストとして記述してあります。次のエントリを含むSPFILEでインスタンスを起動するとします。

*.OPEN_CURSORS=500
prod1.OPEN_CURSORS=1000

SPFILEエントリのピリオド(.)の前にある値は、特定のパラメータの値が適用されるインスタンスを識別します。ピリオドの前にアスタリスク(*)がある場合、その値は、SPFILEに後続の個別の値が示されていないすべてのインスタンスに適用されます。

Oracleシステム識別子(SID)がprod1のインスタンスでは、データベース全体のパラメータが500に設定されていても、OPEN_CURSORSパラメータの設定は1000です。ワイルドカード文字のアスタリスク(*)が使用されたパラメータ・ファイルのエントリは、インスタンス固有のエントリがないインスタンスのみに適用されます。したがって、データベース管理者は、インスタンスprod1のパラメータ設定を制御できます。この2種類の設定は、パラメータ・ファイル内でいずれの順序でも指定できます。

別のDBAが次の文を実行した場合、SIDがprod1以外のすべてのインスタンスの設定がOracle Databaseによって更新されます。

ALTER SYSTEM SET OPEN_CURSORS=1500 sid='*' SCOPE=SPFILE;

これで、SPFILEにはOPEN_CURSORSの次のエントリが含まれます。

*.OPEN_CURSORS=1500
prod1.OPEN_CURSORS=1000

次の文を実行して、prod1を除くすべてのインスタンスのOPEN_CURSORSをデフォルト値にリセットします。

ALTER SYSTEM RESET OPEN_CURSORS SCOPE=SPFILE;

これで、SPFILEにはprod1の次のエントリのみが含まれます。

prod1.OPEN_CURSORS=1000

次の文を実行して、インスタンスprod1のみのOPEN_CURSORSパラメータをデフォルト値にリセットします。

ALTER SYSTEM RESET OPEN_CURSORS SCOPE=SPFILE SID='prod1';

3.6.2 Oracle RACでのパラメータ・ファイルの検索順序

Oracle Databaseでは、プラットフォームに応じてパラメータ・ファイルが特定の順序で検索されます。Oracle RACデータベースの場合、srvctl config databaseコマンドを使用すると、パラメータ・ファイルの場所を簡単に調べることができます。

LinuxおよびUNIXプラットフォームでは、検索順序は次のとおりです。

1. $ORACLE_HOME/dbs/spfilesid.ora

2. $ORACLE_HOME/dbs/spfile.ora

3. $ORACLE_HOME/dbs/initsid.ora

Windowsプラットフォームでは、検索順序は次のとおりです。

1. %ORACLE_HOME%\database\spfilesid.ora

2. %ORACLE_HOME%\database\spfile.ora

3. %ORACLE_HOME%\database\initsid.ora

注意:

すべてのインスタンスで同じファイルを使用する必要があり、すべてのインスタンスのSIDが異なっているため、デフォルトのSPFILE名は使用しないことをお薦めします。かわりに、Oracle ASMにSPFILEを格納します。SPFILEをクラスタ・ファイル・システムに格納する場合は、SPFILEに$ORACLE_HOME/dbs/spfiledb_unique_name.oraというネーミング規則を使用してください。SPFILE=ORACLE_HOME/dbs/spfiledb_unique_name.oraという名前を含む、$ORACLE_HOME/dbs/initsid.oraという名前のPFILEを作成してください。

3.6.3 サーバー・パラメータ・ファイルのバックアップ

リカバリのために、サーバー・パラメータ・ファイルを定期的にバックアップすることをお薦めします。

これには、Oracle Enterprise Manager(『Oracle Database 2日でReal Application Clustersガイド』を参照)またはCREATE PFILE文を使用します。次に例を示します。

CREATE PFILE='/u01/oracle/dbs/test_init.ora'
FROM SPFILE='/u01/oracle/dbs/test_spfile.ora';

Recovery Manager (RMAN)を使用して、サーバー・パラメータ・ファイルのバックアップを作成できます。SPFILEは、クライアント側の初期化パラメータ・ファイルを使用してインスタンスを起動することによって、リカバリすることもできます。その後、CREATE SPFILE文を使用して、サーバー・パラメータ・ファイルを再生成します。この操作に使用されるパラメータ・ファイルがシングル・インスタンス用である場合、Oracle RACインスタンスで一意であっても、パラメータ・ファイルにはインスタンス固有の値は含まれません。したがって、前述のようにパラメータ・ファイルに適切な設定が含まれていることを確認してください。

通常のバックアップ操作の実行中にSPFILE(および制御ファイル)が自動的にRMANによってバックアップされるようにするには、Oracle Enterprise ManagerまたはRMANのCONTROLFILE AUTOBACKUP文を使用して、RMANの自動バックアップ機能を使用可能にします。

3.7 Oracle RACでの初期化パラメータの使用

デフォルトでは、ほとんどのパラメータがデフォルト値に設定されていて、すべてのインスタンスで同じ値です。

ただし、多くの初期化パラメータに対しては、表3-3に記載されているとおり、各インスタンスで別々の値も設定できます。これ以外のパラメータは、次の項で説明されているように、一意または同一である必要があります。

• すべてのインスタンスで同じ値を設定する必要があるパラメータ

• すべてのインスタンスで一意の値を設定するパラメータ

• すべてのインスタンスで同じ値を設定する必要があるパラメータ

表3-3に、Oracle RACデータベースで特に使用される初期化パラメータのサマリーを示します。

表3-3 Oracle RACに固有の初期化パラメータ

パラメータ	説明
ACTIVE_INSTANCE_COUNT	この初期化パラメータは、Oracle RAC 11gリリース2 (11.2)で非推奨になりました。かわりに、1つの優先インスタンスと1つの使用可能なインスタンスを伴うサービスを使用します。
ASM_PREFERRED_READ_FAILURE_GROUPS	ミラー・データのコピーの読取り元の優先ディスクにする一連のディスクを指定します。このパラメータに設定する値はインスタンス固有で、すべてのインスタンスで同じにする必要はありません。
CLUSTER_DATABASE	クラスタ・モードで起動するデータベースを使用可能にするパラメータです。このパラメータをTRUEに設定します。
CLUSTER_DATABASE_INSTANCES	Oracle RACはこのパラメータを使用して、十分なメモリー・リソースを割り当てます。すべてのインスタンスに同じ値を設定する必要があります。 ポリシー管理データベースの場合、16が内部的に設定されます。 管理者管理データベースの場合、構成済のOracle RACインスタンスの数に内部的に設定されます。 また、インスタンスを追加する場合、現行のインスタンスの数より大きい値をこのパラメータに設定できます。ポリシー管理データベースで、このパラメータにより大きい値を設定する必要があるのは、16を超えるインスタンスでデータベースを実行する場合のみです。この場合、パラメータには、このデータベースを実行するインスタンスの予想最大数を設定します。
CLUSTER_INTERCONNECTS	複数のインターコネクトが存在する場合、プライベート・ネットワークの代替クラスタ・インターコネクトを指定します。 注意: すべてのOracle DatabaseとOracle Clusterwareでは同じインターコネクト・ネットワークを使用することをお薦めします。 特別な場合を除き、CLUSTER_INTERCONNECTSパラメータを設定することはお薦めしません。詳細は、「LinuxおよびUNIXプラットフォームでの複数のクラスタ・インターコネクトの管理」を参照してください。 このパラメータは、グリッドのプラグ・アンド・プレイ環境のグリッド・プラグ・アンド・プレイ・プロファイルに格納されます。
DB_NAME	インスタンス固有のパラメータ・ファイルでDB_NAMEの値を設定する場合は、すべてのインスタンスに同じ値を設定する必要があります。
DISPATCHERS	DISPATCHERSパラメータは、共有サーバー構成(多数のユーザー・プロセスが、非常に少数のサーバー・プロセスを共有できるように構成されたサーバー)を使用可能にするために設定します。共有サーバー構成では、多数のユーザー・プロセスがディスパッチャに接続します。DISPATCHERSパラメータには、多くの属性を含めることができます。 少なくとも、PROTOCOL属性およびLISTENER属性を構成することをお薦めします。PROTOCOLには、ディスパッチャ・プロセスがリスニングのエンド・ポイントを生成するネットワーク・プロトコルを指定します。LISTENERには、Oracle Net Servicesリスナーの別名を指定します。別名には、tnsnames.oraファイルなどのネーミング・メソッドを介して解決される名前を設定します。tnsnames.oraファイルには、ネット・サービス名が記述されています。このファイルは、クライアント、ノードおよびOracle Performance Managerノード上で必要になります。Oracle Enterprise Managerでは、Cloud Controlのクライアントでtnsnames.oraエントリは必要ありません。 DISPATCHERSパラメータとその属性の構成、および共有サーバーの構成の詳細は、『Oracle Database Net Services管理者ガイド』も参照してください。
GCS_SERVER_PROCESSES	この静的パラメータでは、Oracle RACインスタンスのグローバル・キャッシュ・サービス(GCS)のサーバー・プロセスの初期数を指定します。GCSプロセスでは、Oracle RACインスタンスのインスタンス間トラフィックのルーティングが管理されます。GCSサーバー・プロセスのデフォルト数は、最小が2で、システム・リソースに基づいて計算されます。CPUが1つのシステムでは、1つのGCSサーバー・プロセスがあります。CPUが2つから8つのシステムでは、2つのGCSサーバー・プロセスがあります。CPUが9つ以上あるシステムでは、GCSサーバー・プロセスの数は、CPUの数を4で割り、端数を切り捨てた数と同じになります。たとえば、CPUが10ある場合は10を4で割るため、システムには2つのGCSプロセスがあることになります。異なるインスタンスで、このパラメータを異なる値に設定できます。
INSTANCE_NAME	一意のインスタンス名を指定します。クライアントは、この名前を使用して、セッションをクラスタ内の特定のインスタンスに強制的に接続します。通常、INSTANCE_NAMEパラメータはdb_unique_name_instance_number(orcldb_2など)という形式になります。 注意: グリッドのプラグ・アンド・プレイ環境では、INSTANCE_NAMEパラメータは必須ではなく、指定しない場合はdb_unique_name_instance_numberがデフォルトになります。
RESULT_CACHE_MAX_SIZE	クラスタ化されたデータベースでは、すべてのインスタンスでRESULT_CACHE_MAX_SIZE=0を設定して結果キャッシュを無効にするか、またはすべてのインスタンスで0(ゼロ)以外の値を使用して結果キャッシュを有効にできます。結果キャッシュの有効と無効を切り替えるには、すべてのインスタンスを再起動する必要があります。 結果キャッシュの有効化: RESULT_CACHE_MAX_SIZEを0より大きい値に設定するか、またはパラメータを未設定のままにします。個々のインスタンスで異なるキャッシュのサイズを指定できます。 結果キャッシュの無効化: すべてのインスタンスでRESULT_CACHE_MAX_SIZE=0を設定すると、結果キャッシュが無効になります。結果キャッシュの無効化はクラスタ全体で行う必要があるため、いずれか1つのインスタンスの起動時にRESULT_CACHE_MAX_SIZE=0を設定した場合は、すべてのインスタンスで起動時にパラメータを0(ゼロ)に設定する必要があります。一部のインスタンスで結果キャッシュを無効にすると、誤った結果になる場合があります。 RESULT_CACHE_MAX_SIZEパラメータを設定しない場合、パラメータはデフォルトの0(ゼロ)以外の値に解決されます。
SERVICE_NAMES	サービスを使用する場合は、SERVICE_NAMESパラメータに値を設定せずに、かわりに、Oracle Enterprise Manager Cloud Controlのクラスタ管理サービス・ページで、クラスタ管理されるサービスを作成する必要があります。これは、Oracle Clusterwareが、ユーザーが作成したサービスおよびデフォルトのデータベース・サービスのこのパラメータの設定を制御するためです。「動的データベース・サービスによるワークロード管理」で説明するサービスの機能は、SERVICE_NAMESを設定する場合に使用可能な機能とは直接関係ありません。また、このパラメータに値を設定した場合、サービスの使用によって得られるメリットが失われてしまう可能性があります。 注意: クライアント接続ではインスタンス名ではなくサービスを使用することをお薦めします。SERVICE_NAMESパラメータのエントリは、INSTANCE_NAMEパラメータの値ではなく、クライアント接続で使用される場合があります。SERVICE_NAMESパラメータに1つ以上の名前が含まれ、異なるインスタンスで1つ以上の名前を共有する場合があるため、クライアントは、接続文字列で選択されたサービス名に応じて、特定のインスタンスまたは一連のいずれかのインスタンスに接続できます。
SPFILE	SPFILEを使用する場合は、Oracle RACデータベースのすべてのインスタンスがSPFILEを使用し、このファイルが共有記憶域に存在する必要があります。
THREAD	インスタンスで使用されるREDOスレッドの数を指定します。使用可能な未使用のREDOスレッド番号であれば、どれでも指定できます。指定する場合、このパラメータの値はすべてのインスタンスに対して一意である必要があります。INSTANCE_NAMEパラメータを使用してREDOログ・グループを指定することをお薦めします。

3.7.1 すべてのインスタンスで同じ値を設定する必要があるパラメータ

データベースの作成に重要な特定の初期化パラメータ、または特定のデータベース操作に影響する特定の初期化パラメータは、Oracle RACデータベースの各インスタンスで同じ値を設定する必要があります。これらのパラメータ値は、SPFILEに指定するか、または各インスタンスの個別のPFILEで指定します。次のリストに、すべてのインスタンスで同一である必要があるパラメータを示します。

• COMPATIBLE
• CLUSTER_DATABASE
• CONTROL_FILES
• DB_BLOCK_SIZE
• DB_DOMAIN
• DB_FILES
• DB_NAME
• DB_RECOVERY_FILE_DEST
• DB_RECOVERY_FILE_DEST_SIZE
• DB_UNIQUE_NAME
• INSTANCE_TYPE (RDBMSまたはASM)
• PARALLEL_EXECUTION_MESSAGE_SIZE
• REMOTE_LOGIN_PASSWORDFILE
• UNDO_MANAGEMENT

すべてのインスタンスで、次のパラメータを同じにする必要があるのは、パラメータの値が0(ゼロ)に設定されている場合のみです。

• DML_LOCKS
• RESULT_CACHE_MAX_SIZE

3.7.2 すべてのインスタンスで一意の値を設定するパラメータ

ポリシー管理データベースで一意の設定を持つパラメータを設定する必要がある場合は、データベースのサーバー・プールに割り当てられる各サーバーに対してsrvctl modify instance -n node_name -i instance_nameコマンドを実行することにより、インスタンスが特定のノードで常に同じ名前を使用するようにできます。その後、パラメータの一意の値をinstance_nameに指定できます(この値は、node_name上でデータベースが実行されるときに使用されます)。

データベース名と、インスタンスに割り当てられたINSTANCE_NAME番号で構成される環境変数ORACLE_SIDを指定します。

CLUSTER_INTERCONNECTS初期化パラメータを使用して、Oracle Clusterwareがプライベート・ネットワークに使用している代替インターコネクトを指定します。CLUSTER_INTERCONNECTS初期化パラメータを設定すると、Oracle RACデータベースの各インスタンスに対して一意の値が使用されます。

Oracle Databaseは、INSTANCE_NUMBERパラメータを使用して起動時にインスタンスを識別し、INSTANCE_NAMEパラメータを使用して特定のインスタンスにREDOログ・グループを割り当てます。インスタンス名はdb_unique_name_instance_numberの形式にすることが可能で、名前と番号がアンダースコアで区切られたこの形式の場合、アンダースコアの後の番号がINSTANCE_NUMBERとして使用されます。グリッドのプラグ・アンド・プレイを使用するOracle Database 11.2では、ポリシー管理データベースのインスタンス番号を明示的に割り当てる必要がなくなり、インスタンス名はデフォルトのdb_unique_name_instance_numberに設定され、Oracle Databaseによってインスタンス番号が割り当てられます。

自動UNDO管理を使用可能にしてUNDO_TABLESPACEを指定する場合、各インスタンスでこのパラメータに一意のUNDO表領域名を設定します。

ROLLBACK_SEGMENTSパラメータを使用する場合は、SPFILEでSID識別子を使用して、これらのパラメータに一意の値を設定することをお薦めします。ただし、各インスタンスのINSTANCE_NUMBERに一意の値を設定する必要があり、デフォルト値は使用できません。

ASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータを使用すると、優先読取り障害グループ名のリストを指定できます。これらの障害グループのディスクは、優先読取りディスクになります。したがって、すべてのノードはそのローカル・ディスクから読み取ることができます。この結果、効率およびパフォーマンスが向上し、ネットワーク・トラフィックが削減されます。このパラメータの設定はインスタンス固有で、すべてのインスタンスで同じにする必要はありません。

3.7.3 すべてのインスタンスで同じ値を設定する必要があるパラメータ

ここにリストされているパラメータをすべてのインスタンスで同じ設定にすることをお薦めします。

表3-4のパラメータには、すべてのインスタンスで同じ値を設定することをお薦めします。これらのパラメータにはインスタンスごとに異なる値を設定できますが、すべてのインスタンスでパラメータに同じ値を設定すると管理が簡単です。

表3-4 すべてのインスタンスで同じ値を設定する必要があるパラメータ

パラメータ	説明
ARCHIVE_LAG_TARGET	Oracle RACデータベースのインスタンスごとに異なる値を設定すると、データベース処理によって追加の自動同期化が実行されるため、多くの場合、オーバーヘッドが増加します。 Oracle RACデータベースのダウンストリーム取得構成で、Oracle Streamsダウンストリーム取得またはOracle GoldenGate統合取得モードを使用する場合、値は0 (ゼロ)より大きい必要があります。
CLUSTER_DATABASE_INSTANCES	このパラメータについては、すべてのOracle RACデータベース・インスタンスで同一の設定であることが望まれますが、これは必須ではありません。
LICENSE_MAX_USERS	このパラメータでは、データベースに定義されるユーザー数のデータベース全体における制限が決定されるため、このパラメータにはデータベースのすべてのインスタンスに同じ値を指定して、どのインスタンスの使用時にも現在の値を確認できるようにすると便利です。異なる値を設定すると、インスタンスの起動時にOracle Databaseによって追加で警告メッセージが生成されたり、データベース・ユーザーの管理に関連するコマンドが一部のインスタンスで失敗する可能性があります。
LOG_ARCHIVE_FORMAT	すべてのインスタンスで同じ値を使用しない場合、メディア・リカバリが複雑になります。アーカイブ・ログ・ファイルを作成したインスタンスにかかわらず、リカバリを行うインスタンスでは、必要なアーカイブ・ログ・ファイル名のフォーマットがそのインスタンス自体のLOG_ARCHIVE_FORMATの値で定義されていると想定します。 Oracle Data Guardをサポートするデータベースでは、アーカイブREDOログ・ファイルの送受信を行うために、すべてのインスタンスでLOG_ARCHIVE_FORMATに同じ値を使用する必要があります。
SPFILE	すべてのインスタンスでこのパラメータに同じファイルを指定しない場合、各インスタンスは、フェイルオーバー、ロード・バランシングおよび通常の操作中に、異なる動作または予測できない動作を行う場合があります。また、ALTER SYSTEM SETまたはALTER SYSTEM RESETコマンドでSPFILEに行う変更は、コマンドを実行したインスタンスで使用されるSPFILEのみに保存されます。加えた変更は、別のSPFILEが使用されるインスタンスには反映されません。 サーバーによって値が設定されているインスタンスでSPFILEの値が異なる場合、デフォルトのSPFILEを使用していないインスタンスを再起動する必要があります。
TRACE_ENABLED	診断トレース情報をOracle RACデータベースで常に使用可能にするには、すべてのデータベース・インスタンスでTRACE_ENABLEDをTRUEに設定する必要があります。一部のインスタンスのみのトレースを行う場合、TRACE_ENABLEDがFALSEに設定されているインスタンスのみにアクセス可能なとき、必要な診断情報を使用できない場合があります。
UNDO_RETENTION	各インスタンスでUNDO_RETENTIONに異なる値を設定すると、スケーラビリティが低下し、フェイルオーバー後に予測できない動作が行われる場合があります。したがって、このパラメータにOracle RACデータベースのインスタンス間で異なる値を割り当てる前に、メリットがあるかどうかを慎重に考慮する必要があります。

3.8 管理者管理データベースのポリシー管理データベースへの変換

管理者管理データベースをポリシー管理データベースに変換できます。

注意:

管理者管理データベースが権限の弱いユーザー用に構成されており、このデータベースをポリシー管理データベースに変換しようとする場合は、この権限の弱いユーザーにウォレットを(まだ存在しない場合)手動で追加し、Oracle Database用のWindowsサービスを作成できるようにする必要があります。

管理者管理データベースを変換するには、次の手順を実行します。

1. すべてのサービスとデータベースの現在の構成を確認します(間違いがあったためにリカバリが必要な場合、元の構成がどうであったかを確認できます)。

   srvctl config database -db db_unique_name
   srvctl config service -db db_unique_name

2. ポリシー管理データベース用のサーバー・プールを作成します(これを実行するには、クラスタ管理者である必要があります)。

   srvctl add srvpool -serverpool server_pool -min 0 -max n

   前述のコマンドでは、0 (ゼロ)はサーバー・プールで希望するサーバーの最小数で、nは最大数です。

   注意:

   この手順では、必ずしも新しく作成したサーバー・プールにサーバーを配置するとはかぎりません。たとえば、新しいサーバー・プールがサーバーを割り当てることができる元の空きプールにサーバーがない場合は、変換が完了したときに、srvctl relocate serverコマンドを使用して別のサーバー・プールからサーバーを再配置する必要がある可能性があります。

3. 次のようにOracle Enterprise ManagerまたはSRVCTLを使用して、データベースを停止します。

   srvctl stop database -db db_unique_name

4. 新しいサーバー・プールに存在するようにデータベースを変更します。

   srvctl modify database -db db_unique_name -serverpool server_pool

5. 次のように、サービス・ユーザーをウォレットに追加します。

   crsctl add wallet -type OSUSER -user user_name -passwd

6. 手順1のコマンドを繰り返してデータベースのステータスを確認し、データベースがポリシー管理になったことを確認します。

次のように、前述の手順で行った変更を認識させるために、Oracle Enterprise Managerを構成します。

1. Oracle Enterprise Manager Cloud Controlに新しいデータベース・インスタンスを認識させるために、インスタンス名をdb_unique_name#からdb_unique_name_#に変更(シャープ記号(#)の前にアンダースコア(_)を追加)する必要があります。

2. dbs/databaseディレクトリ内のorapwdファイルの名前を変更します(または、orapwdコマンドを実行して、新しいorapwdファイルを作成します)。

   デフォルトのorapwdファイルには、orapwdORCL1などのようにインスタンス名が付加されています。前述の手順で変更したインスタンス名に対応するように、ファイル名を変更する必要があります。たとえば、orapwdORCL1をorapwdORCL_1に変更するか、または新しいorapwdファイルを作成する必要があります。

ポリシー管理データベースを管理者管理データベースに直接変換することはできません。その場合は、srvctl remove databaseコマンドおよびsrvctl remove serviceコマンドでポリシー管理構成を削除してから、srvctl add databaseコマンドおよびsrvctl add instanceコマンドで同じデータベースを管理者管理データベースとして登録します。データベースおよびインスタンスの登録後に、srvctl add serviceコマンドを使用して、削除したサービスを元どおりに追加する必要があります。

管理者管理データベースのサービスは、引き続きPREFERREDおよびAVAILABLE定義によって定義されます。ポリシー管理データベースの場合、サービスはデータベース・サーバー・プールに対して定義され、uniform(サーバー・プール内のすべてのインスタンスで実行)またはsingleton(サーバー・プール内の単一インスタンスでのみ実行)のいずれかになります。データベースの管理ポリシーを変更した場合、選択したデータベースの管理ポリシーに応じて、UNIFORMかSINGLETON、またはPREFERRED/AVAILABLEのいずれかになるように、データベース・サービスを再作成する必要があります。

3.9 データベース・サーバーのメモリー不足の管理

オープン・セッションまたはランナウェイ・ワークロードが多すぎるため、エンタープライズ・データベース・サーバーが使用可能メモリーをすべて使用することがあります。メモリーが不足すると、トランザクションが失敗することがあります。極端な場合には、サーバーが再起動し、アプリケーションの貴重なリソースが失われることもあります。Memory Guardは、サーバー上のメモリー不足をリアルタイムで検出し、新しいセッションを他のサーバーにリダイレクトして、メモリーが不足しているサーバー上のすべての使用可能メモリーが使用されることを防ぎます。

Oracle Database QoS Managementが有効になっていて、Oracle Clusterwareサーバー・プールを管理している場合、Cluster Health Monitorは、クラスタ・サーバーのメモリー・リソースに関するリアルタイム情報を提供するメトリック・ストリームをMemory Guardに送信します。この情報の内容は次のとおりです。

• 使用可能メモリーの量

• 現在使用されているメモリーの量

ノードのメモリーが不足しているとMemory Guardが判断した場合は、新しい接続が作成されないように、そのノード上のOracle Clusterwareで管理されているデータベース・サービスが停止されます。メモリー不足が緩和されると、そのノードのサービスが自動的に再開し、リスナーはそのサーバーへの新規接続の送信を開始します。メモリー不足は、いくつかの方法で緩和できます(たとえば、既存のセッションの終了やユーザーの介入など)。

新しいセッションを別のサーバーに再ルートすると、メモリーが不足しているサーバー上の既存のワークロードが保護され、サーバーを使用可能な状態に保つことができます。Memory Guardはサーバーのメモリー不足を管理するOracle RACの機能で、Oracle RACデータベースにホストされているアプリケーションのサービス・レベルの管理に新しいリソース保護機能を追加します。

3.10 Oracle RACデータベースの静止

Oracle RACデータベースを静止する手順は、非クラスタ・データベースを静止する場合と同じです。

1つのインスタンスからALTER SYSTEM QUIESCE RESTRICTED文を使用します。データベースの静止処理中は、どのインスタンスからもデータベースを開くことはできません。DBA以外のすべてのセッションが非アクティブになると、ALTER SYSTEM QUIESCE RESTRICTED文は終了し、データベースは静止状態にあるとみなされます。Oracle RAC環境では、この文を発行したインスタンスのみでなく、すべてのインスタンスにこの文が適用されます。

Oracle RAC環境でALTER SYSTEM QUIESCE RESTRICTED文を正しく発行するには、データベース・リソース・マネージャ機能をアクティブにしておくだけでなく、その機能がクラスタ・データベースのすべてのインスタンスに対しても、インスタンス起動時からアクティブになっている必要があります。DBA以外のセッションがアクティブにならないようにするのは、データベース・リソース・マネージャの機能です。また、この文が適用されている間に現行のリソース・プランを変更しようとすると、システムが静止状態でなくなるまで、その変更はキューに入れられます。

次の条件がOracle RACに適用されます。

• ALTER SYSTEM QUIESCE RESTRICTED文を発行しても、Oracle Databaseがその処理を完了していない場合、データベースを開くことはできません。

• データベースが静止状態にある場合、そのデータベースを開くことはできません。

• ALTER SYSTEM QUIESCE RESTRICTED文およびALTER SYSTEM UNQUIESCE文は、このコマンドを発行したインスタンスのみでなく、Oracle RAC環境のすべてのインスタンスに適用されます。

注意:

コールド・バックアップを実行するために静止状態を使用することはできません。データベースが静止状態にある場合でも、Oracle Databaseのバックグラウンド・プロセスがOracle Databaseの内部処理のために更新を実行していることがあるためです。また、オンライン・データファイルのヘッダーは、引き続きアクセス中であるかのように見えます。このファイル・ヘッダーの状態は、データベースが正しく停止された場合とは異なります。データベースが静止状態の間でも、オンライン・バックアップ操作は実行できます。

3.11 LinuxおよびUNIXプラットフォームでの複数のクラスタ・インターコネクトの管理

LinuxおよびUNIXプラットフォームで実行されるOracle RAC環境では、CLUSTER_INTERCONNECTS初期化パラメータを使用して、Oracle Clusterwareがプライベート・ネットワーク用に使用しているものの代替インターコネクトを指定できます。

注意:

CLUSTER_INTERCONNECTS初期化パラメータは、冗長インターコネクトの使用によって提供されている高可用性IP (HAIP)アドレスに設定しないでください。HAIPは自動的に認識されます。

CLUSTER_INTERCONNECTSに複数の値を設定する場合、Oracle Databaseは、インターコネクトに指定するすべてのネットワーク・インタフェースを使用し、表示されているすべてのインターコネクトが動作している場合はロード・バランシングを提供します。このパラメータで複数のインターコネクトを定義する場合、データベースのすべてのインスタンスで同じ値(インターコネクトをリストする順序を含む)を使用する必要があります。

注意:

オペレーティング・システム・レベルでデフォルトのインターコネクト設定を上書きするCLUSTER_INTERCONNECTS初期化パラメータを設定することはお薦めしません。

かわりに、ベスト・プラクティスは、Oracle RACおよびOracle Real Application Clusters One Node 11gリリース2 (11.2)データベース以上向けのOracle Grid Infrastructure 11gリリース2 (11.2)で使用可能な冗長インターコネクトの使用を使用することです。Oracle Database 11gリリース2 (11.2)より前のデータベースの場合、オペレーティング・システムベースのネットワーク・ボンディング・テクノロジを使用して、クラスタ・インターコネクトとして使用するつもりのネットワーク・インタフェース・カード向けの高可用性(およびロード・バランシング)を可能にします。1つのクラスタ内で複数のデータベース・バージョンを使用する場合は、両方の手法を組み合せることができます。冗長インターコネクトの使用では、結合にかかわらず、オペレーティング・システム・レベルで提示されるインタフェースを使用します。結合テクノロジの詳細は、オペレーティング・システムのベンダーに問い合せてください。

3.11.1 CLUSTER_INTERCONNECTSパラメータを使用するためのユース・ケース

CLUSTER_INTERCONNECTS初期化パラメータでは、IPアドレスが必要です。コロン(:)で区切って、複数のIPアドレスを指定できます。Oracle RACネットワーク・トラフィックは、指定されたIPアドレス間で分散されます。

注意:

• ポリシー管理データベースを使用する場合、CLUSTER_INTERCONNECTSパラメータは設定しないことをお薦めします。

• すべてのデータベースとOracle Clusterwareで同じインターコネクト・ネットワークを使用することをお薦めします。

一般に、CLUSTER_INTERCONNECTSパラメータは、次の場合にのみ設定します。

• クラスタで複数のデータベースが実行され、インターコネクト・トラフィックを分離する必要があり、冗長インターコネクトの使用を使用しない場合。

• オペレーティング・システムによって高可用性が実現された単一のIPアドレスがあり、そのIPアドレスに安定したインタフェース名がない(再起動時に名前を変更できるなど)場合。

次の一般的な構成では、CLUSTER_INTERCONNECTSパラメータは設定しないでください。

• 冗長インターコネクトの使用を使用する場合。

• クラスタ・インターコネクトが1つのみ存在する場合。

• デフォルトのクラスタ・インターコネクトが、Oracle RACデータベースの帯域幅の要件を満たしている場合(通常は満たしています)。

CLUSTER_INTERCONNECTS初期化パラメータの指定時は、次のことに注意してください。

• CLUSTER_INTERCONNECTS初期化パラメータは、UDP IPCが使用可能なLinuxおよびUNIX環境でのみ有効です。

• パラメータ・ファイルでCLUSTER_INTERCONNECTS初期化パラメータを設定する場合は、Oracle RACデータベースの各インスタンスに対して異なる値を指定します。

• 異なるノードで、同じデータベースの異なるインスタンスに指定されたIPアドレスは、同一のインターコネクト・ネットワークに接続するネットワーク・アダプタに属する必要があります。

• このパラメータに対して複数のIPアドレスを指定する場合、同一データベースのすべてのインスタンスに対して、同じ順序でIPアドレスを指定します。たとえば、node1の最初のインスタンスのパラメータで、alt0:、fta0:およびics0:デバイスのIPアドレスをその順に指定する場合、node2の2つ目のインスタンスのパラメータでも同等のネットワーク・アダプタのIPアドレスをその順に指定する必要があります。

• CLUSTER_INTERCONNECTSパラメータに指定したインターコネクトへの書込み中にオペレーティング・システム・エラーが発生した場合は、他のインタフェースが使用可能な場合でも、Oracle Databaseによってエラーが戻されます。これは、Oracle Databaseとインターコネクトの間の通信プロトコルが、使用しているプラットフォームに大きく依存する場合があるためです。詳細は、ご使用のOracle Databaseのプラットフォーム固有のマニュアルを参照してください。

例

単一のクラスタ・インターコネクトで帯域幅の要件を満たすことができない場合は、CLUSTER_INTERCONNECTSの設定を考慮します。冗長インターコネクトの使用を使用できない1つ以上のデータベースから高いインターコネクト帯域幅を要求されているデータ・ウェアハウス環境では、このパラメータの設定が必要な場合があります。

たとえば、高いインターコネクト帯域幅の要件を持つ2つのデータベースがある場合は、オペレーティング・システムが提供するデフォルトのインターコネクトを無効にし、各サーバー・パラメータ・ファイルで次の構文を使用して、各データベースに異なるインターコネクトを指定できます。ipnは、ドットで区切られた標準的な10進形式のIPアドレス(たとえば、144.25.16.214)です。

Database One: crm1.CLUSTER_INTERCONNECTS = ip1
Database Two: ext1.CLUSTER_INTERCONNECTS = ip2

高い帯域幅を必要とするデータベースがある場合は、次の構文を使用して複数のインターコネクトを指定できます。

CLUSTER_INTERCONNECTS = ip1:ip2:...:ipn

3.12 Oracle ClusterwareでのOracle RACデータベースの管理方法のカスタマイズ

これらの例は、Oracle ClusterwareによるOracle RACデータベースに対する制御を最小化するために使用します(アップグレード中に必要となる可能性があります)。

デフォルトでは、Oracle ClusterwareによってOracle RAC環境のデータベースの再起動が制御されます。たとえば、データベースのアップグレード中など、場合によっては、Oracle ClusterwareのOracle RACデータベースに対する制御レベルを最小限に抑える必要があることがあります。

注意:

サード・パーティのクラスタウェアを使用する場合は、Oracle Clusterwareを使用してOracle RACインスタンスを管理することをお薦めします。インスタンスを手動に設定し、そのインスタンスをサード・パーティのクラスタウェアで起動する場合は、データベース・インスタンスの監視および再起動にサード・パーティのクラスタウェアを使用しないでください。Oracle Clusterwareがこれを行う必要があるためです。

システムの再起動時にOracle ClusterwareによるOracle RACデータベースの再起動を防止する場合、または障害が発生したインスタンスの2回目以降の再起動を回避する場合、制御の程度を定義する管理ポリシーを構成します。管理ポリシーには、AUTOMATIC (デフォルト)とMANUALの2つがあります。管理ポリシーをAUTOMATICに設定すると、データベースは、データベース・ホスト・コンピュータの再起動時に、前回の実行状態(起動または停止)に自動的にリストアされます。MANUALの場合、データベースは、データベース・ホスト・コンピュータの再起動時に、自動的に再起動されることはありません。MANUALに設定しても、Oracle Restartは、実行中のデータベースを監視し、障害発生時にデータベースを再起動します。

SRVCTLコマンドを使用して、次の例に示すとおり、Oracle Clusterwareの管理ポリシーを表示および変更します。

例1: 現行管理ポリシーの表示

次のコマンド構文を使用して、現行の管理ポリシーを表示します(ここで、db_unique_nameは、管理ポリシーを変更するデータベースの名前です)。

srvctl config database -db db_unique_name -all

例2: 現行の管理ポリシーの別の管理ポリシーへの変更

次のSRVCTLコマンド構文を使用して、現行の管理ポリシーをAUTOMATIC、MANUALまたはNORESTARTに変更します。

srvctl modify database -db db_unique_name -policy [AUTOMATIC | MANUAL | NORESTART]

このコマンド構文は、データベース・リソースのリソース属性を設定します。

例3: 新規データベース用の管理ポリシーの指定

srvctl add databaseコマンドを使用して新しいデータベースを追加する場合、次の例のように-policyパラメータを使用して管理ポリシーをAUTOMATIC、MANUALまたはNORESTARTのいずれかに指定できます(ここで、db_unique_nameはデータベース名です)。

srvctl add database -db db_unique_name -policy [AUTOMATIC | MANUAL | NORESTART]
   -oraclehome $ORACLE_HOME -dbname DATA

このコマンド構文によって、新しいデータベースがOracle Clusterwareに制御されるようになります。管理ポリシー・オプションを指定しない場合、Oracle Databaseによってデフォルト値automaticが使用されます。管理ポリシーを変更した後、Oracle Clusterwareリソースは、影響を受けたデータベースの新しい値を記録します。

3.13 Oracle Enterprise Managerの高度な管理

Oracle Enterprise Manager Cloud Controlを使用すると、Oracle RACデータベースのインストール、構成および監視を単一の場所で実行できます。

この項では、『Oracle Database 2日でReal Application Clustersガイド』や「Oracle RACデータベースの監視およびチューニングの概要」で取り上げられていない高度な管理タスクについて説明します。

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

• ノードおよびインスタンスの検出のためのOracle Enterprise Manager Cloud Controlの使用

• Oracle Enterprise Managerのその他の機能

• Oracle RACでのジョブおよびアラートの管理

3.13.1 ノードおよびインスタンスの検出のためのOracle Enterprise Manager Cloud Controlの使用

Oracle Enterprise ManagerでOracle RACデータベースおよびインスタンス・ターゲットを検出すると、監視および管理を実行できます。

Oracle Enterprise Manager Cloud Controlでは、Oracle Enterprise Managerコンソール・インタフェースを使用してOracle RACデータベースおよびインスタンス・ターゲットを検出できます。

Oracle RACデータベースが存在するクラスタにOracle Enterprise Manager Cloud Controlエージェントをインストールすると、Oracle RACデータベース・ターゲットはインストール時に検出されます。エージェントのインストール後にデータベースが作成される場合またはエージェントのインストール時にデータベースが自動的に検出されない場合は、コンソール・インタフェースを使用してターゲットを検出できます。

ノードおよびインスタンスを検出するには、次のようにOracle Enterprise Manager Cloud Controlを使用します。

1. Oracle Enterprise Managerにログインし、「ターゲット」タブをクリックします。

2. 「データベース」タブをクリックすると、使用可能なターゲットがすべて表示されます。「タイプ」列に、「クラスタ・データベース」というエントリを使用するOracle RACデータベースが表示されます。

3. ターゲット名を選択して「追加」をクリックし、このデータベース・ターゲットを追加します。「データベースターゲットの追加: ホストの指定」ページが表示されるので、このページで、データベース、リスナーおよびOracle ASMを監視ターゲットとして追加できます。

4. 懐中電灯のアイコンをクリックして使用可能なホスト名を表示し、ホストを選択して「続行」をクリックします。「データベースの追加: ソースの指定」ページが表示されます。

5. Oracle Enterprise Managerを使用して非クラスタのデータベースおよびリスナーのみを検出するか、またはすべてのクラスタ・データベース、非クラスタのデータベースおよびクラスタのリスナーを検出するかを指定し、「続行」をクリックします。

6. この手順で、再構成したクラスタ・データベースおよびそのすべてのインスタンスが検出されなかった場合は、「クラスタでターゲットが検出されました」ページでクラスタ・データベースおよび非クラスタ・データベースを手動で構成できます。

3.13.2 Oracle Enterprise Managerのその他の機能

この項では、Oracle Enterprise Manager 12cとともに使用できるOracle Enterprise Managerの機能について説明します。

• Oracle Grid Infrastructure/Oracle RACプロビジョニング・デプロイメント・プロシージャでは、Oracle RAC 12cおよびOracle Grid Infrastructureをプロビジョニングします。また、この手順では、プロファイルと呼ばれる機能があり、入力を記録しておいて、その後に繰り返されるデプロイメントでこの記録を使用できます。

• 新しい手順の動的前提条件では、My Oracle Support(以前のOracleMetaLink)に接続されていれば、Oracle Enterprise ManagerはOracle RACプロビジョニング用の最新の前提条件とツールをダウンロードできます。

• 既存の「ワンクリックでクラスタ・データベース拡張」機能は、現在、Oracle RAC 12cスタックをサポートしています。

• 既存の「Oracle Real Application Clustersの削除/縮小」機能は、Oracle RAC 12cのクラスタで動作が保証されています。

• 既存の「Oracleデータベースのプロビジョニング」手順は、現在、Oracle Database 12cのシングル・インスタンスのプロビジョニングをサポートしています。

• 非クラスタ・データベース用のOracle Grid Infrastructure 12cをプロビジョニングするために、新しいデプロイメント手順(「スタンドアロン・サーバー用のOracle Grid Infrastructureのプロビジョニング」)が導入されました。

3.13.3 Oracle RACでのジョブおよびアラートの管理

クラスタ・データベースの「ホーム」ページには、Oracle RACデータベースのすべてのインスタンスが表示され、サーバー管理のために自動ワークロード・リポジトリ(AWR)が収集するいくつかのOracle RAC固有の統計の集計が提供されます。

その詳細を表示するために、インスタンス固有のページに移動する必要はありません。ただし、クラスタ・データベースの「ホーム」ページでは、稼働しているはずのインスタンスが停止したり、インスタンスで多数のアラートが発生している場合は、各アラートについてインスタンス固有のページにドリルダウンできます。

この項で後述する管理タスクを実行するには、ターゲットOracle RACデータベースにログインし、クラスタ・データベースの「ホーム」ページに移動し、「管理」タブをクリックします。

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

• Oracle RACでのジョブの管理

• Oracle Enterprise Managerを使用したOracle RACでのアラートの管理

• Oracle Enterprise Managerでの定義済ブラックアウトの使用

3.13.3.1 Oracle RACでのジョブの管理

Oracle Enterprise Managerジョブは、データベース・レベルでもインスタンス・レベルでも管理できます。たとえば、クラスタ・データベース・レベルでジョブを作成し、そのジョブをターゲットOracle RACデータベースのアクティブな任意のインスタンスで実行できます。または、インスタンス・レベルでジョブを作成し、それを作成した特定のインスタンスでのみ実行することもできます。障害が発生した場合、再起ジョブは障害が発生しなかったインスタンスで実行できます。

ジョブは、インスタンス・レベル、クラスタ・レベルまたはクラスタ・データベース・レベルで作成できるため、クラスタ・データベース内の使用可能ないずれのホストでもジョブを実行できます。これはスケジュールされるジョブにも適用されます。Oracle Enterprise Managerでは、ジョブ・アクティビティがActive、History、Libraryなどのカテゴリに分類されて表示されます。

オペレーティング・システムのスクリプトやSQLスクリプトの送信およびスケジュールされたジョブの調査には、「ジョブ」タブを使用します。たとえば、特定のOracle RACデータベースのためのバックアップ・ジョブの作成は、次のように行います。

1. 「ターゲット」をクリックし、ジョブを作成するデータベースをクリックします。

2. ターゲット・データベースにログインします。

3. 表示されたデータベースの「ホーム」ページで、「メンテナンス」をクリックします。

4. Enterprise Managerのジョブ・ウィザードの各ページに入力し、ジョブを作成します。

3.13.3.2 Oracle Enterprise Managerを使用したOracle RACでのアラートの管理

Oracle Enterprise Managerを使用して、Oracle RAC環境のアラートを構成できます。

また、グローバル・キャッシュ変換、読取り一貫性要求など、Oracle RACデータベースの特殊なテストも構成できます。

Oracle Enterprise Managerでは、Oracle RAC環境のデータベース・レベルとインスタンス・レベルのアラートは区別されます。アーカイブ・ログ・アラートなど、インスタンス・レベル・アラートのアラートしきい値は、インスタンスのターゲット・レベルで設定できます。この機能により、パフォーマンスがしきい値を超えた場合、特定のインスタンスに関するアラートを受信できます。また、表領域に関するアラートの設定など、データベース・レベルでアラートを構成することもでき、各インスタンスで重複するアラートの受信を回避できます。

関連項目:

Oracle RACでのアラートの構成の例は、Oracle Technology Networkを参照してください。パッケージを使用してしきい値を構成する方法は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください

3.13.3.3 Oracle Enterprise Managerでの定義済ブラックアウトの使用

Oracle RACデータベースの管理対象のすべてのターゲットについてブラックアウト(メンテナンス操作によって監視データに偏りが発生したり、不要なアラートが生成されないように、データベース監視を一時停止する期間のこと)を定義し、メンテナンス実行中のアラートの発生を防止できます。ブラックアウトは、クラスタ・データベース全体について定義することも、クラスタ・データベースの特定のインスタンスについて定義することもできます。