おらくるのいる生活

OracleのDBAとしての、障害対応やらパフォーマンス・チューニングやらの日々を綴っています

OS再起動後、DBに接続できない

涼しくなり始めたある日、OS再起動後、DBに接続できなくなったとの連絡を受けました。

2ノードRACでOS再起動を行ったのは1号機のみ、接続できなくなったのも1号機のみで、構成は以下の通りです。

Oracle RAC(2ノード) EE 12.1.0.2

RHEL Version 7.3 

まず、1号機の状況を確認した所、リスナーとインスタンスが停止していたので、手動で起動しました。

起動は問題なく行われ、その後、接続もできるようになりました。

OS再起動前後の処理がどうなっていたかと言うと、起動・停止それぞれにJP1ジョブを組んであり、ジョブを使用してDBの起動・停止を行う仕組みになっています。

細かく説明すると、停止ジョブは

DBインスタンス停止→リスナー停止→CRS停止

起動ジョブは上記と逆に

CRS起動→リスナー起動→DBインスタンス起動、の順になっています。

 

早速ジョブログを確認してみました。

CRS-4640: Oracle High Availability Services is already active
CRS-4000: Command Start failed, or completed with errors.

CRSを起動しようとしたところ、既に起動済みだったのでエラーになっています。

CRSはデフォルトではOS起動時に自動起動しますが、自動起動の機能は無効(disable)にしてある筈です。

自動起動を無効としている理由ですが、RACの場合はOS高負荷などの理由によりノード間通信ができなくなった場合など、スプリット・ブレイン状態を避ける為にOS再起動を行うことがあります。

そのようなケースでOS起動時にCRSが自動起動し、OS高負荷や通信不可状態が解消されないと再びOS再起動が走り…と何度も再起動を繰り返してしまう虞がある為、CRSの自動起動を無効化しているのです。

 

今回のケースではOS起動時にCRSが勝手に起動しているので、設定がどうなっているか確認します。

# <GI_HOME>/bin/crsctl config crs
CRS-4622: Oracle High Availability Services autostart is enabled.

予想通り、自動起動が有効(enabled)になっています。

構築時には無効(disable)にしてあったので、その後、何らかの理由により有効に変わってしまったようです。

で、その何らかの理由ですが、調べたところ構築後に個別パッチ適用を行っており、それが原因でした。

GIホームにパッチを適用すると、CRS自動起動がデフォルトの有効に戻ってしまうのです。

無効にするコマンドは、以下の通りです。

# <GI_HOME>/bin/crsctl disable crs