エラーによっては、Database Migration Service はエラーのあるオペレーションを自動的に再試行して、移行プロセスを続行し、中断を回避します。移行ジョブのステータスが [エラーありで実行中] に変わります。このステータスは、Database Migration Service がエラーの影響を受けないデータを移行し続けていることを示します。
一部のエラーは復元できません。Database Migration Service で復元不可能なエラーが発生すると、移行ジョブのステータスが [失敗] に変わります。このようなシナリオでは、問題を修正した後に移行ジョブを再起動する必要があります。
エラー メッセージ: 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 は、クロスバージョンの互換性ガイドラインを満たしている場合にのみ、下位バージョンから上位バージョンへのクロスバージョン移行をサポートします。
サポートされている移行元および移行先のデータベースをご覧ください。
新しい SQL Server バージョンを使用するように Cloud SQL for 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"]],["最終更新日 2025-09-05 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"]]
