SQL Server ソースの移行ソリューションの概要
特定の移行ソリューションに関する考慮事項と制限事項を確認してください：
SQL Server から SQL Server への移行
タイプ | 説明 |
ソースデータベースの制限 | 帯域幅の要件：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行の速度に影響が出ます。 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが出現する可能性があります。 テーブルレベルのオブジェクトを移行し、マッピングテーブルや列名などで編集する必要がある場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 個です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合は、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。 1 つのデータ移行タスクでサポートされるデータベースは最大 10 個です。この制限を超えると、安定性やパフォーマンスの問題が発生する可能性があります。この場合は、データベースを複数の移行タスクに分割してください。 データベース全体ではなく特定のオブジェクトを移行するタスクを設定した場合、同じ名前でスキーマ名が異なるテーブルを同じターゲットデータベースに移行することはできません。 増分移行の場合、データログは次の要件を満たす必要があります： ログが有効になっている必要があります。バックアップモードはフルに設定する必要があります。完全物理バックアップが正常に実行されている必要があります。 増分移行タスクの場合、Data Transmission Service (DTS) では、ソースデータベースのデータログを 24 時間以上保持する必要があります。完全移行と増分移行の両方を含むタスクの場合、DTS では、ソースデータベースのデータログを 7 日間以上保持する必要があります。完全移行の完了後、ログの保存期間を 24 時間以上に変更できます。そうでない場合、DTS がデータログを取得できず、DTS タスクが失敗する可能性があります。極端なケースでは、データ不整合やデータ損失が発生する可能性があります。必要な期間よりも短いログ保存期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。
ソースデータベースから移行するテーブルの変更データキャプチャ (CDC) を有効にするには、次の条件を満たす必要があります。そうでない場合、事前チェックは失敗します。 sys.sysservers ビューの srvname フィールドの値は、SERVERPROPERTY 関数の戻り値と同じである必要があります。 ソースデータベースが自己管理型の SQL Server インスタンスの場合、データベース所有者は sa である必要があります。ソースデータベースが RDS for SQL Server インスタンスの場合、データベース所有者は sqlsa である必要があります。 ソースデータベースが Enterprise Edition の場合、SQL Server 2008 以降である必要があります。 ソースデータベースが Standard Edition の場合、SQL Server 2016 SP1 以降である必要があります。 ソースデータベースが SQL Server 2017 (Standard または Enterprise Edition) の場合、データベースのバージョンをアップグレードしてください。
DTS は fn_log 関数を使用してソースデータベースのログを取得します。この関数にはパフォーマンスボトルネックがあります。ソースデータベースのログを早めにクリアしないでください。そうしないと、DTS タスクが失敗する可能性があります。 ソースデータベースの操作制限： 初期スキーマ同期および完全なデータ移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。 完全なデータ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベース間でデータ不整合が発生します。リアルタイムのデータ整合性を確保するには、初期スキーマ同期、完全なデータ移行、および増分移行を選択してください。
ソースデータベースが読み取り専用インスタンスの場合、DDL 操作は移行できません。 ソースデータベースが Azure SQL Database の場合、1 つの DTS インスタンスで移行できるデータベースは 1 つだけです。 ソースデータベースが RDS for SQL Server インスタンスであり、移行タスクに増分移行が含まれる場合、DTS インスタンスの安定性を確保するために TDE (透過的データ暗号化) を無効にしてください。詳細については、「TDE の無効化」をご参照ください。 初期スキーマ同期タスクが実行される前に、ソースデータベースで sp_rename コマンドを使用してストアドプロシージャなどのオブジェクトの名前を変更すると、タスクが期待どおりに動作しないか、失敗する可能性があります。
説明 データベース内のオブジェクトの名前を変更するには、ALTER コマンドを使用してください。 ハイブリッドログ解析モードでは、10 分未満の間隔でソースデータベースの列を追加または削除する複数の操作を連続して実行することはできません。たとえば、次の SQL 文を連続して実行すると、タスクはエラーを報告します。 ALTER TABLE test_table DROP COLUMN Flag;
ALTER TABLE test_table ADD Remark nvarchar(50) not null default('');
ソースデータベースが Web Edition の RDS for SQL Server インスタンスの場合、タスクを設定する際に SQL Server 増分同期モード を ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) に設定する必要があります。 完全なデータ移行中は、ソースデータベースで READ_COMMITTED_SNAPSHOT トランザクション処理モードパラメーターが有効になっていることを確認してください。これにより、共有ロックがデータ書き込みに影響を与えるのを防ぎます。そうでない場合、データ不整合やインスタンスの障害などの例外が発生する可能性があります。この問題に起因する例外は、DTS SLA の対象外です。
|
その他の制限 | `CURSOR`、`ROWVERSION`、`SQL_VARIANT`、`HIERARCHYID`、`POLYGON`、`GEOMETRY`、`GEOGRAPHY` データ型のデータは移行できません。 ターゲットデータベースの `TIMESTAMP` データ型のフィールドにデータを書き込めない場合、DTS は完全移行と増分移行をサポートしません。これにより、データの不整合やタスクの失敗が発生する可能性があります。 ソースデータベースからトリガーを移行するには、タスクに使用されるデータベースアカウントにターゲットデータベースに対する Owner 権限が必要です。 オブジェクト設定 ステージで SQL Server 増分同期モード に ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) を選択した場合、移行対象のテーブルにはプライマリキー列を含むクラスター化インデックスが必要です。移行対象のテーブルは、ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列のあるテーブル、またはスパース列のあるテーブルであってはなりません。混合ログ解析モードでは、これらの制限は適用されません。 オブジェクト設定 ステップで SQL Server 増分同期モード を クラスター化テーブルはログ解析で増分同期し、ヒープテーブルの場合は CDC で増分同期します (ハイブリッド式ログ解析) に設定した場合、次の制限も適用されます: DTS による増分移行は CDC コンポーネントに依存します。ソースデータベースで CDC ジョブが実行されていることを確認してください。そうでない場合、DTS タスクは失敗します。 デフォルトでは、CDC コンポーネントに保存されている増分データは 3 日間保持されます。exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを使用して保持期間を調整することを推奨します。 1 つの移行タスクで CDC を有効にするテーブルは 1,000 以下にすることを推奨します。そうしないと、タスクの遅延や不安定性が発生する可能性があります。 増分移行タスクの前提条件モジュールは、ソースデータベースの CDC を有効にします。このプロセス中、SQL Server データベースカーネルの制限により、ソースデータベースが短時間ロックされることがあります。
オブジェクト設定 ステップで SQL Server 増分同期モード を 増分同期のための CDC インスタンスのポーリングとクエリ に設定した場合、以下の制限も適用されます。 DTS インスタンスが使用するソースデータベースアカウントには、CDC を有効にする権限が必要です。データベースレベルの CDC を有効にするには、sysadmin ロールを持つアカウントが必要です。テーブルレベルの CDC を有効にするには、特権アカウントが必要です。
説明 Azure SQL Database コンソールから提供される特権アカウント (サーバー管理者) は要件を満たします。vCore ベースのデータベースの場合、すべてのインスタンスタイプが CDC をサポートします。DTU ベースのデータベースの場合、S3 以降のインスタンスタイプのみが CDC をサポートします。 Amazon RDS for SQL Server の特権アカウントは要件を満たしており、ストアドプロシージャのデータベースレベルの CDC を有効にするために使用できます。 クラスター化列ストアインデックステーブルは CDC をサポートしません。 増分移行タスクの前提条件モジュールは、ソースデータベースの CDC を有効にします。このプロセス中、SQL Server データベースカーネルの制限により、ソースデータベースが短時間ロックされることがあります。
DTS はソースデータベースの各テーブルの CDC インスタンスをポーリングして増分データを取得します。そのため、ソースデータベースから移行するテーブルは 1,000 以下にすることを推奨します。そうしないと、タスクの遅延や不安定性が発生する可能性があります。 デフォルトでは、CDC コンポーネントに保存されている増分データは 3 日間保持されます。exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを使用して保持期間を調整することを推奨します。 列を追加または削除する操作を連続して実行することはできません。たとえば、1 分以内に列を追加または削除する DDL 操作を 2 回以上実行することはできません。そうしないと、タスクが失敗する可能性があります。 ソースデータベースの CDC インスタンスを変更することはできません。そうしないと、タスクが失敗したり、データが失われたりする可能性があります。
異なるバージョン間でデータを移行する場合は、事前に互換性を確認してください。 増分データ移行の遅延の精度を確保するため、DTS はログ解析モードでソースデータベースに `dts_cdc_sync_ddl` トリガー、`dts_sync_progress` ハートビートテーブル、および `dts_cdc_ddl_history` DDL ストレージテーブルを作成します。ハイブリッド増分同期モードでは、DTS は `dts_cdc_sync_ddl` トリガー、`dts_sync_progress` ハートビートテーブル、`dts_cdc_ddl_history` DDL ストレージテーブルを作成し、データベースレベルの CDC と一部のテーブルの CDC を有効にします。ソースデータベースで CDC が有効になっているテーブルのデータ変更率は、1,000 レコード/秒 (RPS) を超えないようにすることを推奨します。 データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時間にデータを移行することを推奨します。そうしないと、完全なデータ移行中に DTS がソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。 完全なデータ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。したがって、完全なデータ移行が完了すると、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 DTS が `FLOAT` または `DOUBLE` データ型の列に対して提供する移行精度がビジネス要件を満たしているか確認してください。DTS は ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度を指定しない場合、DTS は `FLOAT` 値を 38 の精度で、`DOUBLE` 値を 308 の精度で移行します。 DTS は、失敗した移行タスクを 7 日以内に再開しようとします。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用して DTS が宛先インスタンスへのアクセスに使用するアカウントの書き込み権限を取り消す必要があります。これにより、タスクが自動的に再開された後、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 移行タスクに増分データ移行が含まれている場合、インデックスを再作成することはできません。そうしないと、タスクが失敗したり、データが失われたりする可能性があります。
説明 CDC が有効になっているテーブルのプライマリキーは変更できません。 1 つの移行タスクで CDC が有効になっているテーブルの数が DTS がサポートする CDC が有効になっているテーブルの最大数の制限 の値より大きい場合、事前チェックは失敗します。 タスクに増分移行が含まれ、CDC が有効なテーブルの単一フィールドに書き込まれるデータが 64 KB を超える場合は、事前に exec sp_configure 'max text repl size', -1; コマンドを実行してソースデータベースの構成を調整する必要があります。
説明 デフォルトでは、CDC ジョブは最大長 64 KB の単一フィールドを処理できます。 増分移行の場合、ターゲットデータベースで有効になっているトリガーと外部キーを無効にしてください。そうしないと、移行タスクは失敗します。 複数の DTS インスタンスが同じ SQL Server データベースをソースとして使用する場合、それらの増分データ取り込みモジュールは互いに独立しています。 インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行されることがあります。
説明 パラメーターが調整される際、変更されるのは DTS インスタンスのパラメーターのみです。データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。 SQL Server は商用のクローズドソースデータベースです。既知または未知のフォーマット固有の制限により、DTS が SQL Server のログに対して CDC と解析を実行する際に問題が発生する可能性があります。したがって、本番環境で SQL Server ソースの増分同期または増分移行を有効にする前に、包括的な概念実証 (POC) テストを実施することを推奨します。テストでは、すべてのビジネス変更タイプ、テーブルスキーマの変更、およびビジネスのピーク時のストレステストをカバーする必要があります。SQL Server のログフォーマットは予測不可能な性質を持つため、本番環境のビジネスロジックが POC テストのビジネスロジックと一致していることを確認する必要があります。これが、DTS の高い効率と安定性を確保するための鍵となります。
|
特殊なケース | ソースインスタンスが RDS for SQL Server インスタンスの場合、DTS はデータ移行のためにソースインスタンスに rdsdt_dtsacct アカウントを作成します。タスクの実行中は、このアカウントを削除したり、パスワードを変更したりしないでください。削除または変更した場合、タスクが失敗する可能性があります。詳細については、「システムアカウント」をご参照ください。 宛先インスタンスが RDS for SQL Server インスタンスの場合、DTS はインスタンスにデータベースを自動的に作成します。移行対象のデータベース名が RDS for SQL Server の命名規則に準拠していない場合は、移行タスクを設定する前に、宛先インスタンスにデータベースを作成する必要があります。詳細については、「データベースの作成」をご参照ください。
|
SQL Server から AnalyticDB for MySQL への移行
タイプ | 説明 |
ソースデータベースの制限 | 帯域幅要件：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行の速度に影響が出ます。 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが出現する可能性があります。 テーブルレベルのオブジェクトを移行し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 個です。この制限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを構成してください。 1 つのデータ移行タスクでサポートされるデータベースは最大 10 個です。この制限を超えると、安定性やパフォーマンスの問題が発生する可能性があります。この場合、データベースを複数の移行タスクに分割してください。 データベース全体ではなく特定のオブジェクトを移行するタスクを構成する場合、同じ名前でスキーマ名が異なるテーブルを同じターゲットデータベースに移行することはできません。 増分移行の場合、データログは次の要件を満たす必要があります： ログが有効になっている必要があります。バックアップモードは [フル] に設定し、完全な物理バックアップが正常に実行されている必要があります。 増分移行タスクの場合、Data Transmission Service (DTS) はソースデータベースのデータログを 24 時間以上保持することを要求します。完全移行と増分移行の両方を含むタスクの場合、DTS はソースデータベースのデータログを少なくとも 7 日間保持することを要求します。完全移行が完了した後、ログの保持期間を 24 時間以上に変更できます。そうしないと、DTS がデータログを取得できないため、DTS タスクが失敗する可能性があります。極端なケースでは、データ不整合やデータ損失が発生する可能性があります。必要な期間よりも短いログ保持期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。
ソースデータベースから移行するテーブルに対して変更データキャプチャ (CDC) を有効にするには、次の条件を満たす必要があります。そうでない場合、事前チェックは失敗します。 `sys.sysservers` ビューの `srvname` フィールドの値は、`SERVERPROPERTY` 関数の戻り値と同じでなければなりません。 ソースデータベースが自己管理型の SQL Server インスタンスの場合、データベース所有者は `sa` である必要があります。ソースデータベースが RDS for SQL Server インスタンスの場合、データベース所有者は `sqlsa` である必要があります。 ソースデータベースが Enterprise Edition の場合、SQL Server 2008 以降である必要があります。 ソースデータベースが Standard Edition の場合、SQL Server 2016 SP1 以降である必要があります。 ソースデータベースが SQL Server 2017 (Standard または Enterprise Edition) の場合、データベースのバージョンをアップグレードしてください。
DTS は `fn_log` 関数を使用してソースデータベースのログを取得します。この関数にはパフォーマンスのボトルネックがあります。ソースデータベースのログを早すぎるタイミングでクリアしないでください。そうしないと、DTS タスクが失敗する可能性があります。 ソースデータベースの操作制限： 初期スキーマ同期および完全データ移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクが失敗します。 完全データ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータ不整合が発生します。リアルタイムのデータ整合性を確保するには、[初期スキーマ同期]、[完全データ移行]、および [増分データ移行] を選択してください。
ソースデータベースが読み取り専用インスタンスの場合、DDL 操作は移行できません。 ソースデータベースが Azure SQL Database の場合、1 つの DTS インスタンスで移行できるデータベースは 1 つだけです。 ソースデータベースが RDS for SQL Server インスタンスで、移行タスクに増分移行が含まれる場合、DTS インスタンスの安定性を確保するために TDE (透過的データ暗号化) を無効にしてください。詳細については、「TDE を無効にする」をご参照ください。 初期スキーマ同期タスクが実行される前に、ソースデータベースで sp_rename コマンドを使用してストアドプロシージャなどのオブジェクトの名前を変更すると、タスクが期待どおりに動作しないか、失敗する可能性があります。
説明 データベース内のオブジェクトの名前を変更するには、ALTER コマンドを使用してください。 ハイブリッドログ解析モードでは、10 分未満の間隔でソースデータベースの列を追加または削除する複数の操作を連続して実行することはできません。たとえば、次の SQL 文を連続して実行すると、タスクはエラーを報告します。 ALTER TABLE test_table DROP COLUMN Flag;
ALTER TABLE test_table ADD Remark nvarchar(50) not null default('');
ソースデータベースが Web 版 RDS for SQL Server インスタンスの場合、タスクを設定する際に SQL Server 増分同期モード を ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) に設定する必要があります。 完全データ移行中は、ソースデータベースの READ_COMMITTED_SNAPSHOT トランザクション処理モードパラメーターが有効になっていることを確認してください。これにより、共有ロックがデータ書き込みに影響を与えるのを防ぎます。そうしないと、データ不整合やインスタンスの障害などの例外が発生する可能性があります。この問題に起因する例外は、DTS SLA の対象外です。
|
その他の制限 | 基本的なデータ型のデータのみ移行できます。`CURSOR`、`ROWVERSION`、`SQL_VARIANT`、`HIERARCHYID`、`POLYGON`、`GEOMETRY`、`GEOGRAPHY`、および CREATE TYPE コマンドを使用して作成されたユーザー定義データ型のデータは移行できません。 DDL 文がターゲットデータベースへの書き込みに失敗した場合でも、DTS タスクは実行を継続します。失敗した DDL 文はタスクログで確認できます。タスクログの表示方法の詳細については、「タスクログの表示」をご参照ください。 ターゲットデータベースにはカスタムプライマリキーを設定するか、テーブル・列設定 ステップで プライマリキー列の追加 を設定する必要があります。そうでない場合、データ移行が失敗する可能性があります。 オブジェクト設定 ステージで SQL Server 増分同期モード に ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) を選択した場合、移行対象のテーブルにはプライマリキー列を含むクラスター化インデックスが必要です。 移行対象のテーブルは、ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列のあるテーブル、またはスパース列のあるテーブルにすることはできません。 混合ログ解析モードでは、これらの制限は適用されません。 オブジェクト設定 ステップで SQL Server 増分同期モード を クラスター化テーブルはログ解析で増分同期し、ヒープテーブルの場合は CDC で増分同期します (ハイブリッド式ログ解析) に設定した場合、以下の制限も適用されます。 DTS による増分移行は CDC コンポーネントに依存します。ソースデータベースの CDC ジョブが実行中であることを確認してください。そうしないと、DTS タスクは失敗します。 デフォルトでは、CDC コンポーネントに保存されている増分データは 3 日間保存されます。保存期間を調整するには、exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを使用することをお勧めします。 1 つの移行タスクで、CDC を有効にするテーブルは 1,000 個以下にすることを推奨します。そうしないと、タスクの遅延や不安定さが発生する可能性があります。 増分移行タスクの前提条件モジュールは、ソースデータベースの CDC を有効にします。このプロセス中、SQL Server データベースカーネルの制限により、ソースデータベースが短時間ロックされる可能性があります。
オブジェクト設定 ステップで、SQL Server 増分同期モード を 増分同期のための CDC インスタンスのポーリングとクエリ に設定した場合、以下の制限も適用されます。 DTS インスタンスが使用するソースデータベースアカウントには、CDC を有効にする権限が必要です。データベースレベルの CDC を有効にするには、sysadmin ロールを持つアカウントが必要です。テーブルレベルの CDC を有効にするには、特権アカウントが必要です。
説明 Azure SQL Database コンソールが提供する特権アカウント (サーバー管理者) は要件を満たしています。vCore ベースのデータベースの場合、すべてのインスタンスタイプが CDC をサポートします。DTU ベースのデータベースの場合、S3 以上のインスタンスタイプのみが CDC をサポートします。 Amazon RDS for SQL Server の特権アカウントは要件を満たしており、ストアドプロシージャのデータベースレベルの CDC を有効にするために使用できます。 クラスター化列ストアインデックスを持つテーブルは CDC をサポートしません。 増分移行タスクの前提条件モジュールは、ソースデータベースの CDC を有効にします。このプロセス中、SQL Server データベースカーネルの制限により、ソースデータベースが短時間ロックされる可能性があります。
DTS はソースデータベースの各テーブルの CDC インスタンスをポーリングして増分データを取得します。したがって、ソースデータベースから移行するテーブルは 1,000 個以下にすることを推奨します。そうしないと、タスクの遅延や不安定さが発生する可能性があります。 デフォルトでは、CDC コンポーネントに保存されている増分データは 3 日間保存されます。exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを使用して保存期間を調整することをお勧めします。 列を追加または削除する操作を連続して実行することはできません。たとえば、1 分以内に列を追加または削除する DDL 操作を 2 回以上実行することはできません。そうしないと、タスクが失敗する可能性があります。 ソースデータベースの CDC インスタンスを変更することはできません。そうしないと、タスクが失敗したり、データが失われたりする可能性があります。
増分データ移行の遅延の精度を確保するために、DTS はログ解析モードでソースデータベースに `dts_cdc_sync_ddl` トリガー、`dts_sync_progress` ハートビートテーブル、および `dts_cdc_ddl_history` DDL ストレージテーブルを作成します。ハイブリッド増分同期モードでは、DTS は `dts_cdc_sync_ddl` トリガー、`dts_sync_progress` ハートビートテーブル、および `dts_cdc_ddl_history` DDL ストレージテーブルを作成し、データベースレベルの CDC と一部のテーブルの CDC を有効にします。ソースデータベースで CDC が有効になっているテーブルのデータ変更率は、1 秒あたり 1,000 レコード (RPS) を超えないようにすることを推奨します。 AnalyticDB for MySQL の制限により、ターゲットの AnalyticDB for MySQL クラスター内のノードのディスク領域使用率が 80% を超えると、ターゲットデータベースへのデータ書き込みパフォーマンスが低下し、DTS タスクの遅延が発生します。ディスク領域使用率が 90% を超えると、ターゲットデータベースにデータを書き込むことができなくなり、DTS タスクが失敗します。移行するオブジェクトに基づいて必要なストレージ容量を見積もり、ターゲットクラスターに十分なストレージ容量があることを確認してください。 DTS タスクの実行中にターゲットの AnalyticDB for MySQL 3.0 クラスターがバックアップされている場合、タスクは失敗します。 データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時間帯にデータを移行することを推奨します。そうしないと、完全データ移行中に DTS がソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。 完全データ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。したがって、完全データ移行が完了した後、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 DTS が提供する FLOAT または DOUBLE データ型の列の移行精度がビジネス要件を満たしているかどうかを確認してください。DTS は ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度を指定しない場合、DTS は FLOAT 値を 38 の精度で、DOUBLE 値を 308 の精度で移行します。 DTS は、失敗した移行タスクを 7 日以内に再開しようとします。したがって、ビジネスをターゲットインスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用して DTS がターゲットインスタンスへのアクセスに使用するアカウントの書き込み権限を取り消す必要があります。これにより、タスクが自動的に再開された後にソースデータがターゲットインスタンスのデータを上書きするのを防ぎます。 移行タスクに増分データ移行が含まれる場合、インデックスの再作成はできません。そうしないと、タスクが失敗したり、データが失われたりする可能性があります。
説明 CDC が有効になっているテーブルのプライマリキーは変更できません。 1 つの移行タスクで CDC が有効になっているテーブルの数が、DTS がサポートする CDC が有効になっているテーブルの最大数の制限 の値を超えている場合、事前チェックは失敗します。 タスクに増分移行が含まれ、CDC が有効になっているテーブルの単一フィールドに書き込まれるデータが 64 KB を超える場合、事前に exec sp_configure 'max text repl size', -1; コマンドを実行してソースデータベースの構成を調整する必要があります。
説明 デフォルトでは、CDC ジョブは最大長 64 KB の単一フィールドを処理できます。 複数の DTS インスタンスが同じ SQL Server データベースをソースとして使用する場合、それらの増分データ取り込みモジュールは互いに独立しています。 インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行される場合があります。
説明 パラメーターが調整される場合、DTS インスタンスのパラメーターのみが変更され、データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。 SQL Server は商用のクローズドソースデータベースです。既知または未知のフォーマット固有の制限により、DTS が SQL Server ログに対して CDC と解析を実行する際に問題が発生する可能性があります。したがって、本番環境で SQL Server ソースの増分同期または移行を有効にする前に、包括的な概念実証 (POC) テストを実施することを推奨します。テストには、すべてのビジネス変更タイプ、テーブルスキーマの変更、およびビジネスのピーク時のストレステストが含まれている必要があります。SQL Server ログ形式の予測不可能な性質のため、本番環境のビジネスロジックが POC テストのロジックと一致していることを確認する必要があります。これは、DTS の高い効率と安定性を確保するための鍵となります。
|
特殊なケース | ソースインスタンスが RDS for SQL Server インスタンスの場合、DTS はデータ移行のためにソースインスタンスに rdsdt_dtsacct アカウントを作成します。タスクの実行中にこのアカウントを削除したり、パスワードを変更したりしないでください。そうしないと、タスクが失敗する可能性があります。詳細については、「システムアカウント」をご参照ください。 |
SQL Server から AnalyticDB for PostgreSQL への移行
タイプ | 説明 |
ソースデータベースの制限 | 帯域幅の要件：ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行の速度に影響が出ます。 移行対象のテーブルには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが出現する可能性があります。 テーブルレベルのオブジェクトを移行し、テーブル名や列名のマッピングなどの編集が必要な場合、1 つのデータ移行タスクでサポートされるテーブルは最大 1,000 個です。この上限を超えると、タスクの送信後にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを設定してください。 1 つのデータ移行タスクでサポートされるデータベースは最大 10 個です。この上限を超えると、安定性やパフォーマンスの問題が発生する可能性があります。この場合、データベースを複数の移行タスクに分割してください。 データベース全体ではなく特定のオブジェクトを移行するタスクを設定した場合、同じ名前でスキーマ名が異なるテーブルを同じターゲットデータベースに移行することはできません。 増分移行の場合、データログは次の要件を満たす必要があります： ログが有効になっていること。バックアップモードが「完全」に設定されていること。完全物理バックアップが正常に実行されていること。 増分移行タスクの場合、Data Transmission Service (DTS) はソースデータベースのデータログを 24 時間以上保持することを要求します。完全移行と増分移行の両方を含むタスクの場合、DTS はソースデータベースのデータログを少なくとも 7 日間保持することを要求します。完全移行が完了した後、ログ保持期間を 24 時間以上に変更できます。そうしないと、DTS がデータログを取得できないために DTS タスクが失敗する可能性があります。極端な場合には、データ不整合やデータ損失が発生する可能性があります。必要な期間よりも短いログ保持期間に起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。
ソースデータベースから移行するテーブルに対して変更データキャプチャ (CDC) を有効にするには、次の条件を満たす必要があります。そうでない場合、事前チェックは失敗します。 sys.sysservers ビューの srvname フィールドの値は、SERVERPROPERTY 関数の戻り値と同じである必要があります。 ソースデータベースが自己管理型 SQL Server インスタンスの場合、データベース所有者は sa である必要があります。ソースデータベースが RDS for SQL Server インスタンスの場合、データベース所有者は sqlsa である必要があります。 ソースデータベースが Enterprise Edition の場合、SQL Server 2008 以降である必要があります。 ソースデータベースが Standard Edition の場合、SQL Server 2016 SP1 以降である必要があります。 ソースデータベースが SQL Server 2017 (Standard または Enterprise Edition) の場合、データベースのバージョンをアップグレードしてください。
DTS は fn_log 関数を使用してソースデータベースのログを取得します。この関数にはパフォーマンスボトルネックがあります。ソースデータベースのログを早すぎるタイミングでクリアしないでください。そうしないと、DTS タスクが失敗する可能性があります。 ソースデータベースの操作制限： 初期スキーマ同期および完全データ移行中は、データベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。 完全データ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベースの間でデータ不整合が発生します。リアルタイムのデータ整合性を確保するには、「初期スキーマ同期」、「完全データ移行」、および「増分データ移行」を選択してください。
ソースデータベースが読み取り専用インスタンスの場合、DDL 操作は移行できません。 ソースデータベースが Azure SQL Database の場合、1 つの DTS インスタンスで移行できるデータベースは 1 つだけです。 ソースデータベースが RDS for SQL Server インスタンスで、移行タスクに増分移行が含まれる場合、DTS インスタンスの安定性を確保するために TDE (透過的データ暗号化) を無効にしてください。詳細については、「TDE の無効化」をご参照ください。 初期スキーマ同期タスクが実行される前に sp_rename コマンドを使用してソースデータベース内のストアドプロシージャなどのオブジェクトの名前を変更した場合、タスクが期待どおりに動作しないか、失敗する可能性があります。
説明 データベース内のオブジェクトの名前を変更するには、ALTER コマンドを使用します。 ハイブリッドログ解析モードでは、ソースデータベースで 10 分未満の間隔で列を追加または削除する複数の操作を連続して実行することはできません。たとえば、次の SQL 文を連続して実行すると、タスクはエラーを報告します。 ALTER TABLE test_table DROP COLUMN Flag;
ALTER TABLE test_table ADD Remark nvarchar(50) not null default('');
ソースデータベースが Web Edition の RDS for SQL Server インスタンスの場合、タスクを設定する際に、SQL Server 増分同期モード を ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) に設定する必要があります。 完全なデータ移行中は、ソースデータベースで READ_COMMITTED_SNAPSHOT トランザクション処理モードパラメーターが有効になっていることを確認してください。これにより、共有ロックがデータ書き込みに影響を与えるのを防ぎます。有効になっていない場合、データ不整合やインスタンス障害などの例外が発生する可能性があります。この問題に起因する例外は、DTS SLA の対象外です。
|
その他の制限 | 移行できるのは、基本データ型のデータのみです。CURSOR、ROWVERSION、SQL_VARIANT、HIERARCHYID、POLYGON、GEOMETRY、GEOGRAPHY、および CREATE TYPE コマンドで作成されたユーザー定義データ型のデータは移行できません。 次のタイプのオブジェクトは移行できません：INDEX、VIEW、PROCEDURE、FUNCTION、TRIGGER、FK、INDEX、FULL_TEXT_INDEX、DATATYPE、DEFAULT、SYNONYM、CATALOG、PLAN_GUIDE、DEFAULT_CONSTRAINT、UK、CK、および SEQUENCE。 移行するテーブルを選択できます。列マッピングを変更することもできます。完全ではないテーブル移行で列マッピングを使用する場合、またはソーステーブルとターゲットテーブルのスキーマが一致しない場合、ソーステーブルには存在するがターゲットテーブルには存在しない列のデータは失われます。 追記最適化 (AO) テーブルは、ターゲットテーブルとしてサポートされていません。 移行対象のテーブルにプライマリキーが含まれている場合、ターゲットテーブルのプライマリキー列はソーステーブルのプライマリキー列と同じでなければなりません。移行対象のテーブルにプライマリキーが含まれていない場合、ターゲットテーブルのプライマリキー列と分散キーは同じでなければなりません。 ターゲットテーブルの一意キー (プライマリキー列を含む) は、その分散キーのすべての列を含んでいる必要があります。 オブジェクト設定 ステージで、SQL Server 増分同期モード に ソースデータベースのログに基づく増分同期 (ヒープテーブル非対応) を選択した場合、移行対象のテーブルにはプライマリキー列を含むクラスター化インデックスが必要です。移行対象のテーブルは、ヒープテーブル、プライマリキーのないテーブル、圧縮テーブル、計算列のあるテーブル、またはスパース列のあるテーブルであってはなりません。ハイブリッドログ解析モードでは、これらの制限は適用されません。 オブジェクト設定 ステップで SQL Server 増分同期モード を クラスター化テーブルはログ解析で増分同期し、ヒープテーブルの場合は CDC で増分同期します (ハイブリッド式ログ解析) に設定した場合、次の制限も適用されます： DTS による増分移行は CDC コンポーネントに依存します。ソースデータベースで CDC ジョブが実行されていることを確認してください。そうしないと、DTS タスクは失敗します。 デフォルトでは、CDC コンポーネントに保存されている増分データは 3 日間保存されます。 exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを使用して保存期間を調整することをお勧めします。 1 つの移行タスクでは、CDC を有効にするテーブルは 1,000 個以下にすることを推奨します。そうしないと、タスクの遅延や不安定さが発生する可能性があります。 増分移行タスクの前提条件モジュールは、ソースデータベースの CDC を有効にします。このプロセス中、SQL Server データベースカーネルの制限により、ソースデータベースが短時間ロックされることがあります。
オブジェクト設定 ステップで SQL Server 増分同期モード を 増分同期のための CDC インスタンスのポーリングとクエリ に設定した場合、次の制限も適用されます： DTS インスタンスが使用するソースデータベースアカウントには、CDC を有効化するための権限が必要です。データベースレベルの CDC を有効化するには、sysadmin ロールを持つアカウントが必要です。テーブルレベルの CDC を有効化するには、特権アカウントが必要です。
説明 Azure SQL Database コンソールから提供される特権アカウント (サーバー管理者) は要件を満たしています。vCore ベースのデータベースの場合、すべてのインスタンスタイプが CDC をサポートします。DTU ベースのデータベースの場合、S3 以降のインスタンスタイプのみが CDC をサポートします。 Amazon RDS for SQL Server の特権アカウントは要件を満たしており、ストアドプロシージャのデータベースレベルの CDC を有効にするために使用できます。 クラスター化列ストアインデックステーブルは CDC をサポートしていません。 増分移行タスクの前提条件モジュールは、ソースデータベースの CDC を有効にします。このプロセス中、SQL Server データベースカーネルの制限により、ソースデータベースが短時間ロックされることがあります。
DTS は、ソースデータベースの各テーブルの CDC インスタンスをポーリングして増分データを取得します。したがって、ソースデータベースから移行するテーブルは 1,000 個以下にすることを推奨します。そうしないと、タスクの遅延や不安定さが発生する可能性があります。 デフォルトでは、CDC コンポーネントに格納されている増分データは 3 日間保持されます。exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>; コマンドを使用して保持期間を調整することをお勧めします。 列を追加または削除する操作を連続して実行することはできません。たとえば、1 分以内に列を追加または削除する DDL 操作を 2 回以上実行することはできません。そうしないと、タスクが失敗する可能性があります。 ソースデータベースの CDC インスタンスを変更することはできません。そうしないと、タスクが失敗したり、データが失われたりする可能性があります。
増分データ移行の遅延の精度を確保するため、DTS はログ解析モードでソースデータベースに dts_cdc_sync_ddl トリガー、dts_sync_progress ハートビートテーブル、および dts_cdc_ddl_history DDL ストレージテーブルを作成します。ハイブリッド増分同期モードでは、DTS は dts_cdc_sync_ddl トリガー、dts_sync_progress ハートビートテーブル、および dts_cdc_ddl_history DDL ストレージテーブルを作成し、データベースレベルの CDC と一部のテーブルの CDC を有効にします。ソースデータベースで CDC が有効になっているテーブルのデータ変更率は、1,000 レコード/秒 (RPS) を超えないようにすることを推奨します。 データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。オフピーク時間帯にデータを移行することを推奨します。そうしないと、完全データ移行中に DTS がソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。 完全データ移行には同時 INSERT 操作が含まれるため、ターゲットデータベースでテーブルの断片化が発生します。したがって、完全データ移行が完了すると、ターゲットデータベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。 DTS が FLOAT または DOUBLE データ型の列に対して提供する移行精度がビジネス要件を満たしているか確認してください。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度を指定しない場合、DTS は FLOAT 値を 38 の精度で、DOUBLE 値を 308 の精度で移行します。 DTS は、失敗した移行タスクを 7 日以内に再開しようとします。したがって、ビジネスを宛先インスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用して DTS が宛先インスタンスにアクセスするために使用するアカウントの書き込み権限を取り消す必要があります。これにより、タスクが自動的に再開された後に、ソースデータが宛先インスタンスのデータを上書きするのを防ぎます。 移行タスクに増分データ移行が含まれている場合、インデックスの再作成はできません。そうしないと、タスクが失敗したり、データが失われたりする可能性があります。
説明 CDC が有効になっているテーブルのプライマリキーは変更できません。 1 つの移行タスクで CDC が有効になっているテーブルの数が、DTS がサポートする CDC が有効になっているテーブルの最大数の制限 の値より大きい場合、事前チェックは失敗します。 タスクに増分移行が含まれ、かつ CDC が有効なテーブルの単一フィールドに書き込まれるデータが 64 KB を超える場合は、事前に exec sp_configure 'max text repl size', -1; コマンドを実行して、ソースデータベースの構成を調整する必要があります。
説明 デフォルトでは、CDC ジョブは最大長 64 KB の単一フィールドを処理できます。 複数の DTS インスタンスが同じ SQL Server データベースをソースとして使用する場合、それらの増分データ取り込みモジュールは互いに独立しています。 インスタンスに障害が発生した場合、DTS ヘルプデスクは 8 時間以内にインスタンスの回復を試みます。回復プロセス中に、インスタンスの再起動やパラメーターの調整などの操作が実行されることがあります。
説明 パラメーターを調整する際、DTS インスタンスのパラメーターのみが変更され、データベース内のパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。 SQL Server は商用のクローズドソースデータベースです。既知または未知のフォーマット固有の制限により、DTS が SQL Server ログに対して CDC と解析を実行する際に問題が発生する可能性があります。したがって、本番環境で SQL Server ソースの増分同期または移行を有効にする前に、包括的な概念実証 (POC) テストを実施することを推奨します。テストでは、すべてのビジネス変更タイプ、テーブルスキーマの変更、およびビジネスのピーク時間帯のストレステストをカバーする必要があります。SQL Server ログフォーマットの予測不可能な性質のため、本番環境のビジネスロジックが POC テストのビジネスロジックと一致していることを確認する必要があります。これは、DTS の高い効率と安定性を確保するための鍵となります。
|
特殊なケース | ソースインスタンスが RDS for SQL Server インスタンスの場合、DTS はデータ移行用にソースインスタンスに rdsdt_dtsacct アカウントを作成します。タスクの実行中は、このアカウントを削除したり、パスワードを変更したりしないでください。そうしないと、タスクが失敗することがあります。詳細については、「システムアカウント」をご参照ください。 |