翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

フェーズ 3: 移行

データベース移行の主なタスクは、最小限のダウンタイムで移行を完了することです。どちらのデータベースも同じプログラミング言語と通信プロトコルを使用する必要があるため、同様のクエリ構文、プロシージャ、関数のコードとスキーマを変換する必要がある場合があります。スキーマを変換するときは、次の点を考慮してください。

SAP ASE データベースや Amazon RDS for SQL Server などのスキーマコード変換には、任意のサードパーティーの移行ツールを使用できます。ANSI 以外の SQL は SQL Server でサポートされていないため、一部のコードを手動で変換する必要がある場合があります。

コードを変換したら、アプリケーションコードまたは動的 SQL アプリケーションを変換し、ユニットテストと機能テストを実行します。詳細については、「移行されたデータベースオブジェクトのテスト (SybaseToSQL)」を参照してください。

データの変換

raw データを変換して、クリーニング、標準化、検証、ソートを行うことで、より便利になります。データベース移行では、抽出、変換、ロード (ETL) プロセスは次の方法で使用されます。

ETL ツールの例には AWS Glue、、Informatica、Talend などがあります。SAP ASE から SQL Server への移行では、一部の無料ツールでストアドプロシージャと関数を自動的に変換できます。

データベースオブジェクトの検証

データベースを検証すると、以降の移行段階での問題を防ぐことができます。コード変換後、SAP ASE と RDS SQL Server の間で次の要素を比較して、データベーススキーマを検証します。

各オブジェクトが正しく移行されたことを確認します。違いが見つかった場合は、失敗の理由を特定します。ターゲットデータベースに欠落しているオブジェクトを手動で作成するか、Transact-SQL コードを変換する必要がある場合があります。詳細については、「SAP ASE から Amazon RDS for SQL Server または Microsoft SQL Server に移行した後のデータベースオブジェクトの検証」を参照してください。

を使用したデータの移行 AWS DMS

複数のデータベースユーザーがいる場合は、スケジュールに従ってアプリケーションを移行する必要がある場合があります。データベースのサイズと移行ウィンドウに応じて、このようなデータ移行には全ロードと増分ロードに関する知識が必要です。このため、 AWS DMS はソースデータベースとターゲットデータベースを接続して、次のプロセスに従ってデータベースコンテンツをレプリケートできます。

特定のデータ型を処理する AWS DMS ために を最適化する必要がある場合があります。詳細については、「SAP ASE データベースをソースとして使用する AWS DMS」を参照してください。

オフラインデータの移行

AWS Storage Gateway を使用して、SAP ASE データベースを Amazon Simple Storage Service (Amazon S3) と統合できます。Amazon S3 は、オンプレミスの SAP ASE データベースバックアップにコスト効率が高く、スケーラブルで安全なストレージを提供します。詳細については、「 を使用して SAP ASE データベースを Amazon S3 に統合する AWS Storage Gateway」を参照してください。

サードパーティー製ツールの使用

一部のアプリケーションは、他のアプリケーションとインターフェイスする単一のコンタクトポイント (SPOC) として機能します。SQL Server データベースプラットフォームに移行すると、これらの相互接続が影響を受ける可能性があり、データベースモニタリングにはサーバー固有の通信プロトコルを使用するネイティブまたはサードパーティーのツールが必要になる場合があります。これらの依存アプリケーションとツールが既に SQL Server をサポートしているかどうか、または適切に機能するために変更が必要かどうかを評価することが重要です。

パッケージ化されたアプリケーションの場合は、ベンダーに問い合わせて、Amazon RDS for SQL Server をサポートしているかどうかを確認してください。カスタムアプリケーションの場合、移行されたデータベースとの互換性を確保するためにコードを変更する必要がある場合があります。

データベースのモニタリング

選択した移行パスに関係なく、Amazon CloudWatch は CPU タイプ、メモリ、I/O 関数などのメトリクスを収集する役割を果たします。また、メトリクスのしきい値を設定し、しきい値がトリガーされたときにアクションを開始することもできます。

例えば、Amazon RDS クラスターメトリクス、通知、アクションのアラームを作成して、未使用または十分に活用されていないリーダーインスタンスを検出してシャットダウンできます。メトリクスとイベントにアラームを設定すると、ダウンタイムとビジネスへの影響を最小限に抑えることができます。Amazon S3、Amazon RDS Performance Insights、Amazon CloudWatch、 AWS のサービス など AWS CloudTrail は RDS データベースプラットフォームと既に統合されているため、パフォーマンスをモニタリングすることをお勧めします。

データの検証

SAP ASE から Amazon RDS for SQL Server へのデータ移行が完了したら、データを検証して正確性と一貫性を確保します。次の SQL クエリを使用して、データベース内の各テーブルのメタデータステートメントを生成します。

ステップ 1: メタデータステートメントと列リストを生成する

SELECT dt.schema_name, dt.table_name,
    STRING_AGG(dt.column_name, ',') AS column_name,
    STRING_AGG(dt.cname, ',') AS column_order
FROM (
    SELECT 
        object_name(a.id) AS table_name,
        a.name colname,
        c.name col_type,
        a.isnullable,
        a.name AS cname,
        schema_name(b.uid) AS schema_name,
        CASE 
            WHEN a.isnullable = 1 THEN
                CASE 
                    WHEN c.name LIKE '%char%' 
                        THEN 'coalesce(ltrim(rtrim('+a.name+')),''X'') as '+a.name
                    WHEN (c.name LIKE '%int%' OR c.name = 'numeric') 
                        THEN 'coalesce('+a.name+',0) as '+a.name
                    WHEN c.name IN ('decimal','float','money') 
                        THEN 'coalesce('+a.name+',0.0) as '+a.name
                    WHEN c.name LIKE 'datetime%' 
                        THEN 'coalesce(convert(nvarchar(30),'+a.name+',112),''99991231'') as '+a.name
                    ELSE a.name 
                END
            WHEN c.name LIKE 'datetime%' 
                THEN 'coalesce(convert(nvarchar(30),'+a.name+',112),''99991231'') as '+a.name
            WHEN c.name LIKE '%char%' 
                THEN 'coalesce(ltrim(rtrim('+a.name+')),''X'') as '+a.name
            ELSE a.name
        END AS column_name
    FROM syscolumns a
    INNER JOIN sysobjects b
        ON a.id = b.id 
        AND b.type = 'U'
    INNER JOIN systypes c
        ON a.usertype = c.usertype
        AND a.xusertype = c.xusertype
        AND c.name != 'varbinary'
    INNER JOIN (
        SELECT 
            OBJECT_NAME(ic.OBJECT_ID) AS table_name,
            COL_NAME(ic.OBJECT_ID, ic.column_id) AS column_name
        FROM sys.indexes AS i
        INNER JOIN sys.index_columns AS ic
            ON i.OBJECT_ID = ic.OBJECT_ID
            AND i.index_id = ic.index_id
            AND i.is_primary_key = 1
    ) pk
        ON pk.table_name = object_name(a.id)
        AND pk.column_name = a.name
) dt 
GROUP BY dt.schema_name, dt.table_name;

次の表に、出力の例を示します。

ステップ 2: メタデータ結果を使用して比較クエリを生成し、SELECT ステートメントを作成する

SELECT <column_name>
FROM [schema_name].[table_name]
ORDER BY <column_order>;

生成されたクエリの例を次に示します。

SELECT BusinessEntityID, AddressID, AddressTypeID
FROM [Person].[BusinessEntityAddress]
ORDER BY BusinessEntityID, AddressID, AddressTypeID;

ステップ 3: 検証

ステップ 4: 行数を検証する

SELECT COUNT(1) AS total_rows
FROM [schema_name].[table_name];

ステップ 5: 新しいデータベースを指すようにアプリケーションの設定を更新する

移行のテスト

テストプロセスは、誤って変換されたクエリやインデックスの欠落など、開発中に見落とした問題を特定するのに役立ちます。また、ワークロードのパフォーマンスに基づいてデータベースエンジンのチューニングやクエリの変更が必要になる場合があります。

アプリケーションワークフローのユニットテストを含む機能テストは、新しいデータベースとのシームレスな統合を確保するのに役立ちます。パフォーマンステストは、許容可能な応答時間を検証し、ボトルネックを特定することで、データベースを最適化するのに役立ちます。

手動テストと自動テストの両方の方法がありますが、特に追加のテストサイクルでは、より効率的であるため、自動方法をお勧めします。