我已将一个数据库添加到已经拥有一些数据库的可用性组，所有这些数据库都已播种并同步到辅助数据库。

最后一个似乎被添加到可用性组中，但被标记为“不同步”并且不会返回任何错误。我已经尝试了多次，结果相同。

我查看了扩展事件、事件查看器......什么也没有。单击仪表板中的“警告”没有任何有用的信息。辅助数据库上根本不存在数据库文件。我怀疑它在播种过程开始时就被阻止了（但显然是在“添加到 AG”向导中的初始验证之后）。

我有一种明显的感觉，SQL Server 一定正在将相关的故障消息记录到一些我不知道的 DMV 中。

是否有一个规范的指南来指导人们应该在所有地方寻找与AlwaysOn相关的错误？

我有一个使用 SQL Server 2017 的 ASP.NET 应用程序。某处有一个错误导致某些记录被删除，我正在尝试恢复数据并找到错误的原因。我们进行每日备份，我有一个查询来查找哪些记录应该存在但不存在，所以我想遍历并在每个备份上运行查询。备份相当大，但我只需要整个数据库中的 2 个表来进行查询。在一个多月的备份中执行此操作的最有效方法是什么？

在测试某些查询时，我在数据库上将恢复模型设置为 full 并运行了两个相同的 1M 行插入，有和没有TABLOCK.

在使用 时TABLOCK，我绕过9295了 sql server 2008 实例8714上的日志记录，以及 SQL Server 2017 实例上的日志记录。

在没有 tabblock 的情况下运行插入时，我绕过1035659了 2008 实例的1068599记录和 2017 实例的记录。

在 sql server 2008 上测试的原因是为了匹配数据加载性能指南关于 ML 操作的恢复模型的声明：

仅当您的数据库处于大容量日志或简单恢复模式时，最少日志操作才可用。

那么，如果不是最小日志记录，这里看到的是什么？

Use DatabaseName

ALTER DATABASE DatabaseName SET RECOVERY FULL;
GO
BACKUP DATABASE DatabaseName TO DISK = '\\location\DatabaseName.bak';

BACKUP LOG DatabaseName TO DISK = '\\location\DatabaseName_log.trn';
GO

IF OBJECT_ID(N'dbo.Accounts', N'U') IS NOT NULL
BEGIN
    DROP TABLE dbo.Accounts;
END; …

我有 Windows Server 2016 和 SQL Server 2017，发现 Windows 日志应用程序充满了登录失败消息（如下）：

用户“sa”登录失败。原因：密码与提供的登录密码不匹配。[客户： ****]

客户端的IP地址多种多样。我在 SQL Server 中没有任何维护计划

有什么问题？

我一直在 Always On High Availability 组中研究数据库，由于我不明白的原因，该组在主节点和辅助节点上对应用程序登录使用不同的默认语言。

我目前的特殊情况是这样的：

• 应用程序期望的语言是英式英语。它没有指定连接时使用的语言；它使用登录的任何默认语言。该应用程序的文档说默认语言应该是英式英语，大概是因为它没有指定连接语言。
• 应用程序连接到侦听器，而不是直接连接到任一节点。
• 应用程序通常将日期保存为字符串（例如UPDATE FooTable SET BarColumn = '01\02\2020' WHERE IdColumn = 42）。数据将保存在日期或日期时间列中。
• 数据库侦听器上登录的默认语言是英式英语。
• 主节点登录的默认语言为英式英语。
• 辅助节点登录默认语言为美式英语

我不是 DBA，当然也不是 Always On High Availability 方面的专家。使用此配置可​​能存在/已经存在哪些危险？如果交换主节点和辅助节点上的语言是否重要？

我们有一个邪恶的查询，它从表中读取每一行，但不应该。为了帮助开发人员找到该查询的来源，当针对该表的任何选择没有 where 子句时，我想使 SQL Server 出错。

一个应用程序正在做一个无处可去的邪恶选择。选择读取大约有 6,500 行的表的每一行。选择在 SSMS 中很快（< 1 秒），但是当由应用程序运行时它很慢（大约 1/2 小时）。我们认为这是因为应用程序正在慢慢地迭代结果集。它是一个用于更新和插入的活动表，因此在进行此读取时可能会阻止其他查询。

开发人员没有理由认为任何应用程序都应该读取该表的每一行。他们怀疑是过去开发人员的疏忽。

到目前为止，邪恶的 query-with-no-where 是我的领跑者，因为它在 Query Store 中的总持续时间最长。

通过使用 SQL Profiler 识别应用程序名称、主机名和数据库用户名，我知道哪个应用程序正在发出恶意查询。该应用程序的开发人员无法找到恶意查询的来源。我想帮忙。

该应用程序使用 C# 并使用 LINQ。邪恶的查询每次都完全相同，具有相同顺序的相同列。可以使用简单的相等来确定发出的查询是否是邪恶的查询。查询以自己的批次发出，没有任何其他查询。

我想让任何针对没有 WHERE 子句（即选择每一行）的表的选择立即失败。我们希望应用程序会记录错误，或者触发 Activity 的最终用户可能会向我们报告 500 错误，这将为我们提供另一个线索来找到发出邪恶查询的代码.

我们针对该表的其他选择具有特定的 where 子句，并且只返回表行的子集。必须允许这些选择继续。

查询

SELECT 
  [a].[Id], 
  [a].[AccountingIntegrationActionTypeId], 
  [a].[CreateDate], 
  [a].[CreatedBy], 
  [a].[FranchiseId], 
  [a].[Message], 
  [a].[ModelObject],
  [a].[ProcessId],
  [a].[RequestedBy], 
  [a].[RequestedFor], 
  [a].[Resolved], 
  [a].[UpdateBy],
  [a].[UpdateDate]
FROM 
  [AccountingIntegrationQueue] AS [a]

我有一个包含 307200 条记录的表，其中 f_column 为 VARCHAR(30)。缺失索引 dmv 中不会显示缺失索引，也不会在执行计划中建议缺失索引。

SELECT f_column, f_column2 FROM t_table WHERE f_column = '23BE46F3-E9A9-4526-A2F8-3F51818025B5'

该查询返回 5 个结果，花费了 9958 次逻辑读取。对于下面的索引，需要 3 次逻辑读取。

CREATE NONCLUSTERED INDEX IX_t_Table_f_column ON t_table (f_column) INCLUDE (f_column2)

当添加索引会给查询带来巨大好处时，什么可能导致缺失索引不会出现在缺失索引 dmv 和执行计划中？

我最初怀疑统计数据，并更新了表的所有统计数据，但问题仍然存在。由于某种原因，添加或更改表上的列将导致 SQLServer 恢复正常，并且缺失的索引会出现在缺失索引 dmv 中以及查询下次执行的执行计划中。

上周其中一个 SQL Server 出现问题，CPU 开始消耗超过 80%（正常为 10-30%）
这持续了大约 2 小时，直到我手动故障转移到 AG 中的辅助副本（这已经解决了问题）

问题开始：12:15
问题结束：14:15（手动 AG 故障转移后）

服务器信息：

SQL Server 2017  
32 logical processors (max DOP = 8)  
256 GB RAM (Max Server Memory = 180 GB, used 179 GB)

以下指标在问题出现之前与问题开始后没有明显变化

• 用户连接数/秒（平均 200-300）
• 批处理请求数/秒（平均 200 及更低）
• 数据库缓存内存 ( ~ 150 GB )

以下指标显着达到峰值，这对于该服务器来说并不典型（通常这些指标很低）：

• CPU（超过 80%）
• 内存授予待处理
• 锁定等待/秒，平均 锁等待时间，死锁
• 锁存等待时间
• 授予的工作区内存和保留的服务器内存

查询：

当问题开始时，我没有注意到此服务器的工作负载发生变化
开发人员还确认应用程序完成了他们通常的工作并正在运行常规查询，应用程序负载没有峰值

在这个“高 CPU 使用率”问题中，CPU 的前 10 个查询看起来并不异常
即使 CPU 正常（10-30 %），我们通常也会看到前 10 条查询

问题：

问题似乎出在几个相关的存储过程中，该应用程序通常每秒运行 1-4 次，而那些通常在 50 毫秒内完成，但在问题期间，只要我检查了 …

我们使用带有“SQL_Latin1_General_CP1_CI_AS”的全新 SQL Server 2017 CU23 标准版数据库。现在，我想将所有系统数据库（ master 、 model 、 temp 、 msdb ）更改为另一种排序规则。如何在不安装 SQL Server 的情况下更改此设置？

谢谢，

之间有差异WHERE [BitField] = 1和WHERE [BitField] <> 0？

它们在逻辑上似乎是等价的。

但是，SQL Server 不同意并创建略有不同的执行计划。（这很糟糕，因为第二种形式不能非常有效地使用现有索引。）

我是否遗漏了什么，或者这只是不等式运算符的行为方式？