1. Real Application Clusters管理およびデプロイメント・ガイド
  2. データベース・インスタンスおよびクラスタ・データベースの管理

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

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

注意:

マルチテナント・コンテナ・データベースは、Oracle Database 20cで唯一サポートされているアーキテクチャです。ドキュメントが改訂されている間は、従来の用語が残っている可能性があります。ほとんどの場合、"データベース"と"非CDB"は、文脈に応じてCDBまたはPDBを指しています。アップグレードなどでは、"非CDB"が以前のリリースの非CDBを指している場合もあります。

関連項目:

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

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

Oracle RACデータベース管理には特定の権限が必要であり、管理タスクはデプロイメント・モデルによって異なります。

Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

親トピック: データベース・インスタンスおよびクラスタ・データベースの管理

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

SYSRAC管理権限を使用して、Oracle RACデータベースを管理します。

セキュリティの強化と管理業務の分離を進めるために、Oracle RACデータベースの管理者はOracle RACデータベースをSYSRAC管理権限で管理します。SYSDBA管理権限は必要ではなくなりました。

SYSRAC管理権限は、SRVCTLなどのOracle RACユーティリティのかわりにOracle Clusterwareエージェントによってデータベースに接続するためのデフォルト・モードです。データベースへのSYSDBA接続は、Oracle RACデータベース・クラスタの日常的な管理に不要になりました。

関連項目

親トピック: Oracle RACデータベースの管理の概要

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

Oracle Database 20c以降、Oracle RACデータベースには1つの統合された管理スタイルがあります。

注意:

Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

Oracle Database 20cより前のOracle RACデータベースでは、2つの異なる管理スタイルおよびデプロイメント・モデルがサポートされています。

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

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

Oracle Database 20c以降、2つの管理スタイルは、各モデルの最良の特徴を組み合せた1つのデプロイメント・モデルに統合されています。管理者管理データベース・デプロイメント・スタイルには、以前はポリシー管理データベースでのみ使用可能だった機能が追加されています。これらの拡張機能により、デプロイメント・スタイルが新たにまとめられました。統合されたデータベース管理スタイルを使用するには、1つ以上のプラガブル・データベース(PDB)が含まれるコンテナ・データベース(CDB)が必要です。

以前と同じコマンドまたはメソッド(DBCAやOracle Enterprise Managerなど)を使用して、統合されたデータベース・デプロイメント・モデルを管理します。すべてのコマンドおよびユーティリティは、Oracle Database 20cより前のOracleデータベースの管理をサポートする下位互換性を維持しています。

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

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

統合されたデータベース管理スタイルにより、動的システムの管理が簡略化されます。クラスタおよびデータベースは、要件の変化に従って拡張または縮小できます。Oracleホーム・ソフトウェアは、クラスタ内のすべてのノードにインストールする必要があります。統合されたデータベース

注意:

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

クラスタ・データベース内のPDBは、PDBのカーディナリティ設定に基づき、すべてのノードまたはノードのサブセットで使用できます。PDBのカーディナリティにより、PDBを同時に実行できるノードの数が管理されます。ALLではなくカーディナリティに数値を使用する場合、PDBがオープンされるインスタンスは各インスタンスの使用可能なリソースによって決まります。

データベース・インスタンスは、PDBをホストするクラスタ内のすべてのサーバーで起動されます。データベース記憶域に、Oracle Automatic Storage Management(Oracle ASM)およびOracle Managed Filesを使用していて、かつインスタンスの起動時に使用可能なREDOスレッドがない場合、Oracle RACは自動的にREDOスレッドを使用可能にし、必要なREDOログ・ファイルとUNDO表領域を作成します。

クライアントは、その時点でPDBが実行されているサーバーに関係なく、同じSCANベースの接続文字列を使用してPDBに接続できます。

関連項目

親トピック: Oracle RACデータベースの管理の概要

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

すでにポリシー管理データベースがホストされているクラスタに管理者管理データベースを作成する場合、管理者管理データベース用のノードは慎重に選択する必要があります。

注意:

Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

管理者管理データベースとポリシー管理データベースの両方を使用する場合、インスタンスの配置は慎重に行う必要があります。これは、管理者管理データベース用に選択したノードはポリシー管理サーバー・プールにあり、このプロセスの一環として汎用サーバー・プールに移動されるためです。

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

注意:

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

関連項目

親トピック: Oracle RACデータベースの管理の概要

3.2 Oracle RACの管理ツール

Oracle Real Application Clusters (Oracle RAC)データベースおよびインスタンスの管理に最も一般的に使用されるツールは、SRVCTLユーティリティ、Oracle Enterprise ManagerおよびSQL*Plusです。

多くの場合、これらのツールを使用してOracle RAC環境を管理する方法は、非クラスタOracle Databaseを管理する場合と同様です。

親トピック: データベース・インスタンスおよびクラスタ・データベースの管理

3.2.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が自動的にこれらのパラメータを維持および設定するためです。

関連項目

親トピック: Oracle RACの管理ツール

3.2.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を使用して、スキーマ、セキュリティおよびクラスタ・データベースの記憶域機能を管理できます。

関連項目

親トピック: Oracle RACの管理ツール

3.2.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を使用しないでください。

注意:

Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

たとえば、プラガブル・データベース(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はアラート・ログ・ファイルに警告を書き込みます。

関連項目

親トピック: Oracle RACの管理ツール

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

Oracle RACデータベースでのインスタンスの起動および停止に、SQL*Plusを使用できます。

ほとんどのSQL文は、現行のインスタンスに適用されます。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ログ・ファイルをアーカイブできます。

次の表に、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コマンドです。

親トピック: Oracle RACの管理ツール

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

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

Oracle Enterprise ManagerとSRVCTLのいずれにも、Oracle Real Application Clusters (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)の値を使用することにより、各データベースのビジネスの重要度を一貫性のある表現で示すことができます。

関連項目

親トピック: データベース・インスタンスおよびクラスタ・データベースの管理

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

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

注意:

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

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

  • クラスタ・データベース全体(すべてのインスタンスとその依存性)を起動するには、次のSRVCTLコマンドを入力します。

    $ srvctl start database -db db_unique_name [-startoption start_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]

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

  • 特定のノード上のデータベースのインスタンスを起動するには、1つのノード名を指定して次のコマンドを使用します。

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

    注意:

    Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

    CRS構成ポリシーおよびCRSポリシー・セットの使用は、将来のリリースでサポートされなくなる可能性があります。サーバー・プールおよびポリシー管理型データベースのかわりに、新しいマージ型管理スタイルの使用をお薦めします。

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

関連項目

親トピック: インスタンスおよびOracle RACデータベースの起動および停止

3.3.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構文をコマンドラインから入力し、必要なデータベース名およびインスタンス名を指定するか、または複数のインスタンス名を指定して、複数の特定のインスタンスを停止します。

  • クラスタ・データベース全体(すべてのインスタンスおよび有効になっているサービス)を停止するには、次のSRVCTLコマンドを入力します。

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

    TRANSACTIONAL停止オプションはsrvctl stop databaseコマンドとともに、TRANSACTIONAL LOCAL停止オプションはsrvctl stop instanceコマンドとともに使用します。

  • 1つ以上のノードでOracle Clusterwareによって管理されているすべてのインスタンスおよび有効になっているサービスを停止するには、次のSRVCTLコマンドを入力します。

    $ srvctl stop instance -node "node_list" [-stopoption stop_options]

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

    $ srvctl stop instance -db db_unique_name {-node "node_list" | -instance "inst_name_list"} 
   [-stopoption stop_options]

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

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

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

関連項目

親トピック: インスタンスおよびOracle RACデータベースの起動および停止

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

ノード上でcrsctl stop crsコマンドを使用するか、crsctl stop cluster -allコマンドを使用してノード上またはクラスタ全体のすべてのインスタンスを停止できます。

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

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

親トピック: インスタンスおよびOracle RACデータベースの起動および停止

3.3.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コマンドでクラスタ・データベースのすべてのインスタンスを起動または停止することはできません。各インスタンスに順次接続し、起動および停止するスクリプトを作成することができます。ただし、インスタンスの追加または削除を行う場合は、このスクリプトを手動でメンテナンスする必要があります。

関連項目

親トピック: インスタンスおよびOracle RACデータベースの起動および停止

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

SRVCTLコマンドを使用してPDBを管理できます。

注意:

Oracle Database 20c以降、非CDB Oracle Databaseアーキテクチャのインストールはサポートされなくなりました。Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

Oracle Database 20c以降、PDBはOracle Clusterwareによって管理されるリソースです。sparkというポリシー管理PDBがあるraccontというCDBを考えてみます。

注意:

先にPDBを作成せずにサービスを作成しようとすると、PDBリソースを先に作成する必要があることを示すエラー・メッセージが表示されます。

カーディナリティを1、2またはALLに設定してspark PDBを作成した場合、PDBにplugというサービスを作成すると、そのサービスでは–cardinality引数も使用できます。-preferredまたは-available引数を使用してspark PDBを作成した場合、PDBに作成した新しいサービスでは–cardinality引数ではなく、-preferredまたは-available引数を使用します。

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

プラガブル・データベースを起動する手順は次のとおりです。
$ srvctl start pdb -db db_name -pdb pdb_name [-startoption start_options]
特定のノードでプラガブル・データベースを起動するには、次のようにします。
$ srvctl start pdb -db db_name -pdb pdb_name -node node_list 
   [-startoption start_options]

IMMEDIATEオプションを使用して、データベース内のすべてのノードでPDBおよびすべてのサービスを停止するには、次のようにします。

$ srvctl stop pdb -db db_name -pdb pdb_name -stopoption IMMEDIATE -drain_timeout 0
  -stopsvcoption IMMEDIATE
特定のノードでプラガブル・データベースを停止するには、次のようにします。
$ srvctl stop pdb -db db_name -pdb pdb_name -node node_list
   [-stopoption stop_options] [-stopsvcoption stop_service_options 
   [-drain_timeout timeout]

Oracle RACデータベースがすべてのノードまたは特定のノードで再起動されたときに、spark PDBを再起動しない場合は、次のコマンドを使用します。 

srvctl disable pdb -db raccont -pdb spark [-node node_name]

PDBサービスplugのステータスを表示するには、次のコマンドを使用します。 

srvctl status service -db raccont -service plug -verbose

PDB sparkのステータスを表示するには、次のコマンドを使用します。 

srvctl status pdb -db raccont -pdb plug -detail

PDBの構成を変更するには、次のコマンドを使用します。

srvctl modify pdb -db db_unique_name -pdb pdb_name 
     [-cardinality {num_of_instances | ALL}]
     [-maxcpu max_cpu_usage] [-mincpuunit min_cpu_usage] 
     [-rank rank] [-startoption start_options] 
     [-stopoption stop_options] [-policy policy]

関連項目

親トピック: データベース・インスタンスおよびクラスタ・データベースの管理

3.5 データベースおよびインスタンスの停止時の停止時間の短縮

停止には、計画されたもの(メンテナンス)と、計画外のものがあります。どちらのタイプの停止も最小限になるように支援する機能を使用できます。

Oracle RACデータベースでは、単一インスタンスの停止がデータベースの可用性に影響することはありません。サーバーまたはインスタンスに障害が発生した場合、データベースだけでなく、リスナーやOracle Automatic Storage Management (Oracle ASM)プロセスなどのサブシステムの再起動も含めた、再起動およびリカバリが自動的に実施されます。サービスを使用して接続しているユーザー・セッションは、正常に稼働しているインスタンスに自動的に移行されます。これは透過的に実行され、ユーザーに対する影響はほとんどありません。

データベース全体を停止する必要がある場合は、ローリング方式で実行できます。各インスタンスの停止は、データベース全体を停止することで個別に実行できます。インスタンスの停止中に、データベースの停止が必要になったタスクを実行して、その後でインスタンスを再起動します。Oracle RACデータベース内のインスタンスが、すべて停止および再起動されるまで繰り返されます。

計画された停止と計画外の停止の両方で、停止時間を最小化するために使用できる追加機能があります。

  • Oracle RACの高可用性フレームワークでは、Oracle Clusterwareとリソース・プロファイルを使用して、サービスの可用性を維持します。Oracle Clusterwareは、ビジネス・ルールとサービス属性に従って、サービスをリカバリするか、サービスを均等に分散します。こうしたサービスがデータベースへのクライアント接続に使用されている場合は、停止エラーを発生させるかわりに、正常に稼働しているインスタンスに自動的にリダイレクトされます。
  • 1つ以上のインスタンスまたはノードを隔離する必要がある修復、アップグレードおよび変更のために、Oracle RACでは、アプリケーション・ユーザーに対するサービスの中断の影響を最小限に抑えて、サービスを再配置、無効化および有効化するインタフェースを使用できます。
  • 高速アプリケーション通知(FAN)は、データベース、ノードおよびネットワークに関連する停止後に、クライアントの即時割込みを実現します。FANは、リソースが使用可能になると即座にクライアントに通知して、クライアントが計画メンテナンス中の停止を認識しないようにデータベース・セッションの排出を開始します。たとえば、Oracle接続プールは、FANを使用して、障害についての非常に高速な通知を受信し、障害後の接続を均等に分散します。障害が発生したコンポーネントが修復されると、接続を再度均等に分散します。
  • アプリケーション・コンティニュイティは、データベース・セッションを使用不可にするリカバリ可能なエラーの後に、データベースに対するリクエストを中断することなく、迅速な方法でリプレイできるようにする機能です。そのため、ユーザーにとって停止は、単なるリクエストの実行の遅延にしか見えなくなります。

計画された停止の場合、Oracle Database 20cのユーザーに対する中断は、ほとんど排除できます(ゼロ・ブラウンアウト)。インスタンスの段階的な停止によって、正常に稼働しているインスタンスがロックなどのリソースの所有権を取得できるため、インスタンス停止後の再構成に必要な作業量が減少します。DBAがインスタンスに向けて停止コマンドを発行すると、そのインスタンスはアクティブ・インスタンスからパッシブ・インスタンスに遷移します。

パッシブ・インスタンスは、アクティブ・インスタンスに、できるだけ多くのリソースとロックを遷移するために停止していることが理想的です。Oracle RACクラスタでは、同時に存在可能なパッシブ・インスタンスは常に1つのみです。このプロセスが開始されると、次のアクションが実行されます。

  • パッシブ・インスタンスで実行中のサービスが停止されて、別のインスタンスに再配置されます。これには、ターゲット排出タイムアウトが指定されたパッシブ・インスタンスからアクティブ・インスタンスへの接続の移動が含まれます。この排出タイムアウトは、パッシブ・インスタンスの停止など、すべての完了を待機する時間を示します。
  • パッシブ・インスタンスからのサービスの排出後、すべてのプラガブル・データベース(PDB)がクローズされます。パッシブ・インスタンスから、すべてのロック・マスターがアクティブ・インスタンスに転送されます。
  • インスタンスが、正常にシャットダウンされます。

親トピック: データベース・インスタンスおよびクラスタ・データベースの管理

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

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

親トピック: データベース・インスタンスおよびクラスタ・データベースの管理

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

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

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

$ srvctl status database -db mail

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

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

また、次のようにして、PDBがクラスタ内で実行されているかどうかを確認できます。

$ srvctl status pdb -db db_unique_name -pdb pdb_name

親トピック: インスタンスの実行の確認

3.6.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.7 特定のクラスタ・インスタンス上でのセッションの終了

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.8 Oracle RACでの初期化パラメータ・ファイルの概要

Oracle RACデータベースの初期化パラメータは、SPFILEに格納されます。

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

注意:

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

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

親トピック: データベース・インスタンスおよびクラスタ・データベースの管理

3.8.1 Oracle RAC用のSPFILEの作成について

Oracle Real Application Clusters環境のすべてのインスタンスは、同じサーバー・パラメータ・ファイルを使用する必要があります。

ただし、別途許可されている場合は、個々のインスタンスで、1つのファイル内の同じパラメータの設定値をそれぞれ変えて使用できます。インスタンス固有のパラメータ定義は、SID.parameter = valueで指定します(SIDはインスタンス識別子です)。

Oracle RACでは、SPFILEの場所はOracle Clusterwareで管理されるデータベース・リソースの属性です。新しいSPFILEを作成する際にコマンドの発行元となるインスタンスが実行されている場合は、次のコマンドによって新しいSPFILEが作成され、新しいSPFILEの場所でデータベース・リソースが自動的に更新されます。

CREATE SPFILE='location' FROM PFILE;

この場合、サーバー・パラメータ・ファイルを名前で参照せずにデータベースを起動できます。

コマンドの発行元となるインスタンスが実行されていない場合は、srvctl modify database -db dbname -spfile spfile_pathを使用して、データベース・リソースのSPFILEを手動で更新する必要があります。また、次のコマンドを使用すると、データベース・リソースのSPFILEの場所が自動的に更新されません。 

CREATE SPFILE FROM PFILE [AS COPY];
CREATE SPFILE='location' FROM PFILE AS COPY;
CREATE SPFILE FROM MEMORY;

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

親トピック: Oracle RACでの初期化パラメータ・ファイルの概要

3.8.2 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';

親トピック: Oracle RACでの初期化パラメータ・ファイルの概要

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

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

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

  1. Oracle Clusterwareによって管理されるデータベース・リソースの-spfile属性で指定される場所。

  2. サブディレクトリ/dbsの、$ORACLE_HOME/bin/orabaseconfigユーティリティによって戻される場所にあるspfilesid.oraファイル。

  3. サブディレクトリ/dbsの、$ORACLE_HOME/bin/orabaseconfigユーティリティによって戻される場所にあるspfile.oraファイル。

  4. サブディレクトリ/dbsの、$ORACLE_HOME/bin/orabaseconfigユーティリティによって戻される場所にある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にpath/dbs/spfiledb_unique_name.oraというネーミング規則を使用します。path/dbs/initsid.oraという名前のPFILEを作成し、名前SPFILE=path/dbs/spfiledb_unique_name.oraを含めます。

関連項目

親トピック: Oracle RACでの初期化パラメータ・ファイルの概要

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

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

Oracle Enterprise Managerを使用してこれを実行するか、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の自動バックアップ機能を使用可能にします。

関連項目

親トピック: Oracle RACでの初期化パラメータ・ファイルの概要

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

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

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

関連項目

親トピック: データベース・インスタンスおよびクラスタ・データベースの管理

3.9.1 Oracle RACに固有の初期化パラメータ

次の表に、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はこのパラメータを使用して、十分なメモリー・リソースを割り当てます。すべてのインスタンスに同じ値を設定する必要があります。

注意: Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

また、インスタンスを追加する場合、現行のインスタンスの数より大きい値をこのパラメータに設定できます。

CLUSTER_INTERCONNECTS

複数のインターコネクトが存在する場合、プライベート・ネットワークの代替クラスタ・インターコネクトを指定します。

注意:

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

  • 特別な場合を除き、CLUSTER_INTERCONNECTSパラメータを設定することはお薦めしません。

  • このパラメータは、グリッドのプラグ・アンド・プレイ環境のグリッド・プラグ・アンド・プレイ・プロファイルに格納されます。
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エントリは必要ありません。

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(ゼロ)以外の値に解決されます。

Oracle Database 20c以降、結果キャッシュのフェッチ機能が強化されています。キャッシュされた結果をリモート・インスタンスからフェッチする前に、データベースはヒューリスティックを使用して、ローカル・インスタンスで結果を再計算するほうが効率的かどうかを判断します。この機能の使用を監視するには、V$RESULT_CACHE_OBJECTSビューとV$RESULT_CACHE_STATISTICSビューを問い合せます。

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ログ・グループを指定することをお薦めします。

関連項目

親トピック: Oracle RACでの初期化パラメータの使用

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

データベースの作成に重要な特定のパラメータ、または特定のデータベース操作に影響する特定のパラメータには、Oracle RACデータベースの各インスタンスで同じ値を設定する必要があります。

これらの初期化パラメータ値は、SPFILEに指定するか、または各インスタンスの個々のPFILEに指定します。次のリストに、すべてのインスタンスで同一である必要があるパラメータを示します。

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

  • DML_LOCKS
  • RESULT_CACHE_MAX_SIZE

親トピック: Oracle RACでの初期化パラメータの使用

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

INSTANCE_NUMBERパラメータなど、特定のパラメータは各インスタンスに固有です。

Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

ポリシー管理データベースで一意の設定を持つパラメータを設定する必要がある場合は、データベースのサーバー・プールに割り当てられる各サーバーに対して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初期化パラメータを使用すると、優先読取り障害グループ名のリストを指定できます。これらの障害グループのディスクは、優先読取りディスクになります。したがって、すべてのノードはそのローカル・ディスクから読み取ることができます。この結果、効率およびパフォーマンスが向上し、ネットワーク・トラフィックが削減されます。このパラメータの設定はインスタンス固有で、すべてのインスタンスで同じにする必要はありません。

関連項目

親トピック: Oracle RACでの初期化パラメータの使用

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

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

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

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

パラメータ 説明
ARCHIVE_LAG_TARGET

Oracle RACデータベースのインスタンスごとに異なる値を設定すると、データベース処理によって追加の自動同期化が実行されるため、多くの場合、オーバーヘッドが増加します。

Oracle RACデータベースのダウンストリーム取得構成で、Oracle GoldenGateダウンストリーム取得または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データベースのインスタンス間で異なる値を割り当てる前に、メリットがあるかどうかを慎重に考慮する必要があります。

親トピック: Oracle RACでの初期化パラメータの使用

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

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

注意:

Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

既存のサーバー・プールは引き続き使用でき、新しいプールおよびポリシーも作成できます。既存のサーバー・プールを使用するリソースは、引き続きこれらを透過的に使用できます。

CRS構成ポリシーおよびCRSポリシー・セットの使用は、将来のリリースでサポートされなくなる可能性があります。サーバー・プールおよびポリシー管理型データベースのかわりに、新しいマージ型管理スタイルの使用をお薦めします。

管理者管理データベースが権限の弱いユーザー用に構成されており、このデータベースをポリシー管理データベースに変換しようとする場合は、この権限の弱いユーザーにウォレットを(まだ存在しない場合)手動で追加し、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.11 データベース・サーバーのメモリー不足の管理

Memory Guardは、サーバー上のメモリー不足をリアルタイムで検出し、新しいセッションを他のサーバーにリダイレクトして、メモリーが不足しているサーバー上のすべての使用可能メモリーが使用されることを防ぎます。

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

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

Oracle Database Quality of Service Managementが有効になっていると、クラスタ・ヘルス・モニターは、クラスタ・サーバーのメモリー・リソースに関するリアルタイム情報を提供するメトリック・ストリームをメモリー・ガードに送信します。この情報の内容は次のとおりです。

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

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

親トピック: データベース・インスタンスおよびクラスタ・データベースの管理

3.12 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.13 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.13.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

関連項目

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

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

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

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

システムの再起動時にOracle ClusterwareによるOracle RACデータベースの再起動を防止する場合、または障害が発生したインスタンスの2回目以降の再起動を回避する場合、制御の程度を定義する管理ポリシーを構成します。管理ポリシーには、次の3つがあります。

  • AUTOMATIC: これはデフォルトの管理ポリシーです。データベースは、データベース・ホスト・コンピュータの再起動時に前回の実行状態(起動または停止)へ自動的に戻されます。
  • MANUAL: データベース・ホスト・コンピュータの再起動時にデータベースは自動的には再起動されません。MANUALに設定しても、Oracle Restartは、実行中のデータベースを監視し、障害発生時にデータベースを再起動します。
  • NORESTART: MANUAL設定と同様に、データベース・ホスト・コンピュータの再起動時にデータベースは自動的には再起動されません。ただし、NORESTART設定では、障害が発生しても、データベースを再起動することはありません。

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.15 Oracle Enterprise Managerの高度な管理

Oracle Enterprise Manager Cloud Controlを使用すると、Oracle Real Application Clusters (Oracle RAC)データベースのインストール、構成および監視を1つの場所から実行できます。

この項では、Oracle RACデータベースの監視およびチューニングで説明されていない高度な管理タスクについて説明します。

親トピック: データベース・インスタンスおよびクラスタ・データベースの管理

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

Oracle Enterprise ManagerでOracle RACデータベースおよびインスタンス・ターゲットを検出すると、監視と管理が可能になります。

Oracle Enterprise Manager Cloud Controlでは、Oracle Enterprise Managerコンソール・インタフェースを使用してOracle Real Application Clusters (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 Automatic Storage Management (Oracle ASM)を監視ターゲットとして追加できます。

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

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

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

親トピック: Oracle Enterprise Managerの高度な管理

3.15.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に接続されていれば、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のプロビジョニング」が導入されました。

親トピック: Oracle Enterprise Managerの高度な管理

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

Oracle Enterprise Managerの「管理」タブは、Oracle RACデータベースに使用できます。

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

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

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

親トピック: Oracle Enterprise Managerの高度な管理

3.15.3.1 Oracle RACでのジョブの管理

Oracle Enterprise Managerジョブは、データベース・レベルでもインスタンス・レベルでも管理できます。

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

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

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

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

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

  3. Oracle Enterprise Managerに「データベース・ホーム」ページが表示されたら、「メンテナンス」をクリックします。

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

3.15.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パッケージおよびタイプ・リファレンス』を参照してください

親トピック: Oracle RACでのジョブおよびアラートの管理

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

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

ブラックアウトを定義すると、メンテナンスの実行中にアラートが発生しないようにできます。ブラックアウトは、クラスタ・データベース全体について定義することも、クラスタ・データベースの特定のインスタンスについて定義することもできます。