Tôi thường thấy "sự cố" liên quan đến các yêu cầu đối với SQL Server để thực hiện "công việc bẩn thỉu" như:
- Trong trình kích hoạt của mình, tôi cần sao chép tệp vào / từ mạng
- Thủ tục đã lưu trữ của tôi cần FTP một tệp
- Sau khi quá trình sao lưu kết thúc, tôi cần SQL Server nén nó, tạo một bản sao rồi lưu trữ nó
- Khi một khách hàng được thêm vào, tôi muốn tạo một cơ sở dữ liệu mới và thực hiện nhiều thứ trong Active Directory
- Công việc SQL Server Agent của tôi cần quét thư mục để tìm tệp và thực hiện chèn hàng loạt khi tìm thấy tệp mới
Đây không phải là một danh sách đầy đủ; Tôi có thể điền vào một trang. Vấn đề là việc thực hiện các tác vụ này từ bên trong SQL Server gây ra những trở ngại đáng kể:
Bảo mật
Thông thường, đối với bất kỳ thứ gì mà bạn cho là SQL Server cần hệ thống tệp hoặc quyền truy cập cấp hệ điều hành khác, bạn sẽ (a) cấp quyền rõ ràng cho tài khoản dịch vụ SQL Server (và / hoặc tài khoản SQL Agent / proxy), hoặc (b) chỉ cần đặt các tài khoản dịch vụ SQL Server để chạy như một tài khoản miền hiện có đã có tất cả các quyền đó. Đây là giải pháp "dễ dàng" - giờ đây, thay vì cấp cho từng cá nhân quyền truy cập vào thư mục này và phần chia sẻ và tài nguyên khác này, bạn chỉ cần lau tay vì họ đã là quản trị viên miền. Tiếp theo, bạn bật cài đặt cấp máy chủ bị tắt theo mặc định nhưng vẫn cản trở bạn hoàn thành một hoặc nhiều tác vụ ở trên (ví dụ:xp_cmdshell ).
Tôi không nghĩ mình phải giải thích mức độ tiếp xúc mà những hành động này có thể thể hiện. Hoặc những loại vấn đề nào có thể xảy ra nếu đây là tài khoản nhân viên thực tế và nhân viên đó bỏ đi - hoặc xác định rằng anh ta / cô ta không hài lòng trước khi họ rời đi. Rất tiếc. Tôi đã gặp một số trường hợp trong đó một tài khoản chung được sử dụng cho tất cả các Máy chủ SQL. Đoán xem điều gì sẽ xảy ra nếu / khi bạn cần thay đổi mật khẩu cho tài khoản miền đang được sử dụng tích cực bởi hàng chục hoặc hàng trăm phiên bản SQL Server? Đừng bận tâm về tần suất nó sẽ xảy ra nếu bạn không loại trừ người dùng đó khỏi các chính sách đặt lại mật khẩu?
Hiệu suất
Ngoài các vấn đề bảo mật, việc ra ngoài máy chủ cơ sở dữ liệu có thể gây ra sự chậm trễ trong khi SQL Server dựa vào một số quy trình bên ngoài mà nó không thể kiểm soát được. Giao dịch cơ sở dữ liệu có thực sự cần đợi một tệp được nén và sao chép, hoặc để quá trình chuyển FTP hoàn tất hay để bộ điều khiển miền dự phòng của bạn phản hồi? Làm thế nào để kết hợp này khi một số người dùng đang thực hiện các tác vụ tương tự, tất cả đều cạnh tranh cho cùng một băng thông và / hoặc đầu đĩa? Ngoài ra, bạn phải xem xét rằng một khi SQL Server đã yêu cầu một số tệp hàng loạt thực hiện điều gì đó, thì giao dịch chứa sẽ được khôi phục lại, bạn không thể khôi phục lại hành động bên ngoài.
Câu trả lời
Chà, thông thường - và luôn có ngoại lệ - câu trả lời là sử dụng các quy trình bên ngoài cho các tác vụ thực sự bên ngoài SQL Server này. Sử dụng PowerShell, sử dụng C #, sử dụng tệp hàng loạt; heck, sử dụng VBScript. Hãy nghĩ xem những tác vụ nào trong số này thực sự cần được xử lý * ngay lập tức * và trong khi giao dịch vẫn đang hoạt động - tôi nghi ngờ là không nhiều. Xây dựng một bảng hàng đợi cho những thứ này và ghi vào bảng hàng đợi bên trong giao dịch (bảng này sẽ được cuộn lại nếu giao dịch không thành công). Sau đó, có một nhiệm vụ nền hoặc tập lệnh sử dụng các hàng từ bảng hàng đợi, thực hiện (các) nhiệm vụ được liên kết và xóa hoặc đánh dấu mỗi hàng là đã hoàn thành. Phần thưởng đã thêm:Không yêu cầu SQL Server Agent ở đây, vì vậy bạn có thể sử dụng bất kỳ bộ lập lịch doanh nghiệp nào và phương pháp này vẫn hoạt động với SQL Server Express.
