小编Joh*_*ell的帖子

我正在研究 SQL ServerREAD COMMITTED SNAPSHOT和SNAPSHOT隔离级别之间的差异，并发现以下资源：

选择基于行版本控制的隔离级别

对于大多数应用程序，由于以下原因，建议使用行版本控制读取提交隔离而不是快照隔离：

• 与快照隔离相比，它消耗的 tempdb 空间更少。

• 快照隔离容易受到更新冲突的影响，这些冲突不适用于使用行版本控制的已提交读隔离。当一个在快照隔离下运行的事务读取数据然后被另一个事务修改时，快照事务对相同数据的更新会导致更新冲突，事务终止并回滚。这不是使用行版本控制的已提交读隔离的问题。

我对这些主题有些陌生，但我似乎无法理解上面链接中的两个要点。

1. 为什么这些模式的 tempdb 空间会不同？一个存储比另一个更精细的版本控制吗？

2. 为什么快照隔离更容易受到更新冲突的影响？

我试图更好地理解（从概念上）统计、执行计划、存储过程执行之间的关系。

我说统计信息仅在为存储过程创建执行计划时使用，而在实际执行上下文中不使用，我说的对吗？换句话说，如果这是真的，一旦创建了计划（并假设它被正确重用），“最新”统计数据有多重要？

我读过的一篇文章（统计、行估计和升序日期列）特别激励我，该文章描述的场景与我每天面对的几个客户数据库非常相似。

在我们使用特定存储过程定期查询的最大表之一中，我们有一个升序日期/时间列。

当您每天添加十万行时，您如何防止执行计划变得陈旧？

如果我们经常更新统计信息来解决这个问题，在这个存储过程的查询中使用 OPTION (RECOMPILE) 提示是否有意义？

任何意见或建议将不胜感激。

更新：我使用的是 SQL Server 2012 (SP1)。

我昨天接到一位客户的电话，他抱怨 SQL Server 的 CPU 使用率过高。我们使用的是 SQL Server 2012 64 位 SE。服务器运行 Windows Server 2008 R2 Standard、2.20 GHz Intel Xeon（4 核）、16 GB RAM。

在确定罪魁祸首实际上是 SQL Server 之后，我使用此处的 DMV 查询查看了等待实例的顶部。前两个等待是： (1)PREEMPTIVE_OS_DELETESECURITYCONTEXT和 (2) SOS_SCHEDULER_YIELD。

编辑：这是“顶部等待查询”的结果（尽管今天早上有人违背我的意愿重新启动了服务器）：

我们做了很多密集的计算/转换，所以我可以理解SOS_SCHEDULER_YIELD。但是，我很好奇PREEMPTIVE_OS_DELETESECURITYCONTEXT等待类型以及为什么它可能是最高的。

我可以在此处找到关于此等待类型的最佳描述/讨论。它提到：

PREEMPTIVE_OS_ 等待类型是离开数据库引擎的调用，通常是到 Win32 API，并且在 SQL Server 之外为各种任务执行代码。在这种情况下，它正在删除以前用于远程资源访问的安全上下文。相关的API其实叫做DeleteSecurityContext()

据我所知，我们没有任何外部资源，如链接服务器或文件表。而且我们不进行任何模拟等操作。备份是否会导致此峰值或域控制器出现故障？

到底是什么导致这成为主要的等待类型？如何进一步跟踪这种等待类型？

编辑 2：我检查了 Windows 安全日志的内容。我看到一些可能感兴趣的条目，但我不确定这些是否正常：

Special privileges assigned to new logon.

Subject:
    Security ID:        NT SERVICE\MSSQLServerOLAPService
    Account Name:       MSSQLServerOLAPService
    Account Domain:     NT …

我有一个相当大的表（约 2 亿行），虽然统计数据是最新的WITH FULLSCAN，但我的直方图（限制为 200 步）是否可能过于宽泛，优化器无法做出正确的估计 - 换句话说，是不是已经不够“选择性”了？使用这个特定客户的数据库/表，我的查询计划估计与其他人相比相差甚远。

我关注的特定统计数据来自表的 PK/CLUSTERED INDEX。它是一个包含int( ParentId) 和smalldatetime( TimeStamp)的多列统计信息。

当我发出 a 时DBCC SHOW_STATISTICS('SomeTable', 'PK_SomeTable')，我得到以下输出（省略了直方图 - 但如果有帮助，我可以发布它）：

Name                    Updated              Rows       Rows Sampled    Steps   Density         Average key length  String Index    Filter Expression   Unfiltered Rows
PK_SomeTable            Jan 31 2014 10:59AM  181170887  181170887       200     2.022617E-05    8                   NO              NULL                181170887

All density     Average Length  Columns
0.0004892368    4               ParentId
5.519651E-09    8               ParentId, TimeStamp

我的大部分查询都是使用这两个列 (ParentId和TimeStamp)的组合来执行的。小的 all 密度值显示了这对的选择性 …

我一直在查看我们客户的一个 SQL Server 实例上的各种 PerfMon 指标，试图很好地衡量我们的数据库（或服务器）可以在哪里使用改进。

让我感到困惑的一项衡量标准是两个 PerfMon 指标的比率：编译/秒和批处理请求/秒。

根据这篇文章，“一般的经验法则是编译/秒应为总批处理请求数/秒的 10% 或更少”。

我们的应用程序有一个 Windows 服务，它每小时对数据库调用一次预定计算。就像发条一样，在我的 PerfMon CSV 数据中，我可以看到 Compilations/sec 和 Batch Requests/sec 的峰值。我没想到的是编译数/秒超过了批处理请求/秒。

我正在查看来自 PerfMon 的 15 秒样本，这些样本以我们的计算开始的时间为中心：

这通常表明什么？这甚至有意义吗？为什么我们要编译更多的语句而不是执行？我错过了什么吗？

问题陈述： 我们的支持工程师需要从客户那里获取数据库备份。目前，我们的数据库包含在一个 Primary/.mdf 文件组/文件中。这些数据库多年来一直在收集历史数据，并且越来越大。我们的工程师需要几天时间才能将备份复制到我们的办公室。

似乎没有任何规定/想法来管理数据库的增长。

最“有价值”的数据是我们系统的“配置”。它包含在大约 50 个表中，我们正在考虑将这些表移至与历史数据（将放置在数据文件组中）分开的新配置文件组，以尝试为部分或文件备份设置阶段。

但我不确定我需要哪种备份/恢复策略来完成这个 - 部分备份或文件备份？

出于研发目的，我有一个名为FilegroupDemo使用SIMPLE恢复模型的数据库。FilegroupDemo包含 3 个文件组：

• 主要（映射到 FilegroupDemo.mdf）
• 配置（映射到 FilegroupDemo_Configuration.ndf）
• 数据（映射到 FilegroupDemo_Data.ndf）

配置文件组中的数据不会经常更改，并且可能会被标记为只读（如果有帮助），而数据文件组中的数据每分钟更改一次。

我希望能够灵活地仅备份/恢复主文件组和配置文件组/文件。

在SQL Server Partial Backups的 BOL 文章中，它指出：

部分备份类似于完整数据库备份，但部分备份不包含所有文件组。相反，对于读写数据库，部分备份包含主文件组、每个读写文件组以及一个或多个只读文件（可选）中的数据。

这种读取方式让我认为部分备份旨在省略只读文件组，最有可能用于不会更改并标记为只读的大量数据。这些不需要每次都备份。

1. 我说存在部分备份是为了备份所有文件组（除了标记为只读的文件组）是否正确？换句话说，如果我不使用只读文件组，那么使用部分备份就没有意义了——对吗？而且我认为我不能使用部分备份来备份只读文件组？

因此，我不认为部分备份是我所需要的。我相当天真地尝试了文件备份/恢复。我将数据库切换到FULL恢复模式并运行：

BACKUP DATABASE FilegroupDemo FILEGROUP = N'PRIMARY'
TO DISK = N'C:\Backups\FilegroupDemo_FG_Primary.bak'
WITH INIT
GO

BACKUP DATABASE FilegroupDemo FILEGROUP = N'Configuration'
TO DISK = N'C:\Backups\FilegroupDemo_FG_Configuration.bak'
WITH INIT
GO

BACKUP DATABASE FilegroupDemo FILEGROUP …