Ada beberapa kontroversi yang sedang berlangsung di komunitas SQL Server tentang kebijaksanaan menginstal Paket Layanan (SP) dan Pembaruan Kumulatif (CU) untuk SQL Server. Ada beberapa posisi dasar berbeda yang biasanya cenderung diambil oleh organisasi dalam hal ini, seperti yang tercantum di bawah ini:
- Organisasi menginstal Paket Layanan dan Pembaruan Kumulatif secara teratur
- Organisasi menginstal Paket Layanan, tetapi tidak menginstal Pembaruan Kumulatif
- Organisasi tidak menginstal Paket Layanan atau Pembaruan Kumulatif
Kasus pertama adalah organisasi yang akan mencoba untuk tetap cukup terkini dengan SQL Server Service Packs dan SQL Server Cumulative Updates menggunakan prosedur pengujian dan implementasi yang menyeluruh. Ini adalah kebijakan terbaik menurut saya. Posisi saya adalah bahwa organisasi Anda jauh lebih baik dilayani dengan tetap up-to-date dengan Paket Layanan dan Pembaruan Kumulatif (selama Anda memiliki prosedur pengujian dan implementasi serta infrastruktur yang diperlukan untuk mendukung kebijakan tersebut).
Kasus kedua adalah organisasi yang akan (mungkin setelah beberapa penundaan), menginstal Paket Layanan SQL Server, tetapi mereka tidak akan menginstal Pembaruan Kumulatif SQL Server karena alasan apa pun. Ini tidak sebagus kasus pertama, tetapi jauh lebih baik daripada kasus ketiga.
Dalam kasus ketiga, beberapa organisasi tidak pernah menginstal Paket Layanan SQL Server atau Pembaruan Kumulatif SQL Server, untuk alasan apa pun. Dalam beberapa kasus, mereka benar-benar tetap pada rilis asli untuk pembuatan (RTM) build dari versi utama SQL Server yang mereka jalankan, selama masa pakai instance. Ini adalah kebijakan yang paling tidak diinginkan, karena sejumlah alasan.
Microsoft memiliki kebijakan untuk menghentikan cabang kode (baik cabang RTM atau cabang Paket Layanan berikutnya) untuk versi SQL Server tertentu ketika sudah dua cabang. Misalnya, ketika SQL Server 2008 R2 Paket Layanan 2 dirilis, cabang RTM asli (terlepas dari tingkat CU) dihentikan, dan menjadi "paket layanan yang tidak didukung". Ini berarti bahwa tidak akan ada lagi perbaikan terbaru atau Pembaruan Kumulatif untuk cabang tersebut, dan Anda hanya akan mendapatkan dukungan pemecahan masalah terbatas dari Microsoft CSS selama kasus dukungan sampai Anda menginstal paket layanan yang didukung pada instans Anda.
Alasan mengapa pemeliharaan SQL Server ditangguhkan
Dalam beberapa kasus, organisasi mungkin tidak menyadari bagaimana SQL Server biasanya dilayani dengan kombinasi Paket Layanan, Pembaruan Kumulatif, dan Perbaikan Terbaru. Banyak organisasi memiliki kebijakan top-down yang kaku tentang bagaimana mereka memelihara dan melayani produk seperti SQL Server, yang menghalangi instalasi reguler SP dan/atau CU oleh administrator database. Mereka juga dapat dibatasi dari melayani contoh SQL Server mereka oleh fakta bahwa mereka menggunakan database pihak ke-3 yang hanya didukung vendor dengan versi tertentu vendor dan tingkat Paket Layanan SQL Server.
Banyak organisasi juga memiliki ketakutan yang dapat dimengerti untuk "melanggar" baik instance SQL Server atau aplikasi yang bergantung pada instance itu. Mereka juga mungkin kekurangan waktu dan sumber daya untuk melakukan tingkat aplikasi dan pengujian sistem yang sesuai setelah menginstal SQL Server yang diperbarui pada instans di lingkungan pengujian. Dalam beberapa kasus, mereka mungkin tidak memiliki lingkungan pengujian khusus (yang merupakan masalah utama yang terpisah).
Beberapa organisasi mungkin tidak memiliki solusi ketersediaan tinggi yang berfungsi (seperti pengelompokan fail-over tradisional, pencerminan basis data, atau grup ketersediaan) di lingkungan Produksi mereka, sehingga mereka jauh lebih ragu untuk melakukan jenis servis apa pun yang mungkin akan menyebabkan server database reboot, dan menyebabkan pemadaman yang relatif lama. Mereka mungkin sebenarnya memiliki solusi ketersediaan tinggi, tetapi mereka jarang mengujinya dengan kegagalan produksi, dan mereka mungkin kurang percaya diri pada fungsi dan keandalannya.
Alasan untuk memelihara SQL Server secara teratur
Setelah membuat daftar beberapa alasan umum mengapa organisasi mungkin memilih untuk tidak secara teratur melayani SQL Server, sekarang saatnya untuk membahas beberapa argumen ini. Pertama, ketidaktahuan tentang bagaimana SQL Server biasanya dilayani oleh Microsoft sebenarnya bukan alasan yang valid lagi. Microsoft memiliki Blog Layanan Rilis SQL, di mana mereka mengumumkan Paket Layanan dan Pembaruan Kumulatif untuk SQL Server. Matthias Bernt menjelaskan strategi servis umum untuk SQL Server dalam postingnya:Pendekatan yang diubah untuk Paket Layanan, dengan detail lebih lanjut tentang pendekatan model servis inkremental SQL Server yang tersedia di artikel basis pengetahuan Micosoft ini.
Versi ringkas dari model layanan adalah bahwa masalah SQL Server individu diperbaiki dengan perbaikan terbaru. Anda harus menghubungi Microsoft CSS dan membuka kasus dukungan untuk mendapatkan akses ke hotfix individual (kecuali hotfix terkait keamanan, yang didorong oleh Microsoft Update). Bergantung pada tingkat dukungan berbayar Anda dengan Microsoft, ini bisa menjadi proses yang relatif membosankan dan memakan waktu. Ada juga masalah bahwa sebagian besar pelanggan SQL Server sangat tidak mungkin menyadari perbaikan terbaru yang ada yang belum dirilis sebagai bagian dari Pembaruan Kumulatif SQL Server. Ini berarti bahwa sebagian besar pelanggan tidak mungkin mendapatkan dan menyebarkan hotfix individual secara teratur.
Pembaruan kumulatif adalah rollup dari sejumlah perbaikan terbaru (biasanya di mana saja dari sekitar 10-50 perbaikan terbaru) yang dirilis setiap delapan minggu. Pembaruan Kumulatif ini sebenarnya kumulatif (sesuai namanya), jadi Anda akan mendapatkan semua perbaikan terbaru yang dirilis sebelumnya untuk versi dan cabang kode Anda (RTM, SP1, SP2, dll.) saat Anda menginstal Pembaruan Kumulatif. Ini berarti bahwa pernyataan umum tentang organisasi “hanya menerapkan Pembaruan Kumulatif untuk memperbaiki masalah tertentu yang mereka alami” sebenarnya tidak terlalu valid dalam kehidupan nyata.
Misalnya, jika Anda menjalankan RTM build SQL Server 2012 Service Pack 1 (11.0.3000), dan Anda memutuskan untuk menginstal SQL Server 2012 Service Pack 1 Cumulative Update 3 (11.0.3349) karena menyertakan hotfix untuk satu masalah yang sebenarnya Anda alami, Anda akan benar-benar mendapatkan semua hotfix untuk SP1 CU1, SP1 CU2, dan SP1 CU3, yang akan berjumlah lebih dari 100 hotfix.
Seperti yang dinyatakan Microsoft tentang Pembaruan Kumulatif:“Karena build bersifat kumulatif, setiap rilis perbaikan baru berisi semua perbaikan terbaru dan semua perbaikan keamanan yang disertakan dengan rilis perbaikan SQL Server 2012 SP 1 sebelumnya. Kami menyarankan Anda mempertimbangkan untuk menerapkan rilis perbaikan terbaru yang berisi perbaikan terbaru ini.” Pada dasarnya ini berarti bahwa jika Anda menemukan masalah tertentu yang relevan yang telah diperbaiki di CU sebelumnya, Anda harus melanjutkan dan menerapkan CU terbaru yang relevan pada sistem (yang juga akan menyertakan perbaikan terbaru tersebut).
Satu argumen yang sering saya dengar tentang mengapa organisasi tidak menerapkan Pembaruan Kumulatif adalah, "mereka tidak sepenuhnya diuji regresi seperti Paket Layanan, jadi kami tidak menerapkannya." Ada beberapa validitas dalam sudut pandang ini, tetapi ada juga kesalahpahaman umum bahwa Pembaruan Kumulatif hanyalah pengujian unit, tanpa pengujian regresi apa pun. Ini tidak terjadi.
Dokumentasi Microsoft tentang Pembaruan Kumulatif menunjukkan bahwa karena mereka "menerapkan pengujian regresi inkremental sepanjang siklus pengembangan diikuti oleh 2 minggu pengujian terfokus dalam jendela rilis 8 minggu, proses jaminan kualitas yang terkait dengan CU melebihi perbaikan terbaru individu." Ini berarti bahwa Anda sebenarnya mengambil lebih sedikit risiko dengan menerapkan CU yang telah diuji regresi secara bertahap dan juga memiliki dua minggu pengujian terfokus daripada jika Anda menggunakan perbaikan terbaru tunggal yang hanya diuji unit.
Selama enam hingga tujuh tahun terakhir, saya secara pribadi telah menerapkan banyak, banyak Pembaruan Kumulatif dan Paket Layanan pada sejumlah besar sistem yang menjalankan SQL Server 2005 hingga SQL Server 2012, dan saya belum mengalami masalah besar. Saya juga belum pernah mendengar ada masalah yang tersebar luas dalam melakukan jenis pekerjaan ini yang dilaporkan di blog, di Twitter, dll. Bisa jadi saya (dan semua orang yang saya kenal) hanya beruntung, atau mungkin Pembaruan Kumulatif dan Paket Layanan tidak cukup berisiko seperti yang diyakini sebagian orang (selama Anda menguji dan menerapkannya dengan benar).
Pentingnya rencana pengujian dan implementasi
Kecuali jika Anda tidak pernah berencana untuk melakukan pemeliharaan server atau pembaruan aplikasi apa pun selama masa pakai sistem Anda (yang tampaknya merupakan proposisi yang tidak mungkin), Anda benar-benar perlu mengembangkan semacam prosedur dan rencana pengujian dan implementasi yang akan Anda ikuti sebagai bagian membuat perubahan apa pun pada server.
Rencana ini mungkin dimulai dengan relatif sederhana, tetapi akan menjadi lebih kompleks dan lengkap saat Anda menjadi lebih berpengalaman dengan servis instans SQL Server Anda secara teratur dan menerapkan pelajaran yang Anda pelajari dengan setiap penerapan. Idealnya, Anda akan mengikuti rencana ini kapan pun Anda membuat perubahan pada sistem, tetapi hal itu mungkin tidak dapat dilakukan dalam setiap kasus.
Berikut adalah beberapa langkah dan pengujian awal yang harus disertakan dalam rencana semacam ini.
- Instal CU pada mesin virtual pengujian
- Apakah CU menginstal tanpa masalah atau kesalahan?
- Apakah penginstalan CU memerlukan boot ulang sistem?
- Apakah semua layanan SQL Server yang relevan dimulai ulang setelah penginstalan?
- Apakah SQL Server tampak berfungsi dengan benar setelah penginstalan?
- Instal CU pada beberapa sistem pengembangan
- Apakah CU menginstal tanpa masalah atau kesalahan?
- Apakah SQL Server tampak berfungsi dengan benar selama penggunaan normal sehari-hari?
- Apakah aplikasi Anda tampak berfungsi dengan benar selama pengujian unit?
- Instal CU di QA bersama atau lingkungan integrasi
- Apakah Anda mengikuti rencana implementasi tertentu dan daftar periksa untuk penginstalan?
- Apakah semua aplikasi yang menggunakan SQL Server lulus pengujian asap?
- Apakah semua aplikasi lulus pengujian otomatis yang Anda miliki?
- Apakah semua aplikasi lulus pengujian fungsional manual yang lebih mendetail?
- Instal CU di lingkungan Produksi Anda
- Gunakan strategi peningkatan versi berkelanjutan jika memungkinkan
- Gunakan daftar periksa langkah demi langkah yang mendetail selama penerapan
- Perbarui daftar periksa Anda dengan item yang terlewat dan pelajaran yang didapat
Kesimpulan
Apa yang ingin saya capai di sini adalah untuk mendapatkan lebih banyak profesional database untuk mulai bergerak menuju pola pikir di mana mereka benar-benar ingin secara teratur memelihara contoh SQL Server mereka, daripada ragu-ragu atau takut untuk melakukannya. Ini dapat melibatkan banyak pekerjaan ekstra di awal, karena Anda mungkin harus meyakinkan orang lain di organisasi Anda untuk bergabung dengan rencana Anda. Anda mungkin harus mendorong bagian lain dari organisasi untuk mengembangkan rencana pengujian yang lebih baik, dan Anda harus membuat daftar periksa implementasi. Anda juga harus mendapatkan otorisasi dari bisnis untuk periode pemeliharaan (yang seharusnya relatif singkat dengan peningkatan berkelanjutan), sehingga Anda benar-benar bisa mendapatkan pembaruan yang diterapkan pada sistem Produksi Anda secara teratur.
Sebagai imbalan atas kerja ekstra ini, Anda akan memiliki sistem terpelihara lebih baik yang kemungkinan kecil mengalami masalah di masa mendatang. Anda akan berada dalam konfigurasi yang didukung penuh dari Microsoft, dan Anda akan lebih percaya diri pada teknologi ketersediaan tinggi Anda, karena Anda akan benar-benar melatihnya secara teratur. Anda juga akan mendapatkan pengalaman berharga saat melakukan perencanaan dan penerapan semua ini yang akan meningkatkan keterampilan pemecahan masalah Anda di masa mendatang.
