运行从Windows服务与SQL Server交互的进程 - 替代SQL Server代理作业

Question

我正在寻找SQL Server代理作业的替代方案 - 需要控制进程的运行和调度（可执行文件，“作业”），因此我打算实现一个Windows服务，它将充当这些作业的调度程序过程

这些进程不是交互式的，因此从Windows服务启动它们没有问题，但它们需要使用SQL Server - 读取和写入数据，执行存储过程等。

Windows服务命令（“调度程序”） - 如“排队作业” - 将从UDF中的SQL Server CLR传递，或者直接从客户端Web应用程序通过WCF传递（尚未决定）。

这是一种正确的方法吗？我应该注意哪些访问和安全问题？我特别担心从Windows服务运行的进程可能存在限制。

请分享您使用类似设计的经验。

另外，我考虑使用SQL Server Service Broker（在类似的线程中提出），但我不确定它是否符合我的需求。

谢谢！ 亚当

Answer 1

达到合理安全级别的正确方法是：

• 创建一个将运行Windows服务的新用户（您可以在控制面板中创建此用户）
• 在SQL Server中创建此用户的新登录名（使用集成安全性）
• 在SQL Server
中为此用户提供必要但最低限度的权限

要实施服务，您必须了解以下几点：

• 如果您使用WCF（或任何其他服务堆栈），则需要一个用于侦听请求的线程和一个不同的线程来运行SQL Server中的进程。如果没有，后续请求可能会超时。 （您可以为每个任务启动新线程，或实现队列以避免服务器过载。）
• 对错误（异常）处理要非常小心。如果抛出未处理的异常，您的服务将停止，直到有人再次启动它
• 实施UDF解决方案更加困难，因为您需要修改SQL Server安全设置以允许UDF与“外部世界”进行通信
• 您应该在服务中加入某种日志记录，以便进行测试并验证其是否正常工作。

make an executable that can be run as console app as well as as a service并不难。如果这样做，您可以从Visual Studio调试器运行它，或者单独运行，并登录控制台（Console.Write...(...)），看看发生了什么。