Microsoft SQL Server データベースの AWS DMS のソースとしての使用 - AWS Database Migration Service
ソースとしての SQL Server に対する許可は、別途付与する必要があります。SQL Server アクセス許可継続的な CDC を使用するための前提条件オンプレミスまたは EC2 上のセルフ管理 SQL Server Server での変更のキャプチャクラウド SQL Server DB インスタンスに対する許可は、別途付与する必要があります。SQL Server 用 RDS に対する許可は、別途付与する必要があります。サポートされている圧縮方法自己管理型 SQL サーバーでの作業 AlwaysOnアベイラビリティグループセキュリティ要件エンドポイント設定SQL Server のソースデータ型

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

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

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

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

ソース SQL Server データベースは、ネットワーク内のどのコンピュータにもインストールできます。選択したタスクのタイプに応じてソースデータベースに対する適切なアクセス権限のある SQL Server アカウントは、そのデータベースを AWS DMS で使用するために必要です。このアカウントは、view definitionそしてview 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 をソースとして使用している場合、列レベルの暗号化はサポートされていません。

  • 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 モードを使用するように 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 では、マージ、双方向、または 1 つのディストリビューションデータベースでのディストリビューションデータベースでのディストリビューションデータベースでのディストリビューションデータベースの使用がサポートされています。 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 を使用) はサポートされていません。

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

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

  • はreadBackupOnly=YRDS のバックアップ方法上の理由により、RDS for SQL Server のソースインスタンスなどエンドポイント設定 (追加接続属性) は機能しません。

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

  • AWS DMStruncate コマンドはキャプチャされません。

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

  • AWS DMSデータ定義言語 (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 個の列を複製します。その理由はAWS DMSレプリケートされたテーブルごとに SQL Server レプリケーションアーティクルが作成されますが、SQL Server のレプリケーションアーティクルには以下の制限があります。

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

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

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

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

  • AWS DMS代替共有フォルダーからのファイルレベルでのトランザクションログバックアップの直接処理はサポートされていません。

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

全ロード専用タスクを実行するには、次の許可が必要です。以下の点に注意してください。AWS DMSは作成されませんdms_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 EC2 上のセルフ管理 SQL Server データベースや、Amazon RDS または 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 サーバーtlogMS CDC キャプチャジョブがそれらの変更を処理するまで、エントリには再利用のマークが付けられません。

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

  • AWS DMS変更データをキャプチャするには、デフォルトで Amazon EC2 またはオンプレミス SQL サーバー上のディストリビューションデータベースがソースとして必要です。そのため、プライマリキーを持つテーブルの MS レプリケーションを設定する際は、必ずディストリビューターを有効にしてください。

オンプレミスまたは 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 での継続的なレプリケーションの設定に関する情報が記載されています。

セルフ管理 SQL Server での継続的なレプリケーション (セルフ管理 SQL Server) のマネージドロールの使用

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 を自動的にセットアップできます。この機能を使用するには、SetUpMsCdcForTablesECAは、本当です。ECA についての詳細は、エンドポイント設定。

のバージョン用AWS DMS3.4.7 より前の場合や、読み取り専用レプリカをソースとして使用する場合は、次の手順を実行します。

  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 ロールなしでスタンドアロン SQL Server で継続的なレプリケーションを設定する方法については、を参照してください。スタンドアロン SQL Server での継続的なレプリケーションのセットアップ:システム管理者の役割なし。

クラウド SQL Server DB インスタンスに対する許可は、別途付与する必要があります。

このセクションでは、クラウドホストの SQL Server データベースインスタンスで CDC をセットアップする方法について説明します。クラウドホスト型 SQL サーバーインスタンスは、SQL Server 用 Amazon RDS、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値を設定すると、アクティブなトランザクションログレコードが蓄積される可能性があります。この蓄積は、トランザクションログのサイズを増加させることにもつながります。

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

トランザクションログのサイズと MS-CDC ジョブの成功を監視することをお勧めします。MS-CDC ジョブが失敗すると、トランザクションログが過度に大きくなり、原因となる可能性があります。AWS DMSレプリケーション失敗。MS-CDC キャプチャジョブのエラーは、を使用して監視できます。sys.dm_cdc_errorsソースデータベースの動的管理ビュー。トランザクションログのサイズは、を使用して監視できます。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. の値を増やすことで、キャプチャジョブによって処理されるイベントの数を増やしてください。maxtransそしてmaxscansパラメータ値。

    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'

この問題に対処するには、以下の値を設定します。maxscansそしてmaxtransそのためmaxtrans*maxscansは、次のようなテーブルで生成されるイベントの平均数と同じです。AWS DMSは、ソースデータベースからの許可は、別途付与されます。

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

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

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

SQL Server に対する許可は、別途付与する必要があります。

でのSQL Server の圧縮方法のサポートについては、次の点に注意してください。AWS DMS:

  • AWS DMSSQL Server バージョン 2008 以降の行/ページの圧縮をサポートします。

  • AWS DMSは Vardecimal ストレージ形式をサポートしていません。

  • AWS DMSスパース列と列構造圧縮はサポートしていません。

自己管理型 SQL サーバーでの作業 AlwaysOnアベイラビリティグループ

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

ではAWS DMS1 つのプライマリまたはセカンダリ可用性グループのレプリカから変更を移行できます。

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

プライマリアベイラビリティグループをのソースとして使用するにはAWS DMS、次の操作を行います。

  1. 可用性レプリカ内のすべての SQL Server インスタンスの配布オプションを有効にします。詳細については、「自己管理型 SQL Server に対する許可は、別途付与する必要があります。」を参照してください。

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

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

2 つ目の可用性グループのレプリカでの作業

セカンダリ可用性グループをソースとして使用するには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 リゾルバーを設定します。詳細については、「 独自のオンプレミスネームサーバーの使用」を参照してください。

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

    追加接続属性 値 メモ
    applicationIntent ReadOnly この ODBC 設定がないと、レプリケーションタスクはプライマリ可用性グループのレプリカにルーティングされます。詳細については、次を参照してください。高可用性、障害回復のための SQL Server ネイティブクライアントのSupportSQL Server のドキュメントに記載されています。
    multiSubnetFailover yes 詳細については、次を参照してください。高可用性、障害回復のための SQL Server ネイティブクライアントのSupportSQL Server のドキュメントに記載されています。
    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) のソースデータベースとして、自己管理型のセカンダリ可用性グループレプリカを使用できます。Cloud SQL Server のマルチ AZ リードレプリカは、サポートされていません。以前のバージョンを使用している場合AWS DMS必ず CDC のソースデータベースとしてプライマリ可用性グループのレプリカを使用してください。

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

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

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

はAWS DMSユーザーアカウントは、最低でもdb_owner接続先のソース SQL Server データベースのユーザーロール。

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

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

次の表は、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 DMSSQL Server ログリーダーエージェントが実行中である必要があるため、AWS DMSレプリケーション対象としてマークされたトランザクションをアクティブな TLOG から移動できます。ログリーダーエージェントが実行されていないと、アクティブな TLOG がいっぱいになり、問題が解決されるまでソースデータベースが読み取り専用モードに切り替わる可能性があることに注意してください。以外の目的でデータベースの Microsoft レプリケーションを有効にする必要がある場合AWS DMSその場合は、この設定を選択する必要があります。

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

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

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

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

    • この設定は、次のような場合には使用できません。Microsoft SQL サーバーの移行ジョブはリモートのディストリビューターマシン上で実行されます。なぜならAWS DMSリモートマシンに対する許可は、付与されていません。

    • EXCLUSIVE_AUTOMATIC_TRUNCATIONAmazon RDS for SQL Server ソースインスタンスなどAmazon RDS のソースインスタンスでは動作しません。sp_repldoneストアドプロシージャ。

    • 設定した場合SafeguardPolicyにEXCLUSIVE_AUTOMATIC_TRUNCATIONsysadmin ロールを使用しない場合は、に対する許可は、付与する必要があります。dbo.syscategoriesそしてdbo.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 を有効にします。この値を次のように設定します。trueを実行するsp_cdc_enable_dbソースデータベースでストアドプロシージャを実行し、sp_cdc_enable_tableソースデータベースで MS-Replication が有効になっていないタスク内の各テーブルに対してストアドプロシージャを実行します。配布の有効化に関する詳細は、を参照してください。自己管理型 SQL Server に対する許可は、別途付与する必要があります。。

有効な値: {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

に設定するとtrueSQL Server データベースリカバリモデルが次のように設定されていると、この設定により致命的なエラーが発生します。simple。

デフォルト値: false

有効な値: true または false

例: '{"FatalOnSimpleModel": true}'

TlogAccessMode

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

デフォルト値: PreferTlog

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

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

ForceLobLookup

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

デフォルト値: false

有効な値: true、false

例: '{"ForceLobLookup": false}'

EnableNonSysadminWrapper

このエンドポイント設定は、sysadmin ユーザーなしでスタンドアロン SQL Server で継続的なレプリケーションを設定する場合に使用します。このパラメータは、でサポートされていますAWS DMSバージョン 3.4.7 以降。スタンドアロン SQL Server での継続的なレプリケーションのセットアップ方法については、を参照してください。スタンドアロン SQL Server での継続的なレプリケーション (システム管理者ロールなし)。

デフォルト値: false

有効な値: true、false

例: '{"EnableNonSysadminWrapper": true}'

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、の使用は、有効にする必要があります SupportLobs 特定のタスク用。Lob サポートの有効化に関する詳細については、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 データ型として扱われます。