您应该使用哪个版本的SQL Server?

在安装下一个SQL Server之前,请先等等。您确定使用的是正确的版本吗?

我知道,管理层希望您继续使用较旧的版本,供应商表示他们将仅支持较旧的版本,但是现在您有机会为较新的版本辩护,我将从黑暗时代开始,介绍每个较新的版本。

 

一、 应考虑使用SQL Server 2008

在今天,SQL Server 2008已不是推荐的版本,因此让我们继续往下看。

 

二、 应考虑使用SQL Server 2008 R2

您需要从SQL 2008开始添加的这些新功能:

  • PowerPivot for Excel(已被替换)
  • Utility Control Point(没人使用)
  • Master Data Services
  • StreamInsight

 

三、 应考虑使用SQL Server 2012

  • 应用程序的最新支持版本仅为SQL Server 2012,而非2014或更高版本。
  • 您不愿意安装修补程序(因为SP4于2017年10月发布,此后仅存在一个安全修复程序,仅此而已。)
  • 您可以在2年内轻松构建另一个SQL Server(因为支持终止于2022年7月)。
  • 您要么不需要强大的备份加密功能,要么愿意购买第三方工具来获取备份。

2012引入了一些新特性——可用性组,列存储索引,contained databasesData Quality Services等。但在2012时功能十分有限,并不推荐在2012时就使用这些功能。

 

四、 应考虑使用SQL Server 2014

  • 应用程序的最新受支持版本仅为SQL Server 2014,而非2016或更高版本。
  • 希望使用Always On可用性组(我甚至不愿意将其放在此处,因为它们在后续版本中将变得更加出色)。我只是将这视为考虑AG的最低起点(忘记2012),因为从2014开始,即使主库故障,从库也可读。
  • 您需要对备份进行加密,并且您不愿意购买第三方备份工具。
  • 您将日志传送用作报告工具,并且具有严格的权限要求(2014添加了新的服务器级角色,使此操作更加容易)。
  • 您需要在不更改代码的情况下提高性能,并且有大量时间进行测试。2014版本的基数预估器(Cardinality Estimator)针对不同的执行计划进行了更改,但总体上效果并不理想。您仍然必须花时间来查找会变慢的查询,并弄清楚如何缓解这些查询。

2014也引入了一些新特性例如:In-Memory OLTP(该版本不适合用于生产环境)、Buffer Pool Extensions, data files in Azure blobs, backing up to a URL, and Delayed Durability.

 

五、 应考虑使用SQL Server 2016

  • 您是一家独立的软件供应商(ISV)。2016 SP1在Standard Edition中为您提供了许多企业功能,这意味着您可以编写适用于Standard版本上的小型客户端和Enterprise版本上的大型客户端的应用程序。
  • 您需要一个非常著名的、文档齐全的产品,很容易找到现成的材料并雇用知道如何使用此版本的人员。
  • 您需要使用标准版。因为它支持128GB RAM(对于某些内部计划,例如查询计划,甚至可以超过它。)
  • 您需要一直使用到2026年。此版本的支持时间比SQL Server 2012/2014更多,因此可以安装一次并使用更长的时间。
  • 您对新应用程序有合规性需求。2016添加了始终加密,动态数据屏蔽,行级安全性和临时表,这些功能使您更轻松地构建保护对象并跟踪您的宝贵数据。
  • 您想使用列存储索引。我将其称为最低版本,因为它们最终是可更新的,并且列存储索引和行存储索引都可以建在同一表上。参考 https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-what-s-new?view=sql-server-2017
  • 您需要查询计划监控,并且您买不起第三方工具。查询存储(Query Store)为您提供了一些非常酷的功能。如果明天我再次从事全职的DBA工作,那么它和PowerShell将是我可能掌握的两项技能。

六、 应考虑使用SQL Server 2017

  • 您愿意每30-60天安装一次补丁。在这样的较新版本中,修补程序更新非常快,并且它们修复了一些非常重要的问题。
  • 您的目标是零RPO和财务风险。2017在AG上新增了最低提交副本设置,可以确保提交被多个副本收到。
  • 您希望将来的升级更轻松。从2017开始,您可以在不同版本的SQL Server 间搭建分布式可用性组(Distributed Availability Group)。DAG的功能目前还不太强大、没有完整的文档,但我想将其作为进行更轻松升级的想法。在此之前,AG版本升级是绝对可怕的,并且通常最好建立一个新集群并迁移到该集群。
  • 您需要高性能的列存储查询。2017为批处理模式执行计划提供了很多不错的选择。
  • 您希望在Linux上运行SQL Server。但是,认真地看一下发行说明,然后单击每个“累积更新”阅读已修复的错误,一些群集错误确实使我大为惊讶。
  • 您希望在SQL Server中进行机器学习和R语言。我知道数据人员这样做是一种新潮,但是请记住,您需要为SQL Server许可在每核上花费2,000至7,000 美元来实现这一目标。

是的,我知道,我在2017没有写“您想要一个非常著名的、文档齐全的产品”,但这不是因为产品不好。它与2012/2014/2016相比相对较新,而且很难找到关于分布式可用性组或Linux上的SQL Server之类的优质培训,或者雇用知道如何使用它们的人

它们不是坏功能,它们是很棒的功能,但现在就采用为时尚早,仅凭最佳实践就更难了。不是不可能,只是更难。

 

七、 应考虑使用SQL Server 2019

  • 您需要尽可能长的支持寿命。直到2030年都将得到支持。问题是,整整十年不重新安装SQL Server会很好吗?
  • 您愿意每30-60天安装一次补丁。在这样的较新版本中,修补程序更新非常快,并且它们修复了一些非常重要的问题。
  • 您有能力通过实验而不是文档来学习。当您使用这些前沿功能时,您的实验和学习时间会增加,因为以下内容在某些方面没有公认的行业最佳实践。
  • 您擅长负载和性能测试。2019增加了许多很酷的功能,但是它也对现有的执行计划进行了重大更改。您将采取什么措施来减轻其性能下降?
  • 您很大程度上依赖于用户定义的功能。2019可以大大加快这些功能,尽管您需要进行大量测试。
  • 您在很大程度上依赖于表变量,并且可以更改代码。

 

八、 那么正确的答案是什么?

SQL Server 2017对大多数人来说是一个非常令人信服的案例。它在新功能、稳定性和较长的支持时间之间取得了很好的平衡。大多数人无法做到每年升级每台服务器中的数据库,通常是现在安装了2017,然后观察2019的发布情况,并计划在2021年进行2019年的部署。

发布了218 篇原创文章 · 获赞 29 · 访问量 5万+

猜你喜欢

转载自blog.csdn.net/Hehuyi_In/article/details/104071828