2.3 升级DBMS的主版本和次版本
变更是个不争的事实，主流DBMS产品的变更相当快。通过在主要版本间交付恒定的错误修复和维护更新，DBMS软件主要版本的典型发布周期是18～24个月。实际上，需要设置全职岗位来保持DBMS软件的版本最新。
变更是个不争的事实。
DBA必须开发一种升级DBMS软件的方法，既要符合企业的需要，又能最大程度地减少由于停电和数据库不可用而带来的业务中断。
你可能已经注意到，本书交叉使用了主版本和次版本。宽泛地讨论DBMS的升级固然很好，但更精确的定义也是必要的。有关主版本和次版本之间差异的更详细讨论，请参阅“主版本或次版本”。
DBMS的版本升级可以认为是新的安装过程的一种特殊情况。安装过程所需的所有程序都适用于版本升级：必须规划适当的资源，考虑所有系统参数，并确保所有的配套软件都已经连接到位。然而，还有另外一个严肃的问题必须规划好：现有的用户与应用程序。需要对升级进行规划，尽可能少地对现有用户造成中断。此外，任何与DBMS协同工作的其他软件（如购买的应用程序、DBA工具和实用程序等）也都必须验证其与新DBMS版本的兼容性。总之，升级可以说是一种既棘手又有难度的任务。
主版本或次版本
供应商通常会在软件产品的主版本与次版本之间作区分。软件的主版本是关注的重点，有许多的变化和新功能。次版本通常只是轻微的改变，变化较少新功能也不多。
例如，Oracle数据库从Version 10g到Version 11g是个重大的变化（版本变化）。而11g的修正版Release 2会被认为是个次版本（只有较小的变化）。通常供应商会在发布主版本时提高价格，而次版本则不一定（但这也不是一个严格的规定）。
通常在版本升级时会添加重要的功能，而在中间的修正版本中则相对较少。然而，从其中的一个修正版本升级到另外的修正版本，可能会存在像主版本升级时那么多的潜在隐患，这取决于每个特定版本发布的新功能的特征。
在这一章讨论的问题和关注点涉及两种类型的DBMS升级：新的次版本和新的主版本。
在一个复杂的、异构的、分布式的数据库环境中，连贯的升级策略必不可少。实际上，即使企业只有一个DBMS，也应该慎重对待DBMS升级并制订相应的计划。计划失败会导致对新功能的采用不当且效率低下，新的以及现有的应用程序性能下降，甚至停机。
升级到新的DBMS版本，回报和风险共存。以下是升级到新版本的一些好处：
开发人员可以利用新版本提供的新特征和新功能。如果开发正好需要某个新功能，或可以直接受益于某个新功能，那么可以相应地减少程序的开发时间或者提高其成本效益。
对于购买的应用程序，供应商可能需要DBMS的某个特定版本或其应用程序的某个特定版本的次版本，来启用该应用程序的特定功能。
新的DBMS版本通常会提供增强的性能和可用功能，用以优化现有的应用程序。有时，新的DBMS版本需要扩展应用程序，以支持更多的用户或更大的数据量。
DBMS供应商往往对软件的新版本提供更好的支持，且响应问题的速度也更快。因为他们不愿看到新版本和大力推广的版本中的错误造成的负面影响。
升级到新的DBMS版本可能节约成本。有企业使用同一DBMS的多个版本时（如测试环境使用新版本，而生产环境使用旧版本），供应商会收取额外费用。如果两个环境都升级到同一版本，DBMS的价格有时会有所降低。
一旦生产环境升级到新的DBMS版本，将会调整测试和生产的数据库环境，从而使开发和实施的环境一致。如果测试环境运行新版本的时间过久，数据库管理和应用程序开发就会变得更困难，因为测试数据库与生产数据库将有不同的操作。
然而，有效的DBMS升级策略必须平衡升级带来的利益与风险，以得到升级DBMS新版本或次版本的最佳时间。升级到新的DBMS版本的风险如下：
有效的DBMS升级策略必须要平衡升级带来的利益与风险。
DBMS的升级通常会牵涉某种程度的业务运营中断，至少，DBMS升级时数据库是不可用的。如果DBMS升级发生在正常的工作时间（或非计划内停机时间），可能会导致停机和丧失商业机会。个人数据库集群迁移到新DBMS版本的同时，集群数据库实现可能允许一些数据库可用。
可能会发生其他中断，如数据库结构转换或恢复那些先前支持而新版本中移除的功能（从而导致应用程序错误）。也存在应用程序实施进度延迟的可能。
升级的成本是DBMS版本迁移的重大障碍。首先，必须预算新版本或新次版本的成本（DBMS新版本的加价可能高达10%～25%）；其次，还必须将升级成本纳入DBMS以及使用数据库的任何应用程序的规划成本、安装成本、测试成本和部署成本；最后，一定还要包括为了使用这些新功能所需的任何新资源的成本（如内存、存储、额外的CPU）。
DBMS供应商经常吹捧新版本可以提升性能。而当SQL技术改变时，DBMS的新版本有可能获取更糟糕的SQL访问路径。DBA必须实施严格的测试过程以确保该访问路径对应用程序性能是有帮助的、无害的。性能受到影响时，可能需要改变应用程序的代码，这是一项非常昂贵又耗时的工作。严格的测试过程应该可以获取测试环境中的大部分访问路径更改。
新的DBMS版本可能会废弃现有应用程序正在使用的一些功能和语法。如果这种情况发生，必须在升级前对应用程序进行修改。
为了利用新的DBMS版本的一些改进，DBA可能要应用一些侵入性的改变。例如，如果新版本增加了一个数据库对象的最大值，DBA可能必须删除并重建此对象以利用该最大值。这将在DBMS内部控制架构增加的情况下，促进这种变化。
配套软件产品可能缺乏对新的DBMS版本的即时支持。配套软件包括操作系统、事务处理器、消息队列、购买的应用程序、DBA工具、开发工具以及查询和报告软件。
在对升级到一个新的DBMS版本的利弊进行权衡之后，DBA团队必须创建一个适用于该企业的升级计划。有时出了新版本后立即进行升级，但往往会滞后一段时间，大约为新版本发布后广泛采用前的这么一段时间。
如果一个新版本的风险大于利益，在不影响未来升级的情况下，一些企业可能选择跳过临时的升级。例如，大量的Oracle用户选择直接从Oracle 7升级到Oracle 8i，而跳过了Oracle 8。如果DBMS供应商不允许用户绕过某个版本或次版本，那么就等到下一个版本发布之后再进行部署。例如，考虑以下一些情况：
1.?ABC公司在使用DBCorp的数据库DB第8版。
2.?DBCorp宣布发布DB第9版。
3.?ABC公司分析了该版本的功能和风险后决定暂不升级。
4.?DBCorp稍后又发布了DB第10版，但没有提供从第8版到第10版的直接升级路径。
5.?ABC公司觉得第10版提供了许多有用的功能，决定马上升级。然而却没有理由来部署使用第9版。
6.?为了满足需求，ABC公司首先升级到第9版，随后立即升级到第10版。
尽管升级多个版本需要更多的时间，但这么做允许用户有效地控制何时以及如何升级到新的DBMS版本，而不至于受DBMS供应商的牵制。尝试多个版本的升级时，一定要充分了解每个临时版本新增的功能和特性。如果遇到以上假设的ABC公司的情况时，DBA就需要研究并准备那些新功能了，不仅第10版，还包括第9版的。
多个版本的升级允许用户有效地控制何时以及如何升级到新的DBMS版本。
适当的DBMS升级策略取决于多种因素。以下章节概括了有效的DBMS升级策略必须考虑的所有问题。