はじめに
OCIのBase Database ServiceにOCPUではなくECPUメトリックを利用するサービスが追加されました。それに伴い、サービス提供の変更が発表されています。（リンク)
今後、OCPUベースのBase DBからECPUベースへの移行が必要となるケースも考えられます。
ECPUメトリック同士であればShapeの変更で移行ができるようですが(VM.Standard.x86 → VM.BaseDB.x86)、従来のOCPUベースのShape からのShape変更での移行は今のところできないようです。
そのため、OCPU→ECPU変更のDB移行をできるだけ簡単に行える手段を考えます。
目的および前提条件・注意事項
本手順では、できるだけ簡便にDBを移行することを目的として、OCIのコンソールで完結する手段を考えます。
そのため、DBの使用停止を前提とし、OCI Base Database Service の OCPU ベース DB System のバックアップから、ECPU ベースの新規 DB System を作成します。旧 DB System を直接変更する手順ではありません。
- 移行元・移行先の DB System は、同一リージョン・同一 VCN・同一 Subnet に配置します。これにより、Security List / NSG / ルート表などのネットワーク設定変更を最小化します。
- 新規作成する DB System には別の Private IP アドレスおよびホスト名が割り当てられます。アプリケーションの接続先は、切替時に新 DB System の接続情報へ変更する必要があります。
- 移行元と移行先では、Single Node / RAC などの DB System 構成を一致させます。また、移行先の Oracle Database バージョンは、バックアップ元と同一またはそれ以上にします。
- バックアップからの復元では、DB 内のデータ、スキーマ、ユーザー、DB 内のジョブなどが復元対象です。一方で、DB System 周辺の設定（監視設定、OS 上の独自スクリプトやファイル、アプリケーション設定など）は必要に応じて移行先へ別途設定します。
- TDE を使用する BaseDB では、復元時に TDE Wallet パスワードまたは RMAN 暗号化パスワードが必要に
なる場合がありなります。 - ECPU 数は OCPU 数との単純な等価変換ではありません。CPU 使用率、メモリ使用量、I/O 性能を基に ECPU 数とストレージ容量を選定し、可能であれば事前に復元・性能検証を実施します。
- 本手順ではデータ不整合を防ぐため、最終バックアップの直前に DB への書込みを停止します。停止開始から新 DB System への接続先切替が完了するまで、アプリケーションからの更新処理は停止します。
- 切替後に問題が発生した場合に備え、旧 DB System はすぐに削除せず、動作確認と切り戻しの判断に必要な期間は保持します。
大まかな移行手順イメージ
本記事では主にこの手順の2,3について説明します。
バックアップの作成
移行の対象となるDBシステムのコンソールに移動しデータベースタブを選択、データベース名をクリックしてデータベース情報に移動します。
バックアップ タブをクリックし、バックアップの情報を表示します。
ここでバックアップの作成ボタンをクリックします。
バックアップの名前を入力してバックアップを作成します。
バックアップの作成が完了すると、状態が アクティブ になります。
バックアップからECPUの新規DBを作成
バックアップの作成が完了したあと、同じコンソールのページの右上の その他のアクション ボタンをクリックし、表示されるメニューから バックアップからのデータベースの作成 を選択します。
最終バックアップからのデータベースの作成 を選択、PDBは すべてのPDB を選択し、その他必要情報を入力します。
シェイプの変更 と必要に応じて ストレージの変更 を行います。
シェイプの変更
BaseDB X86 を選択し、ECPUの構成を変更します。
ECPUの目安として、1 OCPU ≒ 4 ECPU となります。
注意点として、CPUあたりのメモリーがECPU構成ではOCPUの約半分となるため、メモリーを多く使用するシステムでは、必要とするメモリーサイズに応じてECPUのサイズを検討する必要があります。
SSHキーを設定します。ここでは既存のSSHキーファイルをアップロードしています。
ライセンス・タイプを選択し、ネットワーク情報として今回は移行元のDBが置かれている仮想クラウド・ネットワークと、移行元のDBの置かれているサブネットを選択します。
ホスト名接頭辞を指定する場合は入力し、必要に応じてIPv4アドレスを手動割り当てします。
標準ではタイム・ゾーンがUTCとなっているので、拡張オプションを開いて、Tokyoに変更します。
その他の必要情報を入力または変更し、最後に管理者パスワードと、ソース・データベースのTDEウォレットパスワードを入力し、作成 ボタンをクリックします。
DBシステムのステータスが プロビジョニング中 となり、DBの作成が始まりますので、完了するまで待ちます。
無事にDB作成に成功すると 使用可能 ステータスになります。
以上でデータベースの移行作業は完了です。
失敗ケース
失敗例
TDEウォレット、RMANパスワードが間違っているとDBの作成に失敗します。
注意
管理者資格証明 で入力する TDEウォレットまたはRMANパスワード ですが、DBを新規作成した場合、標準では管理者パスワードと同様に設定されます。
このケースでは、管理者パスワード(SYS)と同一で入力したのですが、以前にパスワードがExpireしたため、管理者パスワードを変更していました。この際、TDEウォレットのパスワードは一緒に変更されないので注意が必要です。TDEウォレットのパスワードを明示的に変更していない場合、現在の管理者パスワードではなく、DB作成時に指定したパスワードを指定する必要があります。
補足
バックアップにかかる時間
バックアップ元のデータベースのコンソールから、作業リクエストタブをクリックすると、開始時間と終了時間が確認できます。
参考までに、使用可能なデータ・ストレージ 256GBで作成したこのDBのケースでは約30分弱でバックアップが完了しています。
データベース作成にかかる時間
作成したDBシステムのコンソールから、作業リクエストタブをクリックすると、上記と同様に開始時間と終了時間を確認できます。
今回のケースでは約70分ほどでDBの作成が完了しています。
バックアップ移行作業にかかる時間
今回のようなBase DBの最小構成では、オペレーションを含め、おおよそ2時間ほどあれば移行イメージの２，３にあたる作業は完了できそうです。
今回の手法のメリットの一つは、システム負荷の低いときにバックアップを取ってしまえば、システムを停めることなく、移行先のDBを作成できることです。
そのため、事前に移行テストをし、作業にかかる時間の見積もりや、アプリケーションの接続性などのテストをしっかりと行うことをおすすめします。