翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
のソースとしての 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 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 のソースからの継続的なレプリケーション (CDC) を使用するための前提条件
- オンプレミスまたは Amazon EC2 上のセルフマネージド型 SQL Server のデータ変更のキャプチャ
- Cloud SQL Server DB インスタンスでの継続的なレプリケーションのセットアップ
- のソースとして Amazon RDS for SQL Server を使用する場合の推奨設定 AWS DMS
- SQL Server でサポートされている圧縮方法
- セルフマネージド SQL Server AlwaysOn 可用性グループの使用
- のソースとして SQL Server を使用する場合のセキュリティ要件 AWS Database Migration Service
- のソースとして SQL Server を使用する場合のエンドポイント設定 AWS DMS
- SQL Server のソースデータ型
のソースとして SQL Server を使用する場合の制限 AWS DMS
SQL Server データベースを AWS DMS のソースとして使用する場合は、以下の制限が適用されます。
-
列のアイデンティティプロパティは、ターゲットデータベース列に移行されません。
-
SQL Server エンドポイントは、スパース列でのテーブルの使用をサポートしていません。
-
Windows 認証はサポートされていません。
-
SQL Server の計算済みフィールドの変更はレプリケーションされていません。
-
一時テーブルはサポートされていません。
-
SQL Server パーティション切り替えはサポートされていません。
-
WRITETEXT ユーティリティと UPDATETEXT ユーティリティを使用する場合、ソースデータベースに適用されたイベントはキャプチャ AWS DMS されません。
-
次のデータ操作言語 (DML) パターンはサポートされていません。
SELECT * INTO
new_table
FROMexisting_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
の場合、ディストリビューションは設定されていません。ディストリビューションを設定するには、次の手順を使用します。
ディストリビューションを設定するには
-
SQL Server Management Studio (SSMS) ツールを使用して SQL Server ソースデータベースに接続します。
-
[Replication] (レプリケーション) フォルダのコンテキスト (右クリック) メニューを開き、[Configure Distribution] (ディストリビューション設定) を選択します。ディストリビューションの構成ウィザードが開きます。
-
ウィザードに従ってデフォルト値を入力し、ディストリビューションを作成します。
CDC をセットアップするには
AWS DMS バージョン 3.4.7 以降では、読み取り専用レプリカを使用していない場合、データベースとすべてのテーブルに MS CDC を自動的に設定できます。この機能を使用するには、SetUpMsCdcForTables
ECA を true に設定します。ECA の詳細については、「エンドポイント設定」を参照してください。
3.4.7 より 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 での継続的なレプリケーションのセットアップ: 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 を有効にするには
-
次のクエリのいずれかをデータベース レベルで実行します。
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 -
プライマリ キーがあるテーブルごとに、次のクエリを実行して 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
-
次のコマンドを使用して、ソースで変更を使用できる保持期間を設定します。
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 レプリケーションタスク中に保持期間を維持するには
-
次のコマンドを使用して、トランザクションログを切り捨てるジョブを停止します。
exec sp_cdc_stop_job 'capture'
-
AWS DMS コンソールでタスクを検索し、タスクを再開します。
-
[Monitoring] (モニタリング) タブを選択し、
CDCLatencySource
メトリクスを選択します。 -
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 をソースとして使用する場合、キャプチャジョブはパラメータ maxscans
と maxtrans
に依存しています。このようなパラメータは、キャプチャがトランザクションログに対して実行するスキャンの最大数と、スキャンごとに処理されるトランザクション数を制御します。
データベースでは、トランザクション数が 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 によるトランザクション ログの増加に対処するには
-
データベース
Log Space Used %
の AWS DMS が からレプリケートされていることを確認し、継続的に増加することを確認します。DBCC SQLPERF(LOGSPACE)
-
トランザクションログのバックアッププロセスをブロックしている要因を特定します。
Select log_reuse_wait, log_reuse_wait_desc, name from sys.databases where name = db_name();
log_reuse_wait_desc
値がREPLICATION
と等しい場合、ログバックアップの保持は MS-CDC のレイテンシーが原因です。 -
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 のレイテンシーが増加し、トランザクションログが増大します。
ワークロードの変化により生成されるイベントの数が変化するため、maxtrans
と maxscans
の適切な値を特定することが困難である場合があります。この場合、MS-CDC のレイテンシーのモニタリングを設定することをお勧めします。詳細については、SQL Server ドキュメントの「プロセスを監視するmaxtrans
と maxscans
を動的に設定します。
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)
この問題を軽減するには、maxtrans
と maxscans
の値を上記の推奨のとおりに設定します。
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、次の手順を実行します。
可用性レプリカ内のすべての SQL Server インスタンスでディストリビューションオプションを有効にします。詳細については、「セルフマネージド型 SQL Server での継続的なレプリケーションのセットアップ」を参照してください。
AWS DMS コンソールで、SQL Server ソースデータベース設定を開きます。[サーバー名] には、可用性グループリスナーのために設定したドメインネームサービス (DNS) 名または IP アドレスを指定します。
AWS DMS タスクを初めて開始する場合、開始に通常よりも時間がかかることがあります。このような速度の低下は、テーブルアーティクルの作成が可用性グループサーバーによりレプリケートされるために発生します。
セカンダリ可用性グループレプリカの使用
セカンダリ可用性グループを のソースとして使用するには AWS DMS、次の手順を実行します。
-
個々のレプリカへの接続には、 AWS DMS ソースエンドポイントユーザーが使用するものと同じ認証情報を使用します。
-
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>';
ソースエンドポイントを作成する際、エンドポイントの [サーバー名] またはエンドポイントのシークレットの [サーバーアドレス] として可用性グループリスナーの DNS 名を指定します。可用性グループリスナーの詳細については、SQL Server ドキュメントの「可用性グループリスナーとは
」を参照してください。 パブリック DNS サーバーまたはオンプレミスの DNS サーバーのいずれかを使用して、可用性グループリスナー、プライマリレプリカ、セカンダリレプリカを解決できます。オンプレミスの DNS サーバーを使用するには、Amazon Route 53 Resolver を設定します。詳細については、「 独自のオンプレミスネームサーバーの使用」を参照してください。
次の追加の接続属性をソースエンドポイントに追加します。
追加の接続属性 値 メモ 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
詳細については、「制限事項」を参照してください。 可用性グループ内のすべてのレプリカでディストリビューションオプションを有効にします。すべてのノードをディストリビューターリストに追加します。詳細については、「ディストリビューションを設定するには」を参照してください。
プライマリ読み取り/書き込みレプリカで次のクエリを実行して、データベースの公開を有効にします。このクエリはデータベースに対して 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 '{"
構文で使用してAWS CLI、ソースエンドポイントを作成するときに設定を指定します。EndpointSetting"
: "value"
, ...
}'
次の表は、ソースとして SQL Server を使用できるエンドポイント設定を説明しています。
名前 | 説明 |
---|---|
|
この属性は Safeguard をオンまたはオフにする。 デフォルト値: 有効な値: { 例: |
AlwaysOnSharedSynchedBackupIsEnabled |
この属性は、Always On 可用性グループクラスターの一部としてホストされている SQL Server ソースデータベースから移行 AWS DMS するときの の動作を調整します。 AWS DMS では、Always On クラスターで実行するように設定された SQL Server ソースデータベースのサポートが強化されています。この場合、 AWS DMS は、ソースデータベース インスタンスがホストされているノード以外の Always On クラスタ内のノードからトランザクション バックアップが実行されているかどうかを追跡しようとします。移行タスクの起動時に、 はクラスター内の各ノードへの接続 AWS DMS を試みますが、いずれかのノードに接続できない場合は失敗します。 Always On クラスター内のすべてのノードでトランザクションバックアップを AWS DMS ポーリングする必要がある場合は、この属性を に設定します デフォルト値: 有効な値: 例: |
|
この ODBC ドライバー属性設定により、SQL Server はレプリケーションタスクを最も優先度の高い読み取り専用ノードにルーティングする。この設定を行わないと、SQL Server はレプリケーションタスクをプライマリ読み取り/書き込みノードにルーティングする。 |
|
sysadmin ユーザーを使用せずにスタンドアロン SQL Server 上で継続的なレプリケーションを設定する場合、このエンドポイント設定を使用する。このパラメータは、 AWS DMS バージョン 3.4.7 以降でサポートされています。スタンドアロン SQL Server での継続的なレプリケーションの設定については、「スタンドアロン SQL Server での継続的なレプリケーションのセットアップ: sysadmin ロールなし」を参照。 デフォルト値: 有効な値: 例: |
|
この追加の接続属性 (ECA) を使用して、SQL Server インスタンスのクライアントステートメントのタイムアウトを秒単位で設定する。デフォルト値は 60 秒です。 例: |
|
デフォルト値: 有効な値: 例: |
|
インライン LOB で LOB ルックアップを強制する。 デフォルト値: 有効な値: 例: |
|
この ODBC ドライバ属性によって、可用性グループのフェールオーバー時に DMS が新しいプライマリに接続しやすくなります。この属性は、接続が切断されているか、リスナーの IP アドレスが正しくない状況向けに設計されています。このような状況では、 は可用性グループリスナーに関連付けられているすべての IP アドレスへの接続 AWS DMS を試みます。 |
|
この属性を使用するには、sysadmin 権限が必要です。この属性が に設定されている場合 有効な値: 例: 注意:このパラメータは、RDS がバックアップを実行する方法であるため、Amazon RDS SQL Server ソースインスタンスでは機能しません。 |
|
最適なパフォーマンスを得るために、 AWS DMS は、アクティブなトランザクションログ (TLOG) から未読の変更をすべてキャプチャしようとします。ただし、切り捨てが原因で、アクティブな TLOG に未読の変更がすべて含まれていない場合がある。これが発生すると、 はログバックアップ AWS DMS にアクセスして欠落している変更をキャプチャします。ログバックアップにアクセスする必要性を最小限に抑えるために、 は次のいずれかの方法を使用して切り捨て AWS DMS を防止します。
デフォルト値: 有効な値: { 例: |
|
この属性は、ソースデータベースと MS-Replication が有効になっていないタスクマッピング内のテーブルの MS-CDC を有効にする。この値を 有効な値: { 例: |
|
CDC データをフェッチするために使用されるモードを示す。 デフォルト値: 有効値: 例: |
|
この属性が |
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 サポートの有効化に関する詳細については、タスク内のソースデータベースの LOB サポートの設定 AWS DMS をご参照ください。 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 データ型として扱われます。