| Oracle® Real Application Clusters管理およびデプロイメント・ガイド 11g リリース2 (11.2) B56290-06 |
|
 前 |
 次 |
この章では、Oracle Real Application Clusters(Oracle RAC)データベースおよびデータベース・インスタンスの管理方法について説明します。
内容は次のとおりです。
|
関連項目: Oracle Enterprise Managerの詳細は、Oracle Enterprise Managerのオンライン・ヘルプを参照してください。 |
次の項では、Oracle RACデータベースとインスタンスの管理に一般に使用される3つのツールである、Oracle Enterprise Manager、SQL*PlusおよびSRVCTLユーティリティを使用したOracle RAC管理について説明します。多くの場合、これらのツールを使用してOracle RAC環境を管理する方法は、非クラスタのOracle Databaseを管理する場合と同様です。
Oracle RAC 11g リリース2(11.2)より前は、DBAは、クラスタ内のノードに特定のOracle RACデータベース・インスタンスを割り当てるために、パラメータ(データベース・インスタンス番号やREDOスレッドなど)をハードコードする必要がありました。クラスタ内のノードが起動しないと、データベース・インスタンスは起動しません。Oracle RAC 11g リリース2(11.2.0.2)では、引き続きこの方法でOracle RACデータベースを管理できます。この方法で管理されるOracle RACデータベースは、管理者管理データベースと呼ばれています。管理者管理データベースには、11g リリース2(11.2)より前のOracle DatabaseおよびアップグレードされたOracle Databaseが含まれます。これらのデータベースは、以前のリリースのOracle Databaseで使用したものと同じコマンドまたは方法(DBCAやOracle Enterprise Managerなど)を使用して管理できます。すべてのコマンドおよびユーティリティに下位互換性があります。
Oracle RAC 11gリリース2(11.2)では、データベースをOracle Clusterwareのリソースとして定義します。リソースは、DBCAを使用してデータベースを作成すると自動的に作成され、DBCAを使用しない場合は、SRVCTLを使用してデータベースを追加することによって手動で追加できます。このリソースには、Oracleホーム、SPFILE、1つ以上のサーバー・プールおよびデータベースで必要な1つ以上のOracle ASMディスク・グループが含まれます。また、データベース・リソースにはVIPには弱い起動依存性があり、これは、データベース・インスタンスの起動時にリソースがそのノードのVIPを起動しようとすることです。VIPが正常に起動されない場合、インスタンスは起動されますが、サービスは起動されません。データベース・サービスのリソースは実行中のVIPに依存します。
管理者管理データベースのデータベース・リソースを確認すると、そのOracle Databaseと同じ名前で定義されたサーバー・プールが表示されます。このサーバー・プールは、Oracleで定義される特別なサーバー・プールの一部で、Genericと呼ばれます。Oracle RACは、Genericサーバー・プールを管理して管理者管理データベースをサポートします。SRVCTLまたはDBCAのいずれかを使用して管理者管理データベースを追加または削除すると、Genericのメンバーであるサーバー・プールがOracle RACによって作成または削除されます。Genericサーバー・プールの変更に、SRVCTLまたはCRSCTLコマンドを使用することはできません。
|
関連項目: リソース、サーバー・プールおよびリソースの依存性の定義については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle RAC 11g リリース2(11.2)では、ポリシー管理データベースが導入され、パラメータをハードコードする必要がなくなり、クラスタ内のノードの入替えや要件変更に伴うクラスタの拡張がより簡単になりました。ポリシー管理データベースを使用する場合は、クラスタ内のすべてのノードにOracleホーム・ソフトウェアをインストールする必要があります。ポリシー管理データベースは、Oracle Database 11g リリース2(11.2)を使用する必要があり、管理者管理データベースと同じサーバーに共存させることはできません。
|
注意: 同じノードで同じデータベースの複数のインスタンスを実行することはできません。 |
ポリシー管理データベースは、カーディナリティ(通常の操作で実行する必要があるデータベース・インスタンス数)で定義されます。ポリシー管理データベースは、CRS管理者ロールが割り当てられたユーザーがクラスタに作成した1つ以上のデータベース・サーバー・プールで実行することも、別のサーバーで異なるタイミングで実行することもできます。データベース・インスタンスは、データベースに定義されたサーバー・プール内のすべてのサーバーで起動されます。データベース記憶域に、Oracle Automatic Storage Management(Oracle ASM)およびOracle Managed Filesを使用していて、かつインスタンスの起動時に使用可能なREDOスレッドがない場合、Oracle RACは自動的にREDOスレッドを使用可能にし、必要なREDOログ・ファイルとUNDO表領域を作成します。クライアントは、その時点で実行されているサーバーに関係なく、同じSCANベース接続文字列を使用してポリシー管理データベースに接続することができます。
管理者管理データベースとポリシー管理データベースへの同じクラスタの使用
すでにポリシー管理データベースがホストされているクラスタに管理者管理データベースを作成する場合、管理者管理データベース用のノードは慎重に選択する必要があります。これは、管理者管理データベース用に選択したノードはポリシー管理サーバー・プールにあり、このプロセスの一部としてGenericサーバー・プールに移動されるためです。
すでに他のポリシー管理データベース・インスタンスを実行しているノードを選択した場合、DBCAが管理者管理データベースを作成する際に停止されるインスタンスおよびサービスがリストされたメッセージがDBCAによって表示されます。DBCAによって「続行しますか。」と尋ねられ、そのダイアログ・ボックスで「はい」を選択すると、ポリシー管理データベースのインスタンスおよびサービスは、管理者管理データベース作成プロセスの結果として停止されます。
|
注意: srvctl add instanceコマンドを使用した場合も同様で、データベースが停止されるという内容の同様のメッセージが返されます。srvctl add instanceコマンドで強制オプション(-f)を使用した場合も、DBCAダイアログで「はい」を選択するのと同じです。これにより、ノードをGenericサーバー・プールに移動する前に、そのノードで実行中の一部のポリシー管理データベースが停止されます。 |
Oracle Enterprise Managerでは、Oracle RAC環境を集中的に制御し、複数のクラスタ・データベースで同時に管理タスクを実行できます。これには、非クラスタ環境およびOracle RAC環境を管理するための2つのグラフィカル・ユーザー・インタフェース(GUI)、Database ControlおよびGrid Controlがあります。Oracle RACデータベースの各ノードに1つのOracle Enterprise Managerエージェントがあるため、Database Controlでは、そのデータベースのどのURLを使用しても、Oracle Enterprise Managerでデータベースを管理できます。
Oracle Enterprise Managerでは、通常、Oracle RAC固有の管理タスクは、クラスタ・データベース全体に関係するタスクおよび特定のインスタンスに関係するタスクの2つのレベルが中心です。たとえば、Oracle Enterprise Managerでは、ジョブのスケジュールやメトリックのアラートしきい値の設定に加え、データベース、クラスタ・データベース・インスタンスおよびそのリスナーを起動、停止および監視できます。または、パラメータの設定やリソース・プランの作成のようなインスタンス固有のコマンドを実行できます。また、Oracle Enterprise Managerを使用して、スキーマ、セキュリティおよびクラスタ・データベースの記憶域機能を管理できます。
|
関連項目:
|
SQL*Plusコマンドは、現行のインスタンスで動作します。現行のインスタンスは、SQL*Plusセッションを開始したローカルのデフォルト・インスタンスまたはOracle Net Servicesの接続先リモート・インスタンスです。
デフォルトでは、SQL*Plusのプロンプトで現行のインスタンスが識別されないため、正しいインスタンスにコマンドを発行する必要があります。SQL*Plusセッションを開始して、インスタンスを指定せずにデータベースに接続すると、すべてのSQL*Plusコマンドはローカル・インスタンスで処理されます。この場合も、デフォルト・インスタンスが現行のインスタンスです。
SQL*Plusで別のインスタンスに接続するには、次の例のように、新しいCONNECTコマンドを発行し、リモート・インスタンスのネット・サービス名を指定します(passwordはパスワードです)。
CONNECT user_name@net_service_name
Enter password: password
SYSOPERまたはSYSDBAで接続すると、インスタンスの起動や停止などの権限を必要とする操作を実行できます。複数のSQL*Plusセッションが、同時に同じインスタンスに接続できます。他のインスタンスに接続すると、SQL*Plusによって最初のインスタンスとの接続が自動的に切断されます。
|
注意: Oracle ASMインスタンスに接続し管理するには、SYSDBA権限ではなく、SYSASM権限を使用します。SYSDBA権限を使用してASMインスタンスで実行されるコマンドは非推奨であるため、SYSDBA権限を使用してOracle ASMインスタンスに接続すると、アラート・ログ・ファイルに警告が書き込まれます。
詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
|
関連項目:
|
現行のインスタンス名を含めるようにSQL*Plusのプロンプトを変更するには、次の手順を実行します。
SET SQLPROMPT '_CONNECT_IDENTIFIER> '
このコマンドは、大なり記号(>)の前の文字列「SQL」を、現行のセッションの継続時間中に現行のインスタンス名を表示するユーザー変数_CONNECT_IDENTIFIERに置換します。
すべてのセッションのプロンプトを自動的に変更するには、SQL*Plusの管理ディレクトリに含まれているglogin.sqlファイルに、次のようなエントリを追加します。
SET SQLPROMPT '_CONNECT_IDENTIFIER> '
コマンドの一重引用符の間には、必要な他のテキストまたはSQL*Plusユーザー変数を指定できます。
ほとんどのSQL文は、現行のインスタンスに適用されます。Oracle RACデータベースでのインスタンスの起動と停止に、SQL*Plusを使用できます。SQL*Plusコマンドを、LinuxおよびUNIXシステムのrootとして、またはWindowsシステムのAdministratorとして実行する必要はありません。非クラスタのOracle Databaseで通常使用する権限を持つ適切なデータベース・アカウントのみが必要です。SQL*Plusコマンドのインスタンスへの適用方法の例を示します。
ALTER SYSTEM CHECKPOINT LOCALは、デフォルトのインスタンスまたはすべてのインスタンスではなく、現在接続しているインスタンスにのみ適用されます。
ALTER SYSTEM CHECKPOINTまたはALTER SYSTEM CHECKPOINT GLOBALは、クラスタ・データベースのすべてのインスタンスに適用されます。
表3-1に、SQL*Plusコマンドのインスタンスへの適用方法を示します。
サーバー制御ユーティリティ(SRVCTL)は、シングル・ポイントからOracle RACデータベースを管理するためのコマンドライン・インタフェースです。SRVCTLを使用して、データベースおよびインスタンスの起動と停止、インスタンスおよびサービスの削除または移動を実行できます。また、SRVCTLを使用すると、クラスタ内の他のリソースに加え、サービスの追加および構成情報の管理を行うこともできます。
SRVCTLを使用してクラスタの構成操作を実行すると、SRVCTLは構成データをOracle Cluster Registry(OCR)に格納します。SRVCTLは、Oracle Clusterwareリソース(Oracle Call Interface APIを使用してデータベースの起動および停止操作を実行するエージェントを定義)を構成および管理することによって、インスタンスの起動および停止のようなその他の操作を実行します。
次の各項で説明するように、Oracle Enterprise Manager、SQL*PlusまたはSRVCTLを使用してインスタンスを起動および停止できます。Oracle Enterprise ManagerおよびSRVCTLでは、Oracle RACデータベースのすべてのインスタンスの起動および停止を1つの手順で行うオプションを提供しています。
データベースがNOMOUNTまたはMOUNT状態の場合は、特定の操作のみ実行できます。他の操作を実行するには、データベースがOPEN状態である必要があります。また、操作によっては、1つのインスタンスのみが必須状態になっている必要があったり、すべてのインスタンスが同一状態になっている必要があります。
|
注意: 同じノードで同じデータベースの複数のインスタンスを実行することはできません。 |
次の各項の手順では、Oracle RACデータベース・インスタンスの起動および停止について説明します。
Oracle RACインスタンスを起動する前に、クラスタウェアと使用するオペレーティング・システム固有の必須プロセスが実行されている必要があります。これらのプロセスの詳細は、ご使用のオペレーティング・システムのマニュアルを参照してください。
Oracle RACインスタンスの停止手順は、ここで説明する例外を除いて、非クラスタのOracle Databaseインスタンスの停止と同じです。
|
関連項目: Oracle Databaseの停止の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
Oracle RACデータベースを完全に停止するには、データベースがオープン状態またはマウントされた状態となっているすべてのインスタンスを停止します。
NORMALまたはIMMEDIATEでの停止後は、インスタンスのリカバリは不要です。ただし、SHUTDOWN ABORTコマンドを発行した後、またはインスタンスが異常終了した後は、リカバリが必要です。まだ実行中のインスタンスが、停止したインスタンスに対してインスタンス・リカバリを実行します。他に実行中のインスタンスがない場合は、次にデータベースをオープンするインスタンスが、リカバリが必要なすべてのインスタンスのリカバリを実行します。
LOCALオプションを指定したSHUTDOWN TRANSACTIONALコマンドは、インスタンス上のすべてのアクティブ・トランザクションがコミットまたはロールバックされた後に、そのインスタンスを停止する場合に有効です。これは、このコマンドがSHUTDOWN IMMEDIATEの場合に実行する機能とは別の機能です。他のインスタンス上のトランザクションがこの操作を妨げることはありません。LOCALオプションを省略した場合、この操作は、停止コマンドを発行する前に起動された他のすべてのインスタンス上のトランザクションがコミットまたはロールバックされるまで待機します。
Oracle Enterprise Managerを使用してクラスタ・データベース・インスタンスまたはクラスタ・データベースを起動または停止する手順については、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。
|
注意: この項では、SPFILEを使用していることを前提にしています。 |
ローカル・ノードに接続された状態で、1つのインスタンスのみを起動または停止するには、事前に現行の環境にローカル・インスタンスのSIDが含まれていることを確認する必要があります。SQL*Plusセッションかどうかに関係なく、セッション内の後続のすべてのコマンドは、そのSIDに対応付けられます。
ローカル・インスタンスを起動または停止するには、SQL*Plusセッションを開始し、SYSDBAまたはSYSOPER権限で接続した後に、必要なコマンドを発行します。たとえば、ローカル・ノード上でインスタンスを起動しマウントする場合は、SQL*Plusセッション内で次のコマンドを実行します。
CONNECT / AS SYSDBA STARTUP MOUNT
|
注意: Oracle ASMディスク・グループを使用する場合は、SYSDBA権限ではなく、SYSASM権限を使用してASMインスタンスに接続し、管理します。詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
Oracle Net Servicesを使用して、単一のSQL*Plusセッションから複数のインスタンスを起動できます。Net Services接続文字列(通常は、TNSNAMES.ORAファイルからのインスタンス固有の別名)を使用して、各インスタンスに順次接続します。
|
注意: 正しいインスタンスに接続するには、接続文字列で1つのインスタンスにのみ対応付けられた別名を使用する必要があります。サービスの別名または複数のアドレスを持つ別名を使用すると、目的のインスタンスに接続されない場合があります。 |
たとえば、ローカル・ノード上でSQL*Plusセッションを使用すると、インスタンスの個々の別名を使用して、各インスタンスに順次接続し、リモート・ノード上の2つのインスタンスのトランザクションの停止を実行できます。最初のインスタンスの別名をdb1、2つ目のインスタンスの別名をdb2と仮定します。次のコマンドを入力して、最初のインスタンスに接続してから停止します。
CONNECT /@db1 AS SYSDBA SHUTDOWN TRANSACTIONAL
次のコマンドを入力して、SQL*Plusセッションから2つ目のインスタンスに接続した後、停止します。
CONNECT /@db2 AS SYSDBA SHUTDOWN TRANSACTIONAL
SQL*Plusでは複数のインスタンスを同時に起動または停止することはできないため、単一のSQL*Plusコマンドでクラスタ・データベースのすべてのインスタンスを起動または停止することはできません。各インスタンスに順次接続し、起動および停止するスクリプトを作成することができます。ただし、インスタンスの追加または削除を行う場合は、このスクリプトを手動でメンテナンスする必要があります。
|
関連項目: NOMOUNT、MOUNT、IMMEDIATEなどの他の起動および停止のキーワードについては、 |
|
注意: この項では、データベースにSPFILEを使用していることを前提にしています。 |
次のSRVCTL構文をコマンドラインから入力し、必要なデータベース名およびインスタンス名を提供するか、または複数のインスタンス名を指定して、複数の特定のインスタンスを起動します。
管理者管理データベースを起動する場合は、インスタンス名のカンマ区切りリストを入力します。
$ srvctl start instance -ddb_unique_name-iinstance_name_list[-ostart_options]
Windowsでは、カンマ区切りリストを二重引用符("")で囲む必要があります。
ポリシー管理データベースを起動する場合は、単一のノード名を入力します。
$ srvctl start instance -ddb_unique_name-nnode_name[-ostart_options]
また、このコマンドでは、使用可能で実行されていないすべてのサービスが開始されます。そのサービスには、AUTOMATIC管理ポリシーが設定され、サービスのいずれかのロールがデータベース・ロールと一致します。
1つ以上のインスタンスを停止するには、コマンドラインから次のSRVCTL構文を入力します。
$ srvctl stop instance -ddb_unique_name[ -i "instance_name_list" | -nnode_name] [ -ostop_options]
複数のインスタンス名のカンマ区切りリストを指定して複数のインスタンスを停止することも、1つのノード名を指定して1つのインスタンスを停止することもできます。Windowsでは、カンマ区切りリストを二重引用符("")で囲む必要があります。
このコマンドにより、インスタンスが実行されていたノード上で終了したインスタンスと関連するサービスも停止します。例のとおり、次のコマンドで、immediate stopオプションを使用してorclデータベースの2つのインスタンス(orcl3およびorcl4)を停止することができます。
$ srvctl stop instance -d orcl -i "orcl3,orcl4" -o immediate
クラスタ・データベース全体(すべてのインスタンスおよび使用可能なサービス)を起動または停止するには、次のSRVCTLコマンドを入力します。
$ srvctl start database -d db_unique_name [-o start_options]
$ srvctl stop database -d db_unique_name [-o stop_options]
たとえば、次のSRVCTLコマンドは、Oracle RACデータベースの実行中でないすべてのインスタンスをマウントします。
$ srvctl start database -d orcl -o mount
ノードで実行中のインスタンスを確認するには、SQL*Plusプロンプトから次のコマンドを入力します。passwordはパスワードです。
CONNECT SYS/as SYSDBA
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に示します。
ALTER SYSTEM KILL SESSION文を使用して、特定のインスタンスのセッションを終了できます。セッションが停止すると、そのセッションのアクティブ・トランザクションがロールバックされ、そのセッションが保持していたリソース(ロックやメモリー領域など)がただちに解放されて、他のセッションで使用可能になります。
この文を使用すると、Oracle RAC環境で厳密なアプリケーション品質保証契約を維持できます。多くの場合、品質保証契約は、指定された期限内にトランザクションを実行することを目的としています。Oracle RAC環境では、このためには、指定された期限内にインスタンスでトランザクションを終了し、別のインスタンスでトランザクションを再試行することが必要な場合があります。
セッションを終了するには、次の手順に従います。
GV$SESSION動的パフォーマンス・ビューのINST_ID列の値を問い合せ、どのセッションを終了するかを特定します。
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文を実行してインスタンスでセッションを終了します。
|
関連項目: Oracle Enterprise Managerを使用したこれらの手順の例は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。 |
この例で、実行しているセッションがインスタンス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>
この例で、実行しているセッションがインスタンス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>
次の例には、未完了のアクティビティが完了するのを待機せずにただちにセッションを終了する、オプションの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 Database管理者ガイド』を参照してください。 |
データベースを作成すると、指定したファイルの位置にSPFILEが作成されます。ファイルの位置として指定できるのは、Oracle ASMディスク・グループ、クラスタ・ファイル・システムまたは共有RAWデバイスのいずれかです。手動でデータベースを作成する場合は、初期化パラメータ・ファイル(PFILE)からSPFILEを作成することをお薦めします。
|
注意: Oracle RACで従来のPFILEが使用されるのは、SPFILEが存在しないか、STARTUPコマンドでPFILEを指定した場合のみです。管理の単純化、パラメータ設定の一貫性の維持、データベースの停止および起動イベント全体にわたるパラメータ設定の永続性の保証のために、SPFILEを使用することをお薦めします。また、SPFILEをバックアップするようにRMANを構成することもできます。 |
クラスタ・データベース内のすべてのインスタンスは、起動時に同じSPFILEを使用します。SPFILEはバイナリ・ファイルであるため、エディタを使用して直接編集しないでください。かわりに、Oracle Enterprise ManagerまたはSQL文ALTER SYSTEMを使用して、SPFILEパラメータ設定を変更します。
SPFILEの作成時に、FROM MEMORY句(CREATE PFILE FROM MEMORYやCREATE SPFILE FROM MEMORYなど)を含める場合、CREATE文では、現行のシステム全体のパラメータ設定を使用して、PFILEまたはSPFILEが作成されます。Oracle RAC環境では、作成されたファイルには各インスタンスからのパラメータ設定が含まれています。FROM MEMORY句では、パラメータ・ファイルを作成しようとしているインスタンスに他のすべてのインスタンスがパラメータ設定を送信する必要があるため、合計実行時間は、インスタンスの数、各インスタンスのパラメータ設定の数およびそれらの設定のデータ量によって異なります。
この項の内容は次のとおりです。
SPFILEの設定は、Oracle Enterprise ManagerまたはALTER SYSTEM文のSET句を使用して変更できます。
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=MEMORY;
次に、他のインスタンスで次の文を実行すると、SIDがprod1であるインスタンスの新しい設定も2000になります。
ALTER SYSTEM SET OPEN_CURSORS=2000 sid='*' SCOPE=MEMORY;
たとえば、サーバー・パラメータ・ファイルに次のエントリが含まれるとします。
prod1.OPEN_CURSORS=1000
*.OPEN_CURSORS=500
次の文を実行して、Oracle Databaseでサーバー・パラメータ・ファイルの最初のエントリが無視されるようにします。
ALTER SYSTEM RESET OPEN_CURSORS SCOPE=SPFILE;
次の文を実行して、prod1のインスタンスのみのパラメータをデフォルト値にリセットします。
ALTER SYSTEM RESET OPEN_CURSORS SCOPE=SPFILE SID='prod1';
Oracle Databaseでは、プラットフォームに応じてパラメータ・ファイルが特定の順序で検索されます。
LinuxおよびUNIXプラットフォームでは、検索順序は次のとおりです。
$ORACLE_HOME/dbs/spfilesid.ora
$ORACLE_HOME/dbs/spfile.ora
$ORACLE_HOME/dbs/initsid.ora
Windowsプラットフォームでは、検索順序は次のとおりです。
%ORACLE_HOME%\database\spfilesid.ora
%ORACLE_HOME%\database\spfile.ora
%ORACLE_HOME%\database\initsid.ora
リカバリのために、サーバー・パラメータ・ファイルを定期的にバックアップすることをお薦めします。これには、Oracle Enterprise Manager(『Oracle Database 2日でReal Application Clustersガイド』を参照)またはCREATE PFILE文を使用します。次に例を示します。
CREATE PFILE='?/dbs/initdbname.ora'
FROM SPFILE='/dev/vx/rdsk/oracle_dg/dbspfile'
Recovery Manager (RMAN)を使用して、サーバー・パラメータ・ファイルのバックアップを作成できます。SPFILEは、クライアント側の初期化パラメータ・ファイルを使用してインスタンスを起動することによって、リカバリすることもできます。その後、CREATE SPFILE文を使用して、サーバー・パラメータ・ファイルを再生成します。この操作に使用されるパラメータ・ファイルがシングル・インスタンス用である場合、Oracle RACインスタンスで一意であっても、パラメータ・ファイルにはインスタンス固有の値は含まれません。したがって、前述のようにパラメータ・ファイルに適切な設定が含まれていることを確認してください。
通常のバックアップ操作の実行中にSPFILE(および制御ファイル)が自動的にRMANによってバックアップされるようにするには、Oracle Enterprise ManagerまたはRMANのCONTROLFILE AUTOBACKUP文を使用して、RMANの自動バックアップ機能を使用可能にします。
|
関連項目:
|
デフォルトでは、ほとんどのパラメータがデフォルト値に設定されていて、すべてのインスタンスで同じ値です。ただし、多くの初期化パラメータに対しては、表3-3に記載されているとおり、各インスタンスで別々の値も設定できます。これ以外のパラメータは、次の項で説明されているように、一意または同一である必要があります。
表3-3に、Oracle RACデータベースで特に使用される初期化パラメータのサマリーを示します。
|
関連項目: これらの初期化パラメータとその他の初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。 |
表3-3 Oracle RACに固有の初期化パラメータ
| パラメータ | 説明 |
|---|---|
|
この初期化パラメータはOracle RAC 11gリリース2(11.2)では非推奨です。かわりに、1つの優先インスタンスと1つの使用可能なインスタンスを伴うサービスを使用します。 |
|
|
ミラー・データのコピーの読取り元の優先ディスクにする一連のディスクを指定します。このパラメータに設定する値はインスタンス固有で、すべてのインスタンスで同じにする必要はありません。 |
|
|
クラスタ・モードで起動するデータベースを使用可能にするパラメータです。このパラメータを |
|
|
Oracle RACはこのパラメータを使用して、十分なメモリー・リソースを割り当てます。すべてのインスタンスに同じ値を設定する必要があります。
また、インスタンスを追加する場合、現行のインスタンスの数より大きい値をこのパラメータに設定できます。ポリシー管理データベースで、このパラメータにより大きい値を設定する必要があるのは、16を超えるインスタンスでデータベースを実行する場合のみです。この場合、パラメータには、このデータベースを実行するインスタンスの予想最大数を設定します。 |
|
|
|
複数のインターコネクトが存在する場合、プライベート・ネットワークの代替クラスタ・インターコネクトを指定します。 注意:
|
|
インスタンス固有のパラメータ・ファイルで |
|
|
少なくとも、 DISPATCHERSパラメータとその属性の構成、および共有サーバーの構成の詳細は、『Oracle Database Net Services管理者ガイド』 |
|
|
この静的パラメータでは、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プロセスがあることになります。異なるインスタンスで、このパラメータを異なる値に設定できます。 |
|
|
一意のインスタンス名を指定します。クライアントは、この名前を使用して、セッションをクラスタ内の特定のインスタンスに強制的に接続します。通常、 注意: グリッドのプラグ・アンド・プレイ環境では、 |
|
|
クラスタ化されたデータベースでは、すべてのインスタンスで
|
|
|
サービスを使用する場合は、 注意: |
|
|
SPFILEを使用する場合は、Oracle RACデータベースのすべてのインスタンスがSPFILEを使用し、このファイルが共有記憶域に存在する必要があります。 |
|
|
インスタンスで使用されるREDOスレッドの数を指定します。使用可能な未使用のREDOスレッド番号であれば、どれでも指定できます。指定する場合、このパラメータの値はすべてのインスタンスに対して一意である必要があります。 |
データベースの作成に重要な特定の初期化パラメータ、または特定のデータベース操作に影響する特定の初期化パラメータは、Oracle RACデータベースの各インスタンスで同じ値を設定する必要があります。これらのパラメータ値は、SPFILEに指定するか、または各インスタンスの個別のPFILEで指定します。次のリストに、すべてのインスタンスで同一である必要があるパラメータを示します。
COMPATIBLECLUSTER_DATABASECLUSTER_DATABASE_INSTANCESCONTROL_FILESDB_BLOCK_SIZEDB_DOMAINDB_FILESDB_NAMEDB_RECOVERY_FILE_DESTDB_RECOVERY_FILE_DEST_SIZEDB_UNIQUE_NAMEINSTANCE_TYPE(RDBMSまたはASM)PARALLEL_EXECUTION_MESSAGE_SIZEREMOTE_LOGIN_PASSWORDFILEUNDO_MANAGEMENT
すべてのインスタンスで、次のパラメータを同じにする必要があるのは、パラメータの値が0(ゼロ)に設定されている場合のみです。
DML_LOCKSRESULT_CACHE_MAX_SIZEポリシー管理データベースで一意の設定を持つパラメータを設定する必要がある場合は、データベースのサーバー・プールに割り当てられる各サーバーに対してsrvctl modify instance -n node_name -i instance_nameコマンドを実行することにより、インスタンスが特定のノードで常に同じ名前を使用するようにできます。その後、パラメータの一意の値をinstance_nameに指定できます(この値は、node_name上でデータベースが実行されるときに使用されます)。
データベース名と、インスタンスに割り当てられたINSTANCE_NAME番号で構成される環境変数ORACLE_SIDを指定します。
CLUSTER_INTERCONNECTS初期化パラメータを使用して、Oracle Clusterwareがプライベート・ネットワークに使用している代替インターコネクトを指定します。CLUSTER_INTERCONNECTS初期化パラメータを設定すると、Oracle RACデータベースの各インスタンスに対して一意の値が使用されます。
Oracle Databaseは、INSTANCE_NUMBERパラメータを使用して起動時にインスタンスを識別し、INSTANCE_NAMEパラメータを使用して特定のインスタンスにREDOログ・グループを割り当てます。インスタンス名はdb_unique_name_instance_numberの形式にすることが可能で、名前と番号がアンダースコアで区切られたこの形式の場合、アンダースコアの後の番号がINSTANCE_NUMBERとして使用されます。グリッドのプラグ・アンド・プレイを使用するOracle Database 11.2では、ポリシー管理データベースのインスタンス番号を明示的に割り当てる必要がなくなり、インスタンス名はデフォルトのdb_unique_name_instance_numberに設定され、Oracle Databaseによってインスタンス番号が割り当てられます。
自動UNDO管理を使用可能にしてUNDO_TABLESPACEを指定する場合、各インスタンスでこのパラメータに一意のUNDO表領域名を設定します。
ROLLBACK_SEGMENTSパラメータを使用する場合は、SPFILEでSID識別子を使用して、これらのパラメータに一意の値を設定することをお薦めします。ただし、各インスタンスのINSTANCE_NUMBERに一意の値を設定する必要があり、デフォルト値は使用できません。
ASM_PREFERRED_READ_FAILURE_GROUPS初期化パラメータを使用すると、優先読取り障害グループ名のリストを指定できます。これらの障害グループのディスクは、優先読取りディスクになります。したがって、すべてのノードはそのローカル・ディスクから読み取ることができます。この結果、効率およびパフォーマンスが向上し、ネットワーク・トラフィックが削減されます。このパラメータの設定はインスタンス固有で、すべてのインスタンスで同じにする必要はありません。
表3-4のパラメータには、すべてのインスタンスで同じ値を設定することをお薦めします。これらのパラメータにはインスタンスごとに異なる値を設定できますが、すべてのインスタンスでパラメータに同じ値を設定すると管理が簡単です。
表3-4 すべてのインスタンスで同じ値を設定する必要があるパラメータ
| パラメータ | 説明 |
|---|---|
|
Oracle RACデータベースのインスタンスごとに異なる値を設定すると、データベース処理によって追加の自動同期化が実行されるため、多くの場合、オーバーヘッドが増加します。 Oracle RACデータベースでStreamsを使用する場合、0(ゼロ)より大きい値を使用する必要があります。 |
|
|
このパラメータでは、データベースに定義されるユーザー数のデータベース全体における制限が決定されるため、このパラメータにはデータベースのすべてのインスタンスに同じ値を指定して、どのインスタンスの使用時にも現在の値を確認できるようにすると便利です。異なる値を設定すると、インスタンスの起動時にOracle Databaseによって追加で警告メッセージが生成されたり、データベース・ユーザーの管理に関連するコマンドが一部のインスタンスで失敗する可能性があります。 |
|
|
すべてのインスタンスで同じ値を使用しない場合、メディア・リカバリが複雑になります。アーカイブ・ログ・ファイルを作成したインスタンスにかかわらず、リカバリを行うインスタンスでは、必要なアーカイブ・ログ・ファイル名のフォーマットがそのインスタンス自体の Data Guardをサポートするデータベースでは、アーカイブREDOログ・ファイルの送受信を行うために、すべてのインスタンスで |
|
|
すべてのインスタンスでこのパラメータに同じファイルを指定しない場合、各インスタンスは、フェイルオーバー、ロード・バランシングおよび通常の操作中に、異なる動作または予測できない動作を行う場合があります。また、 サーバーによって値が設定されているインスタンスでSPFILEの値が異なる場合、デフォルトのSPFILEを使用していないインスタンスを再起動する必要があります。 |
|
|
診断トレース情報をOracle RACデータベースで常に使用可能にするには、すべてのデータベース・インスタンスで |
|
|
各インスタンスで |
次のように、管理者管理データベースをポリシー管理データベースに変換できます。
すべてのサービスとデータベースの現在の構成を確認します(間違いがあったためにリカバリが必要な場合、元の構成がどうであったかを確認できます)。
srvctl config database -d db_unique_name srvctl config service -d db_unique_name
|
注意: デフォルトでは、指定されたユーザーがサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するために、CRS管理者リストに特定のユーザーを追加することを強くお薦めします。 |
|
関連項目: CRS管理者リストへのユーザーの追加については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
次のように、ポリシー管理データベースに対してサーバー・プールを作成します(CRS管理者権限を持っている必要があります)。
srvctl add srvpool -g server_pool -l 0 -u n
前述のコマンドのnは、サーバー・プールで必要とするサーバーの数です。
新しいサーバー・プールに存在するようにデータベースを変更します。
srvctl modify database -d db_unique_name -g server_pool
手順1のコマンドを繰り返してデータベースのステータスを確認し、データベースがポリシー管理になったことを確認します。
次のように、前述の手順で行った変更を認識させるために、Oracle Enterprise Managerを構成します。
Oracle Enterprise Manager Database Controlに新しいデータベース・インスタンスを認識させるために、インスタンス名をdb_unique_name#からdb_unique_name_#に変更(シャープ記号(#)の前にアンダースコア(_)を追加)する必要があります。
dbs/databaseディレクトリ内のorapwdファイルの名前を変更します(または、orapwdコマンドを実行して、新しいorapwdファイルを作成します)。
デフォルトのorapwdファイルには、orapwdORCL1などのようにインスタンス名が付加されています。前述の手順で変更したインスタンス名に対応するように、ファイル名を変更する必要があります。たとえば、orapwdORCL1をorapwdORCL_1に変更するか、または新しいorapwdファイルを作成する必要があります。
次のように、emcaを実行して、Oracle Enterprise Manager Database Controlを再構成します。
emca -config dbcontrol db -cluster
ポリシー管理データベースを管理者管理データベースに直接変換することはできません。その場合は、srvctl remove databaseコマンドおよびsrvctl remove serviceコマンドでポリシー管理構成を削除してから、srvctl add databaseコマンドおよびsrvctl add instanceコマンドで同じデータベースを管理者管理データベースとして登録します。データベースおよびインスタンスの登録後に、srvctl add serviceコマンドを使用して、削除したサービスを元どおりに追加する必要があります。
管理者管理データベースのサービスは、引き続きPREFERREDおよびAVAILABLE定義によって定義されます。ポリシー管理データベースの場合、サービスはデータベース・サーバー・プールに対して定義され、uniform(サーバー・プール内のすべてのインスタンスで実行)またはsingleton(サーバー・プール内の単一インスタンスでのみ実行)のいずれかになります。データベースの管理ポリシーを変更した場合、選択したデータベースの管理ポリシーに応じて、UNIFORMかSINGLETON、またはPREFERRED/AVAILABLEのいずれかになるように、データベース・サービスを再作成する必要があります。
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環境のすべてのインスタンスに適用されます。
|
関連項目:
|
UDP IPCが使用可能なLinuxおよびUNIXプラットフォームで実行するOracle RAC環境では、CLUSTER_INTERCONNECTS初期化パラメータを使用して、Oracle Clusterwareがプライベート・ネットワークのために使用する代替インターコネクトを指定できます。
CLUSTER_INTERCONNECTSに複数の値を設定した場合、指定したすべてのインターコネクトが使用され、指定したインターコネクトがすべて動作可能であれば、ロード・バランシングが行われます。このパラメータで複数のインターコネクトを定義する場合、データベースのすべてのインスタンスで同じ値(インターコネクトをリストする順序を含む)を使用する必要があります。
オペレーティング・システム・レベルでデフォルトのインターコネクト設定を上書きするCLUSTER_INTERCONNECTSパラメータを設定することはお薦めしません。かわりに、オペレーティング・システムのボンディング技術(NIC(ネットワーク・インタフェース・カード)ボンディングとも呼ばれます)を使用します。オペレーティング・システム・レベルで NICボンディングを設定する方法については、使用しているプラットフォーム固有のOracle RACのインストレーション・ガイドを参照してください。
この項の内容は次のとおりです。
CLUSTER_INTERCONNECTS初期化パラメータでは、IPアドレスが必要です。コロン(:)で区切って、複数のIPアドレスを指定できます。Oracle RACネットワーク・トラフィックは、指定されたIPアドレス間で分散されます。
|
注意:
|
一般に、CLUSTER_INTERCONNECTSパラメータは、次の場合にのみ設定します。
オペレーティング・システムの制限により、NICボンディングによる複数のネットワーク・インタフェースを使用して、帯域幅を増加させることができない場合。
オペレーティング・システムによって高可用性が実現された単一の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パラメータの使用例」を参照してください。
CLUSTER_INTERCONNECTSパラメータに指定したインターコネクトへの書込み中にオペレーティング・システム・エラーが発生した場合は、他のインタフェースが使用可能な場合でも、Oracle Databaseによってエラーが戻されます。これは、Oracle Databaseとインターコネクトの間の通信プロトコルが、使用しているプラットフォームに大きく依存する場合があるためです。詳細は、ご使用のOracle Databaseのプラットフォーム固有のマニュアルを参照してください。
|
関連項目: CLUSTER_INTERCONNECTS初期化パラメータの詳細は、『Oracle Databaseリファレンス』 |
この項では、CLUSTER_INTERCONNECTSパラメータを設定する場合の2つの例について説明します。
単一のクラスタ・インターコネクトで帯域幅の要件を満たすことができない場合は、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
デバイスのIPアドレスを表示するには、ifconfigまたはnetstatコマンドを使用します。このコマンドは、デバイス名とIPアドレスの関係を表示します。たとえば、デバイスのIPアドレスを特定するには、次のコマンドをrootユーザーで実行します。
# /usr/sbin/ifconfig -a
fta0: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,SIMPLEX>
inet 192.34.137.212 netmask fffffc00 broadcast 192.34.139.255 ipmtu 1500
lo0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
inet 172.0.0.1 netmask ff000000 ipmtu 4096
ics0: flags=1100063<UP,BROADCAST,NOTRAILERS,RUNNING,NOCHECKSUM,CLUIF>
inet 10.0.0.1 netmask ffffff00 broadcast 10.0.0.255 ipmtu 7000
sl0: flags=10<POINTOPOINT>
tun0: flags=80<NOARP>
前述の例では、インタフェースfta0:のIPアドレスは192.34.137.212で、インタフェースics0:のIPアドレスは10.0.0.1です。
たとえば、すべてのGCS、GESおよびIPQ IPCトラフィックに対して、IPアドレスが192.34.137.212であるネットワーク・インタフェースを使用するには、CLUSTER_INTERCONNECTSパラメータを次のように設定します。
CLUSTER_INTERCONNECTS=192.34.137.212
デフォルトでは、Oracle ClusterwareによってOracle RAC環境のデータベースの再起動が制御されます。たとえば、データベースのアップグレード中など、場合によっては、Oracle ClusterwareのOracle RACデータベースに対する制御レベルを最小限に抑える必要があることがあります。
|
注意: サード・パーティのクラスタウェアを使用する場合は、Oracle ClusterwareでOracle RACインスタンスを管理できるようにすることをお薦めします。インスタンスを手動に設定し、そのインスタンスをサード・パーティのクラスタウェアで起動する場合は、データベース・インスタンスの監視および再起動にサード・パーティのクラスタウェアを使用せずに、必ずOracle Clusterwareで行ってください。 |
システムの再起動時にOracle ClusterwareによるOracle RACデータベースの再起動を防止する場合、または障害が発生したインスタンスの2回目以降の再起動を回避する場合、制御の程度を定義するポリシーを構成します。ポリシーには、自動(デフォルト)と手動の2つがあります。ポリシーが自動に設定されると、データベースは、データベース・ホスト・コンピュータの再起動時に、前回の実行状態(開始または停止した状態)に自動的にリストアされます。手動の場合、データベースは、データベース・ホスト・コンピュータの再起動時に、自動的に再起動されることはありません。手動に設定しても、Oracle Restartは、実行中のデータベースを監視し、障害発生時にデータベースを再起動します。
SRVCTLコマンドを使用して、次の例に示すように、Oracle Clusterwareのポリシーを表示および変更できます。
たとえば、現行のポリシーを表示するには、次のコマンド構文を使用します。ここで、db_unique_nameは、ポリシーを変更するデータベース名です。
srvctl config database -d db_unique_name -a
次のSRVCTLコマンド構文を使用して、現行のポリシーをAUTOMATICまたはMANUALのいずれかに変更します。
srvctl modify database -d db_unique_name -y [AUTOMATIC | MANUAL]
このコマンド構文は、データベース・リソースのリソース属性を設定します。
SRVCTLコマンドを使用して新しいデータベースを追加する場合、次の例のように-yオプションを使用して管理ポリシーをAUTOMATICまたはMANUALのいずれかに指定できます(ここで、db_unique_nameはデータベース名です)。
srvctl add database -d db_unique_name -y [AUTOMATIC | MANUAL] -o $ORACLE_HOME -a DATA
このコマンド構文によって、新しいデータベースがOracle Clusterwareに制御されるようになります。管理ポリシー・オプションを指定しないと、Oracle Databaseによってデフォルト値automaticが使用されます。ポリシー変更を行うと、影響を受けたデータベースの新しい値がOracle Clusterwareリソースによって記録されます。
Oracle Enterprise Manager Database ControlまたはOracle Enterprise Manager Grid Controlのいずれかを使用して、集中的にOracle RACデータベースをインストール、構成および監視できます。
この項では、『Oracle Database 2日でReal Application Clustersガイド』や「Oracle RACデータベースの監視およびチューニングの概要」で取り上げられていない高度な管理タスクについて説明します。
|
関連項目: Oracle Enterprise Managerを使用してOracle RACデータベースの日常的な管理タスクを実行する方法を説明するタスク指向型ガイドについては、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。 |
この項の内容は次のとおりです。
Oracle Enterprise ManagerでOracle RACデータベースおよびインスタンスのターゲットを検出すると、コンソールから監視および管理を実行できます。
Database Controlでは、データベース作成中にDBCAが必要な構成を実行するため、検出は必要ありません。Database Controlは、単一のデータベースも監視します。
Grid Controlでは、Oracle Enterprise Managerコンソール・インタフェースを使用してOracle RACデータベースおよびインスタンス・ターゲットを検出できます。
Oracle RACデータベースが存在するクラスタにGrid Controlエージェントをインストールすると、Oracle RACデータベース・ターゲットはインストール時に検出されます。エージェントのインストール後にデータベースが作成される場合またはエージェントのインストール時にデータベースが自動的に検出されない場合は、コンソール・インタフェースを使用してターゲットを検出できます。
ノードおよびインスタンスを検出するには、次のようにOracle Enterprise Manager Grid Controlを使用します。
Oracle Enterprise Managerにログインし、「ターゲット」タブをクリックします。
「データベース」タブをクリックすると、使用可能なターゲットがすべて表示されます。「タイプ」列に、「クラスタ・データベース」というエントリを使用するOracle RACデータベースが表示されます。
ターゲット名を選択して「追加」をクリックし、このデータベース・ターゲットを追加します。「データベースターゲットの追加: ホストの指定」ページが表示されるので、このページで、データベース、リスナーおよびOracle ASMを監視ターゲットとして追加できます。
懐中電灯のアイコンをクリックして使用可能なホスト名を表示し、ホストを選択して「続行」をクリックします。「データベースの追加: ソースの指定」ページが表示されます。
Oracle Enterprise Managerを使用して非クラスタのデータベースおよびリスナーのみを検出するか、またはすべてのクラスタ・データベース、非クラスタのデータベースおよびクラスタのリスナーを検出するかを指定し、「続行」をクリックします。
この手順で、再構成したクラスタ・データベースおよびそのすべてのインスタンスが検出されなかった場合は、「クラスタでターゲットが検出されました」ページでクラスタ・データベースおよび非クラスタ・データベースを手動で構成できます。
この項では、Oracle Enterprise Manager 11g リリース2(11.2)とともに使用できるOracle Enterprise Managerの機能について説明します。
新しいデプロイメント手順(「Oracleグリッド・インフラストラクチャ/RACプロビジョニング」)では、Oracle RAC 11g リリース2(11.2)およびOracle Grid Infrastructureがプロビジョニングされます。また、この手順では、プロファイルと呼ばれる機能が導入されるため、入力を記録しておいて、その後に繰り返されるデプロイメントでこの記録を使用できます。
新しい手順の動的前提条件では、My Oracle Support(以前のOracleMetaLink)に接続されていれば、Oracle Enterprise ManagerはOracle RACプロビジョニング用の最新の前提条件とツールをダウンロードできます。
既存の「ワンクリックでクラスタ・データベース拡張」機能は、現在、Oracle RAC 11g リリース2(11.2)スタックをサポートしています。
既存の「Oracle Real Application Clustersの削除/縮小」機能は、Oracle RAC 11g リリース2(11.2)のクラスタで動作が保証されています。
既存の「Oracleデータベースのプロビジョニング」手順は、現在、Oracle Database 11g リリース2(11.2)のシングル・インスタンスのプロビジョニングをサポートしています。
非クラスタ・データベース用のOracle Grid Infrastructure 11g リリース2(11.2)をプロビジョニングするために、新しいデプロイメント手順(「スタンドアロン・サーバー用のOracle Grid Infrastructureのプロビジョニング」)が導入されました。
クラスタ・データベースの「ホーム」ページには、Oracle RACデータベースのすべてのインスタンスが表示され、サーバー管理のために自動ワークロード・リポジトリ(AWR)が収集するいくつかのOracle RAC固有の統計の集計が提供されます。
その詳細を表示するために、インスタンス固有のページに移動する必要はありません。ただし、クラスタ・データベースの「ホーム」ページでは、稼働しているはずのインスタンスが停止したり、インスタンスで多数のアラートが発生している場合は、各アラートについてインスタンス固有のページにドリルダウンできます。
この項で後述する管理タスクを実行するには、ターゲットOracle RACデータベースにログインし、クラスタ・データベースの「ホーム」ページに移動し、「管理」タブをクリックします。
この項の内容は次のとおりです。
Oracle Enterprise Managerジョブは、データベース・レベルでもインスタンス・レベルでも管理できます。たとえば、クラスタ・データベース・レベルでジョブを作成し、そのジョブをターゲットOracle RACデータベースのアクティブな任意のインスタンスで実行できます。または、インスタンス・レベルでジョブを作成し、それを作成した特定のインスタンスでのみ実行することもできます。障害が発生した場合、再起ジョブは障害が発生しなかったインスタンスで実行できます。
ジョブは、インスタンス・レベル、クラスタ・レベルまたはクラスタ・データベース・レベルで作成できるため、クラスタ・データベース内の使用可能ないずれのホストでもジョブを実行できます。これはスケジュールされるジョブにも適用されます。Oracle Enterprise Managerでは、ジョブ・アクティビティがActive、History、Libraryなどのカテゴリに分類されて表示されます。
オペレーティング・システムのスクリプトやSQLスクリプトの送信およびスケジュールされたジョブの調査には、「ジョブ」タブを使用します。たとえば、特定のOracle RACデータベースのためのバックアップ・ジョブの作成は、次のように行います。
「ターゲット」をクリックし、ジョブを作成するデータベースをクリックします。
ターゲット・データベースにログインします。
表示されたデータベースの「ホーム」ページで、「メンテナンス」をクリックします。
Enterprise Managerのジョブ・ウィザードの各ページに入力し、ジョブを作成します。
Oracle Enterprise Managerを使用して、Oracle RAC環境のアラートを構成できます。また、グローバル・キャッシュ変換、読取り一貫性要求など、Oracle RACデータベースの特殊なテストも構成できます。
Oracle Enterprise Managerでは、Oracle RAC環境のデータベース・レベルとインスタンス・レベルのアラートは区別されます。アーカイブ・ログ・アラートなど、インスタンス・レベル・アラートのアラートしきい値は、インスタンスのターゲット・レベルで設定できます。この機能により、パフォーマンスがしきい値を超えた場合、特定のインスタンスに関するアラートを受信できます。また、表領域に関するアラートの設定など、データベース・レベルでアラートを構成することもでき、各インスタンスで重複するアラートの受信を回避できます。
|
関連項目: Oracle RACでのアラートの構成の例は、Oracle Technology Networkを参照してください。パッケージを使用してしきい値を構成する方法は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
Oracle RACデータベースの管理対象のすべてのターゲットについてブラックアウト(メンテナンス操作によって監視データに偏りが発生したり、不要なアラートが生成されないように、データベース監視を一時停止する期間のこと)を定義し、メンテナンス実行中のアラートの発生を防止できます。ブラックアウトは、クラスタ・データベース全体について定義することも、クラスタ・データベースの特定のインスタンスについて定義することもできます。
|
関連項目: ブラックアウトの定義の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
