Question

最近我一直在尝试重新构建一个不是用文件组设计的旧数据库（只是默认的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张桌子，它就变成了彻头彻尾的asinine。我的手腕受伤了。

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

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

这不是语法太复杂，我不能为它编写代码。至少对于基本的drop-and-recreate-the-primary-key部分。但是增加了计算所有依赖关系并为所有外键生成drop / recreate脚本的开销，这开始感觉它刚好超过了这个阈值，自动化和完全测试的工作量比仅仅执行每个表更多手动与上面的例子一样。

所以，问题是：这个过程能否以任何合理直接的方式实现自动化？我上面写的有什么替代方案吗？

谢谢！

Answer 1

最简单的方法是使用其中一种架构比较工具（My tool，red gate's SQL Compare，Apex SQL Diff作为示例）来创建脚本您的架构。然后，编辑该脚本以在右侧文件组中创建空的所有对象。完成后，您可以使用相同的工具将新数据库与正确的文件组进行比较，并生成脚本以便为您迁移数据。值得用多个测试来找到最适合你的。

SQL Server中的自动文件组迁移

1 个答案: