3

最近，我一直在尝试重组一个没有设计文件组（只是默认PRIMARY）的旧数据库，并且除其他外，将一堆表移动到Data位于 SAN 上的新文件组。我知道如何迁移数据：

ALTER TABLE MyTable
DROP CONSTRAINT PK_MyTable WITH (MOVE TO [MyDB_Data])

ALTER TABLE MyTable
ADD CONSTRAINT PK_MyTable
PRIMARY KEY CLUSTERED (MyID)
ON [MyDB_Data]

但该死的，如果这不是我曾经做过的最乏味的工作。而且很容易出错。有一次，在我意识到我不小心在 PK 中包含了一个值列之前，我移动了一个 30 GB 表的一半（我假设，因为没有进度指示器）。所以我不得不重新开始。

当表有很多依赖时，情况会更糟。然后我不能只删除主键；我必须删除并重新创建每个引用它的外键。这导致了数百行样板代码；乘以 100 个表，它就变得非常愚蠢。我的手腕受伤了。

有没有人想出一个捷径呢？是否有任何工具（以一次性使用的概念定价）可以做到这一点？也许这里的某个人之前必须经历过这个过程并编写了他们自己不介意分享的工具/脚本？

SSMS 显然不会这样做 - 它只能为非聚集索引生成迁移脚本（并且它们必须是索引，而不是UNIQUE约束 - 至少在几个表上，无论好坏，聚集索引实际上并不是主键，这是一个不同的UNIQUE约束）。

并不是语法太复杂以至于我无法为它编写代码生成器。至少对于基本的 drop-and-recreate-the-primary-key 部分。但是加上计算所有依赖项并为所有外键生成删除/重新创建脚本的开销，这开始感觉它刚刚超过那个阈值，在这个阈值中，自动化和全面测试的工作量比只做每个表的工作量要多与上面的示例一样手动。

所以，问题是：这个过程可以以任何相当直接的方式自动化吗？ 我上面写的还有其他选择吗？

谢谢！

4

1 回答 1

2

IMO 最简单的方法是使用一种模式比较工具（我的工具、red gate 的 SQL 比较、Apex SQL Diff作为几个示例）来创建模式的脚本。然后，编辑该脚本以在正确的文件组中创建所有空对象。完成后，您可以使用相同的工具将新数据库与正确的文件组进行比较，它们将生成脚本来为您迁移数据。值得测试多个，以找到最适合您的。

于 2010-02-02T10:30:37.037 回答