小编Eri*_*gum的帖子

所以我确定我的 SQL Server 的不稳定行为是因为 .Net SqlClient 数据提供程序的默认设置SET ARITHABORT OFF. 话虽如此，我已经阅读了各种文章，这些文章讨论了实现这一点的最佳方式。对我来说，我只是想要一个简单的方法，因为 SQL Server 正在遭受痛苦，而且我的查询调优还没有完全超越整个应用程序（显然SET在 sp 中添加是行不通的）。

在 Erland Sommarskog关于该主题的精彩文章中，他基本上建议采取安全的方法，通过更改应用程序来发出SET ARITHABORT ON连接。但是，在 dba.stackexchange question 的这个答案中，Solomon Rutzky提供了实例范围和数据库范围的方法。

设置此实例范围内我在这里遗漏了什么后果？正如我所看到的......因为SSMSON默认设置了这个，我认为ON为所有连接设置这个服务器范围没有坏处。归根结底，我只需要这个 SQL Server 来执行高于一切。

我猜想在 SQL Server 2017 中使用数据库邮件仍然需要 .NET Framework 3.5？因为不久前我不得不将它包含在我在 Server 2016 上安装的 SQL Server 2016 中。

我无法通过网络找到明确的答案，令人惊讶的是，也许它没有说。

我在网上搜索了一段时间，但没有找到我满意的答案。我正在提供新光盘的 VM 上测试 SQL Server。

如果磁盘延迟减少，吞吐量不应该增加吗？磁盘延迟和吞吐量之间是否存在直接关联？似乎如果我有更快的磁盘，我应该会看到吞吐量的增加。

对于作为存储过程一部分的 UPDATE 语句，我在测试/生产之间看到 2 个非常不同的查询计划。显然表大小不同（大约有 1000 万行差异）。基本上区别在于 Prod 我看到一组昂贵的排序，然后是索引更新（nc 索引）

而在测试中，我根本没有看到这些运算符集！只有聚集索引更新。我已经验证了 NC 索引存在等等。我不知道发生了什么？！我已经验证了索引、sp，我试过重新编译，参数的不同值等等。肯定有我遗漏的东西，我什至检查了约束，一切都匹配。

有什么想法吗？我以前从未见过这个。SQL 是否只是抓住了一个糟糕的执行计划！？

UPDATE 的结构是这样的：UPDATE [tablename] SET [column]=123 FROM ...

以下 Prod 计划中的额外运算符（减去聚集索引更新）：

有人能告诉我这个选项实际上做了什么，如果我在一个既定的生产环境中突然取消选中它会产生什么影响？

系统管理员为我提供了一个特定的域帐户来处理备份。我有点困惑，因为我过去从未获得过单独的域帐户来处理备份。我仍然想使用 Agent 来处理这个问题，所以我认为他们正在考虑以下问题：

如果您在代理帐户下运行作业，则代理必须是域帐户。将该帐户添加到 sysadmin 服务器角色并授予它对目录和网络共享的完全控制权。

所以我已经完成了我认为上面描述的事情，我添加了域帐户作为登录名，我创建了一个凭证和代理，并且我将作业步骤创建为 CmdExec 以在代理下运行，但我仍然得到：

操作系统错误 5（访问被拒绝。）。

直到我授予对运行 SQL Server 服务的服务帐户的访问权限后，我才能备份到此网络共享。我还担心恢复，我想利用代理来处理清理任务并将文件随着时间的推移移动到各个目录。

所以我不确定这里发生了什么，但我认为服务帐户至少需要写访问权限？一位系统管理员说他知道有人将备份过程作为“单独的服务”进行，我不太明白，除非它像 ApexSQL 备份之类的东西......

我的任务是通过 t-sql 将 SQL Server 中保存的图像（作为 varbinary）提取到平面文件中。我已经有十多年没有做过 ETL 工作了，除了使用 sp_OACreate、sp_OAMethod 等之外，我不记得通过 t-sql 执行此操作的任何其他方法。

是否有一些新方法可以解决这个问题？更“可靠”并且不需要打开 OLE 自动化程序并做所有这些疯狂的事情的东西？

这将是一个持续的过程。不是一次性运行。