4

我更改了一个存储过程，并在不知不觉中覆盖了其他开发人员对其所做的一些更改。有没有办法撤消更改并恢复旧脚本？

不幸的是，我没有该数据库的备份，因此排除了该选项。

4

8 回答 8

10

答案是肯定的，你可以找回来，但这并不容易。所有数据库都会记录对其所做的每一次更改。你需要：

  1. 关闭服务器（或至少将其置于只读模式）
  2. 对服务器进行完整备份
  3. 获取事故发生前所有数据库日志文件的副本
  4. 将备份恢复到另一台服务器
  5. 使用 db 管理工具，回滚日志文件，直到您“撤消”事故
  6. 检查存储过程中恢复的代码并将其编码回您的当前版本

最重要的是：让您的存储过程代码处于源代码控制之下

许多人不理解这个概念：您只能对数据库进行更改；您不能像使用应用程序代码那样通过将文件替换为以前的版本来回滚存储的 proc 版本。要“回滚”，您必须进行更多更改以删除/定义您的存储过程。

挑剔者注意：“回滚”并不是指“事务回滚”。我的意思是您已经进行了更改，并在服务器备份后决定更改无效。

于 2011-07-18T22:14:49.310 回答
3

您可以查看缓存的执行计划并尝试找到您的同事进行更改的执行计划并再次运行相关部分。

编辑

尽管如果您在 TL 中进行了更改，Bohemian 看起来会有一个很好的答案，但这就是我要说的。查看计划的 SQL 文本。

SELECT  cached.*,
               sqltext.*
         FROM  sys.dm_exec_cached_plans cached
  CROSS APPLY  sys.dm_exec_sql_text (cached.plan_handle) AS sqltext

但正如 squillman 所指出的，没有 DDL 的执行计划。

于 2011-07-18T22:02:19.863 回答
3

除了使用备份或从源代码控制恢复的合理建议（如果您没有做这些事情，您需要开始），您还可以考虑从@MladenPrajdic获取SSMS 工具包. 他的 Management Studio 插件允许您保留您处理或执行的所有查询的运行历史记录，因此很容易及时返回并查看以前的版本。如果其他人在最后一个已知的好版本上工作，这对您没有帮助，但如果您的整个团队都在使用它，任何人都可以返回并查看已执行的任何版本。您可以指定它的保存位置（到您自己的文件系统、网络共享或数据库），并微调自动保存启动的频率。真正无价的功能，尤其是如果您懒于备份和/或源代码控制（尽管我再次强调，你应该在再次接触生产服务器之前做这些事情）。

于 2011-07-18T22:52:21.737 回答
3

“有没有办法撤消更改并恢复旧脚本？”

简短的回答：不。

:-(

于 2011-07-18T22:01:31.380 回答
2

您将无法从数据库方面取回它。此时您的选择几乎仅限于 1) 从备份中恢复，2) 转到源代码控制或 3) 希望其他人在某处的编辑器中仍有副本或保存到文件中。

如果这些都不适合您，那么这是强制性的“您应该定期备份并使用源代码控制”......

于 2011-07-18T22:02:00.020 回答
1

我在这个游戏上迟到了，但我今天早上做了同样的事情，发现我在过去的某个时候忘记了保存我的脚本，需要恢复它。（我完成修复后它将在源代码管理中！！！）

有些人提到从备份中恢复，但没有人真正提到如果你有备份是多么容易。此外，您不会被锁定回滚生产数据库。我认为这是关键，假设你有一个备份，我会说这是一个更好的选择，而不是被投票选出的最佳答案。

您所要做的就是备份并将其还原到新数据库。拉出你正在寻找的 sp，瞧，你已经恢复了丢失的代码。

恢复丢失的文件后，不要忘记删除新创建的数据库。

于 2012-09-21T14:54:07.880 回答
0

我有同样的问题，我没有信心从日志文件恢复到另一台服务器。我非常心烦意乱，直到我意识到解决方案非常简单......

反复按 Ctrl-Z 直到我撤消更改并再次运行 ALTER PROCEDURE。

诚然，我很幸运我仍然可以恢复它，但它确实是最简单的解决方法。不过现在可能有点晚了。

于 2013-08-22T10:08:59.713 回答
0

如果您已经从 Management Studio 对象资源管理器中编写了存储过程的脚本，这将起作用。在展开和折叠对象资源管理器之前，只需滚动并指向您打开的存储过程。将存储过程编写为 create 或 alter to 脚本，然后您可以获取 proc 的先前版本，因为对象资源管理器尚未刷新。这永远是我的救命稻草。

于 2015-11-23T21:07:38.150 回答