我有一个Azure网站，每小时运行大约100K请求，它连接到Azure SQL S2数据库，每天吞吐量约为8GB。我花了很多时间来优化数据库索引，查询等。通常，数据IO，CPU和日志IO百分比在20％范围内表现良好。
保留最近一部分数据吞吐量以支持我们的客户。我有一个夜间维护程序，删除过时的数据来管理数据库大小。这主要适用于删除varbinary（max）字段中的图像blob的例外。
每晚程序有一个循环，一次将10个记录varbinary（max）字段设置为null，等待几秒钟，然后设置下一个10.此循环的每晚总计约为2000.
此循环将运行大约45-60分钟然后停止运行而不返回我的远程Sql代理作业并且未报告错误。必须进行第二次，有时是第三次运行，才能将所需的blob设置为null。
为了减轻夜间程序的负担，我开始每天30秒开始一次作业 - 每次都将一个blob设置为null。
通常这个涓涓细流的工作很好，并在1-6秒内运行。然而，每天一两次出现问题，我找不到任何解释。数据I / O百分比达到峰值100％并保持30-60分钟或更长时间。这会导致数据库响应能力受损，并且网站性能随之下降。涓涓细流的工作也报告了这段延长的时间。如果我停止Sql Agent作业，可能需要几分钟才能停止，但数据I / O在30-60分钟内持续100％。
Web服务请求和数据库需求在整个工作日都相对稳定 - 没有可以解释这一点的不稳定需求。没有报告数据库死锁或其他错误。好像数据库遇到某种积压限制，它的跟踪能力突然下降，然后它就无法赶上，直到最终被阻塞的东西清除。然后表演会突然恢复正常。
您是否有任何想法可能导致这种间歇性和不可预测的问题？当其中一个事件发生时，我可以看到什么想法，以确定数据I / O长时间100％的原因？谢谢。
答案 0 :(得分：2)
如果您使用的是SQL DB V12，还可以考虑使用Query Store feature来导致此性能问题。它现在位于公开预览。
要启用查询存储，只需运行以下语句：
ALTER DATABASE your_db SET QUERY_STORE = ON;