小编var*_*ble的帖子

我正在查看dm_exec_sessions并请求生产服务器上的 DMV。有些查询的状态为“已暂停”，持续时间为 12 分钟，等待类型为ASYNC_NETWORK_IO。

我理解这是因为客户端应用程序获取数据的速度不够快（或者结果太大以至于客户端程序需要时间来消耗它）。

这样的查询（由于正在进行的查询而暂停ASYNC_NETWORK_IO）是否会导致该表阻塞？

该查询是 a SELECT，我看不到该查询阻止任何其他查询。因此我要问的问题是它是否有可能阻止任何东西。

例如：是否ASYNC_NETWORK_IO意味着执行正在进行或执行已完成并且客户端应用程序正在提取数据？在后一种情况下，我不明白为什么这个查询可能会阻止其他查询，因为它已经产生了结果。

查询持有的锁如下：

• 页面锁定请求方式S
• 对象锁请求方式IS

假设我有以下情况：

事务 1 使用 WHERE 子句执行 UPDATE，但尚未提交。

UPDATE TBL SET VAL1=10 WHERE VAL2=100

事务 2 尝试 SELECT 不属于上述 WHERE 子句的行。假设存在索引，并且数据库引擎决定对表、页采用 IX 锁，对属于 WHERE 子句的行采用 X 锁，则该查询将起作用。

现在，假设事务 2 是对不属于 SELECT 查询的 WHERE 子句的行的 UPDATE 查询。

UPDATE TBL SET VAL2=100 WHERE VAL1=500

当上面的查询运行时，假设如上所述持有相同的锁，则会导致更多行满足 VAL2=100 条件（这也是第一次 UPDATE 中的 WHERE 子句）。SQL如何处理这种情况呢？

例如，当sql server看到事务2的更新时，它是否意识到这一点并将事务1的锁升级为表锁，并且不允许事务2的更新发生？

我通过 SAN 磁盘工具配置了数据库备份。在备份集表中，我可以看到 VSS 编写器服务正在进行快照类型的完整备份。

服务器上有85个数据库。

我了解数据库快照的概念，最初它的大小为 0。当源数据库更新时，它将更改推送到快照，从而增加快照大小。

我想问是否：

1. 数据库快照和VSS数据库快照备份（通过VSS writer服务）是同一个概念吗？

2. 对于数据库快照和 vss 数据库快照备份 - 假设有 85 个项目（快照/快照备份），那么这将导致 sql server 上的整体 IO 较差，因为它必须定期维护（随着源数据库发生更改而更新）快照85 个数据库？

假设我在凌晨 12 点进行完整备份。然后每小时记录一次备份。

然后假设在晚上 8.30 我进行手动日志备份（从而截断日志）并删除该文件。这样后续晚上9点的日志备份就会有不完整的日志。

因此，从晚上 8 点到凌晨 12 点的时间点恢复数据是不可能的。

现在中午 12 点将进行另一次完整备份。随后像往常一样每小时进行一次日志备份。现在假设下午 4.30 发生崩溃。

在此完整备份之前进行的手动日志备份是否会使完整备份后的正常日志备份变得无用？或者只有上次手动日志备份到上次完整备份的日志没有用？

select * from sys.dm_tran_locks
where resource_database_id=db_id() 

我正在使用上面的查询来监视锁。

当 SELECT 查询在没有关键字的情况下运行时WITH(NOLOCK)，我可以看到授予以下锁：S、IS

当我使用关键字时WITH(NOLOCK)，我可以看到授予以下锁：Sch-S

既然涉及到锁（共享锁），就意味着它不会阻塞其他读取者。此外，由于该关键字允许脏读，因此它意味着它可以读取正在由尚未提交的事务修改的行。

但我的理解是，行/表上的共享锁将阻止该行/表被写入。这个概念是否也适用于 Sch-S 和关键字所采用的任何其他锁（如果有）with(nolock)？

我尝试复制此处给出的场景： https: //www.sqlskills.com/blogs/paul/the-curious-case-of-the-bulk_operation-lock-during-a-heap-nolock-scan/

创建了 2 个表 - table1 带有聚集索引，table2 没有任何索引。

当我在 table1 上编写选择查询时with (lock)，会应用 Sch-S 锁。同样，当我在 table2 上编写相同的查询时，也有一个 Sch-S 锁。

这两种情况都应用了 S 锁，如上面的链接所示。

要检查锁，我使用以下查询：

SELECT * FROM sys.dm_tran_locks
  WHERE resource_database_id = DB_ID()
  AND resource_associated_entity_id = OBJECT_ID(N'dbo.table1');

是否使用 nolock 块写入器从堆（没有聚集索引的表）中选择数据？

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

示例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 子句直接应用于表？

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

SQL Server 分配有110GB 内存。

它正在消耗整个内存。

我想了解是否存在内存压力。

通常，SQL Server 将从内存中删除旧页面（当前不需要）并从磁盘中提取所需的页面。然而，当存在内存压力时——（假设内存中的所有页面都被需要并被积极使用）SQL Server将利用磁盘上的页面文件作为备用内存区域。

什么 perfmon 指标可以帮助我监控 SQL Server 内存是否面临压力（即正在使用磁盘页面文件）？

我知道内存：页面错误/秒 - 但这不仅限于 SQL 服务器内存压力。还有哪些其他性能指标可以帮助我？

当 INSERT 查询被触发时，SQL Server 将其记录在其日志中并向用户发送查询已完成的确认。同时它还更新数据页面。这两者（日志和数据页）都驻留在内存中。

无论恢复模式如何（简单、批量或完整），每当发生检查点时，SQL Server 都会将日志和脏页从内存刷新到磁盘。

问题：假设在向用户发送确认后、检查点之前发生电源故障，那么，由于内存中的日志尚未写入磁盘，即使用户已收到确认，此 INSERT 操作是否会丢失？这是否违反了 ACID 的持久特性？