我正在使用SQL Server 2005中的SQL Server代理作业执行存储过程。
这项工作一直持续到昨天。从昨天起,这项工作耗时超过1小时而不是2分钟。
我在SSMS中执行了存储过程,执行时间不到1分钟。
我无法弄清楚为什么在作为SQL Server代理作业执行时花费的时间超过1小时?
答案 0 :(得分:5)
经过一段时间的评论并假设SP在SSMS中执行时具有相同的输入参数和数据,我最终认为我可以给出最后一个提示:
根据SP中执行的操作(例如,在循环或游标中插入/更新/删除大量数据),您应该在代码的开头设置nocount。
set nocount on
如果不是这种情况或没有帮助,请添加评论中已提及的更多信息(例如,作业和每个工作步骤的所有设置,已记录的内容,Jobhistory中的内容,检查SQLerrorlogs,事件日志,....)。 另请查看“SQL Server日志”,也许您可以在此处收集一些信息。另外,查看Databaseserver的Application / System事件总是一个好主意。 要获得基本概述,可以使用SSMS中的Activitymonitor,方法是选择Databaseserver并从contextmenu中选择“Activity monitor”并搜索sql代理。
我的最后一次尝试是尝试为代理运行sql跟踪。在这种情况下,您将开始跟踪并过滤,例如由用户运行SQLAgent服务。您可以为跟踪设置很多选项,因此我建议谷歌搜索它,在MSDN上搜索或在stackoverflow上询问另一个问题。
答案 1 :(得分:2)
我注意到SQL Agent作业忽略了服务器的MAXDOP设置,并以MAXDOP为1运行所有内容。如果我在查询窗口中运行存储过程,它会服从服务器设置并使用4个进程。如果我使用SQL Agent,我运行的任何存储过程只使用一个进程。
答案 2 :(得分:1)
我在脚本中遇到了类似的问题,该脚本调用了我创建的一些UDF。 UDF本身通常在SSMS下运行亚秒级。同样,运行我用它们生成的报告在SSMS下是可以忍受的(8s中的30d数据,22s中的365d数据)。我总是使用我的SQL代理作业完成NOCOUNT ON,因为它们通常生成文本文件以供其他进程或Excel使用,我最后不想要额外的数据,因此它不适合我。
在这种情况下,当我们在SQL Agent下运行与作业完全相同的脚本时,我的时间会成倍增长。我的8s脚本需要2分30秒,而我的22s脚本需要2小时20分钟。无论我是在中午与其他用户活动和作业一起运行,还是在没有用户活动的情况下运行它,也不运行作业或备份,这都是一样的。我们的服务器处于空闲状态,充其量只能在运行时使用8个核心中的一个。 DB只有大约10GB运行在SSD上,带有缓存的RAID卡,16个32GB RAM是免费的。由于我的SQL在SSMS中高效运行,我相信我正在达到某种线程限制。我已经研究并尝试在SQL代理中的脚本之前调整MAXDOP而没有运气。
由于这是我想要安排的活动,因此需要以这种或那种方式实现自动化。我可以让这些脚本花费他们在SQL Agent作业中作为SQL步骤运行所需的时间,但我决定从命令行运行,我获得了与SSMS中相同的性能。
sqlcmd -S SQLSRVRHost -i "C:\My Script Loc With Spaces.sql" -v MyVar="VarValue" >"C:\MyOutputFile.txt"
所以我创建了一个批处理脚本,其中包含从sqlcmd运行的SQL作业。然后我从SQL代理作业运行批处理脚本,所以我仍然有相同的管理和控制。我的4个SQL作业总共需要3个小时才能完成,只需1分钟,几秒钟就可以完成SQL Agent执行的单个批处理脚本。
我希望这会有所帮助......
答案 3 :(得分:1)
我们有一个大型的proc,在SSMS中运行88秒,在SQL Server Agent中运行30-45分钟。我添加了dbo。所有表名都有前缀,现在它的运行速度和SSMS一样快。