在2008 R2上优于SQL Server 2012的客观业务原因是什么？

我的公司正在决定是否要为新的数据库服务器购买SQL Server 2012 Denali或SQL Server 2008 R2。我正在寻找客观原因来选择一个。

我们的要求：

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

目前，我知道以下原因：

SQL Server 2012 Denali

• 最新版本

SQL Server 2008 R2

• 成熟的技术

我似乎找不到很多技术原因来偏爱一个。基本上，归结为选择能够成功运行的可靠技术，而不是可用的最新和最佳版本。

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

每个人都对AlwaysOn和ColumnStore感到兴奋，但是SQL Server 2012的许多好处并非高端版本独有。我不想听起来像发言人，但是我已经在SQL Server 2012上进行了大量演讲，并且我认为无论您选择哪种版本，它都可以提供很多功能。

• 部分包含的数据库，使您可以在服务器或环境之间移动数据库，而减少了一些麻烦（即服务器级别的登录名和服务器归类依赖性-将来的版本将处理棘手的项目，如链接服务器和代理作业）。

• Management Studio现在是一个更好的工具，与Visual Studio保持一致。IntelliSense更好，并且其他许多功能使编辑更加容易。现在，您当然可以在服务器上安装2008 R2并使用SSMS的2012版本了，但是我不确定这在许可方面是如何工作的，并且有些商店不希望使用混合版本（我更喜欢使用最新的工具）我的工作站甚至可以管理下层服务器）。我在很早以前就写了关于更改的博客，当时仍然有bug，所以请忽略负面影响，因为RTM的大部分或全部已修复。现在，当我不得不使用早期版本的SSMS时，我会发抖。

• 元数据增强功能使您可以检查对象和临时查询的结果集，还可以更好地调整查询的输出。

• 使用“自定义服务器角色”，您可以在角色级别为用户定义更精细的权限集，而不必一个个地授予/撤消权限，或者只是让复杂性变差并赋予他们sysadmin。

• 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()
  • DATETIMEFROMPARTS与DateSerialVB中类似的日期/时间构造函数（例如）
  • PARSE()/ FORMAT()-就像他们的.NET同行一样
  • TRY_CONVERT()/ TRY_PARSE()-返回NULL如果CONVERT/ PARSE失败

• 扩展事件具有用于配置/查看的增强的UI，并且最终完全涵盖了跟踪/审核功能（包括更好的因果关系跟踪）。

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

• Server Core允许您在没有所有UI组件的情况下在最低限度的服务器上运行（较小的表面积意味着它更安全，并减少了维护，因为较少的OS部件需要进行Windows Update处理）。

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

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

以下是根据要求提供的有关“任何新版本的第一版中的可靠性的可靠证据”的几个示例。这并不是要进行完整的分析，而是对您可能要研究的内容提出建议。

您可以在MSDN网站上通过Google搜索“ 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的一部分发布，存在一些问题，在以下链接中进行了介绍：

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

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

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

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

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

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

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

对于未开发的项目，您有一些喘息的空间来解决错误，如果发现错误，请与供应商联系，因此这不是一个完全不受控制的过程。当我进入RTM时，我参与了SQL Server 2005上的第一个数据仓库项目，而我们却放弃了。

如果2008R2功能集可以满足您的要求，则可以决定是否存在错误/解决方法的风险，而不是推迟升级和节省升级周期的价值。

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

至于对第一个Service Pack的需求，它将在您不知道的情况下就已经存在，并且由于您正在进行新的开发，因此它所解决的问题可能不会对您造成太大的影响，不会影响拥有数百万条记录的旧数据库。

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