Stay organized with collections
Save and categorize content based on your preferences.
Troubleshoot an error
The migration job process might incur errors during runtime.
For some errors, Database Migration Service automatically retries the faulty operations
to continue the migration process and avoid interruptions.
The migration job status changes to Running with errors. This status
represents the fact that Database Migration Service continues migrating data unaffected
by the errors.
Some errors are unrecoverable. When Database Migration Service encounters an unrecoverable
error, the migration job status changest to Failed.
In such scenarios, the migration job needs to be restarted after the issue is
fixed.
To troubleshoot an error, navigate to the affected migration job, view the error,
and follow the steps outlined in the error message. You can also get more
details by viewing the Cloud Monitoring logs for your Cloud SQL destination
instance. Use the Cloud Monitoring link on the migration job details page.
In the following table, you can find some examples of issues and how they can
be solved:
For this problem...
The issue might be...
Try this...
Error message: The BAK file's database major version number
{backup_version_num} must not be higher than the current database
major version number {your Cloud SQL for SQL Server version number}.
You are attempting to import backup files from a later SQL Server
version than the version you use in your Cloud SQL for SQL Server destination
instance.
Database Migration Service only supports cross-version migrations from lower to
later versions if you meet the cross-version compatibility
guidelines. See
Supported source and destination databases.
Re-create the Cloud SQL for SQL Server destination instance with to use
a later SQL Server version and re-try the migration process
with your new instance.
Error message:
The following database already exists in destination: {database_name}.
Your Cloud SQL destination instance already contains a database
that uses the same name as one of the databases included in your migration
job.
Error message:
Permission denied for {cloudsql.databases.get} on the Database Migration Service service account.
The Database Migration Service service account is missing permissions.
Add the missing permissions to the Database Migration Service service account.
See
Access control with IAM.
Error message:
Missing WAL file at Log Sequence Number (LSN) {log_number_here}
Your transaction log files use might be using incorrect epoch timestamps
with regards to the order of updates they contain.
Database Migration Service uses log sequence numbers and epoch timestamps to control
the order in which transaction log files are replicated to the Cloud SQL
destination instance.
When you migrate selected databases and the migration job is unable to replicate data to one or more databases, a Failed status is displayed in the list of databases.
Various migration job errors.
In the Errors column, click View errors and fix them. After you fix the errors, click Restart.
Error: database already exists in destination
You encounter the following error message:
The following database already exists in destination: {database_name}.
The issue might be
Your Cloud SQL destination instance already contains a database that uses
the same name as one of the databases included in your migration job.
Things to try
Depending on your migration scenario, there are different ways you can solve
the problem of duplicate databases. Try one of the following actions:
Rename the source Cloud Storage bucket to migrate
your database with a different name.
The name of the database that Database Migration Service creates in your destination
Cloud SQL instance is derived from the folder names in Cloud Storage
where you store the backup files. If you have two different databases that
share the name and need them both in your Cloud SQL destination,
you can re-name the folders and re-create the migration job to avoid
the naming conflict.
You can add new databases to an existing migration job, but you can't
remove databases from a migration job. That's why you need to re-create
the whole migration job.
Drop the duplicate database from your Cloud SQL for SQL Server instance.
If the database in your Cloud SQL destination instance is a duplicate,
you can drop it from your instance and continue with the migration job.
See
Delete a database in the Cloud SQL for SQL Server documentation.
Adjust transaction log file names for out of order
WAL files
The issue might be
Your transaction log files use might be using incorrect epoch timestamps
with regards to the order of updates they contain.
Database Migration Service uses log sequence numbers and epoch timestamps to control
the order in which transaction log files are replicated to the Cloud SQL
destination instance.
Things to try
Your file uploads could be delayed or out of order. Wait for several
minutes to allow the issue to resolve or check if there are missing files
in your Cloud Storage bucket.
Check the list of your transaction log import operations on the destination
Cloud SQL for SQL Server instance. In the Google Cloud console, go to the
Cloud SQL Instances page.
Click View all operations > View SQL Server error logs.
View all import operations for transaction log files and verify
if their file names contain correct epoch timestamps.
If you notice that recent transaction log files use names with out of order
epoch timestamps, go to your Cloud Storage bucket and rename the file.
Database Migration Service automatically detects the change and attempts to import
the relevant transaction log files.
Amazon RDS only: It's possible that some transaction log files
were missed during the export to S3 process. Try re-running the transaction
log export function for the period around missing WAL files.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eDatabase Migration Service automatically retries some errors, resulting in a "Running with errors" status, and continues the migration process for unaffected data.\u003c/p\u003e\n"],["\u003cp\u003eUnrecoverable errors cause the migration job to fail, requiring the job to be restarted after the issue is resolved.\u003c/p\u003e\n"],["\u003cp\u003eErrors can be troubleshooted by navigating to the migration job, viewing the error message, and checking Cloud Monitoring logs for more details.\u003c/p\u003e\n"],["\u003cp\u003eDatabase naming conflicts during migration can be resolved by either renaming the source Cloud Storage bucket folders or dropping the duplicate database from the Cloud SQL instance.\u003c/p\u003e\n"],["\u003cp\u003eIssues with transaction log file order can be addressed by adjusting epoch timestamps in the file names and checking for missing files in the Cloud Storage bucket.\u003c/p\u003e\n"]]],[],null,["# Diagnose issues for SQL Server\n\nTroubleshoot an error\n---------------------\n\nThe migration job process might incur errors during runtime.\n\n- For some errors, Database Migration Service automatically retries the faulty operations to continue the migration process and avoid interruptions. The migration job status changes to **Running with errors**. This status represents the fact that Database Migration Service continues migrating data unaffected by the errors.\n- Some errors are unrecoverable. When Database Migration Service encounters an unrecoverable error, the migration job status changest to **Failed**. In such scenarios, the migration job needs to be restarted after the issue is fixed.\n\nTo troubleshoot an error, navigate to the affected migration job, view the error,\nand follow the steps outlined in the error message. You can also get more\ndetails by viewing the Cloud Monitoring logs for your Cloud SQL destination\ninstance. Use the Cloud Monitoring link on the migration job details page.\n\nIn the following table, you can find some examples of issues and how they can\nbe solved:\n\n### Error: database already exists in destination\n\nYou encounter the following error message:\n`The following database already exists in destination: {database_name}`.\n\n#### The issue might be\n\nYour Cloud SQL destination instance already contains a database that uses\nthe same name as one of the databases included in your migration job.\n\n#### Things to try\n\nDepending on your migration scenario, there are different ways you can solve\nthe problem of duplicate databases. Try one of the following actions: \n\n#### Rename the source Cloud Storage bucket to migrate\nyour database with a different name.\n\nThe name of the database that Database Migration Service creates in your destination\nCloud SQL instance is derived from the folder names in Cloud Storage\nwhere you store the backup files. If you have two different databases that\nshare the name and need them both in your Cloud SQL destination,\nyou can re-name the folders and re-create the migration job to avoid\nthe naming conflict.\n\nPerform the following steps:\n\n1. Create new folders for the source database that is affected by the naming conflict. See [Store backup files in a Cloud Storage bucket](/database-migration/docs/sqlserver/storage-buckets).\n2. Re-create your migration job. See [Create a migration job](/database-migration/docs/sqlserver/create-migration-job).\n\n You can add new databases to an existing migration job, but you can't\n remove databases from a migration job. That's why you need to re-create\nthe whole migration job. \n\n#### Drop the duplicate database from your Cloud SQL for SQL Server instance.\n\nIf the database in your Cloud SQL destination instance is a duplicate,\nyou can drop it from your instance and continue with the migration job.\nSee\n[Delete a database](/sql/docs/mysql/create-manage-databases#delete) in the Cloud SQL for SQL Server documentation.\n\n*** ** * ** ***\n\n### Adjust transaction log file names for out of order\nWAL files\n\n\u003cbr /\u003e\n\n#### The issue might be\n\nYour transaction log files use might be using incorrect epoch timestamps\nwith regards to the order of updates they contain.\nDatabase Migration Service uses log sequence numbers and epoch timestamps to control\nthe order in which transaction log files are replicated to the Cloud SQL\ndestination instance.\n\n#### Things to try\n\nYour file uploads could be delayed or out of order. Wait for several\nminutes to allow the issue to resolve or check if there are missing files\nin your Cloud Storage bucket.\n\nIf the issue isn't resolved, verify and adjust the\n[epoch timestamps in your transaction log file names](/database-migration/docs/sqlserver/export-backup-files).\n\nPerform the following steps:\n\n1. Check the list of your transaction log import operations on the destination Cloud SQL for SQL Server instance. In the Google Cloud console, go to the **Cloud SQL Instances** page.\n\n [Go to Cloud SQL Instances](https://console.cloud.google.com/sql)\n2. Click **View all operations \\\u003e View SQL Server error logs**.\n3. View all import operations for transaction log files and verify if their file names contain correct epoch timestamps.\n4. If you notice that recent transaction log files use names with out of order epoch timestamps, go to your Cloud Storage bucket and rename the file. Database Migration Service automatically detects the change and attempts to import the relevant transaction log files.\n5. **Amazon RDS only**: It's possible that some transaction log files were missed during the export to S3 process. Try re-running the transaction log export function for the period around missing WAL files.\n\n\u003cbr /\u003e"]]
