Baru-baru ini, Microsoft mengeluarkan Paket Layanan 1 untuk SQL Server 2012, dan mereka segera menindaklanjuti dengan Pembaruan Kumulatif 1 untuk Paket Layanan 1. Alasannya adalah karena paket layanan – karena siklus pengembangan dan pengujian regresi yang lebih lama – tidak mengandung perbaikan dari Pembaruan Kumulatif RTM 3 &4. Karena banyak orang telah menunggu – berdasarkan sebagian besar bias spekulatif pada saat ini – bahkan untuk mulai menguji SQL Server 2012 hingga Service Pack 1 dirilis, saya pikir mungkin berguna untuk membahas beberapa skenario yang mungkin Anda temui. Ini bukan postingan yang sepenuhnya terkait dengan kinerja, tetapi beberapa informasi memang melibatkan gangguan layanan, yang mungkin atau mungkin tidak memengaruhi bisnis Anda, SLA, dll.
PERBARUI – SQL Server 2012 Service Pack 1 Cumulative Update 2 (11.0.3339) dirilis pada 24-01-2013.
Jika SQL Server 2012 belum diinstal…
Saat Anda menginstal contoh baru SQL Server, Anda ingin melakukan langkah sesedikit mungkin. Penyiapan SQL Server 2012 jauh lebih baik tentang slipstreaming paket layanan dan pembaruan kumulatif daripada SQL Server 2008/2008 R2 (dijelaskan oleh Peter Saddow di sini dan di sini). Metode ini tidak digunakan lagi, tetapi masih didukung di SQL Server 2012. Jadi sementara Anda masih dapat menggunakan metode lama jika Anda mau:
D:\setup.exe /Action=Install /PCUSource=C:\SP1ExtractedFolder /CUSource=C:\CU1ExtractedFolder
Metode baru, yang seharusnya Anda gunakan, jauh lebih sederhana – dan tidak mengharuskan Anda untuk mengekstrak paket secara manual menggunakan /x argumen dulu:
D:\setup.exe /Action=Install /UpdateSource=C:\AllUpdatesFolder
Anda hanya perlu meletakkan semua pembaruan yang relevan di folder yang sama. Perhatikan bahwa setiap pembaruan yang Anda dapatkan dengan nama file [...]_zip.exe , Anda perlu mengekstrak untuk mendapatkan inti yang dapat dieksekusi. Misalnya, ketika Anda pertama kali mengunduh Service Pack 1 dan Cumulative Update 1, folder unduhan akan terlihat seperti ini:
Anda perlu mengekstrak 455715_intl_x64_zip.exe dengan mengklik dua kali dan memilih jalur keluaran (menggunakan /x di baris perintah valid, tetapi diabaikan). Setelah selesai, folder tersebut akan terlihat seperti ini. (Pada saat itu, Anda dapat menghapus 455715... file – meskipun mengingat betapa "terkompresinya", saya harus bertanya-tanya mengapa mereka terus menempatkan paket ini di arsip yang mengekstraksi sendiri.)
Sekarang ketika Anda menjalankan baris perintah di atas, ketika Anda masuk ke layar Pembaruan Produk dalam pengaturan, Anda akan melihat bahwa itu telah menyertakan SP1 dan CU1:
Bob Ward melakukan pekerjaan yang sangat baik untuk menggambarkan skenario ini secara lebih rinci di sini:
Blog CSS :Pengaturan SQL Server 2012 menjadi lebih cerdas…
Perhatikan bahwa Anda dapat menyimpan semua Paket Layanan dan Pembaruan Kumulatif dari waktu ke waktu di folder yang sama – jika Anda menggunakan /UpdateSource argumen, SQL Server Setup akan cukup pintar untuk memilih SP terbaru dan CU terbaru, terlepas dari apa lagi yang mungkin ada di folder itu.
Jika SQL Server 2012 sudah terinstal…
Sekali lagi, semua informasi itu berlaku jika Anda menginstal contoh baru SQL Server. Saya, di sisi lain, memiliki banyak contoh SQL Server 2012 RTM yang ingin saya tambal – dan karena saya tidak ingin kehilangan perbaikan apa pun dari Pembaruan Kumulatif 3 &4, saya ingin menerapkan kedua Paket Layanan 1 dan Pembaruan Kumulatif 1. Saya berharap bahwa kecerdasan slipstream yang sama akan dibangun ke dalam pengaturan Paket Layanan 1 yang dapat dieksekusi, sehingga dapat dengan mudah menyertakan pembaruan CU1. Saya mencoba logikanya:
C:\AllUpdatesFolder\SQLServer2012-SP1-KB2674319-x64-ENU.exe /UpdateSource=C:\AllUpdatesFolder
Tapi ini akhirnya menghasilkan kesalahan berikut:
Untuk kebaikan mesin pencari:
The setting 'UpdateSource' is not allowed when the value of setting 'ACTION' is 'Patch'. Error code 0x84B40005.
(Dan ya, saya mencoba meletakkan folder pembaruan CU1 yang diekstrak di lokasi lain.)
Saya telah mengkonfirmasi dengan Microsoft bahwa, sementara SP1 jelas berisi beberapa kode dan logika dari setup.exe inti, itu belum dibangun untuk memungkinkan penggabungan Pembaruan Kumulatif. Dengan kata lain, Anda tidak dapat melakukan slipstream saat menginstal paket layanan, hanya saat menginstal produk inti.
Ini juga berarti bahwa Anda harus melakukan penginstalan dalam dua langkah . Saya membuka saran Connect baru, karena slipstreaming bisa dibilang *lebih* berharga selama servis daripada selama instalasi awal:
Hubungkan #774109 :Izinkan /UpdateSource untuk pemasang Paket Layanan
Jadi, saya melanjutkan untuk melakukan ini dalam dua langkah. Saya menginstal Paket Layanan 1, dan mencatat bahwa tidak ada file yang digunakan yang mungkin memerlukan boot ulang:
Dan kemudian setelah SP1 selesai, saya meluncurkan penginstal SP1 CU1. Namun saya menemukan kesalahan ini:
Jadi saya tidak hanya harus mengambil dua langkah untuk menerapkan tambalan ini, saya juga harus reboot di antaranya. Saya mencari di file log untuk setiap pemasangan (Detail.txt ) dan saya dapat melihat bahwa ketika saya menjalankan SP1, tidak ada indikasi bahwa Windows mengharapkan reboot:
(07) 2012-12-12 06:46:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=True
Tapi kemudian ketika saya menjalankan CU1 dan mendapatkan kesalahan, hanya beberapa menit setelah SP1 selesai, saya melihat di Detail.txt baru bahwa sekarang Windows *sedang* mengharapkan reboot:
(07) 2012-12-12 06:53:38 Slp: Windows Update requires a reboot (07) 2012-12-12 06:53:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=False
Saya tidak yakin apa yang terjadi, karena saya pasti tidak pergi dan menjalankan Pembaruan Windows di antara langkah-langkah.
PEMBARUAN:Terima kasih kepada Shau Phang di Microsoft, kami menemukan di %SystemRoot%\WindowsUpdate.log bahwa Pembaruan Windows otomatis telah dimulai setelah SP1 dimulai, dan selesai sebelum saya memulai pembaruan CU. Saya kira ini karena saya membangunkan komputer dan segera memulai instalasi paket layanan; pemeriksaan "harus reboot" harus dipicu di antaranya. Saya akan menerima tanggung jawab penuh untuk ini jika saya baru saja mengaktifkan Pembaruan Windows dan menerima default; Tapi aku tidak. Ini pengaturan saya:
Jadi, berhati-hatilah di luar sana.
Kesimpulan
Moral dari cerita ini adalah, jika Anda belum menginstal SQL Server 2012, slipstreaming untuk mendapatkan pembaruan terbaru dalam satu tindakan – terlepas dari kapan Anda melakukannya, dan pembaruan apa yang tersedia saat itu – akan sederhana dan tidak menyakitkan.
Jika Anda sudah menginstal instans, dalam hal ini gangguan layanan dan waktu henti hampir selalu menjadi masalah yang lebih kritis daripada saat penginstalan baru, Anda perlu mendekati metodologi penambalan Anda dengan hati-hati, dan pastikan bahwa periode pemeliharaan Anda akan memungkinkan untuk me-restart server, jika diperlukan. Ini juga berarti:waspadai pengaturan Pembaruan Windows Anda dan apakah ada pembaruan yang telah diinstal sejak pengaktifan ulang terakhir.
Jika menurut Anda ini adalah masalah penting, beri suara pada item Connect ini dan, yang lebih penting, beri komentar tentang bagaimana skenario saat ini dapat memengaruhi bisnis Anda.
