はじめに
OCI Base Database Service(BaseDB)で「OS Update」がコンソール/APIから実行できるようになりました。
これは従来dbcliで実施していたOS更新操作を、OCIコンソール/APIからも実行できるようにしたものという理解です。
新機能の詳細はこちら
Oracle Base Database Serviceの新機能「オペレーティング・システムの更新」
元々のdbcliの操作内容をあまり知らなかったということもあり、最初にこの新機能を見たとき、私は「Oracle Linuxのマイナーバージョンを上げてくれる機能なのかな？」と思いました。たとえばOSのリリース自体が上がるようなイメージです。
ただ、実際に確認してみると、今回の OS Update はその意味ではなく、DBシステム上のOSに対して提供されているRPMパッケージ更新を、OCI コンソールやAPI/CLIから実行できる機能でした。
名前だけだと少し勘違いしやすかったので、実際の見え方と検証した内容を共有します。
公式ドキュメント
今回確認した主な公開ドキュメントはこちらです。
公式ドキュメント上では、DBシステムの詳細画面にある Updates (OS) タブから、OS updateのPrecheckとApplyを実行できると説明されています。
またCLIでは、oci db system execute-db-system-os-patch に PRECHECK または APPLY を指定して実行できます。
ちなみにDBシステムは、BaseDBにおいてOracle Databaseを稼働させるVMベースの環境を管理する単位です。
この機能は本番環境でいきなり実行するものではなく、公式ドキュメントでも、バックアップ取得、テスト環境での検証、利用者が少ない時間帯での実施が推奨されています。
検証環境
今回の検証では、以下のようなBaseDBの環境を用意しました。
| 項目 | 値 |
|---|---|
| サービス | OCI Base Database Service(BaseDB) |
| 構成 | シングル |
| リージョン | KIX(大阪リージョン) |
| OS | Oracle Linux 8 |
| 操作方法 | OCI コンソール、OCI CLI 、DBCLI |
検証手順
1. 更新前の状態を確認する
まず、DBシステムの詳細画面を開きます。
OCI コンソールで以下の順に進みます。
Oracle AI Database > Oracle Base Database Service > 対象のDBシステム > 更新(OS)のタブ
ここでOS更新が利用可能かを確認します。画面では使用可能と表示されているので、利用可能な状態です。
あわせて、BaseDBのノードにログインし、現在のOS情報と主要RPMを控えておきます。
[opc@based ~]$ cat /etc/oracle-release
Oracle Linux Server release 8.10
[opc@basedb ~]$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="8.10"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.10"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.10"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:10:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://github.com/oracle/oracle-linux"
ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.10
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.10
[opc@basedb ~]$ uname -r
5.15.0-316.196.4.1.el8uek.x86_64
[opc@basedb ~]$ rpm -qa --last | head
dcs-agent-26.1.2.0.0_260313.1702-11.x86_64 Thu 30 Apr 2026 05:18:39 AM UTC
mysql-8.0.21_el7-8.0.21.x86_64 Thu 30 Apr 2026 05:16:24 AM UTC
glibc-static-2.28-251.0.4.el8_10.27.x86_64 Wed 18 Mar 2026 05:48:04 AM UTC
glibc-static-2.28-251.0.4.el8_10.27.i686 Wed 18 Mar 2026 05:48:04 AM UTC
glibc-nss-devel-2.28-251.0.4.el8_10.27.x86_64 Wed 18 Mar 2026 05:48:04 AM UTC
glibc-nss-devel-2.28-251.0.4.el8_10.27.i686 Wed 18 Mar 2026 05:48:04 AM UTC
oracle-database-preinstall-23ai-1.0-4.el8.x86_64 Wed 18 Mar 2026 05:48:03 AM UTC
gcc-plugin-annobin-8.5.0-28.0.1.el8_10.x86_64 Wed 18 Mar 2026 05:48:03 AM UTC
gcc-c++-8.5.0-28.0.1.el8_10.x86_64 Wed 18 Mar 2026 05:48:03 AM UTC
annobin-11.13-2.0.6.el8.x86_64 Wed 18 Mar 2026 05:48:03 AM UTC
[opc@basedb ~]$
OS更新の後に「OSリリース自体が変わったのか」「RPM更新が入ったのか」を比較できるようにするために情報として控えておきます。
2. 事前チェックを実行する
更新(OS) タブのステータスの右側に位置する「・・・」から 事前チェック を実行します。
2ノード RAC構成の場合は、対象ノードを選択できます。
ちなみにCLIで実行する場合は、以下のようなコマンドで実行します。
oci db system execute-db-system-os-patch \
--db-system-id <DB_SYSTEM_OCID> \
--action PRECHECK
特定ノードを対象にする場合は --db-node-id を指定します。
oci db system execute-db-system-os-patch \
--db-system-id <DB_SYSTEM_OCID> \
--db-node-id <DB_NODE_OCID> \
--action PRECHECK
事前チェックを開始するとBaseDBのステータスが更新中に変更されるので、処理が完了し、ステータスが元に戻るまで待ちます。
3. 事前チェック結果を確認する
事前チェックが完了したら、更新履歴 タブもしくは作業リクエストで結果を確認します。シングルノードの環境で5分程度でした。
コンソールから確認できるポイントは以下です。
- 事前チェックが成功しているか
- あればエラーメッセージ
- 更新対象のRPMパッケージ
- 再起動が必要かどうか
事前チェック後の詳細画面では「再起動が必要です」と表示されました。OS更新を適用した後に、ノードの再起動が必要になることが分かります。
今回はシングルノード構成のため、この再起動中はDBに接続できない時間が発生します。
この時点で、今回のOS更新が「OSのリリースを上げる操作」というより、「OSパッケージ更新を適用する操作」であることが見えてきます。
4. OS Updateを適用する
事前チェックが成功していることを確認したら、更新(OS) タブに戻り、先ほどと同じ「・・・」からOS更新の適用 を実行します。
CLIの場合は以下のコマンドで実行します。
oci db system execute-db-system-os-patch \
--db-system-id <DB_SYSTEM_OCID> \
--action APPLY
特定ノードに適用する場合は --db-node-id を指定します。
oci db system execute-db-system-os-patch \
--db-system-id <DB_SYSTEM_OCID> \
--db-node-id <DB_NODE_OCID> \
--action APPLY
CLIの説明では、この操作は作業リクエストを返し、一部の更新では再起動が必要になる場合があるとされています。
5. 更新後のOS/RPM状態を確認する
更新完了後、ステータスが元に戻ると処理完了です。実行時間はシングルノードの環境で15分くらいで、事前チェックより長く時間がかかりました。
では、ノードを再起動して、更新が反映されているか確認していきます。
ノードの再起動はノードタブに移り、対象ノードの右端「・・・」から再起動ボタンを押して実行します。
再起動が完了したのでノード上で更新前と同じコマンドを実行してみましょう。
[opc@basedb ~]$ cat /etc/oracle-release
Oracle Linux Server release 8.10
[opc@basedb ~]$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="8.10"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.10"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.10"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:10:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://github.com/oracle/oracle-linux"
ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.10
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.10
[opc@basedb ~]$ uname -r
5.15.0-319.201.4.6.el8uek.x86_64
[opc@basedb ~]$ rpm -qa --last | head
glibc-static-2.28-251.0.4.el8_10.34.x86_64 Mon 18 May 2026 02:21:23 AM UTC
rsync-3.1.3-25.el8_10.x86_64 Mon 18 May 2026 02:21:22 AM UTC
perl-XML-Parser-2.44-12.0.1.el8_10.x86_64 Mon 18 May 2026 02:21:22 AM UTC
nss_hesiod-2.28-251.0.4.el8_10.34.i686 Mon 18 May 2026 02:21:22 AM UTC
nss_db-2.28-251.0.4.el8_10.34.x86_64 Mon 18 May 2026 02:21:22 AM UTC
nss_db-2.28-251.0.4.el8_10.34.i686 Mon 18 May 2026 02:21:22 AM UTC
libnsl-2.28-251.0.4.el8_10.34.x86_64 Mon 18 May 2026 02:21:22 AM UTC
jq-1.6-12.el8_10.x86_64 Mon 18 May 2026 02:21:22 AM UTC
glibc-static-2.28-251.0.4.el8_10.34.i686 Mon 18 May 2026 02:21:22 AM UTC
glibc-nss-devel-2.28-251.0.4.el8_10.34.x86_64 Mon 18 May 2026 02:21:22 AM UTC
ここで、OSリリースそのものが変わったのか、RPMパッケージが更新されたのかを確認します。
更新前後を比較すると、Oracle Linuxのリリースはどちらも8.10のままでした。
一方で、カーネルは 5.15.0-316... から 5.15.0-319... に変わり、複数のRPMも更新されています。
つまり今回のOS更新は、Oracle Linux 8.10から別のOSリリースへ上げる操作ではなく、BaseDBのDBシステムに対して提供されているOSパッケージ更新を適用する操作だと確認できました。
私が見たかったのはここで、OS更新 という名前からOSのマイナー・バージョンアップを想像していましたが、実際にはRPMパッケージ単位の更新として捉えるのがよさそうです。
dbcliで確認する場合
従来どおりDBシステムのノードにSSHして dbcli で確認する方法も引き続き可能です。
dbcliはBaseDB専用のCLIです。コンソールからできる操作をベースにBaseDBに対してさまざまな操作ができます。
dbcliを使う場合、利用可能なOSパッチは以下で確認できます。
sudo su -
dbcli get-availableospatches
OS更新の事前チェックは以下です。
dbcli update-server -c os -p
OS更新の適用は以下です。
dbcli update-server -c os
公式ドキュメントでは、get-availableospatches の結果に rebootIsRequired が含まれる場合があり、必要に応じて更新後に再起動することが説明されています。
まとめ
今回の学びはOS更新という名前だけで「OSのバージョンアップ」と捉えない方がよい、という点です。
BaseDBのOS更新は、DBシステムに対するOSパッケージ更新をコンソール/API/CLIから実行できる機能として見ると理解しやすいです。
特にプリチェック、更新対象のRPM確認、作業進捗状況が全てコンソール上で確認可能というのが便利だと感じた一方で、シングルノード構成ではダウンタイムに注意が必要です。また、本番環境ではバックアップ、事前検証、メンテナンス時間帯、必要に応じたData Guardなどの可用性構成を考慮してから実施する方が安心です。
名前でちょっと勘違いしたところから調べ始めましたが、実際に触ってみると「BaseDBのOSパッチ適用をConsole/APIで扱えるようになった」と考えると、かなり運用しやすくなる機能かと思います。