つい最近、私は最新かつ最高のパッチセットアップデート（PSU）を2ノードのOracleRACシステムに適用しようとしていました。最初のノードではすべてがスムーズに進みました。 PSUを2番目のノードに適用しようとしたときに問題が発生しました。問題はOPatchやPSUにあるのではなく、グリッドインフラストラクチャ（GI）を正常に停止することすらできませんでした。さらに悪いことに、それも出てこないでしょう。
問題をグリッドプロセス間通信デーモン（gipcd）まで追跡しました。「crsctlstop crs」を発行すると、gipcdを正常に終了できなかったことを示すメッセージが表示されました。 GIを起動すると、起動はgipcdを起動しようとするところまで到達し、その後終了します。 My Oracle Support（MOS）とGoogle検索で役立つ記事をたくさん見つけました。それらのドキュメントの多くは私の問題で順調に進んでいるように見えましたが、GIを正常に復旧して実行することができませんでした。ノードを再起動しても役に立ちませんでした。この記事の残りの部分は、問題がgipcdにない場合でも役立ちます。それは、私にとってのこだわりでした。
それで、この時点で、私は決断を下しました。 MOSでサービスリクエスト（SR）を提出できます。または、クラスター内のそのノードを「再構築」することもできます。 SRを提出した場合、来週いつでもノードを稼働させることができれば幸いです。そんなに長く待ちたくなかったし、これが本番システムだったら、そんなに長く待つことはできなかったでしょう。そこで、ノードを再構築することにしました。このブログ投稿では、私が行った手順について詳しく説明します。大まかに言えば、これが関係していることです：
- クラスターからノードを削除します
- そのノード上のGIとRDBMSの残りをクリーンアップします。
- ノードをクラスターに戻します。
- 新しいノードのインスタンスとサービスを追加します。
- インスタンスを起動します。
重要な場合、このシステムはOracle Linux7で実行されているOracle12.1.0.2（GIとRDBMSの両方）です。私の例では、host01が「良い」ノードで、host02が「悪い」ノードです。データベース名は「orcl」です。可能な場合、コマンドには、そのコマンドを実行しているノードを示すプロンプトが表示されます。
まず、不良ノードをクラスターから削除します。
まず、適切なノードのインベントリからRDBMSソフトウェアを削除します。
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 次に、GIソフトウェアをインベントリから削除します。
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent 次に、そのノードをクラスタレジストリから削除します。
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
VIPを削除します。
[root@host01]# srvctl config vip -node host02 VIP exists: network number 1, hosting node host02 VIP Name: host02-vip VIP IPv4 Address: 192.168.1.101 VIP IPv6 Address: VIP is enabled. VIP is individually enabled on nodes: VIP is individually disabled on nodes: [root@host01]# srvctl stop vip -vip host02-vip -force [root@host01]# srvctl remove vip -vip host02-vip Please confirm that you intend to remove the VIPs host02-vip (y/[n]) y
次に、インスタンスを削除します。
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
この時点で、良いノードの観点からは、悪いノードはクラスターの一部ではなくなります。
次に、不良ノードに移動してソフトウェアを削除し、いくつかの構成ファイルをクリーンアップします。
[oracle@host02]$ rm -rf /u01/app/oracle/product/12.1.0.2/ [root@host02 ~]# rm -rf /u01/grid/crs12.1.0.2/* [root@host02 ~]# rm /var/tmp/.oracle/* [oracle@host02]$ /tmp]$ rm -rf /tmp/* [root@host02]# rm /etc/oracle/ocr* [root@host02]# rm /etc/oracle/olr* [root@host02]# rm -rf /pkg/oracle/app/oraInventory [root@host02]# rm -rf /etc/oracle/scls_scr
簡単な方法で、「rm」を使用してRDBMSとGridホームソフトウェアを削除しました。これですべてがクリーンアップされました。良いノードはその部分を単一ノードクラスターの一部と見なし、悪いノードはクラスターについてさえ知りません。次に、そのノードをクラスターに追加し直します。 host01でaddnodeユーティリティを使用します。
[oracle@host01]$ cd $GRID_HOME/addnode
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}" これにより、GIホームがhost01からhost02にクローンされます。最後に、host02でroot.shを実行するように求められます。このスクリプトを実行すると、GIがOCRおよび投票ディスクに接続され、クラスターウェアスタックが起動します。ただし、続行する前に、host02でrootとしてもう1つのクリーンアップルーチンを実行する必要があります。
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
ノードをクリーンアップするときに、上記を以前に実行できた可能性があります。しかし、これは私がこの時にそれを実行したところです。次に、要求に応じてroot.shスクリプトを実行します。
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
この時点で、host02はクラスターの一部になり、GIが稼働しています。 「crs_stat-t」と「olsnodes-n」で確認します。 VIPもチェックします。
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
ここでhost01に戻り、RDBMSソフトウェアのクローンを作成します。
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" これにより、OUIが開始されます。ウィザードをウォークスルーして、クローンプロセスを完了します。
次に、そのノードにインスタンスを追加し直します。
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
すべてがうまくいけば、インスタンスはすぐに起動します。
[oracle@host01]$ srvctl start instance -db orcl -instance orcl2
[oracle@host01]$ srvctl status database -d orcl Instance orcl1 is running on node host01 Instance orcl2 is running on node host02
SQL> select inst_id,status from gv$instance;
INST_ID STATUS ---------- ------------ 1 OPEN 2 OPEN
素晴らしい！残っているのは、必要なサービスを再構成して開始することだけです。持っています。
srvctl modify service -db orcl -service hr_svc -modifyconfig -preferred "orcl1,orcl2"
srvctl start service -db orcl -service hr_svc -node host02
srvctl status service -db orcl
それでおしまい。これですべてが機能しました。
このブログ投稿で、「不良」ノードをクラスターから取り出して再度追加するのがいかに簡単であるかが示されていることを願っています。このプロセス全体が完了するまでに約2時間かかりました。 MOSからこれまでに得たどの解像度よりもはるかに高速です。
私は元の問題の根本的な原因にたどり着きませんでした。ノードをクラスターから取り出して再度追加すると、元に戻って実行できるようになりました。問題の根本的な原因がハードウェアまたはOSに関連している場合、このプロセスは機能しません。
そして、このすべての中で私にとって最良の部分は？ host01にはすでにGIホームとRDBMSホームの両方にPSUが適用されているため、それらをhost02に複製すると、host02でOPatchを実行する必要がなくなります。そのホストはPSUパッチを受け取りました。パッチ適用を完了するために必要なのは、データベースに対してdatapatchを実行することだけでした。