今回はDB移行のポイントと移行を支援してくれるツールについて記載します。
#移行支援ツール
Oracle DatabaseからAzure Database for PostgreSQLへの移行を進めていく中で、ソースとなるOracle Databaseのオブジェクトにおいて、定義情報を変更せずに移行できることは稀です。
移行後も同様の機能を遜色なく利用するには様々な調査や改修を実施する事が必要です。一方でこれらの調査や改修を人の手で全て実施していくのは大変時間がかかってしまう作業となります。そういった場合に利用すると有効なツールが移行支援ツールです。
##ora2pg
オブジェクト定義のマイグレーションにおける調査、変換を行ってくれるツールは世の中には様々存在しています。今回は、その中のツールの１つora2pgを紹介します。
ora2pgでは以下のよな事を実施する事が可能です。
-
スキーマ定義のコンバージョン用DDLの作成
接続したOracleデータベースにあるオブジェクト定義からPostgreSQLで実行可能なDDLの出力 -
スキーマコンバージョンのレポート出力
PostgreSQLに変換する際の評価レポート -
データ移行SQLの出力
PostgreSQLで実行可能なINSERT文またはCOPY文の形式によるDMLの出力 -
SQLファイルのコンバージョン
実際のレポート例を出力した例を記載します。
実際に触ったときの手順は今度記事に記載しようと思いますが、今回は特に上記の図の中の「Number」列と「Invalid」に注目してみてください。
Number列は移行元のオブジェクトの総数です。
Invalid列は移行した際に作成できないであろうオブジェクトの数です。
移行に向けて準備する段階で、どれほどの改修が必要になりそうか試算する目的でこのツールを使用するのが良いように思います。
#移行のポイント
##スキーマ移行
オブジェクト定義を含むスキーマ移行を行う場合に、まずはora2pgのような移行支援ツールを使って、Oracle Databaseの定義情報の移行を以下のような順番で行います。
-
抽出
定義情報(DDL,DCL)をOracle Databaseから抽出します。 -
変換
抽出したデータベース・オブジェクト定義(DDL,DCL)を移行先のAzure Database for PostgreSQLに合わせて「ora2pg」等を用いて変換します。 -
作成
変換した定義情報をAzure Database for PostgreSQLへ作成していきます。この時にオブジェクト間の依存関係を考慮に入れて作成する必要があります。依存関係の考慮が出来ない場合には、大量のエラーが発生する可能性がありますが、何回か実行することで依存オブジェクトが徐々に作成されていき、エラーが無くなっていきます。 -
確認
Oracle DatabaseとAzure Database for PostgreSQLでオブジェクトが意図した状態で作成されたか確認します。（作り漏れが無いように）
また、移行支援ツールで変換できなかったオブジェクト類に関しては、手動での変換を行います。システム情報などを参照しているような機能についてはAzure Database for PostgreSQLでも同等のシステム情報を参照できるような機能に変換していきます。
##データの移行
続いてデータの移行方式です。データの移行方式は以下の３パターンが存在します。
-
一括移行
アプリケーションを停止したうえで、Oracle DatabaseからCSV形式などのファイルで出力したデータをAzure Database for PostgreSQLへロードする移行方法
__メリット：__一括での移行になるため、データの漏れなどが発生する可能性が低い。
__デメリット：__データ量に依存するが、長時間のシステム停止をしなければならない。 -
一括移行&差分移行
CSV形式などのファイルで出力した全件データをロードしたのち、定期的に差分データを抽出してターゲットデータベースへロードする移行方法
__メリット：__システムの停止時間を抑えることができる。
__デメリット：__各テーブルごとの差分同期の方式の件との必要がある。 -
レプリケーションツールを活用した移行
データレプリケーションツールを活用した移行方法
__メリット：__システム停止時間を抑えることができる。ツールによる自動移行のため人手をかけずに済む。
__デメリット：__ツールのライセンス費用が掛かる
##アプリケーション移行
データベースを移行しただけでは、システムとして利用できないのため、アプリケーションの移行も必要になってきます。
まずは、Oracleへの接続部分をPostgreSQLへ切り替える必要があります。実行されるSQLなども同様にPostgreSQLへ対応させるように変更を行います。Oracle固有の集計関数や外部結合時に＋表記でかかれているものは書き換えを行います。
また、O/Rマッパーのようなフレームワークをアプリケーションで利用している場合には、フレームワーク側でどの程度、DB変更の影響を吸収できるかを確認することが必要です。
いずれにしても、実際にアプリケーションから接続して一連の処理を行い、想定通りの動きをするかどうか等を確認する必要があります。このテストがプロジェクトの中では最もコストがかかること予想される部分です。
#移行リハーサル～本番移行
基本的には本番移行の前に移行リハーサルを実施する必要があります。移行リハーサルでは実際の本番移行に想定される手番に沿って同じことを行います。移行時の手順を確立させ、本番移行にかかる時間などの計測を行います。また、移行リハーサルと本場移行作業時の作業の差異や違いを明確にする必要があります。
本番移行では、今まで準備してきた手順をもとに実施し、以下のような観点で最終的なチェックを行います。
| 確認項目 | 内容 |
|---|---|
| データロード時のエラー等の確認 | 実行したコマンドのエラーメッセージの有無を確認。 |
| オブジェクト数確認 | オブジェクト数が、移行元データベースの状態と一致するかどうか確認。 |
| データ確認 | テーブル件数が、移行元データベースの状態と一致するかどうか確認。 文字化けが発生していないか等を確認。 |
| アプリケーション接続確認 | アプリケーションから接続して一連の処理を行い、想定通りの動きをするかどうか確認。 |
#最後に
今回は移行支援ツールや移行のポイントについて記載しました。やはり汎用的なやり方はなく、移行対象のシステムにあったやり方を模索する必要がありそうです。
##次回は
実際に移行支援ツールなどを試してみた結果を記載したいと思います。