生产环境中无法解释的 SQL 错误 - 可能与网络有关

Question

我正在做一些相当密集的数据库工作，并最终在数据库中插入了很多很多记录。为了尽量减少上下文膨胀，我一次插入 100 个，处理上下文，然后重新创建上下文。

我遇到了一些我不明白的奇怪错误。这些错误只发生在我们的生产服务器上，但在开发服务器上一切正常。如果有人能阐明他们认为可能存在的问题，我将不胜感激。

System.Data.Entity.Core.EntityCommandExecutionException：执行命令定义时出错。有关详细信息，请参阅内部异常。

System.Data.SqlClient.SqlException：从服务器接收结果时发生传输级错误。 （提供者：TCP Provider，错误：0 - 信号量超时期限已过。）

System.ComponentModel.Win32Exception：信号量超时期限已过

System.Data.SqlClient.SqlException (0x80131904)：从服务器接收结果时发生传输级错误。 （提供者：TCP Provider，错误：0 - 指定的网络名称不再可用。）

System.ComponentModel.Win32Exception (0x80004005)：指定的网络名称不再可用

System.Data.Entity.Infrastructure.CommitFailedException：提交数据库事务时报告错误，但无法确定事务在数据库服务器上是成功还是失败。有关更多信息，请参阅内部异常和 http://go.microsoft.com/fwlink/?LinkId=313468。 > System.Data.SqlClient.SqlException：从服务器接收结果时发生传输级错误。 （提供者：TCP Provider，错误：0 - 指定的网络名称不再可用。）

System.ComponentModel.Win32Exception: 指定的网络名称不再可用`

System.Data.Entity.Core.EntityException：引发了一个异常，可能是由于暂时性故障。如果要连接到 SQL Azure 数据库，请考虑使用 SqlAzureExecutionStrategy。

System.Data.Entity.Core.EntityCommandExecutionException：执行命令定义时出错。有关详细信息，请参阅内部异常。

System.Data.SqlClient.SqlException：向服务器发送请求时发生传输级错误。 （提供者：TCP Provider，错误：0 - 现有连接被远程主机强行关闭。） -

System.ComponentModel.Win32Exception: 现有连接被远程主机强行关闭

这些错误在过程中发生的时间是完全随机的（我有一个计数器告诉我在哪里）。查找这些错误，看起来好像是网络错误。我无权访问我的数据库服务器日志，所以我无法查看那里。我的网络服务器日志对正在发生的事情没有任何启示。任何帮助都会很棒。

编辑：

我没有运行 Azure。

我也遇到很多主键违规错误：

System.Data.Entity.Infrastructure.DbUpdateException：更新条目时出错。有关详细信息，请参阅内部异常。

System.Data.Entity.Core.UpdateException：更新条目时出错。有关详细信息，请参阅内部异常。

System.Data.SqlClient.SqlException：违反主键约束“PK_dbo.MissileDataReferences”。无法在对象“dbo.MissileDataReferences”中插入重复键。重复键值为 (4277, 2, 448388)。

Answer 1

很烦人不是吗？是的，您可以在任何高流量网站上获得这些。

这似乎是微软在 SQL Azure 中引入 Azure 重试策略的原因。您希望即使是他们也能保证他们的网站和他们在同一网络上的同一数据中心中的数据库之间的连接。但他们不能。

您可以为 Azure 打开此功能（您没有说您是否使用 Azure，但我怀疑不是）。请参阅https://docs.microsoft.com/en-us/azure/sql-database/sql-database-connectivity-issues 了解所需的连接字符串更改。

https://msdn.microsoft.com/en-us/library/dn456835(v=vs.113).aspx 还涵盖了 Azure 上的 EF6。

也许这不是您想要的答案，但我认为您应该考虑使用 Polly library，因为它使您能够为每个命令显式设置重试逻辑。

您为什么不想为每次调用都执行此操作（以节省每个命令的编码重试）？好吧，过去我遇到过很多问题，我们重试了插入等的逻辑，但片刻后又重复了一遍（导致主键违规），因为响应没有返回给客户端。

因此，仅对安全的“只读”调用执行此操作，如果您必须对写入进行重试，请放置处理程序以检测重复插入，然后与服务器再次核对并询问用户他们想要做什么。