在SQL Server 2012中,他们引入了包含数据库的概念。这个功能的真正目的是什么?它修复了以前版本的哪些缺陷?
在SQL Server 2012中,他们引入了包含数据库的概念。这个功能的真正目的是什么?它修复了以前版本的哪些缺陷?
例如,在Denali中解决了以下问题:
今天,当您将数据库移动到另一个服务器时,还必须迁移服务器级别的所有SQL登录 - 当SIDs不同步时,这可能很麻烦。对于包含的数据库,没有与SQL Server登录相关联的数据库级用户只需随着数据库备份、分离、镜像、复制等操作一起进行即可。非常简单。
如果您有一个与服务器排序规则不同的数据库,则在使用#temp表连接或执行其他操作时可能会遇到排序规则冲突,因为创建的#temp表将继承服务器排序规则而不是调用数据库的排序规则。虽然您可以通过在每个列引用上指定COLLATE子句来解决这个问题,但对于包含的数据库,#tempdb继承调用数据库的排序规则,覆盖服务器排序规则。
THROW() 也几乎属于这个类别 - 因为您不再必须使用sys.messages来存储自定义消息。虽然这不像上述两个问题那样常见,但如果没有必要也保持sys.messages同步,则迁移到新服务器的工作效果肯定会更好。这不限于包含的数据库,但它扮演着相同的角色。
对于不符合“容纳”标准的内容,有一个DMV可以显示在将它们移动到另一个服务器时可能会出现的问题列表。例如,调用三或四部分名称。
在未来的版本中,还将解决其他问题。例如:
SQL Server Agent是一个外部依赖项。当您将数据库移动到另一个服务器时,引用该数据库的SQL Agent作业不会自动随数据库移动,您必须确定哪些作业会受到影响并自己编写脚本(这不像只需带上msdb那么简单)。在SQL Server的未来版本中,我设想每个数据库都将能够拥有自己的Agent,或者Agent将移动到操作系统级架构,在其中一些翻译层告诉您数据库在哪里,而不是必须让Agent驻留在同一台机器上。后一种选择在涉及Azure、地理分散的网络等方面可能会变得复杂。
连接的服务器也是外部依赖项。这可以通过数据库级联机解决 - 特别是因为它们只是同义词容器/指针。
还有其他问题,但那些是重头戏。