TURNING POINT 
※本記事は上記ドキュメントをベースに構成しています。
CLUSTERPRO構築備忘録①～NEC CLUSTERPRO X とは～
CLUSTERPRO構築備忘録②～CLUSTERPRO X インストール手順～
CLUSTERPRO構築備忘録③～フェイルオーバーグループの構築方法～
CLUSTERPRO構築備忘録⑤～Oracle のインストールと設定～
Contents
Oracle サービスリソースの作成
前回までで Oracle側の設定は完了しているので、ここからはうまーく Oracle をフェイルオーバするための設定を入れ込んでいきます。
① タイプ「サービスリソース」の作成を行います。
② 依存関係は「既存の依存関係に従う」を選択したまま「次へ」をクリックしてください。
③ 要件に合わせて設定を行います。ここではデフォルトのまま進みます。
④ 「接続」をクリックするとサービス一覧が表示されるので、「OracleServiceSID名」となっているサービスを選択します。
OracleServiceSID名 の SID名が大文字のものと小文字のものがリストされますが、どちらを選択しても構いません。
⑤ 完了をクリックすると下図のようなエラーが表示されますが、必ず表示されるものなので「了解」をクリックします。
スクリプトリソースの作成
① タイプ「スクリプトリソース」の作成を行います。
② 依存するリソースに先ほど作成した Oracle のサービスリソースを追加します。
③ 要件に合わせて設定を行います。ここではデフォルトのまま進みます。
④ デフォルトで「start.bat」と「stop.bat」のテンプレートが用意されているので、それぞれを選択した状態で「編集」をクリックして設定内容を追記します。
例えば「start.bat」を開くと下図のように予め設定が入っています。そこの歯抜けになっている部分に内容を追記していくイメージです。
start.batの編集例
（中略）
rem *************
rem 業務通常処理
rem *************
set ORACLE_SID=sid1
lsnrctl start listener
IF errorlevel 1 (
echo “listener start error”
EXIT 1
)
sqlplus /nolog @E:\DBstartup.sql
IF errorlevel 1 (
echo “db start error”
EXIT 2
)
（中略）
rem *************
rem フェイルオーバ後の業務起動ならびに復旧処理
rem *************
set ORACLE_SID=sid1
lsnrctl start listener
IF errorlevel 1 (
echo “listener start error”
EXIT 3
)
sqlplus /nolog @E:\DBstartup.sql
IF errorlevel 1 (
echo “db start error”
EXIT 4
)
start.bat の EXIT の数字って、マニュアルだと実は全部 “1” になっています。これを変更している理由は勿論あります。ここの数字って CLUSTERPRO のエラーメッセージで「終了コード：1」という形で出力されるんですよね。なので、どこで処理が終了されたかという切り分けのために値を変えています。
例えば下図の場合は db1_script リソースの終了コードが “2” なので、業務通常処理のデータベース起動がうまく出来ていないことがわかります。
stop.batの編集例
（中略）
rem *************
rem 業務通常処理
rem *************
set ORACLE_SID=sid1
sqlplus /nolog @E:\DBshutdown.sql
IF errorlevel 1 (
clplogcmd -m “db stop error” -i 1 -l ERR
)
lsnrctl stop listener
IF errorlevel 1 (
clplogcmd -m “listener stop error” -i 2 -l ERR
)
（中略）
rem *************
rem フェイルオーバ後の業務起動ならびに復旧処理
rem *************
set ORACLE_SID=sid1
sqlplus /nolog @E:\DBshutdown.sql
IF errorlevel 1 (
clplogcmd -m “db stop error” -i 1 -l ERR
)
lsnrctl stop listener
IF errorlevel 1 (
clplogcmd -m “listener stop error” -i 2 -l ERR
)
（中略）
:EXIT
EXIT 0
⑤ 完了をクリックします。
.sql ファイルの作成
上記で作成したスクリプトリソースは結局「E:\DBstartup.sql」と「E:\DBshutdown.sql」を実行しているだけです。よってそのファイルを作成して指定のフォルダに配置しなければなりません。
DBstartup.sqlの設定例
whenever sqlerror exit 1
connect sys/Passw0rd as sysdba
startup pfile=E:\oradata\sid1\initsid1.ora
alter pluggable database all open;
exit;
DBstartup.sqlの設定例
whenever sqlerror exit 1
connect sys/Passw0rd as sysdba
shutdown immediate
exit;
正常な戻り値を 0 に
作成したスクリプトリソースのプロパティから「調整」をクリックします。開始と終了の「正常な戻り値」に「0」を設定してください。
全体の依存関係の確認
最終的に以下のような形になっていることを確認してください。
| 深度 | 名前 | 依存リソース名 | タイプ |
| 0 | fip | none | |
| 0 | sd | none | |
| 1 | db1_service | — | 「既定の依存関係」に従った情報 |
| 2 | db1_script | db1_service | サービスリソース |
設定保存
builder の「設定の反映」を実行するのをわすれずに。
設定を保存すればすべての作業は完了です！
ここまでで最低限の設定は終了ですが、実は今回3つのオプションライセンスを持っているので、その設定もしなければなりません。それとパブリック LAN の障害も検出したいです。まとめると、以下の設定を行わなければなりません。
- パブリック LAN 異常検出のための “NIC Link Up/Down監視” モニタリソースの追加
- Database Agent の “Oracle 監視” モニタリソースの追加
- System Resource Agent の “システム監視” リソースの追加
- Alert Service によるメール通報の設定
これらは機会があれば記事にしようかと思います。
フェイルオーバテスト
まずはクラスタ全体をリブートします。そのあとにフェイルオーバで行ったり来たりしても問題がないことを確認してください。
トラブルシューティング
上記でうまくいかなかった場合はトラブルシュートしてください。
ただ、CLUSTERPRO では Cluster WebUI や WebManager からアラートログを確認することができますが、情報があまりにも少ないです。
Cluster WebUI の上部バーにある下矢印マークをクリックするとログをダウンロードすることができます。ざっくばらんとした感じでダウンロードされるので目的のログを探し出すのが辛いですが、トラブルシューティングでは必須のログです。
事例紹介：2号機だけで db1_script が失敗し、フェイルオーバすることができない
結論から言うと、前回の「共有ディスクの権限追加」でのアクセス権の付与が漏れていたことが原因でした。
そもそも db1_script が失敗するあるあるの原因は「データベースサービス」と「リスナーサービス」が手動になっていないことです。ただしこの時は両方とも手動になっていました。
そして start.bat の終了コードは “EXIT2″。つまりリスナーは起動できたがデータベースがうまく起動できていない状況でした。
そこで上記のログを嫌々（量が多くまとまりがないので）見ていたら、いい感じのログがありました。解決に至ったログは以下のものでした。
log\node2\log\scrpl0.log
ORA-01157: データファイル11を識別/ロックできません –
scrpl.c:89 main -DBWRトレース・ファイルを参照してください
scrpl.c:89 main -ORA-01110: データファイル11: ‘E:\ORADATA\SID1\SID1PDB\USERS01.DBF’
あ、これアクセス権ないやつだなと思い「E:\ORADATA\SID1\SID1PDB\USERS01.DBF」を確認すると案の定下図のように oradb のフルコントロールアクセス権を付与し忘れていました。
2号機の oradb 付与し忘れ
こんな感じで、ダウンロードしたログを確認すると意外と情報があったりするので、面倒くさがらずにログを確認することをお勧めします。
