Nhà cung cấp muốn chạy công việc MSDB cứ sau 5 phút cho Ứng dụng doanh nghiệp

Chúng tôi có một nhà cung cấp bên thứ 3 đang cố gắng tích hợp 2 ứng dụng khác nhau trong đó cả hai DB đều cư trú trên phiên bản SQL Server của chúng tôi với hơn 150 DB khác và họ muốn tạo một công việc MSDB để "đồng bộ hóa" 2 ứng dụng khác nhau cứ sau 5 phút muốn chạy nó mỗi phút).

Linh cảm ban đầu của tôi là thay vào đó họ nên làm điều này bằng cách nào đó trong tầng Ứng dụng với một công việc được lên lịch của Windows, hoặc thậm chí là một trình kích hoạt đáng sợ (mà chúng ta thường sử dụng trong các tình huống như thế này).

Tôi thích giữ các công việc MSDB dành riêng cho các nhiệm vụ DBA càng nhiều càng tốt để giảm sự lộn xộn ở đó và cũng đã chạy vào truy vấn MSDB chậm khi xem lịch sử công việc với các công việc siêu tích cực như thế này (cũng nhấn chìm và bỏ lịch sử công việc quan trọng của những thứ quan trọng hơn như lịch sử sao lưu). Nhưng một lần nữa, có thể sở thích của tôi đã sai và tôi cần tạo một khoảng trống cho tầng Ứng dụng trong MSDB và xắn tay áo lên và khắc phục các sự cố về lịch sử công việc mất mãi mãi khi tôi cần giữ lại nhiều mục lịch sử hơn để nắm bắt những thứ quan trọng như sao lưu (hoặc thanh lọc các mục công việc siêu tích cực).

Một vấn đề khác mà tôi gặp phải là bây giờ tôi cần trao quyền "sysadmin" cho nhà cung cấp này thay vì chỉ quyền "dbo" đối với các DB của họ khi họ thực hiện nâng cấp thông qua GUI của họ và hy vọng họ không làm nổ tung trường hợp nhiệm vụ của tôi DB là (một trong những nhược điểm của hợp nhất).

Tôi đoán tôi có thể đặt chúng trên một ví dụ "cô lập", nơi chúng tôi đặt tất cả các nhà cung cấp mà không chơi đẹp, nhưng sau đó chúng ta cần phải cấu hình lại ứng dụng để trỏ đến các trường hợp SQL mới ( thở dài tiếc là không tầm thường trong trường hợp này).

Các nhà cung cấp đã đẩy lùi mối quan tâm của tôi nói về việc kích hoạt xấu như thế nào. Vì vậy, tôi "googled" về điều này một chút và đến trống rỗng. Có ai nhìn thấy bất kỳ liên kết ngoài đó "tìm kiếm có thẩm quyền" rằng đây là một ý tưởng tồi và tôi có thể giới thiệu họ với nó? Hay tôi nên nắm lấy cách tiếp cận của họ?

Tôi không tin rằng tôi đã từng đăng bài trên một diễn đàn sql trước khi yêu cầu giúp đỡ, vì vậy hy vọng yêu cầu của tôi được đóng khung đúng cách.

EDIT: Chúng tôi đang chạy SQL Server 2008 Enterprise R2 x64 SP1 (Cảm ơn bạn đã chỉ ra rằng tôi quên đề cập đến phiên bản!). Hmmm, hy vọng họ không cần thay đổi tập lệnh nâng cấp MSDB khi chúng tôi chuyển sang phiên bản mới hơn.

Cảm ơn vì đã dành thời gian cho tôi! Giàu có

IMO nhà cung cấp của bạn thực sự đang đi đúng hướng.

Một công việc của lớp ứng dụng sẽ yêu cầu anh ta làm lại rất nhiều tính năng Đại lý SQL bên ngoài (ví dụ: logic không chạy một công việc đang chạy, đưa ra giải pháp lưu trữ bảo mật và thông tin xác thực, tích hợp kết quả công việc với báo cáo lỗi và theo dõi kết quả trong SQL, v.v ... vv). Và, quan trọng nhất, cung cấp một giải pháp sao lưu / HA / DC để lập lịch. Bạn không muốn câu chuyện khắc phục thảm họa của mình là 'và sau khi bạn khôi phục xong máy chủ dự phòng, hãy tạo 50 tác vụ lên lịch NT này'. Vì vậy, anh ta đã đúng khi đẩy lùi việc sử dụng bộ lập lịch hệ thống, nó không có tính năng và khả năng nào mà Đại lý có.

Anh ta thậm chí còn đúng hơn trong việc đẩy lùi chống lại các tác nhân. Thay thế một công việc định kỳ bằng trình kích hoạt đồng bộ làm tăng độ trễ yêu cầu, tăng sự gắn kết và khớp nối (nghĩ thay đổi lược đồ ...), tăng rủi ro thời gian chết do vấn đề đồng bộ hóa (lỗi kích hoạt-> lỗi ứng dụng so với lỗi công việc-> sửa lỗi và thử lại sau) , làm tăng đáng kể các vấn đề bế tắc (do cập nhật chéo giữa theo dõi / trackee) và có nhiều vấn đề khác.

Giải pháp đơn giản nhất thực sự là một công việc Đại lý, và msdbkhông có nghĩa là dành riêng cho các DBA. Một giải pháp thú vị hơn là sử dụng bộ hẹn giờ hội thoại và kích hoạt bên trong , điều này sẽ có một số lợi thế so với công việc Đại lý, chủ yếu là do ngăn chặn (mọi thứ đều nằm trong ứng dụng DB, nghĩ rằng phản ánh kịch bản chuyển đổi dự phòng), nhưng tôi hoàn toàn có thể hiểu nếu nhà cung cấp của bạn là miễn cưỡng thử một cái gì đó đòi hỏi một bí quyết rất cụ thể. BTW tôi hy vọng bạn không có nghĩa là một công việc mỗi 5 phút mỗi DB .

Đối với quyền sysadmin: tên của trò chơi là ký mã . Bạn có thể cho phép bất kỳ thủ tục cụ thể nào, được bạn kiểm tra và xác nhận, bằng cách ký chúng với chứng chỉ riêng của bạn.

Sở thích cá nhân của tôi sẽ là sử dụng các kích hoạt để xử lý ít nhất một phần của đồng bộ hóa. Tôi không đặc biệt quan tâm đến việc đồng bộ hóa bỏ phiếu theo lịch trình, vì bạn phải giải quyết các xung đột tiềm ẩn, dữ liệu cũ, tác động hiệu suất của công việc lặp lại, v.v. Nếu họ muốn thực hiện nó mạnh mẽ từ 1 đến 5 phút, tôi đoán đó là để giảm thiểu xung đột và sự cứng nhắc, và tính trực tiếp của một kích hoạt sẽ giải quyết điều đó.

Nếu tất cả đều xảy ra trong cùng một máy chủ, có lẽ bạn sẽ ổn khi đặt mã đồng bộ hóa trong các kích hoạt hoặc yêu cầu kích hoạt gọi một thủ tục được lưu trữ để đồng bộ hóa từng bản ghi bị ảnh hưởng. Nếu đồng bộ hóa mở rộng máy chủ hoặc bạn muốn đảm bảo rằng có một cơ sở dữ liệu ngoại tuyến sẽ không ngăn cơ sở dữ liệu khác có thể sử dụng được, hãy xem xét sử dụng Dịch vụ môi giới để xử lý các cập nhật không đồng bộ. Tôi đã thực hiện điều này để đồng bộ hóa số liệu nhập doanh số với dữ liệu CRM giữa hai máy chủ khác nhau, đồng thời cho phép một trong hai máy chủ được ngoại tuyến mà không ảnh hưởng đến ứng dụng khác. Khi nó hoạt động trở lại, Service Broker sẽ gửi tin nhắn và cập nhật dữ liệu trên máy chủ từ xa.

Và thực sự không có gì xấu về các trình kích hoạt, nhưng giống như hầu hết các khía cạnh của T-SQL, rất có thể viết mã thực hiện khủng khiếp. Tôi đã viết một bài viết về những cạm bẫy phổ biến của các kích hoạt, nếu điều đó giúp bất kỳ.

Viết Triggers cư xử tốt