SQL 作业存在事务日志问题
我有一个仅执行存储过程的 SQL 作业。 每天早上当作业尝试运行时,我都会收到以下错误:
当前事务无法提交,并且无法支持写入日志文件的操作。
当我继续尝试重新启动作业时,它总是给我同样的错误。 但是,如果我只是执行存储过程而不使用作业,它就可以正常工作。
这是非常非常棘手的部分。 如果我只是运行存储过程,取消它,然后运行作业,则作业工作得很好。
有没有人遇到过这个相当独特的问题或者有任何想法可能导致它?
I have a SQL job that simply executes a stored procedure. Each morning when the job attempts to run, I get the following error:
The current transaction cannot be committed and cannot support operations that write to the log file.
When I keep trying to restart the job, it keeps giving me that same error. However, if I just execute the store procedure without using the Job it works fine.
And here's the really really tricky part. If I just run the stored procedure, cancel it, and then run the Job, the job works perfectly fine.
Has anyone come across this rather unique problem or have any ideas what may be causing it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
此错误表明您正在尝试在注定失败的事务期间执行记录的操作。 仅当您忽略 XACT_STATE 值为-1:
事实上,您尝试执行此操作仅表明您的异常处理存在代码问题(换句话说,您的过程有错误)。 我最近在博客中介绍了 使用 BEGIN TRY 的过程模板/BEGIN CATCH 您可以使用它作为修复程序的起点。 Erland Sommarskog 有一篇关于 Transact-SQL 错误处理的著名文章,但这并没有太深入地涵盖 BEGIN TRY/BEGIN CATCH 。
通过适当的错误处理,您可以找出发生的原始错误并导致 CATCH 块首先被执行。 既然您提到手动运行该过程不会导致任何问题,那么问题可能是 SQL 代理作业和手动执行之间的上下文差异。 如果没有任何数据,我无法诊断问题,但我猜测最可能的原因是安全上下文的差异(即代理登录缺少您自己的登录所拥有的某些权限)。
This error indicates that you are trying to do a logged operation during a doomed transaction. This can only happen in a BEGIN CATCH block if you're ignoring the XACT_STATE value of -1:
The fact that your trying to do this merely indicates a code problem with your exception handling (in other words your procedure is buggy). I have recently blogged about a template for procedures that use BEGIN TRY/BEGIN CATCH and you can use that as a starting point to fix your procedure. Erland Sommarskog has a well known article on Transact-SQL error handling, but that does not cover the BEGIN TRY/BEGIN CATCH too deeply.
With proper error handling in place you can then find out the original error that occurs and causes your CATCH block to be executed in the first place. Since you mention that running the procedure manually causes no issues then the problem is likely the differences in context between the SQL Agent job and your manual execution. I cannot diagnose the problem without any data, but my guess about the most likely cause is the difference in the security context (ie. the Agent login is lacking some rights your own login has).
我在不同的条件下收到此错误,并提出了一个短复制路径(软件缺陷缺少
IF XACT_STATE() != 1 ROLLBACK
):I was getting this error under different conditions and I came-up with a short replication path (the software defect is missing
IF XACT_STATE() != 1 ROLLBACK
):