【发布时间】：2016-11-27 17:35:43
【问题描述】：
我们有一个存储过程被每日作业计划调用，该计划过去可以在合理的时间范围内工作，但现在执行非常糟糕并且失败了。不管是什么原因，它似乎也让我们的整个系统陷入困境。我们尝试重新启动计算机，但问题仍然存在。
存储过程充当 ETL，将数据从一个数据库导入另一个数据库并进行一些更新。从作业中调用时，它曾经在一个小时内运行，但大约 7 天前它开始需要 10-15 小时才能运行。然后最后3天它完全失败了。今天我让它运行了10个小时，然后取消了。
失败运行的错误消息发现它失败了，因为日志文件空间不足。所以我尝试使用下面的代码来缩小日志文件。它有效，但根本没有减少文件大小。由于代码不起作用，我尝试使用 SSMS 进行收缩，但由于错误而失败：
超过锁定请求超时时间
我跑了sp_who2，但不确定（我是开发人员而不是 DBA），发现以下似乎相关：
SPID：63，状态：挂起，命令：删除，CPU 时间：1142382，DiskIO：1254258
我认为这可能是问题所在，因此我尝试使用 Kill 63 结束该交易。但是，这似乎不起作用，因为如果我运行sp_who2，它现在会显示
SPID: 63, 状态: Suspended, 命令: Killed/Rollback, CPU Time: 1142803, DiskIO: 1261601
任何解决问题的帮助将不胜感激！具体来说：
有什么想法会突然导致性能不佳吗？
如何缩小日志文件？这会导致性能不佳吗？
这是我尝试过的代码：
USE MyDatabase;
GO
ALTER DATABASE MyDatabase
SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (MyDatabase_log, 1);
GO
ALTER DATABASE MyDatabase
SET RECOVERY FULL;
GO
【问题讨论】：
-
虽然这里有很多人在 SO 上具有 DB 知识，但您最好在 Database Administrators 上提问，因为该网站可能更专注于非开发相关方面。
-
您提供的信息没有多大帮助..请发布存储过程的执行计划。也尝试更新存储过程中涉及的对象的统计信息...发布您的sql版本。最重要的是看这里和看看如何快速询问和获得帮助。即使它是一个tsql格式，尝试理解本质..spaghettidba.com/2015/04/24/…
-
您需要查看与您的查询相关的数据是否有任何增长。此外，查看“长时间运行的查询”，您可能会看到一些趋势 - 或者至少运行它们（如果它们正在读取数据），然后监控您的服务器统计信息和底层硬件。
-
Lock request time out- 这不是运行缓慢 - 这意味着其他人锁定了您的脚本需要的数据并且很长时间没有释放它。 -
关于恢复模式：选项1 - 你说缩小日志是可以的；选项 2 - 您需要完全恢复模式。如果您需要
full- 您可能不会缩小日志并从简单到完整来回切换。如果您不需要日志 - 选择simple模型并且不要更改它。
标签： sql-server stored-procedures job-scheduling logfile shrink