Sẽ đi được bao xa khi Xác thực cài đặt Gói dịch vụ SQL?

Khi áp dụng Gói dịch vụ cho máy chủ SQL sản xuất, tôi thường có một cửa sổ thời gian chết dự kiến ​​khoảng 30 phút.

Đã bị cắn trước đó và phát hiện ra rằng một điều kiện tiên quyết cần thiết như một miếng vá không có, có thể thêm vài phút vào cửa sổ thời gian chết của bạn ( và có thể đưa bạn qua cửa sổ, hoặc buộc lại một lịch trình ).

Bây giờ khi bản cập nhật đang trong giai đoạn lập kế hoạch, tôi di chuyển Gói dịch vụ đến máy chủ và kiểm tra nó thông qua "Kiểm tra tệp đang sử dụng" hoặc "Sẵn sàng cập nhật". Tôi hủy bản cập nhật tại thời điểm đó và cảm thấy tự tin nhất có thể trong quá trình cập nhật, tôi sẽ không chạy qua cửa sổ thời gian chết theo lịch trình.

Bạn có thể hủy từ một trong hai màn hình, nhưng vì nút "Cập nhật" trên "Sẵn sàng cập nhật" ở cùng vị trí với nút "Tiếp theo>" trên "Kiểm tra tệp đang sử dụng", một lần bấm đúp vô tình có thể vô tình bắt đầu cập nhật, trong khi xác nhận

Câu hỏi của tôi:

Tôi có nên dừng xác nhận tại "Kiểm tra tệp đang sử dụng" hoặc "Sẵn sàng cập nhật" không? Tôi đã xác thực mọi thứ tôi có thể vào cuối "Kiểm tra tệp đang sử dụng" chưa? Liệu sẽ "Sẵn sàng cập nhật" thêm giá trị cho xác nhận?

Tôi có nên dừng xác nhận tại "Kiểm tra tệp đang sử dụng" hoặc "Sẵn sàng cập nhật" không? Tôi đã xác thực mọi thứ tôi có thể vào cuối "Kiểm tra tệp đang sử dụng" chưa?

Chỉ cần tiếp tục nhấp NEXTvà áp dụng gói dịch vụ, bạn có thể bỏ qua quy trình này một cách an toàn. Kiểm tra files in use processlà xử lý tình huống trong đó người dùng cuối không muốn khởi động lại sau khi áp dụng gói dịch vụ trong trường hợp đó bạn cần đảm bảo tất cả các quy trình như vậy được dừng lại, nhưng trong mọi trường hợp tôi khuyên bạn nên khởi động máy / nút windows mà bạn đang áp dụng gói dịch vụ.

Điều duy nhất có thể xảy ra là sau khi nâng cấp thành công, bạn cần khởi động máy windows. Điều này là như vậy sẽ KHÔNG làm cho SP thất bại

Liệu sẽ "Sẵn sàng cập nhật" thêm giá trị cho xác nhận?

Việc sẵn sàng cập nhật về cơ bản cho bạn thấy tất cả các tính năng bạn sẽ cập nhật và không có gì hơn thế. Bạn phải bấm vào updateđây, nó không thêm bất kỳ giá trị nào mà sẽ chỉ cho bạn biết bạn đã chọn cấu hình nào

Tình huống lý tưởng là có một máy chủ, về mặt hệ điều hành và phần mềm khác, hoàn toàn khớp với môi trường sản xuất, trên đó bạn có thể thực hiện cập nhật trước. Bằng cách đó bạn biết mọi thứ được yêu cầu.

Điều này tốt nhất sẽ là một VM mà bạn có thể chụp nhanh, vì vậy nếu bạn gặp phải và khắc phục sự cố, bạn có thể quay lại ảnh chụp nhanh và bắt đầu lại với quy trình cập nhật của mình. Lặp lại điều này cho đến khi quy trình nâng cấp hoạt động và bạn biết các yêu cầu khởi động lại, và sau đó lên kế hoạch lặp lại quy trình trong sản xuất.

Một trong những VM phát triển / thử nghiệm của bạn có thể lý tưởng cho việc này nếu bạn có chúng (nghĩa là nếu quá trình phát triển / kiểm tra / phát hành của bạn không chỉ là "đập mã với nhau và ném trực tiếp vào sản xuất"!). Theo cách này, về cơ bản, bạn đang đối xử với gói dịch vụ giống như một trong những sửa lỗi hoặc phát hành tính năng của riêng bạn, nghĩa là bạn có thể thực hiện kiểm tra hồi quy đầy đủ trên ứng dụng của mình sau khi gói dịch vụ được áp dụng cho môi trường kiểm tra (để đảm bảo MS trú ẩn Không giới thiệu bất kỳ lỗi hoặc thay đổi nào đối với hành vi không xác định mà ứng dụng của bạn phụ thuộc vào - hoặc họ chưa sửa lỗi mà mã của bạn phụ thuộc vào!).

Rõ ràng "lý tưởng" này có thể tốn nhiều thời gian hơn các lựa chọn khác ...

Để trả lời câu hỏi của bạn, bạn có thể bỏ qua các tệp đang sử dụng xác nhận; nó không bao giờ chặn bạn tiếp tục và chỉ ở đó để thông báo cho bạn nếu bạn có thể cần phải khởi động lại SAU.

Còn nhiều tình huống nữa mà bạn vẫn phải khởi động lại và nó sẽ không cho bạn biết (thường là liên quan đến .NET Framework) vì vậy bạn sẽ luôn khởi động lại bất kể điều gì. Ngoài ra, nếu bạn không khởi động lại ngay bây giờ, bạn sẽ cần thực hiện vào tháng tới khi gói tiếp theo xuất hiện vì đó là trình chặn bản vá.

Nhưng để giải quyết con voi trong phòng ngay cả khi bạn chỉ vá một hoặc hai máy chủ thì bạn nên phân bổ thời gian nhiều hơn 30 phút; 60-120 phút là đúng, đặc biệt nếu bạn có AGs / FCI / phản chiếu / sao chép và các tính năng Enterprise. Nếu bạn có vài chục máy chủ, bạn có thể nén nó trong khoảng bốn giờ vì bạn sẽ tự động hóa một phần ở giai đoạn đó và thật hiếm khi tất cả đều thất bại với các vấn đề hoàn toàn khác nhau.

Lý do bạn cần thêm thời gian là bạn không bao giờ biết chuyện gì đang xảy ra với máy chủ ESX, tạm thời làm chậm SAN hoặc các lỗi trong năm 2012 mà họ bị cáo buộc đã sửa gần đây với cài đặt cập nhật chậm. Hoặc bằng cách nào đó bạn đã quên xóa SSISDB khỏi AG trước và bây giờ nó đã bị xóa và bạn cần sửa nó. Hoặc các lỗi lặp đi lặp lại từ MS làm hỏng các trường hợp với filestream để bạn phải vào Thêm / Xóa Chương trình và sửa chữa trước khi áp dụng lại bản cập nhật. Hoặc bạn cần đợi AG quay lại đồng bộ sau khi vá (dễ dàng 30 phút trên máy chủ bận), không thực hiện được và thực hiện bản sao.

Những kiểm tra sức khỏe cơ bản bạn đã tự động? Phải mất vài phút cho mỗi máy chủ để chạy tất cả các kiểm tra chính sách AG. Nếu bạn đang làm nó bằng tay, nó sẽ nhiều hơn; xác nhận DQS MDS SSRS SSAS đã quay trở lại và không đưa ra các lỗi ngu ngốc.

Tôi hoàn toàn có thể tự tin nói rằng mặc dù việc kiểm tra QA trước tiên rất hữu ích nhưng đã có rất nhiều lần một bản vá chỉ thất bại trong sản xuất vì ai đó đôi khi đã làm điều gì đó khác đi.

Dù sao danh sách này không phải là vô tận nhưng chắc chắn là hơn 30 phút. Bạn không muốn nhìn vào đồng hồ trong khi bạn đang cố gắng khắc phục thảm họa chỉ vì bạn được trích dẫn với giới hạn thời gian ngắn. Tôi hiểu các nhà quản lý muốn nghe nó - và đó là lý do tại sao các DBA được trả nhiều tiền vì chúng tôi cần nói Không.