小编Mol*_*pad的帖子

作为更广泛的收购项目的一部分，我刚刚继承了大约 20 个 SQL Server 实例。我正在评估性能，我不喜欢维护计划的实施方式。

我每天都在看到全面的索引重建（我可以处理这个）以及每天手动更新统计数据。

大约一半的数据库已设置为 Auto Update Statistics = False，原因尚不清楚，除了我被告知是为了减少“性能问题”...

我一直认为并致力于将其设置为 True 的最佳实践，并认为如果此设置为 True，则不需要手动更新。我错了吗？

任何人都可以解释将此设置为 False 的好处是什么，而是每天进行手动更新？

我应该提到一些数据库是高度事务性的（每天数百万次插入、删除、更新），其他数据库在事务率方面很低，有些几乎是只读的。虽然没有押韵或理由将自动更新设置设置为 False。好像是彩票。

我构建了一个在静态端口 50101 上运行的命名实例。

网络人员已打开防火墙上的端口以允许传入连接。我也要求他们打开 UDP 端口 1434，因为我相信 SQL 浏览器服务在此端口上运行，并且需要将命名实例的正确端口传递回请求连接。即使命名实例在静态 TCP 端口上运行。

那是对的吗？

SQL Browser / UDP 1434 不只是用于动态端口，对吧？

如果连接字符串中的端口不是明确的，它需要打开吗？

真的需要结束这场争论！

议员

这主要是理论上的，但如果将来发生这种情况，我希望有一个记录的选项列表。

今天，我们在 SAN 上遇到了一个严重的磁盘错误，这意味着保存我们一个生产实例的事务日志文件的磁盘崩溃了，最初看起来它已经死了。显然，实例、数据库以及在其上运行的应用程序都会下降。

我们的数据中心人员正忙着研究磁盘故障的原因、原因和方式，同时我很快就想出了一个数据库恢复选项列表。

好的，所以数据中心的人恢复了磁盘。这是 VPLEX 错误，而不是物理硬件故障。

但同时我发现我没有很多选择。考虑到 Sys 和 User 数据库的所有日志文件都无法访问，该实例将无法启动。如果 Sys 数据库日志文件位于“已启动”的单独磁盘上，实例是否会重新启动

我可以访问 .mdf 文件，所以我可以选择将它们复制到另一台服务器，然后将它们与另一个卷上的新日志文件附加在一起。要么使用我们相当有弹性的备份将数据库还原到另一台服务器\实例。任何一种选择都意味着适用于应用程序人员，因为所有应用程序和相关服务都需要重新指向。

我还有另一种选择，即删除服务器上的实例并使用相同的实例名称重新安装它，然后从完整的广告日志备份中恢复所有数据库。从理论上讲，这意味着 App 团队没有工作，但对我（唯一的 DBA）来说却有严重的时间开销。

我在这里缺少任何选项吗？我最近才开始这项工作，可以说这里的文档有限。在过去的几个月里，我一直忙于整理 SQL Estate 的清单，查看修补/​​升级差距等，并参与了多个项目。我认为可以公平地说，针对此类场景的记录在案的灾难恢复计划现在是我们层次结构议程的首要任务。

任何帮助表示赞赏。

我熟悉 SQL Server 的数据库加密选项，例如 TDE，并确保正确加密和保护备份/备份位置。

我正在为一个新客户做一些工作，他要求我详细说明端到端加密的选项，换句话说，以确保从数据库服务器发送到应用程序服务器的数据在途中保持加密并且无法被拦截（或者更确切地说，解释) 通过任何类型的数据包监控。

我知道使用 SSL 证书来加密与数据库的连接，尽管我很少配置它。我真的不知道这是否是端到端加密的合适选项，因为这肯定不能单独使用 SQL Server 进行配置？

在我看来，应用程序端或网络路由上必须有一些东西可以实现这样的端到端加密？

我对网络安全的了解基本上仅限于防火墙规则和一般路由，因此我正在寻找可供我进一步研究或付诸实践的选项。

我担心这个问题会被关闭，因为它是基于意见的，所以我真的要求在 SQL Server 本身（或在 DBA 的职权范围内）提供可靠的选项来配置端到端的数据加密。

我正在对我们的一个 SharePoint 数据库的问题进行故障排除，我认为 PLE 的大幅下降主要是由于 I/O 活动增加（我同时看到读取、写入和延迟写入增加）

此时的缓冲区缓存命中率通常为 96%。

Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) 2012 年 10 月 19 日 13:38:57 版权所有 (c) Microsoft Corporation Enterprise Edition：Windows NT 6.2（Build 9200：）上的基于核心的许可（64 位）（管理程序）

我想在 PLE 删除的确切时间检查缓冲区缓存的大小，所以我正在运行以下查询，我认为它以 MB 为单位给出了大小：

DECLARE @total_buffer INT;

SELECT @total_buffer = cntr_value
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Buffer Manager%'
AND counter_name = 'Database Pages'

SELECT ((@total_buffer * 8) / 1024) AS CacheSizeMB

我看到的大小没有意义（对我来说，我的意思是），通常为 250-350MB。我希望我会看到一个大尺寸，然后我可以检查哪些表在缓存中的页面最多，这有望引导我找到哪些 LOB 对象正在被检索/上传，从而导致问题。

我还需要查看计划缓存吗？即 PLE 丢弃可能是由一些繁重的表扫描引起的吗？

SQL Server 从可用的 16GB 分配了 12GB 的 …

我有一个包含 850GB MDF 文件的数据库。在 20 个月的过程中，应用程序中的日志记录机制创建了各种巨大的表。原本只应该在任何时候保留一周数据的维护脚本没有正确执行（现在是），所以我们不得不手动清理。

我们实际上清除了大约 600GB 的数据。我想释放一些空间，因为它所在的驱动器接近极限。数据文件永远不会再变得这么大，所以它只是浪费了空间。

我打算使用 SHRINK-FILE 来处理这个问题。我已经对数据库的克隆进行了测试，大约需要 3 个小时。数据库上似乎没有任何性能下降。是的，之后索引非常碎片化，但我可以对它们进行排序。

我的问题是这样的：

应用程序需要在整个过程中保持“正常运行”，因为它至关重要。我知道 SHRINKFILE 操作是一个完全在线的操作，还是我错了？

数据库几乎每秒都会发生大量写入活动。

SHRINKFILE 操作导致的 I/O 增加会影响这些写入吗？

反过来说，连续写入是否会影响 SHRINKFILE 操作，即使其完成更慢？

最后，有没有更好的方法来做到这一点？

更新

仅供阅读本文的任何人使用 - 我运行 SHRINKFILE 并监控 I/O 和 CPU。我的高每秒写入数的数据库在这两个方面都略有上升，但完全没有延迟问题。在 1.5 小时的 SHRINK 操作过程中，它一直保持正常运行、稳定且无故障。

之后索引非常碎片化，这让应用程序的报告端有点难过（图形在客户端应用程序上呈现速度很慢），但稍后重建在线索引，一切都恢复正常。

我们的一个应用程序导致了一个问题，因为有一个存储过程在 SSMS 中返回正常，不到 1 秒，但在应用程序中，它最多需要 10 分钟，具体取决于使用的参数。任何参数组合在 SSMS 中都可以正常工作，执行计划对我来说看起来不错。

然而，当分析应用程序时，显然使用了不同的、效率较低的计划。用于连接的 SqlClient 具有 ARITHABORT 设置，设置为 OFF，当在 SSMS 中复制时，我遇到了相同的性能问题。

我猜 ARITHABORT OFF 将不允许优化器使用缓存计划？或者它运行一个单独的计划？

根据应用程序人员的说法，无法更改 SQLClient 连接以使用 ARITHABORT ON

我猜这里的 ARITHABORT 设置有点用词不当，它实际上是优化器没有使用好的计划导致的参数嗅探？

无论如何，我都需要强制它使用一个好的计划，那么如何最好地解决这个问题呢？我是否以某种方式创建计划指南或优化存储过程？

这是 SQL Server 2008R2 SP2。

是否可以编写sp_spaceused存储过程的脚本，以便我可以编辑它以包含日志空间信息并创建我自己的自定义存储过程？

我想将结果放在一个临时表中，以便我可以在我正在处理的项目中使用它，因此我还需要将 2 个结果集压缩为一个结果集。

不知道从哪里开始。有没有更简单的方法来获取相同的数据？

update ch1380.ComplexMiscLogic 
set logic = 'UNIDDisposition IN ('1','2','5')'
where misclogic = 11

在上述更新语句的第一行显示错误语法。请有人能解释一下为什么吗？

RDBMS 是 SQL Server，ch1380 是我的架构，ComplexMiscLogic 是我的表。