sql server中是系统数据库服务器,对 tempdb 的 i/o 子系统要求 - SQL Server | Microsoft Docs...

对 tempdb 数据库的 Microsoft SQL Server i/o 子系统要求

09/25/2020

本文内容

本文介绍了 SQL Server 中 tempdb 数据库的 i/o 子系统要求。

原始产品版本：   Microsoft SQL Server 2005 sql server 2008 sql Server 2012 SQL Server 2014

原始 KB 数：   917047

摘要

Microsoft SQL Server 要求用于存储系统和用户数据库的 i/o 子系统完全遵守 Write-Ahead 日志记录 (通过特定 i/o 主体的 WAL) 要求。 为了服从事务的 ACID 属性，需要满足这些要求：原子、一致、独立和耐用。 有关 i/o 子系统合规性要求的详细信息，请参阅以下参考资料：

备注

本文也适用于 SQL Server 2005 及更高版本。

以下列表是有关要求的快速摘要：

必须维护写入顺序。

必须维护相关的写入一致性。

必须始终在稳定媒体中保护写入。

必须进行残缺 i/o 防护。

持续性维护对所有其他数据库仍然至关重要，但对于 tempdb 数据库来说可能是宽松的。 下表汇总了 SQL Server 数据库的几个关键 i/o 要求。

I/o 要求

简短说明

系统或用户

tempdb

写入顺序

相关写入一致性

子系统保持正确的写入操作顺序的能力。 这对于镜像解决方案、组一致性要求和 SQL Server WAL 协议使用尤其重要。

必填

建议

写入后读取

在成功完成任何写入后发出读取时，使用最新数据图像的子系统服务读取请求的能力。

必需

必需

中断间生存

数据在中断(如系统重新启动)中保持完全不变 (持久) 的功能。

必填

不适用

残缺 i/o 预防

系统避免拆分单个 i/o 请求的能力。

必填

建议

重写扇区

由于邻近的扇区上有写入请求，因此只能写入整个扇区，且无法重写该扇区。

* 不鼓励，仅在事务性时允许

* 不鼓励，仅在事务性时允许

加强的数据

当写入请求或 FlushFileBuffers 操作成功完成时，假定已将数据保存到了稳定的媒体。

必填

不适用

物理扇区的对齐和大小

SQL Server interrogates 数据和日志文件的存储位置。 所有设备都需要支持扇区属性，允许 SQL Server 对物理扇区对齐的边界以及扇区大小的倍数执行写入操作。

必需

必需

事务性扇区重写包括子系统完全记录的操作，允许将某个扇区完全移动、替换或回滚到原始图像。 通常不鼓励这些重写，因为执行此类操作需要额外的开销。 此示例是一个 defragmentation 正在移动文件数据的实用工具。 在新的扇区和数据安全之前，不能将文件中的原始扇区替换为新的扇区位置。 扇区的重映射必须以事务性方式发生，这样任何故障(包括电源故障)都将导致重新建立原始数据。 确保在此类进程中有锁定机制可用来阻止无效的数据访问，从而 upholding 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 2005 扩展支持或压缩为只读数据库和文件组。 有关完整的详细信息，请参阅 SQL Server 2005 联机丛书。

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

您可以将 tempdb 数据库放在专业子系统上，如 RAM 磁盘、固态或其他数据库无法使用的其他高速实现。 但是，在评估这些选项时，必须考虑 "更多信息" 部分中提供的关键因素。

备注

故障转移群集环境中的本地磁盘仅在稳定状态或高速实施中受支持。 这是因为 RAM 磁盘仅可通过 iSCSI 目标创建。 此外，不能在同一主机上使用 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 磁盘用作讨论的基础，但在其他高速实施中会出现类似的结果。

输入/输出安全

必须进行写入和事务性扇区写入后读取合规性。 永远不要在不完全支持 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 2005 中扩展，降低了早期版本的 SQL Server 的 tempdb 数据库使用要求。

注意

SQL Server 设计用于在制定涉及 tempdb 数据库操作的查询计划决策时，考虑内存级别和当前查询活动。 因此，根据工作负载和应用程序设计，性能提升会显著变化。 强烈建议您使用首选解决方案完成测试，以确定在此类部署之前可能获得和评估 i/o 安全要求。

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

临时表由数据页的通用缓冲池例程维护，通常不会显示专业子系统实现中的性能优势。

Tempdb 数据库用作哈希和排序的草稿区。 减少此类操作的 i/o 延迟可能会有好处。 但是，请注意，添加索引以避免哈希或排序可能提供类似的好处。

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

指示器

说明/用法

页面读取和写入

改进 tempdb 数据库 I/Os 的性能可能会更改用户数据库的页面读取和写入的速度，因为与 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进行压缩以节省空间。

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

操作

阻止对扇区1和2的所有写入。

将扇区1解压缩到草稿区，将当前扇区1存储保留为要检索的活动数据。

将扇区1和2压缩为新的存储格式。

阻止扇区1和2的所有读取和写入。

使用新存储为扇区1和2交换旧存储。

如果 exchange 尝试失败 (回滚) ：

还原扇区1和2的原始存储。

从空闲区中删除扇区1和2的组合数据。

将第2扇区写入操作失败。

取消阻止扇区1和2的读取和写入。

在扇区尝试失败时，提供有关扇区修改和回滚更改的能力将被认为是 transitionally 合规性的。 对于将物理存储用于扩展支持的实现，它将包括相应的事务日志方面，以帮助保护对磁盘上的结构应用的更改，以维护 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，然后重新启动它。

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

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

支持

如果使用的子系统包含支持按本文所述的事务性数据库使用的 i/o 保证的 SQL Server，Microsoft 将为 SQL Server 和基于 SQL Server 的应用程序提供支持。 但是，或由子系统导致的问题将被提供给制造商。

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

Microsoft 不会验证或验证第三方产品在 SQL Server 中是否正常工作。 此外，Microsoft 不会提供任何第三方产品对 SQL Server 适用性的担保、guaranty 或声明。

参考

有关详细信息，请单击下面的文章编号，以查看 Microsoft 知识库中的文章：

本文档包含的信息代表 Microsoft Corporation 在本文档发布之日对所讨论问题的当前观点。 由于 Microsoft 必须对不断变化的市场情况作出反应，因此不应将其理解为 Microsoft 所做的承诺，Microsoft 不能保证所提供的信息在本文档发布之后仍然准确。

本白皮书仅用于提供信息之目的。 对于本文档中的信息，MICROSOFT 不做任何明示、暗示或法定的担保。

遵守所有适用的版权法是用户的责任。 在不限制版权许可的权利情况下，未经 Microsoft Corporation 的明确书面许可，不得出于任何目的、以任何形式或通过任何手段(电子、机械、影印、录制或其他方式)复制本文档的任何部分或将其存储到或引入检索系统中或进行传播。

本文档的内容可能涉及 Microsoft 的专利、专利申请、商标、版权或其他知识产权。 除非 Microsoft 的任何书面许可协议中明确声明，否则本文档不提供任何使用这些专利、商标、版权或其他知识产权的许可。

© 2006 Microsoft Corporation。 保留所有权利。

Microsoft、Windows、Windows Server 和 SQL Server 是 Microsoft Corporation 在美国和/或其他国家/地区的注册商标或商标。

SQL Server 要求系统支持按照 SQL Server I/o 可靠性计划要求中所述的 "保证传递到稳定媒体"。 有关 SQL Server 数据库引擎的输入和输出要求的详细信息，请参阅 MICROSOFT Sql Server 数据库引擎的输入/输出要求。