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



我正在寻找SQL Server代理作业的替代方案-需要控制进程(可执行文件,"作业")的运行和调度,因此我打算实现一个Windows服务,作为这些进程的调度程序。

这些进程不是交互式的,因此从Windows服务启动它们没有问题,但它们需要与SQL Server一起工作——读取和写入数据、执行存储过程等。

到windows服务("调度程序")的命令(如"将作业排入队列")将从UDF中的SQL Server CLR传递,或通过WCF直接从客户端web应用程序传递(尚未决定)。

这样做对吗?是否有任何访问和安全问题需要我注意?我特别担心从windows服务运行的进程可能受到限制。

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

此外,我考虑使用SQL Server Service Broker(在类似的线程中建议使用),但我不确定它是否符合我的需求。

谢谢!Adam

实现合理安全级别的正确方法是:

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

要实现服务,您必须注意以下几点:

  • 如果使用WCF(或任何其他服务堆栈),则需要一个线程来侦听请求,并需要一个不同的线程来运行SQL server中的进程。否则,后续请求可能会超时。(您可以为每个任务启动新线程,或者实现一个队列以避免服务器过载)
  • 在处理错误(异常)时要格外小心。如果引发未处理的异常,您的服务将停止,直到有人再次启动为止
  • 实现UDF解决方案比较困难,因为您需要修改SQL Server安全设置以允许UDF与"外部世界"通信
  • 您应该在服务中包含某种类型的日志记录,这样您就可以测试它并验证它是否正常工作

制作一个可以作为控制台应用程序和服务运行的可执行文件并不困难。如果你这样做了,你可以从VisualStudio调试器运行它,或者单独运行,并登录控制台(Console.Write...(...)),看看发生了什么

最新更新