Insight Database Testing と AWS SCT と連携して移行アセスメントをさらに省力化 ( パート 2 アセスメント編 )

こんにちは。インサイトテクノロジーの松尾です！

本ブログは、本ブログでは、Insight Database Testing と AWS SCT を組み合わせて、移行アセスメント、および SQL の修正確認を行う手順を紹介している、Insight Database Testing と AWS SCT と連携して、OracleからRDS for PostgreSQLへの移行アセスメントを省力化 ( パート 1 準備編 ) の続編です。事前の準備については、( パート 1 準備編 ) を参照してください。

なお、本ブログでは製品自体の詳細な説明などは行っておりません。Insight Database Testing については製品ページ:Insight Database Testingとは？等を参照してください。画面の詳細な説明については、Insight Database Testing マニュアルを参照してください。

本ブログで説明する手順の流れ

本ブログで説明する手順は、以下の流れに従います ( 順序が前後しても問題ない場合もあります ) 。

( パート 2 アセスメント編 ) では、以下の流れのターゲット DB の登録から説明します。

移行先データベースの準備
- ( AWS SCT ) AWS SCT のインストール
- ( AWS SCT ) AWS SCT の接続
- ( AWS SCT ) 移行先データベース ( Amazon RDS for PostgreSQL ) にテーブルを作成
SQL アセスメントの実行
- ( PISO Manager ) 評価 SQL セットの作成 ( PISO Manager からマイニングサーチ実行時に作成 ) ( ↑ここまで、パート 1 にて実施 )
- ( Insight Database Testing ) ターゲット DB の登録
- ( Insight Database Testing ) アセスメントの実行
AWS SCT での SQL 修正と再アセスメント
- ( Insight Database Testing ) 失敗 SQL のダウンロード
- ( AWS SCT ) 失敗 SQL の取り込み
- ( AWS SCT ) SQL の変換と保存
- ( Insight Database Testing ) 保存した SQL を修正 SQL セットとして登録
- ( Insight Database Testing ) 再度アセスメントを実行

SQL アセスメントの実行

評価 SQL セットの作成まで終了しましたので、次に、テスト対象のデータベースであるターゲット DB の登録を行います。

今回のテストでは、移行元の Oracle に相当するテスト用データベースも用意し、SQL の実行可否だけでなく、クエリの実行結果の比較も行う構成でアセスメントを行います ( テスト用の Oracle Database を用意せずに、SQL の実行可否の確認だけを行うことも可能です ) 。なお、テスト用のデータベースを2つ用意して結果比較を行う場合には、両方のデータベース内のデータもそろえておく必要があります。

( Insight Database Testing での操作 ) ターゲット DB の登録

SQL のテストを行う対象のデータベースを “ターゲット DB” として登録します。

Insight Database Testing の上部メニューから、ターゲット DB を選択し、新規作成を選びます。
ターゲット DB 名を入力し、データベースを PostgreSQL としたうえで、必要な情報を入力します。ホスト名には、Amazon RDS for PostgreSQL のエンドポイント情報を入力し、ユーザー名とパスワードを入力して、ターゲット DB への接続が可能であることを確認したうえで、ターゲット DB を作成します。
RDS for PostgreSQL と同様に、Oracle Database の情報もターゲット DB として登録します。接続識別子には tnsnames.ora ファイルを編集して登録するか、または (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxx.xxx.xxx)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=pdb1))) のような接続文字列を直接記載することも可能です。

( Insight Database Testing での操作 ) アセスメントの実行

評価 SQL セットを作成し、ターゲット DB の準備ができたら、SQL 文のアセスメント ( 評価 ) を実行します。

Insight Database Testing の上部メニューから、アセスメントを選択し、新規作成を選びます。適当なアセスメント名を設定し、作成した評価 SQL セットを選択します。次に、”テスト用ソースDBにもSQLを実行します” を有効にし、テスト用ソースDBには Oracle Database を登録したターゲット DB を選択し、ターゲット DBの方には、RDS for PostgreSQL のターゲット DB 選択します。接続情報のユーザー名に対してパスワードを入力し、テスト接続を実行することで接続が可能であることを確認します ( 接続ができないと評価を行うことができず、全てエラーとなります ) 。さらに、”実行タイプ” には「実行」を選択し、”高度な比較設定” で「カラム名の比較をしない」を有効にし、アセスメントを実行します。
アセスメントの一覧から実行したアセスメントのアセスメント名をクリックすると、実行したアセスメントの概要情報を確認することができます。今回のアセスメントでは、1 件成功し、1 件失敗したことがわかります。
エラーメッセージなどをクリックし、失敗した SQL を SQL 詳細画面で確認することができます。SQL 詳細画面では、失敗した SQL 文の内容を確認したり、移行情報として移行元データベースが Oracle Database の場合に、非互換の SQL 構文情報を表示することができます。今回の例では、非互換の構文として、外部結合演算子が検出されていることがわかります。
また、同様に、結果が異なる SQL については、SQL を実行した際の取得結果を比較して結果が異なったものを検出します。取得結果については、”結果取得” タブにて確認できます。ちなみにこの結果は、Oracle と PostgreSQL の違いあるあるですが、”1/3″ の演算が、Oracle だと “0.3333….” と評価されるのに対して、PostgreSQL だと整数演算として “0” と評価されるものです。

ここまでで、移行元データベースで実行され、収集・蓄積された SQL の、移行先データベースでの評価を行うことができました。エラーとなった SQL については、エラーの内容を確認し、修正方法について確認のうえ、アプリケーションコードの修正を行います。

構文エラーとなる SQL が大量にある場合、人手による確認と修正確認では大変です。以降では、SQL の修正を AWS SCT を使って行う方法を紹介します。

AWS SCT での SQL 修正と再アセスメント

Insight Database Testing では失敗した SQL を AWS SCT に連携し、AWS SCT により SQL 修正を行った後、修正した SQL を Insight Database Testing に取り込んで再アセスメントを行うことが可能です。

( Insight Database Testing での操作 ) 失敗 SQL のダウンロード

AWS SCT へ取り込むため、Insight Database Testing から SQL を取得します。

アセスメントのサマリー画面のメニューから、ツール連携 – SQL の抽出を選択します。成功した SQL も含めてダウンロードするか、失敗した SQL のみをダウンロードするかを選択しダウンロードを実行します。アセスメントの名称の zip ファイルがダウンロードされます。
ダウンロードした zip ファイルは、この後 AWS SCT から参照するので、参照しやすいディレクトリに展開しておきます。

( AWS SCT での操作 ) 失敗 SQL の取り込み

ダウンロードした SQL を AWS SCT で読み込みます。

AWS SCT のメニューから Applications – New Generic Application を選択します。
New generic application conviersion projectで、Location には、適当なフォルダを指定します。また、Language に Any を選択し、移行元データベースのスキーマを選びます。Target parameter style は AWS SCT で変更することもできますが、IDT Manager でも変換して実行する機能があるため、ここでは Same as in source にしておきます。
OK をクリックした後、File メニューから、ダウンロードしたファイルを展開したフォルダを指定すると、ファイルを確認することができます。

( AWS SCT での操作 ) SQL の変換と保存

失敗した SQL について、AWS SCT で一つずつ確認しながら変換を行い保存することも可能ですが、ここでは、一括で変換する方法を紹介します。

開いてるフォルダの元のフォルダを選択し、メニューの Actions から Convert を選択します。すると、含まれる全 SQL に対しての変換結果が下部に表示されます。
下部のアイコンから Save as CSV を選択すると、変換結果が CSV ファイルに保存されます。

( Insight Database Testing での操作 ) 保存した SQL を修正 SQL セットとして登録

AWS SCT で変換したファイルを IDT Manager へ取り込みます。

IDT Manager のメニューから修正 SQL セットを選択し、新規作成を選択します。”外部ツールで変換した SQL 情報から作成” を選択し、AWS SCT で保存した CSV ファイルを選択します。
新規作成を選択すると、修正 SQL セットが選択されます。中身を確認すると、AWS SCT で変換された SQL が登録されていることを確認できます。

( Insight Database Testing での操作 ) 再度アセスメントを実行

評価 SQL セットと修正 SQL セットを使って、再度アセスメントを行います。

最初にアセスメントを行ったのと同じ手順で、アセスメントを実行しますが、アセスメントの画面で、”修正した SQL を適用します” を有効にし、”ターゲット DB に使用する修正 SQL セット” に、作成した修正 SQL セットを登録します。他のオプションは先の実行時と同様にします。
今回のアセスメントでは 1 回目のアセスメントで存在した “失敗した SQL” がなくなりました。
SQL の詳細を確認すると、修正された SQL が実際に評価されて、成功となったことが確認できます。
まだ残っている、結果が異なる SQL についても確認してみます。こちらの方は、AWS SCT による変換で、”0.3333….” と演算されていることが確認できましたが、Insight Database Testing で結果の比較を行う際に文字列化しており、その際の小数点以下の桁数の違いで結果の差異が生じていることがわかりました。こちらについてはこのまま無視できるものとして扱ってもいいですし、Insight Database Testing で結果が同じとみなされるよう文字列化して取得するような SQL に書き換えることなども対応としては考えられます。

おわりに

ここまで、Insight Database Testing と AWS SCT を用いて、評価の準備や評価の実行、さらに AWS SCT で SQL を修正しての再評価の手順を説明しました。データベース移行にあたっては、SQL の実行可否だけではなく、結果が同じになることや性能なども確認する必要が出てきます。結果を確認するためにはテスト用のデータベースの準備が煩雑になってくる部分はありますが、データベース移行にともなう SQL の確認を、ツールの活用で簡単に行えることを確認いただけたのではないかと思います。

Insight Database Testing をまだご利用いただいていない方で実際に試されたい場合は、製品の説明やデモ、トライアルなどについてInsight Database Testingに関するお問い合わせよりお問い合わせいただければと思います。

今後も Insight Database Testing の活用方法や、関連するトピックなどをこのブログでどんどん紹介していきますので、どうぞお楽しみに！

2022/2/28 追記

Insight Database Testing 3.1 のリリースに伴い、画像の差し替えおよび手順を更新しました。

Insight Database Testing と AWS SCT を連携して移行アセスメントをさらに省力化 ( パート 1 準備編 ) ローカルマシンにインストールせずにコマンド SQL クライアントを使う( PostgreSQL / MySQL 編 )