错误消息：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}。
您尝试导入的备份文件来自比您在 Cloud SQL for SQL Server 目标实例中使用的 SQL Server 版本更高版本。
只有当您满足跨版本兼容性准则时，Database Migration Service 才支持从较低版本向较高版本的跨版本迁移。请参阅
支持的源数据库和目标数据库。
重新创建 Cloud SQL for SQL Server 目标实例，以使用较高版本的 SQL Server，然后使用新实例重新尝试迁移过程。
错误消息：The following database already exists in destination: {database_name}。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-05。"],[[["\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"]]
