小编var*_*ble的帖子

在日志传送配置中 - 主数据库必须处于完整或大容量日志恢复模式。但是，对从库的恢复模式有什么要求吗？

示例：假设主数据库和辅助数据库都处于完整恢复模式，如果发生故障转移并且辅助数据库成为新的主数据库，我们可以更改数据库恢复模式。

另请参阅：https : //www.microsoftpressstore.com/articles/article.aspx?p=2832586&seqNum=3并搜索“日志传送数据库必须使用完整恢复模型”。- 这样对吗？

我有一个完全恢复模式的数据库。

下周需要完成一百万行的计划插入。

为了不增加日志大小，我被告知有 2 个选项。

选项 1 是切换到批量模型，执行插入，然后切换到完整模型。这是完全有道理的。

选项 2 是切换到简单恢复模式，执行插入，然后切换到完整模式。这是真的吗？简单恢复模型在批量插入期间不会增加日志大小吗？我知道每个检查点都会清除日志，但是在批量插入期间会发生检查点吗？

在管理工作室选项卡中，假设我运行创建临时表的代码。

现在，如果我重新运行此代码，则会出现临时表已存在的错误。我可以打开一个新选项卡并运行此代码。发生这种情况是因为每个选项卡都是一个新会话。

我知道使用 drop 作为代码的初始部分是一种解决方案。但是，有什么方法可以在同一窗口中获取新会话（或重置会话），以便在重新运行代码时不必创建新选项卡？

无论 where 子句如何；

当表是堆（没有聚集索引）时，选择查询是否会使sql server锁定所有行，直到它完成读取所有行？

在具有聚集索引的表的情况下，sql server将逐一锁定行并在读取该行后立即释放它们？

有关此主题的任何参考链接都会非常有帮助。

SQL Server 分配有110GB 内存。

它正在消耗整个内存。

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

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

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

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

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

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

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

我的 SQL 2019 enterprise 系统内存为 180GB，最大 SQL Server 内存配置为 160GB。

有 3 个大型数据库，每个数据库大约 450GB。其他的是较小的数据库。

当我运行以下查询时：

SELECT
    databases.name AS database_name,
    COUNT(*) * 8 / 1024 AS mb_used
FROM sys.dm_os_buffer_descriptors
INNER JOIN sys.databases
ON databases.database_id = dm_os_buffer_descriptors.database_id
GROUP BY databases.name
ORDER BY COUNT(*) DESC;

输出是：

Db1 83443
Db2 35665
Db3 20112
Db4 3559
Db5 2236
Tempdb 988
Msdb 670
Ssisdb 21
Master 2
Model 0

以上合计为146696=143GB。

我并行安排了 3 个代理作业，1 个作业目标 1 db（针对 db1、db2 和 db3）。该作业对一些最大的数据库表一一执行 select *。我执行 SELECT * 的所有表的总大小约为 250GB。

我知道 …

运行以下命令后，我正在查看查询的输出：SET STATISTICS IO ON

表1显示扫描计数为5，逻辑读取12197

表2显示扫描计数为0，逻辑读取80

文档说

扫描计数是在任何方向到达叶级别后开始的查找或扫描次数，以检索所有值以构建输出的最终数据集。

我正在寻找一个示例来了解此（扫描计数）对于上述输出的含义。我的困惑是，仅 5 次扫描如何实现 12197 的逻辑读取？

我正在查看执行计划并从右到左阅读它。

例子：

1<-2<-3<-4
      ^
      |_5

所以4和5是并行执行的。当两者都完全完成时，则 3 完全执行，然后 2 完全运行，然后 1。

这是正确的还是可能存在以下情况：

1. 3 甚至在 4 和 5 完全完成之前就开始执行。

2. 2 甚至在 3 完全完成之前就开始执行。

我有 8 个 CPU 的 SQL Server。最大工作线程设置为 850。最大 dop 为 8。并行性的成本线程保持为 50。

这意味着 sql server 会将高于成本阈值的查询分解为 8 个线程。由于每个线程都在一个 cpu 上运行，那么这是否意味着在当前运行的 8 个线程中至少有一个被释放之前，不允许其他用户运行查询？

那么设置 max dop = cpu 数量会导致单个查询阻塞其他查询的情况吗？