Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Memecahkan masalah error
Proses tugas migrasi mungkin mengalami error selama runtime.
Untuk beberapa error, Database Migration Service akan otomatis mencoba kembali operasi yang salah
untuk melanjutkan proses migrasi dan menghindari gangguan.
Status tugas migrasi berubah menjadi Berjalan dengan error. Status ini
menunjukkan fakta bahwa Database Migration Service terus memigrasikan data yang tidak terpengaruh
oleh error.
Beberapa error tidak dapat dipulihkan. Jika Database Migration Service mengalami error yang tidak dapat dipulihkan, status tugas migrasi akan berubah menjadi Gagal.
Dalam skenario tersebut, tugas migrasi perlu dimulai ulang setelah masalah
diperbaiki.
Untuk memecahkan masalah error, buka tugas migrasi yang terpengaruh, lihat error,
dan ikuti langkah-langkah yang diuraikan dalam pesan error. Anda juga bisa mendapatkan detail
selengkapnya dengan melihat log Cloud Monitoring untuk instance tujuan Cloud SQL Anda. Gunakan link Cloud Monitoring di halaman detail tugas migrasi.
Dalam tabel berikut, Anda dapat menemukan beberapa contoh masalah dan cara mengatasinya:
Untuk masalah ini...
Kemungkinan masalah...
Coba langkah ini...
Pesan error: 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}.
Anda mencoba mengimpor file cadangan dari versi SQL Server yang lebih baru daripada versi yang Anda gunakan di instance tujuan Cloud SQL untuk SQL Server.
Database Migration Service hanya mendukung migrasi lintas versi dari versi yang lebih lama ke
versi yang lebih baru jika Anda memenuhi panduan kompatibilitas
lintas versi. Lihat
Database sumber dan tujuan yang didukung.
Buat ulang instance tujuan Cloud SQL untuk SQL Server dengan menggunakan
versi SQL Server yang lebih baru dan coba lagi proses migrasi
dengan instance baru Anda.
Pesan error:
The following database already exists in destination: {database_name}.
Instance tujuan Cloud SQL Anda sudah berisi database yang menggunakan nama yang sama dengan salah satu database yang disertakan dalam tugas migrasi Anda.
Pesan error:
Permission denied for {cloudsql.databases.get} on the Database Migration Service service account.
Akun layanan Database Migration Service tidak memiliki izin.
Tambahkan izin yang tidak ada ke akun layanan Database Migration Service.
Lihat
Kontrol akses dengan IAM.
Pesan error:
Missing WAL file at Log Sequence Number (LSN) {log_number_here}
File log transaksi Anda mungkin menggunakan stempel waktu epoch yang salah
sehubungan dengan urutan update yang dikandungnya.
Database Migration Service menggunakan nomor urutan log dan stempel waktu epoch untuk mengontrol
urutan file log transaksi yang direplikasi ke instance tujuan
Cloud SQL.
Saat Anda memigrasikan database yang dipilih dan tugas migrasi tidak dapat mereplikasi data ke satu atau beberapa database, status Gagal akan ditampilkan dalam daftar database.
Berbagai error tugas migrasi.
Di kolom Errors, klik View errors dan perbaiki error tersebut. Setelah memperbaiki error, klik Restart.
Error: database already exists in destination
Anda mendapatkan pesan error berikut:
The following database already exists in destination: {database_name}.
Masalahnya mungkin adalah
Instance tujuan Cloud SQL Anda sudah berisi database yang menggunakan nama yang sama dengan salah satu database yang disertakan dalam tugas migrasi Anda.
Hal-hal yang sebaiknya dicoba
Bergantung pada skenario migrasi Anda, ada berbagai cara untuk menyelesaikan masalah database duplikat. Coba salah satu tindakan berikut:
Ganti nama bucket Cloud Storage sumber untuk memigrasikan database Anda dengan nama yang berbeda.
Nama database yang dibuat Database Migration Service di instance Cloud SQL tujuan Anda berasal dari nama folder di Cloud Storage tempat Anda menyimpan file cadangan. Jika memiliki dua database berbeda yang memiliki nama yang sama dan memerlukan keduanya di tujuan Cloud SQL, Anda dapat mengganti nama folder dan membuat ulang tugas migrasi untuk menghindari konflik penamaan.
Anda dapat menambahkan database baru ke tugas migrasi yang ada, tetapi tidak dapat menghapus database dari tugas migrasi. Itulah sebabnya Anda perlu membuat ulang
seluruh tugas migrasi.
Hapus database duplikat dari instance Cloud SQL untuk SQL Server Anda.
Jika database di instance tujuan Cloud SQL Anda merupakan duplikat,
Anda dapat menghapusnya dari instance dan melanjutkan tugas migrasi.
Lihat
Menghapus database dalam dokumentasi Cloud SQL untuk SQL Server.
Menyesuaikan nama file log transaksi untuk file WAL yang tidak beraturan
Masalahnya mungkin adalah
File log transaksi Anda mungkin menggunakan stempel waktu epoch yang salah
sehubungan dengan urutan update yang dikandungnya.
Database Migration Service menggunakan nomor urutan log dan stempel waktu epoch untuk mengontrol
urutan file log transaksi yang direplikasi ke instance tujuan
Cloud SQL.
Hal-hal yang sebaiknya dicoba
Upload file Anda dapat tertunda atau tidak berurutan. Tunggu beberapa
menit agar masalah teratasi atau periksa apakah ada file yang hilang
di bucket Cloud Storage Anda.
Periksa daftar operasi impor log transaksi Anda di instance Cloud SQL untuk SQL Server tujuan. Di konsol Google Cloud , buka halaman
Instance Cloud SQL.
Klik Lihat semua operasi > Lihat log error SQL Server.
Lihat semua operasi impor untuk file log transaksi dan verifikasi
apakah nama filenya berisi stempel waktu epoch yang benar.
Jika Anda melihat bahwa file log transaksi terbaru menggunakan nama dengan stempel waktu epoch yang tidak berurutan, buka bucket Cloud Storage dan ganti nama file.
Database Migration Service otomatis mendeteksi perubahan dan mencoba mengimpor
file log transaksi yang relevan.
Khusus Amazon RDS: Mungkin beberapa file log transaksi
terlewat selama proses ekspor ke S3. Coba jalankan kembali fungsi ekspor log transaksi untuk periode sekitar file WAL yang hilang.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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"]]
