小编Rau*_*DBA的帖子

我想问一个关于恢复数据库操作时恢复过程的问题。假设我恢复了一个完整备份，NORECOVERY然后使用NORECOVERY. 最后，我将使用RECOVERY关键字恢复最后的第三个 t-log 备份。

问题是：当我使用RECOVERY关键字恢复最后一个 t-log 备份时，SQL Server 执行重做和撤消阶段还是只执行撤消阶段？

在我看来，当我们使用NORECOVERY关键字恢复备份时，SQL Server 也会执行重做阶段。与使用standby 关键字恢复t-log 备份相同。在这种情况下，SQL Server 会创建一个单独的文件，其名称仅包含“ undo ”而不包含任何“ redo ”。

我是 DBA 新手，在学习不同类型的备份时，我想到了一个问题。所以问题是，上次差异备份中会有什么，只是之前差异备份的总和或之前备份加上 t-log 备份的总和？假设我有以下备份：

full_backup_2018_05_09_000000.bak
tran_backup_2018_05_09_003500.trn
tran_backup_2018_05_09_004000.trn
diff_backup_2018_05_09_004500.bak
tran_backup_2018_05_09_005000.trn
tran_backup_2018_05_09_005500.trn
diff_backup_2018_05_09_006000.bak
tran_backup_2018_05_09_006500.trn
tran_backup_2018_05_09_007000.trn
tran_backup_2018_05_09_007500.trn
diff_backup_2018_05_09_008000.bak

当我无法使用传统方式连接到SQL Server（原因是删除登录触发器）时，DAC引起了我的注意。我在网上做了一些搜索，结果发现访问服务器的唯一方法是使用 DAC 连接，不幸的是默认情况下该连接是关闭的。但是，我仅使用 sqlcmd 就能够解决这个问题（我删除了触发器）。

我的问题是，如果我可以仅使用 sqlcmd 连接到 SQL Server，那么 DAC 的用途是什么？

我使用 64 位操作系统和两个 CPU（每个 CPU 有 7 个逻辑处理器），逻辑处理器总数等于 14。

当我运行此代码时，我得到2048

SELECT max_workers_count FROM sys.dm_os_sys_info

另一方面，当我使用下面的公式时，我得到了完全不同的数字，即672

For a 64-bit operating system:
Total available logical CPUs <= 4
Max Worker Threads = 512
Total available logical CPUs > 4
Max Worker Threads = 512 + ((logical CPUs - 4)*16)

你能向我解释为什么我得到不同的数字吗？我在另一台服务器上对其进行了测试，两种情况的数字都完全相同。

编辑

PS 感谢 Dan Guzman 建议检查最大工作线程的服务器设置。这就是 EXEC sp_configure 'max worker threads' 返回的内容：

我阅读了Brent Ozar 发表的一篇很棒的文章，并提出了一些与内存授予相关的问题。我无法在他文章的评论部分回答我的问题，所以我想从这里得到任何帮助。

1. 问题：有多少数据溢出到磁盘中？ 400 MB还是60 MB (7643KB*8)？

他在文章中指出：

而且无论我更新统计信息多少次，我仍然会得到大约400MB 的磁盘溢出。

我在这里有点困惑（

2. 问题：如果估计一切正常，统计数据是最新的，盒子有足够的内存，并且当时没有查询在运行，那么为什么会发生溢出到磁盘？

查看估计的行数与实际的行数。它们是相同的。统计数据很好。

我也没有使用小型服务器：我的虚拟机有 32GB 的 RAM，我已将其中的 28GB 分配给 SQL Server。没有其他查询同时运行——这只是一个孤独的查询，溢出到磁盘......

我遇到了与自动故障转移相关的异常行为，因此在关闭 SQL Server 服务的情况下自动故障转移不起作用。集群磁盘似乎仍然连接到故障节点，但我无法找出导致此行为的最终问题。如果您能帮助我理解这个问题，我将非常感谢您。

出于测试目的，我在域控制器上创建了 iSCSI 目标，并连接了 2 个启动器：

以下是有关我的集群的详细信息：

以下是有关我的 SQL Server 服务的详细信息：

以下是有关集群磁盘的详细信息（我只添加了其中一个磁盘的详细信息，因为两个磁盘是相同的）：

现在，当我关闭 SQL Server 服务时，不会发生服务的自动故障转移：

我测试了自动故障转移成功运行的其他场景：

1. 手动故障转移
2. 关闭活动节点
3. 在活动节点上禁用适配器
4. 在任务管理器中杀死sql server进程
5. 在任务管理器中杀死sql代理服务进程

在上述所有场景中，资源均成功故障转移到另一个节点。

您能否帮我弄清楚当我关闭活动节点上的 SQL Server 服务时自动故障转移出了什么问题？

下面我有一个代码来获取有关服务器中每个数据库的 t-log 备份的信息。我想从这个列表中排除 tempdb。

exec sp_MSforeachdb 'SELECT server_name, sysdb.name AS DatabaseName, bkup.user_name AS [User],
ceiling(bkup.backup_size /1048576) as ''Size Meg'' ,
cast((bkup.backup_size /1073741824) as decimal (9,2)) as ''Gig'',
bkup.backup_start_date AS [Backup Started],
bkup.backup_finish_date AS [Backup Finished (Last BackUp Time)],
CAST((CAST(DATEDIFF(s, bkup.backup_start_date, bkup.backup_finish_date) AS int))/3600 AS varchar) + '' hours, ''
+ CAST(DATEDIFF(mi, bkup.backup_start_date, bkup.backup_finish_date) - (DATEDIFF(mi, bkup.backup_start_date, bkup.backup_finish_date)/60)*60 AS varchar) + '' minutes, ''
+ CAST((CAST(DATEDIFF(s, bkup.backup_start_date, bkup.backup_finish_date) AS int))%60 AS varchar)+ '' seconds'' AS [Total Time]
,DATEDIFF(DAY,CONVERT(CHAR(8),backup_finish_date,112),CONVERT(CHAR(8),expiration_date,112)) AS expiration_days
,bms.description …

我正在尝试执行以下语句，该语句创建一个名为 service2019 的数据库：

DECLARE @dbname VARCHAR(50);
SET @dbname = 'service' + CAST(YEAR(GETDATE()) AS VARCHAR(4));


EXEC (
'CREATE DATABASE ' + @dbname  + ' ON  PRIMARY 
( NAME =' + '' + @dbname +'' + ', FILENAME = ''C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014TEST\MSSQL\DATA\''' + '''' + @dbname + '''' + '''.mdf'''  + ', SIZE = 10MB , MAXSIZE = UNLIMITED, FILEGROWTH = 100KB )
 LOG ON 
( NAME =' + '' + @dbname + '_log' + ', FILENAME = ''C:\Program Files\Microsoft SQL …