Cập nhật tích lũy máy chủ MS SQL - Thực tiễn tốt nhất

Tôi đang cố gắng có được ý tưởng về những thực tiễn tốt nhất được đề xuất cho các Cập nhật tích lũy SQL Server .

Hiện tại, chúng tôi chạy theo ý tưởng "không làm gì trừ khi vấn đề được sửa bởi CU là vấn đề chúng tôi gặp phải". Nó hoạt động theo cách tiếp cận "nếu nó không bị hỏng, đừng sửa nó", nhưng tôi tự hỏi liệu đó có thực sự là một ý tưởng hay không vì rất nhiều CU có cải tiến hiệu suất. Có lẽ chúng tôi đang xem xét việc thêm CU vào các bản vá được áp dụng trong các chu kỳ bảo trì định kỳ của chúng tôi một hoặc hai tháng sau khi CU được phát hành.

Những người khác làm gì, và tại sao?

Là một bản cập nhật cho câu hỏi ảnh hưởng đến các câu trả lời bên dưới, vào ngày 24 tháng 3 năm 2016, nhóm SQL Server của Microsoft tuyên bố họ đang cập nhật mô hình phục vụ của họ . Microsoft đang khuyến nghị tất cả người dùng cài đặt tất cả các CU được phát hành sau tháng 1 năm 2016:

Kể từ bản phát hành CU tháng 1, những thông báo thận trọng này đã được cập nhật, chúng tôi hiện khuyên bạn nên cài đặt CU, liên tục, chủ động khi chúng có sẵn. Bạn nên có kế hoạch cài đặt CU với cùng mức độ tin cậy mà bạn dự định cài đặt SP (Gói dịch vụ) khi chúng được phát hành. Điều này là do CU's được chứng nhận và thử nghiệm ở cấp độ SP. Ngoài ra, dữ liệu Microsoft CSS chỉ ra rằng một tỷ lệ đáng kể các vấn đề của khách hàng thường được giải quyết trước đây trong CU được phát hành, nhưng không được áp dụng một cách chủ động. Hơn nữa, CU chứa giá trị gia tăng trên và trên hotfix. Chúng cũng có thể chứa các khả năng hỗ trợ, ghi nhật ký và cập nhật độ tin cậy nâng cao trải nghiệm tổng thể.

Ngoài cập nhật tin nhắn và hướng dẫn, chúng tôi đã thực hiện cập nhật cho mô hình mua lại CU.

Thay đổi mua lại:

• Tất nhiên, các CU, theo truyền thống đã được cung cấp trên máy chủ của Hot Hot Cảnh (kèm theo ngôn ngữ cảnh báo của Cameron được liên kết với 'QFE' hoặc 'Hotfix'). Sự không nhất quán ở đây là CUs không thực sự là các hotfix nhanh đơn giản nữa. Các bản cập nhật bao gồm được thử nghiệm tốt ở các cấp độ tích hợp hệ thống cá nhân cũng như đầy đủ hiện nay.
• Do đó, chúng tôi hiện đang đặt CU mới nhất trên đường cơ sở được hỗ trợ chính (2012 SP2 / SP3 và 2014 RTM / SP1 ngày hôm nay) trên microsoft.com/doads, giống như được thực hiện cho Gói dịch vụ ngày hôm nay
• Ngoài ra, chúng tôi sẽ sớm phát hành và duy trì tất cả các CU vào Danh mục Windows Update để tạo điều kiện mua lại và phân phối
• Chỉ các bản sửa lỗi CU 'Theo yêu cầu' tạm thời mới được đặt trên máy chủ hotfix di chuyển về phía trước
• Để giảm ma sát, tải xuống CU từ microsoft.com/doads sẽ không yêu cầu cung cấp / nhận email và URL
• Chúng tôi cũng đang đánh giá việc cung cấp CU mới nhất dưới dạng bản cập nhật Tùy chọn trên Microsoft Update, giống như Gói dịch vụ ngày nay

Tôi là một người ủng hộ lớn để cập nhật cập nhật tích lũy gần đây nhất, nhưng chỉ khi chu kỳ kiểm tra / QA của bạn có thể đảm bảo kiểm tra hồi quy đầy đủ và đúng đắn đối với nó. Glenn Berry của SQLskills cũng là người đề xuất phương pháp này .

Khuyến nghị riêng của Microsoft là chỉ áp dụng các CU khắc phục các sự cố ảnh hưởng đến bạn, mặc dù gần đây họ đã nới lỏng lập trường đó . Vấn đề là bạn có thể bị ảnh hưởng bởi một hoặc nhiều trong số những vấn đề đó và không biết về nó, hoặc bạn có thể bị ảnh hưởng vào ngày mai ngay cả khi nó chưa đánh bạn. Bạn sẽ trải qua và cố gắng tái tạo vấn đề đằng sau mỗi sửa chữa trong mỗi CU duy nhất cho chi nhánh của bạn? Bạn sẽ làm điều này liên tục để đảm bảo bạn vẫn không bị ảnh hưởng?

Tôi sẽ khá thành thật: Tôi chưa bao giờ gặp vấn đề khi áp dụng bất kỳ CU nào cho các trường hợp của tôi. Và trên thực tế, quy trình phát hành CU của họ đáng tin cậy hơn nhiều so với chu kỳ phát hành gói dịch vụ và trong nhiều trường hợp (bao gồm gần đây nhất với SQL Server 2012 Service Pack 2 ), bạn không muốn áp dụng gói dịch vụ cho đến lần đầu tiên CU cho chi nhánh đó đã được phát hành anyway. Trong trường hợp này, có một hotfix tạm thời để giải quyết vấn đề không được khắc phục kịp thời để tạo mã Gói dịch vụ, nhưng điều đó không phải lúc nào cũng đúng.

Chúng tôi thường theo kịp với CU's. Khoảng 1 tháng sau khi phát hành, chúng tôi sẽ áp dụng chúng cho dù chúng tôi có gặp phải sự cố được khắc phục hay không.

Tuy nhiên, sau khi chúng tôi gặp phải một vấn đề lớn, chúng tôi đã dừng thực hành này. Trong trường hợp của chúng tôi, gói dịch vụ chúng tôi đã cài đặt đã khắc phục sự cố với lập chỉ mục toàn văn mà chúng tôi gặp phải. Vài tháng sau, một trong những CU đã quay trở lại sửa chữa cụ thể đó. Điều này gây ra tất cả các loại vấn đề cho chúng tôi đã mất khá nhiều nghiên cứu để tìm hiểu điều gì đã xảy ra. Chúng tôi đã kết thúc việc mã hóa một công việc xung quanh mà sau đó đã bị hỏng khi một CU mới phá vỡ một thứ khác ... Kết quả cuối cùng: máy chủ được cài đặt từ mặt đất lên đến mức SP / CU cụ thể và bị đóng băng.

Hiệu suất ứng dụng của chúng tôi là như vậy mà chúng tôi không quan tâm đến bất kỳ cải tiến hiệu suất SQL mới nào có thể xuất hiện, vì vậy đó không phải là vấn đề. Ngoài ra, báo cáo và các truy vấn khác luôn lấy lại kết quả hợp lệ để mọi chỉnh sửa mới là không cần thiết. Điều đó có nghĩa là nó phải là một vấn đề bảo mật trước khi chúng tôi xem xét áp dụng CU tại thời điểm này.

Tôi hoàn toàn đồng ý với Aaron: chỉ làm điều này nếu chu trình kiểm tra / QA của bạn có thể kiểm tra đúng cách Nếu không tôi sẽ nói rõ ràng trừ khi nó khắc phục vấn đề mà bạn thực sự phải đối mặt. Và thậm chí sau đó, kiểm tra mọi khía cạnh nhỏ của nó với dữ liệu thực để đảm bảo rằng chúng không phá vỡ thứ gì đó mà bạn có thể phụ thuộc.