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

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

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

を使用して、1 つまたは複数の Microsoft SQL Server データベースからデータを移行します AWS DMS。ソースとして 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 をソースとして使用している場合、列レベルの暗号化はサポートされていません。

  • 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 Replication Publisher 定義は削除されません。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 TABLEステートメントで ALTER COLUMN [SET|DROP] NOT NULL句を使用)。

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

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

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

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

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

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

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

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

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

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

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

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

  • AWS DMS は、単一のトランザクション内でのデータ定義言語 (DDL) およびデータ操作言語 (DML) ステートメントのキャプチャをサポートしていません。

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

  • プライマリキーまたは一意のインデックスが関連し、複数のデータ行を更新する UPDATE ステートメントについては、ターゲットデータベースに変更を適用すると競合が発生する可能性があります。これは例えば、ターゲットデータベースが単一の UPDATE ステートメントではなく INSERT や DELETE のステートメントとして更新を適用する場合に発生する可能性があります。バッチ最適化の適用モードでは、テーブルが無視されることがあります。トランザクション適用モードでは、UPDATE 操作により制約違反が発生する可能性があります。この問題を回避するには、関連するテーブルをもう一度ロードします。または、例外の適用コントロールテーブル (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 に保存されたバックアップはサポートされていません。

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

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

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

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

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

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

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

  • 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 での継続的なレプリケーションのセットアップ: sysadmin ロールを使用

AWS DMS SQL Server の 継続的レプリケーションでは、プライマリ キーを持つテーブルにはネイティブ 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 ロールなし」を参照してください。

Cloud SQL Server DB インスタンスでの継続的なレプリケーションのセットアップ

このセクションでは、クラウドでホストされている SQL Server のデータベースインスタンスで CDC をセットアップする方法について説明します。クラウドでホストされる SQL Serverインスタンスは、Amazon RDS for SQL Server、Azure SQL Manged Instance、またはその他のマネージド型 Cloud 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 をオンにする必要があります。

Cloud 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-Log エントリを読み取る前に、T-Log 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 インスタンスのストレージがいっぱいになる可能性があります。

Cloud SQL Server DB インスタンスでの継続的なレプリケーションの制限

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

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

のソースとして Amazon RDS for SQL Server を使用する場合の推奨設定 AWS DMS

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

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

AWS DMS は MS-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. 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'

この問題に対処するには、 maxscansと の値を設定します。maxtransこれは、 maxtrans*maxscansがソースデータベースからレ AWS DMS プリケートするテーブルに対して毎日生成されるイベントの平均数と等しくなります。

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

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

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

注記

AWS DMS を使用して RDS for SQL Server ソースからデータをレプリケートする場合、Amazon RDS インスタンスの停止イベント後にレプリケーションを再開しようとすると、エラーが発生する可能性があります。これは、SQL Server エージェントプロセスが停止または開始のイベントの後に再起動する際、キャプチャジョブプロセスを再起動するためです。これにより、MS-CDC のポーリング間隔がバイパスされます。

このため、MS-CDC キャプチャジョブ処理よりもトランザクションボリュームの低いデータベースでは、 が停止した場所から再開 AWS DMS する前に、データが処理またはレプリケートおよびバックアップとしてマークされ、次のエラーが発生する可能性があります。

[SOURCE_CAPTURE ]E: Failed to access LSN '0000dbd9:0006f9ad:0003' in the backup log sets since BACKUP/LOG-s are not available. [1020465] (sqlserver_endpoint_capture.c:764)

この問題を軽減するには、maxtransmaxscans の値を上記の推奨のとおりに設定します。

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

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

  • AWS DMS は、SQL Server バージョン 2008 以降で行/ページ圧縮をサポートしています。

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

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

セルフマネージド SQL Server AlwaysOn 可用性グループの使用

SQL Server の Always On 可用性グループは、データベースミラーリングに代わるエンタープライズレベルの代替方法を提供する高可用性と災害復旧ソリューションです。

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

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

プライマリ可用性グループを のソースとして使用するには AWS DMS、次の手順を実行します。
  1. 可用性レプリカ内のすべての SQL Server インスタンスでディストリビューションオプションを有効にします。詳細については、「セルフマネージド型 SQL Server での継続的なレプリケーションのセットアップ」を参照してください。

  2. AWS DMS コンソールで、SQL Server ソースデータベース設定を開きます。[サーバー名] には、可用性グループリスナーのために設定したドメインネームサービス (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 Native Client の HADR サポート」を参照。
    multiSubnetFailover yes 詳細については、SQL Server ドキュメントの「 SQL Server Native Client の HADR サポート」を参照。
    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 ユーザーアカウントには、少なくとも接続先のソース SQL Server データベースのdb_ownerユーザーロールが必要です。

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

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

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

名前 説明

ActivateSafeguard

この属性は Safeguard をオンまたはオフにする。SafeguardPolicy の詳細については、次を参照。

デフォルト値: true

有効な値: {false, true}

例: '{"ActivateSafeguard": true}'

AlwaysOnSharedSynchedBackupIsEnabled

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

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

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

デフォルト値: true

有効な値: true または false

例: '{"AlwaysOnSharedSynchedBackupIsEnabled": false}'

"ApplicationIntent": "readonly"

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

EnableNonSysadminWrapper

sysadmin ユーザーを使用せずにスタンドアロン SQL Server 上で継続的なレプリケーションを設定する場合、このエンドポイント設定を使用する。このパラメータは、 AWS DMS バージョン 3.4.7 以降でサポートされています。スタンドアロン SQL Server での継続的なレプリケーションの設定については、「スタンドアロン SQL Server での継続的なレプリケーションのセットアップ: sysadmin ロールなし」を参照。

デフォルト値: false

有効な値: truefalse

例: '{"EnableNonSysadminWrapper": true}'

ExecuteTimeout

この追加の接続属性 (ECA) を使用して、SQL Server インスタンスのクライアントステートメントのタイムアウトを秒単位で設定する。デフォルト値は 60 秒です。

例: '{"ExecuteTimeout": 100}'

FatalOnSimpleModel

true に設定する場合、SQL Server データベースの復旧モデルが simple に設定されていると、このパラメータは致命的エラー発生させる。

デフォルト値: false

有効な値: true または false

例: '{"FatalOnSimpleModel": true}'

ForceLobLookup

インライン LOB で LOB ルックアップを強制する。

デフォルト値: false

有効な値: truefalse

例: '{"ForceLobLookup": false}'

"MultiSubnetFailover": "Yes"

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

ReadBackupOnly

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

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

例: '{"ReadBackupOnly": Y}'

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

SafeguardPolicy

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

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

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

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

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

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

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

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

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

    • sysadmin ロールを使用せずに SafeguardPolicyEXCLUSIVE_AUTOMATIC_TRUNCATION に設定する場合は、dbo.syscategories オブジェクトと dbo.sysjobs オブジェクトに対するアクセス権限を dmsuser ユーザーに付与する必要がある。

デフォルト値: RELY_ON_SQL_SERVER_REPLICATION_AGENT

有効な値: {EXCLUSIVE_AUTOMATIC_TRUNCATION, RELY_ON_SQL_SERVER_REPLICATION_AGENT}

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

SetUpMsCdcForTables

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

有効な値: {true, false}

例: '{"SetUpMsCdcForTables": true}'

TlogAccessMode

CDC データをフェッチするために使用されるモードを示す。

デフォルト値: PreferTlog

有効値: BackupOnlyPreferBackupPreferTlogTlogOnly

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

Use3rdPartyBackupDevice

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

SQL Server のソースデータ型

のソースとして SQL Server を使用するデータ移行では、ほとんどの SQL Server データ型 AWS DMS がサポートされます。次の表は、 の使用時にサポートされる SQL Server ソースデータ型 AWS DMS と 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 Server 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 ステートメントに対しても、 はターゲットの LOB 列 AWS DMS を更新します。

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

NCHAR

WSTRING

NVARCHAR (長さ)

WSTRING

NVARCHAR (最大)

NCLOB

NTEXT

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

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

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

BINARY

BYTES

VARBINARY

BYTES

VARBINARY (最大)

BLOB

IMAGE

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

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

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

TIMESTAMP

BYTES

UNIQUEIDENTIFIER

STRING

HIERARCHYID

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

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

XML

NCLOB

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

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

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

GEOMETRY

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

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

GEOGRAPHY

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

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

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

  • CURSOR

  • SQL_VARIANT

  • TABLE

注記

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