일부 오류의 경우 Database Migration Service는 마이그레이션 프로세스를 계속하고 중단을 방지하기 위해 잘못된 작업을 자동으로 다시 시도합니다.
마이그레이션 작업 상태가 오류가 있는 실행 중으로 변경됩니다. 이 상태는 Database Migration Service가 오류의 영향을 받지 않고 데이터를 계속 마이그레이션하고 있음을 나타냅니다.
일부 오류는 복구할 수 없습니다. 복구할 수 없는 오류가 Database Migration Service에 발생하면 이전 작업 상태가 실패로 변경됩니다.
이러한 시나리오에서는 문제가 해결된 후 마이그레이션 작업을 다시 시작해야 합니다.
오류를 해결하려면 영향을 받는 이전 작업으로 이동하여 오류를 확인하고 오류 메시지에 설명된 단계를 따르세요. Cloud SQL 대상 인스턴스의 Cloud Monitoring 로그를 확인하여 자세한 내용을 확인할 수도 있습니다. 이전 작업 세부정보 페이지에서 Cloud Monitoring 링크를 사용합니다.
다음 표에서 문제의 예와 해결 방법을 확인할 수 있습니다.
문제 설명
문제 원인
해결 방법
오류 메시지: 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}.
SQL Server용 Cloud SQL 대상 인스턴스에서 사용하는 버전보다 상위 버전의 SQL Server에서 백업 파일을 가져오려고 합니다.
Database Migration Service는 교차 버전 호환성 가이드라인을 충족하는 경우에만 하위 버전에서 상위 버전으로의 교차 버전 마이그레이션을 지원합니다.
지원되는 소스 및 대상 데이터베이스를 참고하세요.
이후 버전의 SQL Server를 사용하도록 SQL Server용 Cloud SQL 대상 인스턴스를 다시 만들고 새 인스턴스로 이전 프로세스를 다시 시도합니다.
오류 메시지:
The following database already exists in destination: {database_name}
Cloud SQL 대상 인스턴스에 이미 마이그레이션 작업에 포함된 데이터베이스 중 하나와 동일한 이름을 사용하는 데이터베이스가 있습니다.
오류 메시지:
Permission denied for {cloudsql.databases.get} on the Database Migration Service service account.
Database Migration Service 서비스 계정에 권한이 없습니다.
데이터베이스 이전 서비스 서비스 계정에 누락된 권한을 추가합니다.
IAM으로 액세스 제어를 참고하세요.
오류 메시지:
Missing WAL file at Log Sequence Number (LSN) {log_number_here}
트랜잭션 로그 파일에서 포함된 업데이트 순서와 관련하여 잘못된 epoch 타임스탬프를 사용하고 있을 수 있습니다.
Database Migration Service는 로그 시퀀스 번호와 에포크 타임스탬프를 사용하여 트랜잭션 로그 파일이 Cloud SQL 대상 인스턴스에 복제되는 순서를 제어합니다.
선택한 데이터베이스를 마이그레이션했는데 마이그레이션 작업에서 하나 이상의 데이터베이스에 데이터를 복제할 수 없는 경우 데이터베이스 목록에 실패 상태가 표시됩니다.
다양한 마이그레이션 작업 오류
오류 열에서 오류 보기를 클릭하고 오류를 수정합니다. 오류를 수정한 후 Restart를 클릭합니다.
오류: 대상에 데이터베이스가 이미 있음
다음과 같은 오류 메시지가 표시됩니다. The following database already exists in destination: {database_name}
문제 원인
Cloud SQL 대상 인스턴스에 이미 마이그레이션 작업에 포함된 데이터베이스 중 하나와 동일한 이름을 사용하는 데이터베이스가 있습니다.
해결 방법
이전 시나리오에 따라 중복 데이터베이스 문제를 해결하는 방법은 여러 가지가 있습니다. 다음 작업 중 하나를 시도해 보세요.
소스 Cloud Storage 버킷의 이름을 바꿔 다른 이름으로 데이터베이스를 이전합니다.
Database Migration Service가 대상 Cloud SQL 인스턴스에 만드는 데이터베이스 이름은 백업 파일을 저장하는 Cloud Storage의 폴더 이름에서 파생됩니다. 이름을 공유하고 Cloud SQL 대상에 둘 다 필요한 두 개의 서로 다른 데이터베이스가 있는 경우 폴더 이름을 바꾸고 마이그레이션 작업을 다시 만들어 이름 충돌을 방지할 수 있습니다.
기존 마이그레이션 작업에 새 데이터베이스를 추가할 수 있지만 마이그레이션 작업에서 데이터베이스를 삭제할 수는 없습니다. 따라서 전체 마이그레이션 작업을 다시 만들어야 합니다.
SQL Server용 Cloud SQL 인스턴스에서 중복 데이터베이스를 삭제합니다.
Cloud SQL 대상 인스턴스의 데이터베이스가 중복된 경우 인스턴스에서 데이터베이스를 삭제하고 마이그레이션 작업을 계속할 수 있습니다.
SQL Server용 Cloud SQL 문서의 데이터베이스 삭제를 참고하세요.
순서가 잘못된 WAL 파일의 트랜잭션 로그 파일 이름 조정
문제 원인
트랜잭션 로그 파일에서 포함된 업데이트 순서와 관련하여 잘못된 epoch 타임스탬프를 사용하고 있을 수 있습니다.
Database Migration Service는 로그 시퀀스 번호와 에포크 타임스탬프를 사용하여 트랜잭션 로그 파일이 Cloud SQL 대상 인스턴스에 복제되는 순서를 제어합니다.
해결 방법
파일 업로드가 지연되거나 순서가 잘못될 수 있습니다. 문제가 해결될 때까지 몇 분 정도 기다리거나 Cloud Storage 버킷에 누락된 파일이 있는지 확인합니다.
거래 로그 파일의 모든 가져오기 작업을 확인하고 파일 이름에 올바른 에포크 타임스탬프가 포함되어 있는지 확인합니다.
최근 트랜잭션 로그 파일에서 순서가 잘못된 epoch 타임스탬프가 포함된 이름을 사용하는 경우 Cloud Storage 버킷으로 이동하여 파일 이름을 바꿉니다.
Database Migration Service는 변경사항을 자동으로 감지하고 관련 트랜잭션 로그 파일을 가져오려고 시도합니다.
Amazon RDS만 해당: S3로 내보내는 과정에서 일부 트랜잭션 로그 파일이 누락되었을 수 있습니다. 누락된 WAL 파일 주변 기간에 대한 트랜잭션 로그 내보내기 함수를 다시 실행해 보세요.
[[["이해하기 쉬움","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"]]
