Bagikan melalui


Panduan migrasi: SQL Server ke Azure SQL Database

Berlaku untuk: SQL Server Azure SQL Database

Dalam panduan ini, Anda mempelajari cara memigrasikan instans SQL Server Anda ke Azure SQL Database.

Selesaikan langkah-langkah pra-migrasi sebelum melanjutkan.

Migrate

Setelah menyelesaikan langkah-langkah untuk tahap pra-migrasi, Anda siap untuk melakukan skema dan migrasi data.

Migrasikan data Anda menggunakan metode migrasi yang Anda pilih.

Migrasi menggunakan ekstensi migrasi Azure SQL untuk Azure Data Studio

Untuk melakukan migrasi offline menggunakan Azure Data Studio, ikuti langkah-langkah tingkat tinggi di bawah ini. Untuk tutorial langkah demi langkah terperinci, lihat Tutorial: Memigrasikan SQL Server ke Azure SQL Database (offline).

  1. Unduh serta instal Azure Data Studio dan ekstensi migrasi Azure SQL.
  2. Luncurkan wizard Migrasi ke Azure SQL Migration di ekstensi di Azure Data Studio.
  3. Pilih database untuk penilaian dan lihat kesiapan atau masalah migrasi (jika ada). Selain itu, kumpulkan data performa dan dapatkan rekomendasi Azure berukuran tepat.
  4. Pilih akun Azure dan Target Azure SQL Database Anda dari langganan Anda.
  5. Pilih daftar tabel yang akan dimigrasikan.
  6. Buat Azure Database Migration Service baru menggunakan wizard di Azure Data Studio. Jika sebelumnya Anda telah membuat Azure Database Migration Service menggunakan Azure Data Studio, Anda dapat menggunakan kembali yang sama, jika diinginkan.
  7. Opsional: Jika cadangan Anda berada di berbagi jaringan lokal, unduh dan instal runtime integrasi yang dihost sendiri pada mesin yang dapat tersambung ke SQL Server sumber, dan lokasi yang berisi file cadangan.
  8. Mulai migrasi database dan pantau kemajuan di Azure Data Studio. Anda juga dapat memantau kemajuan di bagian sumber daya Azure Database Migration Service di portal Microsoft Azure.

Sinkronisasi dan transisi langsung data

Saat menggunakan opsi migrasi yang terus-menerus mereplikasi/menyinkronkan perubahan data dari sumber ke target, data sumber dan skema dapat berubah serta menyimpang dari data dan skema pada target. Selama sinkronisasi data, pastikan bahwa semua perubahan pada sumber diterima dan diterapkan ke target selama proses migrasi.

Setelah Anda memverifikasi bahwa data sama pada sumber dan target, Anda dapat memotong dari sumber ke lingkungan target. Penting untuk merencanakan proses peralihan langsung dengan tim bisnis/aplikasi guna memastikan gangguan minimal selama peralihan langsung tidak memengaruhi kelangsungan bisnis.

Penting

Untuk detail tentang langkah-langkah spesifik yang terkait dengan melakukan cutover sebagai bagian dari migrasi menggunakan DMS, lihat Tutorial: Memigrasikan SQL Server ke Azure SQL Database menggunakan DMS (klasik).

Migrasi menggunakan replikasi transaksional

Ketika Anda tidak mampu menghapus database SQL Server Anda dari produksi saat migrasi terjadi, Anda dapat menggunakan replikasi transaksional SQL Server sebagai solusi migrasi Anda. Untuk menggunakan metode ini, database sumber harus memenuhi persyaratan untuk replikasi transaksional dan kompatibel untuk Azure SQL Database. Untuk informasi tentang replikasi SQL dengan grup ketersediaan, lihat Mengonfigurasi replikasi dengan grup ketersediaan AlwaysOn.

Untuk menggunakan solusi ini, Anda mengonfigurasi database Anda di Azure SQL Database sebagai pelanggan ke instans SQL Server yang ingin Anda migrasikan. Distributor replikasi transaksional menyinkronkan data dari database yang akan disinkronkan (penerbit) saat transaksi baru berlanjut.

Dengan replikasi transaksional, semua perubahan pada data atau skema Anda muncul di database Anda di Azure SQL Database. Setelah sinkronisasi selesai dan Anda siap untuk melakukan migrasi, ubah string koneksi aplikasi Anda untuk mengarahkannya ke database Anda. Setelah replikasi transaksional menguras perubahan apa pun yang tersisa di database sumber Anda dan semua aplikasi Anda mengarah ke Azure SQL Database, Anda dapat menghapus instalan replikasi transaksional. Database Anda di Azure SQL Database sekarang menjadi sistem produksi Anda.

Tip

Anda juga dapat menggunakan replikasi transaksional untuk memigrasikan subset database sumber Anda. Publikasi yang Anda replikasi ke Azure SQL Database dapat dibatasi pada subset tabel dalam database yang sedang direplikasi. Untuk setiap tabel yang sedang direplikasi, Anda dapat membatasi data ke subset baris dan/atau subset kolom.

Alur kerja replikasi transaksi

Penting

Gunakan versi terbaru SQL Server Management Studio untuk tetap disinkronkan dengan pembaruan untuk Azure dan SQL Database. Versi SQL Server Management Studio yang lebih lama tidak dapat menyiapkan SQL Database sebagai pelanggan. Dapatkan versi terbaru SQL Server Management Studio.

Langkah Metode
Menyiapkan distribusi SQL Server Management Studio | Transact-SQL
Membuat publikasi SQL Server Management Studio | Transact-SQL
Buat langganan SQL Server Management Studio | Transact-SQL

Beberapa tips dan perbedaan untuk migrasi ke SQL Database

  • Menggunakan distributor lokal
    • Melakukannya menyebabkan dampak performa pada server.
    • Jika dampak performa tidak dapat diterima, Anda dapat menggunakan server lain, tetapi menambahkan kompleksitas dalam manajemen dan administrasi.
  • Saat memilih folder rekam jepret, pastikan folder yang Anda pilih cukup besar untuk menahan BCP dari setiap tabel yang ingin Anda replikasi.
  • Pembuatan rekam jepret mengunci tabel terkait hingga selesai, jadi jadwalkan rekam jepret Anda dengan tepat.
  • Hanya langganan pendorongan di Azure SQL Database yang didukung. Anda hanya bisa menambahkan pelanggan dari database sumber.

Rekomendasi migrasi

Untuk mempercepat migrasi ke Azure SQL Database, Anda harus mempertimbangkan rekomendasi berikut:

Ketidaksesuaian sumber daya Rekomendasi
Sumber (biasanya lokal) Hambatan utama selama migrasi dari sumber adalah I/O file data dan latensi, yang perlu dipantau dengan hati-hati. Berdasarkan I/O dan latensi file data, dan tergantung pada apakah itu komputer virtual atau server fisik, Anda mungkin harus melibatkan admin penyimpanan Anda dan menjelajahi opsi untuk mengurangi hambatan.
Target (Azure SQL Database) Faktor pembatasan terbesar adalah laju pembuatan log dan latensi pada file log database Anda. Dengan Azure SQL Database, Anda bisa mendapatkan tingkat pembuatan log maksimum 96 MB/dtk. Untuk mempercepat migrasi, tingkatkan skala database Azure SQL target ke Business Critical Gen5 8 vCore untuk mendapatkan tingkat pembuatan log maksimum 96 MB/dtk, yang juga memberikan latensi rendah untuk file log. Tingkat layanan Hyperscale menyediakan tingkat log 100 MB/dtk terlepas dari tingkat layanan yang dipilih.
Jaringan Bandwidth jaringan yang diperlukan sama dengan tingkat penyerapan log maksimum 96 MB/dtk (768 Mb/dtk) Bergantung pada konektivitas jaringan dari pusat data lokal Anda ke Azure, periksa bandwidth jaringan Anda (biasanya Azure ExpressRoute) untuk mengakomodasi tingkat penyerapan log maksimum.

Anda juga dapat mempertimbangkan rekomendasi ini untuk performa terbaik selama proses migrasi.

  • Pilih tingkat layanan dan ukuran komputasi tertinggi yang memungkinkan anggaran Anda untuk memaksimalkan performa transfer. Anda dapat menurunkan skala setelah migrasi selesai untuk menghemat uang.
  • Jika Anda menggunakan file BACPAC, minimalkan jarak antara file BACPAC Anda dan pusat data tujuan.
  • Nonaktifkan pembaruan otomatis dan buat statistik secara otomatis selama migrasi.
  • Tabel partisi dan indeks.
  • Hilangkan tampilan terindeks, dan buat ulang setelah selesai.
  • Hapus data riwayat yang jarang dikueri ke database lain dan migrasikan data riwayat ini ke database terpisah di Azure SQL Database. Anda kemudian dapat kueri data riwayat ini menggunakan kueri elastis.

Pasca-migrasi

Setelah Anda berhasil menyelesaikan tahap migrasi, lakukan tugas pascamigrasi berikut untuk memastikan bahwa semuanya berfungsi dengan lancar dan efisien.

Fase pasca-migrasi sangat penting untuk menyelesaikan masalah akurasi data, memastikan kelengkapan, dan mengatasi masalah performa terkait beban kerja.

Perbarui statistik

Perbarui statistik dengan pemindaian penuh setelah migrasi selesai.

Meremediasi aplikasi

Setelah data dimigrasikan ke lingkungan target, semua aplikasi yang sebelumnya menggunakan sumber perlu mulai menggunakan target. Dalam beberapa kasus, hal ini akan memerlukan perubahan pada aplikasi.

Melakukan pengujian

Pendekatan pengujian untuk migrasi database terdiri dari aktivitas berikut:

  1. Mengembangkan pengujian validasi: Untuk menguji migrasi database, Anda perlu menggunakan kueri SQL. Anda harus membuat kueri validasi untuk dijalankan terhadap database sumber dan target. Kueri validasi Anda harus melingkupi cakupan yang telah Anda tentukan.
  2. Menyiapkan lingkungan pengujian: Lingkungan pengujian harus berisi salinan database sumber dan database target. Pastikan untuk mengisolasi lingkungan pengujian.
  3. Menjalankan pengujian validasi: Jalankan pengujian validasi terhadap sumber dan target, lalu analisis hasilnya.
  4. Menjalankan uji performa: Jalankan uji performa terhadap sumber dan target, lalu analisis hasil dan bandingkan hasilnya.

Menggunakan fitur tingkat lanjut

Pastikan untuk memanfaatkan fitur lanjutan berbasis cloud yang ditawarkan oleh SQL Database, seperti ketersediaan tinggi bawaan, deteksi ancaman, dan pemantauan dan penyetelan beban kerja.

Beberapa fitur SQL Server hanya tersedia setelah tingkat kompatibilitas database diubah ke tingkat kompatibilitas terbaru.

Untuk mempelajari selengkapnya, lihat mengelola Azure SQL Database setelah migrasi.

Mengatasi masalah kompatibilitas migrasi database

Anda mungkin mengalami berbagai masalah kompatibilitas, tergantung pada versi SQL Server dalam database sumber dan kompleksitas database yang Anda migrasikan. Versi SQL Server yang lebih lama memiliki lebih banyak masalah kompatibilitas. Gunakan sumber daya berikut, selain pencarian Internet yang ditargetkan menggunakan mesin cari pilihan Anda:

Penting

Azure SQL Managed Instance memungkinkan Anda untuk memigrasikan instans SQL Server yang ada dan databasenya dengan minimal hingga tanpa masalah kompatibilitas. Lihat Apa itu Azure SQL Managed Instance?