SQL Server 2012实施与管理实战指南
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

1.5 数据库的升级

数据库的升级主要指的是大版本升级,如从SQL Server 2008升级到SQL Server 2012。跟打补丁不同的是,在SQL Server 2008及以后的版本,打完补丁后我们还可以把该补丁卸载。而对于大版本升级,一旦升级成功就无法降级。所以在对数据库做大版本升级之前,需要做一个好的评测:

① 旧版本数据库功能在新版本上是否有大的变化会导致应用不能正常工作?

② 旧版本上性能稳定,但是在新版本上数据库性能是否有大幅度降低?

③ 在线升级会不会有什么风险?在数据库升级过程中,万一出现异常,导致服务无法启动,有没有回退预案?

④ 对于有数据库镜像、复制、日志传输、群集这样的复杂环境,升级的顺序是怎样的?

⑤ 数据库升级成功后,有没有什么需要特别注意的?

对于第一个问题,建议读者使用SQL Server Upgrade Advisor(升级向导)。这个工具在安装介质上能够找到,在redist\Upgrade Advisor路径下。安装成功后,其主要界面如图1-22所示。

图1-22 使用SQL Server 2012升级向导

读者可以输入Profiler Trace或SQL Batch文件。根据这些信息升级向导会评估老版本的SQL Server升级到新版本的SQL Server应用程序是否会有兼容性问题。

对于第二个问题,建议读者在升级前做一下性能测试。升级向导能发现潜在的兼容性的问题,但是对于性能问题帮助不大。由于大版本之间功能变化会比较大,有些语句的执行方式可能会发生变化。在一些比较极端的情况下,甚至会发生新版本跑得比旧版本慢的情况。所以对于性能要求很高的系统,建议在大版本升级前一定要在新版本数据库服务器上做一下性能测试。以确保性能方面至少没有变差。对于有性能差异的语句,需要调整语句或者表格的设计,使其更适应新版本的特点。否则一旦升级成功,而后发现性能有问题则会处于进退两难的尴尬境地。

第三个问题是关于在线升级的风险,在线升级的优点是无须做比较大的改动,直接在原服务器上升级服务即可。缺点是万一升级失败,必须找到升级失败的原因并对其进行修复。最差的情况是,升级到一半失败而服务无法正常启动,升级又无法回滚,处于前进不得后退不得的境地。比较安全的做法是在升级前,对系统和所有的数据库做一个备份。这样即使升级失败,也可以通过重装旧版本数据库服务恢复正常运营,有较大的回旋余地。

第四个问题,对于一些有特殊配置的数据库服务,要注意升级的步骤,否则容易发生数据库同步失败。

数据库镜像:根据镜像模式不同,可采用如下推荐步骤。

① 首先把数据库设为High-Safety模式,并且把Witness去掉。

② 升级镜像服务器。

③ 切换数据库到升级后的镜像服务器。

④ 在新的主服务器上,检查数据库,并恢复镜像。

⑤ 升级新的镜像服务器(旧的主服务器),升级成功后,再做一次切换,数据库继续运行在旧的主服务器上。

数据库镜像的升级方案如图1-23所示。

图1-23 数据库镜像的升级方案

日志传输:

● Monitor数据库服务可在任何时候进行升级。

● Secondary数据库服务应先升级。否则如果先升级Primary数据库,则Primary数据库服务的备份无法恢复到Secondary数据库服务,日志传输会失败。

● 升级完Secondary数据库后,再升级Primary数据库。

复制:对于复制,在升级的时候,要注意下面的几点。

● 分发数据库版本要高于或等于发布数据库版本。

● 对于事务复制,发布数据库和订阅数据库可以有两个版本的差别。如发布数据库版本为SQL Server 2005,订阅数据库版本为SQL Server 2012。或发布数据库为SQL Server 2012,订阅数据库版本为SQL Server 2005。在升级之前要确保已发布的所有已提交事务已经由日志读取代理器进行了处理。

确认Log Reader Agent在运行。

停止用户在Published表上的操作。

给定足够的时间,使得Log Reader Agent能够复制事务到分发服务器。

运行sp_replcmds,确保所有的事务都被处理,运行结果应该是空的。

运行sp_replflush,关闭连接。

对数据库进行升级。

升级后,确认Log Reader Agent和SQL Server Agent是运行的。

● 对于合并复制,要求订阅数据库的版本低于发布数据库的版本。在升级后,要为每一个合并发布运行快照代理,并为每一个订阅运行合并代理,以更新复制的元数据。

群集:对于SQL Server 2008以后的版本,下面是推荐的升级步骤。

① 确保所有的磁盘资源是上线的。

② 首先升级被动的结点上的数据库服务器。

③ 做一个切换,把数据库服务切换到被动结点。

④ 再升级新的被动结点。

⑤ 把数据库服务切换到原来的主动结点。

当然最好的办法是数据库管理员能先在测试环境上,把升级的步骤确认一下,然后再在生产环境上实施。这样如果有什么步骤上的问题,在测试环节就能发现。

第五个问题,大版本升级完成后,并不是什么都不用做了。读者还需要:

● 确认数据库的兼容级别升级到了最新的数据库版本。

● 重建数据库上的索引。

● 重新更新数据库上的统计信息。

这几步非常重要。否则,表格上的统计信息可能不准确,会导致升级以后的系统出现严重的性能问题。

数据库的升级一般问题不会太大,只要我们明确升级的步骤按部就班即可。最好在升级前对所有的数据库(包括系统数据库)做一个备份,这样即使升级出现异常,我们还是有办法在一定的时间内重新恢复业务。对数据库服务大版本升级后,一定要重建索引和更新统计信息,不然性能上会有影响。