全部产品
Search
文档中心

ApsaraDB RDS:Migrasikan Data Cadangan Inkremental dari Instans SQL Server yang Dikelola Sendiri ke Instans ApsaraDB RDS untuk SQL Server

更新时间:Nov 10, 2025

ApsaraDB RDS for SQL Server mendukung migrasi data cadangan inkremental ke cloud. Anda dapat menyimpan file cadangan penuh dari instans SQL Server yang dikelola sendiri di bucket Object Storage Service (OSS) dan memulihkannya ke instans ApsaraDB RDS for SQL Server melalui konsol ApsaraDB RDS. Selanjutnya, Anda dapat mengimpor file cadangan diferensial atau file cadangan log untuk menyelesaikan migrasi data cadangan inkremental ke cloud. Metode ini mengurangi waktu henti menjadi hanya beberapa menit.

Skenario

Metode migrasi yang dijelaskan dalam topik ini cocok untuk skenario berikut:

  • Migrasikan data ke instans RDS Anda dalam mode fisik, bukan mode logis.

    Catatan
    • Migrasi fisik memungkinkan Anda memigrasikan data menggunakan file cadangan fisik. Migrasi logis memungkinkan Anda menulis pernyataan bahasa manipulasi data (DML) yang telah dieksekusi ke instans RDS Anda.

    • Migrasi fisik memastikan konsistensi data 100% antara database yang dikelola sendiri dan database tujuan. Migrasi logis tidak dapat memastikan konsistensi data 100%. Sebagai contoh, fragmentasi indeks dan informasi statistik mungkin berubah setelah migrasi.

  • Migrasikan data dengan downtime dalam hitungan menit.

    Catatan

    Jika aplikasi Anda tidak sensitif terhadap downtime (misalnya, dapat mentolerir downtime selama 2 jam) dan ukuran database kurang dari 100 GB, kami sarankan Anda menggunakan file cadangan penuh untuk migrasi cloud.

Prasyarat

  • Instans RDS Anda harus memenuhi persyaratan berikut:

    • Instans RDS menjalankan SQL Server 2012 atau yang lebih baru, atau SQL Server 2008 R2 dengan disk cloud.

    • Nama database pada instans RDS Anda berbeda dari nama database sumber pada instans SQL Server yang dikelola sendiri.

    • Penyimpanan yang tersedia pada instans RDS lebih besar dari ukuran file data yang ingin dimigrasikan. Jika penyimpanan tidak mencukupi, Anda harus memperluas kapasitas penyimpanan instans RDS sebelum memulai migrasi.

  • Instans SQL Server yang dikelola sendiri menggunakan model pemulihan FULL.

    Catatan
    • Cadangan log transaksi diperlukan saat memigrasikan data cadangan inkremental dari instans SQL Server yang dikelola sendiri ke instans RDS. Jika instans SQL Server yang dikelola sendiri menggunakan model pemulihan SIMPLE, log transaksi tidak dapat dicadangkan.

    • Jika ukuran file cadangan diferensial besar, waktu yang diperlukan untuk memigrasikan data cadangan inkremental mungkin bertambah.

  • Jika Anda menggunakan Pengguna Resource Access Management (RAM), kondisi berikut harus dipenuhi:

    • Pengguna RAM memiliki izin AliyunOSSFullAccess dan AliyunRDSFullAccess. Untuk informasi lebih lanjut tentang cara memberikan izin kepada pengguna RAM, lihat Kelola izin OSS menggunakan RAM dan Kelola izin ApsaraDB RDS menggunakan RAM.

    • Akun Alibaba Cloud Anda telah memberikan izin akun layanan ApsaraDB RDS untuk mengakses sumber daya OSS Anda.

      Klik untuk melihat metode otorisasi

      1. Buka halaman Backup and Restoration dari instans ApsaraDB RDS dan klik Restore from OSS Backup.

      2. Di Data Import Wizard, klik Next dua kali untuk melanjutkan ke langkah 3. Data Import.

        Otorisasi selesai jika pesan You Have Authorized The Official RDS Service Account To Access Your OSS Resources ditampilkan di pojok kiri bawah halaman. Jika tidak, klik Authorization URL di halaman untuk memberikan otorisasi.

        image

    • Akun Alibaba Cloud Anda harus secara manual membuat kebijakan akses dan kemudian menyambungkan kebijakan tersebut ke pengguna RAM.

      Klik untuk melihat isi kebijakan

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

Persiapan

Jalankan pernyataan DBCC CHECKDB pada database yang dikelola sendiri dan pastikan tidak ada kesalahan alokasi atau kesalahan konsistensi. Jika tidak ditemukan kesalahan, hasil eksekusi berikut akan ditampilkan:

...
CHECKDB menemukan 0 kesalahan alokasi dan 0 kesalahan konsistensi di database 'xxx'.
Eksekusi DBCC selesai. Jika DBCC mencetak pesan kesalahan, hubungi administrator sistem Anda.

Catatan penggunaan

  • Tingkat Migrasi: Metode migrasi dalam topik ini hanya mendukung migrasi database tunggal. Untuk memigrasikan beberapa atau semua database, lihat Migrasi Data dari Instans SQL Server yang Dikelola Sendiri ke Instans ApsaraDB RDS for SQL Server.

  • Kompatibilitas Versi: Migrasi dari versi SQL Server yang lebih baru ke versi SQL Server yang lebih lama tidak didukung.

  • Manajemen Izin: Setelah mengizinkan akun layanan ApsaraDB RDS untuk mengakses Bucket OSS, peran bernama AliyunRDSImportRole akan dibuat di Resource Access Management (RAM). Jangan modifikasi atau hapus peran ini, karena hal tersebut dapat menyebabkan kegagalan migrasi. Jika peran dimodifikasi atau dihapus, Anda harus memberikan otorisasi ulang kepada akun layanan melalui wizard migrasi.

  • Manajemen Akun: Setelah migrasi selesai, akun dari instans SQL Server yang dikelola sendiri tidak dapat digunakan lagi. Anda harus membuat akun baru untuk instans RDS di Konsol ApsaraDB RDS.

  • Penyimpanan File OSS: Sebelum migrasi selesai, jangan hapus file cadangan dari Bucket OSS, karena hal tersebut dapat menyebabkan kegagalan migrasi.

  • Persyaratan File Cadangan:

    • Pembatasan Nama File: Nama file cadangan tidak boleh berisi karakter khusus (seperti !@#$%^&*()_+-=), karena hal tersebut dapat menyebabkan kegagalan migrasi.

    • Akhiran File: Nama file cadangan harus memiliki akhiran .bak (file cadangan penuh), .diff (file cadangan diferensial), .trn, atau .log (file cadangan log). Sistem tidak dapat mengenali jenis file lainnya.

      Catatan
      • Dalam skenario bisnis nyata, file cadangan mungkin disimpan dalam format yang berbeda. Misalnya, file dengan akhiran .bak bisa menjadi file cadangan penuh, file cadangan diferensial, atau file cadangan log.

      • Jika file cadangan adalah file cadangan log dari instans SQL Server yang dikelola sendiri dan diunduh di Konsol ApsaraDB RDS (bukan file cadangan .bak yang dihasilkan oleh skrip resmi di Langkah 1 topik ini), format default file cadangan yang diunduh adalah .zip.log. File cadangan yang diunduh dapat digunakan untuk migrasi cloud setelah Anda mengonversi format file tersebut.

        Metode Pemrosesan: Ubah ekstensi file menjadi .zip untuk dekompresi, ubah nama file nama_database.lbak yang telah diekstraksi menjadi file dengan akhiran .bak, lalu unggah file .bak ke Bucket OSS sebagai file cadangan log inkremental untuk migrasi cloud.

Contoh alur operasi

Fase Migrasi

Langkah

Deskripsi

Tahap Migrasi Data Penuh

Langkah 1. Sebelum 00:00

Selesaikan persiapan berikut:

  • Jalankan pernyataan DBCC CHECKDB pada database sumber dari instans SQL Server yang dikelola sendiri dan verifikasi bahwa tidak ada kesalahan alokasi atau konsistensi.

  • Matikan sistem cadangan untuk database sumber.

  • Ubah model pemulihan database yang dikelola sendiri menjadi FULL.

Langkah 2. 00:01

Lakukan cadangan penuh pada database sumber. Waktu yang diperlukan: sekitar 1 jam.

Langkah 3. 02:00

Unggah file cadangan penuh ke Bucket OSS. Waktu yang diperlukan: sekitar 1 jam.

Langkah 4. 03:00

Pulihkan data dari file cadangan penuh ke instans RDS Anda di Konsol ApsaraDB RDS. Waktu yang diperlukan: sekitar 19 jam.

Fase Inkremental

Langkah 5. 22:00

Lakukan cadangan log pada database sumber. Waktu yang diperlukan: sekitar 20 menit.

Langkah 6. 22:20

Unggah file cadangan log ke Bucket OSS. Waktu yang diperlukan: sekitar 10 menit.

Langkah 6. 22:30

  • Ulangi Langkah 5 dan Langkah 6 untuk melakukan cadangan log pada database sumber, unggah file cadangan log ke Bucket OSS, lalu pulihkan data dari file cadangan log ke instans RDS Anda. Lakukan operasi ini hingga ukuran file cadangan log terakhir kurang dari 500 MB.

  • Hentikan penulisan data ke database sumber, lakukan cadangan log terakhir, lalu unggah file cadangan log terakhir ke Bucket OSS.

Pembukaan Database

Langkah 8. 22:34

Unggahan inkremental file cadangan LOG terakhir ke cloud selesai, yang memakan waktu 4 menit. Sekarang mulai membawa database online.

Langkah 9. 22:35

Buka database tujuan pada instans RDS Anda. Jika Anda menjalankan pernyataan DBCC dalam mode asinkron, database tujuan dapat dibuka dalam 1 menit.

Migrasi di atas memberikan contoh cara meminimalkan downtime. Aplikasi Anda dapat terus berjalan, dan Anda tidak perlu menghentikan aplikasi Anda hingga cadangan log terakhir. Dalam contoh ini, downtime aplikasi Anda tidak melebihi 5 menit.

1. Cadangkan database sumber

  1. Unduh skrip cadangan dan buka menggunakan SQL Server Management Studio (SSMS).

  2. Konfigurasikan parameter berikut:

    Parameter

    Deskripsi

    @backup_databases_list

    Nama database sumber yang ingin Anda cadangkan. Jika Anda menentukan beberapa database, pisahkan nama-nama database tersebut dengan titik koma (;) atau koma (,).

    @backup_type

    Tipe cadangan. Nilai yang valid:

    • FULL: cadangan penuh

    • DIFF: backup diferensial

    • LOG: cadangan log

    @backup_folder

    Direktori yang digunakan untuk menyimpan file cadangan pada database yang dikelola sendiri. Jika direktori yang ditentukan tidak ada, sistem akan secara otomatis membuatnya.

    @is_run

    Menentukan apakah akan melakukan cadangan atau hanya pengecekan. Nilai yang valid:

    • 1: melakukan cadangan.

    • 0: hanya melakukan pengecekan.

  3. Jalankan skrip cadangan.

    Setelah dijalankan, file .bak akan dibuat secara otomatis, terlepas dari tipe cadangan yang Anda tentukan.

2. Unggah file cadangan ke OSS

  1. Sebelum mengunggah file cadangan ke OSS, Anda perlu membuat Bucket OSS.

    • Jika Bucket OSS sudah ada, pastikan memenuhi persyaratan berikut:

      • Kelas penyimpanan dari bucket adalah Standard. Kelas penyimpanan tidak boleh Standar, Infrequent Access (IA), Arsip, Penyimpanan Arsip Dingin, atau Deep Cold Archive.

      • Enkripsi data tidak diaktifkan untuk bucket tersebut.

    • Jika tidak ada Bucket OSS yang tersedia, Anda perlu membuat satu. (Pastikan bahwa Anda telah mengaktifkan OSS)

      1. Masuk ke Konsol OSS, klik Buckets, lalu klik Create Bucket.

      2. Konfigurasikan parameter berikut. Pertahankan nilai default untuk parameter lainnya.

        Penting
        • Bucket ini terutama digunakan untuk migrasi data ini, Anda hanya perlu mengonfigurasi parameter kunci. Setelah migrasi selesai, Anda dapat menghapus bucket untuk mencegah pelanggaran data dan menghindari biaya terkait.

        • Jangan aktifkan enkripsi data saat membuat bucket.

        Parameter

        Deskripsi

        Contoh

        Bucket Name

        Nama dari Bucket OSS. Nama ini unik secara global dan tidak dapat diubah setelah dikonfigurasi.

        Aturan penamaan:

        • Nama hanya dapat berisi huruf kecil, angka, dan tanda hubung (-).

        • Nama harus dimulai dan diakhiri dengan huruf kecil atau angka.

        • Nama harus memiliki panjang 3 hingga 63 karakter.

        migratetest

        Region

        Wilayah dari Bucket OSS. Jika Anda ingin mengunggah data ke Bucket OSS dari Instance Elastic Compute Service (ECS) melalui jaringan internal dan kemudian memulihkan data ke instance RDS melalui jaringan internal, pastikan bahwa Bucket OSS, Instance ECS, dan Instance RDS berada di wilayah yang sama.

        Tiongkok (Hangzhou)

        Storage Class

        Pilih Standard. Operasi migrasi cloud yang dijelaskan dalam topik ini tidak dapat dilakukan di bucket dengan kelas penyimpanan lainnya.

        Standard

  2. Unggah file cadangan ke Bucket OSS.

    Setelah database yang dikelola sendiri dicadangkan, unggah file cadangan ke Bucket OSS yang berada di wilayah yang sama dengan instance RDS Anda. Jika Bucket OSS dan instance RDS berada di wilayah yang sama, mereka dapat berkomunikasi satu sama lain melalui jaringan internal. Ini mencegah pembuatan biaya lalu lintas internet dan mempercepat pengunggahan data. Anda dapat menggunakan salah satu metode berikut:

    Metode 1: Gunakan alat ossbrowser (disarankan)

    1. Unduh ossbrowser.

    2. Sebagai contoh, jika sistem operasi Anda adalah Windows x64, ekstrak paket oss-browser-win32-x64.zip yang diunduh, dan klik dua kali aplikasi oss-browser.exe.

    3. Gunakan AK sebagai metode login, konfigurasikan parameter AccessKeyId dan AccessKeySecret, pertahankan nilai default dari parameter lainnya, lalu klik Log On.

      Catatan

      AccessKey digunakan untuk verifikasi identitas untuk memastikan keamanan data. Jagalah agar AccessKey Anda tetap aman.

      登录ossbrowser

    4. Klik bucket target untuk masuk ke ruang penyimpanan.进入bucket中

    5. Klik 上传图标, pilih file cadangan yang ingin Anda unggah, lalu klik Buka untuk mengunggah file lokal ke OSS.

    Metode 2: Gunakan Konsol OSS

    Catatan

    Jika ukuran file cadangan kurang dari 5 GB, kami sarankan Anda mengunggah file cadangan di Konsol OSS.

    1. Masuk ke Konsol OSS.

    2. Klik Buckets, lalu klik nama bucket target.网页进入bucket

    3. Di bagian Files, klik Upload.网页上传文件

    4. Anda dapat menyeret dan melepas file cadangan ke bagian Files To Upload, atau klik Select Files untuk memilih file cadangan yang ingin Anda unggah.网页扫描文件

    5. Klik Upload di bagian bawah halaman untuk mengunggah file cadangan lokal ke OSS.

    Menggunakan API OSS untuk unggah multi-bagian

    Catatan

    Jika ukuran file cadangan lebih besar dari 5 GB, kami sarankan Anda memanggil API OSS untuk mengunggah file cadangan ke Bucket OSS menggunakan unggah multi-bagian.

    Kode sampel berikut menunjukkan cara mendapatkan kredensial akses dari variabel lingkungan dalam proyek Java. Anda perlu mengonfigurasi variabel lingkungan sebelum menjalankan kode sampel. Untuk informasi lebih lanjut, 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 {
            // Dalam contoh ini, endpoint dari wilayah Tiongkok (Hangzhou) digunakan. Tentukan endpoint aktual Anda.
            String endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
            // Dapatkan kredensial akses dari variabel lingkungan. Sebelum menjalankan kode sampel, pastikan variabel lingkungan OSS_ACCESS_KEY_ID dan OSS_ACCESS_KEY_SECRET telah dikonfigurasi.
            EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
            // Tentukan nama bucket. Contoh: examplebucket.
            String bucketName = "examplebucket";
            // Tentukan jalur lengkap objek. Contoh: exampledir/exampleobject.txt. Jangan sertakan nama bucket dalam jalur lengkap.
            String objectName = "exampledir/exampleobject.txt";
            // Tentukan jalur lengkap file lokal yang ingin Anda unggah.
            String filePath = "D:\\localpath\\examplefile.txt";
            // Tentukan wilayah tempat bucket berada. Misalnya, jika bucket berada di wilayah Tiongkok (Hangzhou), atur wilayah menjadi cn-hangzhou.
            String region = "cn-hangzhou";
    
            // Buat instance OSSClient.
            // Panggil metode shutdown untuk melepaskan sumber daya ketika OSSClient tidak lagi digunakan.
            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 tentukan parameter 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 tugas unggah multi-bagian.
                InitiateMultipartUploadResult upresult = ossClient.initiateMultipartUpload(request);
                // Dapatkan ID unggah.
                String uploadId = upresult.getUploadId();
    
                // partETags adalah himpunan PartETags. PartETag terdiri dari nomor bagian dan ETag dari bagian yang diunggah.
                List<PartETag> partETags = new ArrayList<PartETag>();
                // Tentukan ukuran setiap bagian, yang digunakan untuk menghitung jumlah bagian dari objek. Unit: byte.
    
                // Atur ukuran bagian menjadi 1 MB.
                final long partSize = 1 * 1024 * 1024L;
    
                // Hitung jumlah bagian berdasarkan ukuran data yang diunggah. Dalam kode sampel berikut, file lokal digunakan sebagai contoh untuk menggambarkan cara menggunakan metode File.length() untuk mendapatkan ukuran data yang diunggah.
                final File sampleFile = new File(filePath);
                long fileLength = sampleFile.length();
                int partCount = (int) (fileLength / partSize);
                if (fileLength % partSize != 0) {
                    partCount++;
                }
                // Unggah setiap bagian hingga semua bagian diunggah.
                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);
                    // Tentukan input stream dari tugas unggah multi-bagian.
                    // Dalam kode sampel berikut, file lokal digunakan sebagai contoh untuk menggambarkan cara membuat objek FileInputStream dan menggunakan metode InputStream.skip() untuk melewati data tertentu.
                    InputStream instream = new FileInputStream(sampleFile);
                    instream.skip(startPos);
                    uploadPartRequest.setInputStream(instream);
                    // Tentukan ukuran yang tersedia untuk setiap bagian. Ukuran setiap bagian kecuali bagian terakhir harus lebih besar dari atau sama dengan 100 KB.
                    uploadPartRequest.setPartSize(curPartSize);
                    // Tentukan nomor bagian. Setiap bagian memiliki nomor bagian yang berkisar antara 1 hingga 10.000. Jika nomor bagian yang Anda tentukan tidak termasuk dalam rentang yang ditentukan, OSS mengembalikan kode kesalahan InvalidArgument.
                    uploadPartRequest.setPartNumber(i + 1);
                    // Bagian tidak harus diunggah secara berurutan dan dapat diunggah dari klien OSS yang berbeda. OSS mengurutkan bagian berdasarkan nomor bagian dan menggabungkan bagian menjadi objek lengkap.
                    UploadPartResult uploadPartResult = ossClient.uploadPart(uploadPartRequest);
                    // Setelah bagian diunggah, OSS mengembalikan hasil yang berisi PartETag. PartETag disimpan di partETags.
                    partETags.add(uploadPartResult.getPartETag());
    
                    // Nonaktifkan input stream.
                    instream.close();
                }
    
                // Buat objek CompleteMultipartUploadRequest.
                // Saat Anda memanggil operasi CompleteMultipartUpload, Anda harus menyediakan semua partETags yang valid. Setelah OSS menerima PartETags, OSS memverifikasi semua bagian satu per satu. Setelah semua bagian diverifikasi, OSS menggabungkan bagian-bagian ini menjadi objek lengkap.
                CompleteMultipartUploadRequest completeMultipartUploadRequest =
                        new CompleteMultipartUploadRequest(bucketName, objectName, uploadId, partETags);
    
                // Selesaikan tugas unggah multi-bagian.
                CompleteMultipartUploadResult completeMultipartUploadResult = ossClient.completeMultipartUpload(completeMultipartUploadRequest);
                System.out.println("Unggah berhasil,ETag:" + completeMultipartUploadResult.getETag());
    
            } catch (OSSException oe) {
                System.out.println("Tangkap OSSException, yang berarti permintaan Anda mencapai 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("Tangkap 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 Instans. Di bilah navigasi atas, pilih Wilayah tempat Instans RDS berada. Kemudian, cari Instans RDS dan klik ID-nya.

  2. Di panel navigasi kiri, klik Backup And Restoration.

  3. Klik OSS Backup Data Recovery To Cloud di bagian atas halaman.

  4. Di wizard Import Guide, klik Next dua kali untuk mengimpor data.

    Catatan

    Jika ini adalah pertama kalinya Anda menggunakan wizard migrasi berbasis OSS, Anda harus memberikan otorisasi akun ApsaraDB RDS untuk mengakses Bucket OSS. Dalam kasus ini, klik Authorize dan selesaikan proses otorisasi. Jika tidak, daftar drop-down OSS Bucket pada langkah Import Data akan kosong.

  5. Konfigurasikan parameter berikut, lalu klik OK.

    Tunggu hingga tugas migrasi selesai. Anda dapat mengklik Refresh untuk memeriksa status terbaru tugas migrasi. Jika tugas migrasi gagal, perbaiki masalah sesuai dengan pesan kesalahan. Untuk informasi lebih lanjut, lihat Kesalahan Umum dalam topik ini.

    Parameter

    Deskripsi

    Database Name

    Masukkan nama database tujuan pada Instans RDS Anda. Database tujuan digunakan untuk menyimpan data yang dimigrasi dari database sumber pada instans SQL Server yang dikelola sendiri. Nama database tujuan harus memenuhi persyaratan open source SQL Server.

    Penting
    • Sebelum migrasi, pastikan bahwa nama-nama database pada Instans RDS tujuan berbeda dari nama database yang ingin Anda pulihkan menggunakan file cadangan yang ditentukan. Selain itu, pastikan bahwa file database dengan nama yang sama seperti database yang ingin Anda pulihkan tidak ditambahkan ke database pada Instans RDS tujuan. Jika kedua persyaratan tersebut terpenuhi, Anda dapat memulihkan database menggunakan file database dalam set cadangan. Perhatikan bahwa file database harus memiliki nama yang sama dengan database yang ingin Anda pulihkan.

    • Jika database dengan nama yang sama seperti database yang ditentukan dalam file cadangan sudah ada pada instans tujuan, atau jika ada file database yang belum disambungkan dengan nama yang sama, operasi pemulihan akan gagal.

    OSS Bucket

    Pilih Bucket OSS yang menyimpan file cadangan penuh.

    OSS File List

    Klik tombol kaca pembesar di sebelah kanan untuk mencari file cadangan menggunakan pencocokan kabur berdasarkan awalan nama file cadangan. Sistem menampilkan nama, ukuran, dan waktu pembaruan setiap file cadangan. Pilih file cadangan yang ingin Anda migrasikan ke cloud.

    Cloud Migration Method

    Pilih Do Not Create A Database.

    • Akses Segera (Cadangan Penuh): Metode ini cocok untuk migrasi data penuh ke cloud. Jika Anda hanya ingin memigrasikan file cadangan penuh, pilih metode migrasi ini. Dalam hal ini, pengaturan parameter berikut berlaku dalam operasi CreateMigrateTask: BackupMode = FULL dan IsOnlineDB = True.

    • Akses Tertunda (Cadangan Inkremental): Metode ini cocok untuk migrasi data inkremental ke cloud. Jika Anda ingin memigrasikan file cadangan penuh dan file log atau cadangan diferensial, pilih metode migrasi ini. Dalam hal ini, pengaturan parameter berikut berlaku dalam operasi CreateMigrateTask: BackupMode = UPDF dan IsOnlineDB = False.

4. Impor file backup log atau diferensial

Setelah file backup penuh dari database sumber pada instans SQL Server yang dikelola sendiri diimpor ke database tujuan pada instans RDS Anda, langkah berikutnya adalah mengimpor file backup log atau diferensial.

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

  2. Di panel navigasi kiri, klik Backup And Restoration. Pada halaman yang muncul, pilih tab Cloud Migration Records Of Backup Data.

  3. Cari database tujuan dan klik Upload Incremental Files di kolom Tindakan Tugas. Pilih file tambahan dan klik OK.

    Catatan
    • Jika terdapat beberapa file backup log, gunakan metode yang sama untuk mengunggah file backup log satu per satu.

    • Pastikan ukuran file backup log atau diferensial terakhir tidak melebihi 500 MB untuk meminimalkan waktu yang diperlukan menyelesaikan migrasi.

    • Sebelum membuat file backup log atau diferensial terakhir, hentikan penulisan data ke database yang dikelola sendiri. Hal ini memastikan konsistensi data antara database yang dikelola sendiri dan database tujuan pada instans RDS Anda.

5. Buka database

Setelah semua file cadangan diimpor ke database tujuan pada instans RDS Anda, database tujuan akan berstatus In Recovery atau Restoring. Jika instans RDS Anda menggunakan RDS Edisi Ketersediaan Tinggi, database tujuan akan berstatus In Recovery. Namun, jika instans RDS Anda menggunakan RDS Edisi Dasar, database tujuan akan berstatus Restoring. Dalam kondisi ini, operasi baca atau tulis tidak dapat dilakukan pada database tujuan. Untuk melanjutkan operasi baca dan tulis, Anda harus membuka database tujuan terlebih dahulu.

  1. Buka halaman Instans. Di bilah navigasi atas, pilih wilayah tempat Instans RDS berada. Selanjutnya, cari Instans RDS dan klik ID-nya.

  2. Di panel navigasi sebelah kiri, klik Backup And Restoration. Pada halaman yang terbuka, klik tab Cloud Migration Records Of Backup Data.

  3. Temukan database tujuan dan klik Open Database pada kolom Tindakan Tugas.

  4. Pilih mode pemeriksaan konsistensi dan klik OK.

    Catatan

    ApsaraDB RDS menyediakan mode pemeriksaan konsistensi berikut:

    • DBCC Asinkron: Pernyataan DBCC CHECKDB dieksekusi setelah database tujuan dibuka. Mode ini mengurangi waktu yang diperlukan untuk membuka database tujuan dan meminimalkan waktu mati aplikasi Anda. Namun, jika database tujuan besar, eksekusi pernyataan DBCC CHECKDB akan memerlukan waktu yang lebih lama. Jika aplikasi Anda sensitif terhadap waktu mati tetapi tidak sensitif terhadap hasil dari pernyataan DBCC CHECKDB, disarankan untuk memilih mode ini. Dalam hal ini, pengaturan parameter berikut berlaku dalam operasi CreateMigrateTask: CheckDBMode = AsyncExecuteDBCheck.

    • DBCC Sinkron: Pernyataan DBCC CHECKDB dieksekusi pada saat yang sama ketika database tujuan dibuka. Jika Anda ingin mengidentifikasi kesalahan konsistensi antara database yang dikelola sendiri dan database tujuan berdasarkan hasil dari pernyataan DBCC CHECKDB, disarankan untuk memilih mode ini. Namun, waktu yang diperlukan untuk membuka database tujuan akan bertambah. Dalam hal ini, pengaturan parameter berikut berlaku dalam operasi CreateMigrateTask: CheckDBMode = SyncExecuteDBCheck.

6. Lihat detail file cadangan yang diimpor

Buka halaman Backup And Restoration dari panel navigasi di sebelah kiri Instans RDS. Pada halaman yang muncul, klik tab Cloud Migration Records Of Backup Data untuk melihat catatan migrasi cadangan. Klik View File Details di kolom Tindakan Tugas pada tugas yang sesuai untuk melihat detail semua file cadangan terkait.

Catatan

Setelah migrasi cloud selesai, sistem mencadangkan data berdasarkan waktu cadangan yang ditentukan dalam kebijakan cadangan otomatis dari Instans RDS. Set cadangan yang dihasilkan mencakup data yang dimigrasikan ke cloud. Anda dapat melihat detailnya di halaman Backup And Restoration dari Instans RDS. Waktu cadangan dapat disesuaikan secara manual.

Jika waktu cadangan yang ditentukan belum tiba tetapi Anda memerlukan file cadangan di cloud, Anda dapat memicu cadangan manual.

Kesalahan umum

Untuk informasi lebih lanjut mengenai kesalahan umum yang mungkin terjadi selama migrasi data cadangan penuh, lihat Kesalahan Umum dalam topik tentang migrasi data cadangan penuh.

Selama migrasi data cadangan inkremental, Anda mungkin menemui kesalahan berikut:

  • Database tujuan tidak dapat dibuka

    • Pesan kesalahan: Gagal membuka database xxx.

    • Penyebab: Beberapa fitur canggih diaktifkan pada instans SQL Server yang dikelola sendiri. Namun, fitur tersebut tidak didukung oleh instans RDS Anda. Sebagai contoh, jika instans SQL Server yang dikelola sendiri menjalankan Edisi Perusahaan SQL Server dan instans RDS Anda menggunakan edisi Web SQL Server, kesalahan ini akan dilaporkan ketika fitur kompresi data dan partisi diaktifkan pada instans SQL Server yang dikelola sendiri saat membuka database tujuan pada instans RDS.

    • Solusi:

  • Nomor Urutan Log (LSN) dalam rantai cadangan tidak berurutan

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

    • Penyebab: LSN dalam file cadangan log atau diferensial berbeda dari LSN dalam file cadangan sebelumnya yang digunakan untuk pemulihan.

    • Solusi: Pilih file cadangan LSN yang sesuai untuk mengunggah file cadangan inkremental. Unggah dapat dilakukan secara kronologis berdasarkan waktu setiap operasi cadangan.

  • Pernyataan DBCC CHECKDB tidak dapat dieksekusi dalam mode asinkron

    • Pesan kesalahan: DBCC checkdb gagal secara asinkron: CHECKDB menemukan 0 kesalahan alokasi dan 2 kesalahan konsistensi dalam tabel 'XXX' (ID objek XXX).

    • Penyebab: Setelah data dipulihkan ke instans RDS Anda dengan mode pemeriksaan konsistensi DBCC Asinkron yang dipilih, ApsaraDB RDS mengeksekusi pernyataan DBCC CHECKDB. Jika database tujuan gagal dalam pemeriksaan konsistensi, kesalahan konsistensi terjadi di database yang dikelola sendiri.

    • Solusi:

      • Eksekusi pernyataan berikut pada database tujuan:

        DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)
        Penting

        Jika Anda mengeksekusi pernyataan ini untuk memperbaiki kesalahan, data Anda mungkin hilang.

      • Eksekusi pernyataan berikut pada database yang dikelola sendiri untuk memperbaiki kesalahan, kemudian migrasikan data lagi:

        DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)
  • File cadangan yang dipilih adalah file cadangan penuh

    • Pesan kesalahan: Backup set (xxx) adalah Database FULL backup, kami hanya menerima transaction log atau differential backup.

    • Penyebab: Setelah data dipulihkan ke instans RDS Anda menggunakan file cadangan penuh, Anda hanya dapat memilih file log atau cadangan diferensial. Jika Anda memilih file cadangan penuh lagi, kesalahan ini dilaporkan.

    • Solusi: Pilih file log atau cadangan diferensial.

  • Jumlah database sumber yang ditentukan melebihi batas atas

    • Pesan kesalahan: Migrasi database (xxx) gagal karena batasan jumlah database.

    • Penyebab: Jika jumlah database sumber yang ditentukan melebihi batas atas, kesalahan ini dilaporkan.

    • Solusi: Migrasikan data dari database sumber ke instans RDS lain. Jika tidak, hapus database yang tidak diperlukan.

  • Pengguna RAM tidak memiliki izin yang diperlukan

    • T1: Ketika Anda melakukan Langkah 5 dari Buat Tugas Migrasi Cloud, semua nilai parameter dikonfigurasi dengan benar, tetapi tombol OK redup?

    • A1: Tombol tersebut mungkin redup karena Anda menggunakan pengguna RAM yang tidak memiliki izin yang diperlukan. Lihat bagian Prasyarat dari topik ini untuk memastikan bahwa izin yang diperlukan telah diberikan.

    • T2: Bagaimana cara menyelesaikan kesalahan tidak ada izin ketika saya menggunakan pengguna RAM untuk memberikan izin AliyunRDSImportRole?

    • A2: Gunakan akun Alibaba Cloud Anda untuk sementara memberikan izin AliyunRAMFullAccess kepada pengguna RAM. Untuk informasi lebih lanjut mengenai cara memberikan izin kepada pengguna RAM, lihat Gunakan RAM untuk Mengelola Izin ApsaraDB RDS.

Operasi API terkait

API

Deskripsi

CreateMigrateTask

Memulihkan file cadangan dari OSS ke instans ApsaraDB RDS for SQL Server dan membuat tugas migrasi data.

CreateOnlineDatabaseTask

Membuka database dari tugas migrasi data ApsaraDB RDS for SQL Server.

DescribeMigrateTasks

Memeriksa daftar tugas migrasi data untuk instans ApsaraDB RDS for SQL Server.

DescribeOssDownloads

Memeriksa detail file dari tugas migrasi data ApsaraDB RDS for SQL Server.