test

Sun Cluster Data Service for Oracle ガイド (Solaris OS 版)

Sun Cluster HA for Oracle のインストールと構成

この章では、次の手順について説明します。

注 –

SunPlexTM Manager を使用して、このデータサービスのインストールと構成を実行できます。詳細は SunPlex Manager のオンラインヘルプを参照してください。

Sun Cluster HA for Oracle のインストールと構成作業の概要

次の表に、Sun Cluster HA for Oracle をインストールして構成する作業の概要を示します。作業手順の詳細が記載されている参照先も示します。指定された順番どおりに、各作業を行ってください。

表 1–1 Task Map: HA for Oracle のインストールと構成

タスク 

参照先 

Sun Cluster HA for Oracle のインストールと構成の計画 

「Sun Cluster HA for Oracle のインストールと構成の計画」

ノードとディスクを準備する 

「ノードとディスクの準備」

Oracle ソフトウェアのインストール 

「Oracle ソフトウェアをインストールする」

Oracle のインストールの確認 

「Oracle のインストールを確認する」

Oracle データベースの作成 

「Oracle データベースを作成する」

Oracle データベースのアクセス権の設定 

「Oracle データベースのアクセス権を設定する」

Sun Cluster HA for Oracle パッケージのインストール 

「Sun Cluster HA for Oracle パッケージのインストール」

Sun Cluster HA for Oracle の登録と構成 

「Sun Cluster HA for Oracle を登録して構成する」

Sun Cluster HA for Oracle のインストールの確認 

「Sun Cluster HA for Oracle のインストールの確認」

Sun Cluster HA for Oracle 障害モニターの概要 

「Sun Cluster HA for Oracle 障害モニターの概要」

(任意) Sun Cluster HA for Oracle サーバー障害モニターのカスタマイズ 

「Sun Cluster HA for Oracle サーバー障害モニターのカスタマイズ」

(任意) Sun Cluster HA for Oracle リソースタイプのアップグレード 

「Sun Cluster HA for Oracle リソースタイプをアップグレードする」

Sun Cluster HA for Oracle のインストールと構成の計画

ここでは、Sun Cluster HA for Oracle のインストールと構成の計画について説明します。

構成に関する要件

注意 – 注意 –

次の要件を満たさないと、データサービスの構成がサポートされない場合があります。

ここで示す要件に従って、Sun Cluster HA for Oracle のインストールと構成の計画を行ってください。これらの要件が当てはまるのは、Sun Cluster HA for Oracle だけです。Sun Cluster HA for Oracle のインストールと構成を始める前に、次の要件を満たしておく必要があります。

すべてのデータサービスに適用される要件については、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「Sun Cluster データサービス構成のガイドライン」を参照してください。

構成計画に関する質問

ここで示す質問に基づいて、Sun Cluster HA for Oracle のインストールと構成の計画を行なってください。答えは、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「構成のワークシート」に記載されているデータサービスワークシートに記入します。

ノードとディスクの準備

ここでは、ノードとディスクを準備する手順について説明します。

ノードを準備する

次の手順で、Oracle ソフトウェアのインストールと構成の準備を行ってください。

注意 – 注意 –

ここで説明するすべての手順をすべてのノードで実行してください。すべてのノードですべての手順を実行しないと、Oracle のインストールが不完全になります。Oracle のインストールが不完全だった場合、起動時に Sun Cluster HA for Oracle でエラーが発生します。

注 –

この手順を実行する前に、Oracle のマニュアルを参照してください。

Sun Cluster ノードを準備し、Oracle ソフトウェアをインストールする手順は、次のとおりです。

  1. すべてのクラスタメンバーでスーパーユーザーになります。

  2. /etc/nsswitch.conf ファイルを次のように構成します。これによって、スイッチオーバーやフェイルオーバーが起こったときに、データサービスの起動と停止が正しく行われます。

    Sun Cluster HA for Oracle が動作する論理ホストをマスターできる各ノードで、次のエントリを /etc/nsswitch.conf ファイルに指定します。


    passwd:    files nis [TRYAGAIN=0]
publickey: files nis [TRYAGAIN=0]
project:   files nis [TRYAGAIN=0]
group:     files

    Sun Cluster HA for Oracle は、su user コマンドを使用してデータベースの起動と停止を行います。クラスタノードのパブリックネットワークに障害が発生すると、ネットワーク情報ネームサービスが使用不能になることがあります。group に上のどれかのエントリが指定されている場合は、ネットワーク情報ネームサービスが使用不能なとき su(1M) コマンドでは、 NIS/NIS+ ネームサービスは参照されません。

  3. Sun Cluster HA for Oracle のクラスタファイルシステムを構成します。

    データベースを raw デバイスに格納する場合は、広域デバイスを raw デバイスアクセス用に構成します。広域デバイスとその構成手順については、『 Sun Cluster ソフトウェアのインストール (Solaris OS 版)』を参照してください。

    Solstice DiskSuiteTM/Solaris Volume Manager ソフトウェアを使用する場合は、ミラー化メタデバイスまたは raw ミラー化メタデバイス上で UNIX ファイルシステム (UFS) ロギングを使用するように、Oracle ソフトウェアを構成します。raw ミラー化メタデバイスの構成方法については、Solstice DiskSuite/Solaris Volume Manager のマニュアルを参照してください。

  4. ローカルディスクまたは多重ホストディスクに $ORACLE_HOME ディレクトリを作成します。

    注 –

    Oracle バイナリをローカルディスクにインストールする場合は、できるだけ別のディスクを使用してください。Oracle バイナリを別のディスクにインストールすると、オペレーティング環境の再インストール時にバイナリが上書きされるのを防止できます。

  5. 各ノードの /etc/group ファイルにデータベース管理者 (DBA) グループのエントリを作成し、予定するユーザーをこのグループに追加します。

    DBA グループには、通常 dba という名前を付けます。root と oracle ユーザーが dba グループのメンバーになっているか確認し、必要に応じてほかの DBA ユーザーのエントリを追加します。このグループ ID は、Sun Cluster HA for Oracle が動作するすべてのノードで一致させる必要があります。次にその例を示します。


    dba:*:520:root,oracle

    グループエントリをネットワークネームサービス (NIS や NIS+ など) に作成することができます。この方法でグループエントリを作成する場合は、ローカル /etc/inet/hosts ファイルにエントリを追加することによって、ネットワークネームサービス上の依存関係を排除します。

  6. 各ノードで、Oracle ユーザー ID (oracle) のエントリを作成します。

    Oracle ユーザー ID には、通常 oracle という名前を付けます。次のコマンドでは、/etc/passwd と /etc/shadow ファイルに Oracle ユーザー ID のエントリを作成します。


    # useradd -u 120 -g dba -d /Oracle-home oracle

    oracle ユーザーエントリは、Sun Cluster HA for Oracle を実行するすべてのノードで一致させる必要があります。

Solstice DiskSuite による Oracle データベースアクセスを構成する

次の手順で、Solstice DiskSuite ボリュームマネージャに対して Oracle データベースを構成します。

  1. Solstice DiskSuite ソフトウェアで使用するディスクデバイスを構成します。

    Solstice DiskSuite ソフトウェアの構成方法については、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』を参照してください。

  2. データベースを raw デバイスに格納する場合は、次のコマンドを実行して各 raw ミラー化メタデバイスの所有者、グループ、モードを変更します。

    raw デバイスを使用しない場合は、次の各手順を実行しないでください。

    1. raw デバイスを作成する場合は、Oracle リソースグループをマスターできる各ノードでデバイスごとに次のコマンドを実行します。


      # chown oracle /dev/md/metaset/rdsk/dn
# chgrp dba /dev/md/metaset/rdsk/dn
# chmod 600 /dev/md/metaset/rdsk/dn
      metaset

      ディスクセットの名前を指定します。

      /rdsk/dn

      metaset ディスクセット内の raw ディスクデバイスの名前を指定します。

    2. 変更が有効になっているか確認します。


      # ls -lL /dev/md/metaset/rdsk/dn

VERITAS Volume Manager による Oracle データベースアクセスを構成する

次の手順で、VERITAS Volume Manager ソフトウェアに対して Oracle データベースを構成します。

  1. VxVM ソフトウェアが使用するディスクデバイスを構成します。

    VERITAS Volume Manager の構成手順については、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』を参照してください。

  2. データベースを raw デバイスに格納する場合は、現在のディスクグループ主ノードで次のコマンドを実行して各デバイスの所有者、グループ、モードを変更します。

    raw デバイスを使用しない場合は、次の各手順を実行しないでください。

    1. raw デバイスを作成する場合は、raw デバイスごとに次のコマンドを実行します。


      # vxedit -g diskgroup set user=oracle group=dba mode=600 volume
      diskgroup

      ディスクグループの名前を指定します。

      volume

      ディスクグループ内の raw ボリュームの名前を指定します。

    2. 変更が有効になっているか確認します。


      # ls -lL /dev/vx/rdsk/diskgroup/volume

    3. ディスクデバイスグループをクラスタに再登録して、クラスタ内での VxVM 名前空間の整合性を確保します。


      # scconf -c -D name=diskgroup

Oracle ソフトウェアのインストール

ここでは Oracle ソフトウェアのインストール手順について説明します。

Oracle ソフトウェアをインストールする

  1. クラスタメンバー上でスーパーユーザーになります。

  2. Oracle インストールの要件に注意してください。

    Oracle バイナリは、次のどちらかにインストールする必要があります。

    • クラスタノードのローカルディスク

    • 高可用性のローカルファイルシステム

    • クラスタファイルシステム

      注 –

      Oracle ソフトウェアをクラスタファイルシステムにインストールする場合には、まず、Sun Cluster ソフトウェアを起動し、ディスクデバイスグループの所有者になる必要があります。

    Oracle ソフトウェアをどこにインストールするかについては、「ノードとディスクの準備」を参照してください。

  3. Oracle ソフトウェアをインストールします。

    Oracle ソフトウェアをどこにインストールする場合でも、Oracle の標準的なインストール手順を使用する場合と同じように、各ノードの /etc/system ファイルを変更する必要があります。その後、再起動します。

    この手順を行うときには、oracle でログインし、ディレクトリ全体を所有する必要があります。Oracle ソフトウェアのインストール方法については、Oracle の適切なインストールおよび構成ガイドを参照してください。

  4. (省略可能) Sun Cluster HA for Oracle と Oracle 10g を使用している場合、Oracle cssd デーモンを起動しないようにします。

    Oracle ソフトウェアがインストールされているノード上で、Oracle cssd デーモン用のエントリを /etc/inittab から削除します。このエントリを削除するには、 /etc/inittab ファイルから次の行を削除します。

    h1:23:respawn:/etc/init.d/init.cssd run >/dev/null 2>&1 > </dev/null

    Sun Cluster HA for Oracle は Oracle cssd デーモンを必要としません。したがって、このエントリを削除しても、Oracle 10g と Sun Cluster HA for Oracle の動作には影響しません。Oracle インストールを変更して、Oracle cssd デーモンが必要になった場合は、/etc/inittab ファイルにおいて、Oracle cssd デーモン用のエントリを復元します。

    注意 – 注意 –

    Oracle 10g Real Application Clusters を使用している場合、 /etc/inittab ファイルから cssd デーモン用のエントリを削除してはなりません。

    /etc/inittab ファイルから cssd デーモン用のエントリを削除した場合、不必要なエラーメッセージが表示されないように設定する必要があります。そうしない場合、init(1M) コマンドで Oracle cssd デーモンを起動しようとすると、このようなエラーメッセージが表示される可能性があります。このようなエラーメッセージは、Oracle バイナリファイルが高可用性のローカルファイルシステムまたはクラスタファイルシステムにインストールされている場合に表示されます。Oracle バイナリファイルがインストールされているファイルシステムがマウントされるまで、このメッセージは繰り返し表示されます。

    これらのエラーメッセージの内容は次のとおりです。


    INIT: Command is respawning too rapidly. Check for possible errors.
id:  h1 "/etc/init.d/init.cssd run >/dev/null 2>&1 >/dev/null"
    		 

    Waiting for filesystem containing $CRSCTL.

    このようなエラーメッセージは、次のイベントが発生すると表示されます。

    • ノードが非クラスタモードで動作しているとき。この場合、Sun Cluster が制御するファイルシステムはマウントされません。

    • ノードがブートしているとき。この状況では、Oracle バイナリファイルがインストールされているファイルシステムを Sun Cluster がマウントするまで、このメッセージは繰り返し表示されます。

    • Oracle が本来動作していなかったノードで、Oracle が起動されているか、フェイルオーバーしているとき。このような構成では、Oracle バイナリファイルは高可用性のローカルファイルシステムにインストールされています。このような状況では、メッセージは Oracle インストールが動作していたノードのコンソールに表示されます。

Oracle のインストールと構成の確認

ここでは、Oracle のインストールと構成を確認する手順について説明します。

Oracle のインストールを確認する

データサービスをまだインストールしていないため、この手順ではアプリケーションの可用性が高いかどうかを確認することはできません。

  1. $ORACLE_HOME/bin/oracle ファイルの所有者、グループ、およびモードが次のようであることを確認します。

    • 所有者: oracle

    • グループ: dba

    • モード: -rwsr-s--x 


    # ls -l $ORACLE_HOME/bin/oracle

  2. リスナーバイナリが $ORACLE_HOME/bin にあることを確認します。

次に進む手順

この節での作業を終了したら、「Oracle データベースの作成」に進みます。

Oracle データベースの作成

ここでは、Sun Cluster 環境で最初の Oracle データベースを構成して作成する手順について説明します。追加のデータベースを作成して構成する場合は、この項の手順を省略します。

Oracle データベースを作成する

  1. データベース構成ファイルを準備します。

    すべてのデータベース関連ファイル (データファイル、redo ログファイル、制御ファイル) を、共有 raw 広域デバイスまたはクラスタファイルシステムに格納します。インストール先の詳細は、「ノードとディスクの準備」 を参照してください。

    場合によっては、init$ORACLE_SID.ora または config$ORACLE_SID.ora ファイル内の control_files と background_dump_dest の設定を、制御ファイルとアラートファイルの格納場所を示すように変更する必要があります。

    注 –

    データベースへのログインに Solaris の認証機能を使用している場合は、init$ORACLE_SID.ora ファイル内の remote_os_authent 変数を True に設定します。

  2. 次のリストから 1 つのユーティリティを選択して、データベースの作成を開始します。

    • Oracle インストーラ

    • Oracle sqlplus(1M) コマンド

    作成中、すべてのデータベース関連ファイルが、共有広域デバイスまたはクラスタファイルシステムの適切な場所に配置されていることを確認してください。

  3. 制御ファイルのファイル名が、構成ファイル内のファイル名と一致していることを確認します。

  4. v$sysstat ビューを作成します。

    カタログスクリプトを実行して v$sysstat ビューを作成します。Sun Cluster HA for Oracle 障害モニターでは、このビューを使用します。

次に進む手順

作業を完了したら、「Oracle データベースのアクセス権の設定」 に進みます。

Oracle データベースのアクセス権の設定

この節で説明する手順を実行して、Oracle データベースのアクセス権を設定します。

Oracle データベースのアクセス権を設定する

  1. 障害モニターに使用されるユーザーとパスワードに対するアクセスを有効にします。

    • Oracle の認証方式を使用する場合 – Oracle でサポートされるすべてのリリースについて、sqlplus プロンプトに次のスクリプトを入力します。


      # sqlplus “/as sysdba”
 
			grant connect, resource to user identified by passwd;
			alter user user default tablespace system quota 1m on
				system;
       			grant select on v_$sysstat to user;
			grant create session to user;
			grant create table to user;
 
   exit;

    • Solaris 認証方式を使用する場合 – Solaris 認証を使用するデータベースのアクセス権を付与します。

      注 –

      Solaris 認証を有効にするユーザーは、$ORACLE_HOME ディレクトリ下のファイルを所有するユーザーです。次のコード例では、ユーザー oracle が、これらのファイルを所有しています。


      # sqlplus “/as sysdba”
 
			create user ops$oracle identified by externally
				default tablespace system quota 1m on system;
			grant connect, resource to ops$oracle;
      			grant select on v_$sysstat to ops$oracle;
			grant create session to ops$oracle;
			grant create table to ops$oracle;
 
   exit;

  2. Sun Cluster ソフトウェア用に NET8 を構成します。

    クラスタ内のすべてのノードから listener.ora ファイルにアクセスできる必要があります。これらのファイルは、Oracle リソースを実行することができる各ノードのクラスタファイルシステム下、またはローカルファイルシステム内に配置できます。

    注 –

    listener.ora ファイルを /var/opt/oracle ディレクトリまたは $ORACLE_HOME/network/admin ディレクトリ以外に配置する場合は、ユーザーの環境ファイルで TNS_ADMIN 変数または同等の Oracle 変数を指定する必要があります。Oracle の変数については、Oracle のマニュアルを参照してください。さらに、scrgadm (1M) コマンドを実行して、ユーザー環境ファイルを指定するリソース拡張パラメータ User_env を設定してください。書式の詳細は、「SUNW.oracle_listener 拡張プロパティ」 または 「SUNW.oracle_server 拡張プロパティ」 を参照してください。

    Sun Cluster HA for Oracle データサービスでは、リスナー名に制限はありません。任意の有効な Oracle リスナー名を指定できます。

    次のコード例は、listener.ora ファイル内で更新された行を示しています。


    LISTENER =
	(ADDRESS_LIST =
			(ADDRESS =
				(PROTOCOL = TCP) 
					(HOST = logical-hostname) <- use logical hostname
				(PORT = 1527)
			)
	)
.
.
SID_LIST_LISTENER =
	.
			.
						(SID_NAME = SID) <- Database name, 
default is ORCL

    次のコード例は、クライアントマシンで更新された tnsnames.ora ファイルの行を示しています。


    service_name =
	.
			.
						(ADDRESS = 
								(PROTOCOL = TCP)
								(HOST = logicalhostname)	<- logical hostname
								(PORT = 1527) <- must match port in LISTENER.ORA
						)
				)
				(CONNECT_DATA =
						(SID = <SID>)) <- database name, default is ORCL

    次の例は、次の Oracle インスタンスに対して listener.ora および tnsnames.ora ファイルを更新する方法を示しています。

    インスタンス 

    論理ホスト 

    リスナー 

    ora8

    hadbms3

    LISTENER-ora8

    ora9

    hadbms4

    LISTENER-ora9

    対応する listener.ora エントリは次のようになります。


    LISTENER-ora9 =
	(ADDRESS_LIST =
			(ADDRESS =
				(PROTOCOL = TCP)
				(HOST = hadbms4)
				(PORT = 1530)
			)
		)
SID_LIST_LISTENER-ora9 =
	(SID_LIST =
			(SID_DESC =
				(SID_NAME = ora9)
			)
		)
LISTENER-ora8 =
  (ADDRESS_LIST =
    (ADDRESS= (PROTOCOL=TCP) (HOST=hadbms3)(PORT=1806))
  )
SID_LIST_LISTENER-ora8 =
  (SID_LIST =
     (SID_DESC =
			(SID_NAME = ora8)
		 )	
  )

    対応する tnsnames.ora エントリは次のようになります。


    ora8 =
(DESCRIPTION =
   (ADDRESS_LIST = 
			(ADDRESS = (PROTOCOL = TCP) 
			(HOST = hadbms3) 
			(PORT = 1806))
   	)    
	(CONNECT_DATA = (SID = ora8))
)
ora9 =
(DESCRIPTION =
  (ADDRESS_LIST =
        (ADDRESS = 
				(PROTOCOL = TCP) 
				(HOST = hadbms4) 
				(PORT = 1530))
  )
  	(CONNECT_DATA = (SID = ora9))
)

  3. Sun Cluster ソフトウェアがインストールされ、すべてのノードで実行されていることを確認します。


    # scstat

次に進む手順

「Sun Cluster HA for Oracle パッケージのインストール」 に進み、Sun Cluster HA for Oracle パッケージをインストールします。

Sun Cluster HA for Oracle パッケージのインストール

Sun Cluster の初回のインストール時に Sun Cluster HA for Oracle パッケージをインストールしなかった場合は、この手順でパッケージをインストールしてください。この手順は、Sun Cluster HA for Oracle パッケージをインストールする各クラスタノード上で個別に実行します。この手順の実行には、Sun Java Enterprise System Accessory CD Volume 3 が必要です。

複数のデータサービスを同時にインストールする場合は、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の「ソフトウェアのインストール」に記載されている手順を実行してください。

次のいずれかのインストールツールを使用して、Sun Cluster HA for Oracle パッケージをインストールします。

注 –

Web Start プログラムは、Sun Cluster 3.1 Data Services 10/03 より前のリリースでは使用できません。

Web Start プログラムを使って Sun Cluster HA for Oracle パッケージをインストールするには

Web Start プログラムは、コマンド行インタフェース (CLI) またはグラフィカルユーザーインタフェース (GUI) を使用して実行できます。CLI と GUI での作業の内容と手順はほとんど同じです。Web Start プログラムの詳細は、installer(1M) のマニュアルページを参照してください。

  1. Sun Cluster HA for Oracle パッケージをインストールするクラスタノード上で、スーパーユーザーになります。

  2. (省略可能) Web Start プログラムを GUI で実行する場合は、必ず DISPLAY 環境変数を設定します。

  3. CD-ROM ドライブに Sun Java Enterprise System Accessory CD Volume 3 を挿入します。

    ボリューム管理デーモン vold(1M) が実行されており、CD-ROM デバイスを管理するように構成されている場合は、デーモンによって CD-ROM が自動的に /cdrom/cdrom0 ディレクトリにマウントされます。

  4. CD-ROM の Sun Cluster HA for Oracle コンポーネントディレクトリに切り替えます。

    Sun Cluster HA for Oracle データサービスの Web Start プログラムは、このディレクトリに入っています。


    # cd /cdrom/cdrom0/\
components/SunCluster_HA_Oracle_3.1

  5. Web Start プログラムを起動します。


    # ./installer

  6. プロンプトが表示されたなら、インストールの種類を選択します。

    • C ロケールのみをインストールする場合は、Typical を選択します。

    • ほかのロケールをインストールする場合は、Custom を選択します。

  7. 表示される手順に従って、ノードに Sun Cluster HA for Oracle パッケージをインストールします。

    インストールが終了すると、Web Start プログラムのインストールサマリが出力されます。このサマリーを使用して、インストール時に Web Start によって作成されたログを確認できます。これらのログは、/var/sadm/install/logs ディレクトリにあります。

  8. Web Start プログラムを終了します。

  9. CD-ROM ドライブから Sun Java Enterprise System Accessory CD Volume 3 を取り出します。

    1. CD-ROM が使用されないように、CD-ROM 上のディレクトリ以外に移動します。

    2. CD-ROM を取り出します。


      # eject cdrom

次に進む手順

「Sun Cluster HA for Oracle の登録と構成」 を参照して Sun Cluster HA for Oracle を登録し、このデータサービス用にクラスタを構成します。

Sun Cluster HA for Oracle パッケージを scinstall ユーティリティーを使用してインストールする

  1. CD-ROM ドライブに Sun Java Enterprise System Accessory CD Volume 3 を挿入します。

  2. オプションは指定せずに、scinstall ユーティリティーを実行します。

    scinstall ユーティリティーが対話型モードで起動します。

  3. メニューオプション「新しいデータサービスのサポートをこのクラスタノードに追加」を選択します。

    scinstall ユーティリティーにより、ほかの情報を入力するためのプロンプトが表示されます。

  4. Sun Java Enterprise System Accessory CD Volume 3 のパスを指定します。

    ユーティリティーはこの CD をデータサービス CD-ROM として示します。

  5. インストールするデータサービスを指定します。

    選択したデータサービスが scinstall ユーティリティによって示され、選択を確定するように求められます。

  6. scinstall ユーティリティーを終了します。

  7. ドライブから CD を取り出します。

次に進む手順

「Sun Cluster HA for Oracle の登録と構成」 を参照して Sun Cluster HA for Oracle を登録し、このデータサービス用にクラスタを構成します。

Sun Cluster HA for Oracle の登録と構成

ここでは Sun Cluster HA for Oracle の構成手順について説明します。

Sun Cluster HA for Oracle 拡張プロパティの設定

付録 A 「Sun Cluster HA for Oracle 拡張プロパティ」の拡張プロパティを使用して、リソースを作成します。リソースを作成するときに、コマンド scrgadm -x parameter=value を使用して拡張プロパティを構成します。リソースが作成済みの場合は、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「データサービスリソースの管理」で説明している手順に従って、拡張プロパティを構成します。拡張プロパティの中には動的に変更できるものがあります。それ以外の拡張プロパティは、リソースを作成するか無効にするときにしか更新できません。そのプロパティをいつ変更できるかについては、説明欄の「調整 : 」を参照してください。Sun Cluster の全プロパティの詳細は、『 Sun Cluster データサービスの計画と管理』の「標準プロパティ」を参照してください。

「SUNW.oracle_server 拡張プロパティ」 に、Oracle サーバーに設定できる拡張プロパティを示します。Oracle サーバーの場合、設定する必要があるのは、次の拡張プロパティだけです。

Sun Cluster HA for Oracle を登録して構成する

次の手順に従って、Sun Cluster HA for Oracle をフェイルオーバーデータベースサービスとして構成します。この手順は、Sun Cluster の初回のインストール時にデータサービスパッケージをインストールしたことを前提としています。Sun Cluster の初回のインストール時に Sun Cluster HA for Oracle パッケージをインストールしなかった場合は、「Sun Cluster HA for Oracle パッケージのインストール」 を参照して、データサービスパッケージをインストールしてください。それ以外の場合は、次の手順で Sun Cluster HA for Oracle を構成します。

この手順を実行するには、次の情報を確認しておく必要があります。

  1. クラスタメンバー上でスーパーユーザーになります。

  2. scrgadm コマンドを実行して、データサービスのリソースタイプを登録します。

    Sun Cluster HA for Oracle の場合は、次のように、SUNW.oracle_server および SUNW.oracle_listener の 2 つのリソースタイプを登録します。


    # scrgadm -a -t SUNW.oracle_server
# scrgadm -a -t SUNW.oracle_listener
    -a

    データサービスのリソースタイプを追加します。

    -t SUNW.oracle_ type

    当該データサービス用にあらかじめ定義されているリソースタイプを指定します。

  3. ネットワークとアプリケーションのリソースを格納するためのフェイルオーバーリソースグループを作成します。

    次のように -h オプションを使用すると、データサービスを実行できるノードのセットを選択できます。


    # scrgadm -a -g resource-group [-h nodelist]
    -g resource-group

    リソースグループの名前を指定します。どのような名前でもかまいませんが、クラスタ内のリソースグループごとに一意である必要があります。

    -h nodelist

    潜在マスターを識別するための物理ノード名または ID をコンマで区切って指定します (省略可能)。フェイルオーバー時、ノードはこのリスト内の順番に従ってプライマリとして判別されます。

    注 –

    ノードリストの順番を指定するには、-h オプションを使用します。クラスタ内にあるすべてのノードが潜在マスターである場合、-h オプションを使用する必要はありません。

  4. 使用するすべてのネットワークリソースがネームサービスデータベースに追加されていることを確認します。

    Sun Cluster のインストール時に、この確認を行なっておく必要があります。

    注 –

    ネームサービスの検索における問題を回避するために、すべてのネットワークリソースがサーバーとクライアントの /etc/inet/hosts ファイルに存在することを確認します。

  5. ネットワークリソースをフェイルオーバーリソースグループに追加します。


    # scrgadm -a -L -g resource-group -l logical-hostname [-n netiflist]
    -l logical-hostname

    ネットワークリソースを指定します。ネットワークリソースは、クライアントが Sun Cluster HA for Oracle にアクセスするときに使用する論理ホスト名または共有アドレス (IP アドレス) です。

    [-n netiflist]

    各ノード上の IP ネットワークマルチパス グループをコンマで区切って指定します (省略可能)。 netiflist の各要素は、netif@node の形式で指定する必要があります。netif は IP ネットワークマルチパス グループ名 (sc_ipmp0 など) として指定できます。ノードは、sc_ipmp0@1、sc_ipmp@phys-schost-1 などのノード名またはノード IDで特定できます。

    注 –

    現在 Sun Cluster では、netif にアダプタ名は使用できません。

  6. SUNW.HAStoragePlus リソースタイプをクラスタに登録します。


    # scrgadm -a -t SUNW.HAStoragePlus

  7. タイプ SUNW.HAStoragePlus のリソース oracle-hastp-rs を作成します。


    # scrgadm -a -j oracle-hastp-rs -g oracle-rg -t SUNW.HAStoragePlus \
 
[データベースが raw デバイスにある場合は、広域デバイスパスを指定します。]
-x GlobalDevicePaths=ora-set1,/dev/global/dsk/dl \
 
[データベースが Cluster File Service にある場合は、
広域ファイルシステムとローカルファイルシステムマウントポイントを指定します。]
-x FilesystemMountPoints=/global/ora-inst,/global/ora-data/logs,/
local/ora-data \
 
[AffinityOn を true に設定します。]
-x AffinityOn=TRUE

    注 –

    フェイルオーバーを行うためには、AffinityOn が TRUE に設定され、ローカルファイルシステムが広域ディスクグループ上に存在する必要があります。

  8. scswitch コマンドを実行して次の作業を完了し、リソースグループ oracle-rg をクラスタノード上でオンラインにします。

    注意 – 注意 –

    切り替えは、リソースグループレベルに限定して行なってください。デバイスグループレベルで切り替えると、リソースグループが混乱し、フェイルオーバーが発生します。

    • リソースグループを MANAGED (管理) 状態にします。

    • リソースグループをオンラインにします。

    このノードは、デバイスグループ ora-set1 および raw デバイス /dev/global/dsk/d1 のプライマリになります。ファイルシステムに関連するデバイスグループ (/global/ora-inst 、 /global/ora-data/logs など) もこのノード上でプライマリになります。


    # scswitch -Z -g oracle-rg

  9. Oracle アプリケーションリソースをフェイルオーバーリソースグループに作成します。

    • Oracle サーバーリソース : 


      # scrgadm -a -j resource -g resource-group \
-t SUNW.oracle_server \ 
-x Connect_string=user/passwd \
-x ORACLE_SID=instance \
-x ORACLE_HOME=Oracle-home \
-x Alert_log_file=path-to-log \
-x Restart_type=entity-to-restart
-y resource_dependencies=storageplus-resource

    • Oracle リスナーリソース : 


      # scrgadm -a -j resource -g resource-group \
-t SUNW.oracle_listener \ 
-x LISTENER_NAME=listener \
-x ORACLE_HOME=Oracle-home
-y resource_dependencies=storageplus-resource
    -j resource

    追加するリソースの名前を指定します。

    -g resource-group

    リソースを格納するリソースグループの名前を指定します。

    -t SUNW.oracle_server/listener

    追加するリソースのタイプを指定します。

    -x Alert_log_file =path-to-log

    サーバーメッセージログ用のパスを $ORACLE_HOME の下に指定します。

    -x Connect_string =user/passwd

    障害モニターがデータベースに接続するために使用するユーザー名とパスワードを指定します。ここでの設定は、「Oracle データベースのアクセス権を設定する」で設定したアクセス権と一致する必要があります。Solaris の承認を使用する場合は、ユーザー名とパスワードの代わりにスラッシュ (/) を入力します。

    -x ORACLE_SID =instance

    Oracle システム識別子を設定します。

    -x LISTENER_NAME =listener

    Oracle リスナーインスタンスの名前を設定します。この名前は、listener.ora 内の対応するエントリに一致する必要があります。

    -x ORACLE_HOME =Oracle-home

    Oracle ホームディレクトリへのパスを設定します。

    -x Restart_type= entity-to-restart

    障害に対する応答再開時に、サーバー障害モニターが再起動するエンティティを指定します。次のように、entity-to-restart を設定します。

    • このリソースが含まれているリソースグループ内のすべてのリソースを再起動する場合は、entity-to-restart に RESOURCE_GROUP_RESTART を設定します。デフォルトでは、このリソースを含むリソースグループが再起動します。

      entity-to-restart に RESOURCE_GROUP_RESTART を設定すると、障害が発生していない場合でも、リソースグループ内の他のすべてのリソース (Apache、DNS など) が再起動します。したがって、リソースグループには、Oracle サーバーリソースの再起動時に再起動する必要があるリソースだけを含めます。

    • このリソースだけを再起動する場合は、 entity-to-restart に RESOURCE_RESTART を設定します。

    注 –

    Oracle データサービスに属する拡張プロパティを設定して、そのデフォルト値を変更できます。どのような拡張プロパティがあるかについては、「Sun Cluster HA for Oracle 拡張プロパティの設定」 を参照してください。

  10. リソースと障害の監視を有効にします。


    # scswitch -Z -g resource-group
    -Z

    リソースとモニターを有効にし、リソースグループを MANAGED 管理状態にし、リソースグループをオンラインにします。

    -g resource-group

    リソースグループの名前を指定します。

例 — Sun Cluster HA for Oracle の登録

次に、2 ノード構成のクラスタで Sun Cluster HA for Oracle を登録する例を示します。


クラスタ情報
ノード名: phys-schost-1, phys-schost-2
論理ホスト名: schost-1
リソースグループ: resource-group-1 (フェイルオーバーリソースグループ)
Oracle リソース: oracle-server-1, oracle-listener-1
Oracle インスタンス: ora-lsnr (リスナー), ora-srvr (サーバー)
 
(フェイルオーバーリソースグループを追加してすべてのリソースを含めます。)
# scrgadm -a -g resource-group-1
 
(論理ホスト名をリソースをリソースグループに追加します。)
# scrgadm -a -L -g resource-group-1 -l schost-1 
 
(Oracle リソースタイプを登録します。)
# scrgadm -a -t SUNW.oracle_server
# scrgadm -a -t SUNW.oracle_listener
 
(Oracle アプリケーションリソースをリソースグループに追加します。)
# scrgadm -a -j oracle-server-1 -g resource-group-1 \
-t SUNW.oracle_server -x ORACLE_HOME=/global/oracle \
-x Alert_log_file=/global/oracle/message-log \
-x ORACLE_SID=ora-srvr -x Connect_string=scott/tiger
 
# scrgadm -a -j oracle-listener-1 -g resource-group-1 \
-t SUNW.oracle_listener -x ORACLE_HOME=/global/oracle \
-x LISTENER_NAME=ora-lsnr
 
(リソースグループをオンラインにします。)
# scswitch -Z -g resource-group-1

次に進む手順

Sun Cluster HA for Oracle の登録と構成が完了したら、「Sun Cluster HA for Oracle のインストールの確認」 に進みます。

Sun Cluster HA for Oracle のインストールの確認

次の確認テストを実行して、Sun Cluster HA for Oracle が正しくインストールされていることを確認してください。

これらの妥当性検査によって、Sun Cluster HA for Oracleを実行するすべてのノードで Oracle インスタンスが起動され、構成内のほかのノードから Oracle インスタンスにアクセスできることが保証されます。これらの妥当性検査を実行して、Sun Cluster HA for Oracle から Oracle ソフトウェアを起動するときに発生する問題を特定してください。

Sun Cluster HA for Oracle のインストールを確認する

  1. Oracle リソースグループを現在マスターしているノードに oracle でログインします。

  2. 環境変数 ORACLE_SID および ORACLE_HOME を設定します。

  3. このノードから Oracle インスタンスを起動できることを確認します。

  4. Oracle インスタンスに接続できることを確認します。

    connect_string プロパティで定義した user/password 変数を指定して、sqlplus コマンドを使用します。


    # sqlplus user/passwd@tns_service

  5. Oracle インスタンスを停止します。

    Oracle インスタンスは Sun Cluster が制御しているので、Oracle インスタンスは Sun Cluster ソフトウェアによって再起動されます。

  6. Oracle データベースリソースが含まれているリソースグループを、そのクラスタ内の別のクラスタメンバーに切り替えます。

    次の例に、この手順を行う方法を示します。


    # scswitch -z -g resource-group -h node

  7. そのリソースグループがあるノードに oracle でログインします。

  8. 手順 3 と 手順 4 を繰り返し行って、Oracle インスタンスの起動とそれへの接続が正常に行われることを確認します。

Oracle クライアント

クライアントからのデータベース参照は、物理ホスト名ではなく、ネットワークリソースを使用して行う必要があります。ネットワークリソースは、フェイルオーバー時に物理ノード間で移動できる IP アドレスです。物理ホスト名はマシン名です。

たとえば、tnsnames.ora ファイルでは、データベースインスタンスを実行するホストとして、ネットワークリソースを指定する必要があります。ネットワークリソースは論理ホスト名または共有アドレスです。「Oracle データベースのアクセス権を設定する」 を参照してください。

注 –

Oracle のクライアントとサーバー間の接続は、Sun Cluster HA for Oracle スイッチオーバーが発生すると切り離されます。このため、クライアントアプリケーションは、必要に応じて、切り離しと再接続、あるいは回復を行う必要があります。トランザクションモニターによって、アプリケーションの処理が簡単になることがあります。また、Sun Cluster HA for Oracle のノードの回復時間は、アプリケーションによって異ります。

Sun Cluster HA for Oracle ログファイルの保管場所

Sun Cluster HA for Oracle データサービスの各インスタンスは、 /var/opt/SUNWscor ディレクトリのサブディレクトリにログファイルを保管します。

これらのファイルには、Sun Cluster HA for Oracle データサービスが実行するアクションについての情報が保存されます。構成のトラブルシューティングを行うために診断情報が必要な場合、または Sun Cluster HA for Oracle データサービスの動作をモニターする場合には、これらのファイルを参照してください。

Sun Cluster HA for Oracle 障害モニターの概要

Sun Cluster HA for Oracle には、サーバーモニターとリスナーモニターという 2 つの障害モニターがあります。

Oracle サーバーの障害モニター

Oracle サーバーの障害モニターは、サーバーの状態を照会する要求をサーバーに送信します。

サーバーの障害モニターは、モニターを高可用性にするために pmfadm によって開始されます。モニターが、何らかの理由により強制終了されても、Process Monitor Facility(PMF) によって自動的に再開します。

サーバー障害モニターのプロセス

サーバーの障害モニターは、次のプロセスで構成されます。

主障害モニターの動作

主障害モニターは、データベースがオンラインであり、トランザクション中にエラーが返されていない場合に、操作が正常に終了したと判断します。

データベースクライアント障害検証の動作

データベースクライアント障害検証機能は、動的パフォーマンスビュー v$sysstat に問い合わせて、データベースパフォーマンスの統計情報を取得します。統計の変化は、データベースが稼働していることを意味します。続けて問い合わせても、統計情報に変化がない場合、障害検証機能がデータベーストランザクションを実行し、データベースが稼働しているかどうかを判断します。このトランザクションにはユーザーテーブル空間におけるテーブルの作成、更新、および削除が伴います。

データベースクライアント障害検証機能は、すべてのトランザクションを Oracle ユーザーとして実行します。このユーザーの ID は、 「ノードを準備する」 で説明したとおり、ノードを準備するときに指定します。

検証機能は、Probe_timeout リソースプロパティに設定されたタイムアウト値を使用して、Oracle を正常に検証するための割り当て時間を判断します。

データベーストランザクションが失敗した場合のサーバー障害モニターのアクション

データベーストランザクションが失敗すると、サーバー障害モニターは、失敗の原因であるエラーによって決定されたアクションを実行します。サーバー障害モニターが実行するアクションを変更する場合は、「Sun Cluster HA for Oracle サーバー障害モニターのカスタマイズ」 の説明に従って、サーバー障害モニターをカスタマイズしてください。

外部プログラムを実行する必要があるアクションの場合、外部プログラムは別個のプロセスとしてバックグラウンドで実行されます。

実行できるアクションは、次のとおりです。

サーバー障害モニターが記録した警告の走査

Oracle ソフトウェアは、警告を警告ログファイルに記録します。このファイルの絶対パスは、 SUNW.oracle_server リソースの alert_log_file 拡張プロパティによって指定されます。サーバー障害モニターは、次の場合に警告ログファイルを走査して、新しい警告があるかどうかを確認します。

サーバー障害モニターが検出した記録済みの警告に対してアクションが定義されている場合は、警告への対応としてそのアクションが実行されます。

記録対象警告に対してどのようなアクションが前もって設定されているかについては、付録 A の表 B–2 を参照してください。サーバー障害モニターが実行するアクションを変更する場合は、「Sun Cluster HA for Oracle サーバー障害モニターのカスタマイズ」 の説明に従って、サーバー障害モニターをカスタマイズしてください。

Oracle リスナーの障害モニター

Oracle リスナーの障害モニターは、Oracle リスナーの状態を調べます。

リスナーが実行されている場合、Oracle リスナーの障害モニターは検証に成功したと判断します。障害モニターがエラーを検知すると、リスナーが再起動されます。

リスナー検証は、可用性を高めるために pmfadm によって開始されます。リスナー検証が強制終了された場合、PMF によって自動的に再開されます。

検証中にリスナーで問題が発生した場合、検証機能によってリスナーの再起動が試行されます。再起動の試行最大回数は、Retry_count リソースプロパティに設定した値によって決定されます。最大回数まで再起動を試行しても検証が成功しない場合、障害モニターは停止され、リソースグループのスイッチオーバーは行われません。

Sun Cluster HA for Oracle サーバー障害モニターのカスタマイズ

Sun Cluster HA for Oracle サーバー障害モニターをカスタマイズして、次のようにサーバー障害モニターの動作を変更できます。

注意 – 注意 –

Sun Cluster HA for Oracle サーバーの障害モニターをカスタマイズする前に、カスタマイズの影響を考慮してください。特に、アクションを再移動または切り替えから無視またはモニターの中止に変更する場合は、十分に注意してください。エラーが長期間放置されると、エラーによってデータベースに問題が起きる可能性があります。Sun Cluster HA for Oracle サーバーの障害モニターをカスタマイズしたあとでデータベースに問題が起きた場合は、カスタマイズしたアクションを元に戻し、事前設定のアクションを使用してください。事前設定のアクションに戻すことで、カスタマイズが問題の原因かどうかを判断できます。

Sun Cluster HA for Oracle サーバーの障害モニターをカスタマイズするには、次の作業が必要です。

  1. エラーのカスタム動作を定義します。

  2. クラスタ内の全ノードにカスタムアクションファイルを伝達します。

  3. サーバー障害モニターに使用させるカスタムアクションファイルを指定します。

エラーのカスタム動作の定義

Sun Cluster HA for Oracle サーバーの障害モニターは、次のタイプのエラーを検出します。

各エラータイプにカスタム動作を定義するには、カスタムアクションファイルを作成します。

カスタムアクションファイルのフォーマット

カスタムアクションファイルは、プレーンテキストファイルです。このファイルに、Sun Cluster HA for Oracle サーバー障害モニターのカスタム動作を定義したエントリを 1 つ以上登録します。エントリごとに、個々の DBMS エラー、個々のタイムアウトエラー、または複数の記録対象警告に対応するカスタム動作を定義します。カスタムアクションファイルに指定できるエントリの最大数は 1024 です。

注 –

カスタムアクションファイルの各エントリを使用して、エラーの事前設定アクションを変更するか、アクションが事前設定されていないエラーに対してアクションを指定します。カスタムアクションファイルには、変更する事前設定アクションまたはアクションが事前設定されていないエラーに対応するエントリだけを指定します。変更不要なアクションに対応するエントリは作成 しないでください。

カスタムアクションファイルのエントリは、セミコロンで区切ったキーワードと値のペアです。1 つのエントリを中括弧で囲みます。

カスタムアクションファイルのエントリの書式は、次のとおりです。

{
[ERROR_TYPE=DBMS_ERROR|SCAN_LOG|TIMEOUT_ERROR;]
ERROR=error-spec; 
[ACTION=SWITCH|RESTART|STOP|NONE;]
[CONNECTION_STATE=co|di|on|*;]
[NEW_STATE=co|di|on|*;]
[MESSAGE="message-string"]
}

キーワードと値のペアの間とエントリの間で空白を使用してファイルをフォーマットできます。

カスタムアクションファイルのキーワードの意味と指定できる値は、次のとおりです。

ERROR_TYPE

サーバー障害モニターが検出したエラーのタイプ。このキーワードに対して指定できる値は、次のとおりです。

DBMS_ERROR

DBMS エラーであることを指定します。

SCAN_LOG

エラーが警告ログファイルに記録される警告であることを指定します。

TIMEOUT_ERROR

タイムアウトであることを指定します。

ERROR_TYPE キーワードは省略可能です。このキーワードを省略した場合は、DBMS エラーとみなされます。

ERROR

エラーを特定します。データ型と error-spec の意味は、次の表に示すように、ERROR_TYPE キーワードの値によって決まります。

ERROR_TYPE

データ型 

意味 

DBMS_ERROR

整数 

Oracle が生成する DBMS エラーのエラー番号 

SCAN_LOG

引用符で囲まれた正規表現 

Oracle が Oracle 警告ログファイルに記録するエラーメッセージの文字列 

TIMEOUT_ERROR

整数 

サーバー障害モニターを最後に起動または再起動して以来、検証のタイムアウトが連続して発生した回数 

ERROR キーワードは、指定する必要があります。このキーワードを省略した場合、カスタムアクションファイルのエントリは無視されます。

ACTION

エラーに対してサーバー障害モニターが実行するアクションを指定します。このキーワードに対して指定できる値は、次のとおりです。

NONE

サーバー障害モニターはエラーを無視します。

STOP

サーバー障害モニターは停止します。

RESTART

サーバー障害モニターは、SUNW.oracle_server リソースの Restart_type 拡張プロパティの値によって指定されたエンティティを停止して再起動します。

SWITCH

サーバー障害モニターは、データベースサーバーリソースグループを別のノードに切り替えます。

ACTION キーワードは省略可能です。このキーワードを省略した場合、サーバー障害モニターはエラーを無視します。

CONNECTION_STATE

エラー検出時の、データベースとサーバー障害モニター間の接続状態を指定します。エントリが適用されるのは、エラー検出時に接続が指定した状態になっていた場合だけです。このキーワードに対して指定できる値は、次のとおりです。

*

接続の状態に関係なく、常にエントリが適用されます。

co

エントリは、サーバー障害モニターがデータベース接続を試行中の場合に限り、適用されます。

on

エントリは、サーバー障害モニターがオンラインの場合に限り、適用されます。データベースに接続している場合、サーバー障害モニターはオンラインです。

di

エントリは、サーバー障害モニターがデータベースから切り離されている場合に限り、適用されます。

CONNECTION_STATE キーワードは省略可能です。このキーワードを省略した場合は、接続の状態に関係なく、常にエントリが適用されます。

NEW_STATE

エラーの検出後、データベースとサーバー障害モニター間で維持する必要がある接続状態を指定します。このキーワードに対して指定できる値は、次のとおりです。

*

接続の状態を現状維持する必要があることを指定します。

co

サーバー障害モニターはデータベースを切断し、ただちにデータベースに再接続する必要があります。

di

サーバー障害モニターはデータベースを切り離す必要があります。サーバー障害モニターは、次回、データベースを検証するときに再接続します。

NEW_STATE キーワードは省略可能です。このキーワードを省略した場合、データベースの接続状態はエラー検出後も変化しません。

MESSAGE

エラーが検出されたときに、リソースのログファイルに出力する追加のメッセージを指定します。メッセージは二重引用符で囲む必要があります。このメッセージは、エラーに対して定義された標準メッセージに追加されます。

MESSAGE キーワードは省略可能です。このキーワードを省略すると、エラーが検出された場合でも、追加のメッセージはリソースのログファイルに出力されません。

DBMS エラーへの対応の変更

サーバー障害モニターが各 DBMS エラーに応じて実行するアクションは、表 B–1 に示すように事前に設定されています。DBMS エラーへの対応を変更すべきかどうかを判断するときは、データベースに対する DBMS エラーの影響を検討して、事前設定されたアクションで不都合があるかどうかを考慮します。以下の各項を参考にしてください。

DBMS エラーへの対応を変更する場合は、カスタムアクションファイルにエントリを作成し、次のようにキーワードを設定します。

影響が大きいエラーに対応する

サーバー障害モニターが無視するエラーによって複数のセッションに影響が出る場合は、サービスの損失を防止するアクションをサーバー障害モニターで実行します。

たとえば、Oracle エラー 4031 にはアクションが事前設定されていません。このエラーは、unable to allocate num-bytes bytes of shared memory というエラーです。ただし、この Oracle エラーは、共有大域領域 (SGA) がメモリー不足である、ひどく断片化されている、またはその両方の状況に陥っていることを意味します。このエラーの影響を受けるセッションが 1 つだけであれば、無視しても問題ありません。しかし、このエラーが複数のセッションに影響を与える場合は、サーバー障害モニターによるデータベースの再起動を考慮してください。

次に、DBMS エラーへの対応を再起動に変更するカスタムアクションファイルのエントリの例を示します。

例 1–1 DBMS エラーへの対応を再起動に変更する

{
ERROR_TYPE=DBMS_ERROR;
ERROR=4031; 
ACTION=restart;
CONNECTION_STATE=*; 
NEW_STATE=*;
MESSAGE="Insufficient memory in shared pool.";
}

この例は、DBMS エラー 4031 の事前設定アクションを無効にするカスタムアクションファイルのエントリを示しています。このエントリは、次の処理を指定しています。

影響が小さいエラーを無視する

サーバー障害モニターが対応するエラーの影響が小さい場合、エラーを無視するほうがエラーに対応するより問題が小さいことがあります。

たとえば、Oracle エラー 4030: out of process memory when trying to allocate num-bytes bytes に対応する事前設定アクションは再起動です。この Oracle エラーは、サーバー障害モニターが専用ヒープメモリーを割り当てられなかったことを意味します。このエラーが発生する原因の 1 つは、オペレーティングシステムで利用できるメモリーが不足しているということです。複数のセッションがこのエラーの影響を受ける場合は、データベースの再起動が適切です。ただし、専用メモリーの追加を必要とするセッションがなければ、このエラーが他のセッションに影響を与えることはありません。この場合は、サーバー障害モニターにエラーを無視させることを考慮してください。

次に、DBMS エラー無視するカスタムアクションファイルのエントリの例を示します。

例 1–2 DBMS エラーを無視する

{
ERROR_TYPE=DBMS_ERROR;
ERROR=4030;
ACTION=none;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="";
}

この例は、DBMS エラー 4030 の事前設定アクションを無効にするカスタムアクションファイルのエントリを示しています。このエントリは、次の処理を指定しています。

記録対象警告への対応を変更する

Oracle ソフトウェアは、Alert_log_file 拡張プロパティに指定されたファイルに警告を記録します。サーバー障害モニターはこのファイルを走査し、アクションが定義されている警告に対してアクションを実行します。

記録対象警告のうち、アクションが事前設定されているものについては、付録 A の表 B–2 を参照してください。記録対象警告への対応を変更することで、事前設定アクションを変更するか、サーバー障害モニターが対応する新しい警告を定義します。

記録対象警告への対応を変更する場合は、カスタムアクションファイルにエントリを作成し、次のようにキーワードを設定します。

サーバー障害モニターは、カスタムアクションファイルのエントリを指定された順に処理します。記録対象警告と最初に一致したエントリだけが処理されます。それ以後のエントリは一致しても無視されます。正規表現を使用して複数の記録対象警告に対するアクションを指定する場合は、固有性の強いエントリを汎用性の強いエントリの前に指定してください。汎用性の強いエントリを先に指定すると、固有性の強いエントリが無視される場合があります。

カスタムアクションファイルで、たとえば、正規表現 ORA-65 および ORA-6 で指定されたエラーに、それぞれ異なるアクションを定義するとします。正規表現 ORA-65 を含むエントリが無視されないようにするには、このエントリを正規表現 ORA-6 を含むエントリの前に指定する必要があります。

次に、記録対象警告への対応を変更するカスタムアクションファイルのエントリの例を示します。

例 1–3 記録対象警告への対応を変更する

{
ERROR_TYPE=SCAN_LOG;
ERROR="ORA-00600: internal error";
ACTION=RESTART;
}

この例は、内部エラーに関する記録対象警告 への事前設定アクションを変更するカスタムアクションファイルのエントリです。このエントリで指定される処理は、次のとおりです。

連続タイムアウトの最大検証回数を変更する

デフォルトでは、サーバー障害モニターは検証タイムアウトが 2 回続くと、データベースを再起動します。データベースの負荷が小さい場合、連続 2 回の検証タイムアウトはデータベースの停止を意味するものと解決できます。ただし、負荷が大きいときは、データベースが正常に動作していても、サーバー障害モニターの検証がタイムアウトすることがあります。サーバー障害モニターがデータベースを不必要に再起動しないようにするには、連続検証タイムアウトの最大回数を増やします。

注意 – 注意 –

連続検証タイムアウトの最大回数を増やすと、データベースの停止を検出するためにかかる時間が長くなります。

連続検証タイムアウトの最大許容回数を変更するには、2 回目以降の検証タイムアウトごとに、カスタムアクションファイルにエントリを 1 つずつ作成します。

注 –

最初の検証タイムアウトについては、対応するエントリを作成する必要はありません。最初の検証タイムアウトに対してサーバー障害モニターが実行するアクションは、事前に設定されています。

許容される最後の検証タイムアウトについては、キーワードを次のように設定してエントリを作成します。

2 回目以降の検証タイムアウトのそれぞれに、次のようにキーワードを設定してエントリを 1 つずつ作成します。

ヒント –

デバッグしやすくするには、検証タイムアウトの序数を示すメッセージを指定します。

次に、検証タイムアウトの最大連続回数を 5 回に増やすカスタムアクションファイルのエントリの例を示します。

例 1–4 連続タイムアウトの最大検証回数を変更する

{
ERROR_TYPE=TIMEOUT;
ERROR=2;
ACTION=NONE;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #2 has occurred.";
}

{
ERROR_TYPE=TIMEOUT;
ERROR=3;
ACTION=NONE;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #3 has occurred.";
}

{
ERROR_TYPE=TIMEOUT;
ERROR=4;
ACTION=NONE;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #4 has occurred.";
}

{
ERROR_TYPE=TIMEOUT;
ERROR=5;
ACTION=RESTART;
CONNECTION_STATE=*;
NEW_STATE=*;
MESSAGE="Timeout #5 has occurred. Restarting.";
}

この例は、検証タイムアウトの最大連続回数を 5 回に増やすカスタムアクションファイルのエントリです。これらのエントリで指定される処理は、次のとおりです。

カスタムアクションファイルをクラスタ内の全ノードに伝達する

サーバー障害モニターの動作は、すべてのクラスタノードで一貫している必要があります。したがって、サーバー障害モニターが使用するカスタムアクションファイルも、すべてのクラスタノードで同じにする必要があります。カスタムアクションファイルを作成または変更したあとで、このファイルをすべてのクラスタノードに伝達し、すべてのクラスタノードで同じ内容のファイルが使用されるようにします。全クラスタノードにファイルを伝達するには、次の中からクラスタ構成に最も適した方法を使用します。

サーバー障害モニターに使用させるカスタムアクションファイルを指定する

サーバー障害モニターにカスタムアクションを適用するには、障害モニターに使用させるカスタムアクションファイルを指定する必要があります。カスタムアクションは、サーバー障害モニターがカスタムアクションファイルを読み取った時点で、サーバー障害モニターに適用されます。サーバー障害モニターは、カスタムアクションファイルが指定されたときに、そのファイルを読み取ります。

カスタムアクションファイルを指定すると、ファイルの妥当性が検証されます。ファイルに構文エラーがあると、エラーメッセージが表示されます。カスタムアクションファイルを修正してから、ファイルを再び指定して、ファイルの妥当性を検査してください。

注意 – 注意 –

変更したカスタムアクションファイルに構文エラーが見つかった場合は、エラーを修正してから、障害モニターを再起動します。障害モニターの再起動時に構文エラーが未修正だった場合は誤ったファイルが読み取られ、最初の構文エラー以後のエントリは無視されます。

サーバー障害モニターに使用させるカスタムアクションファイルを指定する

  1. クラスタノード上で、スーパーユーザーになります。

  2. SUNW.oracle_server リソースの Custom_action_file 拡張プロパティを設定します。

    このプロパティをカスタムアクションファイルの絶対パスに設定します。


    # scrgadm -c -j server-resource\
  -x custom_action_file=filepath
    -j server-resource

    SUNW.oracle_server リソースを指定します。

    -x custom_action_file= filepath

    カスタムアクションファイルの絶対パスを指定します。

Sun Cluster HA for Oracle リソースタイプをアップグレードする

Sun Cluster HA for Oracle データサービスには、以下のリソースタイプがあります。

以下の条件が当てはまる場合は、これらのリソースタイプをアップグレードします。

リソースタイプをアップグレードする一般的な手順については、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「リソースタイプのアップグレード」を参照してください。

SUNW.oracle_listener リソースタイプをアップグレードする

このあと、 SUNW.oracle_listener リソースタイプのアップグレードを完了するために必要な情報を示します。

新しいリソースタイプバージョンの登録に関する情報

以下の表に、SUNW.oracle_listener リソースタイプのバージョンと Sun Cluster データサービスのリリースとの関係を示します。Sun Cluster データサービスのリリースは、リソースタイプが導入されたバージョンを表します。

SUNW.oracle_listener リソースタイプのバージョン

Sun Cluster データサービスのリリース 

1 

1.0 

3.1 

3.1 5/03 

4 

3.1 4/04 

登録されているリソースタイプのバージョンを調べるには、次のどちらかのコマンドを使用します。

このリソースタイプのりソースタイプ登録 (RTR) ファイルは、/opt/SUNWscor/oracle_listener/etc/SUNW.oracle_listener です。

リソースタイプの既存インスタンスの移行に関する情報

SUNW.oracle_listener リソースタイプの各インスタンスを編集するために必要な情報は、次のとおりです。

次の例に、 SUNW.oracle_listener リソースタイプのインスタンスを編集するコマンドの例を示します。

例 1–5 SUNW.oracle_listener リソースタイプのインスタンスを編集する


# scrgadm -cj oracle-lrs -y Type_version=4 \
  -x probe_timeout=60

このコマンドによって、SUNW.oracle_listener リソースは次のように編集されます。

SUNW.oracle_server リソースタイプをアップグレードする

このあと、SUNW.oracle_server リソースタイプのアップグレードを完了するために必要な情報を示します。

新しいリソースタイプバージョンの登録に関する情報

以下の表に、SUNW.oracle_server リソースタイプのバージョンとSun Cluster データサービスのリリースとの関係を示します。Sun Cluster データサービスのリリースは、リソースタイプが導入されたバージョンを表します。

SUNW.oracle_server リソースタイプのバージョン

Sun Cluster データサービスのリリース 

1 

1.0 

3.1 

3.1 5/03 

4 

3.1 10/03 

登録されているリソースタイプのバージョンを調べるには、次のどちらかのコマンドを使用します。

このリソースタイプのリソースタイプ登録 (RTR) ファイルは、/opt/SUNWscor/oracle_server/etc/SUNW.oracle_server です。

リソースタイプの既存インスタンスの移行に関する情報

SUNW.oracle_server リソースタイプの各インスタンスを編集するために必要な情報は、次のとおりです。

次の例に、 SUNW.oracle_server リソースタイプのインスタンスを編集するコマンドの例を示します。

例 1–6 SUNW.oracle_server リソースタイプのインスタンスを編集する


# scrgadm -cj oracle-srs -y Type_version=4 \
  -x custom_action_file=/opt/SUNWscor/oracle_server/etc/srv_mon_cust_actions

このコマンドによって、SUNW.oracle_server リソースが次のように編集されます。