Ketika versi SQL Server ini dirilis, mereka datang dengan dukungan 10 tahun; 5 tahun Dukungan Arus Utama dan 5 tahun Dukungan Perpanjangan. Jika organisasi Anda masih memiliki SQL Server 2008/2008 R2 dalam produksi, bagaimana organisasi Anda berencana untuk mengatasi risiko tersebut? Untuk organisasi yang sangat diatur, ini adalah masalah besar.

Anda harus memilih bagaimana Anda akan bermigrasi dan ke mana Anda akan bermigrasi, lalu pastikan Anda tidak akan menemui hambatan apa pun di sepanjang jalan.

Alat Penilaian Migrasi

Jika Anda merencanakan peningkatan dari SQL Server 2008/2008 R2, Microsoft telah membuat segalanya lebih mudah untuk menguji dan memvalidasi lingkungan Anda. Ada banyak alat yang dapat membantu penilaian migrasi dan bahkan menangani tugas migrasi, dan semuanya sedikit berbeda. Alat-alat ini meliputi:

• Asisten Migrasi Data
• Perangkat Penilaian dan Perencanaan Microsoft
• Layanan Migrasi Database Azure
• Asisten Eksperimen Basis Data

Asisten Migrasi Data membantu Anda meningkatkan ke platform data modern. Ini dilakukan dengan mendeteksi masalah kompatibilitas yang dapat memengaruhi fungsionalitas pada versi SQL Server yang lebih baru dan membuat rekomendasi untuk peningkatan kinerja dan keandalan untuk lingkungan baru. Sumber Anda dapat berupa SQL Server 2005+ dengan target SQL 2012+ dan Azure SQL Database.

Perangkat Penilaian dan Perencanaan Microsoft telah ada selama bertahun-tahun dan sering disebut sebagai Alat MAP. Sangat bagus untuk melakukan inventarisasi lingkungan Anda saat ini untuk menemukan di mana SQL Server (dan aplikasi lain) ada.

Layanan Migrasi Database Azure mengintegrasikan beberapa fungsi alat dan layanan yang ada untuk menyediakan solusi komprehensif bagi pelanggan untuk bermigrasi ke Azure. Alat ini menghasilkan laporan penilaian yang memberikan rekomendasi untuk memandu Anda melalui perubahan apa pun yang diperlukan sebelum melakukan migrasi. Layanan ini saat ini membutuhkan VPN atau Rute Ekspres.

Terakhir, Asisten Eksperimen Basis Data adalah solusi pengujian A/B baru untuk Peningkatan SQL Server dan merupakan alat yang harus Anda ketahui. Ini memanfaatkan Replay Terdistribusi untuk menangkap beban kerja dan memutar ulang terhadap target SQL Server. Ini dapat digunakan untuk menguji perubahan perangkat keras atau perbedaan versi SQL Server. Anda dapat menangkap beban kerja dari SQL Server 2005 dan yang lebih baru.

Opsi Migrasi

Peningkatan versi lokal: Salah satu metode migrasi termudah adalah memutakhirkan ke versi SQL Server yang lebih baru. Dalam hal ini, Anda memiliki SQL Server 2012, 2014, 2016, atau 2017 untuk dipilih. Saya mendorong klien untuk meningkatkan ke versi terbaru yang mereka bisa. SQL Server 2012 sudah keluar dari Mainstream Support dan SQL Server 2014 keluar dari Mainstream Support pada 9 Juli 2019. Upgrade bisa sangat memakan waktu dan mahal untuk organisasi karena semua perencanaan dan pengujian yang terlibat, jadi pindah ke versi terbaru bisa meningkatkan waktu sebelum upgrade berikutnya. Ada juga banyak peningkatan kinerja dan fungsionalitas di SQL Server 2016 dan 2017 yang membuat migrasi ke SQL Server 2012 atau 2014 menjadi pilihan yang sangat buruk saat ini.

Pendekatan umum untuk pemutakhiran lokal adalah membangun yang baru dan bermigrasi, terlepas dari lingkungan fisik atau virtual. Dengan membuat yang baru, Anda dapat memulihkan database dan melakukan banyak putaran pengujian dan validasi untuk memastikan semuanya berfungsi seperti yang diharapkan sebelum memindahkan produksi.

Tingkatkan dan migrasikan ke Azure VM: Untuk organisasi yang ingin bermigrasi ke cloud, Azure Infrastructure as a Service (IaaS) adalah pilihan yang bagus. Menjalankan SQL Server pada Azure VM sangat mirip dengan lokal. Anda menentukan ukuran VM (jumlah vCPU dan memori) dan mengonfigurasi penyimpanan Anda untuk I/O dan persyaratan ukuran. Anda tetap bertanggung jawab untuk mendukung OS dan SQL Server untuk konfigurasi dan patching. Azure IaaS memberi Anda kemampuan untuk menskalakan beban kerja dengan mudah dengan menaikkan atau menurunkan ukuran mesin virtual sesuai kebutuhan beban kerja Anda, serta memanfaatkan integrasi Azure Active Directory, deteksi ancaman, dan banyak manfaat Azure lainnya.

Bermigrasi ke Database Azure SQL: Opsi lain yang Anda miliki adalah bermigrasi ke Azure SQL Database. Azure SQL Database dapat dianggap sebagai Database as a Service dan merupakan bagian dari Platform as a Service (PaaS) Microsoft. Fungsionalitas Azure SQL Database adalah cakupan basis data, yang berarti hal-hal tertentu seperti kueri lintas basis data, Agen SQL Server, Surat Basis Data, dan lainnya tidak tersedia. Namun, banyak pelanggan yang memiliki aplikasi yang menggunakan satu database dapat bermigrasi ke Azure SQL Database dengan sedikit usaha. Anda dapat dengan cepat menguji kompatibilitas dengan Azure SQL Database menggunakan Asisten Migrasi Data. Dengan Azure SQL Database, Anda dapat mengukur database menurut DTU (Database Transaction Units) atau vCores satu per satu, atau mengelompokkan database ke dalam Elastic Pool. Azure SQL Database memungkinkan Anda meningkatkan dan menurunkan sumber daya dengan sedikit usaha dan waktu henti.

Bermigrasi ke Instans Terkelola Azure SQL: Opsi baru (mulai 2018) adalah bermigrasi ke Azure SQL Managed Instance. Ini adalah produk baru yang saat ini tersedia secara umum pada 1 Oktober untuk tingkat Tujuan Umum. Instans Terkelola dibuat menggunakan model pemrograman tingkat instans. Ini berarti bahwa fungsionalitas yang biasa kami gunakan dengan versi lengkap SQL Server didukung. Sasaran Instans Terkelola adalah memiliki kompatibilitas luas permukaan 100% dengan lokal. Semua database dalam instans berada di server yang sama, sehingga kueri lintas database didukung, seperti Database Mail, SQL Server Agent, Service Broker, dan banyak lagi. Ada dua tingkatan harga; Tujuan Umum, yang mencakup sekunder yang tidak dapat dibaca untuk HA, dan Kritis Bisnis, yang memiliki dua sekunder yang tidak dapat dibaca dan sekunder yang dapat dibaca. Instans Terkelola adalah bagian dari penawaran PaaS Microsoft, sehingga Anda mendapatkan semua fitur dan fungsionalitas bawaan PaaS.

Pindah apa adanya ke Mesin Virtual Azure: Microsoft menawarkan tiga tahun Pembaruan Keamanan yang Diperpanjang tanpa biaya tambahan jika Anda memindahkan instans SQL 2008/SQL 2008 R2 ke Azure VM. Tujuannya adalah memberi Anda sedikit lebih banyak waktu untuk memutakhirkan ke versi SQL Server yang lebih baru saat Anda siap.

Bayar Menginap: Ini bukan opsi migrasi, tetapi Anda memiliki opsi untuk membeli Pembaruan Keamanan yang Diperpanjang hingga tiga tahun. Ada batasan di sekitar opsi ini. Anda harus memiliki Jaminan Perangkat Lunak aktif untuk instans tersebut atau lisensi Berlangganan berdasarkan Perjanjian Perusahaan. Jika ini berlaku untuk Anda, maka opsi ini dapat memberi Anda lebih banyak waktu untuk merencanakan dan bermigrasi dari SQL Server 2008/2008 R2.

Praktik Terbaik Migrasi

Saat melakukan migrasi atau peningkatan, ada beberapa hal yang perlu Anda perhatikan. Pertama, Anda membutuhkan garis dasar dan saya tidak bisa cukup menekankan ini. Setiap kali Anda membuat perubahan pada suatu lingkungan, Anda harus dapat mengukur bagaimana perubahan itu berdampak pada lingkungan. Mengetahui metrik kinerja utama untuk lingkungan Anda dapat membantu Anda saat memecahkan masalah dampak yang dirasakan. Anda dapat mengumpulkan metrik ini secara manual menggunakan perfmon dan DMV atau berinvestasi dalam platform pemantauan kinerja. Saya menulis tentang kedua teknik secara lebih rinci di posting sebelumnya, dan sekarang Anda bisa mendapatkan evaluasi SentryOne selama 45 hari . Memiliki metrik dasar untuk hal-hal seperti penggunaan CPU, konsumsi memori, metrik disk, dan lainnya dapat dengan cepat memberi tahu Anda jika keadaan terlihat lebih baik atau lebih buruk setelah peningkatan atau migrasi.

Anda juga harus mencatat opsi konfigurasi dalam instans Anda. Sering kali, saya diminta untuk melihat contoh SQL Server setelah peningkatan atau migrasi dan menemukan bahwa sebagian besar pengaturan default sedang digunakan. Jika sistem lama masih tersedia, saya dapat menanyakannya dan mendapatkan nilai non-default sebelumnya yang ada dan menerapkannya ke lingkungan baru untuk mengembalikannya ke konfigurasi yang diketahui. Itu selalu baik untuk meninjau sys.configurations di server produksi Anda untuk mempertimbangkan membuat perubahan serupa di lingkungan baru Anda (ambang biaya untuk paralelisme, tingkat paralelisme maksimum, optimalkan untuk beban kerja ad hoc, dan banyak lagi.) Perhatikan saya menulis 'mempertimbangkan'. Jika jumlah inti atau memori Anda berbeda di server baru, Anda perlu mengonfigurasi pengaturan dengan mempertimbangkan ukuran server baru.

Apa rencana mundur Anda jika terjadi kesalahan? Apakah Anda memiliki cadangan yang tepat yang dapat Anda gunakan kembali? Dalam kebanyakan kasus dengan peningkatan atau migrasi, Anda pindah ke VM atau server fisik baru. Kegagalan Anda mungkin untuk kembali ke server lama. Jika Anda memiliki perubahan data di versi baru SQL Server, failback Anda jauh lebih rumit. Anda tidak dapat memulihkan cadangan database SQL Server dari versi SQL Server yang lebih baru ke versi yang lebih lama.

Kesimpulan

Jika Anda masih menggunakan SQL Server 2008 atau SQL Server 2008 R2, Anda memiliki beberapa opsi yang tersedia agar Anda tetap mematuhinya setelah 9 Juli 2019. Untuk tetap menggunakan SQL Server 2008 atau SQL Server 2008 R2, Anda dapat membeli Extended Security Updates atau pindah ke mesin virtual Azure jika Anda memenuhi syarat. Jika Anda dapat memutakhirkan, Anda dapat bermigrasi ke versi SQL Server lokal yang didukung atau di Azure VM atau pertimbangkan untuk bermigrasi ke solusi terkelola seperti Azure SQL Database atau Azure SQL Managed Instance.