红鲱鱼错误“用户无权执行此操作”答案

【问题标题】：red herring error "The user does not have permission to perform this action"红鲱鱼错误“用户无权执行此操作”
【发布时间】：2011-02-10 17:53:12
【问题描述】：

在运行存储过程时，我们收到错误 297

“用户无权执行此操作”

这发生在负载较重的时候（通常，当修剪作业同时运行时）。当访问 SQL Server 的服务重新启动时，该错误就会清除（并且很可能修剪作业也已完成），因此这显然不是真正的权限问题。该错误在访问函数的存储过程的一行上报告，该函数又访问动态管理视图。

当它不是真正的权限问题时，什么样的情况会导致这样的错误？

根据this article，是否可能打开跟踪标志 4616 来解决此问题？我希望能够尝试一下，但需要更多信息。此外，令我感到困惑的是，这是一个间歇性问题，仅在高活动期间发生。

我试图在其他情况下重现同样的错误（这也不是真正的权限问题），我发现在 SQL Server 2005 上运行时我确实遇到了权限问题：

select * from sys.dm_db_index_physical_stats(66,null,null, null, null)

（66 是无效的 DBID。）

但是，我们没有使用带有错误 DBID 的 dm_db_index_physical_stats。我们正在使用 dm_tran_session_transactions 和 dm_tran_active_transactions，但它们不接受参数，所以我无法让它们发生错误。但我在想也许这个问题是相关的。

感谢您提供任何见解。

【问题讨论】：

这真的不是我的专业领域，但您是否确切知道哪个操作因此错误而失败，例如在存储过程中失败的调用？
它在存储过程的一行访问一个函数，该函数又访问动态管理视图。虽然谁知道这是否是问题的真正根本原因。
你能告诉我们函数和/或存储过程吗？
您还在使用应用程序角色吗？如果不是，那么我不相信跟踪标志 4616 将适用于您的情况。

标签： sql-server sql-server-2005

【解决方案1】：

感谢大家的意见。我所做的（看起来现在已经解决了问题）是改变日常修剪工作。现在，它在两次删除之间等待的时间大大延长，并且一次删除的记录块要小得多。

稍后我会在获得更多信息后更新此内容。

再次感谢。

【讨论】：

【解决方案2】：

会不会和并发问题有关？

例如，正在处理相同的数据或正在访问全局临时表？如果有，可以考虑sp_getapplock

每个连接是否使用具有不同权限集的不同凭据？是否所有用户都有GRANT VIEW SERVER STATE TO xxx？

最后，与上述两个想法相关，您是否在任何可能无法还原的地方使用EXECUTE AS 等？

完全随机的想法：我以前见过这种情况，但只是当我在存储过程定义的末尾和下面的 GRANT 语句之间省略了一个 GO 时。所以SP试图设置它自己的权限。是否有可能是超时或并发问题导致某些代码无法正常运行？

【讨论】：

正如@gbn 提到的，我也看到了由缺少 GO 引起的类似行为

【解决方案3】：

如果这种情况只发生在活动繁重的时期，也许您可以运行 Profiler 并观察正在持有哪些锁。

这是否总是以同样的方式运行？例如，它是否作为 SQL 代理作业运行？还是您有时手动运行，有时将其作为作业运行。我的想法是它可能作为差异运行。不同时间的用户。

也许也看看这个Blog Post

【讨论】：

锁定也是我的第一个猜测。这可能是一个虚假的错误消息，因为锁无法运行存储过程，但返回的错误消息与未经授权的错误消息相同。