パッチ適用・ハードウェア保守・基盤側のメンテナンスなど、RAC をクラスタごと止めて起こす機会は定期的にやってきます。
そのとき順序の拠りどころになる原則は、1つだけです。
止める順序は DB → GI → OS → ストレージ。起こす順序はその逆。
なぜこの順序かというと、データベースは Grid Infrastructure（クラスタを管理する基盤ソフトウェア。以下 GI）がないと動けず、GI は OS と共有ストレージがないと動けないからです。
動くために必要なものが残っているうちに、必要とする側（データベース）から先に止める。
起こすときはその逆に、必要とされる側（ストレージ・OS）から先に起こす。
順序の理由はこれだけです。
ただ、実際に作業すると、各段階で「どこまで止まったか・どこまで上がったか」を何で確認するかが次の課題になります。
そこで今回は、2ノードRAC で停止から起動までの一連の流れを実機で実施し、全ステップを「操作前の確認 → 操作 → 操作後の確認」の3点セットで記録しました。
確認の軸は、crsctl stat res -t の Target（目指す状態）／State（実際の状態） の2列です。
この2列は、障害時のログ解析を扱った記事「RACインスタンスがダウン ― どのログを解析するのか」でも確認の軸にしたものです。
計画停止の途中でこの2列がどう変わっていくかを見ると、障害時のログを読むときとは別の発見があります。
「srvctl で止めたデータベースは、クラスタを再起動しても自動では上がらない」という、知らないと戸惑う挙動も、Target 列で説明がつきます。
1. 検証環境と全体の順序
検証環境は Oracle Database 19c（19.28）の2ノードRAC。
DB名 rc19u、インスタンスは node1 側が rc19u1、node2 側が rc19u2 です。
共有ストレージは iSCSI で、両ノードから同じディスクが見えています。
停止と起動の全体順序は次のとおりです。
| 順番 | 停止する対象 | 使うコマンド |
|---|---|---|
| 1 | データベース | srvctl stop database（oracle ユーザー） |
| 2 | GI（node2 → node1 の順） | crsctl stop crs（root ユーザー・各ノードで実行） |
| 3 | OS（node2 → node1 の順） | shutdown -h now（root ユーザー） |
| 4 | 共有ストレージ | ※後述（本検証では停止しない） |
| 順番 | 起動する対象 | 使うコマンド |
|---|---|---|
| 1 | 共有ストレージ | ※後述（本検証では停止していない） |
| 2 | OS（両ノード） | 仮想化基盤・電源操作 |
| 3 | GI | 自動起動（crsctl check crs で確認） |
| 4 | データベース | srvctl start database（oracle ユーザー） |
共有ストレージについて先に補足します。
順序の原則どおりなら、ストレージは最後に停止し、最初に起動する対象です。
ただし実務では、共有ストレージ（ストレージ装置）は複数システムで共用され、常時稼働が前提です。DBA が電源操作をする対象になることはまずありません。
本検証でもストレージは停止せず、「原則としては最後に止めて、最初に起こす対象」とだけ押さえておきます。
srvctl と crsctl の使い分け
この記事では2つのコマンドを使い分けます。
| コマンド | 見える範囲 | 出力されるもの | この記事での役割 |
|---|---|---|---|
srvctl | 個別のリソース（データベースなど） | 対象リソースの状態・操作結果 | 操作（停止・起動）と、対象ごとの確認 |
crsctl stat res -t | クラスタが管理する全リソース | 各リソースの Target（目指す状態） と State（実際の状態） の一覧 | 各操作の前後の全体確認 |
操作は srvctl、全体の確認は crsctl、という分担です。
各ステップで「操作前に一覧を確認 → 操作 → 操作後に同じ一覧を確認」を繰り返し、どの行がどう変わったかを追っていきます。
この3点セットは、そのまま本番作業手順書のエビデンス取得の型としても使えます。
※ 本検証では crsctl を root ユーザーで実行しているため、フルパス（
/u01/app/19.0.0/grid/bin/crsctl）で実行しています。
grid ユーザーであれば PATH が通っているのでcrsctlだけで実行できます。
2. 停止手順 ― DB → GI → OS の順に止める
Step 0. 停止前の状態を記録する
最初に、正常稼働中の状態を記録しておきます。
最後の起動確認で「元どおりに戻ったか」を比べる基準になるため、このステップは省略しません。
まずクラスタ全体のリソース一覧です。
[root@node1 ~]# /u01/app/19.0.0/grid/bin/crsctl stat res -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.LISTENER.lsnr
ONLINE ONLINE node1 STABLE
ONLINE ONLINE node2 STABLE
ora.LISTENER_MGMT.lsnr
ONLINE ONLINE node1 STABLE
ONLINE ONLINE node2 STABLE
ora.chad
ONLINE ONLINE node1 STABLE
ONLINE ONLINE node2 STABLE
ora.net1.network
ONLINE ONLINE node1 STABLE
ONLINE ONLINE node2 STABLE
ora.net2.network
ONLINE ONLINE node1 STABLE
ONLINE ONLINE node2 STABLE
ora.ons
ONLINE ONLINE node1 STABLE
ONLINE ONLINE node2 STABLE
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup)
1 ONLINE ONLINE node1 STABLE
2 ONLINE ONLINE node2 STABLE
ora.DATA.dg(ora.asmgroup)
1 ONLINE ONLINE node1 STABLE
2 ONLINE ONLINE node2 STABLE
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE node1 STABLE
ora.LISTENER_SCAN2.lsnr
1 ONLINE ONLINE node2 STABLE
ora.LISTENER_SCAN3.lsnr
1 ONLINE ONLINE node2 STABLE
ora.RECO.dg(ora.asmgroup)
1 ONLINE ONLINE node1 STABLE
2 ONLINE ONLINE node2 STABLE
ora.asm(ora.asmgroup)
1 ONLINE ONLINE node1 Started,STABLE
2 ONLINE ONLINE node2 Started,STABLE
ora.asmnet1.asmnetwork(ora.asmgroup)
1 ONLINE ONLINE node1 STABLE
2 ONLINE ONLINE node2 STABLE
ora.cvu
1 ONLINE ONLINE node2 STABLE
ora.node1.vip
1 ONLINE ONLINE node1 STABLE
ora.node1_2.vip
1 ONLINE ONLINE node1 STABLE
ora.node2.vip
1 ONLINE ONLINE node2 STABLE
ora.node2_2.vip
1 ONLINE ONLINE node2 STABLE
ora.qosmserver
1 ONLINE ONLINE node2 STABLE
ora.rc19u.db
1 ONLINE ONLINE node1 Open,STABLE
2 ONLINE ONLINE node2 Open,STABLE
ora.scan1.vip
1 ONLINE ONLINE node1 STABLE
ora.scan2.vip
1 ONLINE ONLINE node2 STABLE
ora.scan3.vip
1 ONLINE ONLINE node2 STABLE
--------------------------------------------------------------------------------※ 本記事の
crsctl stat res -tの出力では、State details に表示されるHOME=...（Oracleホームのパス）の表記を省略しています。
※ 本検証環境は管理用ネットワークを追加した2系統構成のため、ora.net2.network・ora.LISTENER_MGMT.lsnr・ora.node1_2.vip／ora.node2_2.vipが表示されています。パブリック1系統の構成ではこれらの行は表示されません。
全リソースが Target=ONLINE／State=ONLINE、ora.rc19u.db は両インスタンスとも Open です。
次に、クラスタから見たノードの状態です。
olsnodes は、クラスタを構成するノードの一覧を表示するコマンドです。
オプション -n でノード番号、-s で各ノードの状態が出力に加わります。
[root@node1 ~]# /u01/app/19.0.0/grid/bin/olsnodes -s -n
node1 1 Active
node2 2 Active出力は左から、ノード名・ノード番号（クラスタ内でノードを識別する番号）・状態です。
状態が Active なら、そのノードは GI が起動していてクラスタに参加しています。
crsctl stat res -t がリソース単位（データベース・リスナー・VIP など）の確認なのに対し、olsnodes は「クラスタに何台のノードがいて、それぞれ参加中かどうか」というノード単位の確認です。
リソースの一覧は行数が多いので、ノードの参加状態だけを見たいときはこちらが手早く確実です。
この後、GI を停止したノードがどう表示されるかも、このコマンドで確認します（Step 3）。
最後に、srvctl から見たデータベースの状態です。
[oracle@node1 ~]$ srvctl status database -d rc19u
インスタンスrc19u1はノードnode1で実行中です。
インスタンスrc19u2はノードnode2で実行中です。3つの視点（リソース一覧・ノード・データベース）がすべて正常であることを記録できました。
ここから停止に入ります。
Step 1. データベースを停止する（srvctl stop database）
最初に止めるのは、順序の先頭にあるデータベースです。
oracle ユーザーで、両ノードのインスタンスをまとめて停止します。
[oracle@node1 ~]$ srvctl stop database -d rc19u
[oracle@node1 ~]$成功時は何も出力されません（本検証では約1分でプロンプトが戻りました）。
必ず確認コマンドで結果を見ます。
まず srvctl の視点です。
[oracle@node1 ~]$ srvctl status database -d rc19u
インスタンスrc19u1はノードnode1で実行されていません。
インスタンスrc19u2はノードnode2で実行されていません。次に crsctl の視点です。
一覧のうち、変化したのは ora.rc19u.db の行だけでした（関連行のみ抜粋）。
[root@node1 ~]# /u01/app/19.0.0/grid/bin/crsctl stat res -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
...
ora.rc19u.db
1 OFFLINE OFFLINE Instance Shutdown,ST
ABLE
2 OFFLINE OFFLINE Instance Shutdown,ST
ABLE
...ここで注目したいのは、Target と State の両方が OFFLINE に変わったことです。
障害でインスタンスが停止した場合と並べると、Target 列の違いがはっきりします。
| 停止のしかた | Target | State | クラスタの動き |
|---|---|---|---|
| 障害でのインスタンス停止 | ONLINE | OFFLINE | 「本来は動いているべき」なので、再起動を試みる |
srvctl stop database（計画停止） | OFFLINE | OFFLINE | 「停止があるべき状態」として記録され、自動再起動しない |
この Target の違いが、後の起動フェーズで効いてきます（Step 6 で確認します）。
Step 2. node2 の GI を停止する（crsctl stop crs）
次に GI を停止します。
GI の停止はノード単位で、root ユーザーで crsctl stop crs を実行します。
順番は node2 → node1 としました。
どちらのノードから止めてもかまいません。
今回は確認コマンドを node1 で実行しているため、node2 を先に止めて、node1 から途中経過を確認します。
node2 で実行します（関連行のみ抜粋）。
[root@node2 ~]# /u01/app/19.0.0/grid/bin/crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'node2'
CRS-2673: Attempting to stop 'ora.crsd' on 'node2'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on server 'node2'
CRS-33673: リソース・グループ'ora.asmgroup'をサーバー'node2'で停止しようとしています
CRS-2673: Attempting to stop 'ora.DATA.dg' on 'node2'
CRS-2673: Attempting to stop 'ora.RECO.dg' on 'node2'
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'node2'
CRS-2677: Stop of 'ora.DATA.dg' on 'node2' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'node2'
CRS-2677: Stop of 'ora.asm' on 'node2' succeeded
...
CRS-33677: リソース・グループ'ora.asmgroup'がサーバー'node2'で正常に停止しました。
CRS-2677: Stop of 'ora.scan3.vip' on 'node2' succeeded
CRS-2677: Stop of 'ora.qosmserver' on 'node2' succeeded
CRS-2672: Attempting to start 'ora.qosmserver' on 'node1'
CRS-2672: Attempting to start 'ora.scan2.vip' on 'node1'
CRS-2672: Attempting to start 'ora.scan3.vip' on 'node1'
CRS-2672: Attempting to start 'ora.cvu' on 'node1'
CRS-2672: Attempting to start 'ora.node2.vip' on 'node1'
CRS-2672: Attempting to start 'ora.node2_2.vip' on 'node1'
CRS-2676: Start of 'ora.node2.vip' on 'node1' succeeded
CRS-2676: Start of 'ora.scan2.vip' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.LISTENER_SCAN2.lsnr' on 'node1'
CRS-2676: Start of 'ora.LISTENER_SCAN2.lsnr' on 'node1' succeeded
...
CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'node2' has completed
CRS-2677: Stop of 'ora.crsd' on 'node2' succeeded
CRS-2673: Attempting to stop 'ora.storage' on 'node2'
CRS-2673: Attempting to stop 'ora.ctssd' on 'node2'
CRS-2673: Attempting to stop 'ora.cssd' on 'node2'
CRS-2677: Stop of 'ora.cssd' on 'node2' succeeded
CRS-2673: Attempting to stop 'ora.gipcd' on 'node2'
CRS-2677: Stop of 'ora.gipcd' on 'node2' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'node2' has completed
CRS-4133: Oracle High Availability Services has been stopped.このログには、注目したい点が2つあります。
1つ目は、計画停止でも VIP と SCAN はフェイルオーバすることです。
途中から CRS-2673（停止） に混じって CRS-2672: Attempting to start ... on 'node1' が並び始めます。
node2 が持っていたノードVIP（ora.node2.vip）・SCAN VIP・SCANリスナーなどが、node1 で起動し直されています。
crsctl stop crs は「このノードをクラスタから計画的に外す」操作であり、クラスタとして提供し続けるべきリソース（Target=ONLINE のもの）は、残るノードへ移されます。
障害時だけの動きではなく、計画停止でも同じ機構が動くことが、停止コマンドの出力だけで確認できます。
2つ目は、ノードの内部でも、同じ考え方の順序で停止が進むことです。
CRSD 管理のリソース（ディスクグループ → ASM → リスナー → VIP）が先に止まり、その後に下位スタック（cssd・gipcd など、名前の末尾 d は daemon の意味）が止まります。
手動の手順で守っている「必要とする側から先に止める」順序と、GI がノード内部でリソースを止める順序は同じです。
停止後の確認です。
node2 の GI デーモンに問い合わせると、応答できない旨のエラーになります。
これが「GI スタックが止まっている」ことの確認になります。
[root@node2 ~]# /u01/app/19.0.0/grid/bin/crsctl check crs
CRS-4639: Could not contact Oracle High Availability ServicesStep 3. node1 から node2 の離脱を確認する
残った node1 から、クラスタの見え方を確認します。
まずノードの状態です。
[root@node1 ~]# /u01/app/19.0.0/grid/bin/olsnodes -s -n
node1 1 Active
node2 2 Inactivenode2 が Inactive になりました。
次にリソース一覧です（全文から主要な変化のみ抜粋）。
[root@node1 ~]# /u01/app/19.0.0/grid/bin/crsctl stat res -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.LISTENER.lsnr
ONLINE ONLINE node1 STABLE
...
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.DATA.dg(ora.asmgroup)
1 ONLINE ONLINE node1 STABLE
2 ONLINE OFFLINE STABLE
...
ora.node2.vip
1 ONLINE INTERMEDIATE node1 FAILED OVER,STABLE
ora.node2_2.vip
1 ONLINE INTERMEDIATE node1 FAILED OVER,STABLE
...
ora.rc19u.db
1 OFFLINE OFFLINE STABLE
2 OFFLINE OFFLINE STABLE
ora.scan1.vip
1 ONLINE ONLINE node1 STABLE
ora.scan2.vip
1 ONLINE ONLINE node1 STABLE
ora.scan3.vip
1 ONLINE ONLINE node1 STABLE
--------------------------------------------------------------------------------1回の停止操作の後ですが、行ごとに状態が分かれています。
この一覧には Target／State の読み方のポイントが集まっているので、少し立ち止まって整理します。
| リソース | Target | State | 読み方 |
|---|---|---|---|
| node2 のノードVIP | ONLINE | INTERMEDIATE（FAILED OVER） | アドレスは node1 上で応答しているが、本来の場所（node2）にいない中間状態 |
| SCAN VIP（3つとも） | ONLINE | ONLINE | node1 に移っても正常扱い。どのノードで動いてもよいリソース |
ASM 系（ora.asmgroup の node2 側） | ONLINE | OFFLINE | 停止中だが「node2 が復帰したら自動起動すべきもの」として Target が残る |
データベース（ora.rc19u.db） | OFFLINE | OFFLINE | Step 1 の計画停止の記録のまま |
この表から、押さえておきたい読み方が3つあります。
1つ目は、State は ONLINE／OFFLINE の2値ではないことです。
node2 のノードVIP に出ている INTERMEDIATE は、「起動しているが、本来の状態ではない」ことを示す中間状態です。
2つ目は、同じフェイルオーバでも、ノードVIP と SCAN VIP で表示が異なることです。
ノードVIP は「そのノードのためのアドレス」なので、よそのノードにいる状態は INTERMEDIATE として区別されます。
一方、SCAN VIP はもともとクラスタ内のどのノードで動いてもよいリソースなので、node1 にいても正常（ONLINE）扱いです。
リソースの設計思想の違いが、State 列にそのまま現れています。
3つ目は、同じ「停止中」でも Target が異なることです。
ASM 系リソースの node2 側は Target=ONLINE のまま State だけ OFFLINE。
Step 1 で見た srvctl stop database（Target ごと OFFLINE）と対照的です。
crsctl stop crs によるノード単位の停止では、そのノード上のリソースの Target は ONLINE のまま残り、「node2 が復帰したら自動で起動すべきもの」という扱いになります。
実際に起動フェーズで、この Target=ONLINE のリソースだけが自動で戻ってくることを確認します。
Step 4. node1 の GI を停止する（最後のノード）
続いて、最後に残った node1 の GI を停止します（関連行のみ抜粋）。
[root@node1 ~]# /u01/app/19.0.0/grid/bin/crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'node1'
CRS-2673: Attempting to stop 'ora.crsd' on 'node1'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on server 'node1'
CRS-2673: Attempting to stop 'ora.qosmserver' on 'node1'
CRS-2673: Attempting to stop 'ora.node1.vip' on 'node1'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN2.lsnr' on 'node1'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN3.lsnr' on 'node1'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN1.lsnr' on 'node1'
CRS-33673: リソース・グループ'ora.asmgroup'をサーバー'node1'で停止しようとしています
...
CRS-2677: Stop of 'ora.node2.vip' on 'node1' succeeded
CRS-2677: Stop of 'ora.scan3.vip' on 'node1' succeeded
CRS-2677: Stop of 'ora.scan1.vip' on 'node1' succeeded
...
CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'node1' has completed
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'node1' has completed
CRS-4133: Oracle High Availability Services has been stopped.node2 のときと同じ形式のログですが、決定的な違いが1つあります。
CRS-2672（別ノードでの起動開始）が1行も出ません。
先に止めた node2 のときと並べると、次のとおりです。
| node2 の停止（残るノードがある） | node1 の停止（最後のノード） | |
|---|---|---|
CRS-2672（別ノードでの起動開始） | 出る | 出ない |
| VIP・SCAN の行き先 | 残るノード（node1）へフェイルオーバ | 移動先がなく、そのまま停止 |
| クラスタへの接続経路 | SCAN が node1 で維持される | SCAN VIP・SCANリスナーがすべて停止＝ここで完全に閉じる |
Step 3 で node1 に移ってきていた ora.node2.vip も、ここで停止しています（FAILED OVER 状態だった VIP の最終的な行き先です）。
確認は node2 と同じです。
[root@node1 ~]# /u01/app/19.0.0/grid/bin/crsctl check crs
CRS-4639: Could not contact Oracle High Availability ServicesStep 5. OS を停止する
GI が両ノードとも止まったので、OS を停止します。
順番は GI と同じく node2 → node1 としました。
[root@node2 ~]# shutdown -h now[root@node1 ~]# shutdown -h now実行と同時に SSH セッションが切断されます。
これで、共有ストレージを除くすべてが停止しました。
3. 起動手順 ― OS → GI → DB の順に起こす
Step 6. OS を起動し、GI の自動起動を確認する
起動は停止の逆順です。
共有ストレージは稼働したままなので、両ノードの OS を起動するところからです（本検証では仮想化基盤の操作で、両ノードをほぼ同時に起動しました）。
OS が起動すると、GI は自動で起動します（デフォルトの自動起動が有効な構成の場合）。
node1 に再接続して確認します。
[root@node1 ~]# /u01/app/19.0.0/grid/bin/crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online4つのサービスがすべて online です。
続いてリソース一覧を確認します（関連行のみ抜粋）。
[root@node1 ~]# /u01/app/19.0.0/grid/bin/crsctl stat res -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.DATA.dg(ora.asmgroup)
1 ONLINE ONLINE node1 STABLE
2 ONLINE ONLINE node2 STABLE
...
ora.node2.vip
1 ONLINE ONLINE node2 STABLE
ora.node2_2.vip
1 ONLINE ONLINE node2 STABLE
...
ora.rc19u.db
1 OFFLINE OFFLINE Instance Shutdown,ST
ABLE
2 OFFLINE OFFLINE Instance Shutdown,ST
ABLE
ora.scan1.vip
1 ONLINE ONLINE node2 STABLE
ora.scan2.vip
1 ONLINE ONLINE node1 STABLE
ora.scan3.vip
1 ONLINE ONLINE node1 STABLE
--------------------------------------------------------------------------------この一覧に、今回の検証で確認したかった動きが同時に現れています。
Step 3（node2 の GI 停止後）の一覧と突き合わせて整理すると、次のとおりです。
| リソース | Step 3（node2 の GI 停止後） | クラスタ再起動後 | こうなる理由 |
|---|---|---|---|
| node2 のノードVIP | node1 上で INTERMEDIATE（FAILED OVER） | node2 上で ONLINE | フェイルオーバは恒久的な移動ではなく、元のノードが復帰すれば自動で戻る |
| SCAN VIP | 3つとも node1 に集約 | 両ノードへ分散（配置は停止前と入れ替わり） | SCAN に定位置はなく、分散して配置されること自体が正常 |
ASM 系（ora.asmgroup の node2 側） | Target=ONLINE／State=OFFLINE | 自動で ONLINE に復帰 | Target=ONLINE が保持されていたため、GI の起動とともに自動起動 |
データベース（ora.rc19u.db） | Target=OFFLINE／State=OFFLINE | OFFLINE のまま | srvctl stop database で Target=OFFLINE が記録済み。「停止があるべき状態」として維持される |
分かれ目は Target 列です。
Target=ONLINE だったリソースは、クラスタの再起動とともにすべて自動で ONLINE に戻りました。
Target=OFFLINE のデータベースだけが、停止したままです。
これは異常ではなく、Step 1 の計画停止の記録が正しく守られている状態です。
srvctl で止めたデータベースは、srvctl で起動する。
自動起動を期待して待っていても上がってこないので、この挙動は覚えておく必要があります。
なお、SCAN VIP の配置が停止前（scan1=node1・scan2/scan3=node2）から scan1=node2・scan2/scan3=node1 に入れ替わっていますが、表のとおり定位置がないリソースなので、差分として問題ありません。
Step 7. データベースを起動する（srvctl start database）
最後に、データベースを起動します。
oracle ユーザーで実行します。
[oracle@node1 ~]$ srvctl status database -d rc19u
インスタンスrc19u1はノードnode1で実行されていません。
インスタンスrc19u2はノードnode2で実行されていません。
[oracle@node1 ~]$ srvctl start database -d rc19u
[oracle@node1 ~]$ srvctl status database -d rc19u
インスタンスrc19u1はノードnode1で実行中です。
インスタンスrc19u2はノードnode2で実行中です。停止時と同じく、srvctl start database も成功時は何も出力されません（本検証では1〜2分でプロンプトが戻りました）。
srvctl の「実行中」は、インスタンスのプロセスが動いていることの確認です。
データベースとして OPEN まで到達したかは、もう1段深い確認として gv$instance で見ます。
[oracle@node1 ~]$ sqlplus / as sysdba
SQL> SELECT inst_id, instance_name, status FROM gv$instance ORDER BY inst_id;
INST_ID INSTANCE_NAME STATUS
---------- ---------------- ------------
1 rc19u1 OPEN
2 rc19u2 OPEN※ sqlplus 起動時のバナー表示（バージョン・接続メッセージ）は省略しています。
両インスタンスとも OPEN です。
srvctl と SQL では、確認している層が異なります。
| 確認コマンド | 確認できること |
|---|---|
srvctl status database | インスタンスのプロセスが実行中かどうか |
gv$instance の STATUS | データベースとして OPEN まで到達したか |
最終確認は gv$instance の STATUS=OPEN まで見る、と型にしておくと確実です。
Step 8. 停止前の記録と突き合わせる
仕上げに、Step 0 と同じコマンドで最終状態を確認します。
[root@node1 ~]# /u01/app/19.0.0/grid/bin/crsctl stat res -t
--------------------------------------------------------------------------------
Name Target State Server State details
--------------------------------------------------------------------------------
...
ora.rc19u.db
1 ONLINE ONLINE node1 Open,STABLE
2 ONLINE ONLINE node2 Open,STABLE
...[root@node1 ~]# /u01/app/19.0.0/grid/bin/olsnodes -s -n
node1 1 Active
node2 2 Active全リソースが ONLINE、ora.rc19u.db は両インスタンスとも Open、両ノード Active。
Step 0 の記録との差分は、SCAN VIP／SCANリスナーの配置だけ（前述のとおり正常）でした。
停止から起動までの一連の作業が、確認つきで完了です。
4. よくある疑問
Q1. ノードを止める順番・起こす順番に、決まりはある？
停止は、技術的にはどちらのノードから止めても問題ありません。
途中経過の確認（crsctl stat res -t や olsnodes）を、GI がまだ動いている側のノードで行うことだけ押さえておけば、逆順でも同じ作業ができます。
起動も同様です。
本検証では両ノードの OS をほぼ同時に起動し、GI・ASM・リスナー・VIP・SCAN がすべて自動で ONLINE に戻ることを確認しました。
GI がリソース間の起動順序を管理しているため、ノード間の厳密な起動順を手動で守る必要はありませんでした。
ただし、決まりがないからこそ、実際の運用では「どちらから止めるか」「どのノードで確認するか」を手順書で固定しておくことをおすすめします。
Q2. クラスタ全体を止めるなら、crsctl stop cluster -all は使わない？
crsctl stop cluster -all は、どれか1ノードで実行すると全ノードの Clusterware スタックを停止するコマンドです。
本記事で使った crsctl stop crs とは、止まる範囲が異なります。
| コマンド | 実行のしかた | 止まる範囲 |
|---|---|---|
crsctl stop crs | 止めたいノードごとに実行 | そのノードの GI スタック全体（Oracle High Availability Services まで） |
crsctl stop cluster -all | 1ノードで実行すれば全ノードが対象 | 各ノードの Clusterware スタック（Oracle High Availability Services は稼働したまま） |
crsctl stop crs が Oracle High Availability Services（OS 起動時に GI 全体を起動する、土台のプロセス群）まで止めることは、Step 2 のログの最終行 CRS-4133: Oracle High Availability Services has been stopped. で確認できます。
一方、crsctl stop cluster はこの土台を残したまま、その上の Clusterware スタックだけを止めます。
『Oracle Clusterware管理およびデプロイメント・ガイド』の CRSCTLユーティリティ・リファレンスでは、全ノードの Clusterware を停止する場合は crsctl stop cluster を使うとされています。
理由として、このコマンドではスタックの停止前にリソースが他のサーバーへ再配置されないことが挙げられています。
本記事のように crsctl stop crs を1ノードずつ実行すると、Step 2 で見たとおり VIP・SCAN がいったん残るノードへフェイルオーバします。
全ノードを止めると決まっている場面では、この一時的な移動を挟まずに済む、という違いです。
使い分けの目安は次のとおりです。
OS の停止まで行う計画停止では、本記事のとおりノードごとに crsctl stop crs で GI を止めてから OS を停止します。
OS は動かしたまま、クラスタスタックだけを止めて起こすメンテナンスでは、crsctl stop cluster -all で止めて crsctl start cluster -all で起こします。
なお、本検証で実行したのは crsctl stop crs のみで、crsctl stop cluster -all の挙動は上記ガイドの記載に基づいています。
Q3. クラスタを再起動したのに、データベースが起動していない。異常？
srvctl stop database で停止していた場合、それは正常です。
Target=OFFLINE（停止があるべき状態）が記録されているため、クラスタは自動起動しません。
srvctl start database で起動します。
逆に、障害でインスタンスが停止した場合は Target=ONLINE のまま State だけが OFFLINE になり、クラスタは自動再起動を試みます。
「自動で上がるかどうか」は Target 列で決まっている、と整理できます。
Q4. 起動後、SCAN VIP の場所が停止前と変わっていた。戻すべき？
戻す必要はありません。
SCAN VIP はどのノードで動いてもよいリソースで、定位置がありません。
一方、ノードVIP には本来の場所があります。
本検証でも、停止中に node1 へフェイルオーバしていた node2 のノードVIP は、再起動後に node2 上の ONLINE に戻りました（Step 6）。
もしノードVIP が INTERMEDIATE／FAILED OVER のまま戻っていなければ、本来のノードがクラスタに復帰できていないことを意味します。
olsnodes -s -n で対象ノードが Active に戻っているかを確認し、戻っていなければ、対象ノード側で OS と GI の起動状態（crsctl check crs）を確認します。
GI が起動に失敗しているようであれば、CRSアラートログの調査に進みます。
Q5. 共有ストレージはいつ止める・いつ起こす？
順序の原則では、ストレージは最後に止めて、最初に起こす対象です。
GI より先にストレージを止めると、投票ディスクへの I/O が失われ、別記事「RACのノードエビクション ― 投票ディスク到達不可（ディスクハートビート断）はどのログを解析するのか」で再現した障害と同じ状況を自分で作ることになります。
なお実務では、共有ストレージは複数システムで共用される常時稼働の装置であることが多く、DB 側の計画停止でストレージまで止める場面は限られます。
その場合も「GI が動いている間はストレージを止めない」という順序だけは守る必要があります。
Q6. サービスを止めずに、1ノードずつメンテナンスしたい場合は？
本記事の手順は、クラスタ全体を止める完全停止を想定したものです。
サービスを提供したまま1ノードずつ停止・起動するローリング方式では、使うコマンドがインスタンス単位（srvctl stop instance）になり、確認の中心も「残ったノードでサービスが受けられているか」に変わります。
確認ポイントが本記事とは異なるため、別記事で取り上げます。
5. まとめ
停止・起動の全体像です。
【停止】DB → GI → OS → ストレージ 【起動】ストレージ → OS → GI → DB
DB srvctl stop database -d <db> OS 両ノード起動
│ 確認: srvctl status │ （GI は自動起動）
│ 確認: crsctl stat res -t │
│ → Target/State とも OFFLINE GI 確認: crsctl check crs
▼ │ 確認: crsctl stat res -t
GI crsctl stop crs（node2） │ → DB 以外が ONLINE に戻る
│ 確認: crsctl check crs（CRS-4639） ▼
│ 確認: olsnodes（Inactive） DB srvctl start database -d <db>
│ 確認: crsctl stat res -t（VIP移動） 確認: srvctl status
▼ 確認: gv$instance → OPEN
GI crsctl stop crs（node1・最後） 確認: crsctl stat res -t
│ 確認: crsctl check crs → 停止前の記録と突き合わせ
▼
OS shutdown -h now（node2 → node1）
▼
（ストレージ: 原則は最後に停止・最初に起動。常時稼働なら操作対象外）最後に、今回の停止から起動までの作業で確認できたことを整理します。
| 場面 | 確認できたこと |
|---|---|
srvctl stop database | Target も OFFLINE になる＝クラスタは自動再起動しない（計画停止の記録） |
crsctl stop crs（先に止めるノード） | 計画停止でも VIP・SCAN は残るノードへフェイルオーバする |
crsctl stop crs（最後のノード） | フェイルオーバ先がなく、CRS-2672 が出ない。接続経路はここで完全に閉じる |
| ノードVIP と SCAN VIP | ノードVIP は INTERMEDIATE／FAILED OVER で区別され、復帰後は元のノードに戻る。SCAN は定位置なし |
| クラスタ再起動後 | Target=ONLINE のリソースだけが自動起動。srvctl で止めた DB は srvctl で起動する |
| 最終確認 | srvctl の「実行中」と gv$instance の OPEN は確認の層が異なる。OPEN まで見る |
順序の原則は「止める順序は DB → GI → OS → ストレージ、起こす順序はその逆」の1行です。
そこに「操作前の確認 → 操作 → 操作後の確認」の3点セットを重ねると、各段階の状態変化が記録として残り、そのまま作業エビデンスになります。
Target／State の読み方は、障害解析でも計画停止でも同じです。
障害時のログの読み方は冒頭で挙げた記事「RACインスタンスがダウン ― どのログを解析するのか」で扱っているので、状態確認の型としてあわせて使ってください。
