我对从 Always on AG 仪表板上检查REDO Rate KB/Sec的指标感到有些困惑，在某些情况下，这与 perfmon 计数器数据库副本匹配：重做字节/秒（希望它是通过 perfmon 重做速率的正确计数器），有时一点也不。
大多数情况下，当有大量活动正在进行时，我认为 AG 仪表板和 DMV 在给定时间显示 REDO 速率为例如 40 MB/秒，这与 perfmon 计数器相匹配。
但是，在较少的活动时间或没有太多要发送给 sec 的情况下，与 perfmon 计数器相比，仪表板和 dmv 上的 REDO Rate 似乎显示不正确的值。
无法理解哪个值是正确的以及如何分析。知道为什么或者它是仪表板中的错误吗？
按要求截图：
在那段时间没有发生任何交易 - 初级端没有主要活动。我正在辅助和主服务器上收集该性能，因为在故障转移新的辅助服务器后，我们仍然需要运行这些计数器。但是，屏幕截图性能数据中提取的数据来自辅助数据。
对于过去上周的 tempdb 问题，我需要一些紧急指导：
tempDB 日志文件从特定时间开始增长，比如说下午 2 点。并且几乎继续增长到 150 GB，然后在 10 个小时左右后下降。
我使用了此处列出的各种查询，但没有显示任何内容，因为在此期间没有长时间运行的事务。
混合工作负载的查询不断涌现。没有这样的卡住交易。
此实例上的用户数据库都是日志传送设置的一部分，日志备份每 15 分钟发生一次。
另外我添加了 Xevent
CREATE EVENT SESSION [tempdb_file_size_changed] ON SERVER ADD EVENT
sqlserver.database_file_size_change(SET collect_database_name=(1)ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.is_system,sqlserver.query_hash,sqlserver.session_id,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username) WHERE ([database_id]=(2))) ADD TARGETpackage0.event_file(SET filename=N'C:\ExtendedEvents\TempDBGrowth.xel',max_file_size=(100),max_rollover_files=(25)) WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=1 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)
即使在 XE 中也没有任何内容被捕获，并且在那 10 个小时内它只是空白。
我不知道是什么在吃我的 tempDB 日志，因为没有任何查询或 XE 获取我的数据。我从来没有见过这个东西，通常使用 XE 来获得数据库增长，但在这里我一无所知。
我正在跑步DBCC SQLPERF(logspace)，我可以看到使用的日志每 5 分钟左右不断增加 1 Gb。我们将 TempDB 日志设置为最大 200 GB，但到了 10 小时，它几乎达到 160-180 GB，然后突然下降。
几乎每次在查询下方运行都会给出 ACTIVE TRANSACTION。
SELECT log_reuse_wait, log_reuse_wait_desc
FROM sys.databases d
WHERE database_id = 2;
请帮助我可能做错了什么以及为什么我看不到任何使用 TempDB 日志文件使用的事务？
更新 - 按照@JD 的回答要求，我检查并确认没有数据库邮件或服务代理在内部被用于导致增长：
然而在上周我看到 tempdb 的日志文件的增长是曲折的，曲折增长的趋势有点高：
我需要帮助理解：-
事务日志的增长是如何增长到 80%，然后再下降到 0，然后再增长和增长等等，达到 lmoast max 90-95%。
我确认没有手动收缩。可能有多个进程参与，因为这是全天使用 tempdb 的 OLTP 服务器。只是不明白上周它是如何增长到接近其最大容量的？
谢谢
在我们为 SQL 服务器进行常规操作系统修补后，我们遇到了一个奇怪的问题。
根据最佳实践，我们在被动上应用补丁并进行节点故障转移以使当前的被动、主动或反之亦然以完成修补。
通常，节点故障转移是无缝的，并在一分钟内完成。但是最近我们遇到了在节点故障转移后需要 4 分钟才能使 SQL 联机的问题：
我正在检查日志和事件，但找不到原因：以下是目前的发现：
注意：SQL 服务器在 VM 上运行
请协助我还应该检查什么以找到根本原因？
编辑-我尝试分析集群日志并且可以看到 sql 离线已启动，但我不确定它在内部花费至少 4 分钟实际关闭 sql 并将其恢复。4 分钟后，sql 错误日志显示数据库的所有条目大约需要 10 秒。所以看起来 DB 可能没有任何参与来减慢进程。
编辑-当前检查时的一些 VLF 信息
对于几个场景，不是很多次，但我们很少看到在存储过程上执行 sp_recompile 可以提高性能。
作为一名 DBA，我了解在进行 sp_recompile 时所涉及的一些警告以及为什么它会提高性能。
我们的管理层一直在争论是否向 Application/DEV DBA 提供在看到上述性能问题时进行 sp 重新编译的访问权限。只是为了减少 DBA 的参与，并且 APP 开发人员可以在性能问题期间在其上运行
我很犹豫，因为我认为它会带来一些不需要的行为，有时甚至会恶化其他 proc 的性能。
我正在向您的专家寻求一般指导和经验，为什么在可能的不同情况下或在理想情况下这可能是一个坏主意。您的输入可能会帮助我进行设计，并且可能会以不同的方式解释该方法。
仅供参考-当看到参数嗅探等问题时，不仅在一个应用程序中，而且在少数其他应用程序中都认为上述是自动化的。
我对这种压缩功能在 SQL Server 中的工作方式感到困惑：
对于相当多的大表，超过 TB 的表，我们最近实施了 PAGE 级压缩。
它是如何完成的示例：-
Use [DBname]
ALTER TABLE dbo.sampletable REBUILD PARTITION =1 WITH (DATA_COMPRESSION = PAGE);
ALTER TABLE dbo.sampletable REBUILD PARTITION =2 WITH (DATA_COMPRESSION = PAGE);
等等...
有问题的表都是分区表。
当检查我在表级别（聚集索引）看到的压缩细节时，它显示压缩 =PAGE但对于现有的非聚集索引，压缩表示 =NONE
如果在表级别启用压缩或还需要在索引级别启用压缩，我不确定我应该从上面解释什么？
如果我们还应该考虑压缩 NC 索引，是否有空间和性能优势？基本上，我在这里压缩它们的理想情况是什么？
谢谢
根据我们的安全漏洞和指南，当数据库变得太大而无法满足在给定 RTO 下无法恢复的要求时，我们需要计划实现相同的目标：-
根据您的经验，我需要一些指导和帮助：-
关于相关数据库的一些见解 -
总空间->右键单击数据库-属性->大小= 10TB
上面似乎免费的东西->右键单击数据库属性->可用空间= 5 TB
This database is an OLTP and critical one as it goes through lot of DUI operations throughout with heavy usage of TempDB
我列出了使用空间和索引的 TOP 10 表：-
拉出的所有前 5 名都是
partitioned单表中有超过 700 个分区的十亿和百万行的表
上表已PAGE启用压缩
上述表中的大多数索引少于 3 个，但索引级别的压缩显示NONE
对于备份，我们确实使用了 idera 等第三方工具的压缩来减小大小，但它超过了阈值。完整备份的备份大小约为 1.9 TB。我们也有 diff 和 tran 日志备份。
我对走这条缩小路线有点犹豫，因为它可能会影响性能，但请帮助我提出任何想法，但可以采取其他措施来缩小空间吗？
我们可以将几个大表拆分到自己单独的数据库中吗？如果是，有什么收获？
非常感谢您的帮助
我试图找出监控这两个事件的方法
记录发送队列大小 - 我可以在 perfmon 中看到
重做队列大小 - 我可以在 dmv 中看到，但在 perfmon 计数器中看不到
有什么方法可以使用 perfmon 以便即使计数器在 perfmon 中不可用，我也可以计算重做队列大小？
此外，当这些事件是数据库镜像的一部分时，我看到这些事件被记录在 Windows 事件查看器中。但是现在使用 AG，如何在 Windows 事件查看器中记录这两个值超出一定范围？
编辑
通过警报，我的意思是我们在 AG中有一些东西，如此处所示，作为从 db 镜像中看到的消息？
我们正在尝试了解 SQL 服务器突然自行重启的问题 -
它是一个 SQL server 2012 SP4 -GDR 应用，启用了 40 个 CPU 的 HT，因此总共有 80 个逻辑处理器-
MAXDOP=8 , CTOP 5
从我们发现的错误日志中
/**********************/
BEGIN 堆栈转储
非屈服调度程序 /**********************/
仅在重新启动 SQL 时出现错误消息。也没有像检查那样创建迷你转储。
是的，当时我们有很多查询正在运行。前 3 名等待是：-
1.TranLogIO
2.CXPACKET
3.PAGELATCH SH
然而，我们也注意到SOS WORKER从系统健康 XE 收集的等待调用，我相信这不过是THREADPOOL. 因此，我进一步分析了该系统运行状况中的查询处理详细信息，并发现在未产生调度程序错误时记录了以下错误
19:46
maxworkers- 2944workers created789oldest pending taskwait time0 待定任务 419:51
maxworkers- 2944workers created982oldest pending taskwait time256987 待定任务 165在 19:51，我们开始看到重启发生了。
问题是如果上述计算中仍有近 2000 个工作人员可用，为什么会有线程池等待。另外，当查询有这么多调度程序可供运行并完成对在 CXPACKETS 上等待的一堆查询的请求时，为什么那些待处理的任务计数为 165？
编辑：更新我的问题以等待 XE
SOS_MEMORY_TOPLEVELBLOCKALLOCATOR
当我阅读上面的信息时，请在这里等待https://www.sqlskills.com/help/waits/sos_memory_toplevelblockallocator/
根据博客，在 SP3 CU 中有一个修复，但使用 TF T8075：我目前使用的是 SP4-GDR 最新补丁，是否仍需要应用 TF，尽管我没有看到Failed allocate pages: FAIL_PAGE_ALLOCATION 513错误日志中的任何消息
不确定它是否有帮助-我看到总服务器内存不时下降一个演出，然后匹配到目标服务器内存，即 = 最大服务器内存 (750GB)
大多数时候总=目标=最大服务器内存。滴水只是演出而已，并不多
内存信息 = 总内存：880 GB 最大内存：750GB 最小服务器内存：130 GB 它是一个 2 节点 Windows 集群，没有共享其他 SQL 实例。资源调控器未启用
谢谢
格式化 SQL Server 数据库文件的文件系统的当前最佳实践或一般指南是什么？
目前我们有 SQL Server 文件系统，NTFS 根据这些 Microsoft 指南格式化为 64KB 块大小。
我不确定这现在适用多少，以及我们如何找到最适合我们可以格式化高达 1 或 2 MB 的最新 Windows 服务器。
因此，我正在寻找如何为现代 SQL Server 格式化磁盘的建议，比如 2017 年及更高版本，使用最新的 Windows，因为 MSDN 文档似乎没有更新。不同的块大小（如 512 KB 或 128 KB）是否会更好地格式化 mdf、ndf 和 ldf 文件所在的驱动器。
对于我们的一个 SQL 服务器，有一个 proc 会造成阻塞：
该存储过程在大多数情况下会在一秒钟内完成，但不知何故使事务处于打开状态。我从 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 设置在这种情况下将如何帮助？
请指教
根据我的监控集合，我在收集有关 SQL 实例中的 # 个数据库有多少 VLF' 的信息时遇到了问题。
第一个问题 - 是否有一个脚本可以从 2012 年到 2019 年 SQL 版本作为标准使用来获取实例中所有数据库的 VLF 信息
第二个问题 - 我怎样才能以最少的权限完成第一个，因为我们用来收集信息的登录不是系统管理员，也不能。那么我该如何实现呢？
非常感谢，谢谢！
只是一个快速的问题，不知何故无法弄清楚。
我们有一个 Active Active 集群，或者我应该说多实例集群，如下所示。节点 A 和 B 是同一窗口集群的一部分
节点 A --> Serv1\SQLINSt1
节点 B --> Serv2\SQLINSt2
我如何一次显示节点 A 主机实例 Serv1\SQLINSt1 和节点 B 其他实例 Serv2\SQLINSt2 的信息，因为当我使用 dmvsys.dm_os_cluster nodes并添加SERVERPROPERTY ('instancename')它时，它会为两个节点提供相同的 SQL 实例
是否可以显示两个实例何时都出现在节点 A 上，而节点 B 没有实例？
非常感谢感谢
我相信在数据库镜像中更改主数据库上的兼容模式会更改镜像数据库。
但事实证明这是错误的。我在 Primary 上查询使用sys.databases，我将兼容模式更改为 120 ，但是在其镜像数据库上，兼容级别仍然是 100。为什么？
我在这里使用了不正确的 fn sys.databases 吗？
此外，如果它没有改变它的含义，我是否需要进行故障转移/故障回复以反映？
如果我有日志传送辅助数据库只读以及需要反映此更改的地方怎么办？那我需要重建日志传送吗？
谢谢
需要一些关于从数据库镜像迁移到 AOAG 的实用/一般指导
当前设置 - 2 个独立服务器，数据库镜像配置为异步。
服务器之间的距离约为 150 英里。
我们只需要使用上述服务器并将数据库镜像转换为具有自动故障转移选项的 AG，以提供 HA 作为奖励，因为通过上述设置，它主要是一个 DR 解决方案。
Clusterless AG 找到了我，但似乎 HA 不可用，因为自动故障转移可能不起作用。我在这里遗漏了什么还是有可能？
如果需要，我们最多可以中断 8 小时以将 db 镜像转换为 AG。
我应该如何计划或是否有任何可用资源来做到这一点？找了很多文章都没找到，求指教
希望你们都做得很好，安全：-
我正在使用以下事件从扩展事件中收集查询级别指标 -
SP statement completed
SQL Statement completed
SQL Batch Completed
RPC Completed
我有时会在许多看起来相似的事件中看到类似的查询。我不明白为什么？有人可以准确解释这四个事件之间的主要区别是什么。这只是为了我的开发服务器作为测试，看看我正在收集什么。是否有适合所有人的事件？
我有一个关于重新设置 MAX SQL 内存设置的一般问题-
对于我们当前具有以下规格的 CPU，服务器团队将操作系统内存从 400GB 提高到 1TB：
查看英特尔网站上的规格，这里支持的最大内存似乎是 768。
那么这在 SQL 空间方面究竟意味着什么？即使操作系统有 1 TB，是否应该根据 1 TB 或 768 GB 设置 MAX 内存设置？我们可以在尝试提高 MAX 内存设置时看到 SQL 的问题，比如说超过 850，当我们将其降低到 400 时又恢复正常。
增加 SQL MAX 内存时的问题 - 根据超时设置，运行超过 3 秒的查询的应用程序超时。
测试了这几次，看起来是一样的。需要了解原因
感谢您对此的投入。
这将更多是一般方法问题，而不是过于技术性：
如果我们需要在 CPU 内存磁盘或 CPU 方面扩展 SQL 服务器，我的一个应用程序会主动联系我，因为他们计划将容量增加一倍。
从当前卷中，我捕获了显示 CPU/内存和磁盘运行没有问题的内容。
但是，如果数量增加而最终可能需要增加容量，我该如何自信地衡量一切会发生什么变化？
需要您的专业知识，我如何才能积极主动，我可以衡量什么来做出决定，至少接近数量增长的预期？
是的，我确实有 SQL 服务器监控，它存储了过去 15 天的性能数据。大多数数据来自性能计数器和 DMV。
更新 - 在我更新时添加更多数据 - 每天平均 800 个事务/秒和一天内 400 个批处理请求/秒，然后在一天内稳定 40% 的 CPU 使用率，包括高峰日。读/写的磁盘响应都远低于 5 毫秒。PLE全天超过10K。
非常感谢任何有关如何解决此问题的帮助。我知道这个问题的答案很广泛，但是一些很棒的想法不仅可以帮助我这个服务器，而且将来也会出现类似的东西，谢谢！
我有一个问题想更好地理解 NUMA 节点在 SQL Server 中的帮助：
在我们当前的设置中，我们有 4 个 NUMA 节点，具有 20 个内核并启用了超线程，总共有 40 个逻辑处理器。使用 400 GB 的内存，每个 NUMA 获得 100 GB。
它是在 Windows 2012 R2 Standard 上具有 SQL Server 2012 Enterprise（基于核心的许可）的物理服务器。它有 4 个插槽，每个插槽有 10 个内核，每个插槽有 20 个逻辑处理器，从我看到的错误日志中总共有 80 个。
我的理解是，如果我们使用相同数量的 NUMA（而不是我更喜欢 2 个 NUMA）移动（未来 SQL 刷新到 2017/19），可能有 4 个 NUMA 节点可能不会表现更好。
为什么我这么说是因为我认为 2 NUMA 400 GB 将被分配为每个 200 GB。
因此，我的理解是，根据查询在节点之间切换内存的方式来进行配置可能会更好或最好。是的，我们看到了一些内存问题，我知道我们正在处理其他相关问题，但这个问题更具体到为 SQL Server 设置的 NUMA。
有人可以分享他们的经验，或者提供更多的见解，因为我可能在这里认为错误的信念查询与 4 NUMA 相比，在 2 NUMA 上的交换必须更少？
有没有办法或查询我可以检查查询是否花费时间在两个不同的 NUMA 上交换内存并且可能是一个问题？
有没有一种方法可以衡量两个节点在未来的设计（跨节点内存访问）中是否比四个节点工作得更好？
并基于相同的创建扩展事件
CREATE EVENT SESSION [PerfStats_Node] ON SERVER
ADD EVENT sqlserver.query_thread_profile(
ACTION(sqlos.scheduler_id,sqlserver.database_id,sqlserver.is_system,sqlserver.plan_handle,sqlserver.query_hash_signed,sqlserver.query_plan_hash_signed,sqlserver.server_instance_name,sqlserver.session_id,sqlserver.session_nt_username,sqlserver.sql_text))
ADD TARGET package0.event_file(SET filename=N'C:\Temp\PerfStats_Node.xel',max_file_size=(50),max_rollover_files=(2))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO
然而，在查看目标文件时，我看到捕获的计划似乎是估计的，即使目标事件中出现了一些实际数字，但是当我在 sys.dm_exec_query_plan 中传递计划句柄时，出现的计划似乎有所有估计
博客上明明说会打开实际计划，那为什么我看不到呢？
我也尝试使用 SSMS 17.9，但仍然没有运气。
我正在阅读有关将 SSRS 与 AG 一起使用的 msdn 文章，并且对设置相同的内容几乎没有疑问：
以上节点将成为多子网集群的一部分，N1 在 DC1 中，N2 在 DC2 中。
我正在考虑首先为这些多子网创建具有 2 个 IP 的侦听器，以便我们可以在安装报告服务时使用相同的侦听器，并将侦听器名称指向实例，它的报告服务器数据库指向它，以便它知道主副本即使在之后故障转移。
我的上述理解正确吗？这是它应该如何工作的吗？
其次，文件说即使我在 N1 和 N2 之间使用同步模式也不支持自动故障转移？真的吗？为什么只有 SSRS 才会出现这种情况？另外，如果是，我们可以自动进行故障转移还是每次都必须手动，因为我认为数据源应用程序字符串可以使用该选项MultiSubnetFailover=true？
感谢您的投入。