小编Beg*_*DBA的帖子

我们有一个来自应用程序团队的 AD-HOC 流程，该流程从我们在 SQLserver 中频繁使用的 OLTP 数据库之一获取数据，以将数据迁移到 MongoDB。

在性能测量期间，我们可以看到，当从这个 sql server 获取数据时，他们运行的那部分 CPU 峰值出现了将近一个小时，几乎达到 60-80%。

因此，为了减少这种影响，我们正在考虑使用资源调控器来限制 CPU/内存资源。我从未使用过 RG，但阅读博客似乎是理想的选择。

请建议是否可以实现这一点，或者根据您的经验提出更好的建议。

上述活动是每月一次在 SQL Server 2008R2 中的 5 TB 数据库上获取约 8000 万条数据

有没有办法在系统健康扩展事件文件滚动时找到事件，而不是手动监视事件？

对于我的中等负载服务器，它们最多可停留 2-3 天。但是对于负载较重的服务器，这些文件每 15 分钟左右滚动一次，但没有固定的模式或时间。我们知道原因并努力过滤掉不需要的事件或报告为问题的事件。

我很好奇是否有一种方法可以查询文件翻转发生的时间。我也没有在 MS 文档上看到太多文档，但找不到此信息？

请建议它是否可能以及如何？

我相信在数据库镜像中改变主数据库的兼容模式会改变镜像数据库。

但事实证明这是错误的。我sys.databases在 Primary 上查询使用，我将兼容模式更改为 120 ，但是在其镜像数据库兼容级别仍然是 100。为什么？

我在 sys.databases 中使用了不正确的 fn 吗？

此外，如果它没有改变它的含义，我是否需要进行故障转移/故障回复来反映？

如果我有只读日志传送辅助数据库以及此更改需要反映的地方怎么办？那我需要重建日志传送吗？

谢谢

我们遵循在产品上主动查询的表上创建主键/聚集索引的最佳实践。

现在有一个场景，我们需要在 DEV/test 上完成上述类似的更改。由于我们没想到我们可能会在开发中要求这样做，因此我们从未记录以映射类似的更改。

有没有更好更快的方法来做到这一点，而不是手动编写脚本并在以后创建它们。

谢谢。

我试图找到导致数据库的 mdf 从 20 GB 膨胀到 100 GB 的原因。

到目前为止，我尝试检查自动增长事件以找到时间，但使用标准报告甚至默认跟踪文件都找不到。

我们没有 3rd 方监控工具来确认是否有任何维护工作（如重建）或任何其他过程。

我怎样才能找到导致这个 mdf 增长的原因？

对于我们的一个 SQL 服务器，有一个过程会造成阻塞混乱：

大多数情况下，该存储过程在一秒内完成，但不知何故使事务保持打开状态。我从 sp_whoisactive 看到的是 status = sleep 并打开 tran 1 持续大约 5-6 分钟。在这段时间内，出现了起伏的阻塞链。

这个 SP 没有像 BEGIN 和 END TRAN 这样的任何事务。它做了一些基本的 select col,col2,col3.... into #temptables from table1 inner join table 2 ... 然后从 #temptable 中选择

当我们从应用程序检查为什么可能有一个事务保持打开状态时，我正在阅读这些场景以在 SP 本身中使用 XACT ABORT ON。但是当不涉及事务时，XACT ABORT 设置如何在这种情况下提供帮助？

请指教

我们已经设置了 LS 来从独立的 SQL Server 2012 切换到集群的 2012 服务器。

我们设置 LS 的主数据库也参与了数据库镜像，大小约为 1.8 TB。这是 PERF env，用于测试实际切换，并且在设置 LS 的数据库上事务不频繁。

问题：我看到主服务器上的 LS 备份作业运行时间比计划时间长 [每 15 分钟] 或失败并出现以下错误：

未处理的异常：System.IO.FileLoadException：进程无法访问该文件，因为它正被另一个进程使用。（来自 HRESULT 的异常：0x80070020）在

---

失败时没有固定的模式。通常它会在 18-20 秒内完成，但在某些运行中它会在运行超过 50 分钟左右时失败。

我怎样才能进一步解决这个问题？

编辑：@ 日志备份通常每 15 分钟从 100-200 MB

我只是在浏览系统运行状况扩展事件时遇到一个事件，其中包含用于显示工作线程状态的查询处理的诊断结果：

1. 当我有 80 个逻辑处理器时，为什么最大工作线程显示 2994，根据 msdn 计算，这里 512 + ((logical CPU's - 4) * 16)看起来不正确。但是，这里的最新链接对于大于 64 的逻辑处理器是有意义的，其中 16 的计算更改为 32。但是该链接说从 SQL 2017 开始，但是我得到的数字 2994 是针对 SQL2012, 14 16 的，其中逻辑处理器数为 80 . 我在这里遗漏了什么吗？

sp_configure 中的 max worker 设置设置为“0”

2. 回到该系统运行状况事件状态，显示以下 no 的警告：

maxWorkers="2944" workersCreated="456" workersIdle="314" tasksCompletedWithinInterval="1021881" pendingTasks="1"

我应该检查其他东西还是可以忽略它？

我们在主 DC 中有一个大约 15 TB 的数据库，其中包含分区表，其中最大的一个大约 7 TB。

为避免用户报告 LS 设置是在不同 DC 中为上述数据库完成的，其中 LS 还原作业每晚运行一次。

在 Primay-update stats 和 update stats AYNC 都设置为 True，因此在辅助上反映相同。我不确定为什么有人同时启用这两个功能，应该是这样吗？

现在在次要方面，我看到当从用户运行 SELECT 查询时会发生很多阻塞，结果是 select statman 语句用于该只读数据库的自动更新统计信息。

我不明白为什么在启用自动更新异步时会有一个？

此外，在 LS 恢复期间是否会恢复在主要（每周一次）上完成的更新统计信息？如果没有，在 LS 备用模式中涉及的辅助数据库上运行更新统计信息的更好方法是什么，可能是每天运行以获得更好的选择性能？

请指教

当我正在阅读和理解时，如果匹配索引以支持查询的键列以相同的方式排序，则需要避免 SQL 查询中不需要的 ORDER BY。

对于下面的数据库测试模式——

CREATE PARTITION FUNCTION DemoPartitionFunction (datetime)
AS RANGE RIGHT
FOR VALUES (DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), -7),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), -6),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), -5),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), -4),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), -3),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), -2),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), -1),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), 0),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), 1),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), 2),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), 3),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), 4),
            DATEADD(dd, DATEDIFF(dd, 0, GETUTCDATE()), …