こんにちは！ m.uriuです。
Oracle Cloud Infrastructure Advent Calendar 2023のDay17記事です。
今回は2023年10月末にリリースされた、Oracleベース・データベースで作成できるDBインスタンスの、Oracle Database 19cの最新バージョン 19.21 についてのお話です。
ご存じの方もいらっしゃるとは思いますが、Oracleベース・データベースでは、Oracle Database 19cのバージョン19.21を選択して作成したDBインスタンスは、OSがOracle Linux（以降OL） 8.8でデプロイされます。
バージョン19.19や19.20のDBインスタンスのOSはOL7.9ですが、そのDBインスタンスにバージョン19.21のアップデートパッチを適用して特定の操作をすると、OL8のアップグレードパッチを適用していなくてもOSがOL7.9からOL8.8にアップグレードされることがある、ということがわかりました。
このバ－ジョン19.21のアップデートパッチはDBシステムとデータベース（以降DB）にそれぞれありますが、この現象はDBにアップデートパッチを適用している場合に起こることが確認されています。
（以降アップデートパッチはDBのものを指すものとし、DBシステムは除外します。）
今回の記事では、どんな操作をするとOSがアップグレードしてしまうのかを検証しましたので、その紹介をしていきます。
目次
Oracle DatabaseのバージョンとOS
まず、Oracleベース・データベースでデプロイできるDBインスタンスの、Oracle Database 19cのDBシステムとDBそれぞれのバージョンとOSバージョンの確認をしましょう。
| システム | バージョン | バージョン | バージョン | 備考 |
|---|---|---|---|---|
| DB | 19.19 | 19.20 | 19.21 | 19.21のアップデートパッチが10月末にリリース |
| OS | OL7.9 | OL7.9 | OL8.8 | OL8.8のアップグレードパッチが12/4の週にリリース |
バージョン19.21を境にOS8.8へ変わっていますね。
冒頭でお話しした通り、新しくOracleベース・データベースでOracle Database19cのバージョン19.21を選択して作成すると、OL8.8でデプロイされます。
※おそらく19.21がリリースされた際に、バージョン19.21で新規にデプロイされるDBインスタンスのOSがOL8.8になる仕様になっていたと思われます。既存のOL7.9のDBインスタンスに対するOL8.8へのOSのアップグレードパッチは、12/4の週にリリースされました。
また、既存のDBインスタンスのOSをアップグレードする際は、「DBシステムの詳細画面」から「更新画面」へ移動し、OSのアップグレードパッチを適用することで、DBインスタンスのOSをOL7.9からOL8.8にアップグレードできます。
Oracle DatabaseのOSが変わるとどうなるの？
バージョン19.21でデプロイしたり、更新画面でOL8のアップグレードパッチを適用すれば、OL8.8の環境でDBが使えることが分かりました。
しかし、既存のDBインスタンスのOSをアップグレードすると、とある問題が発生します。
それは、OSの設定が初期化されることです。
アップグレードするとOSが丸ごと置き換わるので、OL7.9でこれまで使っていたOSの設定変更は引き継がれず、OL8.8基準で全部初期化されます。
After your Upgrade is Complete
After a successful upgrade, note the following:
・The upgrade exchanges the boot volume. So all customization of the OS will be removed (and have to be reapplied by the customer)
(以下google翻訳)
アップグレードが完了したら
アップグレードが成功したら、次の点に注意してください。
・アップグレードによりブート ボリュームが交換されます。したがって、OS のカスタマイズはすべて削除されます (顧客が再適用する必要があります)。
（公式ドキュメントはこちら）。
準備もなくOL8.8にアップグレードすると、場合によってはとんでもないことになります。OCIコンソール上の簡単なクリック操作でアップグレードできてしまいますが、ご利用は計画的に。
アップグレード操作をしなくてもOL8.8に？！
これまでの話では、DBインスタンスの新規デプロイや既存のDBインスタンスのOSのアップグレードで、DBインスタンスのOSがOL8.8になることについてご紹介しました。
しかし、実はそれ以外の操作でDBインスタンスのOSがOL7.9からOL8.8に変更されてしまうことがあります。
先ほどご紹介したように、19.21のアップデートパッチとOL8へのアップグレードパッチは既に公開されており、図2のように更新画面で表示されていれば、いつでもパッチの適用が可能です。
図2の通り、OL8のアップグレードパッチと19.21のアップデートパッチは別項目として扱われています。
ここで「19.21アップデートパッチだけ適用して、OSのアップグレードをしなければ、今まで通りOL7.9で使い続けられるのでは？」と思われるかもしれませんが、
OL7.9/バージョン19.21の状態のDBインスタンスでも、OSがOL8.8にアップグレードしてしまうケースがあります。
ここからは、そのDBインスタンスのOSがOL8.8にアップグレードしてしまうケースを2パターンご紹介します。
1.Data Guardアソシエーション機能を使用してData Guardを構築する
1つ目は、DBに19.21のアップデートパッチを適用したDBインスタンスで、Oracleベース・データベースのData Guardアソシエーション機能を使用してData Guardを構成した場合です。
厳密にいえば、Data Guard構成の元となったプライマリ側のDBインスタンスはOL7.9/バージョン19.21のまま変わらないのですが、
Data Guardアソシエーション機能で作成されたスタンバイ側のDBインスタンスは、OL8.8/バージョン19.21となってしまいます。
バージョン19.20以前で作成した、既にData Guardを構成済みのDBインスタンスで、もし一旦Data Guard構成を壊して新しく作り直すときは、バージョンが19.21になっていないか確認しておくべきでしょう。
備考
「プライマリとスタンバイでOSが異なっていても、Data Guardは機能するのか」という点については、
一応過去の問い合わせではDBのバージョンが一致していれば、Data Guardは機能する〜という回答は得ています。
ですが、トラブルシューティングができなそうなので運用したくないですね。
2.バックアップからのリストアをする
2つ目は、DBに19.21のアップデートパッチを適用したDBインスタンスで、バックアップからのリストアをした場合です。
こちらもバックアップ元のDBインスタンスはOL7.9/バージョン19.21のまま変わらないのですが、
リストアされたDBインスタンスは、OL8.8/バージョン19.21となってしまいます。
DBのリストアする自体になった際に、OL7.9で検証していたOS側の機能やソフトウェアパッケージをOL8.8で動作保証できないため、検証などが発生して業務上の復旧時時間が伸びてしまう可能性が高く、現在の運用でバックアップを取得している場合は無視できない仕様かと思われます。
アップデートパッチを適用しなければOSは上がらない？
DBに19.21のアップデートパッチを適用したDBインスタンスで、1.Data Guardアソシエーション機能を使用してData Guardを構築する、もしくは2.バックアップからのリストアをすると、作成されたDBインスタンスのOSがOL8.8になるということが判明しました。
- Data Guardの構築 → スタンバイ側はOL8.8/バージョン19.21でデプロイ
- バックアップからのリストア → OL8.8/バージョン19.21でリストア
ならば、19.21のアップデートパッチを適用しなければOSは変わらないのではないのでしょうか？
OL7.9/バージョン19.20のDBインスタンスを使って、Data Guardアソシエーション機能を使用したData Guardの構築と、バックアップからのリストアを実施し、検証した結果はそれぞれ以下の通りになりました。
- Data Guardの構築 → スタンバイ側はOL7.9/バージョン19.20でデプロイ
- バックアップからのリストア → OL7.9/バージョン19.21でリストア
Data Guardの構築は同じOS、同じバージョンでスタンバイ側が作成されたので、バージョン19.21にアップデートしなければ問題はなさそうです。
バックアップからのリストアですが、こちらはOSは変わらず、バージョンだけ19.21に上がった状態でリストアされてしまいしました。
こちらで解説した通り、バージョン19.21でリストアされたDBインスタンスから、さらにバックアップを取得してリストアすると、そのDBインスタンスのOSはOL8.8になってしまいます。
この問題の対策としては、リストアしたDBインスタンスのDBがバージョン19.21にならないよう、リストア時にバージョン19.20のデータベース・ソフトウェア・イメージ（以降イメージ）を使用すると良いでしょう。
バックアップ元のDBインスタンスから、「データベース詳細画面」の「More actions」にある「データベース・ソフトウェア・イメージの作成」から、バックアップ元のDBと同じバージョンのイメージを作成するか、
「Oracleベース・データベース」の「データベース・ソフトウェア・イメージ」で「データベース・ソフトウェア・イメージの作成」から指定したバージョンのイメージを作成できます。
イメージが作成されると、図5のようにバックアップからのリストアの際にデータベース・イメージのオプションからイメージが選択できるので、ここからあらかじめ作成したイメージを選択してリストアしましょう。
（※バックアップ元のDBインスタンスのバージョンが19.21だった場合、バージョン19.20のイメージは選択できません。）
それでも！OL7.9で使い続けたい
ここまで、既存の運用次第ではDBインスタンスのOSがOL8.8に変更されてしまうケースと、OSをOL7.9のまま使用できるケースについて解説しました。
では、今後OL7.9のままバージョン19.21以降も安心して使い続けることはできるのでしょうか？
Oracle Cloudからのサポートは受け続けられるのかSRに問い合わせたところ、
「Oracle的にはOL7.9でもBaseDatabaseとしてのサポートはします」とのことです。
まとめ
- バージョン19.21でデプロイしたOracle DatabaseのOSはOL8.8になる。
- バージョン19.20以前のDBインスタンスは、更新画面でバージョン19.21のアップデートパッチ、OL8へのアップグレードをそれぞれ適用できる。
- 既存のOL7.9のDBインスタンスをOL8.8にアップグレードされると、OSの設定は全部消える。
- バージョン19.21のアップデートパッチを適用し、Oracleベース・データベースのData Guardアソシエーション機能やバックアップからのリストアを使用すると、OL8.8のDBインスタンスが作成される。
- OL7.9のままDBインスタンスを維持することは可能だが、運用次第ではアップグレードは避けられない。
バージョン19.21のリリースにより、アップグレードパッチを適用せずにOSがアップグレードされてしまうケースがある、ということをご紹介しました。
できればOracle側で、「OL7.9のバージョン19.21」と「OL8.8のバージョン19.21」2つのイメージをユーザが任意で選択できるようにしてほしいところです。
ただ、今年はOracle Databaseの23cもリリースされたということで、ある種時代の節目なのかもしれません。上記のような便利なイメージが登場せず、これまでの運用が難しいなら、どこかのタイミングでOL8にアップグレードしたり、OL8.8に対応した構成でDBインスタンスを再構築をすることを考えなければいけないのかもしれませんね。