ApsaraDB RDS:Migrasi data cadangan inkremental ke cloud (SQL Server 2008 R2 pada cloud disk dan SQL Server 2012 atau versi lebih baru)

Kasus penggunaan

Gunakan migrasi data inkremental ke RDS SQL Server dalam skenario berikut:

• Anda ingin melakukan migrasi fisik ke RDS SQL Server menggunakan file backup alih-alih migrasi logis.

  Catatan

  • Migrasi fisik berbasis file, sedangkan migrasi logis menghasilkan pernyataan DML dari data dan mengeksekusinya pada instans RDS SQL Server tujuan.

  • Migrasi fisik memastikan bahwa database tujuan identik 100% dengan database sumber. Sebaliknya, migrasi logis tidak dapat menjamin konsistensi ini. Misalnya, atribut seperti fragmentasi indeks dan informasi statistik mungkin berbeda setelah migrasi.

• Anda memerlukan downtime minimal, terbatas hanya beberapa menit.

  Catatan

  Jika downtime yang lebih lama dapat diterima (misalnya, gangguan selama 2 jam) dan ukuran database Anda kurang dari 100 GB, migrasikan database Anda menggunakan file cadangan penuh.

Prasyarat

• Instans RDS for SQL Server Anda harus memenuhi persyaratan berikut:

  • Instans harus menjalankan SQL Server 2012 atau versi lebih baru, atau merupakan instans SQL Server 2008 R2 yang menggunakan cloud disk.

  • Instans tidak boleh berisi database dengan nama yang sama dengan database yang akan dimigrasikan.

  • Ruang penyimpanan tersedia pada instans harus lebih besar daripada ukuran file data yang akan dimigrasikan. Jika ruang penyimpanan tidak mencukupi, tingkatkan kapasitas penyimpanan instans.

• Model pemulihan (recovery model) untuk database SQL Server on-premises Anda harus FULL.

  Catatan

  • Migrasi data inkremental memerlukan cadangan log transaksi. Model pemulihan Simple tidak mendukung pencadangan log transaksi.

  • File cadangan diferensial yang besar dapat memperpanjang durasi migrasi data inkremental.

• Jika Anda login sebagai Pengguna RAM, Anda harus memenuhi persyaratan berikut:

  • Pengguna RAM harus memiliki izin AliyunOSSFullAccess dan AliyunRDSFullAccess. Untuk informasi lebih lanjut, lihat Kontrol akses ke OSS menggunakan RAM dan Kontrol akses ke RDS menggunakan RAM.

  • Pastikan akun Alibaba Cloud Anda telah memberikan akses akun layanan resmi RDS ke sumber daya OSS Anda.

    Metode otorisasi

    1. Buka halaman Restoration instans RDS for SQL Server dan klik Restore Backup Data from OSS.

    2. Pada panduan Import Guide, klik Next dua kali hingga mencapai langkah 3. Import Data.

       Jika pesan You have authorized RDS official service account to access your OSS muncul di pojok kiri bawah halaman, otorisasi telah diberikan. Jika tidak, klik tautan Authorization URL pada halaman tersebut untuk memberikan otorisasi.

       

  • Anda harus secara manual membuat kebijakan akses di akun Alibaba Cloud Anda, lalu melampirkannya ke Pengguna RAM tersebut.

    Isi kebijakan

    {
        "Version": "1",
        "Statement": [
            {
                "Action": [
                    "ram:GetRole"
                ],
                "Resource": "acs:ram:*:*:role/AliyunRDSImportRole",
                "Effect": "Allow"
            }
        ]
    }

Persiapan

Jalankan perintah DBCC CHECKDB pada database yang dikelola sendiri untuk memeriksa allocation errors dan consistency errors. Output yang diharapkan adalah sebagai berikut:

...
CHECKDB found 0 allocation errors and 0 consistency errors in database 'xxx'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Catatan

• Tingkat migrasi: Solusi ini hanya memigrasikan satu database. Untuk memigrasikan beberapa atau semua database, lihat Migrasi cloud tingkat instans SQL Server.

• Kompatibilitas versi: Anda tidak dapat memulihkan backup dari instans SQL Server yang dikelola sendiri ke instans ApsaraDB RDS for SQL Server yang menjalankan versi SQL Server lebih lama.

• Manajemen izin: Setelah Anda memberikan otorisasi kepada akun layanan ApsaraDB RDS untuk mengakses OSS, sebuah role bernama AliyunRDSImportRole dibuat di Resource Access Management (RAM). Jangan mengubah atau menghapus role ini. Jika tidak, tugas migrasi cloud akan gagal. Jika Anda secara tidak sengaja mengubah atau menghapus role ini, Anda harus memberikan kembali izin tersebut melalui wizard migrasi.

• Manajemen akun: Setelah migrasi selesai, Anda tidak dapat menggunakan akun database yang ada sebelumnya. Anda harus membuat akun baru di konsol ApsaraDB RDS.

• Retensi file OSS: Jangan menghapus file backup dari OSS sebelum tugas migrasi cloud selesai. Jika tidak, tugas tersebut akan gagal.

• Persyaratan file backup:

  • Batasan nama file: Nama file backup tidak boleh mengandung karakter khusus (seperti !@#$%^&*()_+-=). Jika tidak, migrasi cloud akan gagal.

  • Ekstensi file: ApsaraDB RDS mendukung file backup dengan ekstensi berikut: .bak (cadangan penuh), .diff (cadangan diferensial), dan .trn atau .log (cadangan log). ApsaraDB RDS tidak mengenali jenis file lainnya.

    Catatan

    • Dalam praktiknya, ekstensi file tidak selalu menunjukkan jenis backup-nya. Misalnya, file .bak dapat berisi cadangan penuh, cadangan diferensial, atau cadangan log transaksi.

    • File cadangan log SQL Server yang diunduh dari konsol ApsaraDB RDS secara default memiliki format .zip.log. Ini berbeda dengan file backup .bak yang dihasilkan oleh skrip resmi pada Langkah 1. Setelah Anda mengonversi format file tersebut, Anda dapat menggunakannya untuk migrasi cloud inkremental.

      Metode pemrosesan: Ubah ekstensi file menjadi .zip dan ekstrak file tersebut. Kemudian, ubah nama file hasil ekstraksi database_name.lbak agar memiliki ekstensi .bak. Terakhir, unggah file .bak ini ke OSS sebagai cadangan log inkremental untuk migrasi cloud.

Alur kerja contoh

Alur kerja ini menunjukkan bahwa downtime aplikasi yang diperlukan sangat singkat. Anda hanya perlu menghentikan penulisan aplikasi tepat sebelum cadangan log terakhir. Dalam contoh ini, total downtime kurang dari 5 menit.

Langkah 1: Cadangkan database lokal

1. Unduh skrip backup dan buka di SSMS.

2. Modifikasi parameter berikut.

   Parameter	Deskripsi
   @backup_databases_list	Daftar database yang akan dicadangkan, dipisahkan dengan titik koma atau koma.
   @backup_type	Jenis backup yang akan dilakukan. Nilai yang valid: FULL: cadangan penuh DIFF: cadangan diferensial LOG: cadangan log
   @backup_folder	Direktori lokal untuk file backup. Skrip akan membuat direktori ini secara otomatis jika belum ada.
   @is_run	Menentukan apakah akan menjalankan backup. Nilai yang valid: 1: Menjalankan backup. 0: Hanya menjalankan pemeriksaan tanpa melakukan backup.

3. Jalankan skrip backup.

   Skrip ini menghasilkan file .bak secara default, terlepas dari jenis backup yang dipilih.

2. Unggah file backup ke OSS

1. Untuk mengunggah file backup ke OSS, Anda harus membuat bucket terlebih dahulu.

   • Jika Anda sudah memiliki bucket di OSS, pastikan bucket tersebut memenuhi persyaratan berikut:

     • kelas penyimpanan bucket adalah Standard. Kelas penyimpanan tidak boleh Infrequent Access (IA), Archive, Cold Archive, atau Deep Cold Archive.

     • enkripsi data tidak diaktifkan untuk bucket tersebut.

   • Jika Anda belum memiliki bucket di OSS, buatlah satu. (Pastikan Anda telah mengaktifkan OSS.)

     1. Login ke konsol OSS, klik Buckets, lalu klik Create bucket.

     2. Konfigurasikan parameter utama berikut. Gunakan nilai default untuk parameter lainnya.

        Penting

        • Bucket ini hanya digunakan untuk migrasi data ini Anda hanya perlu mengonfigurasi parameter utama saja. Setelah migrasi selesai, segera hapus bucket tersebut untuk mencegah kebocoran data dan menghindari biaya terkait.

        • Jangan aktifkan enkripsi data saat membuat bucket.

        Parameter	Deskripsi	Contoh
        Bucket Name	Nama bucket. Nama harus unik secara global dan tidak dapat diubah setelah bucket dibuat. Konvensi penamaan: Hanya boleh berisi huruf kecil, angka, dan tanda hubung (-). Harus dimulai dan diakhiri dengan huruf kecil atau angka. Panjangnya harus antara 3 hingga 63 karakter.	migratetest
        Region	Wilayah tempat bucket berada. Untuk menggunakan jaringan internal saat mengunggah dari instans ECS dan memulihkan ke instans RDS, instans ECS, bucket, dan instans RDS harus berada di wilayah yang sama.	China (Hangzhou)
        Storage Type	Pilih Standard. Metode migrasi yang dijelaskan dalam topik ini tidak mendukung bucket dengan kelas penyimpanan lainnya.	Standard

2. Unggah file backup ke OSS.

   Setelah mencadangkan database lokal, unggah file backup ke bucket OSS yang berada di wilayah yang sama dengan instans RDS Anda. Hal ini memungkinkan komunikasi melalui jaringan internal, sehingga menghindari biaya trafik internet dan meningkatkan kecepatan unggah. Anda dapat menggunakan salah satu metode berikut:

   Gunakan tool ossbrowser (Direkomendasikan)

   1. Unduh ossbrowser.

   2. Sebagai contoh, pada sistem Windows x64, ekstrak paket oss-browser-win32-x64.zip yang diunduh dan klik ganda aplikasi oss-browser.exe.

   3. Gunakan metode login AK, masukkan Access Key ID dan Access Key Secret Anda, pertahankan nilai default untuk parameter lainnya, lalu klik Log On.

      Catatan

      AccessKey digunakan untuk verifikasi identitas guna memastikan keamanan data. Simpan pasangan Kunci Akses Anda dengan aman.

   4. Setelah login, klik bucket target, misalnya migratetest, dalam daftar Buckets untuk membuka halaman manajemen file-nya.

   5. Klik , pilih file backup yang akan diunggah, lalu klik Open.

   Gunakan konsol OSS untuk mengunggah file

   Catatan

   Kami merekomendasikan penggunaan konsol OSS untuk file berukuran kurang dari 5 GB.

   1. Login ke konsol OSS.

   2. Di panel navigasi sebelah kiri, klik Buckets. Temukan bucket target dan klik namanya, misalnya migratetest, untuk membuka halaman detailnya.

   3. Di tab Files, klik Upload File.

   4. Di panel Upload Object, seret file backup Anda ke area Files to Upload atau klik Select Files. Pertahankan pengaturan default untuk object ACL, yaitu Inherit from Bucket. Ukuran file maksimum untuk metode ini adalah 5 GB. Untuk mengunggah file lebih dari 5 GB, gunakan tool seperti ossutil untuk melakukan unggah multi-bagian.

   5. Klik Upload File di bagian bawah halaman.

   Gunakan API OSS untuk unggah multi-bagian

   Catatan

   Kami merekomendasikan penggunaan API unggah multi-bagian untuk file berukuran lebih dari 5 GB.

   Contoh Java berikut menunjukkan cara memperoleh kredensial akses dari variabel lingkungan. Sebelum menjalankan kode ini, pastikan variabel lingkungan telah dikonfigurasi. Untuk contoh lainnya, lihat Unggah multi-bagian.

   import com.aliyun.oss.*;
   import com.aliyun.oss.common.auth.*;
   import com.aliyun.oss.common.comm.SignVersion;
   import com.aliyun.oss.internal.Mimetypes;
   import com.aliyun.oss.model.*;
   import java.io.File;
   import java.io.FileInputStream;
   import java.io.InputStream;
   import java.util.ArrayList;
   import java.util.List;
   
   public class Demo {
   
       public static void main(String[] args) throws Exception {
           // Gunakan endpoint wilayah China (Hangzhou) sebagai contoh. Tentukan endpoint aktual.
           String endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
           // Peroleh kredensial akses dari variabel lingkungan. Sebelum menjalankan kode contoh, pastikan variabel lingkungan OSS_ACCESS_KEY_ID dan OSS_ACCESS_KEY_SECRET telah dikonfigurasi.
           EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
           // Tentukan nama bucket, misalnya examplebucket.
           String bucketName = "examplebucket";
           // Tentukan path lengkap objek, misalnya exampledir/exampleobject.txt. Path lengkap tidak boleh mengandung nama bucket.
           String objectName = "exampledir/exampleobject.txt";
           // Path file lokal yang akan diunggah.
           String filePath = "D:\\localpath\\examplefile.txt";
           // Tentukan wilayah tempat bucket berada. Misalnya, jika bucket berada di wilayah China (Hangzhou), atur region ke cn-hangzhou.
           String region = "cn-hangzhou";
   
           // Buat instance OSSClient.
           // Saat instance OSSClient tidak lagi digunakan, panggil metode shutdown untuk melepaskan sumber daya.
           ClientBuilderConfiguration clientBuilderConfiguration = new ClientBuilderConfiguration();
           clientBuilderConfiguration.setSignatureVersion(SignVersion.V4);
           OSS ossClient = OSSClientBuilder.create()
                   .endpoint(endpoint)
                   .credentialsProvider(credentialsProvider)
                   .clientConfiguration(clientBuilderConfiguration)
                   .region(region)
                   .build();
   
           try {
               // Buat objek InitiateMultipartUploadRequest.
               InitiateMultipartUploadRequest request = new InitiateMultipartUploadRequest(bucketName, objectName);
   
               // Buat objek ObjectMetadata dan atur Content-Type.
               ObjectMetadata metadata = new ObjectMetadata();
               if (metadata.getContentType() == null) {
                   metadata.setContentType(Mimetypes.getInstance().getMimetype(new File(filePath), objectName));
               }
               System.out.println("Content-Type: " + metadata.getContentType());
   
               // Ikat metadata ke permintaan unggah.
               request.setObjectMetadata(metadata);
   
               // Inisialisasi unggah multi-bagian.
               InitiateMultipartUploadResult upresult = ossClient.initiateMultipartUpload(request);
               // Kembalikan ID unggah.
               String uploadId = upresult.getUploadId();
   
               // partETags adalah kumpulan objek PartETag. Objek PartETag terdiri dari ETag dan nomor bagian suatu bagian.
               List<PartETag> partETags = new ArrayList<PartETag>();
               // Ukuran setiap bagian. Ini digunakan untuk menghitung jumlah bagian. Satuan: byte.
               // Ukuran bagian minimum adalah 100 KB, dan ukuran bagian maksimum adalah 5 GB. Ukuran bagian terakhir dapat lebih kecil dari 100 KB.
               // Atur ukuran bagian menjadi 1 MB.
               final long partSize = 1 * 1024 * 1024L;   
   
               // Hitung jumlah bagian berdasarkan ukuran data yang akan diunggah. Kode berikut memberikan contoh cara memperoleh ukuran data yang akan diunggah dari file lokal menggunakan File.length().
               final File sampleFile = new File(filePath);
               long fileLength = sampleFile.length();
               int partCount = (int) (fileLength / partSize);
               if (fileLength % partSize != 0) {
                   partCount++;
               }
               // Iterasi bagian-bagian dan unggah.
               for (int i = 0; i < partCount; i++) {
                   long startPos = i * partSize;
                   long curPartSize = (i + 1 == partCount) ? (fileLength - startPos) : partSize;
                   UploadPartRequest uploadPartRequest = new UploadPartRequest();
                   uploadPartRequest.setBucketName(bucketName);
                   uploadPartRequest.setKey(objectName);
                   uploadPartRequest.setUploadId(uploadId);
                   // Atur stream bagian yang akan diunggah.
                   // Kode berikut memberikan contoh cara membuat objek FileInputStream dari file lokal dan melewati data tertentu menggunakan metode InputStream.skip().
                   InputStream instream = new FileInputStream(sampleFile);
                   instream.skip(startPos);
                   uploadPartRequest.setInputStream(instream);
                   // Atur ukuran bagian.
                   uploadPartRequest.setPartSize(curPartSize);
                   // Atur nomor bagian. Setiap bagian yang diunggah memiliki nomor bagian yang berkisar dari 1 hingga 10.000. Jika nomor bagian berada di luar rentang ini, OSS akan mengembalikan kode kesalahan InvalidArgument.
                   uploadPartRequest.setPartNumber(i + 1);
                   // Bagian tidak perlu diunggah secara berurutan. Mereka bahkan dapat diunggah dari klien yang berbeda. OSS akan mengurutkan bagian berdasarkan nomor bagian untuk membuat objek lengkap.
                   UploadPartResult uploadPartResult = ossClient.uploadPart(uploadPartRequest);
                   // Setelah setiap bagian diunggah, respons OSS mencakup PartETag. PartETag disimpan di partETags.
                   partETags.add(uploadPartResult.getPartETag());
   
                   // Tutup stream.
                   instream.close();
               }
   
               // Buat objek CompleteMultipartUploadRequest.
               // Saat Anda menyelesaikan unggah multi-bagian, Anda harus menyediakan semua partETags yang valid. Setelah OSS menerima partETags yang diajukan, OSS akan memverifikasi validitas setiap bagian. Setelah semua bagian diverifikasi, OSS akan menggabungkan bagian-bagian tersebut menjadi objek lengkap.
               CompleteMultipartUploadRequest completeMultipartUploadRequest =
                       new CompleteMultipartUploadRequest(bucketName, objectName, uploadId, partETags);
   
               // Selesaikan unggah multi-bagian.
               CompleteMultipartUploadResult completeMultipartUploadResult = ossClient.completeMultipartUpload(completeMultipartUploadRequest);
               System.out.println("Unggah berhasil, ETag: " + completeMultipartUploadResult.getETag());
   
           } catch (OSSException oe) {
               System.out.println("Terjadi OSSException, yang berarti permintaan Anda sampai ke OSS, "
                       + "tetapi ditolak dengan respons kesalahan karena suatu alasan.");
               System.out.println("Pesan Kesalahan:" + oe.getErrorMessage());
               System.out.println("Kode Kesalahan:" + oe.getErrorCode());
               System.out.println("ID Permintaan:" + oe.getRequestId());
               System.out.println("ID Host:" + oe.getHostId());
           } catch (ClientException ce) {
               System.out.println("Terjadi ClientException, yang berarti klien mengalami "
                       + "masalah internal serius saat mencoba berkomunikasi dengan OSS, "
                       + "seperti tidak dapat mengakses jaringan.");
               System.out.println("Pesan Kesalahan:" + ce.getMessage());
           } finally {
               if (ossClient != null) {
                   ossClient.shutdown();
               }
           }
       }
   }

3. Buat tugas migrasi cloud

1. Buka halaman Instances. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Lalu, temukan instans RDS tersebut dan klik ID-nya.

2. Di panel navigasi kiri, klik Restoration.

3. Di bagian atas halaman, klik Restore Backup Data from OSS.

4. Di halaman Import Guide, klik Next dua kali untuk menuju langkah Import Data.

   Catatan

   Jika ini pertama kalinya Anda menggunakan fitur migrasi data backup OSS ke RDS, Anda harus memberikan otorisasi kepada akun RDS untuk mengakses OSS. Klik Authorize untuk memberikan izin yang diperlukan. Jika tidak, daftar drop-down OSS Bucket akan kosong.

5. Atur parameter berikut dan klik Yes.

   Tunggu hingga tugas migrasi cloud selesai. Klik Refresh untuk melihat status terbaru tugas tersebut. Jika tugas gagal, lakukan pemecahan masalah berdasarkan pesan kesalahan dalam deskripsi tugas. Untuk informasi lebih lanjut, lihat Kesalahan umum.

   Parameter	Deskripsi
   Database Name	Nama database tujuan pada instans RDS. Nama harus sesuai dengan konvensi penamaan SQL Server. Penting Sebelum memulai migrasi, pastikan instans tujuan tidak memiliki database atau file database yang tidak terpasang dengan nama yang sama dengan database dalam file backup. Jika database dengan nama yang sama dengan database yang ditentukan dalam file backup sudah ada pada instans tujuan, atau jika file database yang tidak terpasang dengan nama yang sama sudah ada, migrasi cloud akan gagal.
   OSS Bucket	Pilih bucket OSS tempat file backup disimpan.
   OSS File	Klik ikon kaca pembesar untuk melakukan pencarian fuzzy file backup berdasarkan awalan. Hasilnya menampilkan nama file, ukuran file, dan waktu modifikasi terakhir. Pilih file backup yang akan dimigrasikan.
   Cloud Migration Method	Pilih Do Not Open Database. Immediate Access (Full Backup): Gunakan metode ini untuk migrasi data penuh ke cloud jika Anda memiliki satu file cadangan penuh yang akan dimigrasikan. Untuk opsi ini, operasi CreateMigrateTask menggunakan parameter berikut: BackupMode = FULL dan IsOnlineDB = True. Access Pending (Incremental Backup): Gunakan metode ini untuk migrasi data inkremental ke cloud jika Anda memigrasikan file cadangan penuh diikuti oleh file cadangan diferensial atau log. Untuk opsi ini, operasi CreateMigrateTask menggunakan parameter berikut: BackupMode = UPDF dan IsOnlineDB = False.

4. Impor cadangan diferensial atau log

Setelah memigrasikan cadangan penuh database SQL Server yang dikelola sendiri, impor file cadangan diferensial atau log tersebut.

1. Buka halaman Instances. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Lalu, temukan instans RDS tersebut dan klik ID-nya.

2. Di panel navigasi kiri, klik Restoration, lalu tab Backup Data Upload History.

3. Di daftar tugas, temukan tugas yang sesuai dan klik Upload Incremental Files di kolom Actions. Pilih file inkremental dan klik OK.

   Catatan

   • Jika Anda memiliki beberapa file cadangan log, buat tugas migrasi terpisah untuk masing-masing file.

   • Pastikan file backup terakhir tidak melebihi 500 MB. Hal ini akan meminimalkan waktu yang diperlukan untuk migrasi cloud inkremental.

   • Sebelum menghasilkan file cadangan log terakhir, hentikan semua operasi tulis pada database yang dikelola sendiri. Hal ini memastikan konsistensi data antara database yang dikelola sendiri dan instans RDS for SQL Server.

5. Buka database

Setelah mengimpor file backup, database pada instans ApsaraDB RDS for SQL Server Anda masuk ke status In Recovery atau Restoring. Untuk instans Edisi Ketersediaan Tinggi, statusnya adalah In Recovery, sedangkan untuk instans Edisi Dasar, statusnya adalah Restoring. Dalam kedua status tersebut, database tidak tersedia untuk operasi baca dan tulis. Anda harus membuka database agar tersedia.

1. Buka halaman Instances. Di bilah navigasi atas, pilih wilayah tempat instans RDS berada. Lalu, temukan instans RDS tersebut dan klik ID-nya.

2. Di panel navigasi kiri, pilih Restoration, lalu klik tab Cloud Migration Records of Backup Data.

3. Di daftar tugas, temukan catatan impor file backup dan klik Open Database di kolom Actions.

4. Pilih opsi pemeriksaan konsistensi database dan klik OK.

   Catatan

   Opsi berikut tersedia untuk pemeriksaan konsistensi database:

   • Asynchronous DBCC: Opsi ini menjalankan operasi DBCC CHECKDB secara asinkron setelah database dibuka. Metode ini meminimalkan downtime dengan membawa database online lebih cepat. Opsi ini ideal jika database Anda besar dan operasi DBCC CHECKDB memakan waktu lama. Gunakan opsi ini jika layanan Anda sensitif terhadap downtime dan Anda tidak memerlukan hasil pemeriksaan segera. Untuk panggilan API CreateMigrateTask, opsi ini mengatur parameter CheckDBMode menjadi AsyncExecuteDBCheck.

   • Synchronous DBCC: Opsi ini menjalankan operasi DBCC CHECKDB saat database dibuka. Metode ini memungkinkan Anda segera memverifikasi konsistensi data dan mengidentifikasi kesalahan apa pun. Gunakan opsi ini jika Anda memprioritaskan verifikasi data, tetapi perhatikan bahwa hal ini meningkatkan waktu yang diperlukan untuk membuka database. Untuk panggilan API CreateMigrateTask, opsi ini mengatur parameter CheckDBMode menjadi SyncExecuteDBCheck.

6. Lihat detail backup migrasi cloud

Untuk melihat detail file backup untuk tugas migrasi cloud, buka halaman Restoration di panel navigasi kiri instans RDS. Di tab Cloud Migration Records of Backup Data, temukan tugas tersebut dan klik View File Details di kolom paling kanan.

Kesalahan umum

Untuk kesalahan umum selama migrasi data cadangan penuh, lihat Kesalahan umum dalam migrasi data cadangan penuh.

Anda mungkin mengalami kesalahan berikut selama unggah inkremental:

• Gagal membuka database

  • Pesan error: Gagal membuka database xxx.

  • Penyebab: Database SQL Server sumber menggunakan fitur lanjutan yang tidak didukung oleh edisi instans ApsaraDB RDS for SQL Server yang dipilih. Misalnya, kesalahan ini terjadi jika instans SQL Server sumber menjalankan Edisi Perusahaan dengan kompresi data atau partisi yang diaktifkan, dan Anda memigrasikan data ke instans ApsaraDB RDS for SQL Server yang menjalankan Edisi Web.

  • Solusi:

    • Nonaktifkan fitur lanjutan pada instans SQL Server sumber, buat backup baru, lalu coba migrasi lagi.

    • Beli instans ApsaraDB RDS for SQL Server dengan edisi SQL Server yang sama dengan instans sumber Anda. Untuk informasi lebih lanjut, lihat Buat instans ApsaraDB RDS for SQL Server.

      Catatan

      Untuk informasi lebih lanjut, lihat Perbandingan fitur antar versi SQL Server dan edisi RDS yang berbeda.

• Ketidaksesuaian LSN dalam rantai backup

  • Pesan kesalahan: Log dalam set cadangan ini dimulai pada LSN XXX, yang terlalu baru untuk diterapkan ke database. RESTORE LOG dihentikan secara tidak normal.

  • Penyebab: Di SQL Server, cadangan diferensial atau log hanya dapat dipulihkan jika Log Sequence Number (LSN) awalnya sesuai dengan LSN file backup yang dipulihkan sebelumnya. Kesalahan ini terjadi jika LSN tidak cocok.

  • Solusi: Pilih file backup dengan LSN yang cocok untuk unggah inkremental. Pastikan Anda mengunggah file backup secara kronologis.

• Asynchronous DBCC CHECKDB failed

  • Pesan kesalahan: asynchronously DBCC checkdb failed: CHECKDB found 0 allocation errors and 2 consistency errors in table 'XXX' (object ID XXX).

  • Penyebab: Setelah file backup dipulihkan ke instans ApsaraDB RDS for SQL Server, sistem menjalankan DBCC CHECKDB asinkron. Jika pemeriksaan ini gagal, berarti database sumber sudah mengandung kesalahan konsistensi.

  • Solusi:

    • Pada instans ApsaraDB RDS for SQL Server tujuan, jalankan perintah berikut:

      DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)

      Penting

      Perintah perbaikan ini dapat menyebabkan kehilangan data.

    • Pada instans sumber, jalankan perintah berikut untuk memperbaiki kesalahan, lalu coba lagi unggah inkremental.

      DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)

• Jenis file backup salah untuk unggah inkremental

  • Pesan kesalahan: Backup set (xxx) is a Database FULL backup, we only accept transaction log or differential backup.

  • Penyebab: Selama unggah inkremental ke instans ApsaraDB RDS for SQL Server, sistem hanya menerima file cadangan log atau diferensial setelah cadangan penuh dipulihkan. Kesalahan ini terjadi jika Anda memilih kembali file cadangan penuh.

  • Solusi: Pilih file cadangan log atau diferensial.

• Jumlah database melebihi batas

  • Pesan kesalahan: Migrasi database (xxx) gagal karena melebihi batas jumlah database yang diizinkan.

  • Penyebab: Kesalahan ini terjadi saat Anda memigrasikan database ke instans yang telah mencapai batas maksimum jumlah database.

  • Solusi: Migrasikan database ke instans ApsaraDB RDS for SQL Server lain, atau hapus database yang tidak diperlukan dari instans saat ini.

• Izin Pengguna RAM Tidak Cukup

  • Q1: Pada Langkah 5 Buat tugas migrasi data, mengapa tombol OK tampak redup dan tidak dapat diklik meskipun semua parameter telah dikonfigurasi?

  • A1: Hal ini dapat terjadi jika Pengguna RAM Anda tidak memiliki izin yang diperlukan. Lihat bagian Prasyarat dalam topik ini dan berikan izin yang diperlukan.

  • Q2: Bagaimana cara mengatasi kesalahan no permission yang terjadi saat Pengguna RAM mencoba memberikan role AliyunRDSImportRole?

  • A2: Gunakan akun Alibaba Cloud Anda untuk sementara memberikan izin AliyunRAMFullAccess kepada Pengguna RAM. Untuk petunjuk cara memberikan izin kepada Pengguna RAM, lihat Gunakan RAM untuk mengelola izin ApsaraDB RDS.

• Cadangan inkremental dipulihkan ke cadangan penuh yang salah

  • Pesan kesalahan: Backup diferensial ini tidak dapat dipulihkan karena database tidak berada dalam keadaan yang sesuai. RESTORE DATABASE dihentikan secara tidak normal.

  • Penyebab: Kesalahan ini terjadi jika cadangan inkremental yang lebih baru dipulihkan ke cadangan penuh yang lebih lama. Hal ini memutus rantai backup karena LSN file cadangan diferensial tidak sesuai dengan LSN file cadangan penuh yang dipulihkan dengan opsi NORECOVERY.

  • Solusi: Pastikan Anda memilih file backup yang benar dan mengunggahnya dalam urutan yang tepat. Anda dapat mengkueri tabel msdb.dbo.backupset pada instans sumber untuk memverifikasi urutan dan hubungan LSN antara file cadangan penuh dan diferensial Anda.

• Kesalahan dengan Striped Backups multi-file

  • Pesan kesalahan: Gagal memverifikasi (xxx.bak). Pesan kesalahan: Set media memiliki xxx keluarga media, tetapi hanya satu yang disertakan. Semua anggota harus disertakan. VERIFY DATABASE dihentikan secara tidak normal.

  • Penyebab: Database sumber dicadangkan menggunakan fitur Striped Backup, yang menulis satu cadangan penuh ke beberapa file .bak. Namun, Anda hanya menyediakan salah satu file tersebut untuk tugas migrasi. ApsaraDB RDS for SQL Server tidak mendukung migrasi data dari beberapa file backup dalam satu tugas.

  • Solusi: Cadangkan database sumber ke satu file .bak tunggal, lalu coba unggah lagi.

Referensi API