Azure功能缓慢执行存储过程

时间:2018-03-19 06:18:00

标签: azure azure-sql-database azure-functions

我正在使用像预定作业一样的Azure功能,使用cron计时器。在每天早上的特定时间,它会调用存储过程。

该功能现在需要4分钟来运行存储过程,需要几秒钟才能在SSMS中运行。尽管努力成功提高存储过程的速度,但这一时间仍在增加。

该功能没有做任何密集的事情。

using (SqlConnection conn = new SqlConnection(str))
{
    conn.Open();

    using (var cmd = new SqlCommand("Stored Proc Here", conn) { CommandType = CommandType.StoredProcedure, CommandTimeout = 600})
    {
        cmd.Parameters.Add("@Param1", SqlDbType.DateTime2).Value = DateTime.Today.AddDays(-30);
        cmd.Parameters.Add("@Param2", SqlDbType.DateTime2).Value = DateTime.Today;

        var result = cmd.ExecuteNonQuery();
    }
}

我已经检查过,当存储过程正在运行时,数据库没有加载另一个进程。

我有什么办法可以加速Azure功能吗?或者找出原因为何如此缓慢的任何方法?

更新

我不相信Azure功能有问题,问题似乎与SQL Server有关。

我最终运行了生产SP并查看了执行计划。我注意到统计数据已经消失了,例如,连接期望返回的行数为20,但实际数字接近800k。

我的问题的解决方案是每周更新特定表格上的统计信息。

关于为什么这些统计数据如此之多,以及客户端每晚进行批量更新并插入数十万行。我只能假设这影响了统计数据并且它是累积的,所以随着时间的推移似乎会变得更糟。

2 个答案:

答案 0 :(得分:2)

请小心添加重新编译提示。通常,对于给定的简单查询而言,编译要比执行昂贵得多,这意味着使用这种方法,可能无法为所有应用提供良好的性能。

您的经历可能有不同的原因。发生这种情况的一个常见原因是,您在app路径和ssms路径中有不同的查询计划。发生这种情况的原因可能多种多样(我将在下面进行总结)。您可以使用查询存储(记录有关查询,计划和运行时状态的摘要数据)来确定是否要获得不同的计划。请在此处查看摘要: https://docs.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store?view=sql-server-2017

尽管您可以使用来自任何tds客户端的直接查询,但是您需要使用最新的sms来获取ui。

现在总结一些可能的原因: 计划差异的一种可能原因是设置选项。这些是查询的不同环境变量,例如启用或禁用ansi null。每个不同的设置都可能更改计划的选择,从而影响性能。不幸的是,不同语言驱动程序的默认设置有所不同(每一个构建时的历史工件-现在很难更改而不会破坏应用程序)。您可以查看查询存储以查看是否存在不同的“上下文设置”(设置选项的每个唯一组合都是查询存储中的唯一上下文设置)。每个不同的集合都意味着不同的可能计划,因此潜在的性能变化。

像您在帖子中解释的那样,计划更改的第二个主要原因是参数嗅探。根据编译范围(例如:在sproc内还是作为临时查询文本),sql有时会在编译期间查看当前参数值,以推断将来执行中公共值的频率。使用特定值可以生成一个计划,该计划对于单个值(或一组值)是最佳的,但对于超出该值的值可能会更慢,而不是忽略该值并仅使用默认频率。您也可以在查询存储区的查询计划选项中看到这一点。

除了我提到的以外,还有其他可能导致性能差异的原因。有时在mars模式下运行与在客户端中运行时,性能会有差异。调用客户端驱动程序的方式可能会有所不同,从而影响性能。

我希望这会为您提供一些工具,以调试造成这种差异的可能原因。祝你好运!

答案 1 :(得分:1)

对于我从事的项目,我们遇到了同样的事情。它不是功能问题,而是SQL Server问题。对于我们来说,我们在开发过程中正在更新sproc,事实证明,按照执行计划,sql server将缓存某些路由/索引(通俗易懂的解释),而对于新的sproc则不同步。

我们通过在sproc的末尾指定WITH (RECOMPILE)来解决此问题,并且API调用和SSMS具有相同的时间安排。

系统解决后,可以并且应该删除该语句。

搜索慢速处理的ssms等,以查找遇到这种情况的其他人。