我一直在阅读有关 SQL Server 中日志备份的 Microsoft 文档，并发现以下声明：
（日志备份）指定仅备份事务日志。日志从上次成功执行的日志备份开始备份到当前日志末尾。在创建第一个日志备份之前，您必须创建完整备份。”
由此我了解到，日志备份是备份上次日志备份以来的日志记录。但是，我也知道差异备份和完整备份也包含一些日志记录。这引出了我的问题：
日志备份是否还包括之前的完整备份或差异备份中备份的日志记录？或者日志备份是否严格备份从上次日志备份开始的日志记录，完整备份或差异备份不会干扰或影响后续日志备份中备份的内容？
任何见解将不胜感激。提前致谢！
我一直在使用 SQL Server 及其实例类型 - 默认和命名。我的理解一直是，要连接到命名实例，必须指定实例名称。但是，我最近发现，如果将 TCP 端口设置为 1433，我可以连接到命名实例，而无需指定实例名称，也无需设置别名。
我很想知道这是否是预期的行为。我无法找到任何解释或证实此行为的文档。谁能对此提供一些见解？当 TCP 端口设置为 1433 时，是否通常能够在不提供实例名称的情况下连接到命名实例？
我感谢对此事的任何澄清。
提前致谢！
您好 SQL Server 社区，
我正在尝试加深对 SQL Server 工作线程的理解，特别是关于繁忙的 OLTP 系统中的最大工作线程设置。我目前正在与sys.dm_os_threadsDMV 合作，正在探索如何最好地优化我们服务器上的线程管理。
我目前的理解是，如果默认的最大工作线程设置不变，SQL Server会根据系统的工作负载自动管理工作线程。SQL Server 可能会分配更多工作线程来处理增加的工作负载，并可能在任务完成后回收或销毁这些线程，尽管这可能不会立即发生。
然而，我并不完全确定我的理解是否正确，特别是当涉及到 SQL Server 可能已达到创建新线程的限制时。如果发生这种情况并且仍然有新的传入请求，是否会导致“调度程序死锁”情况？我们最近在我们的环境中遇到了这样的问题，我正在尝试了解这是否可能是原因。
鉴于此背景，我有几个问题：
我们将非常感谢您对此事的见解或建议。谢谢。
我一直在阅读SQL Server 文档并发现以下关于自动检查点的声明：
在后台自动发出以满足恢复间隔服务器配置选项建议的时间上限。自动检查点运行直至完成。自动检查点根据未完成写入的数量以及数据库引擎是否检测到写入延迟增加超过 50 毫秒来进行限制。
我试图理解“自动检查点运行至完成”的含义。我的母语不是英语，这句话对我来说听起来很奇怪。是否有任何检查点没有运行完成而只完成了一半的工作？
此外，我记得 Paul Randal 的一份声明，他提到如果 IO 延迟大于 20 毫秒，检查点进程将限制未完成的 IO。在关闭期间，该阈值增加到 100 毫秒以加快该过程。但是，SQL Server 文档建议使用 50 毫秒的阈值来限制自动检查点。阈值是否发生变化，或者我误解了这个概念？
对这些问题的任何澄清将不胜感激。
先感谢您！
我是公司数据库团队的一员，目前面临查询优化和性能方面的困境。每当我的一些同事遇到查询速度慢时，他们的默认解决方案就是创建索引来加快查询速度。这导致一些表有超过 70 个索引！
就我个人而言，我倾向于以不同的方式处理这个问题。我经常发现自己修改现有索引（例如添加额外的包含列等）以加快查询速度，而不是每次都创建新索引。然而，并非所有团队成员都采用这种方法，导致我们数据库中的索引数量不断增加。
尽管做出了这些努力，我还是注意到，随着索引数量的增加，其他 DML 操作的速度有所减慢。这似乎是一个第二十二条军规：没有索引，查询会很慢，但是有了索引，其他一切都会变慢一点。
我正在寻求有关如何应对这种情况的建议。有多少索引通常被认为“太多”？是否有任何最佳实践或策略来平衡快速查询的需求与整体数据库性能？
任何见解或资源将不胜感激。
谢谢你！
我目前正在使用 SQL Server 的fn_dblog功能，并且遇到了一个我无法理解的概念。在函数的结果中，有一个“页面 ID”列和一个“插槽 ID”列，该组合对应于单个日志记录。
我的问题是，这是否意味着一条日志记录只能（最多）描述单行的修改？
我试图更深入地了解 SQL Server 如何管理和表示数据修改，特别是 fn_dblog 函数，因此任何见解或资源将不胜感激。
我正在 SQL Server 中试验聚集索引和非聚集索引，我注意到一些有趣的事情。
这是我的 T-SQL 代码的简化版本：
IF OBJECT_ID('dbo.dept') IS NOT NULL DROP TABLE dbo.dept;
CREATE TABLE dept(id INT, name NVARCHAR(20), address NVARCHAR(50));
GO
INSERT INTO dept(id, name, address) VALUES (1, 'Dept 1', 'Sarjapur Road');
INSERT INTO dept(id, name, address) VALUES (2, 'Dept 2', 'Whitefield');
INSERT INTO dept(id, name, address) VALUES (3, 'Dept 3', 'Electronic City');
INSERT INTO dept(id, name, address) VALUES (4, 'Dept 4', 'Koramangala');
GO
CREATE CLUSTERED INDEX cl ON dbo.dept(id);
CREATE INDEX ncl ON dbo.dept(address);
GO
SELECT *, %%lockres%% lock, %%physloc%% physloc, sys.fn_PhysLocFormatter(%%physloc%%) formatted
FROM dbo.dept WITH (NOLOCK, INDEX (cl))
SELECT *, %%lockres%% lock, %%physloc%% physloc, sys.fn_PhysLocFormatter(%%physloc%%) formatted
FROM dbo.dept WITH (NOLOCK, INDEX (ncl))
这是结果：
+----+--------+-----------------+----------------+--------------------+------------+
| id | name | address | lock | physloc | formatted |
+----+--------+-----------------+----------------+--------------------+------------+
| 1 | Dept 1 | Sarjapur Road | (de42f79bc795) | 0xB01F000004000000 | (4:8112:0) |
| 2 | Dept 2 | Whitefield | (9d6bf8154a2a) | 0xB01F000004000100 | (4:8112:1) |
| 3 | Dept 3 | Electronic City | (052c8c7d9727) | 0xB01F000004000200 | (4:8112:2) |
| 4 | Dept 4 | Koramangala | (1a39e6095155) | 0xB01F000004000300 | (4:8112:3) |
+----+--------+-----------------+----------------+--------------------+------------+
+----+--------+-----------------+----------------+--------------------+-----------+
| id | name | address | lock | physloc | formatted |
+----+--------+-----------------+----------------+--------------------+-----------+
| 3 | Dept 3 | Electronic City | (b64f1cd4ff4f) | 0x1800000003000000 | (3:24:0) |
| 4 | Dept 4 | Koramangala | (4471456166ef) | 0x1800000003000100 | (3:24:1) |
| 1 | Dept 1 | Sarjapur Road | (7948805432b9) | 0x1800000003000200 | (3:24:2) |
| 2 | Dept 2 | Whitefield | (584262fe5906) | 0x1800000003000300 | (3:24:3) |
+----+--------+-----------------+----------------+--------------------+-----------+
正如您所看到的，两个结果集的锁和 physloc 非常不同。过去，我一直相信这些伪列揭示了有关表dbo.dept（聚集索引或堆）的信息，因为我是从中进行选择的。但这次测试似乎证明它们正在显示有关如何访问数据的信息。我的理解正确吗？
我一直在阅读Paul Randal 撰写的关于 SQL Server 备份过程的博客文章，其中概述了完整备份的主要阶段。他提到的一点是，在完整备份期间，进程会读取“所有分配的盘区，无论该盘区中的所有 8 个页面是否都在使用中”。
完整备份有以下主要阶段：
- 执行检查点。
- 从数据文件中读取所有正在使用的数据（从技术上讲，读取所有分配的盘区，无论盘区中的所有 8 个页面是否都在使用）。
- 读取从初始检查点最旧的未提交事务开始到第 2 阶段完成的时间的所有事务日志。这是必要的，以便数据库可以在恢复过程中恢复到一致的时间点（有关更多详细信息，请参阅这篇文章）。
- （可选地测试所有页面校验和，可选地执行备份压缩，并且可选地执行备份加密）。
这个说法让我想知道到底备份了什么内容。具体来说，备份过程是否包括所有分配的扩展区，即使这些扩展区中的所有页面并未都在使用中？
如果您对此主题有任何见解或澄清，我将不胜感激。预先感谢您的帮助！
下面的两个会话尝试更新同一行的场景由 Paul White 提供。
场景一：
- 会话 1
U在读取时获取基表行的锁。- 会话 2 阻塞，等待获取
U基表中的同一行。- 会话 1 将值设置为 10 并提交。
- 会话 2 获取了它的
U锁并且发现没有什么可做的，因为现在 Value != 0。结果：值设置为 10。
根据 Paul 的说法，会话 2 已经找到了需要更新的行，但它被阻止了。当阻塞消失并且会话 2 获得 U 锁时，它需要再次检查条件吗？我理解正确吗？对我来说这有点奇怪。会话找到了这一行，这是因为它评估了导致识别该行的过滤器。为什么在实际更新之前需要再次检查条件？
我的一个生产数据库日志文件驱动器已满，我在 SQL Server 错误日志中注意到以下消息。
2022-02-13 03:16:24.500 spid72 Error: 9002, Severity: 17, State: 4.
2022-02-13 03:16:24.500 spid72 The transaction log for database 'huge_database' is full due to 'ACTIVE_TRANSACTION'.
2022-02-13 03:16:26.060 spid72 Error: 9002, Severity: 17, State: 4.
2022-02-13 03:16:26.060 spid72 The transaction log for database 'huge_database' is full due to 'ACTIVE_TRANSACTION'.
2022-02-13 03:16:26.070 spid72 Error: 3314, Severity: 21, State: 3.
2022-02-13 03:16:26.070 spid72 During undoing of a logged operation in database 'huge_database', an error occurred at log record ID (2766:550754:254). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
2022-02-13 03:16:26.090 spid72 Database huge_database was shutdown due to error 3314 in routine 'XdesRMReadWrite::RollbackToLsn'. Restart for non-snapshot databases will be attempted after all connections to the database are aborted.
2022-02-13 03:16:26.090 spid72 Error: 3314, Severity: 21, State: 5.
2022-02-13 03:16:26.090 spid72 During undoing of a logged operation in database 'huge_database', an error occurred at log record ID (2678:51796:1). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
2022-02-13 03:16:32.900 spid48s Starting up database 'huge_database'.
2022-02-13 03:16:37.980 spid48s Recovery of database 'huge_database' (20) is 0% complete (approximately 89573 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
2022-02-13 03:16:57.980 spid48s Recovery of database 'huge_database' (20) is 0% complete (approximately 60835 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
...
2022-02-13 04:26:15.160 spid36s Recovery of database 'huge_database' (20) is 85% complete (approximately 721 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
...
2022-02-13 04:36:35.230 spid36s Recovery of database 'huge_database' (20) is 99% complete (approximately 1 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
2022-02-13 04:36:35.790 spid36s 1 transactions rolled back in database 'huge_database' (20:0). This is an informational message only. No user action is required.
2022-02-13 04:36:35.790 spid36s Recovery is writing a checkpoint in database 'huge_database' (20). This is an informational message only. No user action is required.
2022-02-13 04:36:36.850 spid36s Recovery completed for database huge_database (database ID 20) in 4804 second(s) (analysis 4881 ms, redo 1196931 ms, undo 3600721 ms.) This is an informational message only. No user action is required.
所以看起来数据库日志驱动器已满，并且它启动了恢复过程，花了一个多小时。为什么在这种情况下需要恢复？我想重现它但失败了。下面是我的代码：
CREATE DATABASE MyDatabase
ON
(NAME = MyDatabase_Data,
FILENAME = 'f:\mssql\data\MyDatabase_Data.mdf',
SIZE = 10MB,
MAXSIZE = 1000MB,
FILEGROWTH = 5MB)
LOG ON
(NAME = MyDatabase_Log,
FILENAME = 'U:\data\MyDatabase_Log.ldf',
SIZE = 5MB,
MAXSIZE = 500MB,
FILEGROWTH = 1MB);
GO
USE MyDatabase;
GO
CREATE TABLE MyTable (
ID INT IDENTITY(1,1) PRIMARY KEY,
Data VARCHAR(MAX) NOT NULL
);
GO
BEGIN TRANSACTION;
DECLARE @i INT = 0;
WHILE @i < 1000000
BEGIN
INSERT INTO MyTable (Data) VALUES (REPLICATE('A', 8000));
SET @i = @i + 1;
END;
-- Don't commit the transaction
-- COMMIT TRANSACTION;
当我运行我的代码时，我在 SSMS 中得到了以下信息：
消息 9002，级别 17，状态 4，第 30 行 数据库“MyDatabase”的事务日志因“ACTIVE_TRANSACTION”而已满，并且保留 lsn 为 (39:24:1)。
SQL Server 错误日志中的内容如下：
2023-08-18 02:59:54.200 spid84 Error: 17053, Severity: 16, State: 1.
2023-08-18 02:59:54.200 spid84 U:\data\MyDatabase_Log.ldf: Operating system error 112(There is not enough space on the disk.) encountered.
2023-08-18 02:59:55.200 spid84 Error: 9002, Severity: 17, State: 4.
2023-08-18 02:59:55.200 spid84 The transaction log for database 'MyDatabase' is full due to 'ACTIVE_TRANSACTION' and the holdup lsn is (39:24:1).
没有恢复过程。为什么？如何模拟我的生产数据库问题？
顺便说一句，在恢复生产数据库期间，我仍然可以访问它。它仍然与 sys.databases 中的其他数据库具有相同的状态。这是预期的吗？我虽然无法访问恢复中的数据库。
在撤消数据库“huge_database”中记录的操作期间，日志记录 ID (2678:51796:1) 发生错误。
这个错误日志听起来像是 SQL 没有预留足够的空间来回滚。我记得Paul Randal说过SQL Server总是保留一些日志用于回滚。如果是这样，为什么会发生这种情况？
我正在使用 SQL Server，我有两个表，table1并且table2. 两个表都有一个DATETIME表示为 的列dt。我不仅需要根据某些条件连接这些表，还要确保匹配的行具有列中相同的日期（此处不考虑时间）dt。
这是我当前使用的查询：
select *
From table1 a inner join table2 b
on a.id = b.a_id
and convert(date, a.dt) = convert(date, b.dt)
该查询可以获取我需要的结果，但我担心它的性能，尤其是当表大小增加时。
我想知道是否有更高效的方法可以达到相同的结果？是否有技术或 SQL Server 功能可以帮助我优化此查询，尤其是日期比较部分？
任何意见或建议将不胜感激。先感谢您。
我正在 SQL Server 中处理扩展事件会话，并遇到了我不完全理解的 T-SQL 代码的一部分。具体来说，我对以下代码部分中使用“Mode = 3 OR Mode = 4”感到困惑：
...
ADD EVENT sqlserver.latch_suspend_end
(WHERE (
Duration > 0
AND (Mode = 3 OR Mode = 4)
AND has_waiters = 1
)
)
...
我一直在尝试寻找文档或任何类型的信息来解释“Mode = 3”和“Mode = 4”在这种情况下代表什么，但到目前为止，我还没有运气。
此外，我有兴趣找到描述不同事件的属性和可能值的文档或参考的综合来源，而不仅仅是针对这个特定示例。有人可以向我指出相关文档或解释这些模式值在此扩展事件会话中的含义吗？
预先感谢您的帮助！
DBCC INPUTBUFFER我知道SQL Server中有一个命令，
对我来说，输入缓冲区似乎是会话正在运行的 SQL。
SQL Server 也有sys.dm_exec_sql_text，
并且sys.dm_exec_input_buffer，其中
我有点困惑。对我来说，它们看起来非常相似且难以辨认。
我还看到了Jonathan Kehayias 的一篇文章 Understanding the sql_text Action in Extended Events。他在文章中指出
创建此事件会话后，我们可以在环境中运行几个不同的测试场景，以显示此操作如何不是 sql_text，而是正在触发的事件的 input_buffer
他非常确信 SQL 文本不是输入缓冲区，我不明白其中的原因。有人可以帮忙澄清一下吗？谢谢。
RESTORE FILELISTONLY我试图理解SQL Server 中命令的输出中“大小”列与差异备份和日志备份一起使用时的含义。
对于完整备份，我理解“大小”值代表恢复备份后磁盘上的文件大小。但是，我不确定如何解释差异备份和日志备份的该值。是不是意味着恢复备份后，磁盘上的文件会增加这个大小？
RESTORE FILELISTONLY以下是差异备份结果的示例：
+-------------+---------------+------+---------------+----------+
| LogicalName | PhysicalName | Type | FileGroupName | Size |
+-------------+---------------+------+---------------+----------+
| dx | F:\dx.mdf | D | PRIMARY | 83788608 |
| dx_log | F:\dx_log.ldf | L | NULL | 46385562 |
+-------------+---------------+------+---------------+----------+
这是日志备份的示例：
+-------------+---------------+------+---------------+----------+
| LogicalName | PhysicalName | Type | FileGroupName | Size |
+-------------+---------------+------+---------------+----------+
| dx | F:\dx.mdf | D | PRIMARY | 19386301 |
| dx_log | F:\dx_log.ldf | L | NULL | 3327087 |
+-------------+---------------+------+---------------+----------+
有人可以帮助我理解这些场景中的“大小”列吗？
我正在对 SQL Server 中的可用性组进行一些测试。当我位于主副本上时，我可以看到所有副本节点上都有刷新图标。
但是，当我检查辅助副本时，所有其他节点的副本名称上都有一个问号。这是什么意思？
顺便说一句，我正在将 SSMS 18 与 SQL Server 2022 一起使用。
我有以下 TSQL 语句，该语句通常在多个会话中并行执行，并导致严重的 pagelatch_ex 等待：
DELETE dbo.huge_table1
WHERE c1 = 0
AND c3 IN (SELECT v FROM dbo.string_split(@c3_list));
我捕获了工作负载，发现很多时候，传入的 @c3_list 导致没有行被删除。考虑到 DELETE 总是需要独占锁，我想知道以下重写是否可以帮助减少 pagelatch_ex 等待。它本质上将 DELETE 分为两个步骤：首先检查是否有需要删除的行，然后删除它们。
INSERT INTO #tmp (c3)
SELECT c3
FROM dbo.huge_table1
WHERE c1 = 0
AND c3 IN (SELECT v FROM dbo.string_split(@c3_list) );
IF @@rowcount > 0
DELETE t1
FROM dbo.huge_table1 t1
JOIN #tmp t2
ON t2.c3 = t1.c3;
我的逻辑是 select 语句仅采用 pagelatch_sh 锁存器。如果不需要删除任何行，则不会生成不必要的pagelatch_ex。
此重写有助于减少 pagelatch_ex 等待吗？预先感谢您的任何见解！
我在 SQL Server 文档中注意到，日志序列号 (LSN) 有时被描述为数字 (25,0)，有时被描述为二进制 (10)。为什么 LSN 使用两种不同的数据类型？我什么时候应该使用每种类型？
LSN 是数据类型 numeric(25,0) 的值。算术运算（例如，加法或减法）没有意义，不得与 LSN 一起使用。
start_lsn 二进制文件（10）
在 SQL Server 中，我们可以使用set statistics profile on启用会话分析。然后你可以执行任意一条语句，对应的执行计划会以表格的形式显示出来。是否可以将这个流行的表单计划保存到某个表中，以便我可以对其进行过滤？
此 tablet 表单执行计划的示例如下所示：
我最近注意到我的 SQL Server 错误日志中有一条错误消息，内容为“查询处理器耗尽内部资源，无法生成查询计划”。我怀疑我的服务器可能内存或 CPU 资源不足。但是，我不确定如何确认这一点。
我知道 sysprocesses 和 sp_whoisactive 命令，但我不确定它们是否可以告诉我此时我的服务器是否资源不足。
有人可以为我提供一些有关如何检查我的 SQL Server 当前是否耗尽内存或 CPU 资源的指导吗？任何帮助，将不胜感激。
我注意到有两种命令语法可以更改 SQL Server 中的数据库配置设置 - ALTER DATABASE SCOPED CONFIGURATION 和 ALTER DATABASE SET。但是，我不清楚每种语法下哪些数据库设置。
例如，我知道数据库兼容性是特定于数据库的设置，但它使用 ALTER DATABASE SET 语法。这让我想知道为什么它不使用 ALTER DATABASE SCOPED CONFIGURATION 语法。
所以，我的问题是：您是否有任何心理指南可以帮助确定哪些数据库设置属于哪种语法？我将不胜感激有关此主题的任何见解或信息。