Oracle Database 19c Release Update (RU) の適用

シングル インスタンスまたは Oracle Restart (Grid Infrastructure + ASM) の 19c データベースに四半期ごとの Release Update を適用します: OPatch の更新、競合と空き領域の事前チェック、ORACLE_HOME のバックアップと保証付きリストア ポイント、opatch apply (Oracle Restart では opatchauto)、任意で OJVM RU、datapatch、utlrp、検証。停止時間を短縮する out-of-place 方式 (新しいホームにインストールして切り替える) と、各方式のロールバック手順も含みます。RAC を選択した場合は、ノードごとのローリング適用のために RAC ガイドへ案内します。

構成: サーバー 1 台 (シングル インスタンスまたは Oracle Restart)。RAC はローリング パッチのガイド

開始前の確認

• パッチ ファイルが … の下にあること: …GI RU ……DB RU ………、OJVM RU ……、OPatch ……、新しいホーム用のベース インストール ファイル LINUX.X64_193000_db_home.zip…。パッチ番号を MOS で確認し、RU の README を最初から最後まで読んでください (OPatch の最小バージョン、既知の問題、追加の手順は README に書かれています)。
• MOS 555.1 で推奨されている one-off パッチのうち、新しい RU に対応したバージョンをダウンロード済みであること。現在のホームにある one-off が新しい RU と競合するかどうかを把握していること (競合する one-off には、その RU 上で作成された新しいバージョンが必要です)。
• 現在のパッチ レベルとデータベースの状態が記録されていること。すべてのコンポーネントが VALID。
• ORACLE_HOME があるファイル システムに 15 GB 以上 (OPatch は旧ファイルを .patch_storage に保存します)、… にホームのサイズ分…、新しいホーム用に 15 GB 以上…の空き領域があること。
• リストア ポイントのために、データベースが ARCHIVELOG モードで、FRA に十分な空き領域があること (パッチ適用中に生成されるフラッシュバック ログ用)。
• 過去 24 時間以内に取得した、成功し検証済みの RMAN バックアップがあること。
• メンテナンス ウィンドウが承認され、アプリケーション チームが停止を把握し、監視 (EM/エージェント) がブラックアウト中で、スケジュール ジョブ (cron、DBMS_SCHEDULER) が停止されていること。
• 可能であればサーバー (VM) のスナップショットを取得済みであること。
• データベースに Data Guard スタンバイがある場合は、パッチ適用の順序が計画されていること: 先にスタンバイのホームにパッチを適用し (Standby-First、MOS 1265700.1)、プライマリは後で適用して、datapatch はプライマリでのみ実行します。スタンバイがない場合、この項目は該当しません。
• クラスターが正常で、すべてのノードでインスタンスがオープンしていること。RAC のパッチ適用の詳しい前提条件は Oracle RAC 19c rolling Release Update ガイドにあります。
• Standby-First の条件 (MOS 1265700.1): RU の README に 「Data Guard Standby-First Installable」 と記載されていること (Release Update は該当します。one-off は README を個別に確認してください)…。19c の OJVM RU は無条件に Standby-First 適用可能ではありません (下の注記を参照)…。プライマリとスタンバイのパッチ レベルの差は切り替え期間中 (短時間) だけに留めること。datapatch は、すべてのスタンバイ と プライマリへのパッチ適用が終わった後、プライマリでのみ 1 回実行すること。… このプライマリのすべてのスタンバイに新しい RU のバイナリがインストールされ、スタンバイが REDO 適用を継続していること。…

ガイドのフェーズ

• RAC: 環境を確認し、ローリング パッチのガイドに進む — クラスターとノードを確認する · RAC ローリング パッチのガイドを実施する
• 事前チェック — 現在のパッチ レベルを確認する (DB ホーム) · 現在のパッチ レベルを確認する (Grid ホーム) · データベースの状態と SQL パッチ履歴を確認する · スタンバイのロールと REDO 適用の状態を確認する (Data Guard スタンバイ) · Data Guard の状態を確認する (プライマリ) · スタンバイに新しい RU がインストールされていることを確認する …
• バックアップと切り戻しポイント — RMAN バックアップを確認する · REDO 適用を停止する (Data Guard スタンバイ) · 保証付きリストア ポイントを作成する · 保証付きリストア ポイントを作成する (スタンバイ)
• 適用: in-place (opatch apply) — データベースとリスナーを停止する · ORACLE_HOME とインベントリをバックアップする · RU を適用する (opatch apply) · OJVM RU を適用する · リスナーとデータベースを起動する · リスナーとスタンバイ (MOUNT) を起動し、REDO 適用を開始する
• 適用: in-place (Oracle Restart、opatchauto) — Oracle Restart を停止する (バックアップのため) · Grid ホーム、DB ホーム、インベントリをバックアップする · Oracle Restart を起動する · GI RU を適用する (opatchauto) · OJVM RU を DB ホームに適用する · REDO 適用を開始する (Data Guard スタンバイ)
• 適用: out-of-place (新しいホーム) — 新しいホームのディレクトリを作成する · ベース ソフトウェアを展開し、OPatch を更新する · 新しいホーム用のレスポンス ファイルを準備する · 新しいホームを RU 付きでインストールする · root.sh を実行する (新しいホーム) · 旧ホームと新しいホームのパッチを比較する …
• SQL レベルのパッチ (datapatch) — datapatch を実行する · 無効なオブジェクトを再コンパイルする (utlrp) · スタンバイで datapatch を実行しない · SQL の変更がスタンバイに伝わっていることを確認する
• 検証 — バイナリのパッチ レベルを確認する · バイナリのパッチ レベルを確認する (Grid ホーム) · SQL パッチの登録状況とオブジェクトを確認する · スタンバイで新しいバイナリによる REDO 適用が継続していることを確認する · アラート ログを確認する · アプリケーションのテストを実施する …
• 完了処理 — リストア ポイントを削除する · リストア ポイントを削除する (スタンバイ) · 後片付けを行う
• ロールバック (必要な場合のみ) — データベースとリスナーを停止する · パッチをロールバックする (opatch rollback) · パッチをロールバックする (opatchauto rollback) · 旧ホームに戻す · スタンバイを旧バイナリで MOUNT し、REDO 適用を開始する · 起動して SQL パッチをロールバックする (datapatch) …