Kế hoạch bảo trì máy chủ Sql - Thực tiễn tốt nhất về nhiệm vụ và lập lịch

Tôi được giao nhiệm vụ đưa ra một kế hoạch bảo trì cho cơ sở dữ liệu Sql Server 2005 của chúng tôi. Tôi biết để sao lưu Tôi muốn thực hiện sao lưu cơ sở dữ liệu đầy đủ hàng ngày và sao lưu nhật ký giao dịch cứ sau 15 phút. Vấn đề của tôi là tìm ra những nhiệm vụ khác mà tôi muốn làm và tần suất tôi nên thực hiện chúng.

Vì vậy, cho đến nay tôi có điều này trong tâm trí. Chỉnh sửa cho tôi nếu có bất kỳ sai sót trong suy nghĩ của tôi hoặc một cách tốt hơn để làm điều này.

1. Sao lưu - Tất cả các bảng, Sao lưu đầy đủ (hàng ngày)
2. Sao lưu - Bảng được chọn, Sao lưu đầy đủ (hàng giờ)
3. Sao lưu - Nhật ký giao dịch (cứ sau 15 phút)
4. Kiểm tra tính toàn vẹn cơ sở dữ liệu (hàng ngày)
5. Sắp xếp lại chỉ số (hàng ngày)
6. Cập nhật số liệu thống kê (hàng ngày)
7. Thu nhỏ cơ sở dữ liệu (hàng tuần)
8. Chỉ số xây dựng lại (hàng tuần)
9. Dọn dẹp bảo trì (hàng ngày)

Tôi nhớ đã đọc cách đây một thời gian (khi tôi thiết lập một kế hoạch tương tự ở một công việc khác) rằng một số trong những nhiệm vụ này không cần phải được chạy hàng ngày hoặc không nên chạy hàng ngày. Như những cái nào, nó thoát khỏi tôi. Tôi có thể sử dụng một chút hướng dẫn về cách tạo một kế hoạch bảo trì tốt hơn để giảm mất dữ liệu trong thảm họa, nhưng sẽ không đánh thuế hệ thống khi chạy trong giờ cao điểm (và cũng tăng hiệu suất).

Josh,

Đây là một nhiệm vụ rất phổ biến cho tất cả các DBA và câu trả lời đúng KHÔNG giống nhau cho mọi người và cho mỗi máy chủ. Nhiều thứ khác, nó phụ thuộc vào những gì bạn cần.

Chắc chắn là bạn không muốn chạy "Shrink Database" như đã đề xuất. EVIL của nó để thực hiện và giới thiệu dưới đây sẽ cho bạn thấy lý do tại sao. Nó gây ra đĩa và cũng như phân mảnh chỉ mục và điều này có thể dẫn đến các vấn đề hiệu suất. Bạn nên tận dụng bằng cách cấp phát trước một kích thước lớn cho các tệp dữ liệu và nhật ký để tự động phát hành sẽ KHÔNG khởi động.

Tôi không hiểu số 2 của bạn. chọn bảng sao lưu đầy đủ. Bạn có thể giải thích thêm về điều này?

Đến với Index sắp xếp lại, cập nhật số liệu thống kê và xây dựng lại chỉ mục, bạn cần cẩn thận với cách bạn làm điều này nếu không bạn sẽ sử dụng nhiều tài nguyên hơn và kết thúc với các vấn đề về hiệu suất.

Khi bạn xây dựng lại các chỉ mục, số liệu thống kê của các chỉ mục được cập nhật với fullscan nhưng nếu bạn cập nhật số liệu thống kê sau đó, thì các số liệu đó sẽ được cập nhật lại với một mẫu mặc định (phụ thuộc vào một số yếu tố, thường là 5% của bảng khi kích thước bảng> 8 MB) có thể dẫn đến các vấn đề hiệu suất. Tùy thuộc vào phiên bản bạn có, bạn có thể thực hiện xây dựng lại chỉ mục trực tuyến. Cách đúng đắn để thực hiện hoạt động này là kiểm tra mức độ phân mảnh và tùy thuộc vào việc xây dựng lại chỉ mục hoặc sắp xếp lại chỉ mục + thống kê cập nhật. Và bạn cũng có thể muốn xác định bảng nào cần cập nhật số liệu thường xuyên hơn và cố gắng cập nhật số liệu thống kê thường xuyên hơn.

Các kế hoạch bảo trì đều ổn nhưng thật khó để tận dụng tốt nhất chúng khi thực hiện các tùy chỉnh này trừ khi bạn có thể đăng nhập vào SSIS và điều chỉnh MP. đó là lý do tại sao tôi KHÔNG thích sử dụng chúng và sử dụng các tập lệnh miễn phí của Ola Hallengren mạnh hơn MP. Ngoài ra, tôi cũng khuyên bạn nên theo kịp bài viết được tham khảo của Paul Randal về chủ đề này.

Tham chiếu: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

Đây KHÔNG phải là một câu trả lời toàn diện cho câu hỏi của bạn mà là một điểm khởi đầu tốt. HTH và cho chúng tôi biết nếu bạn có thêm câu hỏi / nhận xét nào.

Tôi sẽ chia sẻ kinh nghiệm của mình, ngay cả khi bạn đã chấp nhận câu trả lời. Có lẽ nó sẽ hữu ích :-).

1. Sao lưu toàn bộ hàng ngày (hàng ngày) - tuyệt vời, nhưng đừng quên kiểm tra dung lượng và xóa các tệp cũ sau một thời gian được xác định trước.
2. Sao lưu các bảng đã chọn (hàng giờ) - không hiểu tại sao bạn cần cái này, tốt hơn hết là bạn nên sao lưu bằng các bản sao lưu khác biệt. Làm thế nào để bạn chỉ sao lưu các bảng nhất định: SSIS, script, bcp? Về sao lưu khác, đừng lên lịch quá thường xuyên, vì bạn sẽ đánh cắp vai trò sao lưu nhật ký.
3. Sao lưu nhật ký giao dịch (cứ sau 15 phút) - thật tuyệt, bạn có chắc bạn cần cho tất cả các cơ sở dữ liệu? Có phải tất cả các cơ sở dữ liệu sử dụng mô hình phục hồi đầy đủ hay không?
4. Kiểm tra tính toàn vẹn của db - có, nhưng bạn cần đảm bảo rằng bạn không giết chết môi trường của bạn. Các báo cáo kiểm tra DBCC khá ích kỷ về tài nguyên và quét các dbs hoàn chỉnh, vì vậy chúng cần được lên lịch trong giờ nghỉ.
5. Sắp xếp lại chỉ số (hàng ngày) - đừng ép buộc, chỉ làm điều đó nếu cần. Kiểm tra chỉ số DMV về phân mảnh và tổ chức lại chỉ dựa trên nhu cầu. Tôi sẽ di chuyển tất cả các hoạt động chỉ số và thống kê trên một nhiệm vụ hàng tuần.
6. Cập nhật số liệu thống kê (hàng ngày) - Vui lòng xem câu trả lời của tôi cho câu hỏi trước đó. Thay vì chỉ buộc cập nhật tất cả các số liệu thống kê, mỗi ngày, bạn nên kiểm tra tốt hơn khi số liệu thống kê được cập nhật lần cuối và chỉ trong một số trường hợp cập nhật chúng.
7. Cơ sở dữ liệu thu nhỏ (hàng tuần) - Ồ, không. Xin vui lòng đọc bài viết của Paul Randal về thu nhỏ tập tin.
8. Chỉ số xây dựng lại (hàng tuần) - xem 5.

9. Dọn dẹp bảo trì (hàng ngày) - ok với điều đó.

10. Bạn cũng nên thêm một tác vụ để xác minh các bản sao lưu của mình - có một phiên bản lệnh RESTORE (verifyOnly .. nếu tôi nhớ chính xác) - hãy nói hàng tuần, mặc dù tôi thích nó hàng ngày.

Bạn đề cập rằng bạn muốn được bảo vệ trong trường hợp mất dữ liệu, vì vậy tôi muốn nói rằng bạn cần thêm cơ sở dữ liệu hệ thống trong quy trình bảo trì này. Và cũng cẩn thận sao lưu các tệp trên một máy khác với máy chủ. Giữ ở đâu đó một tệp với những việc cần làm trong trường hợp bạn cần xây dựng lại db chính, msdb..etc. Chúc may mắn với nhiệm vụ của bạn!

Câu trả lời muộn nhưng có thể được sử dụng cho các độc giả khác.

Xin lưu ý rằng có rất nhiều nhiệm vụ bảo trì hoặc báo cáo, bạn có thể tạo, mang những rủi ro không thể nhìn thấy liên quan đến chúng.

Điều gì sẽ xảy ra khi một ổ đĩa được lấp đầy trong quá trình sao lưu vi sai được thực hiện hàng ngày? Và nếu một công việc xây dựng lại chỉ mục chạy dài bất thường thì sao? Sẽ thế nào nếu một quá trình tải dữ liệu gây ra sự tranh chấp tài nguyên trên diện rộng, đưa các hoạt động bình thường đến đầu gối của họ? Tất cả đều là những sự kiện được lên kế hoạch, nhưng có thể gây ra sự gián đoạn đáng kể cho chính các quy trình chúng tôi đang cố gắng bảo vệ.

Luôn xem xét cách các công việc khác nhau tương tác và thời gian chúng sao cho không có sự chồng chéo trong các nhiệm vụ nhạy cảm hoặc tốn nhiều tài nguyên.

Tôi khuyên bạn nên đọc bài viết này trước: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-t task-in-sql-server /

Nó mô tả cách thực hiện các nhiệm vụ bảo trì quan trọng trong SQL Server - không có rủi ro. Ví dụ: bạn có thể xây dựng các kiểm tra đơn giản vào các công việc bảo trì của mình để xác minh các tài nguyên có sẵn cũng như những gì một hoạt động sẽ yêu cầu trước khi thực hiện. Điều này cho phép bạn đảm bảo rằng môi trường của bạn có thể xử lý những gì bạn sắp làm và hủy bỏ với một lỗi có ý nghĩa nếu tài nguyên không đủ.

1. Trông có vẻ ổn

2. Bạn có thể hưởng lợi từ việc thực hiện Sao lưu khác biệt ở đây. Nhìn vào chúng cho chắc chắn

3. Trông có vẻ ổn

4. Trông có vẻ ổn

5. Như đã nêu trước đây, thu hẹp cơ sở dữ liệu là xấu vì chúng tạo ra sự phân mảnh vật lý của dữ liệu và tệp nhật ký của bạn, do đó gây ra nhiều lần đọc IO ngẫu nhiên hơn.

5, 6 và 8: Xem sau.

Chúng thực sự đi đôi với nhau, vì các chỉ mục dựa trên số liệu thống kê cập nhật và thứ tự của các hoạt động này là khá quan trọng. Phương pháp cơ bản mà tôi sử dụng, được thừa nhận có thể không hiệu quả với tất cả mọi người, là tôi thực hiện hai vòng bảo trì chỉ số. Đầu tiên, tôi thực hiện các chỉ mục được nhóm và sau đó là các chỉ mục không bao gồm. Phương pháp tôi sử dụng cho cả hai là như sau. Nếu một chỉ mục đủ lớn và đủ phân mảnh (sys.dm_db_index_physical_stats), tôi sẽ xây dựng lại chỉ mục (bao gồm cập nhật thống kê với quét toàn bộ). Nếu một chỉ mục quá nhỏ để xây dựng lại hoặc không đủ phân mảnh để xây dựng lại (dưới 100 trang và phân mảnh từ 5% đến 15%), trước tiên tôi sẽ thực hiện sắp xếp lại chỉ mục. Sau đó tôi sẽ thực hiện cập nhật thống kê với quét toàn bộ.

Bây giờ, điều này bao gồm số liệu thống kê chỉ số, nhưng bỏ qua việc làm bất cứ điều gì để thống kê cột. Hàng tuần, tôi sẽ cập nhật số liệu thống kê cột.

Tôi hy vọng điều này đã giúp một cách nào đó!

Tôi nghiêng về nhận xét "mất dữ liệu có thể có sự phân nhánh hợp pháp tại đây".

Sau đó, bạn chắc chắn muốn có được một công cụ bên thứ 3 mạnh mẽ (như DPM) có thể xử lý các bản sao lưu (và phục hồi sau các sự kiện thảm khốc trong nháy mắt và quấy rối tối thiểu) nhanh hơn rất nhiều so với bất kỳ tập lệnh nào bạn có thể rút ra khỏi Internet.

Có bản sao lưu là một chuyện. Biết cách sử dụng chúng trong trường hợp khẩn cấp là chuyện khác.

Đừng quên rằng nếu bạn đang khôi phục lại một bản sao lưu sau một thất bại lớn, có lẽ bạn đã phải chịu một sự căng thẳng và áp lực. Bạn không cần thêm gánh nặng của việc đào bới và viết lên hoàn hảo câu lệnh RESTORE DATABASE với 12 tệp nhật ký giao dịch ... Và cầu nguyện rằng nó không làm bạn thất vọng ...

Tại nơi làm việc của tôi, tôi có thể khôi phục / khôi phục cơ sở dữ liệu 350Gb đến bất kỳ điểm nào trong khoảng thời gian 5 phút cho tuần trước bằng cách sử dụng DPM. Với giao diện GUI. Đáng giá, trong cuốn sách của tôi.

Đối với phần còn lại, chắc chắn xem xét tập lệnh chỉ mục của Ola Hallengren và điều chỉnh các tham số theo nhu cầu của bạn. Cá nhân, tôi đã kết hợp nó với một nhiệm vụ theo lịch trình khiến nó chạy trong một giờ mỗi đêm mà không cần quét lại, do đó, nó xử lý các chỉ mục tồi tệ nhất mỗi lần và buộc quét lại toàn bộ phân mảnh mỗi thứ bảy hoặc khi tất cả các chỉ mục trong danh sách đã được phân mảnh.

Cuối cùng, tôi thêm giọng nói của mình vào nhóm "không tự động thu nhỏ tệp của bạn". File Shrink chỉ là một công cụ để sử dụng một cách rời rạc khi một sự kiện bất thường xảy ra đã ghi đè lên các bản ghi hoặc tệp DB của bạn (vòng lặp vô hạn hoặc tương tự). Nó không phải là một công cụ bảo trì. Nếu bạn có áp suất không gian đĩa, co lại sẽ chỉ trì hoãn điều không thể tránh khỏi.