Pembaruan Kumulatif MS SQL Server - Praktik Terbaik

Saya mencoba untuk mendapatkan gambaran tentang apa yang direkomendasikan praktik terbaik untuk Pembaruan Kumulatif SQL Server .

Saat ini, kami menjalankan gagasan "jangan melakukan apa pun kecuali masalah yang diperbaiki oleh CU adalah yang kami alami". Itu bekerja dari pendekatan "jika tidak rusak, jangan perbaiki", tetapi saya bertanya-tanya apakah itu benar-benar ide yang baik karena begitu banyak CU yang memiliki peningkatan kinerja. Kami sedang mencari kemungkinan menambahkan CU ke tambalan yang diterapkan selama siklus pemeliharaan berkala kami satu atau dua bulan setelah CU dirilis.

Apa yang dilakukan orang lain, dan mengapa?

Sebagai pembaruan untuk pertanyaan yang mempengaruhi jawaban di bawah ini, pada 24 Maret 2016, tim Microsoft SQL Server mengumumkan bahwa mereka memperbarui model layanan mereka . Microsoft merekomendasikan agar semua pengguna menginstal semua CU yang dirilis setelah Januari 2016:

Pada rilis Januari CU, pesan peringatan ini telah diperbarui, kami sekarang merekomendasikan instalasi CU yang proaktif dan berkelanjutan saat tersedia. Anda harus merencanakan untuk menginstal CU dengan tingkat kepercayaan yang sama dengan yang Anda rencanakan untuk menginstal SP (Paket Layanan) ketika mereka dirilis. Ini karena CU disertifikasi dan diuji ke tingkat SP. Selain itu, data Microsoft CSS menunjukkan bahwa persentase signifikan dari masalah pelanggan sering ditangani sebelumnya dalam CU yang dirilis, tetapi tidak diterapkan secara proaktif. Lebih dari itu, CU mengandung nilai tambah di atas dan di atas perbaikan terbaru. Ini juga mungkin berisi dukungan, pencatatan, dan pembaruan keandalan yang meningkatkan pengalaman keseluruhan.

Selain pembaruan perpesanan dan panduan, kami telah memperbarui model akuisisi CU.

Perubahan akuisisi:

• CU, tentu saja, secara tradisional telah tersedia di server "Hotfix" (disertai dengan "bahasa peringatan" yang terkait dengan 'QFE' atau 'Hotfix'). Ketidakkonsistenan di sini adalah bahwa CU bukan hotfix cepat benar-benar sederhana lagi. Pembaruan yang dicakup diuji dengan baik pada tingkat integrasi sistem individu maupun penuh hari ini.
• Oleh karena itu, kami sekarang menempatkan baseline CU terbaru per mainstream yang didukung (2012 SP2 / SP3 dan 2014 RTM / SP1 hari ini) di microsoft.com/downloads, seperti yang dilakukan untuk Paket Layanan hari ini
• Selain itu, kami akan segera merilis, dan memelihara, semua CU ke dalam Katalog Pembaruan Windows untuk memfasilitasi akuisisi dan distribusi
• Hanya perbaikan sementara 'On-Demand' CU yang akan ditempatkan pada server perbaikan terbaru yang bergerak maju
• Untuk mengurangi gesekan, mengunduh CU dari microsoft.com/downloads tidak akan memerlukan penyediaan / penerimaan email dan URL
• Kami juga mengevaluasi penawaran CU terbaru sebagai pembaruan opsional pada Pembaruan Microsoft, seperti Paket Layanan hari ini

Saya adalah penganjur besar untuk mengikuti perkembangan dengan pemutakhiran kumulatif terbaru, tetapi hanya jika siklus pengujian / QA Anda dapat memastikan pengujian regresi penuh dan tepat terhadapnya. Glenn Berry dari SQLskills juga merupakan pendukung pendekatan ini .

Rekomendasi Microsoft sendiri adalah untuk hanya menerapkan CU yang memperbaiki masalah yang memengaruhi Anda, meskipun mereka telah melonggarkan sikap itu baru-baru ini . Masalahnya adalah bahwa Anda mungkin terpengaruh oleh satu atau lebih masalah itu dan tidak mengetahuinya, atau Anda mungkin akan terpengaruh besok meskipun itu belum mengenai Anda. Apakah Anda akan melalui dan mencoba mereproduksi masalah di balik setiap perbaikan tunggal di setiap CU tunggal untuk cabang Anda? Apakah Anda akan melakukan ini terus menerus untuk memastikan Anda masih tidak terpengaruh?

Saya akan cukup jujur: Saya tidak pernah memiliki masalah dalam menerapkan CU pada instance saya. Dan sebenarnya proses rilis CU mereka jauh lebih dapat diandalkan daripada siklus rilis paket layanan, dan dalam banyak kasus (termasuk yang terbaru dengan SQL Server 2012 Paket Layanan 2 ), Anda tidak ingin menerapkan paket layanan hingga yang pertama CU untuk cabang itu sudah dirilis. Dalam kasus ini ada perbaikan terbaru sementara untuk menyelesaikan masalah yang tidak diperbaiki pada waktunya untuk membuat kode Paket Layanan, tetapi itu tidak selalu benar.

Kami terbiasa dengan CU. Sekitar 1 bulan setelah rilis, kami akan menerapkannya, apakah kami mengalami masalah yang diperbaiki atau tidak.

Namun, setelah kami mengalami masalah besar, kami menghentikan latihan ini. Dalam kasus kami paket layanan yang telah kami instal memperbaiki masalah dengan pengindeksan teks lengkap yang kami alami. Beberapa bulan kemudian, salah satu CU memutar kembali perbaikan khusus itu. Ini menyebabkan segala macam masalah bagi kami yang memerlukan sedikit riset untuk mencari tahu apa yang terjadi. Kami akhirnya mengkodekan pekerjaan yang kemudian dikacaukan ketika CU baru memecahkan sesuatu yang lain ... Hasil bersih: server diinstal ulang dari tanah ke tingkat SP / CU tertentu dan dibekukan.

Kinerja aplikasi kami sedemikian rupa sehingga kami tidak peduli dengan peningkatan kinerja SQL baru yang mungkin keluar, jadi itu bukan masalah. Selain itu, pelaporan dan kueri lainnya secara konsisten menarik kembali hasil yang valid sehingga setiap tweak baru tidak diperlukan. Yang berarti bahwa itu harus menjadi masalah keamanan sebelum kita mempertimbangkan untuk menerapkan CU saat ini.

Saya sepenuhnya setuju dengan Aaron: hanya lakukan ini jika siklus pengujian / QA Anda dapat mengujinya dengan benar. Kalau tidak, saya akan mengatakan lebih baik kecuali jika itu memperbaiki masalah yang sebenarnya Anda hadapi. Dan bahkan kemudian, uji setiap sisi kecil itu dengan data nyata untuk memastikan mereka tidak merusak sesuatu yang Anda mungkin bergantung pada.