AWS Schema Conversion Tool (AWS SCT) は、データベースエンジン間で既存のデータベーススキーマを変換するのに役立ちます。リレーショナル OLTP スキーマまたはサポートされているデータウェアハウス OLAP スキーマから、Amazon RDS (たとえば、Amazon Aurora MySQL または Amazon Aurora PostgreSQL など) に変換できます。また、リレーショナル OLTP スキーマまたはサポートされているデータウェアハウス OLAP スキーマを Amazon Redshift に変換することもできます。サポートされているすべてのソースとターゲットについては、AWS のドキュメントを参照してください。

AWS SCT は 頻繁に更新されるツールの 1 つであり、新機能を組み込んだビルドがほぼ毎月リリースされます。機能リリースごとにリリースノートを提供していますが、それに加えて AWS SCT リリースのブログシリーズを開始し、各ビルドの重要な新機能を詳しく紹介していきます。

ロードマップはお客様の要望に基づいて構築されます。AWS SCT ユーザーとして、AWS SCT の新機能を確認したい場合は、こちらのブログ記事に自由にコメントしてください。お客様からのフィードバックをお寄せいただければ幸いです。また、AWS SCT 自体にフィードバックを残すこともできます (ヘルプに移動して [Leave feedback] を選択します)。

この記事では、本日リリースしたビルド 613 に含まれるいくつかの新機能を紹介します。このブログ記事で紹介する機能は次のとおりです。

• Oracle から PostgreSQL への変換 – SQL スクリプトファイルの変換
• Oracle から PostgreSQL への変換 – EXECUTE IMMEDIATE、DBMS_SQL、カーソルに関する動的 SQL 変換の改善
• ソースとしての Microsoft SQL Server に対する Microsoft Windows 認証のサポート
• Greenplum から Amazon Redshift への変換 – 組み込み SQL 関数の Amazon Redshift スカラー SQL UDF への変換

上記のリストに示した新機能は、ビルド 613 に含まれる機能の一部に過ぎません。完全なリストについては、リリースノートの該当セクションを参照してください。

Oracle から PostgreSQL への変換 – SQL スクリプトファイルの変換

AWS SCT の以前のビルドでは、評価レポートを作成し、テーブル構造、インデックス、関数などの Oracle データベースオブジェクトを PostgreSQL に変換することができました。しかし、ほとんどのエンタープライズデータベース管理者は、管理や保守などの日常業務に SQL スクリプトも使用しています。通常、こうした SQL スクリプトは、ソフトウェアプロジェクトの一環として作成されたスタンドアロンの SQL ファイルです。総所有コストを削減するためにデータベースエンジンを変更する場合、こうした SQL スクリプトも変換する必要が生じます。

実際のところ、このような変換についてはお客様から多数の要望がありました。お客様の要望は、現在サポートされているデータベースオブジェクトに対して AWS SCT が提供している SQL スクリプトを評価および変換できるメリットを、前述のような SQL スクリプトでも享受することでした。

ビルド 613 では、Oracle から PostgreSQL への変換でこの機能を AWS SCT に組み込みました。例を見てみましょう。[]

スタンドアロンの SQL スクリプトを変換する手順

1. Oracle から PostgreSQL への変換の新規プロジェクトを作成します。
2. Oracle および PostgreSQL のエンドポイントに接続します。
3. ソースツリー内のすべてのノードのチェックを外します。
4. SQL スクリプトノードのコンテキスト (右クリック) メニューを開き、[Load Scripts] を選択します。
5. すべての SQL スクリプトを含むフォルダを選択します。
6. SQL スクリプトノードのコンテキスト (右クリック) メニューを再度開き、[Convert Script] を選択します (データベースオブジェクトを変換するときと同じです)。
7. 評価レポートをレビューし、変換を適用します。

変換された Oracle のサンプル HR スキーマスクリプトと評価レポートの例を次に示します。

Oracle から PostgreSQL への変換 – 動的 SQL 変換の改善

動的 SQL は、実行時に SQL ステートメントを生成して実行するプログラミング技法です。データベース定義言語 (DDL) のステートメントを実行する必要があるプログラムを作成する場合に便利です。また、SQL ステートメントの全文またはその入出力変数の数やデータ型がコンパイル時にわからない場合にも便利です。

PostgreSQL の動的 SQL の用語は、Oracle とは異なるルールのセットに従います。場合によっては、こうした動的 SQL ステートメントを変換する構文と方法は、データベースのバージョンによって異なります。このビルドでは、Oracle から PostgreSQL への複雑な動的 SQL の変換率を改善しました。さまざまな種類の動的 SQL のバージョンの相違と構文の相違を考慮し、動的 SQL を PostgreSQL に正しく変換するために役立てています。

例を見てみましょう。

古いバージョンの Oracle では、PL/SQL ブロックで decode ステートメントが使用されていました。この関数は、Oracle では結局 case ステートメントに置き換えられました。AWS SCT ビルド 613 の拡張では、このような相違をピックアップして、decode ステートメントを PostgreSQL の case ステートメントに変換することができます。以前のビルドと同様に、AWS SCT Oracle 拡張パックの to_char() 関数による変換を使用できます。拡張パックの使用方法の詳細については、AWS のドキュメントを参照してください。

単純な動的 SQL 変換の例をもう 1 つ見てみましょう。ご覧のように、PostgreSQL では関数の引数を宣言する必要があります。AWS SCT は、ソースの Oracle ディクショナリを介して自動的にそれらの引数タイプを識別し、Oracle から PostgreSQL への完全な変換を呈示します。

このブログシリーズでもっと多くの拡張を確認したい場合は、この記事の最後にコメントしていただくか、AWS SCT を通じてフィードバックをお寄せください。

ソースとしての SQL Server に対する Windows 認証のサポート

以前は、AWS SCT で SQL Server エンドポイントを使用する場合は、SQL 認証のみが使用可能でした。SQL Server は、Windows 認証と呼ばれる LDAP/Active Directory ベースの認証もサポートしています。今回のリリースでは、AWS SCT は Windows 認証による SQL Server エンドポイントへの接続もサポートしています。

この新機能を使用するのは簡単です。次のスクリーンショットに示すとおり、SQL Server エンドポイントに接続するときに Windows 認証を選択するだけです。

Greenplum から Amazon Redshift への変換 – 組み込み SQL 関数の Amazon Redshift スカラー SQL UDF への変換

Amazon Redshift では、SQL SELECT 句または Python プログラムのいずれかを使用して、カスタムのユーザー定義スカラー関数 (UDF) を作成できます。新しく作成された関数はデータベースに格納され、ログインしたユーザーが Amazon Redshift で持っている権限に基づいて使用できます。

ビルド 613 以降、Greenplum から Amazon Redshift への OLAP データベースオブジェクトの変換は、SQL 関数から Amazon Redshift のスカラー SQL UDF への変換をサポートします。スカラー SQL UDF には、関数が呼び出されたときに実行されて単一の値を返す SQL SELECT 句が組み込まれています。この変換では、Amazon Redshift のすべてのベストプラクティスとルールが考慮されます。また、この変換では、SQL 関数変換の評価レポートが表示され、変換後の SQL が Amazon Redshift に適用される前に表示されます。Amazon Redshift のスカラー SQL UDF の作成の詳細については、Amazon Redshift のドキュメントを参照してください。

ここで挙げた機能に加えて、ビルド 613 では他にも多くの機能拡張が提供されます。その中には、カスタム型のマッピングの改善、AWS プロファイル設定の拡張、Oracle から PostgreSQL への連想配列変換のサポートなどがあります。

これまでと同様、AWS SCT が自動的に変換できないオブジェクトは評価レポートに表示されます。ターゲットエンドポイントで変更を適用する前に、評価レポートを確認することをお勧めします。評価レポートには、自動的に変換できないオブジェクトが表示されるだけではありません。ターゲットエンジンのベストプラクティスに基づいて特定のオブジェクトを変換する方法に関する情報のリンクも含まれています。

結論

このブログ記事の締めくくりとして、さまざまなチャネルを通じてお客様からフィードバックをいただいたことと、そうしたご要望をもとに変換率を改善できたことに感謝したいと思います。このブログシリーズをもう 1 つのチャネルとして活用し、フィードバックを収集して変換率をさらに改善したいと考えています。このシリーズを通して、AWS のオープンソースデータベースの真の可能性をお客様に実感していただければ幸いです。

変換について特別な要望がある場合は、このブログ記事にコメントをお寄せください。できるだけ早くお答えいたします。

お客様の将来の移行が成功しますように!

著者について

Arun Thiagarajan は、アマゾン ウェブ サービスの Database Migration Service (DMS) & Schema Conversion Tool (SCT) チームでデータベースエンジニアを務めています。 彼は、データベースの移行に関する課題に取り組み、お客様と緊密に協力して DMS サービスの真の可能性を実現するのを支援しています。DMS と SCT を使用して 100 種類のデータベースを AWS クラウドに移行するのを手伝ってくれました。