variable's questions

我已收到一个数据库备份文件。

恢复后，我在这个数据库中运行了脚本，它向我显示了查询的行数：

SELECT qs.execution_count,  
    SUBSTRING(qt.text,qs.statement_start_offset/2 +1,   
                 (CASE WHEN qs.statement_end_offset = -1   
                       THEN LEN(CONVERT(nvarchar(max), qt.text)) * 2   
                       ELSE qs.statement_end_offset end -  
                            qs.statement_start_offset  
                 )/2  
             ) AS query_text,   
     qt.dbid, dbname= DB_NAME (qt.dbid), qt.objectid,   
     qs.total_rows, qs.last_rows, qs.min_rows, qs.max_rows  
FROM sys.dm_exec_query_stats AS qs   
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt   
WHERE qt.text like '%SELECT%'   
ORDER BY qs.execution_count DESC;

但这不会返回与我在生产数据库上运行时看到的相同的输出。

sys.dm_exec_query_stats 值是存储在服务器级别还是数据库级别？我的意思是还原后数据没有保留吗？

授予执行存储过程（全部）权限是否隐式允许任何关键权限？例如，通过运行相关存储过程来控制安全性等的权限？

授予执行所有存储过程的权限的方法是：

GRANT EXECUTE TO [user]

假设我在 4 节点集群中有 AG，主站点上有 2 个节点，灾难恢复站点上有 2 个节点，1 个云见证。故障转移模式是手动的。

现在由于某种原因，假设主站点网络出现故障，特别是我无法连接到主数据中心。

情况 1：主节点具有法定人数，因为它仍然能够与云见证进行通信。由于主站点存在一些网络问题，SQL 仍在主站点上运行，并认为它是主站点。

情况 2：主节点无法与云见证通信并且已失去法定人数。动态见证人和动态法定人数可能会生效。

假设我现在连接到其中一个 DR 节点并调用强制手动故障转移。

当我调用手动故障转移时，DR 站点上的 SQL 会认为它是主站点。从技术上讲，这是一个拆分集群场景。

案例 1 中的分裂场景是显而易见的。在情况 2 中，这可能是由于动态见证人和动态法定人数的启动所致。

当主要网络重新建立时，我需要做什么来处理这种情况？因为如果我的想法是正确的，那么两个站点都会认为它拥有主 SQL 服务器。

我将数据库恢复到不同的 SQL 服务器，但有趣的是，该服务器上的 msdb 备份集表显示了源服务器的数据库备份历史记录。

这是预期的吗？

注意：我没有恢复msdb。

重现步骤：

1. 在源服务器上执行完整备份，然后进行几个日志备份。
2. 在目标服务器上，使用数据库恢复 UI 执行完整备份和日志备份的恢复。
3. 在目标服务器上触发以下查询，您将看到该数据库的完整备份历史记录（来自源服务器）出现在此处。

询问：

SELECT 
   CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server, 
   msdb.dbo.backupset.database_name, 
   msdb.dbo.backupset.backup_start_date, 
   msdb.dbo.backupset.backup_finish_date, 
   msdb.dbo.backupset.expiration_date, 
   CASE msdb..backupset.type 
      WHEN 'D' THEN 'Database' 
      WHEN 'L' THEN 'Log' 
      END AS backup_type, 
   msdb.dbo.backupset.backup_size, 
   msdb.dbo.backupmediafamily.logical_device_name, 
   msdb.dbo.backupmediafamily.physical_device_name, 
   msdb.dbo.backupset.name AS backupset_name, 
   msdb.dbo.backupset.description 
FROM 
   msdb.dbo.backupmediafamily 
   INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id 
WHERE 
   (CONVERT(datetime, msdb.dbo.backupset.backup_start_date, 102) >= GETDATE() - 7) 
ORDER BY 
   msdb.dbo.backupset.backup_finish_date desc

当启用自动调整时，使用SET AUTOMATIC_TUNING(FORCE_LAST_GOOD_PLAN)，然后基于查询回归假设SQL Server自动决定强制执行一个计划，那么它什么时候重新访问它的决定并重新评估是否有更好的计划可以执行该查询更快/更少的资源？

我有以下 XE 谓词示例：

样本1：

Duration>1000000
AND cputime>1000
OR logicalreads>25000

样本2：

Duration>1000000
OR cputime>1000
AND logicalreads>25000

我知道它确实短路，但是在没有括号的情况下它如何计算出逻辑？

对于样本1来说是：

(A and B) or C
A and (B or C)

对于样本2来说是：

A or (B and C)
(A or B) and C

我正在使用本地 SQL 2022 企业版。

从 SSMS 19.1 开始，删除了 SQL 漏洞评估选项。

我读到此功能现在已成为云防御者的一部分。

如果有人尝试过这个，那么这个是免费的吗？我现在是否需要要求 Azure 管理员设置云防御器才能进行 SQL 漏洞评估？

我想通过在另一台计算机上添加新实例并配置多个基本 AG（使用手动故障转移模式）来为单实例 SQL Server 设置 HA DR 。

我希望所有客户端应用程序都能够使用相同的连接字符串来访问服务器。为此，我是否使用侦听器（仅为 1 AG 创建一个侦听器，并在所有连接字符串中使用它）还是使用数据库镜像端点？

在默认 SQL 安装中，引擎帐户是 NT Service\MSSQLSERVER，代理帐户是 NT Service\SQLSERVERAGENT

在 SQL 安全性中，我可以看到它们都被列为具有 sysadmin 角色的登录名。

它们还自动拥有各个文件夹的必要安全权限。

如果我通过配置管理器将引擎和代理帐户更改为域或本地帐户（如 mydomain\sqlengine、mydomain\sqlagent），则：

1. 我是否需要在 SQL 安全性下创建这些帐户并为其分配 sysadmin 角色？

2. 是否有任何其他后期步骤（如任何其他权限分配 - 如下所示： https: //learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-权限？view=sql-server-ver16#Windows - 或者这是通过虚拟帐户隐式应用的？）？

3. 我可以从我的 SQL 服务器登录中删除上述 2 个 NT 服务帐户吗？

询问的原因是 - 我知道 SQL 引擎在幕后使用服务 sidNT SERVICE\MSSQLSERVER帐户，代理使用NT SERVICE\SQLSERVERAGENT, 来获取各种文件夹权限（数据/日志/等），以及 Windows 权限和权限，例如Log in as a service, Replace a process level token,等等。但是，即使将SQL Server引擎服务帐户更改为域用户帐户后，它仍然使用该虚拟帐户来访问文件夹/文件吗？

当我通过配置管理器将 SQL Server 服务帐户更改为域用户帐户时，它不会自动更改数据或日志文件夹或文件权限。文件夹/文件安全弹出窗口始终显示MSSQLSERVER（不是域用户帐户），并且 SQL 服务器工作得很好。

这是否意味着即使 SQL 引擎服务帐户更改为域用户帐户，SQL Server 引擎仍使用 NT SERVICE\MSSQLSERVER ？

我遇到一个问题，索引重建导致同步 AG 辅助节点上出现较大的重做队列。

此问题仅发生在 1 个数据库上，该数据库与所有其他数据库之间的唯一区别是该数据库强制延迟了持久性。平均而言，所有数据库的数据文件大小范围为 300 到 600GB。

根据文档，我了解对于此数据库，无法保证事务持久性（例如重新启动或崩溃时），并且客户端在将日志记录写入主/辅助 AG 节点上的磁盘之前收到提交。

我的问题是 - 当日志最终刷新到主节点上的磁盘（通过持久事务或强制刷新命令）时，此时日志是否也会发送到辅助节点？那么实际上这是一大块记录并且可能是重做队列变大的原因？

更新：索引重建期间重做队列的建立仅持续约 20 秒（当强制延迟持久性时）。如果我将延迟持久性设置为关闭，那么在索引重建期间就不会建立重做队列。我想知道大块刷新（由于延迟的持久性）是否导致瞬时重做队列建立。

我们有 AG 感知的 SQL 代理作业：第一个作业步骤检查服务器是否是主服务器（如果是，则转到下一步，即实际的作业步骤），否则退出报告成功的作业。

有 1 个数据库未参与 AG（计划是在发生故障转移时手动恢复此数据库）。主数据库上有一个作业从该数据库调用 SP。我被要求在辅助服务器上创建此作业（以便在故障转移后我们只需恢复数据库而无需重新创建作业）。由于辅助数据库上不存在该数据库，因此我无法在辅助数据库上为该数据库创建作业。即使我在辅助数据库上恢复数据库的副本，创建作业，然后删除数据库，数据库下拉列表（在作业内）也会变成空。

一种解决方案是在恢复此数据库后手动创建故障转移后的作业。是否有任何替代解决方案允许我在数据库不存在的情况下创建代理作业？

数据库上的延迟持久性（强制）设置可确保客户端应用程序无需等待日志刷新（写入）到磁盘即可获得提交。

同步AG要求将事务写入主日志（flush到磁盘），并写入辅助日志（flush到磁盘），然后客户端才会收到commit。

对于参与 AG 的数据库，此设置（延迟持久性 = 强制）是否适用于主数据库和辅助数据库，并且两台服务器上的 SQL 引擎都不会等待日志写入磁盘？

SELECT 查询需要 SCH-S 锁。这可以与其他读取查询共享。

UPDATE 查询需要 SCH-M 锁。这不能与其他读取/更新查询共享。

链接：https: //www.mssqltips.com/sqlservertip/5880/why-is-index-reorganize-and-update-statistics-causing-sql-server-blocking/

该示例显示索引重组 (Sch-S) 锁阻塞了统计信息更新的 Sch-M 锁。但为什么它也阻止了 SELECT 查询请求的后续 Sch-S 锁？Sch-S 锁不是共享的吗？

C盘是OS盘

D盘是数据盘（系统和用户dbs）

E盘是日志盘（系统和用户dbs）

D盘坏了。所以 sql 没有启动，因为缺少主 mdf 文件。

我可以通过指向主 mdf 文件的备份来启动 sql server，然后恢复 msdb/model/user dbs。但是我所有的备份文件都是 .bak 格式。

我有系统/用户数据库 (.bak) 的完整备份和日志备份。如何提取主 mdf 文件以启动我的 sql server？

也许在新的测试服务器上恢复 master，然后将该 master mdf 文件复制到原始的 sql server。还是重建系统数据库，然后恢复 master/msdb/model/user 数据库是否合适？

修复孤立用户的正确方法是什么：

sp_change_users_login @Action='update_one', 
@UserNamePattern='TestUser1', 
@LoginName='TestUser1'

或者

ALTER USER TestUser1 WITH LOGIN=TestUser1

两者都修复了孤立用户。

我正在 prod AG 服务器上设置 sql 登录。并在辅助 AG 节点上使用相同的 sid 创建它。

我们还需要在其他生产独立 SQL 服务器、AG SQL 服务器和开发 SQL 服务器上使用此用户。

创建相同的登录名时，在其他 sql server 上重新使用来自 1 sql server 的 sid 是否有任何风险？

好处是在跨服务器移动数据库后不必处理孤立用户。不知道有没有风险？

在 2 节点 AG 中，假设一个节点不可达或宕机或崩溃，那么主节点上的日志文件大小将不断增长。

在这种情况下，除了以下方法之外，还有什么方法可以防止日志增长：

1. 从 AG 中移除另一个节点
2. 修复另一个节点的问题

日志备份对于时间点恢复和自动截断日志文件（在完整恢复模型中）以便为日志重用腾出空间很重要。

但是当由于网络问题或故障转移后无法访问辅助节点时，我了解到日志不断增长（因为它可以防止截断：https: //www.sqlshack.com/sql-server-transaction-log-growth-监控和管理/）。

在这种情况下，日志备份不会截断日志，那么这是否意味着发生的日志备份的行为类似于仅复制日志备份？也就是说 - 日志备份不会截断日志（因此每个后续日志备份的大小都会不断增长），但它还允许进行时间点恢复。

这是对日志备份行为的正确理解吗？

我拥有所有默认的 WSFC 和 AG 设置。同步和自动故障转移模式。

AG 有 2 个节点：Node1 & Node2

节点 1 是主节点。

我在 Node1 上重新启动了 sql server 服务，导致故障转移到 Node2。

然后，我在 Node2 上重启了 sql server 服务。但它并没有导致故障转移到 Node1。

当我在新主节点 (Node2) 上重新启动 sql 服务时，为什么 SQL AG 故障转移不起作用？

我正在探索扩展事件查询跟踪，并对以下几个奇怪的查询有疑问：

示例 1：

select top 10  *   from   (   SELECT [id]       ,[date]       ,[ordnum]       ,
[customer]  ,[amt]   ,[gm pc]   FROM [DbName].[dbo].[tblSales]  ) as [_]
where [date]>='2022-01-01T00:00:00.000'

示例 2：

select [_].[id],      [_].[date],   [_].[ordnum],  [_].[customer], [_].[amt], 
[_].[gm pc]  
from   (  SELECT [id] ,[date] ,[ordnum] ,  [customer]  ,[amt]  ,[gm pc]   
FROM [DbName].[dbo].[tblSales]  ) as [_]  where [_].[date] >= 
convert(datetime2, '2020-01-01 00:00:00') 
    and [_].[date] < convert(datetime2, '2021-01-01 00:00:00')

所以在子查询中它选择所有行。然后在外部查询中应用 where 条件。

如果它确实是这样工作的，那么这意味着子查询将进行全表扫描，然后将 where 子句应用于结果。或者这个查询是否得到优化，以便直接在表上应用 where 子句？