在我的连接断开的情况下运行SQL命令? (SQL Server)

时间:2011-03-10 18:29:00

标签: sql sql-server disaster-recovery

以下是我的假设计划所发生的一系列事件......

  1. 打开与服务器的连接。
  2. 运行UPDATE命令。
  3. 离开并做一些可能需要花费大量时间的事情。
  4. 运行另一个UPDATE以反转步骤2中的更改。
  5. 关闭连接。
  6. 但是哦 - 不!在步骤3中,运行该程序的机器实际上爆炸了。查询同一数据库的其他机器现在会认为已爆炸的机器仍在工作并正在做某事。

    我想做的是,就像打开连接一样,但在进行任何更改之前,告诉服务器该连接应该因为某种原因而关闭,以运行一些SQL。这样,我可以肯定,如果出现问题,关闭更新将会运行。

    (为了抢先回答,我不是在寻找表/记录锁或交易。我这里没有做资源索赔。)

    非常感谢,billpg。

3 个答案:

答案 0 :(得分:1)

我不确定内置了什么,所以我认为你必须做一些定制的东西......

这完全是假设的,直接在我的头顶,但是:

  1. 获取您的连接的SPID 打开并存放在某个温度中 表,与逆转的文本 更新
  2. 使用后台进程(或者 SSIS或其他东西)来监控 临时表并检查 SPID仍然作为开放连接存在。
  3. 如果连接中断,则后台进程可以执行存储的还原命令
  4. 如果连接正确完成,则可以从临时表中删除SPID,以便后台进程在连接关闭时不再还原它。
  5. 欢迎评论或改进!

答案 1 :(得分:1)

我会扩展我的评论。一般来说,我认为你应该重新考虑你的方法。所有数据库访问代码都应该打开一个连接,执行查询然后关闭依赖连接池的连接,以减少打开大量数据库连接的开销。

如果我们正在讨论单个SQL命令,其操作的行不应该更改,那么这是一个应该由事务隔离级别处理的问题。为此,您可以调查SQL Server 2005 +中的Snapshot隔离级别。

如果我们讨论的是一系列长期运行事务的查询,那就更复杂了,可以通过存储其他连接读取的事务状态来处理,以确定它们是否可以继续。走这条路,您需要为用户提供可以取消可能不再适用的长期交易的工具。

答案 2 :(得分:0)

假设它甚至可能......只有在交易期间客户端机器爆炸时,这才会对您有所帮助。此外,还存在误报的风险 - 由于网络噪音,连接可能会丢失几秒钟。

我采取的方法是在另一台机器上启动一个进程,该进程定期ping第一台机器以检查它是否仍在线,然后在无法访问时采取措施。