Những ưu và nhược điểm của các tập lệnh của Ola so với việc sử dụng gói bảo trì là gì?

9

Bạn có thể giúp tôi hiểu những ưu và nhược điểm của việc sử dụng giải pháp của Ola trong kế hoạch bảo trì không? Tôi đã chuẩn bị một bản trình bày dựa trên SQL Pass ( http://www.pass.org/DoadFile.aspx?File=ebae1b31 ) mà tôi sẽ trình bày.

Tôi cũng đang chuẩn bị một vài tình huống mà giải pháp của Ola giải quyết và giải pháp kế hoạch bảo trì không có. Tất cả các bạn có thể vui lòng giúp tôi giải thích điều này kỹ thuật hơn?

Nhân tiện, chúng tôi đang quản lý gần 150+ máy chủ (kết hợp 2008/2012/2014/2016) với giải pháp của Ola trên ít nhất 75% trong số họ. Tôi thích bài viết này của Brent Ozar. Nhưng trong một ý kiến, Brent đã khuyến nghị sử dụng giải pháp dựa trên tập lệnh cho số lượng máy chủ chúng tôi có. https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/

sql-server ola-hallengren

— Pat
nguồn

Chúng ta đang nói về các bản sao lưu, bảo trì chỉ số / chỉ số, kiểm tra tham nhũng hay tất cả những điều trên?

— nkdbajoe

Tất cả bọn họ. Toàn bộ kịch bản giải pháp bảo trì của Ola. Tôi đã giải quyết các vấn đề về xây dựng lại chỉ số và cập nhật thống kê không cần thiết trong kế hoạch bảo trì bằng các tập lệnh của Ola. Tôi chỉ muốn một số đạn kỹ thuật từ các DBA khác ngoài kia. Cảm ơn bạn.

— Pat

2

Cá nhân tôi tin rằng giải pháp tốt nhất là một giải pháp đáp ứng yêu cầu kinh doanh của bạn và khả năng của bạn để giải quyết nó khi có lỗi. Nói chung, giải pháp của Ola không tệ nhưng tôi vẫn thích giải pháp tùy chỉnh của riêng mình cho môi trường của mình. Ví dụ, để bảo trì chỉ mục, tôi muốn có các thực thi song song để tiết kiệm thời gian. Giải pháp của Ola không hoạt động ở đây. Tôi muốn cập nhật số liệu thống kê gia tăng, giải pháp của Ola cũng không hoạt động ở đây.

— jyao

Bạn có dữ liệu nào cho thấy họ tốt hơn không hay bạn chỉ đi với những gì bạn cảm thấy tốt hơn? Cách tốt nhất để giải quyết vấn đề là lấy một số dữ liệu hiệu suất để có thể chỉ ra lý do tại sao một phương pháp tốt hơn

— Joe W

Để bảo trì chỉ mục, nhiều lần yếu tố giới hạn là SAN và lưu trữ phụ của bạn. Tùy thuộc vào cấu hình SAN của bạn, bạn có thể không thấy bất kỳ cải thiện nào trong việc xây dựng lại song song.

— Alen

13

Tôi đã viết ở đây

Các kế hoạch bảo trì không phải là xấu, nhưng khi môi trường của bạn phát triển, tính linh hoạt và chức năng hạn chế mà các kế hoạch bảo trì cung cấp sẽ không đủ.

Để thêm

Giải pháp bảo trì của Ola được chấp nhận rộng rãi trong cộng đồng và các tổ chức lớn .
Nguồn mở của nó và các vấn đề có thể được nêu ra tại github / các vấn đề với khả năng sửa nó rất nhanh.
Nó linh hoạt và có thể mở rộng (ngay cả khi bạn muốn triển khai nó tới 100 máy chủ, chỉ cần sử dụng Install-DbaMaintenanceSolution từ dbatools.)
Microsoft đã mất gần một thập kỷ để sửa lỗi GUI kế hoạch bảo trì bị lỗi :-)
có nhiều tài liệu và câu hỏi thường gặp và được cập nhật liên tục để chứa các phiên bản máy chủ sql mới hơn.
trong phiên bản xem trước , bạn thậm chí có thể chạy các bản sao lưu song song.
đối với giải pháp bảo trì chỉ mục, bạn thậm chí có thể xử lý thời gian, ví dụ nếu nó chạy nhiều hơn X lượng thời gian, hãy hủy bỏ nó.

— Kin Shah
nguồn

5

Một trong những ưu điểm chính của giải pháp dựa trên tập lệnh là dễ triển khai - thứ gì đó có liên quan rõ ràng trong trường hợp của bạn, khi bạn có hơn 150 máy chủ. Cố gắng triển khai một số kế hoạch bảo trì (tức là tối thiểu 2, một cho cơ sở dữ liệu hệ thống và một cho cơ sở dữ liệu người dùng) trên 150 máy chủ sẽ là một cơn ác mộng. Duy trì chúng một lần tại chỗ cũng nhiều rắc rối.

Một giải pháp dựa trên kịch bản dễ dàng hơn nhiều để triển khai và duy trì theo thời gian. Kịch bản của Ola khá toàn diện và đáp ứng hầu hết các nhu cầu. Chúng đại diện cho một điểm khởi đầu tuyệt vời cho bất kỳ tổ chức nào sau đó điều chỉnh để phù hợp với yêu cầu riêng của họ.

Trong trường hợp của chúng tôi, chúng tôi có khoảng 40 phiên bản SQL trong môi trường DEV của chúng tôi và chúng tôi sử dụng các tập lệnh Ola đã sửa đổi với tính năng đa kết nối của SSMS để có thể đưa ra các thay đổi cho chế độ bảo trì trên tất cả 40 trường hợp chỉ với một cú nhấp chuột. Bất kỳ trường hợp đặc biệt được xử lý bởi sửa đổi của chúng tôi.

— Mike
nguồn

3

Tôi không chắc chắn 100% về các tập lệnh của anh ấy nhưng các tập lệnh tùy chỉnh tốt hơn các kế hoạch bảo trì. Các kế hoạch được xây dựng sẽ xây dựng lại mọi chỉ mục trên một bảng cho dù có phân mảnh nhỏ như thế nào. Nếu bạn luôn bật, nó sẽ tạo ra một cơn bão giao thông.

Tập lệnh tùy chỉnh bạn có thể xây dựng lại bất cứ thứ gì trên 20% hoặc bất cứ ngưỡng nào của bạn. Ít chỉ số được xây dựng lại tại một thời điểm. Ít luôn luôn trên dữ liệu để gửi cho người thứ hai. Xây dựng lại nhanh hơn bởi vì bạn đang xây dựng lại các chỉ mục ít hơn. Cửa sổ bảo trì ngắn hơn yêu cầu.

Lần trước tôi đã sử dụng các kế hoạch bảo trì, tôi đã có một bảng hàng 300 triệu và Luôn Bật sẽ chậm hàng giờ mỗi khi việc xây dựng lại chỉ số bắt đầu và các vấn đề với nhật ký giao dịch bị tràn. Đã trở lại với kịch bản và tất cả đã biến mất.

— Alen
nguồn

1

Ban đầu tôi đã viết riêng cho SQL 2005 vào khoảng năm 2007. Tôi đã sử dụng những cuốn sách trực tuyến làm cơ sở và thay đổi nó một chút. Trước đó, có vẻ như hầu hết mọi người đang sử dụng các kế hoạch và bây giờ dường như nó đã đảo ngược. Và trước khi tôi bắt đầu làm công cụ DBA, DBA trước đó trước tôi đã có các tập lệnh tùy chỉnh cho SQL 2000. Điều duy nhất tôi khác là tôi xây dựng lại mọi thứ. Nó đã nhanh hơn để xây dựng lại bất cứ điều gì hơn 20% hoặc 30% so với tổ chức lại là tốt. Để sao lưu, chúng tôi luôn sử dụng các sản phẩm của bên thứ ba

— Alen

1

Cũng như lý do yêu thích ở trên của tôi là có thể tự động chuyển loại sao lưu để cơ sở dữ liệu mới sẽ có bản sao lưu đầy đủ vào lần đầu tiên công việc sao lưu nhật ký chạy thay vì đợi đến khi công việc sao lưu đầy đủ tiếp theo chạy.

— SQLDBAWithABeard
nguồn

0

Kế hoạch bảo trì sẽ làm tốt hầu hết thời gian. Kịch bản của Ola Hallengren sẽ làm tốt hầu hết thời gian.

Trong những trường hợp rất hiếm, bạn có thể phải tự trồng.

Như Jyao đã nói, bạn cảm thấy thoải mái nhất khi làm việc. Nếu đồng nghiệp của bạn cảm thấy thoải mái nhất với các kế hoạch bảo trì, tại sao bạn lại gặp khó khăn?

Nếu anh ta làm việc trong hơn 20 năm, anh ta đã viết kịch bản bảo trì của riêng mình. Ngay khi bạn đang học lái xe, có lẽ có một số thanh niên mặc quần short và quần áo đi kèm và tất cả đều như "này, bạn là một lập trình viên cũ, kế hoạch bảo trì tốt hơn - và kéo quần của bạn xuống, bạn trông thật lố bịch! ".

Sau đó, có lẽ đã có một trận chiến kéo dài 4 năm, nơi thanh niên kiêu ngạo trượt vào kế hoạch bảo trì bất cứ khi nào anh ta có thể. Bây giờ, một thanh niên punk khác với quần jean skinny và cà vạt nơ kỳ dị đang bảo anh ta quay lại kịch bản. Nó đủ để biến mái tóc của bạn thành màu xám.

Ba điều cần xem xét:

Những ví dụ về sự vượt trội của Hallengrenite có thực sự áp dụng cho môi trường của bạn không?

Nó sẽ gây ra cho bạn một vấn đề thực tế nếu anh ta sử dụng các kế hoạch bảo trì?

Nếu bạn thuyết phục anh ấy sử dụng kịch bản của Hallengren và có vấn đề, anh ấy sẽ có thể tự giải quyết hay anh ấy sẽ phải gọi cho bạn?

— James
nguồn

Trả lời hai câu hỏi đầu tiên Có. Chúng tôi đã thấy các vấn đề với Kế hoạch bảo trì và tôi đã giải quyết những vấn đề đó bằng giải pháp của Ola. Có một tác vụ nhật ký thu nhỏ (??) trên máy chủ sản xuất và tôi đã vô hiệu hóa ngay lập tức. Câu hỏi thứ ba, tôi không biết. Tôi không chắc liệu anh ấy có thể giải quyết các vấn đề do chính Kế hoạch bảo trì tạo ra hay không. Khi tôi hỏi anh ấy trong trường hợp chúng tôi thấy vấn đề với nó, chúng tôi nên làm gì? Câu trả lời của ông là gọi cho bộ phận hỗ trợ của Microsoft. (??)

— Pat

@Pat, ahh, có vẻ như anh ta đã đạt đến giới hạn của mình theo Nguyên tắc Peter. Hãy cẩn thận cố gắng làm cho anh ta tốt hơn - anh ta sẽ không đánh giá cao sự giúp đỡ.

— James