快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

SQL Server 2008和2008 R2的终止扩展支持

在线QQ客服:1922638

专业的SQL Server、MySQL数据库同步软件

许多组织仍然在SQL Server 2008或2008 R2上运行他们的公司。升级的原因很多,但最紧迫的原因是扩展支持已用完。在本文中,Brian Kelley解释了这意味着什么,向您介绍了升级后将获得的一些功能,并提供了一些选项。

如果您还不知道,SQL Server 2008和SQL Server 2008 R2的扩展支持将在2019年7月9日结束。Microsoft已经将此结束日期告知了一段时间,包括此公告以及有关如何从这两个版本的Microsoft SQL进行迁移的资源。服务器。

这是什么意思

Microsoft具有已定义的生命周期支持策略,但是在本文撰写时,有两个单独的策略。SQL Server 2008和SQL Server 2008 R2属于一种,称为“ 固定生命周期策略”。根据此政策,Microsoft承诺至少提供10年的支持,而对于“主流支持”和“扩展支持”则至少各提供5年的支持。两者有什么区别?扩展支持结束时会发生什么?

主流支持

在“主流支持”下,客户可以获得事件(应用程序或系统的问题)和安全更新的支持。另外,客户可以要求产品设计和功能更改。如果发现与安全性无关的错误,Microsoft可以选择修复它并发布更新。多年来,Microsoft已将许多这些修补程序汇总到Service Pack和累积更新中。

扩展支持

除非客户拥有现在称为统一支持的特殊支持合同,否则扩展支持会终止常规事件支持以及对产品设计和功能更改的请求。Microsoft将继续发布安全更新,但通常不会发布其他类型错误的更新。SQL Server 2008和SQL Server 2008 R2处于固定生命周期,直到2019年7月9日为止。

扩展支持之外

如果不属于扩展支持更新计划的一部分,则扩展支持终止后,您的组织就没有其他更新,安全性或其他任何更新。仅当Microsoft认为特定的安全漏洞足够敏感时,他们才决定发布补丁,即使对于现在已超出扩展支持状态的系统也是如此。Microsoft已针对不支持的操作系统发布了几次补丁,但是您不应指望它。在讨论无法及时从SQL Server 2008或SQL Server 2008 R2迁移时该怎么办时,我将在本文结尾讨论更多有关扩展支持的信息。

合规要求

根据适用于您组织的行业标准,政府法规和法律,如果您拥有不受支持的软件,则可能会无法遵守法规。这意味着您将必须参加扩展支持升级计划,而该计划将产生费用。

升级理由

如果像我一样,您没有太多的空闲时间来升级系统。在IT中,总是要做的事情多于没有时间做。Microsoft停止支持是合理的理由,但是我希望从升级中获得更多收益,并且伴随着这种努力所带来的混乱不只是获得支持。好消息是,通过从SQL Server 2008或2008 R2升级,您可以立即使用其他功能。这些功能甚至不需要触摸任何应用程序。此外,较新版本的SQL Server包含大量功能,需要进行一些修改,但值得考虑。以下是一些新功能的列表:

SQL Server 2008和2008 R2的终止扩展支持

内存中OLTP

从前,有DBCC PINTABLE()命令,它使您可以将表保留在内存中以提高性能。尽管该命令仍存在于该版本的SQL Server中,但SQL Server 2005停止了该命令。这个想法是SQL Server的优化和获取功能足够强大,可以满足需求。

当然,这并不成立。因此,Microsoft研究开发了Hekaton,这是一个内存数据库选项。从头开始设计,它根本不像旧的DBCC PINTABLE()命令那样起作用,因为数据的存储方式不同。如果您需要此选项提供的性能,则该选项可在SQL Server 2014中使用。

列存储索引

大多数查询并不需要表中的所有列。但是,由于标准索引是按行组织的,因此您必须为与查询谓词匹配的每一行检索每一行以及每一行的每一列。从概念上讲,数据是这样存储的,对于给定的行,每一列都保持在一起:

SQL Server 2008和2008 R2的终止扩展支持

换句话说,引擎可能正在进行大量额外的读取操作以获得所需的数据。但是,由于这就是存储数据的方式,因此您别无选择。

列存储索引将数据存储在单独的段中,每个段一列。一列可以包含一个以上的段,但是任何一个段都不能包含一个以上的列。在较高的层次上,您可以想到索引的工作方式如下:

SQL Server 2008和2008 R2的终止扩展支持

结果,您只需要拉出与您关心的列相关的段,读取较少的页面即可获得更好的性能。继续使用概念视图,只需要BusinessEntityID,FirstName和LastName的查询就需要较少的读取,因为SQL Server不必仅读取整行中的Title,MiddleName,Suffix和ModifiedDate即可获取数据:

SQL Server 2008和2008 R2的终止扩展支持

列存储索引对于星型或雪花型方案具有较大事实表的报表和分析方案特别有用。列的分段和内置在列存储索引中的压缩意味着查询的运行速度比传统索引快得多。但是,此功能直到SQL Server 2012才可用。

可用性组和基本可用性组

如果您曾经使用过传统的故障转移群集实例,那么您将了解这种高可用性(HA)选项带来的痛苦。好消息是,只有一个实例,并且所有数据库都是高度可用的。需求的最大负担是所有节点都可以访问的共享存储。这意味着您只有一组数据库文件,并且只有一个可访问的数据副本。

对于故障转移群集实例,故障转移意味着在一个节点上停止SQL Server,然后在另一节点上启动它。这可以自动发生,但是在故障转移期间,SQL Server实例不可用。

通过SQL Server 2012中引入的可用性组,高可用性位于数据库级别。可用性组不需要共享存储。实际上,可用性组根本不使用共享存储。这意味着您有一个以上的副本:至少一个主副本,从一到八个辅助副本。这些辅助副本可用于只读访问。此外,如果某伙伴检测到页面级损坏并获得正确的页面来替换损坏的页面,则该技术允许任何一个伙伴(主要或辅助)与其他伙伴联系。此功能是自动页面修复。

最后,Microsoft在SQL Server 2016中引入了基本可用性组。您是否需要高可用性,但不需要访问辅助服务器以进行只读操作?然后,您可以利用仅需要标准版的基本可用性组,因此,它便宜得多。

审核对象

设置审核的最简单方法之一是使用恰当命名的Audit对象。但是,当Microsoft首次在SQL Server 2008中引入此功能时,Microsoft认为它只是企业版功能。尽管您可以使用扩展事件(实际上,审计对象是一组扩展事件)执行类似的操作,但设置起来并不容易。

随着行业对仅进行审核的需求的增长,Microsoft逐步改变了其立场。从SQL Server 2012开始,Microsoft为Standard Edition启用了服务器级审核。然后,在SQL Server 2016中,从SP1开始,您现在可以在Standard Edition的数据库级别上使用Audit对象。获得对Audit的访问权限对于我们SQL Server的合规性可以带来巨大的好处。我发现快速查看图表会有所帮助:

SQL Server 2008和2008 R2的终止扩展支持

备份加密

Microsoft在引入透明数据加密(TDE)时,还引入了加密备份。但是,最初,加密备份仅适用于受TDE保护的数据库。TDE是仅企业版的功能。这意味着只有在您(a)使用Enterprise Edition和(b)在特定数据库上配置了TDE的情况下,您才具有加密备份。

第三方市场(包括Red Gate)多年来一直在其SQL Server备份产品中提供加密。结果,社区要求Microsoft也将备份加密作为Microsoft SQL Server的标准功能包括在内,而不必使用TDE。因此,Microsoft将其添加到了SQL Server 2014中。

备份加密至关重要,因为精明的攻击者会寻找数据库备份。如果攻击者可以获取未加密的数据库备份,则攻击者不必尝试闯入SQL Server。攻击者获得了相同的回报,但工作量减少了。因此,如果您可以加密数据库备份,尤其是如果您属于没有第三方备份解决方案的公司,则可以迫使攻击者使用另一种希望更困难的方法来获取数据。攻击者必须尝试的技术越多,发现被黑客入侵的可能性就越大。

动态数据屏蔽

我会承认自己不喜欢数据屏蔽。实现数据屏蔽的解决方案要么使静态数据不被屏蔽,要么将算法与屏蔽数据一起以某种形式存储。这是有道理的,因为特权用户必须能够看到真实数据。SQL Server在这方面没有什么不同。

但是,SQL Server数据屏蔽的目的是为不应该看到实际数据的应用程序和用户提供无缝的解决方案。您可以定义屏蔽算法。您还可以使用新建权限定义谁可以看到真实数据UNMASK。只要您不更改用于适应屏蔽算法的字段的数据类型/长度,就可以实现动态数据屏蔽,而无需更改应用程序代码或用户查询,除非他们正在做一些事情来实际数据。

Microsoft在SQL Server 2016中引入了此功能,其实现可以解决有关保护系统或报表中数据的典型审核点。因此,如果您需要满足这种审核要求,那么从SQL Server 2008 / 2008R2升级是一个很好的理由。

行级安全

您可以使用视图多年在SQL Server中实现行级安全解决方案。但是,这存在一些问题,因为这些本地解决方案存在信息披露问题。攻击是基本的:精明的攻击者可以执行查询,该查询通过强制错误揭示有关解决方案的构建方式。需要一个真正的,集成的行级安全解决方案。结果,Microsoft首先在Microsoft Azure中实现了行级安全性,然后在SQL Server 2016中实现了此功能。

从经验上来讲,正确制定本地解决方案可能是一个问题。您必须注意如何编写过滤视图或函数。有时您会得到重复的行,因为安全主体匹配多种访问方式。因此,您最终将使用DISTINCT关键字或类似方法。另一个问题是,安全视图或功能通常会被序列化,这意味着在负载超过最小的任何系统中,性能都非常糟糕。

尽管您仍然可以在性能方面犯错误,但是可以避免信息泄露问题和行重复问题。

始终加密

在查看SQL Server的加密解决方案时,您应该询问谁可以查看数据。通常将重点放在DBA或管理员上。这是三个选项:

  1. DBA可以查看数据。
  2. DBA无法查看数据,但是安装SQL Server的OS系统管理员可以查看。
  3. DBA和系统管理员都无法查看数据。

通常会出于以下两个原因之一来挑选系统管理员:

  1. DBA对操作系统也具有管理权限。在这种情况下,#1和#2具有相同的权限级别,这意味着DBA可以查看数据。
  2. SQL Server的系统管理员没有Web或应用程序服务器的权限。

如果DBA可以查看数据,则可以使用SQL Server的内置加密机制,并允许SQL Server使用以下标准模式执行密钥托管:数据库主密钥对非对称密钥进行加密/证书对对称密钥对数据进行加密。如果DBA无法查看数据并且他们不是系统管理员,但是系统管理员可以(因为他们可以看到系统的内存),那么您可以使用SQL Server内置加密,但是您需要对那些密钥进行加密应用程序已存储和使用的密码。无论哪种情况,内置函数都可以完成任务,但是很难将其改造到现有的应用程序中,即使从头开始,它们也不是最容易使用的。

如果不允许DBA或任何可以访问系统内存的人查看数据,那么您将无法使用SQL Server的内置加密。数据在到达SQL Server之前必须先加密。以前,这意味着您必须在应用程序中构建加密解决方案。对于大多数开发人员来说,这通常不是技能。这意味着开发人员的工作超出了他们的核心知识体系,这意味着他们的工作速度比他们希望的慢。这也意味着他们可能会错过一些重要的事情,因为尽管他们尽了最大的努力,但他们仍然缺乏正确实施加密解决方案的知识。

另一种情况是您可能需要改造现有的应用程序,以确保数据库中的数据已加密和/或运行中的数据已加密。改造应用程序很昂贵。该系统已投入生产,因此更改是应用程序生命周期中最昂贵的。为了保持现有功能,进行这些更改将需要进行广泛的测试。如果我们的应用程序可以无缝地进行加密/解密,那不是很好吗?这就是“始终加密”的功能。

从SQL Server 2016(企业版)或SQL Server 2016 SP1(为标准版开放)开始,可以使用“始终加密”。“始终加密”在应用程序服务器上具有一个客户端。客户端从应用程序获取数据库请求,并无缝处理加密/解密。SQL Server中的后端数据以二进制格式存储,而SQL Server具有有关如何加密数据的信息:有关密钥的算法和元数据,但是,解密密钥并不与SQL Server存储在一起。结果,除非DBA可以访问多个SQL Server或安装SQL Server的OS,否则DBA无法解密数据。

更好地支持扩展活动

扩展事件是在SQL Server 2008中引入的,但是使用起来并不容易。例如,没有GUI可以帮助设置和使用扩展事件。使用扩展事件的唯一方法是通过T-SQL。

从SQL Server 2012开始,SQL Server Management Studio(SSMS)中引入了GUI支持。对于SQL Server的每个新版本,Microsoft扩展了您可以通过扩展事件监视的内容(双关语)。捕获有关新功能的信息的功能仅适用于扩展事件。如果您仍在“ C​​amp Profiler”中,则无法捕获这些功能,除非捕获每个T-SQL语句或批处理。那不是很有效。

摆脱Profiler服务器端跟踪而转向扩展事件的最重要原因之一就是性能。跟踪的观察者开销通常比扩展事件要高,尤其是在CPU负载下。使用Profiler(GUI)监视SQL Server活动时尤其如此。性能改进的另一个领域是过滤器/谓词。您可以像使用Profiler一样设置过滤器。但是,对于扩展事件,过滤被设计为尽快发生。SQL Server将考虑是否要捕获事件,因此将使用该筛选器。如果它碰到了过滤器,它将切出并且不再继续进行特定的扩展事件设置。这与不建议使用的跟踪行为不同。尽管跟踪仍将应用过滤器,这样做是在事件/数据收集发生之后进行的,这导致“相对较少的性能节省”。有了这两项改进,扩展事件应该只捕获您指定的数据,并且如果由于您指定的过滤器而确定您实际上对事件不感兴趣,就应该删除扩展事件,这意味着由于监视而减少了系统负载。

这就是为什么在大多数情况下,扩展事件比传统跟踪更轻量级的原因。他们当然可以捕获更多,特别是如果您使用的是SQL Server 2012及更高版本引入的任何新功能。就其本身而言,这可能是从SQL Server 2008迁移的一个重要原因。毕竟,您可以更好地衡量生产环境,同时最大程度地降低性能影响,则更好。

T-SQL中的窗口函数,我们要求的DDL等

对于SQL Server的每个新版本,Microsoft将添加新功能并改进现有功能。在SQL Server 2012中,Microsoft通过T-SQL引入了大量新功能。此功能中的某些功能适用于查询,而其他功能适用于配置和数据库架构管理。这是三个三个有意义的例子。

窗口功能

窗口函数基于定义的分区来计算聚合。SQL Server 2008和2008R2确实具有使用OVER()和PARTITION BY进行排名和汇总的窗口功能。使用SQL Server 2012,您会得到LAG()和LEAD()。您还可以使用聚合函数做更多的事情。例如,假设有一个场景,您必须报告每个订单的订单总数,但是还必须显示上一个订单总数(LAG)和下一个订单总数(LEAD)。您可能还有另一个要求,那就是显示运行总计。所有这些都可以放入一个简单的查询中:

最巧妙的功能是SUM()因为ORDER BYOVER()子句。注意,查询ROWS在框架子句中使用关键字。这是SQL Server 2012的新功能,ROWS此处的使用告诉SQL Server将所有当前行之前(包括当前行)相加。由于SQL Server一次收集数据,因此单个查询的执行速度比让多个查询尝试收集,重新收集和计算相同信息的查询要快。此外,数据全部在同一行上:

SQL Server 2008和2008 R2的终止扩展支持

围绕等级分布和RANGE子句的窗口函数更多,其用法与相似ROWS。SQL Server 2012大大扩展了SQL Server的窗口功能支持。

用户定义的服务器角色

当SQL Server 2005首次发布时,它引入了粒度访问模型。DBA可以将安全性应用于SQL Server的几乎每个对象或功能。Microsoft推动在内置数据库和服务器角色上使用新的安全模型。但是,当时某些服务器级别的功能键入的是登录是否具有sysadmin之类的角色,而不是检查登录是否具有CONTROL权限。因此,DBA主要停留在SQL Server附带的角色中。

另一个问题是SQL Server不允许在服务器级别使用用户定义的角色。因此,如果DBA希望使用粒度模型在服务器级别实现一组特定的权限,则可以这样做,但这与角色无关。这与创建角色,为角色分配权限,然后为安全主体(在SQL Server中为登录名或用户)授予该角色成员资格的最佳实践相冲突。DBA可以在数据库级别而不是服务器级别执行此最佳实践。使用SQL Server 2012,现在可以使用服务器级别的用户定义角色。因此,现在可以遵循此最佳实践。但是,您需要在服务器级别划分权限。您可以创建角色,分配权限,然后授予成员资格。

存在的话

DBA在处理部署时面临的一个常见问题是,脚本想要创建一个已经存在的对象,或者脚本想要删除一个不存在的对象。为了解决这个问题,DBA和开发人员通常不得不编写如下代码:

请注意,这些语句中的每一个都必须具有正确的名称。结果,DBA或开发人员将部署脚本汇总在一起以更新数百个对象,这将需要验证每个IF EXISTS()语句。如果没有第三方工具来为您执行这种脚本编写,那么它会很麻烦,尤其是在大型部署中。所有IF EXISTS()要做的就是检查对象的存在。因此,社区要求Microsoft IF EXISTS在该DROP语句中提供一个进行检查的子句,从而消除了对这种更大,更容易出错的子句的需要。Microsoft在SQL Server 2016中添加了此功能。现在,您只需执行以下操作:

DROP TABLE IF EXISTS FooTable;

如果该表存在,SQL Server会将其删除。如果该表不存在,则SQL Server继续运行不会出现错误。

迁移方式

希望您已获得批准,可以从旧的SQL Server 2008 / 2008R2实例迁移到新版本。下一个问题是“如何?” 最大的担忧之一是破坏现有应用程序。有一些技术可以最大程度地减少这些痛苦。

DNS是您的朋友

我听说有关迁移数据库服务器的主要问题之一是:“我必须更新所有连接。” 有时后面跟着“我不确定它们都在哪里,尤其是在报告方面。” 这是DNS可以提供​​帮助的地方。

我建议尝试在DNS中使用“友好”名称,而不是指服务器名称,而是指通用名称。假设有一个名为Brian的超级应用程序的应用程序。您无需指向SQLServer144的实际服务器名称,而是在DNS中创建一个别名BriansSuperApp-SQL(在DNS中用CNAME记录),该别名是SQLSErver144的别名。然后,您可以将应用程序指向该更友好的名称。如果在任何时候SQLServer144上的IP地址发生更改,则CNAME将始终是对SQLServer144的引用,这意味着客户端将获得正确的IP地址。此外,如果需要迁移到另一个SQL Server(例如SQLServer278),只需更改别名即可。将BriansSuperApp-SQL指向SQLServer278,然后重新指向客户端。您无需更改任何连接信息。

但是,如果已经有应用程序配置为直接指向SQLServer144,该怎么办?同样,DNS可以提供​​帮助。如果可以将数据库和安全性从SQLServer144迁移到较新的SQL Server,然后使SQLServer144脱机,则可以在DNS中使用相同的技巧。只是要删除指向SQLServer278的所有DNS记录,然后创建指向SQLServer278的名为SQLServer144的DNS记录,而不是引用指向SQLServer278的BriansSuper-SQL。我在迁移过程中使用了很多技巧,但是它确实要求所有数据库都大规模移动到单个替换服务器,而旧服务器必须完全脱机才能工作。

记住兼容性级别

如果您的应用程序要求兼容级别的SQL Server 2008或2008R2,请记住,较新版本的SQL Server可以支持通过设置为较旧版本的SQL Server的数据库ALTER DATABASE。SQL Server 2008和2008R2的兼容性名称均为100。SQLServer的所有受支持版本均允许您在此兼容模式下运行数据库。因此,您应该能够部署到SQL Server 2017(或2019,如果在阅读本文时已淘汰)。

数据迁移助手

如果不确定是否可以从SQL Server 2008迁移怎么办?新版本中是否有功能会中断?您可以将数据库移动到Azure吗?试图回答这些问题可能是艰巨的任务。但是,Microsoft确实具有数据迁移助手来评估您的数据库是否准备升级或迁移到Azure。以前,DBA将评估SQL Server升级顾问。数据迁移助手非常易于使用。首先,您需要创建一个项目,并告诉DMA您正在尝试做什么:

SQL Server 2008和2008 R2的终止扩展支持

在这种情况下,评估是针对从SQL Server到SQL Server的迁移(本地)。然后,您需要告诉DMA连接到什么以及要评估什么。DMA验证后,它可以连接并访问您选择的数据库,您将指出要查看的DMA:

SQL Server 2008和2008 R2的终止扩展支持

在这里,指定的目标是SQL Server 2017,并且指示DMA不仅要检查兼容性问题,还要检查可能有用的任何新功能。DMA会撤回并返回其评估:

SQL Server 2008和2008 R2的终止扩展支持

在这种情况下,DMA注意到全文搜索对象存在于数据库中。在DMA评估SQL Server 2014系统和DB的同时,请注意DMA仍然标记SQL Server 2008问题。与任何工具建议一样,您需要考虑所提供的信息是否适用于您的情况。在这里,由于DMA正在查看在SQL Server 2014上运行的SQL Server 2014 DB,因此将数据库升级到SQL Server 2017实例没有问题。

现在,AdventureWorks是一个很小的相对简单的数据库。您不会期望DMA会找到很多东西。对于您的数据库,尤其是大型和复杂的数据库,希望DMA暂时运行一段时间,并有更多建议和警告。

如果不能,该怎么办?

您可能处于无法在截止日期前行动的情况下。您有什么选择?有三种:

扩展的安全更新

第一个选项是加入前面提到的扩展支持更新程序,尤其是如果您必须使用本地SQL Server时。这是一个昂贵的选项,但这是维护对本地SQL Server支持的唯一方法。但是请记住,为了注册该程序,Microsoft可能会很好地要求您制定迁移计划,说明如何以及何时迁移到受支持的SQL Server版本。

微软Azure

如果您可以选择迁移到Azure中的VM,那么您将有三年的额外覆盖时间,如Microsoft在Microsoft Azure博客上的帖子中所述。如果您在Azure VM上运行,Microsoft已承诺免费提供扩展的安全更新。此外,博客还提醒用户,Azure中的托管实例是客户的另一种选择。

同样,您必须具有迁移到Azure的能力。但是,如果您已经在Azure中,或者已经准备建立状态,那么如果不能从SQL Server 2008或2008R2迁移,则Azure VM可能是解决方案。

没有支持就去

最后一个选项是在不支持的情况下继续运行SQL Server 2008或SQL Server 2008 R2。您的组织可能会认为Microsoft SQL Server仅通过少量补丁程序就已经相对安全。但是,有两个问题。

第一个问题是“您不知道自己不知道的事情。” 明天有人可能会发现一个至关重要的漏洞,易于利用,并且对手很快就会抓住它。SQL Server 2000时代的SQL Slammer就是这种情况。

第二个问题是合规性。一些法规,行业标准和法律要求系统在受支持的修补软件上运行。如果您的组织被要求以这种方式进行合规,那么在没有支持的情况下进行就意味着该组织故意违反合规性并面临被捕获的风险。这不仅仅是一个紧迫的问题。毕竟,许多法规和法律可能会在违规期满后很长时间内处以罚款。

组织应该只在经过适当的风险评估后才选择不提供支持。我知道有些组织决定由于无法迁移到Active Directory而决定继续在NT 4域上的情况。其他组织拥有只能在Windows 95,SQL Server 6.5或某些其他古老软件上运行的关键软件。他们找不到合适的替代软件,并且与运行不受支持的操作系统或软件相比,没有该软件或其功能的商业风险更为严重。但是,这些都是在考虑哪个风险更大之后才做出的明智决定。

结论

随着SQL Server 2008和2008 R2扩展支持的结束,现在该离开这些数据库平台了。即使您不需要从GRC角度进行升级,也可以利用新版本的SQL Server中的许多功能来使您的组织受益。Microsoft提供了升级工具和指南。一个示例是数据迁移助手。Microsoft还提供了其他有关SQL文档的文档指南,以涵盖您的迁移方案。如果您无法升级,但需要支持,则必须选择两种方法。成本更高的选项是进入扩展支持升级程序。另一个途径是在Microsoft Azure中部署到SQL Server 2008实例,因为这些实例将一直受支持直到2022年。

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1922638