📌 はじめに

クラウドネイティブな Kubernetes / OpenShift 環境において、ステートレスな Web アプリケーションのバージョンアップは「コンテナイメージのタグを差し替えるだけ」で安全に完了します。しかし、Oracle データベース（CDB/PDB）を Pod 上で運用している場合、イメージを更新しただけではパッチ適用は半分しか完了していません。

特にエンタープライズ現場で広く使われている長期サポート版（LTS）の Oracle 19c において、初期リリースである 19.3 から長期保守パッチが適用された 19.28 へアップグレードする際、「ソフトウェアバイナリの更新」 と 「PVC 内に保持されたデータディクショナリ（データ辞書）の更新」 を正しく分離して理解していないと、起動後の致命的な内部エラー（ORA-00600）やセキュリティ監査違反を招く原因になります。

本記事では、Oracle のバージョン体系（RU）、OPatch と Datapatch の本質的な責務分担、そしてコンテナ（Pod）環境特有のアップグレード落とし穴について図解を交えて整理します。

1. Oracle 19c と RU（Release Update）の基本体系

Oracle 19c（長期サポート版: LTS）の位置づけ

内部バージョン: 12.2.0.3。12c / 18c ファミリーの最終安定版。
LTS（Long-Term Support）: 短期サポートの Innovation Release（18c, 21c, 23c等）とは異なり、極めて長期間の公式標準サポートおよび延長サポートが提供されます。金融、製造、交通などの基幹系エンタープライズ基盤では、19c をベースラインとして長期運用する設計が一般的です。

RU（Release Update）とは？

Oracle 18c 以降、従来の PSU（Patch Set Update）や CPU（Critical Patch Update）に代わり導入された四半期ごとの累積パッチ提供方式です。

累積性（Cumulative）:
- 毎年 1月・4月・7月・10月にリリースされます。
- 全量累積型であるため、過去のパッチを順番に1つずつ当てる必要はありません。19.3 から最新の 19.28 へダイレクトにスキップ適用（ジャンプアップグレード） 可能です。
RU の内包物:
- セキュリティ修正（CVE）: 既知の重大なセキュリティ脆弱性を塞ぐパッチ。
- コア Bug 修正: カーネルクラッシュ、メモリリーク、ORA 内部エラーの解消。
- オプティマイザの調整: SQL 実行計画の不具合修正。

2. 19.3 と 19.28 の実務的差異

「ベースイメージが 19.3 のまま放置されているシステム」と「19.28 まで更新されたシステム」では、セキュリティ監査および可用性の観点で大きな差が存在します。

比較項目	Oracle 19.3 (19.3.0)	Oracle 19.28 (19.28.0)
リリース時期	2019年4月（19c の初回初期リリース）	2025年年中（通算25回目となる四半期RU累積）
コンテナ/イメージの現状	各種サンプルや初期検証で最も多く使われる素の状態	企業のセキュリティコンプライアンスを満たす本番標準
既知の脆弱性 (CVE)	過去数年間に発見された数百件の重大脆弱性が未修正	Log4j、ネットワークインジェクション、特権昇格等を網羅的に改修済
カーネル安定性	初期 PDB 制御、高負荷並行処理時のメモリリーク等の懸念あり	数万件の Bug 修正が適用され、内部ロックや予期せぬダウンが激減
セキュリティ監査	現代のセキュリティスキャンで「Critical（緊急）」判定	金融・エンタープライズの厳格なセキュリティベースラインに適合

3. パッチ適用の2大コアコンポーネント：OPatch vs Datapatch

Oracle のパッチ適用は、「外部ソフトウェア（バイナリ）の更新」 と 「内部データ辞書（SQL）の更新」 という前・後半の2つのフェーズに明確に分かれています。

               ┌────────────────────────────────────────────────────────┐
               │           RU (Release Update 四半期累積パッチ)          │
               │  内包物：① コンパイル済みバイナリ  ② SQL/PL/SQL 更新スクリプト│
               └──────────────────────────┬─────────────────────────────┘
                                          │
            ┌─────────────────────────────┴─────────────────────────────┐
            ▼                                                           ▼
【前半戦：外部ソフトウェアバイナリ更新】                     【後半戦：内部データディクショナリ更新】
         OPatch                                                      Datapatch
- 操作対象：$ORACLE_HOME ディレクトリ                        - 操作対象：データベース内部の辞書表 (CDB/PDB)
- 稼働状態：インスタンス停止 (Shutdown)                      - 稼働状態：インスタンス起動中 (Open)
- 処理内容：実行ファイル・動的共有ライブラリ (.so) の置換    - 処理内容：内部SQLを実行し、システムパッケージ/ビューを刷新

3つの要素の役割分担

① RU（Release Update：パッチ実体）

C/C++ でコンパイルされた OS 側の実行バイナリ（カーネル、ネットワークリスナー等）と、DB 内部で実行されるべき SQL / PL/SQL 定義スクリプトが 1 つにまとめられたパッケージです。

② OPatch（バイナリレイヤーの適用ツール）

実行場所: $ORACLE_HOME/OPatch/opatch（Java/Perl ベースの CLI）。
役割: opatch apply を実行し、$ORACLE_HOME 配下の実行モジュール（oracle や tnslsnr）および共有ライブラリを物理的に差し替えます。
特性: ファイルシステム上のバイナリを書き換えるだけであり、データベースに接続してテーブルスペースやデータファイル（.dbf）を直接操作することは一切ありません。

③ Datapatch（データベースレイヤーの反映ツール）

実行場所: $ORACLE_HOME/OPatch/datapatch。
役割: datapatch -verbose を実行します。
特性: DB インスタンス起動後、SQL 経由で CDB$ROOT、PDB$SEED、およびすべての業務 PDB に接続します。RU に含まれる SQL スクリプトを実行してシステムパッケージや内部ビューを最新化し、適用ステータスを dba_registry_sqlpatch などのメタデータ表へ記録します。

4. 従来の標準適用シーケンス（時系列）

物理マシンや仮想マシンでの標準的な適用フローは以下の 3 ステップです。

[ ステップ 1: インスタンス停止とバイナリ更新 ]
  DB インスタンスおよびリスナーを停止
       │
       ▼
  opatch apply 実行 ──► $ORACLE_HOME のバイナリが新バージョンへ置換

[ ステップ 2: インスタンス起動 ]
  sqlplus / as sysdba 経由で startup 実行
       │
       ▼
  alter pluggable database all open; で各 PDB をオープン

[ ステップ 3: データ辞書の反映 ]
  OS ターミナルから datapatch -verbose 実行 ──► 各 PDB の辞書表へ SQL を流し込む
       │
       ▼
  dba_registry_sqlpatch 뷰でステータスが "SUCCESS" であることを確認

5. Kubernetes / Pod（OpenShift）環境における落とし穴と設計ポイント

コンテナ環境で Oracle 19.3 から 19.28 へアップグレードする場合、この2段階の仕組みを前提としたアーキテクチャ設計が不可欠です。

落とし穴：イメージ差し替えだけでは「パッチ適用は未完了」

コンテナイメージの更新範囲:
CI/CD でビルドされた 19.28 のコンテナイメージは、Dockerfile 内で opatch apply が実行済みの状態であり、コンテナ内の $ORACLE_HOME（前半戦）のみが 19.28 に更新されています。
PVC（永続ボリューム）のデータは 19.3 のまま:
業務データ、SYSTEM 表領域、SYSAUX 表領域は永続ボリューム（PersistentVolumeClaim: PVC）に永続化されています。
新しいイメージで Pod を起動した直後、「Oracle 実行エンジンは 19.28 なのに、内部のデータ辞書は 19.3 のまま」というバージョンの食い違い（不整合） が発生します。
発生する障害:
バージョン不一致のまま運用を続けると、システムパッケージの呼び出し時に内部エラー（ORA-00600）が発生したり、ストアドプロシージャのコンパイルエラー、特定 SQL の実行時例外が頻発します。

コンテナ環境におけるベストプラクティス

マニフェスト更新: Helm の values.yaml でコンテナイメージのタグを 19.28 へ切り替えてデプロイ。
インスタンス自動起動: コンテナのエントリポイントスクリプトが DB インスタンスおよび PDB を OPEN 状態まで立ち上げる。
datapatch の実行（必須ステップ）:

Pod 起動スクリプトのライフサイクルフック（postStart）やエントリポイント内に datapatch -verbose の実行ロジックを組み込むか、初回起動後にコンテナ内へ kubectl exec 経由で接続して datapatch -verbose を手動実行する。

適用結果の検証:

各 PDB に接続し、SELECT patch_id, version, status FROM dba_registry_sqlpatch; を実行して SUCCESS を確認する。

6. まとめ

Oracle 19c は長期サポートの標準: 金融やエンタープライズの安定稼働基盤であり、四半期ごとの RU を適用してセキュリティと堅牢性を維持する。
2段階更新の徹底:
OPatch: OS レベルのバイナリ（$ORACLE_HOME）を書き換えるツール（停止時実行）。コンテナではイメージビルド時に完了。
Datapatch: DB 内部のデータディクショナリを更新するツール（起動時実行）。Pod 起動後に明示的な実行が必要。
Pod 更新時の鉄則: コンテナイメージのタグ更新（image.tag 変更）だけで安心せず、PVC 内部のデータ辞書に対する datapatch 適用までを完結させて初めてアップグレードが成功する。