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

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

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

ノート:

マルチテナント・コンテナ・データベース(CDB)は、Oracle Database 21c以降で唯一サポートされているアーキテクチャです。

関連項目:

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

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

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

ポリシー管理データベース・デプロイメント・オプションは、Oracle Database 23aiでサポートされなくなりました。

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

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

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

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

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

関連トピック

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

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

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

ノート:

ポリシー管理データベース・デプロイメント・オプションは、Oracle Database 23aiでサポートされなくなりました。

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

管理者管理デプロイメントでは、クラスタ内の特定のノードで実行されるように各データベース・インスタンスを静的に構成する必要があります。このデプロイメントでは、preferredおよびavailable指定を使用して、特定のデータベースに属する特定のインスタンスで実行されるようにデータベース・サービスを構成する必要があります。

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

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

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

統合されたデータベース管理スタイルにより、動的システムの管理が簡略化されます。クラスタおよびデータベースは、要件の変化に従って拡張または縮小できます。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データベースの管理の概要

Oracle RACの管理ツール

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

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

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

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の管理ツール

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の管理ツール

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

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

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

ノート:

ポリシー管理データベース・デプロイメント・オプションは、Oracle Database 23aiでサポートされなくなりました。

たとえば、プラガブル・データベース(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の管理ツール

インスタンスへの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の管理ツール

インスタンスおよび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データベース・インスタンスは起動しません。

関連トピック

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

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 Database 23aiでサポートされなくなりました。

    ポリシー管理データベースはOracle Database 21cで非推奨となり、管理者管理データベース・デプロイメントはポリシー管理データベースと同様の機能で拡張されました。Oracleでは、ポリシー管理データベースによって提供される自動化を管理者管理データベースの一貫性と組み合せることで、データベース管理者のデータベース管理タスクを簡素化しようとします。このコンバージド・データベース・デプロイメントでは、デプロイメント時に特定のスタイルを選択する必要なく、データベースの起動順序をランク付けおよび定義するオプションを提供するなど、両方のオプションの最適なオプションが提供されます。

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

関連トピック

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

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]

    ノート:

    いずれかのインスタンスで実行中のサービスがある場合は、-forceオプションを使用してサービスおよびインスタンスを停止する必要があります。

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

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

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

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

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

関連トピック

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

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データベースの起動および停止

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データベースの起動および停止

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

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

ノート:

Oracle Database 21c以降、非CDB Oracle Databaseアーキテクチャのインストールはサポートされなくなりました。ポリシー管理データベース・デプロイメント・オプションは、Oracle Database 23aiでサポートされなくなりました。

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

ノート:

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

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

PDBはOracle Clusterwareリソースとして管理されるため、一般的なOracle RACベースの管理プラクティスが適用されます。このため、PDB sparkにAUTOMATIC管理ポリシーがある場合、PDBはCDBの起動時に起動されます。同様に、このサービスをホストしているサーバー上でOracle Clusterwareが停止しているときにPDB sparkがオンライン状態であり、管理ポリシーがMANUALに設定されている場合、このサーバー上のOracle Clusterwareの再起動後に、PDBは元の状態にリストアされます。デフォルトのPDB管理ポリシーは、そのCDBの管理ポリシーから導出されます。

プラガブル・データベースを起動するには:
$ 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 spark -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]

ノート:

-cardinalityパラメータは、PDBの作成時に-cardinalityパラメータを設定した場合にのみ変更できます。

関連トピック

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

ローカルのローリング・データベースのメンテナンス

Oracle Database 23ai以降では、データベースの可用性およびワークロードに影響を与えずに、Oracle Real Application Clusters (Oracle RAC)およびOracle RAC One Nodeデータベースをアウトオブプレース・モードでローカルにパッチ適用できます。

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

ローカル・ローリング・データベース・メンテナンスについて

Oracle Database 23ai以降では、Oracle Real Application Clusters (Oracle RAC)およびOracle RAC One Nodeデプロイメントに対してローリング・パッチを適用し、その他のメンテナンス操作をローカルに実行できます。

ローカル・ローリングは、データベース・インスタンスを停止して別のノード上の別のインスタンスにワークロードを再配置するかわりに、同じノードの2番目のホームから2番目のデータベース・インスタンスを作成して起動します。ローカル・ローリング・データベースのメンテナンスにより、接続の移行にかかる時間が短縮されます。この機能により、ワークロードがローカル・ノードに保持され、ブラウンアウト時間が短縮されます。2つのインスタンスを一時的に実行するのに十分なCPU、メモリーおよびその他のコンピューティング・リソースがあることを確認する必要があります。

ローカル・ローリングでは、2つのOracleホーム間のデータベースのローリング移行中に、クラスタ内で少なくとも同じ数のOracle RACおよびOracle RAC One Nodeインスタンスが実行されていることを確認します。この機能を使用すると、単一のクラスタ・ノード内でアウトオブプレース・ローリング・パッチ適用を実行できます。

ローカル・ローリング・アウトオブプレース・パッチ適用を使用する場合、Oracle RACは新しいOracleホームに2番目のインスタンスを作成し、2番目のインスタンスを起動し、パッチ適用対象のノード上の古いOracleホームの最初のインスタンスを停止します。この機能では、PDBの配置とサービスが保持されるため、ノードではパッチ適用前に実行していた同じ作業が引き続き実行されます。

ノート:

  • srvctl modify databaseコマンドは、一意のインスタンス名(ORACL_SID)を持つ新しいインスタンスを自動的に作成します。
  • 新しいインスタンス名は、現在のインスタンス名にアンダースコア(_)と数字を付加したものです。たとえば、現在のインスタンス名がsales_1である場合、新しいインスタンス名はsales_2になります。パッチ適用操作が完了すると、新しいインスタンスのみがパッチ適用済のノードで実行されます。
  • ローリング・パッチ適用を2回目に実行すると、元のORACLE_SIDがリストアされます。たとえば、2回目のローリング・パッチ適用操作の後、ORACLE_SIDはsales_1に戻ります。3番目のローリング・パッチ適用操作ではsales_2が使用される、というように続きます。

マルチノード環境では、ローカル・ローリング・アウトオブプレース・パッチ適用はオプションです。このオプションはデフォルトでは無効にされています。この機能を有効にするには、srvctl modify databaseで-localrollingオプションを使用します。

親トピック: ローカル・ローリング・データベースのメンテナンス

ローカル・ローリングのメンテナンスを使用するための要件

ローカル・ローリング・データベースのメンテナンスを構成および使用するために実行が必要なことを学習します。

Oracle RACでローカル・ローリング・データベースのメンテナンス機能を利用するには、次の要件を満たす必要があります:
  • Oracle Managed Files (OMF)を構成します。
  • サーバー・パラメータ・ファイル(SPFILE)を使用します。
  • ローカル・ローリングが完了したら、THREADおよびUNDO_TABLESPACE初期化パラメータをリセットします。
  • ローカル・ローリング・パッチ適用中にsrvctl add instance、srvctl remove instanceまたはsrvctl modify instanceコマンドを実行しないでください。
  • インスタンスごとに新しいREDOスレッドと新しいUNDO表領域を作成するために十分な空き記憶域が使用可能であることを確認する必要があります。この機能では、初めて使用するときに新しいインスタンスごとに新しいREDOスレッドと新しいUNDO表領域が作成されます。この機能を2回目以降使用する場合、以前使用していた古いREDOスレッドとUNDO表領域が使用され、新しいREDOとUNDOは作成されません。

親トピック: ローカル・ローリング・データベースのメンテナンス

ローカル・ローリング・モードでのOracle RACデータベースのパッチ適用

Oracle Real Application Clusters (Oracle RAC)およびOracle RAC One Nodeデータベースは、ローカル・ローリング・モードでパッチ適用できるため、接続の移行時間を短縮できます。

  1. Oracle Databaseインストール・イメージ・ファイル(db_home.zip)をダウンロードし、イメージ・ファイルを新しいOracleホーム・ディレクトリに展開します。
    $ mkdir -p /u01/app/oracle/product/23.4.0/dbhome_1
$ chgrp oinstall /u01/app/oracle/product/23.4.0/dbhome_1
$ cd /u01/app/oracle/product/23.4.0/dbhome_1
$ unzip -q /tmp/db_home.zip
  2. 新しいOracleホーム・ディレクトリから、Oracle Databaseソフトウェアのインストールを開始し、必要なリリース更新(RU)を適用します。
    $ cd /u01/app/oracle/product/23.4.0/dbhome_1
$ ./runInstaller -applyRU patch_directory_location
  3. 新しいOracle RACまたはOracle RAC One Node対応ホームを準備します。

    ノート:

    Oracle FPPまたはその他の方法を使用してOracle RACソフトウェアをインストールすることもできます。
  4. データベースのローカル・ローリングを有効にします。
    $ srvctl modify database –db mydb -oraclehome new_Oracle_home -localrolling
    このコマンドは、新しいインスタンスの名前も生成します。
  5. Oracle RACおよびOracle RAC One NodeのPDBとサービスを古いOracleホームから新しいOracleホームに転送します。
    $ srvctl transfer instance –d mydb [-node node_list] 
{[-stopoption stop_option] | -rollback} [-drain_timeout timeout] [-verbose]

    新しいインスタンスは、新しいOracleホームから開始され、セッションが新しいインスタンスに移行されるまで、-drain_timeoutパラメータで指定された時間まで待機します。すべてのセッションが新しいインスタンスに移行されると、古いインスタンスは停止します。

    ノート:

    -drain_timeoutを指定しない場合、指定したノード上のデータベースで実行中のすべてのサービスに構成されている最大ドレイン・タイムアウトが使用されます。
  6. データベース構成の変更を確認します。
    $ srvctl config database -db mydb
  7. 必要に応じて、サービスと接続文字列を追加または変更します。

関連トピック

親トピック: ローカル・ローリング・データベースのメンテナンス

ローカル・ローリング・モードで失敗した転送からリカバリする方法

ローカル・ローリング・データベースのメンテナンス中に、一部のインスタンスがターゲットのOracleホームへの転送に失敗することがあります。ローカル・ローリング・モードで障害が発生した転送からリカバリするには、次のいずれかの手順を使用します。

  1. すべてのインスタンスをターゲットのOracleホームから古いOracleホームに戻します。
    1. Oracle RACローカル・ローリング構成の変更を元に戻します。
      srvctl modify database -db mydb -localrolling_revert
    2. すべてのデータベース・インスタンスを古いOracleホームに転送します。
      srvctl transfer instance -db mydb
      この手順では、ローカル・ローリング前のデータベースを元の状態にリストアします。すべてのインスタンスは、古いOracleホームから実行を開始します。前のターゲットOracleホームを削除し、新しいOracleホームを作成して、ローカル・ローリング・プロシージャを再度開始できます。
  2. 一部のインスタンスをターゲットのOracleホームから古いOracleホームに戻します。
    1. Oracle RACローカル・ローリング構成の変更を元に戻します。
      srvctl modify database -db mydb -localrolling_revert
    2. 一部のデータベース・インスタンスを古いOracleホームに転送します。
      srvctl transfer instance -db mydb -node node_list
      転送されたノードのローカル・ローリング・ターゲットOracleホームを修正します。ローカル・ローリング・ターゲットOracleホームからまだ実行中のインスタンスがある場合、データベースはローカル・ローリングREVERT状態になります。
    3. 同じターゲットのOracleホームを使用してデータベースをTRANSFER状態に変更し、インスタンスを転送します。
      srvctl modify database -db mydb -localrolling -oraclehome target_Oracle_home
  3. 一部のインスタンスをターゲットのOracleホームから古いOracleホームに戻します。
    1. 一部のインスタンスをターゲットのOracleホームから古いOracleホームにロールバックします。
      srvctl transfer instance -db mydb -node node_list -rollback
      データベースはTRANSFER状態になります。
    2. ターゲットのOracleホームを修正します。
    3. データベース・インスタンスをターゲットのOracleホームに転送しなおします。
      srvctl transfer instance -db mydb

関連トピック

親トピック: ローカル・ローリング・データベースのメンテナンス

プラガブル・データベースのランク

PDBの-rankパラメータは、カーディナリティを指定して作成されるPDBの相対的な重要度を、RANK管理ポリシーを使用してデータベースに定義します。

プラガブル・データベース(PDB)のランクは、PDBに割り当ててPDBのワークロードの重要度を指定できる事前定義済の値です。Oracle Clusterwareでは、PDBのランクに基づいていくつかの決定が行われます。デフォルトでは、Oracle Clusterwareのワークロードの重要度はPDBごとに同じです。ただし、PDBの-rankパラメータを使用すると、PDBのワークロードの重要度を区別するために、事前定義済の値のセットから選択できます。ランクが高いほど、PDBワークロードの重要度が高くなります。たとえば、PDBランク5が最高ランクで、1が最低ランクです。

PDBの-rankパラメータはオプションであり、デフォルトでは設定されません。srvctl modify pdbコマンドを使用して構成できます。-rankパラメータが設定されている場合、Oracle Clusterwareでは、次の操作を実行するためのランクを持つPDBが優先されます。

  • クラスタ内のPDBの起動順序を決定します。Oracle Clusterwareは、ランクが最も高いPDBを、ランクが低い他のPDBよりも前に起動しようとします。

  • RANK管理ポリシーを使用して、クラスタ・データベース・インスタンスを停止します(そのデータベース・インスタンスを必要とする実行中のPDBがない場合)。

  • PDBのリソース要件がデフォルト以外の値に設定されている場合に、上位ランクのPDBのリソース要件を満たすのに十分なリソースがクラスタにないときに、PDBの起動を拒否するか、PDBの実行を停止するかを決定します。デフォルト以外のランクおよびリソース要件の値を持つPDBは、デフォルトのランクおよびリソース要件の値を持つPDBより優先度が高くなります。

    CDB1のPDBがRANK 3で、CDB2のPDBがRANK 2のときに、一方のCDBのみを起動するのに十分なリソースしかない場合、CDB1のPDBのランクのほうが高いため、Oracle Clusterwareは依存性によってCDB1を起動します。CDB2のPDBのほうがランクが低いため、Oracle ClusterwareはCDB2を起動しません。

PDBランクの仕組み

PDBの-rankパラメータが定義されている場合、Oracle Clusterwareでは最初にランクが最も高いPDBが考慮され、次にPDBのフェイルオーバー時に必要なCPUの数が考慮されます。たとえば、各ノードに4つのCPUを持つ3つのノード・クラスタに、3つのPDB (RANK 1でCPU数4のPDB1、RANK 2でCPU数4のPDB2、RANK 3でCPU数4のPDB3)がある場合、Oracle Clusterwareはフェイルオーバーを次の順序で処理します。

  1. クラスタには、すべてのPDBを起動するのに十分なリソースがあります。最初のノードに障害が発生した場合、PDB2およびPDB3は実行し続けますが、PDB1はランクが最も低いため、Oracle Clusterwareによって停止されます。PDB2およびPDB3が障害が発生したノードでホストされていた場合、Oracle Clusterwareは実行中のノードでPDB1を停止し、これらのノードでPDB2およびPDB3を起動します。
  2. 2番目のノードに障害が発生した場合、PDB3は実行し続けますが、PDB2はランクが最も低いため、Oracle Clusterwareによって停止されます。PDB3が障害が発生したノードでホストされていた場合、Oracle Clusterwareは実行中のノードでPDB2を停止し、そのノードでPDB3を起動します。
  3. PDBは、異なるCDBから実行できます。複数のCDBがあり、これらのCDBのいずれかに実行中のPDBがない場合、Oracle Clusterwareは実行中のPDBがないCDBを停止します。

PDBのランクは、PDBを作成するCDBのみでなく、クラスタ全体に設定されます。

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

プラガブル・データベースの配置

指定したCDBインスタンスで明示的に実行するように、またはクラスタ内のCDBまたはCDBのサブセットで動的に実行するようにPDBを構成します。

PDBの次の2つの配置オプションから選択できます。

  • 優先および使用可能なPDB: これらのPDBは、指定したクラスタ・ノードのリストで実行されている、明示的に指定したCDBインスタンスでのみ実行できます。このようなPDBを構成する間に、CDB名と、CDBを実行できるインスタンスまたはノードのリストを指定する必要があります。CDBを実行できるインスタンスまたはノードのリストを変更できます。

  • フローティングPDB: これらのPDBは指定されたカーディナリティで作成され、作成されたCDBの任意のインスタンスで実行できます。PDBのカーディナリティにより、PDBを同時に実行できるノードの数が管理されます。ALLではなくカーディナリティに数値を使用する場合、PDBがオープンされるインスタンスは各インスタンスの使用可能なリソースによって決まります。

    Oracle Clusterwareは、PDBの-maxcpuおよび-mincpuunitパラメータの値に基づいて、各クラスタ・データベース・インスタンスのリソースを評価します。-maxcpu、-mincpuunitおよび-rankパラメータを変更するには、gridまたはrootユーザーとしてログインする必要があります。

PDB配置オプションは、新しいPDBの作成中に、または既存のPDBを変更することで構成できます。

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

カーディナリティおよびランクを使用したプラガブル・データベースの作成の例

これらの例を使用して、Oracleデータベースを作成し、Oracleデータベースでカーディナリティを指定してプラガブル・データベースを作成する方法を確認できます。

-rankパラメータを使用して、Oracleデータベース内のプラガブル・データベースの相対的な重要度を定義できます。このオプションは、RANK管理ポリシーを使用してデータベースのカーディナリティを指定して作成されたプラガブル・データベースで機能します。

次の例は、RANK管理ポリシーを使用してOracleデータベースを作成し、カーディナリティを指定してプラガブル・データベースをOracleデータベースに追加し、PDBカーディナリティを変更する方法を示しています。

例3-1 SRVCTLを使用したOracle Databaseの作成

この例では、SRVCTLを使用して、RANK管理ポリシーでOracleデータベースDATAを作成します。 

$ srvctl add database -db db_unique_name -policy RANK -oraclehome $ORACLE_HOME -dbname DATA

例3-2 SRVCTLを使用したプラガブル・データベースの作成

この例では、SRVCTLを使用して、OracleデータベースDATAにカーディナリティを指定してプラガブル・データベースMYPDBを作成します。 

$ srvctl add pdb -db DATA -pdb MYPDB -cardinality 2

ノート:

CDBの管理ポリシーをRANKに設定すると、そのCDBで作成したPDBのデフォルト・ポリシーはRESTARTに設定されます。

例3-3 SRVCTLを使用したPDB構成の確認

この例では、SRVCTLを使用してプラガブル・データベースMYPDBの構成を確認します。 

$ srvctl config pdb -db DATA -pdb MYPDB
Pluggable database name: MYPDB
Application Root PDB: 
Cardinality: 2 
Maximum CPU count (whole CPUs): 0 
Minimum CPU count unit (1/100 CPU count): 0 
Start Option: open
Stop Option: immediate

例3-4 SRVCTLを使用したプラガブル・データベースのカーディナリティとランクの変更

この例では、gridユーザーとして、プラガブル・データベースMYPDBのカーディナリティを変更し、SRVCTLを使用して最大CPU使用率、最小CPU使用率およびランクを設定します。 

$ srvctl modify pdb -db DATA -pdb MYPDB -cardinality 1 -maxcpu 3 -mincpuunit 20 -rank 2

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

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

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

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

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

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

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

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

Oracle RACの高可用性ベスト・プラクティス

パッチ適用および再構成の停止時間を最小限に抑えるために、Oracle Real Application Clusters (Oracle RAC)ベスト・プラクティスを実装します。

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

Oracle RACの2段階ローリング更新

Oracle Database 23ai以降、Oracle RACの2段階ローリング・パッチ機能を使用すると、以前の非ローリング・パッチをローリング方式で適用できます。

Oracle RACの2段階ローリング・パッチは、段階的にローリング方式で適用できる新しいタイプのパッチです。最初のノードにパッチが適用されたら、2番目のノードにパッチが適用される、というように続きます。すべてのノードにパッチが適用されたら、パッチを有効にできます。この機能を使用して適用する修正は、デフォルトでは無効になっています。

すべてのノードに正常にパッチが適用された後、alter system enable RAC two_stage rolling updates all;コマンドを使用してこれらの修正を有効にできます。2段階ローリング・パッチは、パッチを適用した直後に有効にするか、後で有効にするかを選択できます。ただし、2段階ローリング・パッチ適用を使用して別のパッチまたはリリース更新(RU)が適用されている場合、これらのパッチは自動的に有効になります。V$RAC_TWO_STAGE_ROLLING_UPDATESビューを使用して、Oracle RACの2段階ローリング更新を使用して適用されたパッチをリストします。

ノート:

Oracle RACの2段階ローリング更新は、非ローリングRUに適用されますが、Oracle RACデータベースの主なアップグレードには適用されません。

Oracle RACの2段階のローリング更新により、非ローリング・パッチを適用するための停止時間の必要性が減ります。ただし、すべての非ローリング修正をRACローリング方式で適用できるわけではありません。この機能を使用すると、Oracle RACの非ローリング・パッチの数が大幅に削減されます。

ノート:

パッチの適用方法については、パッチのREADMEファイルを確認し、パッチのアップグレードを開始する前に必要なステップをすべて完了します。

この機能を使用すると、RUのすべてのOracle RACバグ修正および新機能を含めることができます。リリース・バージョンの不一致を回避するために、1つのメンテナンス・ウィンドウ内のすべてのインスタンスにパッチを適用することをお薦めします。

親トピック: Oracle RACの高可用性ベスト・プラクティス

Oracle RACインスタンスのスムーズな再構成

Oracle Real Application Clusters (Oracle RAC)インスタンスをスムーズに再構成すると、クラスタ再構成時のブラウンアウト時間が短縮されます。

スムーズな再構成機能により、ノードのOracle RACクラスタへの参加または退出などの特定のOracle RAC操作によって発生するブラウンアウト時間が短縮されるか、ノードがメンテナンスを受けたり障害に陥ったときのブラウンアウト時間が短縮されます。この機能により、Oracle RACサービスおよびクライアント・アプリケーションの継続的な可用性が保証されます。

ブラウンアウト時間は、データベースのSGAサイズによって異なります。SGAサイズが大きいほど、ブラウンアウトが長くなります。ブラウンアウトは、ノードに障害が発生したり、クラスタから離れたときに、新しいノードが既存のインスタンスに参加するか既存のインスタンスにリソースを再分散するときに、グローバル・エンキュー・サービス(GES)およびキャッシュ・フュージョンのリソースを再分散することに関連しています。キャッシュ・フュージョン・リクエストは、個々のリソース・ベースで再構成をトリガーできます。

スムーズな再構成機能を使用すると、クラスタの再構成中にクライアントによってリクエストされるキャッシュ・フュージョンのリソースに対して、オンデマンドのキャッシュ・フュージョン再構成が可能になります。クライアントがオンデマンド再構成後にリクエストを完了できるように、クライアントのリクエスト時にキャッシュ・フュージョン・リクエストがただちに再構成されます。オンデマンドのキャッシュ・フュージョン再構成は、進行中のクラスタ再構成と並行して機能します。

親トピック: Oracle RACの高可用性ベスト・プラクティス

Oracle RACでの順序付けられた順序の最適化

順序は、複数のユーザーが一意の整数を生成できるデータベース・オブジェクトです。順序を使用すると、主キー値を自動的に生成できます。

Oracle Real Application Clusters (Oracle RAC)では、次の順序構成がサポートされています。
  • CACHEおよびORDER: アプリケーションでは順序番号の順序付けが必要で、連続しない順序番号を使用できる場合は、CACHEおよびORDERを使用して、Oracle RACの順序番号のキャッシュおよび順序付けを実行します。すべてのインスタンスが同じ番号セットをキャッシュします。
  • CACHEおよびNOORDER: 順序番号を使用している場合、常にNOORDERオプションを指定したCACHEを使用することによって、順序番号生成のパフォーマンスを最適化します。ただし、CACHEオプションを使用すると、連続しない順序番号が生成される場合があります。この構成には、パフォーマンスへの影響が最小であり、オプションなしで新しい順序を作成する場合のデフォルト構成です。
  • NOCACHEおよびORDER: アプリケーションで連続した順序付けられた順序番号が必要な場合は、NOCACHEおよびORDERを使用します。NOCACHEとORDERの組合せは、その他のキャッシュおよび順序付けの組合せと比較すると、パフォーマンスに最も大きな影響を及ぼします。
  • NOCACHEおよびNOORDER: 制限された連続しない順序番号を政府規制または法律で必要とする場合は、NOCACHEおよびNOORDERを使用します。この構成では順序付けは保証されませんが、NOCACHEおよびORDERよりもパフォーマンスが向上します。

ノート:

Oracle Database 18c以降では、大規模な順序キャッシュを構成するかわりに、スケーラブルな順序を使用して、データのロードのスケーラビリティを向上させることができます。特に順序値が表の主キー列の移入に使用される場合、スケーラブルな順序により同時データ・ロード操作のパフォーマンスが向上します。

Oracle Database 23aiでは、順序付けエンキューのロック取得数を減らすことで、Oracle RAC環境で順序付けられた順序がパフォーマンスのために最適化されます。これらの改善では、手動操作や順序の変更は必要ありません。順序付けされた順序の最適化と、Oracle Database 19cで導入された順序キャッシュの自動サイズ設定機能によって、順序付けされた順序を使用するワークロードのパフォーマンスが向上します。

関連トピック

親トピック: Oracle RACの高可用性ベスト・プラクティス

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

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

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

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

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

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

$ srvctl status database -db mail

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

Instance mail1 is running on node node11
Instance mail2 is running on node node10

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

$ srvctl status pdb -db db_unique_name -pdb pdb_name

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

インスタンスが実行中であることを確認するための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として識別します。

関連トピック

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

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

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

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

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

ノート:

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

セッションを終了するには、次のステップに従います。

  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-5 ビジー状態のインスタンスでのセッションの特定および終了

この例で、実行しているセッションがインスタンス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-6 アイドル状態のインスタンスでのセッションの特定および終了

この例で、実行しているセッションがインスタンス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-7 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>

関連トピック

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

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パラメータ設定を変更します。

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

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

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

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

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

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

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

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

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

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

関連トピック

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

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 Database 23aiでサポートされなくなりました。

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

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 21c以降、結果キャッシュのフェッチ機能が強化されています。キャッシュされた結果をリモート・インスタンスからフェッチする前に、データベースはヒューリスティックを使用して、ローカル・インスタンスで結果を再計算するほうが効率的かどうかを判断します。この機能の使用を監視するには、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での初期化パラメータの使用

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

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

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

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

  • DML_LOCKS
  • RESULT_CACHE_MAX_SIZE

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

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

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

表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での初期化パラメータの使用

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の内部処理のために更新を実行していることがあるためです。また、オンライン・データファイルのヘッダーは、引き続きアクセス中であるかのように見えます。このファイル・ヘッダーの状態は、データベースが正しく停止された場合とは異なります。データベースが静止状態の間でも、オンライン・バックアップ操作は実行できます。

関連トピック

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

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

関連トピック

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

CLUSTER_INTERCONNECTSパラメータを設定するためのユース・ケース

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

ノート:

すべてのデータベースと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プラットフォームでの複数のクラスタ・インターコネクトの管理

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リソースは、影響を受けたデータベースの新しい値を記録します。

関連トピック

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

Oracle Enterprise Managerの高度な管理

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

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

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

ノードおよびインスタンスの検出のための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の高度な管理

Oracle Enterprise Managerのその他の機能

Oracle Enterprise Managerには、様々な管理機能があります。

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

  • 新しいプロシージャの動的前提条件により、My Oracle Supportに接続されていれば、Oracle Enterprise ManagerではOracle RACプロビジョニング用の最新の前提条件およびツールをダウンロードできます。

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

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

  • 既存の「Oracleデータベースのプロビジョニング」プロシージャでは、シングル・インスタンスのOracle Databaseのプロビジョニングがサポートされるようになりました。

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

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

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

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

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

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

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

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

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のジョブ・ウィザードの各ページに入力し、ジョブを作成します。

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でのジョブおよびアラートの管理

Oracle Enterprise Managerでの定義済一時停止の使用

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

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