迁移 CLR 程序集

K09*_*K09 7 sql-server migration sql-clr

我正在将 SQL Server 2008R2 数据库迁移到新服务器。(也是 2008R2)

服务器上有许多 CLR 程序集。这些会自动随数据库迁移还是我必须手动编写脚本?

谢谢!

Sol*_*zky 7

你是如何迁移数据库的?通过备份/恢复或分离/附加将数据库复制到另一台服务器将包括程序集以及指向程序集中代码的 T-SQL 包装器对象。使用可让您选择对象类型的工具可能需要您至少验证已选择要迁移的程序集。

如果您的所有程序集都有一个PERMISSION_SETSAFE那么您应该没有额外的步骤(除了在另一个答案中提到的明显启用 CLR 集成之外)。

如果任何程序集具有其中PERMISSION_SET之一EXTERNAL_ACCESSUNSAFE那么您将需要执行一些额外的步骤:

  1. 如果您使用的是非首选但更容易且因此更常用的方法来设置TRUSTWORTHYto的数据库属性ON,那么您需要确保ON在新服务器上将其设置为。我希望备份/恢复方法能够正确执行此设置,但其他方法可能不会,尤其是当它们在目标上创建新数据库时。
  2. 如果您使用基于非对称密钥的登录的首选方法,那么这些部分位于[master]数据库中,您需要确保在目标上复制或重新创建它们:
    1. 确保所有的非对称密钥(即用于CLR安全性)中存在[master]的目的地
    2. 确保所有基于这些非对称密钥的登录都存在于[master]目标中
    3. 确保这些登录在目标上具有相同的服务器级权限:GRANT EXTERNAL ACCESS ASSEMBLY和/或GRANT UNSAFE ASSEMBLY
  3. 无论您使用上述两个选项中的哪一个,请确保数据库所有者 SID 在数据库属性中显示的内容与[master]数据库元数据中记录的内容之间匹配。如果创建目标数据库然后将对象复制到其中,这通常不是问题,但如果使用备份/还原,则数据库所有者 SID 可能不匹配,这将阻止 CLR 代码运行
  4. 我不太确定这一个,因为我还没有在几年遇到过的,但有一个,如果DB所有者SID是变化的,那么对于任何组件PERMISSION_SET的任何EXTERNAL_ACCESS或者UNSAFE,你可能需要至少PERMISSION_SET属性重置为SAFE然后回到原来的样子。如果这没有帮助,那么您可能需要删除并重新创建程序集和关联的 T-SQL 包装器对象。

确保存在于当前/源服务器上的任何 4.0 之前版本的 .Net 框架也存在于目标服务器上也是一个好主意。目标上是否存在其他框架版本并不重要,但如果至少没有遗漏任何东西,它将使过渡更加平滑。尽管 SQL Server 2005 - 2008 R2 静态链接到 .Net 2.0 系列(2012 和 2014 静态链接到 4.0 系列),但程序集可能需要 3.0 或 3.5。如果发生这种情况并且那些框架版本尚未加载,那么您将收到一条神秘消息,该消息并不意味着缺少 .Net 框架版本。但是,如果 CLR 对象当前可以运行,那么显然不需要源服务器上没有的任何版本。


Sea*_*ser 3

那要看。

如果程序集已创建并存在于正在迁移的数据库中,那么它们将随数据库一起迁移,因为它们已经是数据库中的对象。

如果程序集是在未迁移的其他数据库中创建的,则需要在源实例中的某个位置重新创建它们。例如,如果程序集是在 master 数据库中创建的,那么它不是您要迁移的用户数据库的一部分,需要在目标服务器上的 master 数据库中创建。

由于您从同一版本的 SQL Server 迁移到同一版本的 SQL Server,因此我认为这不是问题。然而,为了将来的参考,当从 2005 年迁移到 2012 年时,程序集的执行可能会出现一些问题,因为它们是在不同版本的 .net 中制作的,并且具有被认为是安全的不同类。

  • 新实例在实际执行相关程序集之前需要“exec sp_configure 'clrenabled',1”。 (2认同)