Risiko yang terlibat dalam peningkatan ke SQL Server 2008 R2

Kami memiliki cukup banyak SQL Server yang perlu ditingkatkan dari versi 2005 ke 2008 R2. Pekerjaan direncanakan sebelum pertengahan tahun karena Microsoft mengakhiri dukungannya untuk hal yang sama.

SQL Server 2005 semuanya SP3 dan SP4, berjalan pada Windows Server 2003 (yang dukungannya telah berakhir, tetapi kami memiliki pengecualian ekstensi untuk satu tahun lagi), tetapi jika diperlukan kami juga dapat melakukan peningkatan OS server.

Server-server ini termasuk replikasi (transaksional), pengiriman log, layanan pelaporan, dan server integrasi yang menjalankan paket SSIS.

Pertanyaan saya di sini bukan bagaimana, saya ingin tahu risiko yang terlibat atau pra-cek yang dapat dilakukan sebelum merencanakan peningkatan ini?

Juga, akankah pembaruan di tempat menjadi rencana yang lebih baik daripada berdampingan untuk migrasi / peningkatan ini?

Itu pertanyaan yang sangat besar, jadi mari kita hentikan sedikit.

Apa yang bisa saya lakukan sebelumnya?

Mulailah dengan beberapa bacaan wajib .

• Kompatibilitas Mundur 2008 R2
• Kompatibilitas Mundur 2008

Tautan ini memiliki tautan ke informasi lebih lanjut seperti

• Fitur SQL Server yang sudah tidak digunakan lagi
• Fitur SQL Server Dihentikan
• Mematahkan Perubahan
• Perubahan Perilaku ke Fitur SQL Server

Baca masing-masing untuk melihat hal-hal utama apa yang berubah. Berikan perhatian khusus pada fitur yang Anda gunakan.

Selain itu, Anda harus menggunakan Penasihat Peningkatan . Ia memeriksa komponen yang diinstal dan mengidentifikasi komponen yang perlu Anda perbaiki sebelum atau setelah instalasi.

Banyak pro dan kontra ada di sini di kedua sisi.

Di tempat

Pro

• Jauh lebih mudah. Semua konfigurasi Anda tetap sama misalnya. Juga string koneksi untuk aplikasi Anda mungkin tidak perlu diubah.
• Lebih murah Tidak diperlukan perangkat keras kedua.

Cons

• Mundur sulit untuk mustahil. Jika terjadi kesalahan, Anda harus menjalankan dan menyelesaikannya karena backout melibatkan pembuatan server baru dan menginstal ulang SQL kemudian memulihkan cadangan tabel Anda.

Bersebelahan

Pada dasarnya pro & kontra adalah kebalikan dari Di tempat.

Pro

• Aman - Jika terjadi kesalahan Anda mematikan versi baru dan melanjutkan dengan yang lama. Maka Anda bisa mencoba lagi nanti.

Cons

• Ini lebih mahal karena Anda harus membuat satu set instance baru mungkin pada server baru.
• Ini lebih sulit karena Anda harus mengubah string koneksi, pastikan semua konfigurasi Anda sama, dll.

Sekarang Anda dapat mengurangi biaya dari sisi-by-side dengan membuat contoh baru di server yang sama, memindahkan semuanya ke sana, lalu menghapus instalan contoh lama. Ini bekerja dan tergantung pada situasi Anda mungkin merupakan ide terbaik.

Jujur pindah dari 2005 - 2008 R2 tidak terlalu buruk. Tidak ada apa-apanya dibandingkan dengan 2000 - 2005 atau 2008 R2 - 2012 (kebanyakan perubahan SSIS). Saya akan mengatakan dengan perencanaan dan membaca yang cermat Anda harus dalam kondisi yang baik.

Jadi pertanyaan saya di sini bukan bagaimana, lebih suka mengetahui risiko yang terlibat atau pra-cek yang dapat dilakukan sebelum merencanakan peningkatan ini?

Anda harus menjalankan penasihat pemutakhiran dan mengatasi masalah yang dilaporkan sebelum bermigrasi.

Lihat jawaban saya untuk daftar lengkap langkah peningkatan pra dan pasca .

SQL server yang perlu ditingkatkan dari versi 2005 ke 2008R2

Anda memilih jalur di mana Anda akan kembali ke titik 1 (karena dalam 3 tahun, Anda harus meningkatkan lagi). Lihat tabel di bawah ini

akankah upgrade Inplace menjadi rencana yang lebih baik atau berdampingan untuk migrasi / peningkatan ini?

Berdasarkan pengalaman saya, saya akan menyarankan Anda untuk melakukan migrasi berdampingan karena Anda mendapatkan versi OS dan SQL baru. Ini adalah pendekatan yang jauh lebih bersih karena Anda akan memiliki server lama Anda masih ada, kalau-kalau Anda ingin gagal. Lihat: Apakah pemutakhiran di tempat SQL Server tidak disarankan seperti dulu? . Jangan salah paham ketika saya menyarankan migrasi berdampingan, itu hanya sisi yang lebih aman ketika datang ke rollback.

IMO jika Anda akan berupaya untuk bermigrasi maka Anda harus pergi ke 2014 bahkan jika Anda menjalankannya dalam mode kompatibilitas 10.0.

Anda akan tetap membayar lisensi. Juga upaya pengujian regresi dan kurva pembelajaran pengembang / DBA akan signifikan dalam kedua kasus tersebut. Jika Anda berhenti di 2008R2 sekarang Anda hanya perlu mengulangi latihan lagi dalam beberapa tahun. 2008R2 telah melihat Paket Layanan terakhir dan dalam beberapa bulan (minggu) akan ada 3 versi lengkap di belakang versi saat ini.

Saya merekomendasikan organisasi saya pindah dari 2008R2 langsung ke 2016 karena alasan yang sama. Saya berharap kami akan memulai upaya pengujian segera setelah tahun 2016 menyentuh RTM.

BTW, saya setuju bahwa upgrade Side-by-Side lebih disukai. Ketika saya terakhir melakukan latihan ini, kami menjalankan versi "Pra-Produksi" di lingkungan Dev selama sekitar satu bulan.