Oracle RAC 19c ローリング Release Update (opatchauto)
Oracleレベル: 上級所要時間: ノードあたり 45~90 分稼働中の 2~8 ノード構成 RAC 19c クラスタに、四半期ごとの GI Release Update を停止なし (rolling) で適用します。OPatch の更新、opatchauto analyze による競合チェック、OCR バックアップとフォールバック・ポイント、サービスを再配置しながらのノード単位の適用、datapatch の単一ノードでの完了、検証、必要に応じたロールバックまでを扱います。シングル・インスタンスおよび Oracle Restart には「Oracle Database 19c Release Update (RU) の適用」ガイドを使用してください。OJVM RU はローリング適用できず、別途停止時間が必要です。
構成: 既存の 2~8 ノード構成 RAC 19c
開始前の確認
- RU の README を確認済み: 必要な OPatch の最小バージョン、既知の問題、前提となる one-off パッチ、別パッチの OJVM (OJVM RU はローリング適用できず、別途停止時間が必要)。My Oracle Support の "Oracle Database 19c Important Recommended One-off Patches" (Doc ID 555.1) と RU ダウンロード・ガイド (Doc ID 2118136.2) をこの RU について確認済み。
- 全ノードの … に … と p6880880_190000_Linux-x86-64.zip (最新の OPatch) があり、MOS に掲載された SHA-256 値でファイルを検証済み。
- GI ホームと DB ホームがあるファイル・システムに 20 GB 以上 (README の値を確認)、/tmp に 1 GB 以上の空き容量がある。…… にホームのバックアップ用の容量がある。…
- クラスタが正常: 全ノードで CRS がオンライン、OFFLINE のままのリソースがなく、全インスタンスがオープンしている。パッチ適用中に 1 ノードが停止しても、残りのノードで全負荷を処理できる。
- アプリケーション・サービスが各ノードで別のインスタンスへ移行できるように定義されており (preferred/available または uniform)、アプリケーションは SCAN + サービス名で接続している (FAN/AC があればセッションは中断なく移行します)。
- データベースの最新の RMAN バックアップとアーカイブ・ログがあり、OCR バックアップも取得済み。メンテナンス・ウィンドウが承認され、Enterprise Manager でブラックアウトを設定済み。
- ほかの opatch/opatchauto 処理が実行されておらず、ホームにロック・ファイルがない。
- データベースに Data Guard スタンバイがある場合は、スタンバイのクラスタ (またはサーバー) に先にパッチを適用し (Standby-First、MOS 1265700.1)、その後このガイドでプライマリに適用します。datapatch はプライマリでのみ実行します。
ガイドのフェーズ
- 事前チェック — 現在のパッチ・レベルを記録する (Clusterware) · ホームのパッチを一覧表示する (…) · SQL パッチ履歴と無効なオブジェクトを記録する
- 準備: RU、OPatch、分析 — RU を展開する (…) · GI ホームの OPatch を更新する (…) · DB ホームの OPatch を更新する (…) · 競合と前提条件の分析を実行する (…)
- バックアップとフォールバック・ポイント — OCR の手動バックアップを取得する · 保証付きリストア・ポイントを作成する · GI ホームと DB ホームをバックアップする (…)
- 検証と完了 — PDB がオープンしていることを確認する · datapatch を 1 ノードのみで実行する · SQL パッチ・レジストリを検証する · 無効なオブジェクトを再コンパイルする (必要な場合) · クラスタのパッチ状態を検証する · サービスを優先配置に戻す …
- ロールバック (必要な場合のみ) — ロールバック: opatchauto rollback を実行する (…) · ロールバック: datapatch を実行する (1 ノード) · ロールバック: 結果を検証する · 最終手段: データベースをリストア・ポイントまでフラッシュバックする