AWS Schema Conversion Tool、ビルド 616 の新機能紹介

AWS Schema Conversion Tool (AWS SCT) の新しいバージョンを導入することに興奮しています。これには、PostgreSQL10 のパーティショニング、新しいサーバレベルのアセスメントレポート、テーブル値関数のサポートなどをサポートが含まれています。

AWS SCT とは、あるデータベースエンジン上の既存のデータベーススキーマを別のデータベースエンジン用に変換するためのツールです。リレーショナル OLTP スキーマやサポート対象のデータウェアハウス OLAP スキーマを Amazon RDS に変換することができます。たとえば、MySQL や PostgreSQL などと互換性があるため、Amazon Aurora に変換できます。また、リレーショナル OLTP スキーマやサポート対象のデータウェアハウス OLAP スキーマを Amazon Redshift に変換することも可能です。サポートされているすべてのソースとターゲットをドキュメントで検索してください。

以下に、このブログ記事でカバーするトピックの概要を示します：

SCT Assessment Report への変更
- Oracleから Amazon RDS for Oracle
- Microsoft SQL Server から Amazon RDS for SQL Server
テーブル値関数の実装
- SQL Server から PostgreSQL へ
- SQL Server から MySQL へ
次のソースに対する PG10 パーティショニングのサポート：
- Db2 LUW
- Oracle
- SQL Server

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

SCT Assessment Report への変更

Amazon RDS では、特定のサーバーレベルのオブジェクトや Oracle や SQL Server の機能の使用方法が異なることがあります。SCT では、どの機能がサポートされているのかいないのかが簡単に分かるように、ソース、すなわち、Oracle または SQL Server インスタンスで構成されたサーバーレベルのオブジェクトを分析して、新しいサーバーレベルの Assessment Report を作成するようになっています。ソースインスタンスで使用されているサーバーレベルのオブジェクトと機能を識別し、移行対象としてAmazon RDS を選択する場合に、どのくらい自動的に変換できるかを見積もります。

サーバーレベルのオブジェクトに対して Assessment Report を作成するために必要な手順を見てみましょう：

新しいプロジェクトを作成し、ソース（Oracle またはSQL Server）およびターゲット（RDS for Oracle または RDS for SQL Server）に接続します。
接続後、SCT は、左側に見つかったサーバーレベルのオブジェクト表示します。
次に示すように、サーバーレベルのオブジェクトのコンテキスト（右クリック）メニューを開き、[Create Report]を選択します。
サーバーレベルの Assessment Report を確認し、問題を処理し、変換をターゲットに適用します。

Oracle から RDS for Oracle へ

Oracle から RDS for Oracle への変換を見てみましょう。SCTは、ディレクトリオブジェクト、 tablespaces（表領域）、ユーザーロールと権限、仮想プライベートデータベースポリシーなどのサーバーレベルのオブジェクトを分析します。また、ハードウェア構成、およびその他の機能、例えば、ライセンス、RAC および RAC One Node、Data Guard および Active Data Guard、データベースボールト、空間およびロケータ機能、スケジュールや監査などについても調べます。これらの機能がターゲットバージョンでサポートされているかどうかを入力します。

たとえば、Oracle の場合には、データはtablespaces（表領域）に論理的に格納され、物理的には対応する表領域に関連付けられたデータファイルに格納されます。Oracle では、データファイル名を持つ tablespaces（表領域）を作成できます。

一方、Amazon RDS では、データファイル、ログファイル、制御ファイル用の Oracle Managed Files（OMF）をサポートしています。RDS でデータファイルとログファイルを作成するときは、物理ファイル名を指定することはできません。DATAFILE および TEMPFILE 句のファイル名パラメータは、削除する必要があります。

Oracle       
CREATE TEMPORARY TABLESPACE tbs_test_temp
    TEMPFILE 'tbs_test_temp.dat'
    SIZE 5M
    EXTENT MANAGEMENT LOCAL UNIFORM size 1M;       
    
 Oracle RDS  
CREATE TEMPORARY TABLESPACE tbs_test_temp
 TEMPFILE 
/*AI 1512 
RDS は Oracle Managed Files のみをサポートします。カスタムファイル名は RDS に指定できません。
*/
/*'tbs_test_temp.dat'*/
    SIZE 5242880
    FLASHBACK ON 
    EXTENT MANAGEMENT LOCAL
    UNIFORM SIZE 1048576;

次に、Oracle から RDS for Oracle への移行のためのサンプル Assessment Report を示します。

SQL Server を RDS for SQL Server に変換する

SQL Server をソースとして使用すると、SCT はサーバーレベルのオブジェクトを分析します。分析には、インスタンスごとのデータベースの最大数、DB インスタンスの最大サイズ、レプリケーション設定、サービスブローカー、ジョブ、オペレーター、リンクサーバー、バックアップデバイス、アラート、およびエンドポイントの検出が含まれます。この情報を使用して、SCT はサーバーレベルの Assessment Report を生成します。また、ターゲットバージョンで使用できない機能を調べて報告します。

たとえば、Amazon RDS上のSQL Server を実行する各 DB インスタンスに、最大 30 のデータベースを作成できます。ソース DB インスタンスに、さらにデータベースが含まれている場合、SCT はこの制限に関する情報を Assessment Report に表示します。

SQL Server から RDS for SQL Server への変換 Assessment Report のサンプルを示します。

テーブル値関数

SQL Server 2005 以降、テーブル値関数が使用されています。テーブル値関数は、テーブル値を返す関数です。このタイプの関数は、表の代わりに使用することも、SQLステートメント内の別の表と結合することもできます。

テーブル値関数の変換は、お客様からの要望の1つでした。このバージョンの SCT から、SQL Server からPostgreSQL へ、SQL Server から MySQL への移行対応で、この機能がサポートされています。

SCT は、一時テーブルを作成して、インラインテーブル値関数の動作をエミュレートします。以下に、変換を明確にするのに役立つ例をいくつか示します。

以下は、SQL Server から PostgreSQL への例を示しています。以下は、SQL Server から MySQL への例を示しています。

PostgreSQL 10 でのパーティショニングのサポート

パーティションテーブルは、テーブルデータを複数のストレージオブジェクト（データパーティションまたは範囲と呼ばれます）に分割するデータ組織スキーマを使用します。これらは、テーブルの、1つ以上のテーブルパーティションキー列の値に従って分割されます。

バージョン10 から、PostgreSQL は、テーブルをパーティションに分割する方法を指定する手順を提供しています。分割されたテーブルは、パーティションテーブルと呼ばれます。この仕様では、パーティションの方法と、パーティションキーとして使用される列または式のリストで構成されています。現在サポートされているパーティション方法には、範囲とリストがあり、各パーティションには、それぞれ一連のキーとキーのリストが割り当てられています。

PostgreSQL にはテーブル分割のためのいくつかの実装があります：

宣言的パーティショニング（バージョン10 以降で使用可能）
継承を使用した実装

バージョン 615 以降、SCT では、PostgreSQL のパーティショニング機能を、Oracle と SQL Serverrの両方対応でのソースデータベースとしてサポートしています。バージョン 616 から Db2 LUW をサポートしました。

Db2 から PostgreSQL へ

各データベースエンジンでは、さまざまなパーティション方法があります。PostgreSQL は、Oracle、SQL Server、Db2 とは異なる方法でパーティションテーブルを管理します。データベース間のパーティションスキーマの違いを知っていると、AWS SCT がパーティションテーブルを Oracle、SQL Server、Db2 から PostgreSQL に変換する方法を理解するのに役立ちます。

次に、Db2 と PostgreSQL の違いのいくつかを示します：

PostgreSQL は、RANGE パーティションの NULL 値をサポートしていません。
Db2 には、範囲境界値に対応する、INCLUSIVEおよびEXCLUSIVEという特別な句があります。これらには、この境界を含むデータパーティションに値を含めるかどうかを設定します。 PostgreSQL では、開始境界では INCLUSIVE、終了境界では EXCLUSIVE のみをサポートしています。
Db2 を使用すると、パーティションテーブルのプライマリキーまたはユニークキーを作成できます。PostgreSQL では、各パーティションのプライマリまたはユニークキーを直接作成します。
Db2 を使用すると、パーティションテーブルとの間で外部キー制約を作成できます。PostgreSQL の場合、パーティションテーブルを参照する外部キーはサポートされていません。パーティションテーブルから別のテーブルへの外部キー参照もありません。
Db2 を使用すると、パーティションテーブルのインデックスおよび行トリガーを作成できます。PostgreSQL では、各パーティションに対してインデックスと行トリガを直接作成します。

次は、SCT が Db2 のパーティションテーブルをPostgreSQL に変換する方法の例です。

次では、単一列の範囲パーティションを示しています。次に、複数列範囲のパーティションを示します。

Oracle から PostgreSQL へ

Oracle と PostgreSQL 間のパーティションスキーマの違いは次のとおりです：

Oracle では、範囲パーティションとサブパーティションの上限のみが設定されます。PostgreSQL では、両方の境界を設定する必要があります。
日付範囲の場合、PostgreSQL はバインドされた値のリテラルのみをサポートします。したがって、Oracle からのすべてのバウンド値を適切なテキストリテラルに変換する必要があります。
Oracleでは、パーティション境界にDEFAULT特殊値を使用して、未指定の値をそのパーティションまたはサブパーティションに直接格納できます。PostgreSQL はこの機能をサポートしていません。
Oracleでは、NOT NULL 制約なしで列ごとにテーブルをパーティション化できます。その場合、すべての NULL 値は一番右側のパーティションに移動します。PostgreSQL はこのような方法をサポートしていません。
Oracle を使用すると、パーティションテーブルとの間で外部キー制約を作成できます。PostgreSQL の場合、パーティションテーブルを参照する外部キーはサポートされていません。パーティションテーブルから別のテーブルへの外部キー参照もありません。
Oracle では、あるパーティションの列値を変更することで、あるパーティションから別のパーティションに行が移動する場合に、パーティション間でデータを移動できます。しかし、この場合は、行の新しい値が元のパーティションの暗黙的なパーティション制約を満たさない可能性があるため、PostgreSQL は失敗する可能性があります。

次は、Oracle パーティションテーブルをPostgreSQL へ自動変換する例です。

次に示すのは、リストのパーティションです。.

次に示すのは、範囲のパーティションです。

SQL Server から PostgreSQL へ

SQL Server の場合、パーティションは、パーティション機能を使用して構築されます。各関数について、作成されるパーティションの数はn + 1に等しくなります。値を順に並べる必要はありません。値が順序どおりでない場合、データベースエンジンはそれらをソートします。

PostgreSQL はリテラルのみを境界値の値としてサポートしています。元の日時境界値は、適切なテキストリテラルに変換されます。

SQL Server と PostgreSQL 間のパーティションスキーマの違いは次のとおりです：

PostgreSQL は上限に対する INCLUSIVE ロジックをサポートしていません。
SQL Server を使用すると、NOT NULL 制約なしで列ごとにテーブルをパーティションできます。その場合、すべての NULL 値は一番左のパーティションに移動します。PostgreSQL は、範囲パーティションのための　NULL 値をサポートしていません。
SQL Server では、パーティションされたテーブルのプライマリキーまたはユニークキーを作成できます。PostgreSQL では、各パーティションのプライマリまたはユニークキーを直接作成します。
SQL Server を使用すると、パーティションテーブルとの間で外部キー制約を作成できます。PostgreSQL の場合、パーティションテーブルを参照する外部キーはサポートされていません。パーティションテーブルから別のテーブルへの外部キー参照もありません。
SQL Server では、パーティションされたテーブルのインデックスを作成できます。PostgreSQL の場合、インデックスは各パーティションに対して直接作成する必要があります。インデックスは、親テーブルから削除する必要があります。

結論

この記事の前半で説明した機能に加えて、ビルド 616 は、その他のUIの改善がされています。リリースノートページで、すべての機能リストにアクセスできます。

新しいサーバーレベルの Assessment Report により、スキーマの変換と RDS への移行をより簡単に行えると、当社では確信しております。パーティショニングのサポートは、パーティションテーブルを PostgreSQL に移行するために必要な手作業の量を削減するのにも役立ちます。

いつものように、コメント欄に質問やフィードバックを、ご遠慮することなくお寄せください。楽しんで「移行作業」をしましょう！

著者について

Ramya Kaushik は、アマゾンウェブサービスの Database Migration Service (DMS) & Schema Conversion Tool (SCT) チームでデータベースエンジニアを務めています。

Amazon Web Services ブログ