Microsoft SQL Server データベースの AWS DMS のソースとしての使用 - AWS Database Migration Service
ソースとしての SQL Server の制限事項SQL Server アクセス許可継続的なCDCを使用するための前提条件オンプレミスまたは EC2 上のセルフ管理 SQL Server の変更のキャプチャクラウド SQL Server DB インスタンスで継続的レプリケーションをセットアップするソースとしての RDS for SQL Server のオプション設定サポートされている圧縮方法セルフ管理 SQL Server AlwaysOn 可用性グループの操作セキュリティ要件エンドポイント設定SQL Server のソースデータ型

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

Microsoft SQL Server データベースの AWS DMS のソースとしての使用

AWS DMS を使用して、1 つ以上の Microsoft SQL Server データベースからデータを移行できます。SQL Server データベースをソースとして使用すると、別の SQL Server データベースまたはサポートされている他の AWS DMS データベースのいずれかにデータを移行できます。

AWS DMSソースとしてサポートする SQL Server のバージョンについては、を参照してくださいAWS DMS のソース。

ソース SQL Server データベースは、ネットワーク内のどのコンピュータにもインストールできます。選択したタスクのタイプに応じてソースデータベースに対する適切なアクセス権限のある SQL Server アカウントは、そのデータベースを AWS DMS で使用するために必要です。このアカウントには、view definitionview server stateおよびの権限が必要です。この許可は、次のコマンドを使用して追加します。

grant view definition to [user]
grant view server state to [user]

AWS DMS は、SQL Server の名前付きインスタンスからのデータ移行をサポートしています。ソースエンドポイントを作成するとき、サーバー名では次の表記を使用できます。

IPAddress\InstanceName

たとえば、正しいソースエンドポイントサーバー名を以下に示します。ここでは、名前の最初の部分はサーバーの IP アドレス、2 番目の部分は SQL Server インスタンス名 (この例では SQLTest) です。

10.0.0.25\SQLTest

また、SQL Server の名前付きインスタンスがリッスンするポート番号を取得し、それを使用して AWS DMS ソースエンドポイントを設定します。

注記

ポート 1433 は、Microsoft SQL Server のデフォルトです。ただし、SQL Server をスタートするたびに変化する動的ポート、およびファイアウォール経由で SQL Server に接続するために使用される特定の静的ポート番号もよく使用されます。したがって、AWS DMS ソース エンドポイントを作成するときに、SQL Server の名前付きインスタンスの実際のポート番号を確認してください。

SSL を使用して、SQL Server エンドポイントとレプリケーションインスタンスとの接続を暗号化できます。SQL Server エンドポイントで SSL を使用する方法の詳細については、「AWS Database Migration Service での SSL の使用」をご参照ください。

SQL Server ソースデータベースと AWS DMS を使用する方法の詳細については、以下をご参照ください。

SQL Server を AWS DMS のソースとして使用する場合の制限

SQL Server データベースを AWS DMS のソースとして使用する場合は、以下の制限が適用されます。

  • 列のアイデンティティプロパティは、ターゲットデータベース列に移行されません。

  • SQL Server エンドポイントでは、スパーステーブルの使用はサポートされていません。

  • Windows 認証はサポートされていません。

  • SQL Server の計算済みフィールドの変更はレプリケーションされていません。

  • 一時テーブルはサポートされていません。

  • SQL Server パーティション切り替えはサポートされていません。

  • WRITETEXT ユーティリティと UPDATETEXT ユーティリティを使用している場合、AWS DMS ではソースデータベースに適用されたイベントがキャプチャされません。

  • 次のデータ操作言語 (DML) パターンはサポートされていません。

    SELECT * INTO new_table FROM existing_table

  • SQL Server をソースとして使用している場合、列レベルの暗号化はサポートされていません。

  • データベースレベルで有効になっている透過的なデータ暗号化 (TDE) がサポートされています。

  • AWS DMSでは、ソースとして使用する SQL Server 2008 または SQL Server 2008 R2 でのサーバーレベルの監査はサポートされていません。これは、SQL Server 2008 および 2008 R2 に関する既知の問題が原因です。たとえば、次のコマンドを実行すると AWS DMS でエラーが発生します。

    USE [master]
GO 
ALTER SERVER AUDIT [my_audit_test-20140710] WITH (STATE=on)
GO

  • ソースとして SQL Server を使用する場合、フル Lobモードではジオメトリ列はサポートされません。代わりに、制限付き LOB モードを使用するか、インライン LOB モードを使用するように InlineLobMaxSize タスク設定を行います。

  • Microsoft SQL Server ソースデータベースを使用して、そのタスクを削除しても SQL Server レプリケーションパブリッシャ定義は削除されません。Microsoft SQL Server システム管理者がそれらの定義を Microsoft SQL Server から削除する必要があります。

  • non-schema-boundスキーマバウンドとビューからのデータの移行は、フルロードのみのタスクでサポートされています。

  • sp_rename を使用したテーブルの名前の変更はサポートされていません (たとえば、sp_rename 'Sales.SalesRegion', 'SalesReg;))。

  • sp_rename を使用した列の名前の変更はサポートされていません (たとえば、sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';)。

  • AWS DMS では、列のデフォルト値を設定および設定解除するための変更処理 (ALTER TABLE ステートメントでの ALTER COLUMN SET DEFAULT 句の使用)はサポートされていません。

  • AWS DMS では、列の null 機能を設定するための変更処理はサポートされていません (ALTER COLUMN [SET|DROP] NOT NULL 句を使用した ALTER TABLE ステートメント)。

  • SQL Server 2012 および SQL Server 2014 では、可用性グループで DMS レプリケーションを使用する場合、ディストリビューション データベースを可用性グループに配置できません。SQL 2016 では、マージ、双方向、peer-to-peerまたはレプリケーショントポロジで使用されるディストリビューションデータベースを除き、ディストリビューションデータベースを可用性グループに配置できます。

  • 分割テーブルの場合、AWS DMSパーティションごとに異なるデータ圧縮設定をサポートしていません。

  • SQL Server の空間データ型 (GEOGRAPHY および GEOMETRY) に値を挿入するときは、SRID (空間リファレンス系識別子) プロパティを無視するか、別の数値を指定できます。空間データ型のテーブルをレプリケートする場合、AWS DMS は SRID をデフォルトの SRID に置き換えます (GEOMETRY の場合は 0、GEOGRAPHY の場合は 4326)。

  • データベースが MS-REPLICATION または MS-CDC 用に設定されていない場合でも、プライマリキーを持たないテーブルをキャプチャできますが、INSERT/DELETE DML イベントのみがキャプチャされます。UPDATE イベント TRUNCATE TABLE イベントは無視されます。

  • Columnstore インデックスはサポートされていません。

  • メモリ最適化テーブル (インメモリ OLTP を使用) はサポートされていません。

  • 複数の列で構成されるプライマリ キーを持つテーブルをレプリケーションする場合、全ロード中にプライマリ キー列の更新はサポートされません。

  • 遅延永続化はサポートされていません。

  • RDS がバックアップを実行する方法が原因により、RDS for SQL Server readBackupOnly=Y ソースインスタンスでエンドポイント設定 (追加接続属性) ha機能しません。

  • RDS ユーザーは SQL Server ストアド プロシージャ (sp_repldone) を実行するアクセス権がないため、Amazon RDS SQL Server ソースインスタンスで EXCLUSIVE_AUTOMATIC_TRUNCATION は動作しません。

  • AWS DMS切り捨てコマンドはキャプチャされません。

  • AWS DMS高速データベースリカバリ (ADR) がオンになっているデータベースからのレプリケーションはサポートしていません。

  • AWS DMS1 つのトランザクションでデータ定義言語 (DDL) とデータ操作言語 (DML) のステートメントをキャプチャすることはサポートされません。

  • AWS DMSデータ層アプリケーションパッケージ (DACPAC) のレプリケーションはサポートしていません。

  • 主キーや一意のインデックスを含み、複数のデータ行を更新する UPDATE ステートメントでは、ターゲットデータベースに変更を適用するときに競合が発生する可能性があります。たとえば、ターゲットデータベースが更新を 1 つの UPDATE ステートメントではなく INSERT および DELETE ステートメントとして適用する場合などに発生する可能性があります。バッチ最適化適用モードでは、テーブルが無視されることがあります。トランザクション適用モードでは、UPDATE 操作によって制約違反が発生する可能性があります。この問題を回避するには、関連するテーブルを再ロードしてください。または、Apply Exceptions コントロールテーブル (dmslogs.awsdms_apply_exceptions) で問題のあるレコードを見つけて、ターゲットデータベースで手動で編集します。詳細については、「変更処理のチューニング設定」を参照してください。

  • AWS DMS名前に次のセットの特殊文字が含まれているテーブルとスキーマの複製はサポートしていません。

    \\ -- \n \" \b \r ' \t ;

  • データマスキングはサポートされません。 AWS DMSマスクされたデータをマスキングなしで移行します。

  • AWS DMS主キーを使用して最大 32,767 のテーブルを複製し、各テーブルにつき最大 1,000 列を複製します。これは、レプリケートされたテーブルごとに SQL Server AWS DMS レプリケーションアーティクルが作成され、SQL Server レプリケーションアーティクルにはこのような制限があるためです。

  • チェンジデータキャプチャ (CDC) を使用する場合は、NOT NULL固有のインデックスを構成するすべての列をとして定義する必要があります。この要件が満たされない場合、SQL Server システムエラー 22838 が発生します。

バックアップトランザクションログにアクセスするときには、次の制限が適用されます。

  • 暗号化バックアップはサポートされていません。

  • URL または Windows Azure に保存されたバックアップはサポートされていません。

ファイルレベルでバックアップトランザクションログにアクセスする場合は、次の制限が適用されます。

  • バックアップトランザクションログは、適切なアクセス許可とアクセス権を持つ共有フォルダに存在する必要があります。

  • アクティブなトランザクションログには、Microsoft SQL Server API (ファイルレベルではなく) を介してアクセスします。

  • UNIX プラットフォームはサポートされていません。

  • 複数のストライプからのバックアップログの読み取りはサポートされていません。

  • Microsoft SQL Server の複数のディスクへのバックアップ (たとえば、MIRROR TO DISK) はサポートされていません。

全ロードのみのタスクに対する許可

全ロード専用タスクを実行するには、次の許可が必要です。AWS DMSdms_userログインは作成されないことに注意してください。SQL Server 用のログインの作成については、「」を参照してくださいマイクロソフト SQL サーバーによるデータベースユーザーの作成。

USE db_name;
                
                CREATE USER dms_user FOR LOGIN dms_user; 
                ALTER ROLE [db_datareader] ADD MEMBER dms_user; 
                GRANT VIEW DATABASE STATE to dms_user ; 
                
                USE master;
                
                GRANT VIEW SERVER STATE TO dms_user;

SQL Server ソースから継続的なレプリケーション (CDC) を使用するための前提条件

オンプレミスまたは Amazon Amazon RDS または Amazon EC2 S または Microsoft Azure SQL のマネージドインスタンスなどクラウドデータベースでの継続的なレプリケーション (変更データキャプチャ、つまり CDC) を使用できます。

AWS DMS のソースとして SQL Server データベースを使用して継続的なレプリケーションを使用する場合は、次の要件が特別に適用されます。

  • SQL Server を完全バックアップ用に設定し、データのレプリケートの開始前にバックアップを実行する必要があります。

  • 復旧モデルを [Bulk logged] または [Full] に設定する必要があります。

  • 複数のディスクへの SQL Server のバックアップはサポートされていません。データベースバックアップを異なるディスク上の複数のファイルに書き込むようにバックアップを定義している場合、AWS DMS ではそのデータを読み取ることができず、AWS DMS タスクは失敗します。

  • セルフ管理 SQL Server ソースの場合、DMS CDC タスクで使用されたソース データベースの SQL Server レプリケーション パブリッシャ定義は、そのタスクを削除しても削除されません。SQL Server システム管理者がそれらの定義をセルフマネージド型ソースの SQL Server から削除する必要があります。

  • CDC 中に、AWS DMS は SQL Server トランザクションログのバックアップを検索して、変更読み取りの必要があります。AWS DMS​ では、ネイティブ フォーマットではないサードパーティーのバックアップソフトウェアを使用して作成された SQL Server トランザクションログのバックアップはサポートされていません。ネイティブフォーマットのトランザクションログバックアップをサポートするには、サードパーティーのバックアップソフトウェアを使用して作成されている場合は、ソース エンドポイントへの use3rdPartyBackupDevice=Y の接続属性を追加します。

  • セルフマネージド型 SQL Server ソースの場合、SQL Server は新しく作成されたテーブルの変更を、公開されるまでキャプチャしない点に注意してください。テーブルが SQL Server ソースに追加されると、AWS DMS は公開の作成を管理します。ただし、この処理には数分かかることがあります。この遅延中に新たに作成されたテーブルに行われたオペレーションは、ターゲットにキャプチャまたはレプリケーションされません。

  • AWS DMS変更データキャプチャでは、SQL Server ですべてのトランザクションログを有効にする必要があります。SQL Server でフルトランザクションロギングを有効にするには、MS-REPLICATION または変更データキャプチャ (CDC) を有効にします。

  • SQL Server の tlog エントリは、MS CDC キャプチャジョブがそれらの変更を処理するまで再利用対象としてマークされません。

  • CDC オペレーションはメモリ最適化テーブルに対してはサポートされていません。この制限は、SQL Server 2014 (この機能が最初に導入されたとき) 以降に適用されます。

オンプレミスまたは Amazon EC2 上のセルフ管理 SQL Server のデータ変更のキャプチャ

Microsoft SQL Server ソースデータベースからの変更をキャプチャするには、データベースが完全バックアップ用に構成されていることを確認してください。データベースをフルリカバリモードまたは一括ログモードで構成します。

セルフマネージド型 SQL Server ソースの場合、AWS DMS は以下を使用します。

MS レプリケーション

プライマリ キーを持たないテーブルの変更をキャプチャします。これは、ソース SQL Server インスタンスで AWS DMS エンドポイント ユーザーに sysadmin 権限を付与することで自動的に設定できます。または、このセクションで説明されているステップに従ってソースを準備し、AWS DMS エンドポイントに sysadmin 以外のユーザーを使用することもできます。

MS-CDC

プライマリ キーを持たないテーブルの変更をキャプチャします。MS-CDC は、すべてのテーブルのデータベースレベルで個別に有効にします。

継続的なレプリケーション (CDC) に SQL Server データベースをセットアップする場合、次のいずれかの操作を実行できます：

  • sysadmin ロールを使用する継続的なレプリケーションをセットアップします

  • sysadmin ロールを使用しない継続的なレプリケーションをセットアップします。

自己管理 SQL Server で sysadmin ロールを使用して継続的なレプリケーションをセットアップする

SQL Server の AWS DMS 継続的レプリケーションでは、プライマリ キーのあるテーブルにはネイティブ SQL Server レプリケーションを使用し、プライマリ キーのないテーブルには変更データキャプチャ (CDC) を使用します。

継続的レプリケーションを設定する前に、「SQL Server ソースから継続的なレプリケーション (CDC) を使用するための前提条件」をご参照ください。

プライマリキーがあるテーブルの場合、AWS DMS は基本的にソースで必要なアーティファクトを設定できます。ただし、セルフ管理 SQL Server ソース インスタンスの場合、最初に、SQL Server のディストリビューションを手動で設定する必要があります。その後、sysadmin アクセス許可のある AWS DMS ソース ユーザーは、プライマリ キーのあるテーブル公開を自動作成できます。

ディストリビューションがすでに設定されているかどうかを確認するには、以下のコマンドを実行します。

sp_get_distributor

列ディストリビューションの結果が NULL の場合、ディストリビューションは設定されていません。ディストリビューションを設定するには、次の手順を使用します。

ディストリビューションを設定するには

  1. SQL Server Management Studio (SSMS) ツールを使用して SQL Server ソースデータベースに接続します。

  2. [Replication] (レプリケーション) フォルダのコンテキスト (右クリック) メニューを開き、[Configure Distribution] (ディストリビューション設定) を選択します。ディストリビューションの設定ウィザードが表示されます。

  3. ウィザードに従ってデフォルト値を入力し、ディストリビューションを作成します。

CDC をセットアップするには

AWS DMSバージョン 3.4.7 以降では、読み取り専用レプリカを使用していない場合、データベースとすべてのテーブルに MS CDC を自動的に設定できます。この機能を使用するには、SetUpMsCdcForTables ECA を true に設定します。ECA の詳細については、を参照してくださいエンドポイント設定。

3.4.7 AWS DMS より前のバージョン、または読み取り専用レプリカをソースとして使用する場合は、次の手順を実行してください。

  1. プライマリ キーがないテーブルの場合、データベースの MS-CDC をセットアップします。そのためには、sysadmin ロールが割り当てられたアカウントを使用し、次のコマンドを実行します。

    use [DBname]
EXEC sys.sp_cdc_enable_db

  2. 次に、ソーステーブルごとに MS-CDC を設定します。一意キーはあるがプライマリ キーがないテーブルごとに、次のクエリを実行して MS-CDC を設定します。

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@index_name = N'unique_index_name',
@role_name = NULL,
@supports_net_changes = 1
GO

  3. プライマリ キーと一意キーの両方がないテーブルごとに、次のクエリを実行して MS-CDC を設定します。

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

特定のテーブルの MS-CDC をセットアップする方法の詳細については、 SQL Server のドキュメントをご参照ください。

自己管理 SQL Server で sysadmin ロールを使用せずに継続的なレプリケーションをセットアップする

ユーザーアカウントが sysadmin 権限を持っている必要がない SQL Server データベースソースに継続的なレプリケーションをセットアップできます。SQL Server データベースを継続的レプリケーション用に構成するには、sysadmin 権限を持つユーザーが必要です。

注記

DMS タスクの実行中にこの手順を実行できます。DMS タスクが停止している場合は、トランザクションログまたは実行中のデータベースバックアップがない場合にのみこの手順を実行できます。これは、SQL Server ではバックアップにログ シーケンス ナンバー (LSN) 位置をクエリするために SYSADMIN 権限 が必要なためです。

継続的レプリケーションを設定する前に、「SQL Server ソースから継続的なレプリケーション (CDC) を使用するための前提条件」をご参照ください。

プライマリ キーのあるテーブルの場合、以下の手順を実行します。

sysadmin ロールを使用せずに継続的なレプリケーションの SQL Server データベースソースをセットアップするには

  1. SQL Server Management Studio (SSMS) を使用してパスワード認証する新しい SQL Server アカウントを作成します。この例では、dmstest というアカウントを使用します。

  2. SSMS の [User Mappings] (ユーザーマッピング) を選択し、MSS と MASTER データベース (公開許可を付与します) を選択し、継続的なレプリケーションに使用するデータベースに DB_OWNER ロールを割り当てます。

    USE [master]
CREATE LOGIN [dmstest] WITH PASSWORD=N'xxxxxxx';
CREATE USER [dmstest] FOR LOGIN [dmstest];

USE [msdb];
CREATE USER [dmstest] FOR LOGIN [dmstest];

USE [DB name used by DMS];
CREATE USER [dmstest] FOR LOGIN [dmstest];
ALTER ROLE [db_owner] ADD MEMBER [dmstest];

  3. 新しいアカウントのコンテキストメニュー (右クリック) を開き、[Security] を選択して Connect SQL 権限を明示的に付与します。

  4. 以下の付与コマンドを実行します。

    GRANT SELECT ON FN_DBLOG TO dmstest;
GRANT VIEW SERVER STATE TO dmstest;
use msdb;
GRANT EXECUTE ON MSDB.DBO.SP_STOP_JOB TO dmstest;
GRANT EXECUTE ON MSDB.DBO.SP_START_JOB TO dmstest;
GRANT SELECT ON MSDB.DBO.BACKUPSET TO dmstest;
GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO dmstest;
GRANT SELECT ON MSDB.DBO.BACKUPFILE TO dmstest;

  5. SSMS で、[Replication] フォルダのコンテキスト (右クリック) メニューを開き、[Configure Distribution] を選択します。すべてのデフォルトステップに従って、ディストリビューションのこの SQL Server インスタンスを設定します。ディストリビューションデータベースがデータベースの下に作成されます。

  6. SQL Server の継続的レプリケーション用に公開を作成するには次のようにします：

    1. SYSADMIN ユーザーアカウントを使用して、SSMS にログインします。

    2. [レプリケーション] を展開します。

    3. [Local Publications (ローカルパブリケーション)] のコンテキスト (右クリック) メニューを開きます。

    4. 「新規パブリケーション」ウィザードで、「次へ」を選択します。

    5. パブリケーションを作成するデータベースを選択します。

    6. [Transactional publication (トランザクションパブリケーション)] を選択したら、[次へ] を選択します。

    7. [Tables] (テーブル) を展開し、PK と発行するテーブル を含むテーブルを選択します。[Next] (次へ) を選択します。

    8. フィルターを作成する必要がないため、[Next (次へ)] を選択します。

    9. [Snapshot Agent (スナップショットエージェント)] 画面で、最初のオプションの [Create a snapshot immediately and keep the snapshot available to initialize subscriptions (スナップショットをすぐに作成し、スナップショットをサブスクリプションの初期化に使用できるようにする)] を選択します。[Next] (次へ) を選択します。

    10. [Security Settings] (セキュリティ設定) を選択し、[Run under the SQL Server Agent service account] (SQL Server エージェントサービスアカウントで実行) の順に選択します。公開者接続用に、[By impersonating the process account] (プロセス用アカウントを偽装) 選択します。[OK] を選択します。

    11. [Next] (次へ) を選択します。

    12. [Create the publication (パブリケーションの作成)] を選択します。

    13. パブリケーションの名前をこの形式 (AR_PUBLICATION_000DBID) で指定します。

      たとえば、DBID が 10 未満の場合は、公開 AR_PUBLICATION_0000DBID> (4 ゼロ)の名前を指定します。DBID が 10 以上である場合、公開の名前 AR_PUBLICATION_000DBID(3 ゼロ) を指定します。また、SQL Server で DB_ID 関数を使用することもできます。DB_ID 関数の詳細については、SQL Server ドキュメント をご参照ください。

  7. 作成したユーザーアカウントを使用して、ソース エンドポイントとして SQL Server を持つ新しい AWS DMS タスクを作成します。

プライマリ キーがないテーブルの場合、データベースの MS-CDC をセットアップします。そのためには、sysadmin ロールが割り当てられたアカウントを使用し、次のコマンドを実行します。

use [DBname]
EXEC sys.sp_cdc_enable_db

次に、ソーステーブルごとに MS-CDC を設定します。一意キーはあるがプライマリ キーがないテーブルごとに、次のクエリを実行して MS-CDC を設定します。

exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@index_name = N'unique_index_name',
@role_name = NULL,
@supports_net_changes = 1
GO

プライマリ キーと一意キーの両方がないテーブルごとに、次のクエリを実行して MS-CDC を設定します。

exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

特定のテーブルの MS-CDC をセットアップする方法の詳細については、 SQL Server のドキュメントをご参照ください。

クラウド SQL Server DB インスタンスで継続的レプリケーションをセットアップする

このセクションでは、クラウドでホストされた SQL Server データベースインスタンスで CDC を設定する方法について説明します。クラウドホストの SQL サーバーインスタンスは、Amazon RDS for SQL Server、Azure SQL 管理インスタンス、またはその他のマネージドクラウド SQL Server インスタンス上で実行されるインスタンスです。各データベースタイプの継続的なレプリケーションの制限については、を参照してくださいSQL Server を AWS DMS のソースとして使用する場合の制限。

継続的レプリケーションを設定する前に、SQL Server ソースから継続的なレプリケーション (CDC) を使用するための前提条件 をご参照ください。

セルフ管理 SQL Server ソースとは異なり、Amazon RDS for SQL Server では MS レプリケーションはサポートされません。したがって、AWS DMS はプライマリキーの有無にかかわらずテーブルに MS-CDC を使用する必要があります。

Amazon RDS は、ソース SQL Server インスタンスの継続的変更に AWS DMS が使用するレプリケーション アーティファクトを設定するために、sysadmin 権限を付与しません。以下の手順で、Amazon RDS インスタンスで MS-CDC (マスターユーザー権限を使用して) を有効にする必要があります。

クラウド SQL Server DB インスタンスで MS-CDC を有効にするには

  1. 次のクエリのいずれかをデータベースレベルで実行します。

    RDS for SQL Server DB インスタンスの場合、このクエリを使用してください。

    exec msdb.dbo.rds_cdc_enable_db 'DB_name'

    Azure SQL マネージド DB インスタンスの場合は、このクエリを使用してください。

    USE DB_name 
GO 
EXEC sys.sp_cdc_enable_db 
GO

  2. プライマリ キーがあるテーブルごとに、次のクエリを実行して MS-CDC を有効にします。

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL,
@supports_net_changes = 1
GO

    一意キーはあるがプライマリ キーがないテーブルごとに、次のクエリを実行して MS-CDC を有効にします。

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@index_name = N'unique_index_name',
@role_name = NULL,
@supports_net_changes = 1
GO

    プライマリキーと一意キーの両方がないテーブルごとに、次のクエリを実行して MS-CDC を有効にします。

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

  3. 次のコマンドを使用して、ソースで変更を使用できる保持期間を設定します。

    use dbname
EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 86399
exec sp_cdc_stop_job 'capture'
exec sp_cdc_start_job 'capture'

    パラメータ @pollinginterval は秒単位で測定され、推奨値 86399 に設定されます。つまり、@pollinginterval = 86399 の場合、トランザクションログは 86,399 秒 (約 1 日) の変更を保持します。手順 exec sp_cdc_start_job 'capture' によって設定が開始されます。

    注記

    SQL Server の一部のバージョンでは、pollinginterval が 3599 秒以上に設定されている場合、値はデフォルトの 5 秒にリセットされます。この場合、T-ログ エントリは AWS DMS が読み取りする前にパージされます。この既知の問題の影響を受ける SQL Server のバージョンを確認するには、「このマイクロソフト KB 記事」をご参照ください。

    マルチ AZ で Amazon RDS を使用している場合は、フェイルオーバー時に適切な値を持つようにセカンダリも設定してください。

    exec rdsadmin..rds_set_configuration 'cdc_capture_pollinginterval' , 86399

SQL Server ソースに対する継続的変更をキャプチャする AWS DMS レプリケーション タスクが 1 時間以上停止する場合は、次の操作を行います。

AWS DMS レプリケーション タスク中の保持期間の維持

  1. 次のコマンドを使用して、トランザクションログを切り捨てるジョブを停止します。

    exec sp_cdc_stop_job 'capture'

  2. AWS DMS コンソールで自分のタスクを見つけ、タスクを再開します。

  3. [Monitoring] (モニタリング) タブを選択し、CDCLatencySource メトリクスを選択します。

  4. CDCLatencySource メトリクスが 0 (ゼロ) に等しく、そのままの場合、次のコマンドを使用して、トランザクション ログ切り捨てジョブを再開します。

    exec sp_cdc_start_job 'capture'

必ず SQL Server トランザクションログを切り捨てるジョブをスタートしてください。そうしないと、SQL Server インスタンスのストレージがいっぱいになる可能性があります。

クラウド SQL Server DB インスタンスで継続的レプリケーションの制限事項

  • AWS DMSアクティブなトランザクションログのみによる継続的レプリケーション (CDC) をサポートします。CDC ではバックアップログを使用できません。

  • イベントをアクティブなトランザクションログからバックアップログに移動したり、アクティブなトランザクションログから切り捨てたりすると、イベントが失われる可能性があります。

Amazon RDS for SQL Server ソースとして使用するとき推奨される設定 AWS DMS

Amazon RDS for SQL Server をソースとして使用する場合、maxscansキャプチャジョブはパラメータとに依存します。maxtransこれらのパラメータは、キャプチャがトランザクションログに対して実行するスキャンの最大数と、スキャンごとに処理されるトランザクション数を決定します。

トランザクション数がより多いデータベースではmaxtrans*maxscans、polling_interval値を増やすとアクティブなトランザクションログレコードが蓄積される可能性があります。その結果、この蓄積によってトランザクションログのサイズが大きくなる可能性があります。

MS-CDC AWS DMS キャプチャジョブには依存しないことに注意してください。MS-CDC キャプチャジョブは、トランザクションログエントリを処理済みとしてマークします。これにより、トランザクションログバックアップジョブでトランザクションログからエントリを削除できます。

トランザクションログのサイズと MS-CDC ジョブの成功を監視することをお勧めします。MS-CDC ジョブが失敗すると、トランザクションログが過度に大きくなり、レプリケーションが失敗する可能性があります。AWS DMSsys.dm_cdc_errorsソースデータベースの動的管理ビューを使用して MS-CDC キャプチャジョブのエラーを監視できます。DBCC SQLPERF(LOGSPACE)管理コマンドを使用してトランザクションログのサイズを監視できます。

MS-CDC が原因で発生するトランザクションログの増加に対処するには

  1. Log Space Used %データベースのレプリケーション元がかどうかを確認し、AWS DMSデータベースが増え続けていることを確認します。

    DBCC SQLPERF(LOGSPACE)

  2. トランザクションログのバックアッププロセスを妨げている原因を特定します。

    Select log_reuse_wait, log_reuse_wait_desc, name from sys.databases where name = db_name();

    log_reuse_wait_desc値が等しい場合はREPLICATION、MS-CDC の遅延が原因でログバックアップが保持されます。

  3. maxtransmaxscansおよびパラメータ値を増やして、キャプチャジョブによって処理されるイベントの数を増やします。

    EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@maxtrans = 5000, @maxscans = 20 
exec sp_cdc_stop_job 'capture'
exec sp_cdc_start_job 'capture'

この問題に対処するには、maxscansmaxtransmaxtrans*maxscansAWS DMSソースデータベースからレプリケートされるテーブルに対して生成されるイベントの平均数と毎日同じになるように、およびの値を設定します。

これらのパラメータを推奨値よりも高く設定すると、キャプチャジョブはトランザクションログのすべてのイベントを処理します。これらのパラメータを推奨値より低く設定すると、MS-CDC の待ち時間が長くなり、トランザクションログが大きくなります。

maxtransワークロードの変化によって生成されるイベントの数はさまざまであるため、maxscansおよびの適切な値を特定するのは難しい場合があります。この場合、MS-CDC 遅延のモニタリングを設定することをお勧めします。詳細については、SQL Server ドキュメントの「プロセスの監視」を参照してください。次にmaxtrans、maxscans監視結果に基づいて動的に構成します。

AWS DMSタスクの再開または続行に必要なログシーケンス番号 (LSN) をタスクが見つけられない場合、タスクは失敗し、完全なリロードが必要になることがあります。

SQL Server でサポートされる圧縮方法

次の表は、SQL Server バージョンごとに AWS DMS によりサポートされている圧縮方法を示しています。

SQL Server version

行/ページの圧縮 (パーティションレベル)

Vardecimal ストレージ形式

2005

いいえ

いいえ

2008

はい

いいえ

2012

はい

いいえ

2014

はい

いいえ
注記

スパース列とカラム構造圧縮はサポートされていません。

セルフ管理 SQL Server AlwaysOn 可用性グループの操作

SQL Server Always On 可用性グループは、データベースミラーリングに代わるエンタープライズレベルの代替手段として、高可用性と障害回復を実現します。

ではAWS DMS、1 つのプライマリまたはセカンダリアビリティグループのレプリカの変更を移行できます。

プライマリ可用性グループレプリカの操作

プライマリ可用性グループをのソースとして使用するにはAWS DMS、以下の操作を実行します。

  1. 可用性レプリカのすべての SQL Server インスタンスの配布オプションを有効にします。詳細については、「自己管理 SQL Server で sysadmin ロールを使用して継続的なレプリケーションをセットアップする」を参照してください。

  2. AWS DMS コンソールで、SQL Server ソースデータベース設定を開きます。[Server Name]、可用性グループリスナーに設定されたドメインネームサービス (DNS) または IP アドレスを指定します。

初めて AWS DMS タスクを開始する場合、開始に通常より時間がかかることがあります。この速度低下は、テーブルアーティクルの作成が可用性グループサーバーによって複製されているために発生します。

二次可用性グループレプリカの使用

ソースとしてセカンダリアビリティグループをで使用するにはAWS DMS、以下の操作を実行します。

  1. 個々のレプリカへの接続には、AWS DMSソースエンドポイントのユーザーが使用する認証情報と同じ認証情報を使用します。

  2. AWS DMSレプリケーションインスタンスが既存のすべてのレプリカの DNS 名を解決し、それらに接続できることを確認します。次の SQL クエリを使用して、すべてのレプリカの DNS 名を取得できます。

    select ar.replica_server_name, ar.endpoint_url from sys.availability_replicas ar
JOIN sys.availability_databases_cluster adc
ON adc.group_id = ar.group_id AND adc.database_name = '<source_database_name>';

  3. ソースエンドポイントを作成するときに、エンドポイントのサーバー名またはエンドポイントシークレットのサーバーアドレスに可用性グループリスナーの DNS 名を指定します。可用性グループリスナーの詳細については、「可用性グループリスナーとは」を参照してください。 SQL Server ドキュメントを参照してください。

    パブリック DNS サーバーまたはオンプレミス DNS サーバーのいずれかを使用して、可用性グループリスナー、プライマリレプリカ、およびセカンダリレプリカを解決できます。オンプレミスの DNS サーバーを使用するには、Amazon Route 53 Resolverを設定します。詳細については、「 独自のオンプレミスネームサーバーの使用」を参照してください。

  4. ソースエンドポイントに、次の追加の接続属性を追加します。

    追加接続属性 値 メモ
    applicationIntent ReadOnly この ODBC 設定がない場合、レプリケーションタスクはプライマリ可用性グループのレプリカにルーティングされます。詳細については、SQL Server ドキュメントの「高可用性と障害回復のためのSQL Server ネイティブクライアントSupport、ディザスタリカバリ」を参照してください。
    multiSubnetFailover yes 詳細については、SQL Server ドキュメントの「高可用性と障害回復のためのSQL Server ネイティブクライアントSupport、ディザスタリカバリ」を参照してください。
    alwaysOnSharedSynchedBackupIsEnabled false 詳細については、「ソースとして SQL Server を使用する場合エンドポイント設定 AWS DMS」を参照してください。
    activateSafeguard false 詳細については、「制限事項」を参照してください。
    setUpMsCdcForTables false 詳細については、「制限事項」を参照してください。

  5. 可用性グループのすべてのレプリカで配布オプションを有効にします。すべてのノードをディストリビューターリストに追加します。詳細については、「ディストリビューションを設定するには」を参照してください。

  6. プライマリ読み取り/書き込みレプリカに対して次のクエリを実行して、データベースを公開できるようにします。このクエリは、データベースに対して 1 回だけ実行します。

    sp_replicationdboption @dbname = N'<source DB name>', @optname = N'publish', @value = N'true';

制限事項

二次可用性グループのレプリカを操作する場合、次の制限があります。

  • AWS DMS読み取り専用の可用性グループレプリカをソースとして使用する場合、Safeguardはサポートされません。詳細については、「ソースとして SQL Server を使用する場合エンドポイント設定 AWS DMS」を参照してください。

  • AWS DMS読み取り専用の可用性グループレプリカをソースとして使用する場合、setUpMsCdcForTables追加の接続属性はサポートされません。詳細については、「ソースとして SQL Server を使用する場合エンドポイント設定 AWS DMS」を参照してください。

  • AWS DMS自己管理型のセカンダリ可用性グループレプリカを、バージョン 3.4.7 以降の継続的なレプリケーション (変更データキャプチャ、または CDC) のソースデータベースとして使用できます。クラウド SQL Server マルチ AZ リードレプリカはサポートされません。以前のバージョンを使用する場合はAWS DMS、必ず CDC のソースデータベースとしてプライマリ可用性グループレプリカを使用してください。

他のノードへのフェイルオーバー

ApplicationIntentエンドポイントの追加接続属性をに設定するとReadOnly、AWS DMSタスクは読み取り専用ルーティングの優先順位が最も高い読み取り専用ノードに接続します。次に、優先順位が最も高い読み取り専用ノードが使用できなくなったときに、可用性グループの他の読み取り専用ノードにフェイルオーバーします。設定しない場合ApplicationIntent、AWS DMSタスクは可用性グループのプライマリ (読み取り/書き込み) ノードにのみ接続します。

ソースとして SQL Server を使用する場合セキュリティ要件 AWS Database Migration Service

AWS DMSユーザーアカウントには、少なくとも接続先のソース SQL Server db_owner データベース上のユーザーロールが必要です。

ソースとして SQL Server を使用する場合エンドポイント設定 AWS DMS

エンドポイントの設定を使用して、追加の接続属性の使用と同様に SQL Server ソースデータベースを設定できます。設定は、AWS DMSコンソールを使用するか、--microsoft-sql-server-settings '{"EndpointSetting": "value", ...}' JSON create-endpoint AWS CLI構文のコマンドを使用してソースエンドポイントを作成するときに指定します。

次の表は、ソースとして SQL Server で使用できるエンドポイントの設定を示しています。

名前 説明
AlwaysOnSharedSynchedBackupIsEnabled

この属性は、Always On 可用性グループクラスターの一部としてホストされている SQL Server ソースデータベースから移行する AWS DMS の動作を調整します

AWS DMS では、Always On クラスタで実行するように構成された SQL Server ソースデータベースのサポートが強化されています。この場合、AWS DMS は、ソースデータベース インスタンスがホストされているノード以外の Always On クラスタ内のノードからトランザクション バックアップが実行されているかどうかを追跡しようとします。移行タスクの起動時に、AWS DMSクラスタ内の各ノードに接続しようとしますが、いずれかのノードに接続できない場合は失敗します。

必要な場合、AWS DMS Always On クラスタ内のすべてのノードでトランザクションバックアップをポーリングするには、false に対してこの属性を設定します。

デフォルト値: true

有効な値: true または false

例: '{"AlwaysOnSharedSynchedBackupIsEnabled": false}'

SafeguardPolicy

パフォーマンスを最大限に高めるため、AWS DMS は未読み取りのすべての変更をアクティブなトランザクションログ (TLOG) からキャプチャしようとします。ただし、切り捨てが原因で、アクティブなTLOGに未読の変更がすべて含まれていない場合があります。これが発生すると、AWS DMSログバックアップにアクセスして欠落している変更をキャプチャします。ログバックアップにアクセスする必要性を最小限に抑えて、次のいずれかの方法を使用してAWS DMSで切り捨てを防止します。

  1. RELY_ON_SQL_SERVER_REPLICATION_AGENT(データベースでトランザクションを開始): これがのデフォルトですAWS DMS。

    この設定を使用する場合、AWS DMSレプリケーション対象としてマークされたトランザクションをアクティブな TLOG AWS DMS から移動できるように、SQL Server Log Reader Agent が実行されている必要があります。Log Reader Agent が実行されていない場合、アクティブな TLOG がいっぱいになり、問題が解決されるまでソースデータベースが読み取り専用モードに切り替わる可能性があることに注意してください。以外の目的でデータベースの Microsoft レプリケーションを有効にする必要がある場合はAWS DMS、この設定を選択する必要があります。

    この設定を使用すると、AWS DMSというテーブルを作成してログバックアップの読み取りを最小限に抑え、awsdms_truncation_safeguardデータベースで開いているトランザクションを模倣して TLOG の切り捨てを防ぎます。これにより、データベースがイベントを切り捨ててバックアップログに移動するのを 5 分間 (デフォルト) 防ぎます。メンテナンスジョブが失敗する可能性があるため、テーブルがメンテナンスプランに含まれていないことを確認してください。Start Transactionsデータベースオプションで設定されたタスクがない場合は、テーブルを安全に削除できます。

  2. EXCLUSIVE_AUTOMATIC_TRUNCATION(1 つのタスクでのみ使用sp_repldone): この設定を使用すると、AWS DMSログエントリに「使用中」ready for truncation とマークするレプリケーションエージェントプロセスを完全に制御できますsp_repldone。この設定では、RELY_ON_SQL_SERVER_REPLICATION_AGENT (デフォルト) AWS DMS 設定のようにダミートランザクションを使用しません。この設定は、MS Replication AWS DMS がソースデータベース以外の目的で使用されていない場合にのみ使用できます。また、この設定を使用する場合、AWS DMSデータベースにアクセスできるタスクは 1 つだけです。同じデータベースに対してparallel AWS DMS タスクを実行する必要がある場合は、を使用してくださいRELY_ON_SQL_SERVER_REPLICATION_AGENT。

    • この設定では、データベースで Log Reader Agent を停止する必要があります。タスク開始時にログリーダーエージェントが実行中の場合、AWS DMSタスクは強制的に停止します。または、タスクを開始する前に Log Reader Agent を手動で停止することもできます。

    • MS-CDC でこの方法を使用する場合は、MS-CDC キャプチャジョブと MS-CDC クリーンアップジョブを停止して無効にする必要があります。

    • Microsoft SQL Server 移行ジョブがリモートのディストリビュータマシンで実行される場合は、AWS DMSリモートマシンにアクセスできないため、この設定は使用できません。

    • EXCLUSIVE_AUTOMATIC_TRUNCATIONAmazon RDS sp_repldone がストアドプロシージャを実行するためのアクセス権がないため、Amazon RDS for SQL Server ソースインスタンスでは機能しません。

    • sysadmin SafeguardPolicy EXCLUSIVE_AUTOMATIC_TRUNCATION ロールを使用せずにに設定した場合は、dbo.syscategoriesdbo.sysjobsおよびオブジェクトに対する権限をユーザーに付与する必要があります。dmsuser

デフォルト値: RELY_ON_SQL_SERVER_REPLICATION_AGENT

有効な値: {EXCLUSIVE_AUTOMATIC_TRUNCATION, RELY_ON_SQL_SERVER_REPLICATION_AGENT}

例: '{"SafeguardPolicy": "EXCLUSIVE_AUTOMATIC_TRUNCATION"}'

ActivateSafeguard

この属性により、セーフガードのオン/オフを切り替えます。セーフガードについて詳しくは、SafeguardPolicy以下を参照してください。

デフォルト値: true

有効な値: {false, true}

例: '{"ActivateSafeguard": true}'

SetUpMsCdcForTables

この属性は、ソースデータベースと、MS-Replication が有効になっていないタスクマッピング内のテーブルの MS-CDC を有効にします。この値を設定すると、sp_cdc_enable_dbソースデータベースでストアドプロシージャが実行され、ソースデータベースで MS sp_cdc_enable_table レプリケーションが有効になっていないタスクの各テーブルでストアドプロシージャが実行されます。trueディストリビューションをオンにすることの詳細については、「」を参照してください自己管理 SQL Server で sysadmin ロールを使用して継続的なレプリケーションをセットアップする。

有効な値: {true, false}

例: '{"SetUpMsCdcForTables": true}'

ReadBackupOnly

この属性を使用するには、sysadmin 権限が必要です。この属性が Y に設定されている場合、AWS DMS は、継続的レプリケーション間にトランザクションログのバックアップからの変更のみを読み取り、アクティブ トランザクション ログ ファイルからは読み取られません。このパラメータを Y に設定すると、完全ロードおよび継続的なレプリケーションタスク中に、アクティブなトランザクションのログファイルの拡張を制御することができます。ただし、これによって継続的なレプリケーションに一部のソースレイテンシーが生じることがあります。

有効な値: N または Y。デフォルトは N です。

例: '{"ReadBackupOnly": Y}'

注意:このパラメータは、RDS がバックアップを実行する方法であるため、Amazon RDS SQL Server ソースインスタンスでは機能しません。

Use3rdPartyBackupDevice

この属性がYに設定されている場合,AWS DMS は、サードパーティのトランザクション ログ バックアップがネイティブ形式で作成されている限り処理します。

"MultiSubnetFailover": "Yes"

この ODBC ドライバ属性によって、可用性グループのフェールオーバー時に DMS が新しいプライマリに接続しやすくなります。この属性は、接続が切断されているか、リスナーの IP アドレスが正しくない状況向けに設計されています。このような状況で、AWS DMS は、可用性グループリスナーに関連付けられたすべての IP アドレスへの接続を試みます。

"ApplicationIntent": "readonly"

この ODBC ドライバー属性設定により、SQL Server はレプリケーションタスクを最も優先度の高い読み取り専用ノードにルーティングします。この設定がない場合、SQL Server はレプリケーションタスクをプライマリ読み取り/書き込みノードにルーティングします。

FatalOnSimpleModel

に設定した場合true、SQL Server simple データベースリカバリモデルがに設定されていると、致命的エラーが発生します。

デフォルト値: false

有効な値: true または false

例: '{"FatalOnSimpleModel": true}'

TlogAccessMode

CDC データの取得に使用されるモードを示します。

デフォルト値: PreferTlog

有効な値: BackupOnly、PreferBackup、PreferTlog、TlogOnly

例: '{"TlogAccessMode": "PreferTlog"}'

ForceLobLookup

インライン LOB で LOB 検索を強制します。

デフォルト値: false

有効な値: true、false

例: '{"ForceLobLookup": false}'

SQL Server のソースデータ型

SQL Server を AWS DMS のソースとして使用するデータ移行では、ほとんどの SQL Server データ型がサポートされます。次の表に、AWS DMS を使用する場合にサポートされる SQL Server のソースデータ型と、AWS DMS のデータ型からのデフォルトマッピングを示します。

ターゲットにマッピングされるデータ型を表示する方法については、使用しているターゲットエンドポイントのセクションをご参照ください。

AWS DMS のデータ型の詳細については、「AWS Database Migration Service のデータ型」をご参照ください。

SQL Server のデータ型

AWS DMS データ型

BIGINT

INT8

BIT

BOOLEAN

DECIMAL

NUMERIC

INT

INT4

MONEY

NUMERIC

NUMERIC (p,s)

NUMERIC

SMALLINT

INT2

SMALLMONEY

NUMERIC

TINYINT

UINT1

REAL

REAL4

FLOAT

REAL8

DATETIME

DATETIME

DATETIME2 (SQL サーバー 2008 以降)

DATETIME

SMALLDATETIME

DATETIME

DATE

DATE

TIME

TIME

DATETIMEOFFSET

WSTRING

CHAR

STRING

VARCHAR

STRING

VARCHAR(max)

CLOB

TEXT

AWS DMS でこのデータ型を使用するには、特定のタスク用に CLOB データ型の使用を有効にする必要があります。

SQL Server テーブルの場合、SQL Server で LOB 列の値を変更しない UPDATE ステートメントでも、AWS DMS はターゲットの LOB 列を更新します。

CDC 中、AWS DMS はプライマリキーを含むテーブルでのみ CLOB データ型をサポートします。

NCHAR

WSTRING

NVARCHAR (長さ)

WSTRING

NVARCHAR (最大)

NCLOB

NTEXT

でこのデータ型を使用するにはAWS DMS、特定のタスクでの使用を有効にする必要があります。SupportLobsLob サポートの有効化に関する詳細については、AWS DMS タスクのソースデータベースの LOB サポートの設定 をご参照ください。

SQL Server テーブルの場合、SQL Server で LOB 列の値を変更しない UPDATE ステートメントでも、AWS DMS はターゲットの LOB 列を更新します。

CDC 中、AWS DMS はプライマリキーを含むテーブルでのみ CLOB データ型をサポートします。

BINARY

BYTES

VARBINARY

BYTES

VARBINARY (最大)

BLOB

IMAGE

SQL Server テーブルの場合、SQL Server で LOB 列の値を変更しない UPDATE ステートメントでも、AWS DMS はターゲットの LOB 列を更新します。

AWS DMS でこのデータ型を使用するには、特定のタスク用に BLOB データ型の使用を有効にする必要があります。

AWS DMS は、プライマリキーを含むテーブルでのみ BLOB データ型をサポートします。

TIMESTAMP

BYTES

UNIQUEIDENTIFIER

STRING

HIERARCHYID

SQL Server ターゲットエンドポイントにレプリケートする場合は、HIERARCHYID を使用します。

他のすべてのターゲットエンドポイントにレプリケートする場合は、WSTRING (250) を使用します。

XML

NCLOB

SQL Server テーブルの場合、SQL Server で LOB 列の値を変更しない UPDATE ステートメントでも、AWS DMS はターゲットの LOB 列を更新します。

AWS DMS でこのデータ型を使用するには、特定のタスク用に NCLOB データ型の使用を有効にする必要があります。

CDC 中、AWS DMS はプライマリキーを含むテーブルでのみ NCLOB データ型をサポートします。

GEOMETRY

このデータ型をサポートするターゲットエンドポイントにレプリケートする場合は、GEOMETRY を使用します。

このデータ型をサポートしないターゲットエンドポイントにレプリケートする場合は、CLOB を使用します。

GEOGRAPHY

このデータ型をサポートするターゲットエンドポイントにレプリケートする場合は、GEOGRAPHY を使用します。

このデータ型をサポートしないターゲットエンドポイントにレプリケートする場合は、CLOB を使用します。

AWS DMS は、以下のデータ型のフィールドを含むテーブルをサポートしません。

  • CURSOR

  • SQL_VARIANT

  • TABLE

注記

ユーザー定義のデータ型は、基本型に従ってサポートされます。たとえば、DATETIME をベースとするユーザー定義のデータ型は DATETIME データ型として扱われます。