Google Cloud DMSでOracleからAlloyDBへ移行しようとしてみた

はじめに

Google Cloud DMS (Database Migration Service)は、オンプレミス環境や他のパブリッククラウド環境上で稼働しているデータベースをGoogle Cloud上のデータベースへ移行してくれるサービスになります。
例えば、オンプレミス環境のMySQL環境をGoogle Cloud上のCloud SQL for MySQLへの移行であったり、今回トライしたような Oracle DatabaseをPostgreSQLへ変換しつつ移行することが可能です。さらに、初期のスキーマ変換だけではなく、データ移行などもあわせて担う事ができる優れものです。

• Overview of Database Migration Service

やろうとしたこと

今回は移行元データベースとして OCI上のBaseDB(Oracle Database) から、移行先データベースとして Google Cloud 上のAlloyDB for PostgreSQL へ移行しようとしました。

途中でAlloyDBをDMSのターゲットとする場合には、現時点ではプライベート接続が必要になりかなり設定が大変そうだと思われたため、ターゲットを Cloud SQL for PostgreSQLへ変更しました。

• AlloyDB
  • Migrate Oracle workloads into AlloyDB for PostgreSQL by using Database Migration Service
  • Configure Private Service Connect for a destination cluster
• Cloud SQL for PostgreSQL
  • Migrate Oracle workloads into Cloud SQL for PostgreSQL by using Database Migration Service

DMS設定の流れ

DMSを利用するためには、以下のような流れで実施します。

1. 移行元データベースで事前設定を行う
2. 接続プロファイルの作成
   • 移行元データベース(Oracle Database)への接続プロファイル作成
   • 移行先データベース(Cloud SQL for PostgreSQL)への接続プロファイル
3. コンバージョンワークスペースの作成
   • 移行元データベースからスキーマ情報の取得
   • 取得したスキーマ情報の移行先データベース向けの変換
4. データ移行ジョブを実施

今回は 1. ～ 3. まで、つまり Cloud SQL for PostgreSQL上にスキーマやテーブルを作成するところまで実施しました。

1. 移行元データベースでの事前設定

移行元データベースがOracle Databaseの場合、以下のような設定が事前に必要です。詳細は 「Configure your source Oracle database」に記載があります。

• アーカイブログモードである事
• サプリメンタルロギングがONになっている事
• 適切な権限を持ったユーザで接続可能である事
  • コンテナデータベースの場合には、ユーザはCDBの共通ユーザである必要がある

サプリメンタルロギングの設定

$ sqlplus sys/[e-mail]:1521/xxxxxxxx.subnetxxxxxxxx.vcnxxxxxxxx.oraclevcn.com as sysdba

SQL*Plus: Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on Sun Sep 8 10:04:12 2024
Version 23.5.0.24.07

Copyright (c) 1982, 2024, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.24.0.0.0

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (all) COLUMNS;

Database altered.

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Database altered.

移行用の共通ユーザ(c##dms)の設定（CDB$ROOT）

※手順上は細かい権限で設定ですが、CDB側はdba権限を付与してます

$ sqlplus sys/[e-mail]:1521/xxxxxxxx.subnetxxxxxxxx.vcnxxxxxxxx.oraclevcn.com as sysdba

SQL*Plus: Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on Sun Sep 8 07:34:00 2024
Version 23.5.0.24.07

Copyright (c) 1982, 2024, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.24.0.0.0

SQL> grant dba to c##dms;

Grant succeeded.

SQL> exit

移行用の共通ユーザ(c##dms)の設定（PDB）

$ sqlplus sys/[e-mail]:1521/PDBTEST.subnetxxxxxxxx.vcnxxxxxxxx.oraclevcn.com as sysdba

SQL*Plus: Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on Sun Sep 8 07:42:15 2024
Version 23.5.0.24.07

Copyright (c) 1982, 2024, Oracle.  All rights reserved.

Connected to:
Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
Version 19.24.0.0.0

SQL> GRANT CREATE SESSION TO C##DMS;
GRANT SET CONTAINER TO C##DMS;
GRANT SELECT ANY TABLE TO C##DMS;

Grant succeeded.

SQL>
Grant succeeded.

SQL> GRANT SELECT ANY DICTIONARY TO C##DMS;

Grant succeeded.

SQL>
Grant succeeded.

SQL> GRANT SELECT ON SYS.V_$DATABASE TO C##DMS;
GRANT SELECT ON SYS.V_$ARCHIVED_LOG TO C##DMS;
GRANT SELECT ON DBA_SUPPLEMENTAL_LOGGING TO C##DMS;
GRANT SELECT ON DBA_EXTENTS TO C##DMS;
Grant succeeded.

SQL>
Grant succeeded.

SQL>
Grant succeeded.

SQL>

Grant succeeded.

SQL>

2. 接続プロファイルの作成

移行元データベース(Oracle Database)への接続プロファイル作成

移行元データベースとなるOracle Databaseへの接続プロファイルを作成します。

• Create an Oracle connection profile

接続するデータベースエンジンは「Oracle」を選択します。

接続方法は、今回は「IP許可リスト」を選択しています。
東京リージョンの場合は次図の5つのIPアドレスを許可する必要があります。

Oracle Database側のファイヤウォール設定で上記の5つのIPアドレスの接続を許可しています。(TCPの1521のみで良いと考えてます)

設定に問題がなければ、接続テストが成功してプロファイル作成を行うことが可能です。

移行先データベース(Cloud SQL for PostgreSQL)への接続プロファイル

同様に移行先データベース向けの接続プロファイルを作成します。

今回は「パブリックIP」を選択し、接続テストを行います。

3. コンバージョンワークスペースの作成

コンバージョンワークスペースとは、データベースマイグレーションに伴うスキーマ変換などを行う空間になります。今回は 移行元データベースであるOracle Databaseの定義を移行先データベースである PostgreSQLの定義に変換を行っています。

• Work with conversion workspaces

まずは移行元データベースと移行先データベースを設定してコンバージョンワークスペースを作成します。

移行元データベースからスキーマ情報の取得

移行元となるOracle Databaseへ接続し、スキーマ定義を取得します。

取得したスキーマ定義をCloud SQL for PostgreSQL向けに変換します。

変換を行った結果が次図になります。
「PRODUCT_REVIEWS」というVIEWのみ必要なアクションがあるようです。
中身を確認すると、OracleのJSON_TABLEという関数がPostgreSQLにはないので、変換が提案されています。
＃正しい変換なのかの確認はできてません・・

取得したスキーマ情報の移行先データベース向けの変換

コンバージョンワークスペースで設定した定義を移行先データベースに適用します。

• Apply schema to destination

コンバージョンワークスペースではViewや制約などについても変換を行いましたが、データ移行前のスキーマの段階ではテーブル本体と主キー制約のみの適用が推奨されていますので、今回はテーブルと主キー制約、そしてシーケンスがテーブル定義に依存しているためシーケンスも移行してみます。

無事適用が完了しました。
Cloud SQL for PostgreSQL上でもオブジェクトが作成されていることが次の通り確認できます。

postgres=> select schemaname, tablename, tableowner from pg_tables where schemaname='co';
 co         | order_items | postgres
 co         | customers   | postgres
 co         | inventory   | postgres
 co         | orders      | postgres
 co         | products    | postgres
 co         | shipments   | postgres
 co         | stores      | postgres

4. データ移行ジョブを実施

スキーマ変換後、そのままデータ移行ジョブも作成することが可能です。
ただ、今回は 移行元のテーブルに主キー制約がない、というエラーが出てしまい解消できませんでした。
＃主キーは全てのテーブルに設定されています

SQL> select owner, constraint_name, constraint_type, table_name from dba_constraints where owner='CO' and constraint_type='P';

OWNER      CONSTRAINT_NAME                          C TABLE_NAME
---------- ---------------------------------------- - --------------------
CO         CUSTOMERS_PK                             P CUSTOMERS
CO         STORES_PK                                P STORES
CO         PRODUCTS_PK                              P PRODUCTS
CO         ORDERS_PK                                P ORDERS
CO         SHIPMENTS_PK                             P SHIPMENTS
CO         ORDER_ITEMS_PK                           P ORDER_ITEMS
CO         INVENTORY_PK                             P INVENTORY

7 rows selected.

まとめ

データベースの移行については、こういったデータの移行・ジョブなどは実際の移行プロジェクトの中のほんの一部になります。
実際にはアプリケーション側でのノンデグレの確認などが工数の割合としては大半になるでしょう。
しかしながら、スキーマ変換やデータ連携がマネージドで実施することができると作りこみを行う箇所も減らせるので利用しやすくなるでしょう。

現時点では移行元はともかく、移行先のデータベースへの接続方式についてもプライベートの場合には制限が多く、なかなか利用が難しいと思われますが、そちらはGoogle Cloud内で完結しているのでいずれ制約がなくなると期待できます。

いずれにせよ、スキーマ変換などは現状でも利用できるため（そしてスキーマ変換だけなら無料）、移行を検討している場合や移行を検討していなくても将来のためにうちのデータベースはどんな感じなのかな？という事を確認してみても良いかもしれません。