运行存储过程时，我们收到错误297
“用户无权执行此操作”
这在重负载期间发生（定期，当修剪作业同时运行时）。重新启动访问SQL Server的服务时错误清除（修剪作业很可能也完成），因此显然不是真正的权限问题。在访问函数的存储过程的一行上报告错误，该函数又访问动态管理视图。
什么样的情况可能导致这样的错误，当它不是真正的权限问题？
根据this article，可能会启用跟踪标志4616来解决这个问题吗？我希望能够尝试一下，但需要更多信息。此外，我感到困惑的是，这是一个间歇性的问题，只发生在高活动期间。
我试图在其他情况下重现同样的错误（也不是真正的权限问题），我发现在SQL Server 2005上运行时我确实遇到了权限问题：
select * from sys.dm_db_index_physical_stats(66,null,null, null, null)
（66是无效的DBID。）
但是，我们没有将dm_db_index_physical_stats与不正确的DBID一起使用。我们正在使用dm_tran_session_transactions和dm_tran_active_transactions，但它们不接受参数，所以我不能让它们发生错误。但我想也许这个问题是有联系的。
感谢您的任何见解。
答案 0 :(得分：4)
是否与并发问题有关？
例如，正在处理相同的数据或正在访问全局临时表？如果是这样，您可以考虑sp_getapplock
每个连接是否使用不同的凭据和不同的权限集？所有用户都有GRANT VIEW SERVER STATE TO xxx？
最后，并且与上述两个想法相关，您是否在可能无法还原的任何地方使用EXECUTE AS等？
完全随机的想法：我以前见过这个，但只有当我在存储的proc定义的结尾和下面的GRANT语句之间省略了GO时。所以SP试图设置它自己的权限。是否有可能超时或并发问题导致某些代码无法正常运行？
答案 1 :(得分：0)
如果仅在活动繁重期间发生这种情况，您可以运行Profiler并观察正在进行的锁定。
这也总是以同样的方式运行吗？例如，它是作为SQL代理作业运行的吗？或者您有时手动运行，有时将其作为工作运行。我的想法可能是它正在运行。用户在不同时间。
也许还要看一下这个Blog Post
答案 2 :(得分：0)
感谢大家的意见。我所做的（现在看来它解决了这个问题），改变了日常工作。它现在在删除之间等待的时间要长得多，并且一次删除一小部分记录。
我会在稍后用更多信息更新此内容。
再次感谢。