与 2008 R2 相比，更喜欢 SQL Server 2012 的客观商业原因是什么？

Question

我的公司正面临为新的数据库服务器购买 SQL Server 2012 Denali 还是 SQL Server 2008 R2 的决定。我正在寻找客观的理由来选择一个。

我们的要求：

• 标准版（出于经济原因和不需要企业功能）
• OLTP 工作负载（这意味着我们不需要新的窗口函数和列存储索引）
• 数据库大小 10-100 GB
• 不需要商业智能功能。只需要关系引擎
• 同步数据库镜像

目前，我知道以下原因：

SQL Server 2012 德纳利

• 最新版本可用

SQL Server 2008 R2

• 成熟的技术

我似乎找不到很多技术原因来偏爱其中一个。基本上，这归结为选择成功运行的成熟技术与可用的最新和最好的版本。

做出决定的客观原因是什么？

Answer 1

每个人都对 AlwaysOn 和 ColumnStore 感到兴奋，但 SQL Server 2012 的许多优点并不是高端版本独有的。我不想听起来像一个发言人，但我已经就 SQL Server 2012 进行了大量的演示，我认为它可以提供很多适合您的版本。

• 部分包含的数据库允许您在服务器或环境之间移动数据库，而具有较少的束缚（即服务器级登录和服务器整理依赖项 - 未来版本将处理更棘手的项目，如链接服务器和代理作业）。

• Management Studio现在是一个更好的工具，与 Visual Studio 保持一致。IntelliSense 更好，一大堆其他功能使编辑更容易。现在当然你可以在你的服务器上安装 2008 R2 并使用 2012 版本的 SSMS，但我不确定它在许可方面是如何工作的，而且一些商店不想要混合版本（我更喜欢在我的工作站甚至可以管理下层服务器）。我很早就在博客上介绍了这些变化，当时仍然存在错误，所以请忽略负面因素，因为大部分或全部都在 RTM 中得到了修复。当我不得不使用早期版本的 SSMS 时，我不寒而栗。

• 元数据增强允许您检查对象和即席查询的结果集，还允许您更好地塑造查询的输出。

• 自定义服务器角色允许您在角色级别为用户定义一组更精细的权限，而不是一个一个地授予/撤销，或者只是屈服于复杂性并授予他们系统管理员。

• FileTable可以让您像管理文档表一样管理文件夹，但仍然可以对内容进行外部控制（因此想象一下能够使用 T-SQL 执行此操作，并想象一下在 cmd 或 PowerShell 中执行此操作有多么困难：）UPDATE C:\Docs\*.* SET ReadOnly = 1 WHERE Author = 'Bob' AND Created < '20100101';。 . 认为 FileStream 满足 WinFS 并获得一些启动的可用性。

• T-SQL 增强功能允许您完成许多在以前版本中很麻烦的事情：

  • THROW （将其视为重新加注）
  • OFFSET/FETCH（更简单的 ANSI 标准分页 - 另见这篇文章）
  • SEQUENCE （集中的 IDENTITY 机制，就像在 Oracle 中一样）
  • 窗口/框架增强（这里有各种各样的东西，例如令人敬畏的运行总计性能）
  • IIF()/ CHOOSE()/ CONCAT()/EOMONTH()
  • 日期/时间构造函数（例如DATEFROMPARTS）类似于DateSerialVB
  • PARSE()/ FORMAT()- 就像他们的 .NET 同行一样（但请参阅这篇关于后者的帖子）
  • TRY_CONVERT()/ TRY_PARSE()-NULL如果CONVERT/PARSE失败则返回

• Extended Events具有用于配置/查看的增强 UI，最终完全涵盖了跟踪/审计功能（包括更好的因果关系跟踪）。

• 许多用于诊断和性能故障排除的新 DMV、系统程序和 ShowPlan 增强功能。还可以看看 CSS 所谓的“黑盒记录器”。

• Server Core允许您在没有所有 UI 组件的情况下在最低限度的服务器上运行（较小的表面积意味着它更安全，并减少了维护，因为操作系统的较少部分受 Windows 更新影响）。

• 全文搜索获得了一些重要的底层性能增强，以及语义搜索（想想关键字）和可定制的接近度/NEAR。

• 不再支持 AWE，这意味着 x86 上具有 32GB RAM 的 SQL Server 实例只能使用 4GB - 因此您最终将有动力摆脱旧的 32 位硬件。

Answer 2

根据要求，以下只是关于“支持或反对任何新版本的第一个版本可靠性的实际证据”的几个示例。这并不是一个完整的分析，而是对您可能想要研究的内容的建议。

您可以在 MSDN 网站上搜索“SQL Server 2008 Service Pack 1 修复的问题列表”和“SQL Server 2008 Service Pack 3 修复的问题列表”。比较两个列表中问题的数量和严重性。IMO 第一个列表更长，它包含更多可能毁了我一天的项目，例如：

• 在运行 Windows Vista 或 Windows Server 2008 的客户端计算机上连接到 SQL Server 的命名实例时出现错误消息
• 当日志读取器代理运行以复制事务时，日志读取器代理会跳过一些事务
• 在 SQL Server 2008 中运行涉及外部联接操作的查询时出现错误消息
• 对没有在 SQL Server 2008 中创建的聚集索引的表执行更新或删除操作时出现错误消息
• 在 SQL Server 2008 中同时在多个连接中运行查询时，使用参数和 RECOMPILE 选项的查询返回不正确的结果

让我们再深入一层，只考虑一个命令，MERGE。它作为 SQL 2008 的一部分发布，但存在几个问题，在以下链接中进行了描述：

• 一个有趣的合并错误，
• SQL Server 2008 RTM 合并错误和修复，
• 在非聚集索引 (2008RTM) 上创建外键约束时的 MERGE 错误，
• INSERT/DELETE 使用和过滤索引时的 MERGE 语句错误，
• MERGE 查询计划允许违反 FK 和 CHECK 约束，
• MERGE 语句绕过参照完整性，
• 参数化 DELETE 和 MERGE Allow Foreign Key Constraint Violations。

因此，在最初发布 SQL 2008 时，我决定不使用 MERGE。我现在在 2008 R2 上经常使用 MERGE，我认为这是一个非常棒的功能。

编辑： 这里是最近修复的 SQL 2012 中的缺陷列表。希望能帮助到你。

另一个编辑：我选择了 MERGE 进行更详细的分析，因为它是一个非常重要的改进。事实上，这是赶上 Oracle 的重要一步，它确实提高了我们的生产力。因此，在 SQL 2008 发布时，MERGE 已大量上市。然而，它最初发布时还没有完全准备好在正式的生产系统中使用，并且没有简单的方法可以从演示文稿/文章/博客文章等中了解它。

类似地，快照隔离是一个很棒的新功能，它可以正常工作，但在 CHECK 约束中调用标量 UDF 并非在所有情况下都有效，因此当我们需要数据完整性时，不应在生产中使用。但是，在“SQL xxxx 中的新特性”演示以及书籍、文章等中，都以类似的热情推荐了这两个新特性。

我们需要对新功能非常小心 - 并非所有新功能都会有用/可靠/高性能。

Answer 3

这里没有提到的一点与功能集完全无关。如果您正在进行新的构建，您可以将数据库升级推迟一段时间，这样可以节省迁移成本。

对于绿地项目，您有一些喘息的空间来解决错误，并在错误出现时向供应商提出这些错误，因此这不是一个完全不受控制的过程。我参与了 SQL Server 2005 上的第一个数据仓库项目，就在它进入 RTM 时，我们成功了。

如果 2008R2 的功能集可以满足您的需求，那么决定就归结为一些错误/变通方法的风险，而不是推迟升级的必要性和节省升级周期的价值。

Answer 4

当您购买新产品时，选择与您考虑升级时大不相同。购买新的 我相信您应该始终购买您可以获得的最新版本。远早于 2012 版本将不再支持 2008 版本。最好从最新的开始，因为您将长时间使用此后端。

至于第一个服务包的需求，它会在您知道之前发布，并且由于您正在进行新的开发，因此它修复的问题可能不会像拥有数百万条记录的旧数据库所面临的那样影响您。

现在，如果您只是获得一台新服务器，但在其上放置了一个旧数据库，那么问题就变成了您要从什么升级？如果数据库已经是 2008 数据库，使用相同版本的风险会大大降低。如果要升级，请检查是否可以从您的版本直接升级到 2012。