环境：
- 安装了 SQL Server 2016 Standard 的 Azure Windows 2016 VM
- 机器尺寸：DS12_v2（以前是 DS3_v2，除了 RAM 较少外其他都相同）
- 4 核
- 28 GB 内存
- SqlServer 为 14 GB RAM
- 高级存储
- P40 上的数据文件
- P30 上的日志文件
- P10 上的 tempdb
每天晚上，我们都会备份我们的生产系统，然后将其还原到有问题的服务器。备份是压缩的。一切都运行良好，直到几周前，我们在还原过程中开始收到缓冲区闩锁（类型 2）错误。这些错误还伴随着“I/O 请求需要超过 15 秒才能完成”的消息。这些消息出现在各种数据库中。
等待缓冲区闩锁时发生超时 —— 类型 2，……
SQL Server 在文件 [{myPath}\ReportServer.mdf] 上遇到了 4 次花费超过 15 秒才能完成的 I/O 请求...
绝大多数缓冲区闩锁问题都是针对 [ReportServer] 或 [ReportServerTempDB] 报告的，但也有少数问题出现在 [tempdb] 上。
我向我们的 Azure 支持人员创建了一张票据，他们报告说我们的日志磁盘和 VM 都由于吞吐量限制而受到限制，这就是我们看到这些消息的原因。
我感到困惑的是，为什么会突然发生这种情况，为什么 SQL 会在恢复过程中突然尝试推送比以前更多的数据，从而迫使 Azure 减速。我们的数据库大小不会增长那么多，因为我们对更活跃的表进行了归档，并且我们一次恢复一个数据库。不幸的是，我们没有跟踪机制来监控数据和日志文件空间利用率。
在发生这种情况之前的 3 周内没有对 VM 或 SQL Server 进行任何更改，包括安装更新。
问题：
我知道，有时 SQL 查询性能可能会“急剧下降”，即使它正在使用的数据集发生了最小的变化，但 I/O 是否也可能发生同样的事情？是不是因为一点点增长就将服务器推到了比以前恢复时尝试推送更多数据的地步？
我尝试过的事情：
- 禁用所有 SQL CEIP 服务
- 增加了更多 RAM（实际上是为了解决 SSRS 中的内存压力）
- 为 Windows Defender 添加了数据、日志和 tempdb 文件夹以及 sqlserver 进程的排除项。
- 将日常作业 [syspolicy_purge_history_schedule] 的执行时间更改为在我们的备份/恢复过程之前运行。
！！ 编辑：
另外，我们所有的日志文件都有至少 90% 的可用空间，我们的数据文件至少有 25% 的可用空间，因为我们会提前扩展它们以尽量减少自动增长事件。所以当我想到数据增长可能是罪魁祸首时，我现在不太确定了。此过程所恢复的文件大小在几年内应该都是一样的。
答案1
鉴于我们没有 SQL 文件使用情况的历史记录，我只能假设我们在文件空间消耗方面越界了，这迫使 SQL 尝试推送比以前更多的数据。这不是一个可靠的答案，但我认为考虑到我们的情况，任何人都可以提供答案。