Tôi đang sử dụng SQL Server Agent để lên lịch ngay cả các tác vụ không phải là cơ sở dữ liệu - đây có phải là ý tưởng tồi không?

Vì tôi là một DBA (và trong nhiều trường hợp là sysadmin thực tế), SQL Server được cài đặt trên hầu hết mọi máy chủ mà tôi phải làm việc thường xuyên. Gần đây tôi nhận ra rằng tôi đã sử dụng SQL Agent làm công cụ lập lịch công việc trong hầu hết mọi trường hợp, thay vì Trình lập lịch tác vụ Windows gốc.

Từ quan điểm của tôi, Tác nhân SQL có một số lợi thế so với Trình lập lịch tác vụ Windows gốc:

• Điều khiển từ xa (từ máy trạm của tôi) bắt đầu / dừng / giám sát các tác vụ
• Lịch trình được chia sẻ (chứ không phải mỗi nhiệm vụ riêng)
• Nhiều bước và điều khiển luồng
• Các loại nhiệm vụ khác nhau
• Cảnh báo về thất bại / hoàn thành
• Có thể được cấu hình để hoạt động như những người dùng khác nhau
• (Trung bình) thông báo lỗi mô tả, thay vì chỉ là một mã lỗi

Tuy nhiên, tôi không thể thoát khỏi cảm giác rằng đây là một thực tiễn tồi - Tác nhân SQL nên được dành riêng cho các tác vụ liên quan đến cơ sở dữ liệu và tôi nên để các tác vụ cấp hệ điều hành chạy trong Trình lập lịch tác vụ Windows, mặc dù tôi không thích tính khả dụng của nó.

Có thể dựa vào Đại lý SQL theo cách này không? Nếu không, tôi có nên xem xét một bộ lập lịch tác vụ Windows của bên thứ ba để có được một số chức năng mà tôi đang tìm kiếm không?

Cá nhân tôi nghĩ rằng sự cảnh báo lớn nhất sẽ là khó khăn trong việc giữ danh sách các công việc được tổ chức. Theo như tôi biết, bạn không thể tạo các thư mục để sắp xếp công việc, vì vậy một số lượng lớn sẽ rất cồng kềnh. Tuy nhiên, tôi không chắc chắn 100% về điều này, vì không có máy chủ nào của tôi có hơn một tá công việc. Trình lập lịch tác vụ của máy chủ 2008 trở lên cho phép tổ chức IMO dễ dàng hơn nhiều và nói chung có chức năng tốt hơn nhiều so với các phiên bản trước. Tôi chắc chắn các ứng dụng của bên thứ ba làm một công việc thậm chí còn tốt hơn. Tôi sẽ khóc nếu tôi phải sử dụng bộ lập lịch tác vụ của Server 2003 hoặc at.exe.

Sự cảnh báo thứ hai mà tôi có thể nghĩ đến sẽ có khả năng gây quá nhiều tải cho máy chủ SQL. The Agent là một chương trình nhỏ, nhưng chạy một nhiệm vụ dài hoặc phức tạp có thể dễ dàng tiêu tốn rất nhiều tài nguyên. Những tài nguyên đó sẽ không có sẵn cho công cụ SQL. Vì công cụ SQL được lập trình để chiếm khoảng 80% bộ nhớ hệ thống khả dụng, đây có thể là một vấn đề.

Thứ ba, sao lưu có thể là một vấn đề. Bạn sẽ không chỉ cần sao lưu hệ thống tệp mà còn cả cơ sở dữ liệu msdb để cho phép khôi phục các công việc (hoặc sử dụng một cái gì đó để kịch bản các tác vụ thành tệp văn bản). Điều này thêm một lớp phức tạp để khắc phục thảm họa.

Cuối cùng, bạn sẽ không muốn ở vị trí mà bạn đang trả tiền cho một giấy phép SQL Server chỉ để chạy SQL Server Agent. Nếu cơ sở dữ liệu ngừng hoạt động, bạn sẽ cần phát triển một kế hoạch di chuyển khỏi Tác nhân máy chủ SQL.

Ở công việc trước đây của tôi, tôi đã làm chính xác điều này, chủ yếu là vì tất cả các công việc đều chạy từ cụm chính, trung tâm của chúng tôi, là máy chủ dễ thấy nhất. Tôi có thể thấy tất cả các tác vụ theo lịch trình của chúng tôi ở một nơi thay vì phải kiểm tra công cụ dòng lệnh trên một loạt các máy chủ.

Mặc dù điều này chủ yếu là chủ quan (và sẽ rất khó để có được câu trả lời "đúng" trong định dạng này), tôi không nghĩ rằng có bất kỳ điều gì vốn đã sai với cách tiếp cận này ngoài việc nó trở thành một điểm thất bại duy nhất.

Điều đó có thể không liên quan nếu tất cả các tác vụ tương tác hoặc phụ thuộc vào máy chủ cơ sở dữ liệu đang hoạt động và các dịch vụ SQL Server đang chạy (trong trường hợp của chúng tôi, nó đã làm).

Ồ, và bạn cần thêm vào xử lý lỗi cho các trường hợp máy chủ nơi tác vụ cố chạy không hoạt động - điều bạn sẽ không phải làm nếu tác vụ được thiết lập trên máy chủ đó.

Tôi sẽ ~ có khả năng ~ đưa SQL Agent qua trình quản lý tác vụ windows ... rõ ràng cho các tác vụ liên quan đến cơ sở dữ liệu.

Nếu bạn hoàn toàn có thể viết mã hoặc có những người có thể viết mã, bạn có thể thực hiện khá nhiều với các ứng dụng bảng điều khiển và gói chúng vào một trình tạo dịch vụ như TopShelf (http://topshelf-project.com/) Đây có thể là một giá rẻ / dễ dàng hack để có được một chút tách rời từ SQL Agent cho mọi thứ và bắt đầu cũng cung cấp cho bạn một lớp để xếp hàng nếu bạn đang ở thời điểm đó.

Cá nhân, bạn dường như quan tâm đủ về điều này cũng như biết đủ về vấn đề của bạn mà tôi nghĩ bạn sẽ ổn. Đó là những người không quan tâm / biết rằng tôi thực sự lo lắng. Tôi chắc chắn rằng bạn sẽ đánh giá các giải pháp của bạn trong khoảng thời gian hợp lý và hành động phù hợp.

Một tùy chọn khác là tạo một bảng cho các tác vụ theo lịch trình với một thủ tục được lưu trữ để cập nhật bảng hàng đợi tin nhắn từ nó. Sau đó, Đại lý máy chủ SQL sẽ gọi thủ tục được lưu trữ thường xuyên để tạo thư và cập nhật trạng thái tác vụ. Các hệ thống khác sẽ truy vấn bảng hàng đợi thông qua kết nối SQL hoặc lớp API web dưới dạng JSON.