Sun Cluster 3.1 Data Service for Oracle ガイド

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

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

注 –

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

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

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

表 1–1 作業マップ : 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 のインストールの確認	Oracle のインストールを確認する
Sun Cluster HA for Oracle 障害モニターの概要	Sun Cluster HA for Oracle 障害モニターの概要
(任意) Sun Cluster HA for Oracle サーバー障害モニターのカスタマイズ	Sun Cluster HA for Oracle サーバー障害モニターのカスタマイズ
(任意) `SUNW.oracle_server` リソースタイプのアップグレード	`SUNW.oracle_server` リソースタイプをアップグレードする

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 3.1 データサービスのインストールと構成』の「データサービス固有の要件の識別』を参照してください。

Oracle アプリケーションファイル – これらのファイルには、Oracle バイナリ、構成ファイル、およびパラメータファイルが含まれます。これらのファイルはローカルファイルシステム、高可用性のローカルファイルシステム、またはクラスタファイルシステムのいずれにでもインストールできます。

Oracle バイナリをローカルファイルシステム、高可用性のローカルファイルシステム、またはクラスファイルシステムに置いた場合のそれぞれのメリットとデメリットについては、『 Sun Cluster 3.1 データサービスの計画と管理』の「Sun Cluster データサービスの構成のガイドライン」を参照してください。
データベース関連ファイル – これらのファイルには制御ファイル、redo ログ、およびデータファイルが含まれます。これらのファイルは Raw デバイスまたは正規ファイルとして、高可用性のローカルファイルシステムまたはクラスタファイルシステムにインストールする必要があります。

構成計画に関する質問

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

ネットワークアドレスとアプリケーションリソースにどのリソースグループを使用しますか、それらの間にはどのような依存関係がありますか。
データサービスへのアクセスにクライアントが使用する論理ホスト名 (フェイルオーバーサービスの場合) または共有アドレス (スケーラブルサービスの場合) を指定してください。
システム構成ファイルはどこに置きますか。

クラスファイルシステムではなくローカルファイルシステムに Oracle バイナリを置くメリットとデメリットについては、『 Sun Cluster 3.1 データサービスの計画と管理』の「Sun Cluster データサービスの構成のガイドライン」を参照してください。

ノードとディスクの準備

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

ノードを準備する

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

注意 –

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

注 –

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

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

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

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

Sun Cluster HA for Oracle が動作する論理ホストをマスターできる各ノードで、次の group エントリのどれかを /etc/nsswitch.conf ファイルに指定します。
group: files group: files [NOTFOUND=return] nis group: files [NOTFOUND=return] nisplus
Sun Cluster HA for Oracle は、su user コマンドを使用してデータベースの起動と停止を行います。クラスタノードのパブリックネットワークに障害が発生すると、ネットワーク情報ネームサービスが使用不能になることがあります。group に上のどれかのエントリが指定されている場合は、ネットワーク情報ネームサービスが使用不能なとき su(1M) コマンドでは、 NIS/NIS+ ネームサービスは参照されません。

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

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

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

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

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

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

DBA グループには、通常 dba という名前を付けます。 root と oracle ユーザーが dba グループのメンバーになっているか確認し、必要に応じてほかの DBA ユーザーのエントリを追加します。このグループ ID は、Sun Cluster HA for Oracle が動作するすべてのノードで一致させる必要があります。次にその例を示します。
dba:*:520:root,oracle
グループエントリをネットワークネームサービス (NIS や NIS+ など) に作成することができます。この方法でグループエントリを作成する場合は、ローカル /etc/inet/hosts ファイルにエントリを追加することによって、ネットワークネームサービス上の依存関係を排除します。

各ノードで、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 データベースを構成します。

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

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

データベースを 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 データベースを構成します。

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

VERITAS Volume Manager の構成方法については、『Sun Cluster 3.1 10/03 ソフトウェアのインストール』を参照してください。

データベースを 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 ソフトウェアをインストールする

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

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

Oracle バイナリは、次のどちらかにインストールする必要があります。
- クラスタノードのローカルディスク
- 高可用性のローカルファイルシステム
- クラスタファイルシステム
  
  注 –
  Oracle ソフトウェアをクラスタファイルシステムにインストールする場合には、まず、Sun Cluster ソフトウェアを起動し、ディスクデバイスグループの所有者になる必要があります。
Oracle ソフトウェアをどこにインストールするかについては、ノードとディスクの準備を参照してください。

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

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

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

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

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

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

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

oracle ユーザーと dba グループが $ORACLE_HOME/bin/oracle ディレクトリを所有していることを確認します。

$ORACLE_HOME/bin/oracle のアクセス権が次のように設定されていることを確認します。
-rwsr-s--x

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

次の作業

作業を完了したら、Oracle データベースの作成に進みます。

Oracle データベースの作成

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

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

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

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

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

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

データベースを作成します。

Oracle インストーラを起動し、データベースを作成するオプションを選択します。Oracle のバージョンによっては、Oracle の svrmgrl (1M) コマンドを使用してデータベースを作成できます。

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

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

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

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

次の作業

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

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

ここで説明する手順に従って、Oracle 8i または Oracle 9i に対応する Oracle データベースのアクセス権を設定します。

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

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

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;

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

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

注 –

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

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))
)

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 Cluster Agents CD-ROM が必要です。

複数のデータサービスを同時にインストールする場合は、『Sun Cluster 3.1 10/03 ソフトウェアのインストール』の「ソフトウェアのインストール」を参照してください。

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

Web Start プログラム
scinstall ユーティリティー

注 –

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

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

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

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

(省略可能) Web Start プログラムを GUI で実行する場合は、DISPLAY 環境変数を設定しておく必要があります。

Sun Cluster Agents CD-ROM を CD-ROM ドライブに挿入します。

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

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

Sun Cluster HA for Oracle データサービス用の Web Start プログラムは、次のディレクトリにあります。
# cd /cdrom/scdataservices_3_1_vb/\ components/SunCluster_HA_Oracle_3.1

Web Start プログラムを起動します。
# ./installer

プロンプトに対してインストールタイプを選択します。
- C ロケールだけをインストールする場合は、一般 (Typical) を選択します。
- 他のロケールをインストールする場合は、カスタム (Custom) を選択します。

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

インストールが完了すると、Web Start プログラムによってインストールの概要が作成されます。この概要によって、インストール中に Web Start プログラムによって生成されたログを表示できます。このログは /var/sadm/install/logs ディレクトリに保管されます。

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

CD-ROM ドライブから Sun Cluster Agents CD-ROM を取り出します。
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` ユーティリティーを使用してインストールする

CD-ROM ドライブに Sun Cluster Agents CD-ROM を挿入します。

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

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

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

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

Sun Cluster Agents CD-ROM のパスを指定します。

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

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

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

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

ドライブから 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 拡張プロパティ

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

表 1–2 Sun Cluster HA for Oracle リスナー拡張プロパティ


名前 / データタイプ	説明
`LISTENER_NAME` (文字列)	Oracle リスナーの名前初期値 : `LISTENER` 範囲 : なし調整 : 無効時 (When_ disabled)
`ORACLE_HOME` (文字列)	Oracle ホームディレクトリへのパス初期値 : なし範囲 : 最小 = `1` 調整 : 無効時 (When_ disabled)
`User_env` (文字列)	環境変数が含まれているファイル。リスナーの起動と停止の前に設定されます。Oracle の初期値と値が異なる環境変数は、このファイルに定義する必要があります。たとえば、ユーザーの `listener.ora` ファイルが、 `/var/opt/oracle` ディレクトリまたは `$ORACLE_HOME/network/admin` ディレクトリにないことがあります。この場合、`TNS_ADMIN` 環境変数を定義する必要があります。各環境変数の定義は、`VARIABLE_NAME = VARIABLE_VALUE` という書式で行う必要があります。これらの環境変数は、それぞれ環境ファイル内で 1 行に 1 つずつ指定する必要があります。初期値 : ““ 範囲 : なし調整 : 任意の時点 (Anytime)

表 1–3 に、Oracle サーバーに設定できる拡張プロパティを示します。Oracle サーバーの場合、設定する必要があるのは、次の拡張プロパティだけです。

ORACLE_HOME
ORACLE_SID
Alert_log_file
Connect_string

表 1–3 Sun Cluster HA for Oracle サーバー拡張プロパティ


名前 / データタイプ	説明
`Alert_log_file` (文字列)	Oracle 警告ログファイル初期値 : なし範囲 : 最小 = `1` 調整 : 任意の時点 (Anytime)
`Auto_End_Bkp` (ブール)	Oracle リレーショナルデータベース管理システム (RDBMS) のホットバックアップが中断した場合に、次の回復処理を実行するかどうかを指定します。ホットバックアップモードのままのファイルが原因で、データベースが開かない状況を認識する。この確認処理は Sun Cluster HA for Oracle の起動時に行われる。ホットバックアップモードのままになっているファイルをすべて識別して解放する。データベースを使用できるように開く。このプロパティに指定できる値は、次のとおりです。 `False` – 回復処理を実行しないことを指定します。これが初期値です。 `True` – 回復処理を実行することを指定します。初期値 : False 範囲 : なし調整 : 任意の時点 (Anytime)
`Connect_cycle` (整数)	データベースを切断するまでにサーバー障害モニターが実行する検証の回数初期値 : `5` 範囲 : `0` – `99,999` 調整 : 任意の時点 (Anytime)
`Connect_string` (文字列)	サーバー障害モニターがデータベースに接続するのに使用する Oracle ユーザーとパスワード初期値 : なし範囲 : 最小 = `1` 調整 : 任意の時点 (Anytime)
`Custom_action_file` (文字列)	Sun Cluster HA for Oracle サーバー障害モニターのカスタム動作を定義したファイルの絶対パス初期値 : ““ 範囲 : なし調整 : 任意の時点 (Anytime) 導入されたリリース : 3.1 10/03
`Debug_level` (整数)	記録する Sun Cluster HA for Oracle デバッグメッセージのレベル初期値 : 1 範囲 : 1 – 100 調整 : 任意の時点 (Anytime)
`ORACLE_HOME` (文字列)	Oracle ホームディレクトリへのパス初期値 : なし範囲 : 最小 = `1` 調整 : 無効時 (When_ disabled)
`ORACLE_SID` (文字列)	Oracle システム識別子初期値 : なし範囲 : 最小 = `1` 調整 : 無効時 (When_ disabled)
`Parameter_file` (文字列)	Oracle パラメータファイル。指定しない場合は、Oracle プロパティのデフォルトが使用されます。初期値 : ““ 範囲 : 最小 = `0` 調整 : 任意の時点 (Anytime)
`Probe_timeout` (整数)	Oracle サーバーインスタンスの検証にサーバー障害モニターが使用するタイムアウト時間 (秒) 初期値 : `60` 範囲 : `0` – `99,999` 調整 : 任意の時点 (Anytime)
`Restart_type` (文字列)	障害に対する応答再開時に、サーバー障害モニターが再起動するエンティティを指定します。このプロパティに指定できる値は、次のとおりです。 `RESOURCE_GROUP_RESTART` – このリソースが含まれているリソースグループ内のすべてのリソースを再起動する `RESOURCE_RESTART` – このリソースだけを再起動する初期値 : `RESOURCE_GROUP_RESTART` 範囲 : なし調整 : 任意の時点 (Anytime)
`User_env` (文字列)	環境変数が含まれているファイル。サーバーの起動と停止の前に設定される。Oracle の初期値と値が異なる環境変数は、このファイルに定義する必要があります。たとえば、ユーザーの `listener.ora` ファイルが、 `/var/opt/oracle` ディレクトリまたは `$ORACLE_HOME/network/admin` ディレクトリにないことがあります。その場合は、`TNS_ADMIN` 環境変数を定義する必要があります。各環境変数の定義は、`VARIABLE_NAME = VARIABLE_VALUE` という書式で行う必要があります。これらの環境変数は、それぞれ環境ファイル内で 1 行に 1 つずつ指定する必要があります。初期値 : `NULL` 範囲 : なし調整 : 任意の時点 (Anytime)
`Wait_for_online` (ブール)	データベースがオンラインになるまで `START` メソッドで待機します。初期値 : `True` 範囲 : なし調整 : 任意の時点 (Anytime)

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 を構成します。

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

データサービスをマスターするクラスタノードの名前。
クライアントがデータサービスにアクセスするために使用するネットワークリソース。通常、この IP アドレスはクラスタをインストールするときに設定します。ネットワークリソースの詳細は、『Sun Cluster 3.1 10/03 の概念』を参照してください。
構成しようと計画しているリソース用の Oracle アプリケーションのバイナリへのパス。

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

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

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

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

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

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

-h nodelist

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

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

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

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

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

ネットワークリソースをフェイルオーバーリソースグループに追加します。
# scrgadm -a -L -g resource-group -l logical-hostname [-n netiflist]
-l logical-hostname

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

[-n netiflist]

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

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

SUNW.HAStoragePlus リソースタイプをクラスタに登録します。
# scrgadm -a -t SUNW.HAStoragePlus

タイプ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 に設定され、ローカルファイルシステムが広域ディスクグループ上に存在する必要があります。

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

注意 –
切り替えは、リソースグループレベルに限定して行なってください。デバイスグループレベルで切り替えると、リソースグループが混乱し、フェイルオーバーが発生します。
- リソースグループを MANAGED (管理) 状態にします。
- リソースグループをオンラインにします。
このノードは、デバイスグループ ora-set1 および raw デバイス /dev/global/dsk/d1 のプライマリになります。ファイルシステムに関連するデバイスグループ (/global/ora-inst 、 /global/ora-data/logs など) もこのノード上でプライマリになります。
# scswitch -Z -g oracle-rg

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 拡張プロパティを参照してください。

リソースと障害の監視を有効にします。
# 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 のインストールを確認する

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

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

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

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

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

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

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

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

次の例に、この手順を行う方法を示します。
# scswitch -z -g resource-group -h node

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

手順 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 ディレクトリのサブディレクトリにログファイルを保管します。

/var/opt/SUNWscor/oracle_server ディレクトリには、Oracle サーバー用のログファイルが格納されます。
/var/opt/SUNWscor/oracle_listener ディレクトリには、Oracle リスナー用のログファイルが格納されます。

これらのファイルには、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) によって自動的に再開します。

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

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

障害モニターの主プロセスが、エラー検索と scha_control アクションを実行します。
データベースクライアント障害検証が、データベーストランザクションを実行します。

主障害モニターの動作

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

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

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

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

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

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

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

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

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

無視。サーバー障害モニターはエラーを無視します。
モニター中止。データベースを停止せずに、サーバー障害モニターを中止します。
再起動。Restart_type 拡張プロパティの値によって指定されたエンティティを停止してサーバー障害モニターは再起動します。
- Restart_type 拡張プロパティに RESOURCE_GROUP_RESTART が設定されている場合は、データベースサーバーリソースグループが再起動されます。デフォルトでは、データベースサーバーリソースグループが再起動されます。
- Restart_type 拡張プロパティに RESOURCE_RESTART が設定されている場合は、データベースサーバーリソースが再起動されます。
注 –
再起動の試行回数が Retry_interval リソースプロパティに指定した時間内に、 Retry_count リソースプロパティの値を超えることがあります。その場合、サーバー障害モニターはリソースグループを別のノードに切り替えようとします。
切り替え。サーバー障害モニターはデータベースサーバーリソースグループを別のノードに切り替えます。ノードが利用できない場合、リソースグループの切り替えは失敗します。リソースグループの切り替えができなかった場合、データベースサーバーが再起動します。

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

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

サーバー障害モニターの起動時。
サーバー障害モニターがサーバーの状態を問い合わせるとき。

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

記録対象警告に対してどのようなアクションが前もって設定されているかについては、付録 A の表 A–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 サーバーの障害モニターをカスタマイズするには、次の作業が必要です。

エラーのカスタム動作を定義します。
クラスタ内の全ノードにカスタムアクションファイルを伝達します。
サーバー障害モニターに使用させるカスタムアクションファイルを指定します。

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

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

サーバー障害モニターによるデータベースの検証中に発生する DBMS エラー
Oracle が警告ログファイルに記録するエラー
Probe_timeout 拡張プロパティの設定時間内に応答を得られなかったために発生するタイムアウト

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

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

カスタムアクションファイルは、プレーンテキストファイルです。このファイルに、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`	`Integer`	Oracle が生成する DBMS エラーのエラー番号
`SCAN_LOG`	引用符で囲まれた正規表現	Oracle が Oracle 警告ログファイルに記録するエラーメッセージの文字列
`TIMEOUT_ERROR`	`Integer`	サーバー障害モニターを最後に起動または再起動して以来、検証のタイムアウトが連続して発生した回数

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

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

ERROR_TYPE に DBMS_ERROR を設定します。
ERROR に DBMS エラーのエラー番号を設定します。
ACTION に必要なアクションを設定します。

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

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

たとえば、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 の事前設定アクションを変更するカスタムアクションファイルのエントリです。このエントリで指定される処理は、次のとおりです。

DBMS エラー 4031 への対応としてサーバー障害モニターが実行するアクションは、再起動です。
このエントリは、エラー検出時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、エラー検出後も維持されます。
このエラーが検出されると、次のメッセージがリソースのログファイルに出力されます。
Insufficient memory in shared pool.

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

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

たとえば、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 の事前設定アクションを変更するカスタムアクションファイルのエントリです。このエントリで指定される処理は、次のとおりです。

サーバー障害モニターは、DBMS エラー 4030 を無視します。
このエントリは、エラー検出時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、エラー検出後も維持されます。
エラーが検出された場合でも、追加のメッセージがリソースのログファイルに出力されることはありません。

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

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

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

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

ERROR_TYPE に SCAN_LOG を設定します。
ERROR に、Oracle が Oracle 警告ログファイルに記録したエラーメッセージの文字列を特定する正規表現を設定します。
ACTION に必要なアクションを設定します。

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

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

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

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

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

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

記録された警告にテキスト ORA-00600: internal error が含まれている場合、サーバー障害モニターが対応として実行するアクションは再起動です。
このエントリは、エラー検出時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、エラー検出後も維持されます。
エラーが検出された場合でも、追加のメッセージがリソースのログファイルに出力されることはありません。

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

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

注意 –

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

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

注 –

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

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

ERROR_TYPE に TIMEOUT_ERROR を設定します。
ERROR に、連続検証タイムアウトの最大許容回数を設定します。
ACTION に RESTART を設定します。

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

ERROR_TYPE に TIMEOUT_ERROR を設定します。
ERROR に検証タイムアウトの序数を設定します。たとえば、2 回目の連続検証タイムアウトの場合は、2 を設定します。3 回目の連続検証タイムアウトの場合は、3 を設定します。
ACTION に NONE を設定します。

ヒント –

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

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

サーバー障害モニターは、連続する検証タイムアウトの 2 回目から 4 回目までを無視します。
5 回目の連続検証タイムアウトに対して、サーバー障害モニターが実行するアクションは再起動です。
このエントリは、タイムアウト発生時のデータベースとサーバー障害モニター間の接続状態に関係なく適用されます。
データベースとサーバー障害モニター間の接続状態は、タイムアウト発生後も維持されます。
2 回目から 4 回目の連続検証タイムアウトについては、発生時に次の形式のメッセージがリソースのログファイルに出力されます。
Timeout #number has occurred.
5 回目の連続検証タイムアウトが発生すると、次のメッセージがリソースのログファイルに出力されます。
Timeout #5 has occurred. Restarting.

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

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

すべてのノードが共有するファイルシステムにファイルを配置する
可用性の高いローカルファイルシステムにファイルを配置する
rcp(1) コマンド、rdist(1) コマンドなどのオペレーティングシステムコマンドを使用して、各クラスタノードのローカルファイルシステムにファイルをコピーする

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

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

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

注意 –

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

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

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

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

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

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

次の条件に当てはまる場合は、SUNW.oracle_server リソースタイプをアップグレードしてください。

旧バージョンの Sun Cluster HA for Oracle データサービスからアップグレードする
このデータサービスの新機能を使用する必要がある

リソースタイプをアップグレードする一般的な手順については、『Sun Cluster 3.1 データサービスの計画と管理』の「リソースタイプのアップグレード」を参照してください。このあと、SUNW.oracle_server リソースタイプのアップグレードを完了するために必要な情報を示します。

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

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

リソースタイプのバージョン	Sun Cluster データサービスのリリース
1	1.0
3.1	3.1 5/03
4	3.1 10/03

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

scrgadm -p
scrgadm -pv

このリソースタイプに対応するリソースタイプ登録 (RTR) ファイル : /opt/SUNWscor/oracle_server/etc/SUNW.oracle_server

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

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

移行はいつでも実行できます。
Sun Cluster HA for Oracle データサービスの新機能を使用する場合は、Type_version プロパティに設定する必要がある値は 4 です。
サーバー障害モニターの動作をカスタマイズする場合は、 Custom_action_file 拡張プロパティを設定します。詳細は、Sun Cluster HA for Oracle サーバー障害モニターのカスタマイズを参照してください。

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

例 1–5 `SUNW.oracle_server` リソースタイプのインスタンスを移行する

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

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

SUNW.oracle_server リソースの名前は oracle-rs です。
このリソースのType_version プロパティには 4 が設定されます。
このリソースの障害モニターのカスタム動作は、ファイル /opt/SUNWscor/oracle_server/etc/srv_mon_cust_actions に指定されています。

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

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

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

構成に関する要件

構成計画に関する質問

ノードとディスクの準備

ノードを準備する

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

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

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

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

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

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

次の作業

Oracle データベースの作成

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

次の作業

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

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

次の作業

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

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

次の作業

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

次の作業

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 のインストールを確認する

Oracle クライアント

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

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

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

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

主障害モニターの動作

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

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

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

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

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

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

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

DBMS エラーへの対応の変更

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例 1–5 SUNW.oracle_server リソースタイプのインスタンスを移行する

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

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

例 1–5 `SUNW.oracle_server` リソースタイプのインスタンスを移行する