Question

我的生产环境中有一个存储过程，最初是由没有足够时间正确设计的人编写的。它通过链接服务器连接以9个或更多连接写入数据库。

存储过程需要一个多小时才能运行。大约一年半以前，我重新设计了它（设计它？）以更有效地访问数据，现在存储过程只在链接服务器上进行两次不同的调用。这些更改后，运行时间降至不到5分钟。

大约6个月后（以及prod发布后的第二天），存储过程的性能可以恢复到一个多小时。当我查看存储过程（右键单击，修改）时，代码已经恢复了旧的糟糕代码。

任何有权运行ALTER PROCEDURE的人都不会承认已更改它，所以我做了任何理性信任的DBA会做的事情 - 我再次修复它并在生产数据库上放置一个DDL审计触发器来跟踪任何和所有DDL的生产变化。

大约6个月后，在发布产品后的第二天，糟糕的代码又回来了。检查DDL审计表显示没有触及存储过程。我修复了存储过程，修复事件显示在DDL审计表中。 W.T.H。??

我们使用Visual Studio在beta和prod之间进行模式比较，然后生成脚本，从而构建数据库发布脚本。生成的脚本的一部分是几个

EXECUTE sp_refreshsqlmodule N'[dbo].[db object here]';

呼叫。对于接下来的几个版本，我确保执行违规存储过程没有sp_refreshsqlmodule - 我们没有问题。然后我发布了一个版本，备份DBA没有删除sp_refreshsqlmodule调用 - 错误的代码返回没有DDL审核记录。

我们的生产服务器已使用正确的代码进行了几次硬启动。 sp_refreshsqlmodule在哪里/如何/是什么来获取存储过程的旧副本并将其放在好的副本上？如何将存储过程的良好版本强制进入这个神奇的隐藏位置？

Answer 1

我自己从来没有遇到过这个问题，但是我听说有人在使用ALTER命令修改了存储过程时遇到了这个问题（如修改所使用的那样）。当他们做了DROP和CREATE时，问题就消失了。

Answer 2

您可能遇到了sp_refreshsqlmodule

的错误

Microsoft连接链接已损坏，因此我正在共享Google缓存链接