Microsoft tempdb 数据库的 SQL Server I/O 子系统要求

2025-06-12

本文介绍 SQL Server 中 tempdb 数据库的 I/O 子系统要求。

原始产品版本： Microsoft SQL Server
原始 KB 数： 917047

总结

Microsoft SQL Server 要求用于存储系统和用户数据库的 I/O 子系统通过特定的 I/O 主体完全遵循预写日志记录（WAL）要求。为了遵守事务的 ACID 属性，需要满足这些要求：原子、一致、独立和持久。 SQL Server I/O 基础知识中提供了有关 I/O 子系统符合性要求的详细信息。

以下列表简要概述了这些要求：

必须维护写入顺序。
必须保持依赖写入一致性。
必须始终在稳定介质中/在稳定介质上保护写入。
必须发生撕裂的 I/O 防护。

持久性维护对于所有其他数据库来说仍然至关重要，但可能会放宽 tempdb 数据库。下表总结了 SQL Server 数据库的关键 I/O 要求。

I/O 要求	简要描述	系统或用户	tempdb（临时数据库）
写入排序依赖写入一致性	子系统保持写入操作的正确顺序的能力。这对于镜像解决方案、组一致性要求和 SQL Server WAL 协议的使用尤其重要。	必须	建议
写入后读取	在成功完成任何写入后发出读取请求时，子系统能够使用最新数据映像为读取请求提供服务。	必须	必须
中断的生存	数据在中断（如系统重启）时保持完全完好（Durable）的能力。	必须	不适用
撕裂的 I/O 防护	系统避免拆分单个 I/O 请求的能力。	必须	建议
扇区重写	该扇区只能全部写入，并且由于附近扇区的写入请求而无法重写。	* 不鼓励，仅在事务性的情况下才允许	* 不鼓励，仅在事务性的情况下才允许
强化的数据	预期在写入请求或 FlushFileBuffers 操作成功完成时，数据已保存到稳定的媒体。	必须	不适用
物理扇区对齐和大小	SQL Server 会询问数据和日志文件存储位置。所有设备都需要支持扇区属性，使 SQL Server 能够对物理扇区对齐边界和扇区大小的倍数执行写入。	必须	必须

事务扇区重写涉及子系统的完全记录操作，允许完全移动、替换或回滚到原始映像的扇区。通常不建议进行这些重写，因为执行此类操作所需的额外开销。此示例是移动 defragmentation 文件数据的实用工具。在保护新扇区和数据之前，文件中的原始扇区不能替换为新的扇区位置。必须以事务方式重新映射扇区，使任何故障（包括电源故障）都会导致重新建立原始数据。确保在此过程中提供锁定机制，以防止数据访问无效，从而维护 SQL Server I/O 的其他租户。

中断的生存

tempdb 数据库是 SQL Server 的暂存区域，并在每次 SQL Server 启动时重新生成。初始化取代了数据在重启后所需的任何需求。

事务部门重写操作

若要保证恢复过程（如回滚和崩溃恢复）的成功，必须在存储数据页之前正确存储在稳定介质上，并且不能在不遵循事务属性的情况下重写日志记录。这要求子系统和 SQL Server 维护特定属性，例如写入顺序、扇区对齐和大小写入，以及前面提到的文档中列出的其他此类 I/O 安全属性。对于 tempdb 数据库，不需要崩溃恢复，因为数据库始终在 SQL Server 启动期间初始化。但是，tempdb 数据库仍需要回滚功能。因此，可以放宽 WAL 协议的某些属性。

tempdb 数据库的存储位置必须严格按照已建立的磁盘驱动器协议进行操作。在各种方面，存储 tempdb 数据库的设备必须显示并充当提供写入功能后读取的物理磁盘。事务扇区重写操作可能是特定实现的附加要求。例如，SQL Server 不支持使用 NTFS 文件系统压缩进行数据库修改，因为 NTFS 压缩可以重写已写入并被视为强化的日志扇区。这种重写过程中的失败可能导致数据库不可用，从而破坏 SQL Server 已认为安全的数据。

注意

SQL Server 扩展支持或压缩，以只读数据库和文件组。有关完整详细信息，请参阅 SQL Server 联机丛书。

事务扇区重写操作与包含 tempdb 数据库的所有 SQL Server 数据库相关。越来越多的扩展存储技术使用设备和实用工具，这些设备和实用工具可以重写 SQL Server 认为安全的数据。例如，某些新兴技术执行内存中缓存或数据压缩。为了避免严重数据库损坏，任何扇区重写都必须具有完全事务支持，这样一来，如果发生故障，数据将回滚到以前的扇区映像。这可以保证 SQL Server 永远不会受到意外中断或数据损坏情况的侵害。

可以将 tempdb 数据库置于专用子系统上，例如 RAM 磁盘、固态或其他不能用于其他数据库的高速实现。但是，评估这些选项时，必须考虑“更多信息”部分中显示的关键因素。

注意

故障转移群集环境中的本地磁盘仅支持固态或高速实现。这是因为只能通过 iSCSI 目标创建 RAM 磁盘。此外，无法在同一主机上使用 iSCSI 目标和故障转移群集功能。

详细信息

评估 tempdb 数据库的存储位置时，应仔细研究几个因素。例如，tempdb 数据库使用情况包括但不限于内存占用、查询计划和 I/O 决策。 tempdb 数据库的相应优化和实现可以提高系统的可伸缩性和响应能力。本部分讨论确定 tempdb 数据库的存储需求的关键因素。

高速子系统

市场上提供了各种高速子系统实现，这些实现提供 SQL Server I/O 子系统协议要求，但不提供媒体的持久性。

重要

始终与产品供应商确认，以确保完全符合 SQL Server I/O 需求。

RAM 磁盘是此类实现的一个常见示例。 RAM 磁盘安装必要的驱动程序，并使主 RAM 磁盘的一部分像附加到系统的任何磁盘驱动器一样正常运行。所有 I/O 子系统都应完全符合 SQL Server I/O 要求。但是，很明显，RAM 磁盘不是持久介质。因此，RAM 磁盘等实现只能用作 tempdb 数据库的位置，不能用于任何其他数据库。

实现和部署之前要考虑的密钥

在此类子系统上部署 tempdb 数据库之前，需要考虑一些要点。本部分使用 RAM 磁盘作为讨论的基础，但在其他高速实现中也会出现类似的结果。

I/O 安全性

写入后读取和事务性扇区写入的符合性是必须的。从不完全支持 SQL Server I/O 要求的任何系统上部署 SQL Server，否则可能会损坏和丢失数据。

已缓存的页面（双 RAM 缓存）

临时表与数据库中的所有其他表一样。它们由缓冲池缓存，并由延迟写入操作处理。将临时表页存储在 RAM 磁盘上会导致双 RAM 缓存，一个位于缓冲池中，另一个存储在 RAM 磁盘上。这可以直接从缓冲池的总大小中消失，并且通常会降低 SQL Server 的性能。

放弃 RAM

RAM 磁盘将主 RAM 的一部分指定为名称。可以使用 RAM 磁盘和基于 RAM 的文件缓存的多个实现。有些还启用物理 I/O 支持操作。基于 RAM 的文件缓存的关键元素是它直接从 SQL Server 可以使用的物理内存中获取。始终有力证据表明添加基于 RAM 的文件缓存可以提高应用程序性能，并且不会降低其他查询或应用程序性能。

先优化

应用程序应优化以删除可能导致使用 tempdb 数据库的不必要的不必要的排序和哈希。多次添加索引可以完全消除对计划中的排序或哈希的需求，从而获得最佳性能，而无需使用 tempdb 数据库。

可能的权益点

将 tempdb 数据库置于高速系统上的好处只能通过对应用程序工作负荷进行严格的测试和度量来确定。工作负荷必须仔细研究 tempdb 数据库可能受益于的特征，并且必须在部署之前确认 I/O 安全性。

排序和哈希操作与 SQL Server 内存管理器协同工作，以确定每个排序或哈希操作的内存中暂存区域的大小。一旦排序或哈希数据超过分配的内存中暂存区域，数据就可以写入 tempdb 数据库。此算法在 SQL Server 中得到了扩展，减少了与早期版本相比对 tempdb 数据库的使用需求。

注意

SQL Server 设计用于在做出涉及使用 tempdb 数据库操作的查询计划决策时考虑内存级别和当前查询活动。因此，性能提升因工作负载和应用程序设计而异。强烈建议使用首选解决方案完成测试，以确定可能的收益，并在此类部署之前评估 I/O 安全要求。

SQL Server 使用 tempdb 数据库来处理涉及排序、哈希、行版本存储和临时表的各种活动：

临时表由数据页的常见缓冲池例程维护，通常不会表现出特殊子系统实现的性能优势。
tempdb 数据库用作哈希和排序的暂存区域。减少此类操作的 I/O 延迟可能很有用。但是，知道添加索引以避免哈希或排序可能会带来类似的好处。

使用和不使用存储在高速子系统上的 tempdb 数据库运行基线，以比较优势。测试的一部分应包括针对不涉及排序、哈希或临时表的用户数据库的查询，然后确认这些查询不会受到不利影响。评估系统时，以下性能指标可能会有所帮助。

指示器	说明/用法
页面读取和写入	提高 tempdb 数据库 I/O 的性能可能会更改用户数据库的页读取和写入速率，因为与 tempdb 数据库 I/O 关联的延迟降低。对于用户数据库页，整个数字不应因同一工作负荷而异。
对 tempdb 数据库的物理读取和写入字节数	如果将 tempdb 数据库移动到设备（如 RAM 磁盘）会增加 tempdb 数据库的实际 I/O，则表明从缓冲池中获取的内存会导致 tempdb 数据库活动增加。此模式指示数据库页的页面生存期也可能以负面方式受到影响。
页生存期	页面预期寿命下降可能表示用户数据库的物理 I/O 要求增加。速率降低可能表示从缓冲池中获取的内存正在强制数据库页过早退出缓冲池。结合其他指示器并进行测试，以充分了解参数边界。
总体吞吐量 CPU 使用率伸缩性响应时间	tempdb 数据库配置更改的主要目标是提高总体吞吐量。测试应包括可横向扩展的可重复工作负荷的组合，以确定吞吐量的受影响程度。类似于基于压缩的 RAM 磁盘实现之类的内容可能适用于 10 个用户。但是，随着工作负荷的增加，这可能会将 CPU 级别推送到所需级别之外，并会对工作负荷高时的响应时间产生负面影响。鼓励进行真正的压力测试和将来的负载预测测试。
工作文件和工作表创建操作	如果将 tempdb 数据库移动到设备（如 RAM 磁盘），则通过增加工作文件或工作表的数量或大小来更改查询计划，则表明从缓冲池中获取的内存导致 tempdb 数据库活动增加。此模式表明数据库页的页面生存期也可能以负面方式受到影响。

事务扇区重写示例

以下示例详细说明了 SQL Server 数据库所需的数据安全性。

假设 RAM 磁盘供应商使用内存中压缩实现。必须通过提供文件流的物理外观来正确封装实现，就像扇区对齐和调整大小一样，以便 SQL Server 不知道并正确保护基础实现。查看更接近的压缩示例。

扇区 1 写入设备并压缩以节省空间。
扇区 2 写入设备，并使用扇区 1 进行压缩以节省空间。

当设备与扇区 2 的数据相结合时，设备可以执行以下操作来帮助保护扇区 1 的数据。

阻止对扇区 1 和 2 的所有写入。
将扇区 1 解压缩到暂存区域，将当前扇区 1 存储保留为要检索的活动数据。
将扇区 1 和 2 压缩为新的存储格式。
阻止扇区 1 和 2 的所有读取和写入。
将旧存储交换为扇区 1 和 2 与新存储。如果交换尝试失败（回滚）：
- 还原扇区 1 和 2 的原始存储。
- 从暂存区域删除扇区 1 和 2 合并的数据。
- 扇区 2 写入操作失败。
取消阻止扇区 1 和 2 的读取和写入。

当部门交换尝试失败时，能够围绕扇区修改提供锁定机制，并在被视为过渡性合规时回滚更改。对于使用物理存储进行扩展后备的实现，它将包括适当的事务日志方面，以帮助保护和回滚应用于磁盘结构的更改，以保持 SQL Server 数据库文件的完整性。

启用扇区重写的任何设备都必须以事务方式支持重写，以便 SQL Server 不会公开数据丢失。

注意

在 tempdb 数据库中发生联机 I/O 和回滚失败时，将重启 SQL Server 的实例。

移动 tempdb 数据库时请小心

移动 tempdb 数据库时要小心，因为如果无法创建 tempdb 数据库，SQL Server 将不会启动。如果无法创建 tempdb 数据库，请使用（-f）启动参数启动 SQL Server 并将 tempdb 数据库移动到有效位置。

若要更改 tempdb 数据库的物理位置，请执行以下步骤：

ALTER DATABASE使用语句和MODIFY FILE子句更改 tempdb 数据库中每个文件的物理文件名，以引用新的物理位置，例如新磁盘。

ALTER DATABASE tempdb MODIFY FILE 
(name = tempdev, filename = 'C:\MyPath\tempdb.mdf')

ALTER DATABASE tempdb MODIFY FILE 
(name = templog, filename = 'C:\MyPath\templog.ldf')

停止，然后重启 SQL Server。

合作伙伴产品认证不是兼容性或安全的保证

第三方产品或特定供应商可以接收Microsoft徽标认证。但是，合作伙伴认证或特定Microsoft徽标不会认证 SQL Server 中特定用途的兼容性或适用性。

支持

如果将子系统用于支持事务数据库使用的 I/O 保证的子系统，如本文所述，Microsoft将为基于 SQL Server 和 SQL Server 的应用程序提供支持。但是，子系统的问题或原因将转介给制造商。

对于 tempdb 数据库相关问题，Microsoft 支持部门服务会要求你重新定位 tempdb 数据库。请与设备供应商联系，验证是否已正确部署和配置设备以供事务数据库使用。

Microsoft不会认证或验证第三方产品是否适用于 SQL Server。此外，Microsoft不提供任何保证、担保或任何第三方产品适用于 SQL Server 的声明。

参考

有关详细信息，请参见:

通过