正文
如何减少SQL Server中的PREEMPTIVE_OS_WRITEFILEGATHER等待类型
小程序：扫一扫查出行【扫一扫了解最新限行尾号】
复制小程序
在数据库大小分配期间，我正在等待类型PREEMPTIVE_OS_WRITEFILEGATHER。昨天，我将数据库大小配置为供应商建议的值。我们需要将数据库大小设置为700GB，保留150 GB的日志文件。我已经在不到2分钟的时间内成功配置了数据文件大小，因为我们已经启用了 即时文件初始化。我们知道即时文件初始化（IFI）通过跳过零初始化操作来加速数据文件大小分配。但是当我开始扩展日志文件大小时，花了很多时间。花费更长时间的一个原因可能是因为 正在运行以分配日志文件空间的会话ID显示的等待类型PREEMPTIVE_OS_WRITEFILEGATHER。什么是PREEMPTIVE_OS_WRITEFILEGATHER？
根据MSDN，PREEMPTIVE_OS_WRITEFILEGATHER是在SQL Server等待操作系统完成部分写操作时发生的等待类型。此等待通常出现在未正确配置自动增长的数据库中或在大规模分配到数据库文件期间。如果您经常获得此等待类型，则应调查SQL Server实例。您还可以观察此等待类型以及BACKUPBUFFER 和LOGBUFFER等待类型。
有时，我们在数据库恢复操作期间也会获得此等待类型。我们知道，备份操作会捕获数据库文件大小等详细信息，而不管数据或日志文件中填充了多少数据或日志。当您执行还原操作时，它将创建那么大的文件，这将花费更多的时间，因为SQL Server将忙于将文件归零，相当于源数据或日志文件大小。如果您已在数据库服务器上启用了IFI，那么您将无法获得数据文件的此等待类型，但仍可以获取日志文件大小分配。
假设您的数据库有100GB的日志文件，并且只填充了12 GB。如果你备份这个数据库并在任何地方恢复它，那么恢复操作将创建一个100GB的日志文件，这将花费很多时间，因为要对所有100GB大小执行零初始化操作。
减少等待类型的解决方案PREEMPTIVE_OS_WRITEFILEGATHER
Microsoft已提供一项功能即时文件初始化以克服或减少此等待类型，但此功能仅适用于数据文件而非日志文件。我们希望此功能可以在SQL Server的未来版本中同时处理数据和日志文件。
如果在扩展数据文件期间或在数据文件自动增长期间获得此等待类型，则只需在SQL Server数据库服务器上启用即时文件初始化，此等待类型将从下次消失。此功能将跳过数据文件的零初始化，并直接将给定大小分配给数据文件。阅读附加文章以了解即时文件初始化以及如何在SQL Server实例上启用它？
但我们知道此功能对日志文件不起作用，因此如果在扩展日志文件期间或日志文件自动增长期间发生这种情况，我们就无法使用此功能来减少此等待类型。我们遇到了同样的问题，因为我们已经为数据文件启用了即时文件初始化，但在扩展日志文件期间卡住了 在这里，我将为您提供一些可以应用的最佳实践，以避免和减少此等待类型。
- 将自动增长从默认值增加到某个数值，以减少数据库文件的频繁自动增长。Thumb规则是将自动增长大小保持为相应数据库文件大小的八分之一。阅读本文以了解数据库文件Autogrowth的 完美价值？
- 如果可能，通过将未来增长的预期大小分配给数据库来避免自动增长。
- 监控存储子系统并调查是否发现任何问题。如果需要升级存储。
- 有关任何系统相关问题，请查看Windows事件查看器。
- 启用即时文件初始化以避免数据文件的零初始化。
- 将事务从逐行语句合并到批处理。
- 如果您有更大的日志文件，其中填充了少量日志。您可以使用附加文章中给出的DBCC SQLPERF命令检查日志文件大小。您可以缩小日志文件并再次执行备份以执行还原。这应该是一个快速的过程，而不是等待归零以完成以前大小的日志文件。
- 停止任何活动以释放目标磁盘的标头，以便它可以专门用于清零LDF文件。
什么是PREEMPTIVE_OS_WRITEFILEGATHER？
根据MSDN，PREEMPTIVE_OS_WRITEFILEGATHER是在SQL Server等待操作系统完成部分写操作时发生的等待类型。此等待通常出现在未正确配置自动增长的数据库中或在大规模分配到数据库文件期间。如果您经常获得此等待类型，则应调查SQL Server实例。您还可以观察此等待类型以及BACKUPBUFFER 和LOGBUFFER等待类型。
有时，我们在数据库恢复操作期间也会获得此等待类型。我们知道，备份操作会捕获数据库文件大小等详细信息，而不管数据或日志文件中填充了多少数据或日志。当您执行还原操作时，它将创建那么大的文件，这将花费更多的时间，因为SQL Server将忙于将文件归零，相当于源数据或日志文件大小。如果您已在数据库服务器上启用了IFI，那么您将无法获得数据文件的此等待类型，但仍可以获取日志文件大小分配。
假设您的数据库有100GB的日志文件，并且只填充了12 GB。如果你备份这个数据库并在任何地方恢复它，那么恢复操作将创建一个100GB的日志文件，这将花费很多时间，因为要对所有100GB大小执行零初始化操作。
减少等待类型的解决方案PREEMPTIVE_OS_WRITEFILEGATHER
Microsoft已提供一项功能即时文件初始化以克服或减少此等待类型，但此功能仅适用于数据文件而非日志文件。我们希望此功能可以在SQL Server的未来版本中同时处理数据和日志文件。
如果在扩展数据文件期间或在数据文件自动增长期间获得此等待类型，则只需在SQL Server数据库服务器上启用即时文件初始化，此等待类型将从下次消失。此功能将跳过数据文件的零初始化，并直接将给定大小分配给数据文件。阅读附加文章以了解即时文件初始化以及如何在SQL Server实例上启用它？
但我们知道此功能对日志文件不起作用，因此如果在扩展日志文件期间或日志文件自动增长期间发生这种情况，我们就无法使用此功能来减少此等待类型。我们遇到了同样的问题，因为我们已经为数据文件启用了即时文件初始化，但在扩展日志文件期间卡住了 在这里，我将为您提供一些可以应用的最佳实践，以避免和减少此等待类型。
- 将自动增长从默认值增加到某个数值，以减少数据库文件的频繁自动增长。Thumb规则是将自动增长大小保持为相应数据库文件大小的八分之一。阅读本文以了解数据库文件Autogrowth的 完美价值？
- 如果可能，通过将未来增长的预期大小分配给数据库来避免自动增长。
- 监控存储子系统并调查是否发现任何问题。如果需要升级存储。
- 有关任何系统相关问题，请查看Windows事件查看器。
- 启用即时文件初始化以避免数据文件的零初始化。
- 将事务从逐行语句合并到批处理。
- 如果您有更大的日志文件，其中填充了少量日志。您可以使用附加文章中给出的DBCC SQLPERF命令检查日志文件大小。您可以缩小日志文件并再次执行备份以执行还原。这应该是一个快速的过程，而不是等待归零以完成以前大小的日志文件。
- 停止任何活动以释放目标磁盘的标头，以便它可以专门用于清零LDF文件。
