SQL Compare 和 SQL Packager





0/5 (0投票)
2004 年 6 月 25 日
3分钟阅读

42864
解决 sysdepends 损坏时的简单脚本方案。
这是我们CodeProject赞助商的展示评论。这些评论旨在为您提供我们认为对开发人员有用且有价值的产品和服务信息。
问题所在
当数据库有相当数量的对象时,损坏的依赖信息是一个常见问题。本文解释了如何使用 Red Gate 的 SQL Compare 和 SQL Packager 自动编写数据库脚本,即使 sysdepends 表中包含的依赖信息丢失。
背景
SQL Server 的设计使得依赖信息在对象创建、修改和销毁时被记录。这种方法意味着在脚本创建期间几乎没有开销。在一个具有许多依赖关系的大型数据库中,这提供了显着的性能优势。
这种方法的缺点是它可以通过三个途径引入依赖错误
- 当依赖链中的一个对象被删除然后重新创建时;
- 当依赖链中的一个对象被重命名时;以及
- 当 SQL Server 中存在错误时。
当 sysdepends 表被损坏时,如果由 SQL Server 运行脚本,脚本很可能会失败。在这种情况下,通常的解决方法是让 SQL Server 编写数据库脚本,然后以您希望保留依赖关系的方式重新排序对象脚本。
在搜索引擎中输入“在 SQL Server 中编写脚本依赖关系”将很快返回大量人们正在努力解决此任务的故事。如果您的数据库有多个依赖关系,那么在重新创建数据库时,很难弄清楚您应该以何种顺序向 SQL Server 呈现脚本。
解决方案
Red Gate 的 SQL Compare 的一个鲜为人知的属性是能够在正确的顺序中编写对象脚本,而无需依赖 sysdepends 中的依赖信息。
作为 SQL Compare 如何处理缺失或不正确的 sysdepends 信息的极端例子,我们将删除数据库中的所有依赖信息。显然,这在现实生活中永远不会发生,但它很好地证明了 SQL Compare 如何完美地处理损坏的信息。
首先,我们创建两个数据库——已损坏和空白。
然后,我们创建三个具有简单依赖链的对象——一个表、一个依赖于该表的视图,然后是第二个依赖于第一个视图的视图。
在幕后,我们的 sysdepends 表已更新。
接下来,我们更改 SQL Server 上的基本权限。不要在任何包含重要信息的服务器上执行此操作。
现在我们清空 sysdepends 表。
接下来,我们重新配置 SQL Server 以使其正常工作,并查看 sysdepends 中是否有任何内容。正如您所看到的,sysdepends 现在是空的。
我们的数据库现在已损坏到无法修复的程度,直到现在,编写此数据库脚本是不可能的。但是使用新版本的 SQL Compare,它将完美运行。
我们首先将损坏的数据库与空白数据库进行比较。
这三个对象存在于损坏的数据库中。让我们创建一个脚本,将这些对象放入空白数据库中。
查看此摘要,您可以看到,尽管 sysdepends 表为空,但这三个对象将按正确的顺序创建。现在让我们运行此脚本并重新比较。
空白数据库现在具有这三个对象并且运行良好。
结论
sysdepends 很容易通过重命名、删除和重新创建对象或通过 SQL Server 中的错误而损坏。SQL Compare 在编写脚本期间轻松解决了这个问题。
Red Gate 的新产品 SQL Packager 更进一步,无需创建空白数据库的中间步骤即可修复损坏的依赖关系。
访问 Red Gate 的 网站以获取更多信息并下载您的 功能齐全的免费试用版。