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

我们的要求:


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

当前,以下原因对我来说是众所周知的:

SQL Server 2012 Denali

>
可用最新版本

SQL Server 2008 R2


成熟的技术

我似乎找不到有很多技术上的原因要优先于另一个。基本上,归结为选择成功运行的可靠技术与最新的最佳版本。

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

评论

我认为,只要每核许可更改不会改变您的预算,并且您不必担心供应商追赶缓慢,那么使用SQL Server 2012无疑是明智之举。这是基于成熟的技术,因此不应将其视为完整的重写和/或V1。

根据我之前三个版本的经验,我将至少等待一个Service Pack。在2008年之前,我一直等到R2,但仍然有缺陷。仅仅是我的顶峰:在2008 R2中,我可以绕过受信任的FK约束并插入孤立行,可以在SSMS中运行脚本,并且其中的一部分针对错误的数据库执行。

@AaronBertrand我认为您的比喻是错误的。如果您看到同一个人多次发短信并开车,那么就可以断定那个人是可怕的驾驶员。这就是OP的概括方式,而不像您建议的那样。

亚历克斯,让我知道什么时候交付了任何复杂的RDBMS平台而没有任何错误。 IIRC您的FK repro非常复杂,而且不是常见情况。还请让我知道,如果您认为软件公司不能随着时间的推移而变得更好,或者如果您预计SQL 2012中会出现slammer型漏洞,则在此之后的版本中,以及在此之后的版本中……在某些时候,您必须放弃这些老太太的故事,自己建立一个平台,而不要通过以前版本中的某些错误来判断它。

“等待服务包”是一个古老的神话和FUD

#1 楼

每个人都对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()

日期/时间构造函数(例如DATEFROMPARTS)类似于VB中的DateSerial

PARSE() / FORMAT()-与他们的.NET同类产品一样(但请参阅有关后者的本帖)

TRY_CONVERT() / TRY_PARSE()-如果NULL返回CONVERT / PARSE失败



扩展事件具有用于配置/查看的增强的UI,并且最终完全涵盖了跟踪/审核功能(包括更好的因果关系跟踪)。
许多新的DMV ,系统过程和ShowPlan增强功能,以进行诊断和性能故障排除。还请看一下CSS所谓的“黑匣子记录器”。
服务器核心使您可以在没有所有UI组件的情况下在裸机上运行(较小的表面积意味着它更安全,并减少了维护工作)因为较少的操作系统部分需要进行Windows更新)。
全文搜索获得了一些重要的基础性能增强,以及语义搜索(想像关键字)和可自定义的接近度/ NEAR。
AWE不再支持,这意味着x86上具有32GB RAM的SQL Server实例只能使用4GB-因此,您最终将有动力摆脱旧的32位硬件。


评论


回复:powershell评论,它仍然非常简单:gci c:\ users | where-object {$ _。Author ='Bob'-and $ _。creationdate -lt'1/1/2010'} | %{$ _。Readonly = 1}或类似内容-但不像2012选项那样简单易读!

– JNK
2012年3月9日在20:44

PS的伟大之处在于您可以(几乎)一行完成任何事情。不好的是,很难读那行:)

– JNK
2012年3月9日20:47

SSMS 2012更好吗?

–托马斯·斯金格
2012年3月9日20:56

是的,我喜欢它。我应该再写一篇关于它的博客文章。一些亮点:片段很棒,IntelliSense更好,区域编辑功能非常强大,标签条非常适合多显示器,并且内置了缩放功能。

–亚伦·伯特兰(Aaron Bertrand)
2012年3月9日20:57

我还可以将项目符号总结为:“ x86的吸引力将超过已经存在的力量。”

–亚伦·伯特兰(Aaron Bertrand)
2012年3月9日21:57

#2 楼

以下仅是根据要求提供的一些示例,这些示例涉及“任何新版本的第一版中支持或反对可靠性的实际证据”。这并不意味着要进行完整的分析,而是对您可能要研究的内容的建议。

您可以在Google上搜索“ SQL Server 2008 Service Pack 1修复的问题列表”,然后MSDN网站上的“ SQL Server 2008 Service Pack 3修复的问题列表”。比较两个列表中问题的数量和严重性。 IMO的第一个列表较长,并且有更多项目可能会破坏我的一天,例如:在客户端计算机上连接到SQL Server的命名实例时出现错误消息,正在运行Windows Vista或Windows Server 2008
运行日志读取器代理以复制事务时,日志读取器代理会跳过某些事务
当您运行涉及SQL Server 2008中的外部联接操作的查询时,错误消息<当您对没有在SQL Server 2008中创建的聚集索引的表执行更新或删除操作时出现错误消息
使用参数和RECOMPILE选项的查询在运行查询时返回不正确的结果在SQL Server 2008中同时进行多个连接中的操作

让我们向下钻取一个级别并仅考虑一个命令MERGE。它是作为SQL 2008的一部分发布的,存在一些问题,在以下链接中进行了介绍:



有趣的MERGE错误,

SQL Server 2008 RTM MERGE错误和修复,在非聚集索引(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的新增功能”演示文稿以及书籍,文章等中都推荐了这两个新功能,并且具有类似的热情。

我们需要非常小心使用新功能-并非所有功能都将是有用/可靠/高性能的。

评论


我看到了清单。并没有真正将其视为止步者,提到的几乎所有问题都影响到2008 R2和2012。

–亚伦·伯特兰(Aaron Bertrand)
2012年4月12日14:25

这是另一个可能导致死锁的MERGE错误。

–尼克·查玛斯(Nick Chammas)
2012年5月2日18:43

@NickChammas是的,对,谢谢您提到这一点。我们正在使用sp_getapplock来解决问题。

–A-K
2012年5月2日在20:45

#3 楼

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

对于未开发的项目,您有一些喘息的空间来解决错误。并在出现供应商的情况下向供应商提出要求,因此这不是一个完全不受控制的过程。当我进入RTM时,我参与了SQL Server 2005上的第一个数据仓库项目,我们就放弃了。

如果2008R2的功能集可以满足您的要求,那么决定归因于存在一些错误/解决方法的风险,与推迟升级必要性和节省升级周期的价值有关。

#4 楼

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

关于第一个Service Pack的需求,它将在您不知不觉中出现,并且由于您正在进行新开发,因此它所解决的问题可能不会对您拥有数百万人的旧数据库产生太大影响记录将面临。

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

评论


没有升级。这是在新硬件上的新应用。

–usr
2012年9月9日在22:28