代码之家  ›  专栏  ›  技术社区  ›  Aaronaught

SQL Server中的自动文件组迁移

  •  3
  • Aaronaught  · 技术社区  · 15 年前

    最近我一直在尝试重组一个不是用文件组设计的旧数据库(只是默认的 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中包含了一个值列之前,我移动了一个30GB的表(我假设,因为没有进度指示器)。所以我必须重新开始。

    当表有很多依赖项时,情况更糟。那么我不能只删除主键;我必须删除并重新创建 所有外键 它引用了它。这导致了成百行的样板文件;乘以100张表格,它就变成了一个非常愚蠢的东西。我的手腕疼。

    有人想出一个捷径吗?是否有任何工具(考虑到一次性使用的概念定价)可以做到这一点?也许这里的一些人以前必须经历这个过程,并且写下他们不介意共享的自己的工具/脚本?

    显然,SSMS不会这样做——它只能为非聚集索引生成迁移脚本(它们必须是索引,而不是 UNIQUE 约束-至少在一些表上,无论好坏,聚集索引实际上不是主键,它是不同的 独特的 约束)。

    不是因为语法太复杂,我不能为它编写代码生成器。至少对于基本删除并重新创建主键部分。但是,增加了计算所有依赖项和为所有外键生成drop/recreate脚本的开销,这开始让人觉得它刚刚超过了临界值,在这个临界值上,自动化和完全测试的工作量要比用上面的示例手动执行每个表的工作量大。

    所以,问题是: 这个过程能以任何合理直接的方式自动化吗? 我上面写的东西还有其他选择吗?

    谢谢!

    1 回复  |  直到 15 年前
        1
  •  2
  •   Matt Whitfield    15 年前

    最简单的方法是使用模式比较工具之一。( My tool , red gate's SQL Compare , Apex SQL Diff 例如)创建模式脚本。然后,编辑该脚本以在正确的文件组中创建所有空对象。完成后,您可以使用相同的工具将新数据库与正确的文件组进行比较,它们将生成脚本来为您迁移数据。值得用多个测试来发现哪一个最适合您。

    推荐文章