Oracle RAC環境へRelease Update（RU）を適用する場合、シングル・インスタンス環境とはパッチ適用方法が異なります。
Oracle RACでは、Oracle Grid InfrastructureとOracle Databaseの両方が存在するため、一般的にはOPatchAuto（opatchauto）を使用してパッチを適用します。
OPatchAutoを使用すると、Oracle ClusterwareやOracle RACインスタンスの停止・起動、GridホームやDatabaseホームへのパッチ適用など、RAC環境に必要な処理を自動的に実行できます。Oracle公式でも、Grid InfrastructureおよびRAC環境のパッチ適用にOPatchAutoが使用されています。
本記事では、Oracle Database 19cの2ノードRAC環境へRUをローリング適用する基本的な流れを解説します。
本記事の対象環境
本記事では、次のような一般的なOracle RAC環境を想定します。
Oracle Database ：19c
Oracle Grid Infrastructure：19c
構成 ：2ノードRAC
OS ：Oracle LinuxなどのLinux
Gridホーム ：各ノードのローカル領域
Databaseホーム ：各ノードのローカル領域
データベース ：CDB＋PDB
ストレージ ：ASM
パッチ ：Grid Infrastructure Release Update
適用方式 ：インプレース
ノード構成は次のとおりです。
Oracle RAC
┌───────────────┐
│ ASM共有Disk │
└───────┬───────┘
│
┌───────┴───────┐
│ │
┌─────────────┐ ┌─────────────┐
│ NODE1 │ │ NODE2 │
│ │ │ │
│ Grid Home │ │ Grid Home │
│ DB Home │ │ DB Home │
│ ORCL1 │ │ ORCL2 │
└─────────────┘ └─────────────┘
共有Oracleホーム、ACFSを使用した構成、Exadata、RAC One Nodeなどでは手順が異なる場合があります。
Oracle公式でも、GridホームやRACホームが共有されている場合、ACFSを使用している場合など、構成によってパッチ適用方法が異なることが説明されています。実際の作業では、対象RUのREADMEおよびOracle Supportの「Supplemental Readme – Grid Infrastructure Release Update」を必ず確認してください。
RACではOPatchAutoを使用する
シングル・インスタンス環境では、次のようにOPatchを使用しました。
シングル環境
opatch apply
↓
Databaseホームへパッチ適用
↓
datapatch
一方、RAC環境では一般的にOPatchAutoを使用します。
RAC環境
opatchauto apply
│
├─ Clusterwareを制御
├─ RACインスタンスを制御
├─ Gridホームへパッチ適用
├─ Databaseホームへパッチ適用
└─ 必要なSQLパッチ処理
OPatchAutoはRAC/GI構成情報を取得し、その環境に必要なパッチ手順を自動的に組み立てて実行します。
そのため通常のGI RU適用で、
opatch apply
をGridホームに対して直接実行するのではなく、対象RUのREADMEに従って、
opatchauto apply
を使用します。
RACのローリングパッチとは
Oracle RACの大きな特徴が、ローリング方式でパッチを適用できることです。
2ノードRACの場合、基本的には次のように1ノードずつ適用します。
【通常状態】
NODE1 NODE2
ORCL1：OPEN ORCL2：OPEN
│ │
└──── RAC Database ─────┘
↓
【NODE1へパッチ適用】
NODE1 NODE2
ORCL1：停止 ORCL2：OPEN
パッチ適用中 業務継続
↑
接続を処理
↓
【NODE1完了】
NODE1 NODE2
ORCL1：OPEN ORCL2：OPEN
新RU 旧RU
↓
【NODE2へパッチ適用】
NODE1 NODE2
ORCL1：OPEN ORCL2：停止
新RU パッチ適用中
↑
業務継続
↓
【完了】
NODE1 NODE2
ORCL1：OPEN ORCL2：OPEN
新RU 新RU
Oracle Grid Infrastructureのパッチは、対応しているパッチであればローリング方式で1ノードずつ適用できます。Oracle公式手順でも、最初のノードへの適用が完了してから、次のノードへ順番に適用する方法が示されています。
複数ノードで同時にopatchautoを実行してはいけません。
OPatchAutoは各ノードで順番に実行します。
ローリングパッチ＝完全無停止ではない
ここは誤解しやすいポイントです。
ローリング適用ではクラスタ全体を同時停止しませんが、パッチ対象ノード上のRACインスタンスやClusterwareは停止する場合があります。
つまり、
ローリングパッチ
≠ 全プロセスが一度も停止しない
○ 1ノードずつ停止して
他ノードでサービスを継続する
という意味です。
アプリケーションから見て影響を小さくするには、RACサービス、接続時フェイルオーバー、FANなどが正しく構成されている必要があります。
なお、Oracle Database 19c RU 19.16以降では、Grid Infrastructureのパッチ適用中もRAC Databaseインスタンスを稼働させるZero-Downtime Oracle Grid Infrastructure Patchingという機能も提供されています。これは通常のローリングパッチとは別の仕組みです。
本記事では、一般的なOPatchAutoによるローリング適用を扱います。
RACへのRU適用の全体的な流れ
2ノードRACでは、次のように進めます。
GI RUを入手
↓
README確認
↓
各ホームのOPatch確認・更新
↓
現在のパッチ状態を確認
↓
opatchauto apply -analyze
↓
NODE1
opatchauto apply
↓
NODE1正常性確認
↓
NODE2
opatchauto apply
↓
NODE2正常性確認
↓
全ノードのパッチレベル確認
↓
DBA_REGISTRY_SQLPATCH確認
↓
完了
1．Grid Infrastructure RUを入手する
RAC環境では、My Oracle Supportから対象バージョンのGrid Infrastructure Release Update（GI RU）を入手します。
Oracle Database 19cのRAC環境では、Oracleのプロアクティブ・パッチ方式としてGI Updateが提供されています。
本記事ではパッチ番号を固定せず、
<GI_RU_PATCH_ID>
と記載します。
例：
/u01/stage/patch/<GI_RU_PATCH_ID>
実際には、適用するRUのREADMEに記載されたパッチ番号とディレクトリを使用してください。
2．RUを展開する
パッチ配置用ディレクトリを作成します。
mkdir -p /u01/stage/patch
cd /u01/stage/patch
ダウンロードしたGI RUを展開します。
unzip p<GI_RU_PATCH_ID>_190000_Linux-x86-64.zip
展開されたディレクトリを確認します。
ls -l
例：
/u01/stage/patch/
└── <GI_RU_PATCH_ID>
├── README.html
├── <Database RU>
├── <OCW RU>
├── <ACFS RU>
└── ...
GI RUは複数のサブパッチを含むシステムパッチとして提供されるため、単純なDatabase RUとはディレクトリ構造が異なります。
実際にどのサブパッチがGridホーム・Databaseホームへ適用されるかは、対象RUのREADMEを確認します。
3．OPatchのバージョンを確認する
RACではGridホームとDatabaseホームの両方にOPatchがあります。
例：
Grid Home
/u01/app/19.0.0/grid/OPatch
Database Home
/u01/app/oracle/product/19.0.0/dbhome_1/OPatch
Gridユーザーで確認します。
$GRID_HOME/OPatch/opatch version
Oracleユーザーで確認します。
$ORACLE_HOME/OPatch/opatch version
さらに、すべてのノードで確認します。
NODE1
├─ GRID_HOMEのOPatch
└─ DB_HOMEのOPatch
NODE2
├─ GRID_HOMEのOPatch
└─ DB_HOMEのOPatch
OPatchAutoを使用したマルチノードパッチでは、対象ノードのOracleホームで同じOPatchバージョンを使用してからパッチ適用を開始する必要があります。
必要な最低OPatchバージョンは、対象RUのREADMEを確認してください。
4．現在のクラスタ状態を確認する
パッチ適用前にClusterwareの状態を確認します。
Gridユーザーで実行します。
crsctl check cluster -all
リソース状態を確認します。
crsctl stat res -t
RAC Databaseの状態も確認します。
srvctl status database -d ORCL
例：
Instance ORCL1 is running on node NODE1
Instance ORCL2 is running on node NODE2
PDBを使用している場合は、Database側から状態を確認します。
SELECT inst_id,
name,
open_mode
FROM gv$pdbs
ORDER BY inst_id, con_id;
パッチ開始前にクラスタが正常な状態であることを確認します。
5．現在のパッチ状態を確認する
Gridホームのパッチ状態を確認します。
NODE1：
$GRID_HOME/OPatch/opatch lsinventory
NODE2：
$GRID_HOME/OPatch/opatch lsinventory
Databaseホームについても確認します。
$ORACLE_HOME/OPatch/opatch lsinventory
簡易的に確認する場合は、
$GRID_HOME/OPatch/opatch lspatches
$ORACLE_HOME/OPatch/opatch lspatches
を使用できます。
Oracle公式のOPatchAuto手順でも、パッチ開始前に全ノードが同じパッチレベルであることを確認するよう説明されています。
6．OPatchAutoのanalyzeを実行する
実際にパッチを適用する前に、-analyzeオプションを使用して事前チェックを実行します。
rootユーザーで実行します。
$GRID_HOME/OPatch/opatchauto apply \
/u01/stage/patch/<GI_RU_PATCH_ID> \
-analyze
-analyzeでは実際のファイル変更は行われません。
OPatchAutoが、
・対象Oracleホーム
・パッチ適用可否
・既存パッチとの競合
・必要な前提条件
・パッチ適用時に実行する処理
などを確認します。
Oracle公式でも、実際のパッチ適用前に、
opatchauto apply -analyze
で前提条件を確認する方法が案内されています。
正常な場合は、解析が成功したことを示す結果が表示されます。
問題が検出された場合は、実際のapplyへ進まず、OPatchAutoログを確認します。
特に多いのが既存の個別パッチとの競合です。
7．NODE1へRUを適用する
事前チェックが正常終了したら、最初のノードからRUを適用します。
NODE1へrootユーザーでログインします。
su - root
GridホームのOPatchAutoを使用します。
$GRID_HOME/OPatch/opatchauto apply \
/u01/stage/patch/<GI_RU_PATCH_ID>
例えばGridホームが、
/u01/app/19.0.0/grid
の場合は次のようになります。
/u01/app/19.0.0/grid/OPatch/opatchauto apply \
/u01/stage/patch/<GI_RU_PATCH_ID>
Oracle公式のGrid Infrastructure 19cのパッチ適用手順でも、rootユーザーから次の形式で実行する方法が示されています。
Grid_home/OPatch/opatchauto apply <patch_directory>/<patch_ID>
OPatchAutoでは何が行われる？
具体的な処理はパッチや構成によって変わりますが、OPatchAutoはRAC/GIの構成情報を使用して必要な処理を自動的に実行します。
イメージとしては次のようになります。
NODE1
opatchauto apply
│
├─構成情報取得
│
├─対象リソース停止
│
├─NODE1のRACインスタンス停止
│
├─Clusterware関連処理
│
├─Grid Homeへパッチ
│
├─Database Homeへパッチ
│
├─Clusterware起動
│
├─RACインスタンス起動
│
└─SQLパッチ処理
これらを手動で1つずつ実行するのではなく、OPatchAutoが環境に応じてオーケストレーションします。
8．NODE1の正常性を確認する
NODE1へのパッチ適用が完了したら、すぐNODE2へ進まず、NODE1が正常にクラスタへ復帰したことを確認します。
crsctl check crs
リソース状態を確認します。
crsctl stat res -t
Database状態を確認します。
srvctl status database -d ORCL
例：
Instance ORCL1 is running on node NODE1
Instance ORCL2 is running on node NODE2
Gridホームのパッチ状態も確認します。
$GRID_HOME/OPatch/opatch lspatches
Databaseホームも確認します。
$ORACLE_HOME/OPatch/opatch lspatches
NODE1への適用が正常に完了し、RACインスタンスがクラスタへ戻ってからNODE2へ進みます。
9．NODE2へRUを適用する
次にNODE2へrootユーザーでログインします。
NODE1と同じコマンドを実行します。
$GRID_HOME/OPatch/opatchauto apply \
/u01/stage/patch/<GI_RU_PATCH_ID>
処理中は、
NODE1
ORCL1：稼働
NODE2
ORCL2：停止・パッチ適用
という状態になります。
NODE2への適用が正常終了したら、
crsctl check crs
crsctl stat res -t
srvctl status database -d ORCL
を実行します。
Oracle公式手順でも、最初のノードへの適用が完了してから、次のノードへ1台ずつ適用する方法が示されています。
3ノード以上のRACの場合も、
NODE1
↓
NODE2
↓
NODE3
↓
NODE4
のように順番に適用します。
10．全ノードのGrid Infrastructureパッチレベルを確認する
全ノードへのパッチ適用が完了したら、Clusterwareのパッチレベルを確認します。
crsctl query crs softwarepatch NODE1
crsctl query crs softwarepatch NODE2
crsctl query crs softwarepatchは、指定したノードにインストールされているOracle Clusterwareのパッチレベルを確認するコマンドです。
両ノードのパッチレベルがそろっていることを確認します。
NODE1 ：Patch Level XXXXXXXX
NODE2 ：Patch Level XXXXXXXX
必要に応じて、
crsctl query crs releasepatch
も確認します。
クラスタ内でパッチレベルが不整合な状態になると、Oracle Clusterwareが正常に起動できない場合があります。Oracle公式のCRSエラー情報でも、releasepatchとsoftwarepatchでパッチレベルを確認する方法が案内されています。
11．GridホームへのRU適用を確認する
各ノードで確認します。
$GRID_HOME/OPatch/opatch lspatches
詳細を確認する場合は、
$GRID_HOME/OPatch/opatch lsinventory
を実行します。
NODE1とNODE2で同じRUが適用されていることを確認します。
NODE1 Grid Home
└─ GI RU適用済み
NODE2 Grid Home
└─ GI RU適用済み
12．DatabaseホームへのRU適用を確認する
Databaseホームについても各ノードで確認します。
$ORACLE_HOME/OPatch/opatch lspatches
または、
$ORACLE_HOME/OPatch/opatch lsinventory
を実行します。
NODE1 Database Home
└─ Database RU適用済み
NODE2 Database Home
└─ Database RU適用済み
となっていることを確認します。
Oracle公式のRACパッチ手順でも、OPatchAuto適用後にはOracleホームのインベントリを確認し、パッチが正常に適用されていることを確認する流れになっています。
13．datapatchの結果を確認する
シングル環境では、
opatch apply
↓
datapatch -verbose
と手動で実行しました。
OPatchAutoの場合は少し異なります。
OPatchAutoは必要に応じてdatapatchを呼び出し、SQL変更の適用処理も実行します。
Oracle公式のOPatchAutoトラブルシューティング資料でも、OPatchAutoは、
・GI/RACホームへのバイナリ適用
・datapatchを使用したSQL適用
の両方を実行すると説明されています。
そのため、正常にOPatchAutoが完了している場合、通常はシングル環境のように機械的にもう一度datapatch -verboseを実行する必要はありません。
ただし、SQLパッチが正常に適用されたかは必ず確認します。
sqlplus / as sysdba
SET LINESIZE 250
SET PAGESIZE 100
COLUMN action_time FORMAT A30
COLUMN status FORMAT A15
COLUMN description FORMAT A90
SELECT patch_id,
patch_type,
action,
status,
action_time,
description
FROM dba_registry_sqlpatch
ORDER BY action_time;
今回のDatabase RUについて、
PATCH_TYPE ：RU
ACTION ：APPLY
STATUS ：SUCCESS
になっていることを確認します。
RACでは最初のノードでdatapatchが実質何もしない場合がある
OPatchAutoによるローリング適用では、少し特殊な動作があります。
Oracle公式資料では、複数ノードへOPatchAutoを順番に実行した場合、各実行時にdatapatchが呼び出されますが、最初から最後の1つ前までのノードでは処理がno-opとなり、最後のノードでSQLパッチ適用を試みる場合があると説明されています。
イメージすると次のようになります。
NODE1 opatchauto
│
├─バイナリ適用
└─datapatch
└─まだNODE2が旧RU
→ SQL適用を保留する場合あり
NODE2 opatchauto
│
├─バイナリ適用
└─datapatch
│
├─全RAC Homeが新RU
└─SQL変更を適用
このため、NODE1のOPatchAutoログにdatapatch関連のメッセージが表示されたからといって、すぐに異常とは限りません。
最終的には、全ノードへのバイナリ適用後に、
DBA_REGISTRY_SQLPATCH
を確認することが重要です。
datapatchが正常に実行されなかった場合
最終ノードでもdatapatchが失敗した場合は、原因を確認します。
まずすべてのRAC Databaseホームへのバイナリ適用が完了していることを確認します。
$ORACLE_HOME/OPatch/opatch lspatches
PDBの状態を確認します。
SELECT name,
open_mode
FROM v$pdbs
ORDER BY con_id;
必要なPDBをオープンします。
ALTER PLUGGABLE DATABASE ALL OPEN;
その後、READMEやOPatchAutoログの指示に従い、1ノードからdatapatchを手動実行します。
cd $ORACLE_HOME/OPatch
./datapatch -verbose
Oracle公式でも、最終ノードでdatapatchが失敗した場合には、手動でdatapatchを再実行する方法が示されています。
実行後に再度、
SELECT patch_id,
action,
status,
description
FROM dba_registry_sqlpatch
ORDER BY action_time;
を確認します。
14．RAC Database全体の状態を確認する
すべてのインスタンスが起動していることを確認します。
srvctl status database -d ORCL
例：
Instance ORCL1 is running on node NODE1
Instance ORCL2 is running on node NODE2
サービス状態も確認します。
srvctl status service -d ORCL
Clusterwareリソースを確認します。
crsctl stat res -t
PDBについても確認します。
SELECT inst_id,
name,
open_mode
FROM gv$pdbs
ORDER BY inst_id, con_id;
OPatchAutoで特定のOracleホームだけを適用する場合
通常のGI RU適用では、OPatchAutoがGI/RAC構成を認識して対象ホームへ適切なサブパッチを適用します。
一方、特定のOracleホームだけを対象としたい場合は、-ohオプションを使用できます。
Gridホームのみの場合：
$GRID_HOME/OPatch/opatchauto apply \
/u01/stage/patch/<GI_RU_PATCH_ID> \
-oh $GRID_HOME
Databaseホームを指定する場合：
$GRID_HOME/OPatch/opatchauto apply \
/u01/stage/patch/<GI_RU_PATCH_ID> \
-oh $ORACLE_HOME
Oracle公式でも、
GI Home + RAC DB Home
opatchauto apply PATCH
GI Homeのみ
opatchauto apply PATCH -oh GI_HOME
RAC DB Home
opatchauto apply PATCH -oh DB_HOME
という使い分けが説明されています。
ただし、GI RUの通常適用で安易に-ohを付けるのではなく、対象RUのREADMEで指定されている方法を使用してください。
OPatchとOPatchAutoの違い
シングル環境の記事と比較すると、違いが分かりやすくなります。
┌─────────────────────────────┐
│ OPatch │
├─────────────────────────────┤
│ 主に単一Oracle Homeへのパッチ │
│ │
│ opatch apply │
│ ↓ │
│ バイナリ適用 │
│ ↓ │
│ datapatchを手動実行 │
└─────────────────────────────┘
┌─────────────────────────────┐
│ OPatchAuto │
├─────────────────────────────┤
│ GI / RAC構成を認識 │
│ │
│ opatchauto apply │
│ ↓ │
│ Clusterware制御 │
│ ↓ │
│ RACインスタンス制御 │
│ ↓ │
│ GI・DB Homeへパッチ │
│ ↓ │
│ datapatchを含む後処理 │
└─────────────────────────────┘
RACでは、単純に「各ノードでOPatchを実行する」という考え方ではなく、クラスタ構成を考慮できるOPatchAutoを使用するのがポイントです。
RAC RUをロールバックする場合
問題が発生しRUをロールバックする場合は、opatchauto rollbackを使用します。
まず対象RUのREADMEに記載されたロールバック手順を確認してください。
事前に解析する場合は、
$GRID_HOME/OPatch/opatchauto rollback \
/u01/stage/patch/<GI_RU_PATCH_ID> \
-analyze
を実行します。
実際のロールバックは、
$GRID_HOME/OPatch/opatchauto rollback \
/u01/stage/patch/<GI_RU_PATCH_ID>
で実行します。
ローリング適用可能な場合は、適用時と同様に1ノードずつ実施します。
NODE1 rollback
↓
NODE1正常性確認
↓
NODE2 rollback
↓
NODE2正常性確認
OPatchAutoにはrollback機能があり、適用したパッチをGI/RAC環境からロールバックできます。
ロールバック後も、
$GRID_HOME/OPatch/opatch lsinventory
$ORACLE_HOME/OPatch/opatch lsinventory
crsctl query crs softwarepatch NODE1
crsctl query crs softwarepatch NODE2
を確認します。
SQL変更を含むDatabase RUでは、
SELECT patch_id,
action,
status,
description
FROM dba_registry_sqlpatch
ORDER BY action_time;
も確認します。
対象RUについて、
ACTION ：ROLLBACK
STATUS ：SUCCESS
になっていることを確認します。
RACパッチ適用で注意したいポイント
RACへのRU適用では、特に次の点が重要です。
OPatchAutoはrootで実行する
Grid InfrastructureおよびRAC環境への通常のOPatchAuto適用はroot権限で実行します。
$GRID_HOME/OPatch/opatchauto apply <PATCH>
ノードを並列でパッチしない
ローリング適用では、
NODE1完了
↓
NODE2
↓
NODE3
と1ノードずつ実行します。
複数ノードで同時にOPatchAutoを実行しないよう注意してください。
GridホームとDatabaseホームの両方を確認する
RACには複数のOracleホームがあります。
Grid Home
Database Home
そのため、パッチ完了後は両方のインベントリを確認します。
$GRID_HOME/OPatch/opatch lspatches
$ORACLE_HOME/OPatch/opatch lspatches
全ノードのパッチレベルをそろえる
ローリング適用途中は一時的に新旧RUが混在しますが、作業終了時にはすべてのノードを同じパッチレベルへそろえます。
正常
NODE1：19.xx
NODE2：19.xx
NG
NODE1：19.xx
NODE2：19.yy
Oracle Clusterwareではパッチレベルの不整合が原因で起動できなくなる場合があるため、最終確認は重要です。
まとめ
Oracle Database 19c RAC環境へRUを適用する基本的な流れは次のとおりです。
GI RUを入手
↓
OPatch確認
↓
クラスタ状態確認
↓
opatchauto apply -analyze
↓
NODE1
opatchauto apply
↓
NODE1復帰確認
↓
NODE2
opatchauto apply
↓
NODE2復帰確認
↓
GI Home確認
↓
DB Home確認
↓
Clusterware Patch Level確認
↓
DBA_REGISTRY_SQLPATCH確認
シングル・インスタンス環境との最大の違いは、OPatchではなくOPatchAutoを中心にパッチを適用することです。
シングル環境
↓
opatch apply
↓
datapatch
RAC環境
↓
opatchauto apply
↓
GI・RAC構成を認識して
パッチ処理を自動化
また、RACではローリング適用を利用することで、
NODE1停止中 → NODE2でサービス継続
NODE2停止中 → NODE1でサービス継続
という形で、クラスタ全体の停止を避けながらRUを適用できます。
ただし、すべてのパッチがローリング適用可能とは限りません。また、共有ホーム、ACFS、個別パッチとの競合などによって手順が変わる場合があります。
そのため、実際のパッチ適用時には必ず対象GI RUに付属するREADMEを最優先し、その環境に対応した手順で作業してください。
[参考]
Oracle Database Oracle Databaseパッチ・メンテナンス, リリース19c以降のリリース
コメント