Skip to content

Commit 63dd5d5

Browse files
Merge pull request #273747 from abhims14/patch-7
Update faq.yml
2 parents 7acd480 + 0ccd08a commit 63dd5d5

File tree

1 file changed

+11
-5
lines changed

1 file changed

+11
-5
lines changed

articles/dms/faq.yml

Lines changed: 11 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -62,12 +62,18 @@ sections:
6262
- question: |
6363
How can I ensure that DMS has migrated all the data from the source database to Azure SQL Targets?
6464
answer: |
65-
For Azure SQL VM and Azure SQL MI targets, DMS uses physical migration i.e. using Backup and restore. Data consistency between source and target is ensured as explained below depending on the migration mode chosen.
65+
For Azure SQL VM and Azure SQL MI targets, DMS uses physical migration i.e., using backup and restore. As described below, the migration mode chosen determines how the data is kept consistent between source and target.
66+
67+
* Offline migration: During offline migration to Azure SQL VM and Azure SQL MI targets, application downtime starts when the migration starts. DMS will restore all the backup files to the Target, as long as the latest backup file/s from source have been transferred to SMB network storage or to Azure blob container (as per the migration configuration). If the backup is taken with the CHECKSUM option, DMS restore operation automatically performs the validation. In the absence of checksum, the integrity of the backup is explicitly checked before restoring. This ensures that the restore file is identical to the backup file and hence have the same data. You can verify all the backup files including the last backup file name from source with the backup file applied/restore on target shown on DMS migration monitoring page and validate their respective checksum.
68+
69+
* Online migration: During online migration to Azure SQL VM and Azure SQL MI targets, downtime starts once you initiate the migration cutover along with stopping the application. DMS will restore all the backup files to the Target, as long as the latest backup file/s from source have been transferred to SMB network storage or to Azure blob container (as per the migration configuration). After you press the cutover button, DMS shows the count for pending backup file/s (if any) which are present on the SMB network storage or Azure blob container and yet to be applied/restore on target. If the backup is taken with the CHECKSUM option, DMS restore operation automatically performs the validation. In the absence of checksum, the integrity of the backup is explicitly checked before restoring. This ensures that the restore file is identical to the backup file and hence have the same data. You can verify all the backup files including the last backup file name from source with the backup file applied/restore on target shown on DMS migration monitoring page and validate their respective checksum.
70+
71+
For Azure SQL DB targets, DMS does logical migration in the case of Azure SQL DB i.e., it copies the data from source SQL database’s tables and writes it to the Target Azure SQL DB’s tables. As DMS only supports offline migration to Azure SQL DB, application downtime starts when the migration starts. You can monitor and validate the number of rows read (from source database table) and copied (written to target Azure SQL DB table) from the migration monitoring page. As additional confirmation, you can run the below TSQL to get checksum both at source and destination databases and validate the source and restore data being identical.
72+
73+
"SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
74+
75+
Note: Provided no application/s is/are writing to source or Target DB. You can also leverage tools like [Database Comparison tool](https://techcommunity.microsoft.com/t5/modernization-best-practices-and/database-comparison-tool/ba-p/3249580) for data comparison.
6676
67-
* Offline migration: During offline migration to Azure SQL VM and Azure SQL MI targets, application downtime starts when the migration starts, DMS will ensure that all the backup files get restored to the Target provided the last backup file/s from source is copied to SMB network storage or to blob container (as per the migration configuration). You can verify the last backup file name from source with the last applied backup file applied on target shown on DMS migration monitoring page.
68-
* Online migration: During online migration to Azure SQL VM and Azure SQL MI targets once you initiate the migration cutover and followed by stopping the application, DMS will ensure that all the backup files get restored to the Target provided the last backup file/s from source is copied to SMB network storage or to blob container (as per the migration configuration). It also shows the count for pending backup file/s which are yet to be applied on target, before you complete the migration cutover. You can verify the last backup file name from source with the last applied backup file applied on target shown on DMS migration monitoring page.
69-
70-
For Azure SQL DB targets, DMS does logical migration in case of Azure SQL DB i.e. it copies the data from source SQL database’s tables and write it to the Target Azure SQL DB’s tables. As DMS only support offline migration to Azure SQL DB, application downtime starts when the migration starts, you can monitor and validate the number of rows read (from source database table) and copied (written to target Azure SQL DB table) from the migration monitoring page.
7177
7278
7379
- name: Security

0 commit comments

Comments
 (0)