如何最小化或通知用户数据库连接滞后/失败？答案

【问题标题】：How do I minimize or inform users of database connection lag / failure?如何最小化或通知用户数据库连接滞后/失败？
【发布时间】：2013-09-05 02:54:08
【问题描述】：

我正在维护一个 ASP/C# 程序，该程序使用 MS SQL Server 2008 R2 来满足其数据库要求。

在正常和完美的日子里，一切正常。但我们并不生活在一个完美的世界中。

申请（请假、病假、加班、加班等）审批流程最多需要十个独立的数据库连接。该程序连接到数据库，传递一些相关参数，并使用存储过程来完成这项工作。十次。

现在，由于整个事物的结构，我无法更改，连接中的下降，或者见鬼，如果我在 VS2005 中放置一个调试点并让它挂在那里足够长的时间，应用程序批准流程就会进行不完整。这些表通常只是连接在一起，因此数据不匹配（此处缺少数据，此处无法更新主键）意味着整行将无用。

现在，我知道我无法阻止这种情况发生 - 毕竟这是一个连接问题。

但是有没有办法最大限度地减少连接延迟/失败？或者是一种通知用户流程出现问题的方法？回滚更改功能（通过程序或 SQL），以便撤消数据库中任何不完整的数据？

谢谢。

【问题讨论】：

又是什么问题？
配置文件/优化（执行计划、跟踪和调优顾问是基本的，但可以有很长的路要走）以提高性能。目前尚不清楚您是否正在使用事务，但如果您没有使用，它们是确保流程不会失败和留下工件的高效方法。
@O.O，如果不清楚，抱歉。更新了问题。
@TimMedora，程序只是连接数据库，传递一些参数，然后执行存储过程。可能不使用事务 - 实际上直到现在才听说过。
一定要查看事务，使用System.Transactions.TransactionScope 或在您的存储过程中。事务是一种“全有或全无”的机制，即它们确保整个操作成功或回滚。 SQL Server 为您完成所有工作。

标签： c# asp.net sql-server visual-studio-2005

【解决方案1】：

但是有没有办法最大限度地减少连接延迟/失败？或者一种方法通知用户流程出现问题？一种回滚更改功能（通过程序或 SQL），以便任何数据库中不完整的数据会被撤消吗？

正如我们在 cmets 中所讨论的，事务将解决您的许多问题。

事务包括在数据库中执行的工作单元针对数据库的管理系统（或类似系统），并处理以独立于其他交易的连贯可靠的方式。数据库环境中的事务有两个主要目的：

提供可靠的工作单元，允许从故障中正确恢复并保持数据库一致，即使在系统出现故障的情况下失败，当执行停止（完全或部分）并且许多对数据库的操作仍未完成，状态不明确。

在同时访问数据库的程序之间提供隔离。如果没有提供这种隔离，程序的结果可能是错误的。

_Source

.Net 中的交易

如您所料，数据库对于为数据库相关操作提供事务支持是不可或缺的。但是，从业务层创建事务非常简单，并且允许您在多个数据库调用中使用单个事务。

引用我的回答here：

我看到了从业务层控制交易的几个原因：

跨数据存储边界的通信。事务不必针对 RDBMS；它们可以针对各种实体。
基于业务逻辑回滚/提交事务的能力可能不适用于您正在调用的特定存储过程。
在单个事务中调用任意一组查询的能力。这也消除了对事务计数的担忧。
个人偏好：c# 具有更优雅的交易声明结构：using 块。相比之下，我总是发现存储过程中的事务在跳转到回滚/提交时很麻烦。

事务最容易使用 TransactionScope (reference) 抽象来声明，它为您完成了艰苦的工作。

using( var ts = new TransactionScope() )
{
    // do some work here that may or may not succeed

    // if this line is reached, the transaction will commit. If an exception is
    // thrown before this line is reached, the transaction will be rolled back.
    ts.Complete();
}

由于您刚刚开始处理事务，我建议您从 .Net 代码中测试事务。

调用执行 INSERT 的存储过程。
在 INSERT 之后，故意让程序产生任何类型的错误。
您可以通过查看 INSERT 已自动回滚来验证您的实施。

数据库中的交易

当然，您也可以在存储过程（或任何类型的 TSQL 语句）中声明事务。 See here 了解更多信息。

【讨论】：

TransactionScopes 如果 DB 和 Web 应用程序位于不同的机器上，则非常讨厌，尤其是在 Web 应用程序被外部化的情况下。有许多安全团队，如果它是一个选项，你会很幸运。内化的应用程序可能会更好。
怎么样？（对你的经验感到好奇）我经常在机器上使用它们而没有问题（也有一些设置经过审核）。在某些情况下需要 DTC，但这可以相当容易（且安全）地设置。除了提供数据库（或其他事务感知实体）可以使用的跟踪/同步机制之外，事务范围并没有做太多事情。
是的，这是 DTC 的问题。我认为我们的问题是信任授权。在一个案例（A 公司）中，我们托管在其他人的服务器上——一切都在本地运行良好，但生产不支持这一点，安全团队也没有实施它的计划。 B 公司刚刚表示这非常令人头疼（可能是由于数据的敏感性及其大小），以至于它甚至都不是一个选择。我不知道细节。我确实喜欢这个想法，因为它可以处理多个 sql 事务，但最终他们认为它要么不安全，要么成本太高，让人头疼。
好吧，这更有意义。如果您可以控制环境（以及熟悉 Windows 管理员的人），那么 DTC 并不是什么大问题。我不认为真的存在安全风险，因为网络中没有数据传递，只有交易元数据。此外，仅在特定情况下（通常在较大的分布式应用程序中）才会升级到 DTC。不过，我可以看到它是如何成为绊脚石的。
@ps2goat，怎么会这样？是否存在性能/安全问题？ Web 应用程序和数据库服务器位于不同的机器上，但位于相同的位置和相同的网络/域。但是，许多其他子公司通过网络应用访问它，而且它们通常不在同一个位置。

【解决方案2】：

如果您使用相同的 SQLConnection 或其他实现 IDbConnection 的连接类型，您可以执行类似于事务范围的操作，但无需创建事务范围的安全风险。

在 VB 中：

Using scope as IDbTransaction = mySqlCommand.Connection.BeginTransaction()

   If blnEverythingGoesWell Then
      scope.Commit()
   Else
      scope.Rollback()
   End If

End Using

如果不指定commit，则默认回滚事务。

【讨论】：