Oracle Database テナント構成におけるバージョンアップとPDB移動の考え方

Oracle Database 21c リリース当時、様々な仕様変更が発表されました。そのうちの一つ、DB構成に関してはDBごとにインスタンスを持つ従来構成の廃止も決まりました。21c以降はインスタンスをDB間で共有利用するテナント構成のみが選択可能になります。管理者の方々は19cへバージョンアップの際、テナント構成に変えるのか、21c以降のロングタームリリース（長期リリース）が登場するまで従来構成を維持するのか、選択が必要です。
今回は「テナント構成にしておくことのメリット」のうちの一つ「可搬性」にフォーカスしてバージョンアップとPDB移動の考え方をご紹介します。

テナント構成とは 12cR1からリリースされたOracle Database の新しいDB構成です。後述の参考記事でも紹介しておりますので詳細は割愛しますが、テナント構成は「Container Database（CDB）」と「Pluggable Database（PDB）」で構成されており、ユーザーデータは「PDB」に格納されます。

テナント構成は「シングルテナント」と「マルチテナント」の2種類の構成があります。Standard Edition2（以下SE2） および Enterprise Edition（以下EE） の場合は1個のCDBに対し3個のPDBまで、という個数の上限があります(*)。上限を解除したい場合、EEの有償オプションである Oracle Multitenant オプションを利用すると、PDB4個以上のマルチテナント構成をとることも可能です。

(*) オプション未保有の場合18c ではシングルテナントのみ構築可能でした。19cからは1CDBにつき3個のPDBまで、と上限が緩和されています。

【参考】マルチテナントのPDB数はどう見積もる？最適なエディション選択と検討のヒント
https://www.ashisuto.co.jp/db_blog/article/howto-estimate-number-of-pdb.html

「可搬性」とは「持ち運んだり移動させたりすることが可能であること」を表します。テナント構成における可搬性とは、PDBを特定のCDBから別のCDBに unplug/plug できる機能を指します。

移動前後のCDBはオンプレにあるのか、クラウドにあるのかは意識せずに unplug/plug することができます。例えばオンプレとクラウド、もしくはオンプレとオンプレでもPDBの移動は可能です。

PDBを移動させるだけではなく、「クローン機能」や「テナント構成のアップグレード機能」もうまく使うことで下記のような悩みを解決できるケースもあります。

もう少し具体的にご紹介しましょう。

テナント構成のPDBは「クローン機能」を使うことで複製できます。クローニング、とも呼ばれます。

例えば本番DBから検証用のDBを作成したい場合、従来構成の場合は検証用のDBを別途作成し、本番DBからデータをExport、検証用のDBへImportする、といった複数のステップが必要でした。テナント構成の場合、PDBをクローン機能で複製し、別のマシンのCDBに plug する、という少ないステップで実現することができます。

本番DBが稼働中の状態で複製することも可能です。この複製機能は「ホットクローン」と呼びます。12cR2から登場しました。過去の記事ではこのホットクローンの操作をキャプチャした動画も公開しています。ぜひそちらもご覧ください。

【参考】
20cから従来構成は非サポート！Oracle Multitenantを攻めのITとして使おう！
https://www.ashisuto.co.jp/tech-note/article/20200526_oracle.html

リプレースの際、一番シンプルな手法は「Export / Import」です。10gR2以降は後継としてData Pump Export / Import が提供されており、テナント構成でも従来構成でも利用できます。

リプレース計画を検討する際、本番切替時に「システム停止が可能な時間はどれくらいあるのか」も考慮した計画を事前に練ることになります。計画をする上で管理者の頭を悩ませるのは、格納データの移行手法です。例えば先ほどご紹介した「Export / Import」の場合、データ量が大きければ大きいほどExport の時間も Import の時間もかかります。中間ファイルとして「Export したダンプファイル」も必要です。リプレースをする場合、このダンプファイルの移動（もしくは転送）時間も考慮が必要です。

テナント構成の場合、クローン機能とDBLink を組み合わせることでバージョンアップのステップを簡素化することができます。結果として「システム停止が必要な時間」を短くすることに繋がります。リプレースをする際、DBのバージョンアップも兼ねて実施するケースも多いと思いますが、異なるバージョン間でもこの手法は使えます。

実施ステップの違い（1PDBあたり）を図で表すと下記のようなイメージです。複数のDBを移行する場面だと、さらにステップ数のシンプルさが活きてきます。

ちなみにホットクローン機能（12cR2～）を使った場合は、クローン生成後にリフレッシュ操作を実施した後にアップグレード処理を実施します。ホットクローン機能はDBに読み書きを施している間に複製ができるため、例えばデータ量が多い場面ではシステム停止前に複製しておき、システム停止後にリフレッシュ操作をすることで停止期間中の作業工程を短くすることも可能です。

マルチテナント構成ならDBの集約・統合に向いている、メモリやCPUのリソースを節約できる、というお話は見聞きしたことはあると思います。バージョンアップも兼ねて集約・統合を検討される場面は多いので、アップグレード関連の機能についてもご紹介しましょう。

例えば「複数のDBを順次テナント構成の基盤に集約・統合し、バージョンアップを実施する」という場面を例に考えてみます。

5個のDBが対象だとします。それぞれのDBに関連する5個のシステムを同時に停止させてパッチ適用やバージョンアップを実施するとなると社内調整のハードルも高く、管理者の作業負荷も大きくなります。今回の例ではシステムへの影響度を考えて、プロジェクト自体を分割して少しずつDBを新しい基盤に移していく、とします。

新しい移動先のCDB上にあるPDBには、最終的にはアップグレード処理が必要です（具体的にはアップグレードに必要なスクリプトを実行します）。新しい環境上のPDBは1個から2個、2個から3個と増えます。Oracle Database の仕様上、スクリプトの実行時に何も指定しない場合、CDB全体がアップグレードスクリプトの実行対象の範囲になります。既にアップグレード済みのPDBにも再度スクリプトが実行されるため、PDB数が増えれば増えるほど無駄な工程も増えてしまいます。

このようなシーンに備え、Oracle Database のテナント構成では「アップグレード範囲を制限する機能」が提供されています。「包含リスト」もしくは「除外リスト」の2種類の指定方法があります。どちらの場合も本来アップグレードしたいPDBだけをスクリプトの実行対象にすることができます。

どちらを選択するかはその時のアップグレード対象のPDB数により選択が可能です。SE2の場合、1つのCDBに3つまでのPDBしか作成できないためどちらのリストでも大差はありません。EE の Oracle Multitenant オプションを導入している場合は 4個以上、場合によっては数十、百以上のPDBが1つのCDBに集約されるケースもあるため、リストに指定する内容が少ない方を選ぶと良いでしょう。12cR2以降では、どのPDBからアップグレードするかを指定できる優先度リストも利用できます。

このように包括リスト、または除外リストを使ってアップグレードにかかる無駄な工数を削減し、作業コストを抑えることができます。

【参考】
マルチテナントのPDB数はどう見積もる？最適なエディション選択と検討のヒント
https://www.ashisuto.co.jp/db_blog/article/howto-estimate-number-of-pdb.html

今回は「テナント構成にしておくことのメリット」のうちの一つ「可搬性」にフォーカスしてバージョンアップとPDB移動の考え方をご紹介しました。クローン機能やアップグレード処理の機能も組み合わせることで管理者負荷も大幅に削減できます。早い段階でテナント構成に切り替えておくことで、次期バージョン環境へのリプレースもしやすくなることが期待できます。

また、PDBが移動できるということは「マシンスペックの有効活用」につなげられる可能性もあります。例えば高スペックなマシンから低スペックなマシンにPDBを移動させ、重要度の高い新システムを高スペックなマシンの空いた空間に搭載するなど、クラウドには移せないシステムでも従来構成ではできなかった選択肢がとりやすくなります。EE の Oracle Multitenant オプションがあればPDB数の制限を気にしなくて良いため、さらに利便性が高まります。

Oracle Multitenant のオプションを利用したいと思っても、EE ライセンスの課金対象は搭載されているコア数に依存するため、IAサーバの想定だと検討が進めにくい場面もあると思います。必要なスペックに合わせたライセンス数量で運用したいお客様には「Oracle Database Appliance（略称：ODA） 」 などのアプライアンス製品でライセンスコストを抑えることも可能です。
自社にとっての最適なDB構成にお悩みの方は、ぜひアシストにご相談くださいませ。

管理者ガイド（19c）
https://docs.oracle.com/cd/F19136_01/multi/preface.html#GUID-02957445-DCA3-408A-B16A-72527C816CCD

アップグレードガイド（19c）
https://docs.oracle.com/cd/F19136_01/upgrd/manual-upgrade-scenarios-multitenant-architecture-oracle-databases.html#GUID-8231CE50-ABEC-4BA3-A4AC-D461EB791ACD

マルチテナントのPDB数はどう見積もる？最適なエディション選択と検討のヒント
https://www.ashisuto.co.jp/db_blog/article/howto-estimate-number-of-pdb.html

マルチテナントはトラブル調査をどう変えるのか
https://www.ashisuto.co.jp/tech-note/article/20210107_oracle.html

20cから従来構成は非サポート！Oracle Multitenantを攻めのITとして使おう！
https://www.ashisuto.co.jp/tech-note/article/20200526_oracle.html