MSDB là một cơ sở dữ liệu hệ thống được sử dụng bởi SQL Server. MSDB lưu trữ tất cả các loại dữ liệu, chẳng hạn như lịch sử sao lưu và khôi phục, lịch sử công việc SQL Agent, nhật ký theo dõi quá trình vận chuyển, gói SSIS, dữ liệu Database Engine Tuning Advisor và dữ liệu hàng đợi Service Broker. Cũng giống như cơ sở dữ liệu người dùng, msdb cần được bảo trì thường xuyên, bao gồm tối ưu hóa chỉ mục và quan trọng hơn là thanh lọc thường xuyên.
Lịch sử sao lưu và khôi phục
Theo mặc định, không có phương pháp nào để xóa hoặc xóa lịch sử sao lưu và khôi phục khỏi msdb. Nó được lưu giữ mãi mãi cho đến khi bạn thiết lập quy trình thủ công hoặc tự động để xóa dữ liệu. Bằng cách không xóa dữ liệu này, msdb sẽ tiếp tục phát triển, có nghĩa là việc đọc và ghi vào các bảng đó có thể trở nên chậm hơn và ảnh hưởng đến tốc độ của các công việc sao lưu của bạn.
Hầu hết các công cụ của bên thứ ba và các giải pháp bảo trì có uy tín đều bao gồm các quy trình xóa lịch sử sao lưu và khôi phục để ngăn điều này trở thành sự cố. Một cách dễ dàng để biết bạn có đang xóa lịch sử sao lưu hay không là truy vấn trực tiếp msdb:
CHỌN CHUYỂN ĐỔI (CHAR (100), SERVERPROPERTY ('Tên máy chủ')) AS Server, msdb.dbo.backupset.database_name, msdb.dbo.backupset.backup_finish_date, CASE msdb..backupset.type WHEN 'D' THEN ' Cơ sở dữ liệu 'WHEN' L 'THEN' Log 'KẾT THÚC NHƯ backup_typeFROM msdb.dbo.backupmediafamilyINNER THAM GIA msdb.dbo.backupset TRÊN msdb.dbo.backupmediafamily.media_set_id =msdb.dbo.backupset.media_set_idORDER BY msdb.dbo.fiupset.backate_back / pre>
Nếu bạn có lịch sử sao lưu hoặc khôi phục cách đây hơn 90 ngày, thì bạn nên điều tra xem có yêu cầu quy định nào bắt buộc bạn phải lưu giữ thông tin lịch sử về các bản sao lưu đó trong một khoảng thời gian cụ thể hay không. Nếu không có yêu cầu, thì bạn nên xem xét xóa dữ liệu cũ hơn một khoảng thời gian nhất định. Lịch sử sao lưu là không cần thiết để khôi phục cơ sở dữ liệu của bạn và chúng tôi khuyên bạn nên xóa nó thường xuyên để giữ cho msdb ở kích thước hợp lý. Giữ 90 ngày hoặc ít hơn là phạm vi mà tôi thường đề xuất cho khách hàng.
Để thiết lập quy trình xóa lịch sử sao lưu và khôi phục, hãy tạo một công việc thực thi sp_delete_backuphistory thủ tục được lưu trữ trong msdb và chuyển cho nó một tham số ngày. Quy trình được lưu trữ sẽ xóa tất cả lịch sử sao lưu và khôi phục cũ hơn ngày bạn cung cấp. Bạn cũng có thể tạo Kế hoạch Bảo trì Cơ sở dữ liệu và sử dụng tác vụ Lịch sử Dọn dẹp.
Cố vấn Điều chỉnh Công cụ Cơ sở dữ liệu
Cố vấn Điều chỉnh Cơ sở dữ liệu, còn được gọi là DTA, là một công cụ mà các nhà phát triển và Quản trị viên Cơ sở dữ liệu có thể sử dụng để giúp điều chỉnh cơ sở dữ liệu. DTA tận dụng cơ sở dữ liệu msdb để lưu trữ lịch sử điều chỉnh và các đối tượng hỗ trợ khác.
Tôi thường xuyên tìm thấy phần còn lại của DTA trong msdb trên máy chủ sản xuất của khách hàng. Khi tôi tìm thấy các bảng này, tôi truy vấn trực tiếp để xác định xem DTA có còn được sử dụng hay không. May mắn thay, tôi vẫn chưa tìm thấy một khách hàng nào đang tích cực chạy DTA chống lại quá trình sản xuất, vì nó có thể ảnh hưởng đáng kể đến hiệu suất. Khi tôi xác nhận và giao tiếp với khách hàng, tôi xóa các bảng DTA khỏi msdb. Trong một số trường hợp, điều này giải phóng nhiều gigabyte dung lượng. Để đề phòng, tôi cũng dành thời gian để giải thích tác động về hiệu suất mà việc chạy DTA chống lại quá trình sản xuất có thể gây ra và khuyến khích khách hàng của tôi rằng mọi việc sử dụng trong tương lai nên được thực hiện trên máy chủ phát triển.
Tác nhân máy chủ SQL
Đôi khi, tôi sẽ tìm thấy một khách hàng đã vô tình bỏ chọn hộp giới hạn kích thước của nhật ký lịch sử công việc. Đây là một sai lầm dễ mắc phải nếu bạn có một máy chủ bận và nhật ký liên tục di chuyển nhanh đến mức bạn không có bất kỳ lịch sử công việc hữu ích nào để tham khảo khi khắc phục sự cố công việc SQL Server Agent. Một cách tiếp cận tốt hơn là tăng kích thước nhật ký lịch sử công việc tối đa (theo hàng) lên một giá trị cao hơn nhiều thay vì để nó phát triển không bị hạn chế.
Trong trường hợp khách hàng tăng trưởng công việc không hạn chế, bảng lịch sử hệ thống đã phát triển quá mức và cần phải được thanh lọc. Cách tốt nhất để xóa lịch sử là sử dụng sp_purge_jobhistory và chuyển vào một tham số ngày. Thủ tục được lưu trữ sẽ xóa tất cả lịch sử công việc cũ hơn ngày bạn cung cấp. Nếu bạn phải giữ một số ngày tối thiểu của lịch sử SQL Server Agent, thì việc giới hạn nhật ký lịch sử công việc dựa trên các hàng sẽ không hiệu quả. Thay vào đó, không giới hạn kích thước của nhật ký lịch sử công việc và cũng lập lịch công việc sẽ chạy sp_purge_jobhistory và chuyển vào tham số ngày cho số ngày tối thiểu trong lịch sử công việc mà bạn cần. Thông thường giá trị sử dụng là 14 hoặc 30 ngày.
Nhà môi giới dịch vụ
Gần đây, tôi đã gặp sự cố với một ứng dụng khách trong đó msdb đã tăng kích thước lên 14GB. Sau nỗ lực cập nhật phiên bản lên gói dịch vụ hiện tại, việc nâng cấp không thành công khi áp dụng các tập lệnh cho msdb và khiến msdb tăng trở lại theo cấp số nhân. Sau một số nghiên cứu, chúng tôi phát hiện ra Service Broker đã được bật cho các thông báo sự kiện nhưng nó không được định cấu hình đúng cách. Trong hơn một năm, các thông báo sự kiện đã được xếp hàng đợi, nhưng không được định tuyến.
Khi kiểm tra sys.transmission_queue, tôi thấy rằng nhà môi giới dịch vụ trong cơ sở dữ liệu đích không khả dụng và nhà môi giới dịch vụ đã bị vô hiệu hóa về mặt quản trị. Sau đó, tôi đã kiểm tra xem thông báo sự kiện nào đã được thiết lập bằng cách truy vấn sys.server_events_notifications và chỉ tìm thấy một mục nhập:ghi lại tất cả các sự kiện nhật ký lỗi. Sau đó, tôi truy vấn sys.transmissions_queue để xem có bao nhiêu sự kiện trong hàng đợi và tìm thấy vài triệu bản ghi ở đó.
Sau khi thảo luận vấn đề này với khách hàng và giải thích những phát hiện, chúng tôi đồng ý rằng cách hành động tốt nhất là bỏ thông báo sự kiện và xóa hàng đợi hiện tại bằng cách tạo một nhà môi giới mới. Để làm điều này, tôi đã thực thi ALTER DATABASE msdb SET NEW_BROKER. Điều này được thực hiện sau nhiều giờ và sau khi sao lưu đầy đủ msdb.
Sau khi xóa lệnh truyền_kết và xóa sự kiện, tôi có thể giảm msdb từ 14GB xuống 300MB. Trước khi khắc phục sự cố này, cơ sở dữ liệu msdb có độ trễ đĩa cao nhất trên phiên bản và máy khách đang gặp phải tình trạng tắc nghẽn thường xuyên. Sau khi triển khai thay đổi này, cũng như các tối ưu hóa khác, trải nghiệm người dùng của khách hàng được cải thiện đáng kể.
Đăng nhập Vận chuyển
Đầu sự nghiệp DBA của mình, tôi được thừa hưởng một máy chủ hợp nhất có vài trăm cơ sở dữ liệu đã được Đăng nhập Chuyển đến một máy chủ phụ trong một trung tâm dữ liệu khác. Máy chủ này đã hoạt động trong vài năm và đang chuyển các bản ghi sau mỗi 15 phút. Trường hợp này không chỉ bị lỗi do không xóa lịch sử sao lưu, mà còn không xóa lịch sử theo dõi Log Shipping đúng cách. Sau khi tôi xóa lịch sử sao lưu và kiểm tra kích thước của msdb, nó vẫn hiển thị nhiều dung lượng được sử dụng hơn bình thường. Tôi đã chạy một tập lệnh để hiển thị cho tôi tổng kích thước của mỗi bảng và nhận thấy rằng log_shipping_monitor_history_detail bàn rất lớn. Trong trường hợp này, tôi có thể chạy sp_cleanup_log_shipping_history để xóa lịch sử và đưa msdb trở lại kích thước bình thường.
Lập chỉ mục
Việc tối ưu hóa chỉ mục trong msdb cũng quan trọng như cơ sở dữ liệu người dùng của bạn. Nhiều lần tôi đã tìm thấy những khách hàng đang tối ưu hóa cơ sở dữ liệu người dùng nhưng không phải là cơ sở dữ liệu hệ thống. Vì cơ sở dữ liệu msdb được sử dụng nhiều bởi SQL Server Agent, Log Shipping, Service Broker, SSIS, sao lưu và khôi phục và các quy trình khác, các chỉ mục có thể bị phân mảnh cao. Đảm bảo rằng các công việc tối ưu hóa chỉ mục của bạn cũng bao gồm cơ sở dữ liệu hệ thống của bạn hoặc ít nhất là msdb. Tôi đã thấy các tối ưu hóa chỉ mục giải phóng vài gigabyte dung lượng khỏi các chỉ mục bị phân mảnh cao trong msdb.
Tóm tắt
Bỏ qua msdb có thể tác động tiêu cực đến hiệu suất của môi trường của bạn. Điều quan trọng là phải theo dõi kích thước của msdb, cũng như các quy trình sử dụng nó, để đảm bảo rằng nó hoạt động tối ưu. Lịch sử sao lưu và khôi phục là lý do phổ biến nhất khiến cơ sở dữ liệu msdb phình to, tuy nhiên Cố vấn điều chỉnh cơ sở dữ liệu, lịch sử SQL Server Agent, nhà môi giới dịch vụ, vận chuyển nhật ký và thiếu bảo trì chỉ mục đều có thể góp phần vào sự tăng trưởng quá mức của msdb và ảnh hưởng đến hiệu suất của cơ sở dữ liệu.
