Seiring berjalannya waktu, semakin banyak perusahaan yang bermigrasi ke, atau setidaknya mengevaluasi, Azure SQL Database sebagai alternatif dari biaya tinggi menjalankan SQL Server di tempat.
Memeriksa Kompatibilitas
Salah satu aspek pertama memindahkan database Anda ke Azure SQL Database adalah untuk memeriksa kompatibilitas dan Microsoft memberi Anda banyak cara untuk melakukan ini untuk Azure SQL Database V12 (selanjutnya disebut hanya 'V12'). Salah satu metode ini menggunakan SQL Server Data Tools for Visual Studio (SSDT) yang menggunakan aturan kompatibilitas terbaru untuk mendeteksi ketidaksesuaian V12. Di SSDT Anda dapat mengimpor skema database Anda dan membangun proyek untuk penerapan V12, dan jika ditemukan ketidaksesuaian, mereka dapat diperbaiki dalam SSDT dan kemudian disinkronkan kembali ke database sumber.
Anda juga dapat menggunakan alat baris perintah yang disebut SqlPackage yang dapat menghasilkan laporan masalah kompatibilitas (dan selalu pastikan Anda memiliki versi terbaru). SQL Server Management Studio adalah cara lain untuk melakukannya, menggunakan fitur Ekspor Data-tier Application, yang dapat mendeteksi dan melaporkan kesalahan ke layar. Jika tidak ada kesalahan yang terdeteksi, Anda dapat memigrasikan database ke V12. Jika ketidakcocokan terdeteksi, mereka dapat diperbaiki menggunakan SSMS sebelum migrasi.
Data Migration Assistant adalah alat yang berdiri sendiri (mudah bingung dengan SQL Server Migration Assistant) yang dapat digunakan untuk membantu mengurangi upaya untuk memutakhirkan, dan menggantikan SQL Server 2016 Upgrade Advisor Preview. DMA juga dapat merekomendasikan peningkatan kinerja dan keandalan. Alat lain, SQL Azure Migration Wizard (SAMW), adalah alat Codeplex yang menggunakan aturan kompatibilitas Azure SQL Database V11 untuk mendeteksi ketidaksesuaian V12. SAMW juga dapat menyelesaikan migrasi ke V12 dan memperbaiki beberapa masalah kompatibilitas. Hal yang perlu diperhatikan saat menggunakan SAMW adalah dapat mendeteksi ketidaksesuaian yang tidak perlu diperbaiki.
Memigrasikan Data
Setelah database Anda lulus pemeriksaan kompatibilitas, Anda harus menentukan metode terbaik untuk bermigrasi. Beberapa metode yang lebih umum termasuk menggunakan SSMS Migration Wizard, mengekspor ke BACPAC, menggunakan replikasi transaksional, atau membuat skrip database secara manual dan memasukkan data Anda.
Menggunakan SSMS Migration Wizard sangat bagus untuk SQL Server 2005 dan database lebih tinggi yang berukuran kecil hingga sedang. Anda dapat mengaktifkan wizard ini di SSMS 2016, dengan mengklik kanan pada database, pilih Tasks, lalu Deploy Database to Microsoft Azure SQL Database. Di SSMS 2014 ini disebut Deploy Database to Windows Azure SQL Database. Menggunakan wizard ini memungkinkan Anda untuk menentukan database yang akan dimigrasi, menyambungkan ke langganan Azure, memilih lokasi untuk file .bacpac, nama database baru, dan tingkat yang akan dimigrasikan. Ketika Anda mengklik selesai, wizard akan mengekstrak dan memvalidasi skema dan kemudian mengekspor data. Setelah data diekspor, itu akan membuat rencana penerapan dan mulai mengimpor data ke database V12 baru.
Sangat mirip dengan Wizard Migrasi SSMS adalah Aplikasi Tingkat Data Ekspor. Untuk memilih opsi ini, klik kanan pada database, pilih Tasks, lalu Export Data-tier Application. Dalam pengaturan ekspor, Anda menentukan di mana Anda ingin membuat file .bacpac. Anda dapat menyimpan ini secara lokal, atau menyimpannya langsung ke akun penyimpanan Azure Anda. Ada juga tab lanjutan di mana Anda dapat memilih tabel mana yang akan disertakan. Ini berguna jika database lokal Anda berisi salinan tabel yang tidak ingin Anda migrasikan ke V12. Ketika Anda memilih Selesai, itu akan mengekspor data Anda. Anda kemudian dapat terhubung ke server Azure Anda melalui SSMS dan memilih untuk Mengimpor Aplikasi Tingkat Data. Anda akan menentukan lokasi file, nama database, dan tingkat Database Azure SQL. Ketika Anda memilih selesai, database akan mulai mengimpor. Metode ini memberi Anda sedikit lebih banyak kontrol atas proses karena memisahkan ekspor dari impor. Ini juga memberi Anda opsi untuk menyimpan file .bacpac di akun penyimpanan Azure Anda sehingga proses impor yang lebih rentan tidak akan bergantung pada koneksi internet Anda.
Opsi saat menggunakan Panduan Migrasi SSMS atau Aplikasi Tingkat Data Ekspor, adalah membuat VM Azure dengan SQL Server dan menyiapkan pengiriman log. Ini akan melakukan pra-tahap database Anda di Azure cloud untuk membantu meminimalkan waktu impor database. Ketika tiba saatnya untuk melakukan migrasi, Anda tinggal mengembalikan backup log terakhir pada secondary lalu menghapus log shipping. Untuk membuat database online, lakukan pemulihan dengan pemulihan. Ini pada dasarnya akan menghilangkan waktu yang diperlukan untuk menyalin database Anda dari pusat data Anda ke pusat data Azure.
Replikasi transaksional adalah metode lain untuk membantu mengurangi waktu henti saat bermigrasi ke V12. Ini adalah opsi terbaik jika Anda memiliki jendela pemeliharaan yang sangat kecil untuk beralih ke V12, jika database dapat mendukung replikasi transaksional. Menyiapkan replikasi transaksional memerlukan kunci utama untuk setiap tabel yang diterbitkan, yang dapat menjadi masalah bagi banyak database. Mengonfigurasi replikasi transaksional juga bisa rumit, karena Anda harus menyiapkan basis data distribusi, menyiapkan penerbit dan pelanggan, dan memantau tugas.
Anda juga dapat melakukan migrasi secara manual menggunakan wizard Hasilkan Skrip dan membuat skrip skema database dan/atau data. Anda kemudian dapat membuat database kosong di Azure dan mengimpor skema dan atau data Anda, dengan menjalankan skrip. Saya telah mendengar beberapa orang menggunakan metode ini untuk membuat database kosong dan kemudian secara manual memasukkan data mereka satu tabel pada satu waktu menggunakan SSMS dan server tertaut. Metode ini mungkin cocok untuk Anda, tetapi juga bisa sangat rumit jika Anda memiliki banyak konstruksi skema seperti hubungan kunci asing dan kolom identitas, dalam hal ini metode lain di atas akan lebih andal dan efisien.
Pertimbangan Migrasi Lainnya
Saat merencanakan migrasi database lokal ke V12, ukuran database merupakan faktor besar dalam berapa lama migrasi akan berlangsung. Ekspor database, transfer data, dan impor semuanya akan meningkat sebanding dengan ukuran database.
Faktor besar lainnya dalam waktu pemulihan/impor saat memindahkan database Anda ke V12 adalah tingkat kinerja yang Anda pulihkan juga. Proses pemulihan/impor membutuhkan banyak tenaga, jadi untuk membantu mempercepat migrasi Anda, Anda harus mempertimbangkan untuk memulihkan ke tingkat kinerja yang lebih tinggi. Saat database online, Anda dapat dengan mudah dan cepat turun ke tingkat yang lebih rendah yang memenuhi kebutuhan kinerja harian Anda. Mampu mengubah tingkat kinerja dengan beberapa klik mouse adalah salah satu manfaat besar dari Azure SQL Database.
Pemantauan
Bagian penting dalam mengelola database apa pun adalah pemantauan. Jika Anda tidak memantau sesuatu, Anda tidak dapat mengukurnya. Jika Anda tidak tahu apa metrik Anda saat semuanya berjalan normal, bagaimana Anda tahu hal mana yang lebih buruk saat performa menurun? Dengan basis data di tempat, kami memiliki alat yang kami kenal:SQL Server Management Studio, Monitor Kinerja, Pengelola Tugas, DMV, dan sebagainya. Saat kami memindahkan database kami ke V12, kami kehilangan kemampuan untuk memantau dari perspektif OS, dan konsep lain juga sedikit berubah. Kami sekarang memiliki metrik yang disebut DTU untuk digunakan, yang merupakan singkatan dari Unit Transaksi Basis Data. Anggap saja sebagai kombinasi CPU, data dan log transaksi I/O, dan memori. Portal Azure menyertakan bagan pemantauan yang secara default memiliki persentase DTU yang diperiksa, dan Anda dapat mengedit bagan ini untuk menyertakan metrik tambahan, seperti:
- Diblokir oleh Firewall
- % CPU
- Batas DTU
- DTU digunakan
- Data I/O %
- Ukuran basis data %
- Kebuntuan
- Koneksi Gagal
- Penyimpanan OLTP dalam Memori %
(pratinjau)
- Masukkan I/O %
- Sesi %
- Koneksi Berhasil
- Total ukuran basis data
- Pekerja %
Minimal, saya akan menambahkan persentase CPU, persentase I/O data, kebuntuan, dan persentase ukuran basis data. Saat ini, bagan ini menampilkan jam penggunaan sumber daya sebelumnya.
Pemantauan oleh DMV tidak banyak berubah, selain memiliki beberapa DMV baru yang terkait untuk metrik basis data individual dan cara menghitung ukuran basis data. Salah satu artikel saya sebelumnya di sini, Memulai Menyetel Kinerja di Azure SQL Database, mencakup beberapa perbedaan dalam skrip umum yang digunakan untuk mengumpulkan latensi disk dan statistik tunggu terkait dengan Azure SQL Database.
Alat pihak ketiga juga telah mulai menyertakan pengait ke Azure SQL Database, seperti SentryOne dengan DB Sentry. DB Sentry memberi Anda kemampuan untuk memantau kinerja dan mengelola peristiwa yang terjadi di sistem Anda. Salah satu fitur keren adalah fungsi Top SQL yang memungkinkan Anda melihat kueri yang paling berdampak pada kinerja Anda secara keseluruhan sehingga Anda dapat menyetel/memperbaiki masalah apa pun dengan kueri itu. Lainnya adalah memetakan DTU dari waktu ke waktu dan memvisualisasikannya di dasbor bersama metrik penting lainnya.
 SQL teratas di klien SentryOne |  Penggunaan DTU di DB Sentry Dashboard |
Metrik ini disimpan dalam database khusus, yang memberi Anda kemampuan untuk membuat dasar dan tren dari waktu ke waktu, yang jauh lebih baik daripada bagan terbatas yang saat ini Anda dapatkan di Portal Azure.
Ringkasan
Ada banyak manfaat bermigrasi ke Azure SQL Database V12, jika database Anda kompatibel, jadi manfaatkan salah satu alat yang tersedia untuk memeriksa kompatibilitas Anda dengan V12. Jika database Anda kompatibel, atau dapat dengan mudah dimodifikasi agar kompatibel, maka Anda dapat dengan mudah bermigrasi ke Azure SQL Database V12 dan mulai menguji dan membandingkan aplikasi dan beban kerja Anda.
