RDS for Oracle の OS アップグレードを実施した際のイベントログと所要時間を確認してみた

こんにちは！クラウド事業本部のおつまみです。

今回、お客様から「RDS for Oracle に保留中のメンテナンス（OS アップグレード）が表示されているがどう対応すればよいか」というご相談をいただきました。調査・対応の結果、無事に作業が完了したので、OSアップグレード時のRDSイベントログや所要時間などを記録として本ブログに残しておきます。

3行まとめ

1. RDS for Oracle の OS アップグレードは DB エンジン（Oracle）のバージョンは変わらず、セキュリティ・パフォーマンス改善を目的とした基盤 OS のアップデートです。
2. アップデート中はインスタンスが一時的に停止します。マルチ AZ 構成でもフェイルオーバーが発生するためダウンタイムは発生します。
3. 今回の環境（db.r5.large、マルチ AZ あり / なし 混在、6 台）では、1 台あたり約 25〜30 分で完了しました。

OS アップグレード通知とは

RDS コンソールの「メンテナンスとバックアップ」タブに「保留中のメンテナンス」として New Operating System update is available が表示されることがあります。

AWS のドキュメントには以下のように記載されています。

Amazon RDS は、データベースパフォーマンスと顧客の全体的なセキュリティ体制改善のために、OS を新しいバージョンにアップグレードします。通常、アップデートには約 10 分かかります。アップデートは DB インスタンスの機能には影響しません。

参考：DB インスタンスのメンテナンス - Amazon Relational Database Service

主な特徴

自動適用について

「必須アップデート」として指定されている場合、適用期限（Auto-Apply Date）が設定されます。期限を過ぎると、メンテナンスウィンドウ中に AWS によって自動的に適用されます。

今回の対象環境では、2026年5月15日以降にメンテナンスウィンドウ中に自動適用されるスケジュールが組まれていました。

OS アップグレードは DB エンジンのバージョン変更を伴わず、動作への影響もないため、メンテナンスウィンドウを業務影響の少ない時間帯に設定しておき、自動適用に任せるのがシンプルで楽な方法です。今回はお客様のご要望により手動で実施しましたが、メンテナンスウィンドウが適切に設定済みであれば、特に対応なく自動適用されるのを待つのも十分な選択肢です。

対象環境

作業の流れ

今回は以下のタイムテーブルで実施しました。

事前スナップショット取得

OS アップグレードは通常問題なく完了しますが、万が一アップグレード後に予期しない問題が発生した場合に備えて、アップグレード前に手動スナップショットを取得しました。RDS の自動バックアップとは別に手動で取得することで、問題発生時にアップグレード前の状態へ確実に戻せるようにしておくためです。
インスタンスのサイズにもよりますが、今回はスナップショット完了まで約 19 分かかりました。

OS アップグレードの適用

複数台を同時に実施すると接続確認が難しくなるため、システムごとに少しずつ時間をずらして 順番に適用しました。

適用は左ペインのレコメンデーションタブを押下し、該当のインスタンスを選択後、[適用]で実行できます。

また適用中は、RDS コンソールの「最近のイベント」でリアルタイムに状況を確認できます。

RDS イベントログの内容

今回記録したイベントログをご紹介します。マルチ AZ ありの場合とマルチ AZ なしの場合でイベントの流れが異なります。

マルチ AZ ありの場合（db.r5.large）

2:00に適用開始し、2:28 にバックアップ完了（2:01 にプリチェック開始）しているため、約 25〜30 分かかっています。

イベントの流れ（マルチ AZ ありの場合）

大きく以下の流れで進みます。

1. プリチェック（約 1 分）
2. バックアップ → インスタンスシャットダウン → フェイルオーバー開始
3. エンジンバージョンアップグレード（OSパッチ適用）
4. フェイルオーバー完了 → DBインスタンス再起動
5. OS パッチ適用（スタンバイ側）
6. DB インスタンス再起動
7. DBパラメータグループ更新
8. バックアップ完了

マルチ AZ 構成の場合、プライマリのダウンタイム中はスタンバイへフェイルオーバーして処理を継続しようとしますが、OS アップグレードの性質上、プライマリ・スタンバイ両方を順次更新するためダウンタイムは発生します。

マルチ AZ なしの場合

マルチ AZ なしの場合は、フェイルオーバーが発生しない分、イベントの流れがよりシンプルになります。

気になったイベントメッセージ

イベントログに以下のメッセージが出力されていました。

Your database contains invalid objects. Check the invalid objects and recompile them. （データベースに無効なオブジェクトが存在します。確認して再コンパイルしてください）

invalid objects については、Oracle のバージョンアップ後によく見られるメッセージで、内部的な依存関係の解決に伴いオブジェクトが一時的に INVALID 状態になるものです。DBMS_UTILITY.COMPILE_SCHEMA や UTL_RECOMP.RECOMP_PARALLEL で再コンパイルすることで解消できます。

今回の検証では、これらのメッセージが出力された後も各システムへの接続・動作確認に問題はありませんでした。

実際にかかった時間

AWS 公式では「約 10 分」とされていますが、今回の環境では 20〜27 分程度かかりました。インスタンスタイプやデータ量、エンジンバージョンによって変わるため、事前にメンテナンスウィンドウの時間を十分に確保しておくことをおすすめします。

まとめ

今回は RDS for Oracle の OS アップグレード（New Operating System update is available）を実施した結果をまとめました。

• ダウンタイムは発生しますが、データやアプリケーション設定への影響はありませんでした
• マルチ AZ 構成でも、OS アップグレードの場合はダウンタイムが発生します
• 所要時間は 1 台あたり 25〜30 分（AWS 公式の「約 10 分」より長めでした）
• invalid objects / timezone file のイベントメッセージが出ましたが、動作には影響なし
• メンテナンスウィンドウを業務影響の少ない時間帯に設定しておけば、自動適用に任せるだけで対応完了します
• 手動で実施する場合は、業務影響の少ない時間帯での作業をおすすめします

OS アップグレード自体はシンプルな作業ですが、ダウンタイムが発生するため、事前にメンテナンスウィンドウの設定を見直しておくと、次回以降は自動適用でスムーズに対応できます。

最後までお読みいただきありがとうございました。
どなたかのお役に立てれば幸いです。

以上、おつまみ（@AWS11077）でした！

参考

• DB インスタンスのメンテナンス - Amazon Relational Database Service
• RDS エンジンのバージョンアップグレード後に表示されたアップデートについて | DevelopersIO