小编New*_*DBA的帖子

我在这里寻找专家关于如何管理大约 18 TB 的非常大的数据库的更新统计信息的建议。

我们最近开始面临性能问题，并认为这是由于旧的统计数据造成的。

实际上，我们有一个作业运行 exec sp_update stats 并以默认采样率更新，在我们的例子中为 1.2%。所以我们必须手动更新统计数据并看到一些改进。

我相信安排 FULL SCAN 将是一个挑战。据我所知，我正在将行与采样的行进行比较。例如，在一张大小为 400 GB 且行数超过 100M 的表上，我可以看到采样行约为 2 到 4M。大表是分区的。

我们使用的是 SQL Server 2012 企业版。未启用跟踪标志 2371。

请建议我如何为如此大的数据库以更好的方式更新统计数据以及如何使用该采样率？

我们正在尝试解决其中一个应用程序的连接问题，该应用程序试图从防火墙后面非常安全的 SQL 服务器提取数据。我不是安全方面的专业知识，但需要有关如何继续打开该应用程序的端口以从安全域后面的 SQL Server 提取数据的帮助。

我们\xe2\x80\x99已经打开了sql server正在侦听的端口，比如说12345，但仍然没有运气。

我如何知道可能需要打开哪些其他端口（例如 udp 1434 默认 1433 或镜像（例如 5022））？我们有什么办法可以找到这些信息吗？

对于我们的一个数据库，如下所示的查询非常慢。

由于安全原因，我无法分享实际的查询或计划，但只是想知道如何编写查询如下

SELECT [Id]
      ,[AboutMe]
      ,[Age]
      ,[CreationDate]
      ,[DisplayName]
      ,[DownVotes]
      ,[EmailHash]
      ,[LastAccessDate]
      ,[Location]
      ,[Reputation]
      ,[UpVotes]
      ,[Views]
      ,[WebsiteUrl]
      ,[AccountId]
  FROM [StackOverflow2010].[dbo].[Users]
  WHERE DisplayName IN (

 SELECT DisplayName from dbo.Users
 WHERE CAST(LastAccessDate AS DATE) = CAST ('20160814' AS DATE)
 AND CreationDate>= DATEADD (DAY, -30,LastAccessDate)
 AND CreationDate<= LastAccessDate)

在 stackoverflow 数据库中，这不会返回任何行，但对于我们现有的 6 TBS 数据库，它真的很慢。

CreationDate和LastAccessdate列都是日期时间 (10)

和 DisplayName是VARCHAR（50）

如果以上可以重写，请建议我如何提高性能

我们最近从 LogShippingstandby/read-only设置迁移到具有可读辅助设备的多子网 AG 设置。

通常，在旧设置中，我们会选择运行较长时间的查询，因为相关数据库超过 20 TB，并且主数据库上有混合读写工作负载。

在转移到 AG 的新设置后，我们开始看到我无法理解的阻塞。为什么辅助选择查询会阻止我的可读辅助副本实例中的其他选择查询，即使正在查询的数据库有RCSI enabled？

以下是我捕获的内容

• 主要阻止程序是一些长时间运行的SELECT查询，不会显示任何特定的等待类型，例如 SPID129

• SPID 129阻止会话 ID 45（我确信这不是用户 ID）近 6 小时，这取决于 spid129 并且等待类型是 LCK_M_SCH_M

• SPID 45当这在 6 小时的持续时间内阻止所有其他选择查询时，问题就来了。

我无法理解发生了什么。有人可以帮助我排除故障或寻找正确的方向吗？

有人可以帮我弄清楚我的理解是否正确：

在我的可读辅助副本的 AG 仪表板上，我看到：

• 预计恢复时间（秒） - 4598
• REDO 队列 - 将近 24 GB

那么，如果我的辅助 AG 需要将节点/故障转移或 SQL 重新启动作为活动的一部分，这究竟意味着什么？

这是否意味着我的二级数据库需要 4598 秒才能使用 24 GB 的重做队列启动这个数据库？

我很担心，因为我们的一个生产秒方在白天的大部分时间里重做大小为 400 GB，而从 AG 仪表板恢复时间将近 10 小时。这是否意味着所谓的 DR 受到了损害？

我刚刚做了一个测试故障转移，正如我从错误日志消息中看到的那样，数据库按预期进行了恢复，并看到它在 1235 秒内完成。只是好奇，因为估计恢复的数量还差得很远。这只是为了解释我的业务用户帮助他们我们正在谈论的中断窗口。

需要一些帮助来理解UPDATE以下语句之一的缓慢：-

UPDATE TOP (100) xyz
SET xyz.flag = 1
OUTPUT inserted.Rcode, inserted.EDR, inserted.id, abc.EID,abc.CID,abc.ENID,abc.Cdate
FROM dbo.table1 xyz WITH (UPDLOCK, READPAST)
INNER JOIN dbo.table2 abc WITH (NOLOCK)
on xyz.id=abc.id
WHERE xyz.flag = 0

表1有大约。50 万行，表 2 大约有。500 万行

慢计划

哈希匹配不同流运算符显示黄色警报，消息为：

操作员使用 Tempdb 溢出数据，以溢出级别 4 和 1 个溢出线程执行”

构建残差：

database.dbo.table2.id as abc.id = database.dbo.table2.id as abc.id

我截了屏。不幸的是，由于安全原因，我不能提供更多，甚至不能提供匿名计划。从我的工作站我无法访问互联网，所以我无法让计划浏览器在那里运行。

通常，对于较小的行子集，它在几秒钟内，就像我们刚刚匹配 10K 行或其他东西一样。但是随着数据量的增加，这似乎是一个临界点，应用程序无法承受 1 分钟的运行时间。从 SSMS 我得到 30 秒，但从应用程序我们有平均。约 50 秒 RCSI 处于测试阶段。

我的好计划没有显示 Hash Match Flow Distinct 运算符，如我的屏幕截图所示，而其余计划保持不变。好的一个在 3 秒左右完成。正如所见，该操作员花费了近 16 秒。我们可以通过适当的索引或查询重写来消除它吗？ …