IO 请求时间和更少的写入延迟

Question

我面临着与不断增长的日志文件相关的问题，因此我收到了错误。当我检查 SQL 日志时，我发现以下消息（错误日志中几乎 90% 都填充了这些消息）

SQL Server 遇到 1 次 I/O 请求需要超过 15 秒才能在文件中完成

几乎所有数据库都会发生这种情况，包括 temdb [.mdf 和 .ndf 文件] 以及我也收到以下消息

平均吞吐量：0.34 MB/秒 I/O 饱和度：196 次上下文切换 1210

最后一个未完成的目标：530 avgWriteLatency 2

FlushCache：在 142370 毫秒内清理了 6233 个 buf，384 次写入（避免了 99 个新的脏 buf），用于 db 6:0

我的 temdb 大小和其他数据库和日志文件大小足够大。

历史：

• 以前的开发人员已经多次进行数据库收缩和日志收缩。
• 所有数据库都处于压缩模式。

我的行动计划：

• 我发现日志文件的初始大小很小，增长了 10%。我计划将初始大小增加 512 MB，增加 512 MB 以获得合理数量的 VLF。

  问题 1：虽然我会在非高峰时段进行工作，但进行这些更改是否有可能损坏我的数据库或日志文件？

  问题二：数据库压缩方式会影响IO操作吗？如果是，我该如何解决？

• 我计划从防病毒检查中删除所有数据库和日志文件。

• 我计划将目标恢复时间更改为 < 1 分钟的数据库（特别是 tempdb 和我的数据库）

  问题 3：这会影响我的数据库吗？我的意思是刷新缓冲区和写入磁盘应该可以提高性能，对吗？

  问题 4：我有 3 个 tempdb 数据文件，已经有 3 个数据文件。根据Microsoft 的建议，我是否必须增加我的 temdb 数据文件/日志文件？下面提到了我当前的处理器配置

问题5：我走错方向了吗？有什么我应该做的事情来纠正这个问题吗？

编辑 为什么我认为这与日志文件大小有关？

如果出现 IO 问题，那么 SQL 的读写能力会下降，这将导致长时间运行的事务，从而导致日志文件过大。

Answer 1

\n

问题 1：虽然我会在非高峰时段进行操作，但是进行这些更改是否有可能损坏我的数据库或日志文件？

\n

\n

不，这不会损坏您的日志文件。

\n

\n

问题2：数据库压缩模式会影响IO操作吗？如果是，我该如何解决？

\n

\n

是的，数据库压缩会影响 I/O，根据我的经验，它会减少 I/O，如果您查看 I/O 消耗，它实际上是有益的。我会告诉你怎么做。

\n

\n
1. 压缩数据存储在磁盘上时将占用更少的页面，因此读取数据时需要更少的 I/O 来获取内存中的数据。
\n
2. 同样，由于购买到内存中的页面更少，这增加了缓冲池的可用性。
\n
3. CPU 是压缩或解压发生时消耗的资源。但在大多数情况下，您会发现空间和 I/O 获得的好处将超过 CPU 消耗
\n
4. 请记住，压缩页面在磁盘上将保持压缩状态，并且在进入内存进行读取或写入时也会保持压缩状态。所以不需要在内存中进行额外的解压工作
\n

\n

这是一篇关于数据压缩的优秀文章，虽然篇幅很大，但可以帮助您理解数据压缩

\n

您必须从防病毒检查中删除所有与 SQL Server 相关的文件夹和文件，特别是如果您有 McAfee 防病毒软件。

\n

\n

\xe2\x80\xa2我计划将数据库的目标恢复时间更改为 < 1 分钟（特别是 tempdb 和我的数据库）

\n

\n

我只能说请保留默认值，我不确定恢复时间与日志文件及其配置有什么关系

\n

关于 Tempdb，请确保您的数据文件等于物理核心的数量。Paul 有更多关于每个核心可以拥有多少个文件的问题，恕我直言，您可以从 4 个 tempdb 文件开始，但要继续监视争用情况。确保所有 tempdb 数据文件具有相同的初始大小和相同的自动增长设置。您还可以启用 TF 1118 以避免争用

\n

要检查争用，您可以运行以下查询

\n

select \nsession_id, \nwait_duration_ms,   \nresource_description\nfrom    sys.dm_os_waiting_tasks \nwhere   wait_type like \'PAGE%LATCH_%\' and \nresource_description like \'2:%\'\n

\n

有一些关于 Tempdb 和 Contention 的好文章供您阅读

\n

\n

1. Tempdb 争用故障排除作者：Paul Randal

   \n
\n

2. 减少 Tempdb 数据库中分配争用的建议

   \n
\n

3. 监控 Tempdb 中的分配瓶颈

   \n
\n

\n

编辑：

\n

\n

SQL Server 遇到 1 次 I/O 请求在文件上完成时间超过 15 秒

\n

\n

此消息意味着特定会话或查询请求 I/O 以从磁盘获取数据，但该会话必须等待 15 秒以上，然后才能满足该请求。您可以猜测 15 秒是阈值，此时越界消息将转储到错误日志中。这主要意味着磁盘无法处理正在生成的 I/O 请求，进而意味着磁盘可能会很慢。既然你说你的错误日志的 90% 都充满了这些信息，我不得不相信底层硬件很慢或者可能需要固件升级。本文将帮助您了解问题并解决它

\n