3

在 SQL Server 2012 中，他们引入了包含数据库。这个功能的真正目的是什么？它修复了以前版本的哪些缺点？

4

1 回答 1

8

正在开发它们以使系统之间的数据库迁移更容易（您的数据库和 SQL Azure 上的数据库，它们需要四处移动以平衡资源）。任何在数据库之外具有依赖关系的东西都被认为是一种风险，因为它是必须与数据库一起使用的额外脚手架——容易忘记、容易出错、容易失去同步。

例如，在德纳利，这些问题得到解决：

  • 今天，当您将数据库移动到另一台服务器时，您还必须在服务器级别迁移所有 SQL 登录 - 这可能会很痛苦，尤其是当 SID 不同步时。使用包含的数据库，与 SQL Server 登录无关的数据库级用户只是在备份、分离、镜像、复制数据库等时出现。很好而且很容易。

  • 如果您的数据库的排序规则与服务器排序规则不同，您可能会发现在使用 #temp 表加入或执行其他操作时存在排序规则冲突，因为创建的 #temp 表将继承服务器排序规则，而不是调用数据库。虽然您可以通过在每个列引用上指定 COLLATE 子句来解决这个问题，但对于包含的数据库，#tempdb 会继承调用数据库的排序规则，覆盖服务器排序规则。

  • THROW() 几乎也可以属于这一类——因为您不再需要使用 sys.messages 来存储自定义消息。这不像上述两个问题那么常见，但如果不需要保持 sys.messages 同步，它确实可以更好地迁移到新服务器。这不限于包含的数据库，但它起着相同的作用。

  • 对于不符合“遏制”标准的事物，有一个 DMV 可以向您显示如果您将它们移动到另一台服务器可能会破坏的事物列表。例如，调用由三部分或四部分组成的名称。

在未来的版本中，还有其他问题将得到解决。例如：

  • SQL Server 代理是一个外部依赖项。当您将数据库移动到不同的服务器时，引用该数据库的 SQL 代理作业不会自动随数据库一起移动，您必须确定哪些受到影响并自己编写脚本（这并不像带 msdb 那样简单也）。在 SQL Server 的未来版本中，我设想（a）每个数据库将能够拥有自己的代理，或者（b）代理将被移动到操作系统级架构，其中一些翻译层会告诉您数据库的位置是，而不必让 Agent 在同一台机器上运行。当我们谈论 Azure、地理不同的网络等时，后一种选择可能会变得复杂。

  • 链接服务器也是一个外部依赖项。这可以通过数据库级​​链接服务器轻松解决 - 特别是因为这些只是同义词容器/指针。

还有其他人，但那些是重量级人物。

于 2011-07-14T02:59:36.027 回答