下载掌阅APP，畅读海量书库
立即打开
由于DB2 UDB V8版本将逐渐退出历史舞台，本节我们重点介绍DB2 9版本的主要功能，包括9.1、9.5、9.7、9.8等。比起之前的版本，DB2在9版本中对系统架构做了大量的调整。在9版中的每一个小版本中，DB2都着重在某一特定的方面进行提高。当然，每一个版本中包含着大量的新特性与功能，总的来说，每一个版本都在包含了前一个版本功能的前提下，有着自己的针对性。
在DB2 9.1版本中，主要的新特性就是原生XML、表分区与表压缩功能。从系统框架上看，DB2 9.1与V8相比并没有特别多的改变，总体的内存和进程模型基本相同。
XML则是IBM在DB2 9.1版本中主推的一个功能。如今在很多系统中，关系模型已经不能满足业务的需要了，而过去的XML Extender是将XML文档切分后用关系模型存储在关系数据库中，对性能和稳定性带来了很大的影响。在9.1版本中，XML作为一种DB2内建的数据类型，支持XML文档的解析、存储和快速访问，在性能和稳定性上都有极大的提高。XML特性目前在医疗行业有很多成功案例。
表分区则是一个非常有用的功能，能够让用户在最短的时间内将某一个表分区连接到一个表，或者从表中断开。这个功能在一些数据仓库和在线交易系统中被广泛使用。
DB2 9.1引入的行数据压缩能够为用户节省大量的磁盘空间，同时由于每一个数据页可以容纳更多的数据，读取同样多的数据则需要更少的I/O，也就是说，从某种程度上对性能也会带来提升。一般我们都认为性能与空间是成反比的关系，但是对于DB2 9.1的数据压缩，既可以提高性能也能够节省空间，因此是DB2 9.1中的一大亮点。DB2提供的行压缩比可以高达80%，已经获得很多客户的认可和好评。
在DB2 9.5版本中，抛开一些细节的改变不提，最主要的更改是架构的变更：在UNIX系统中原进程模型变为线程模型。实际上，这个改变并没有想象中的那样巨大。在DB2 for Windows中，DB2一直使用着线程模型，因此该技术已经相当成熟。一般来说，在操作系统内部的进程间切换的开销要远远大于线程之间的切换。因此，由进程模型变为线程模型会对系统性能有所帮助。
在DB2 9.5之前，由于很多用户使用32位系统，而线程模型在有限的寻址空间（最大4GB）中会造成过大的冗余开销（例如每个线程的堆栈空间），造成进程无法使用很大的共享内存。因此，在早期的32位系统中必须使用进程模型。但是到了DB2 9.5，大部分用户都已经使用了64位系统（少量的用户使用32位Linux和Windows），对于64位系统，进程的寻址空间已经几乎无限倍地增加，因此，从进程模型切换到线程模型已经具备了所需的条件（对于依然使用32位Linux的用户，一般从系统的业务量来说，也不会同时运行成百上千的并发连接，因此并不会造成过多的困扰）。
DB2 9.7的系统架构与DB2 9.5相比变化不大，最主要的特点就是与Oracle PL/SQL兼容和锁机制的增强。过去，DB2在锁机制上一直对很多开发人员造成困扰。与Oracle相对简单的锁机制相比，DB2严格的锁机制让应用程序的开发过程相对复杂，开发人员需要经过大量的测试与调整才能够在逻辑上保证应用程序不会造成过多的锁等待。而对于一些已经为Oracle专门设计的应用程序，想要移植到DB2上几乎是天方夜谭。于是，DB2 9.7的新特性则为应用程序的跨平台移植提供了方便。
首先，DB2 9.7中的当前已落实（Currently Committed）功能避免了互斥锁与共享锁之间的等待，这样对于很多使用了该特性的Oracle应用程序，可以在不更改大量应用程序的逻辑下移植到DB2中。
另一方面，DB2在9.7版本中增加了很多的存储过程与函数，支持PL/SQL语言，方便客户从Oracle迁移到DB2数据库中。
除了这两个方面，DB2 9.7在存储优化、数据库可管理性、监控、高可用性等方面也都有很大增强，下面为大家简要介绍：
●支持索引压缩、临时表数据压缩和XML压缩，更加降低了存储空间成本。
●支持内联大对象（Inline Large Object）。大对象的使用越来越多，但大对象在读/写时无法通过内存池缓存数据。在很多情况中，LOB字段存储的数据并不是很大，如果可以和普通字段存放在同一个数据页面就可以通过内存池缓存数据了，这就是内联LOB的好处。
●在线表迁移（Online Table Move）功能对于DB2运维人员来说是一把瑞士军刀，现代IT系统对数据库系统的持续可用性提出了更高要求，运维时间窗口越来越短，在线表迁移功能可以保证表迁移时例如表从一个表空间迁移到另外一个表空间、更改表的定义（增加/删除字段、改变字段数据类型、改变字段顺序等）、改变分区表的分区键或范围、执行在线表压缩、执行在线reorg等，数据仍然是可用的。在线表迁移通过ADMIN_TABLE_MOVE存储过程实现。
●支持实时表字段更改，比如字段定义变长或变短、字段类型更改、改变字段名等，在更改过程中，DB2扫描每条记录，验证是否满足更改条件，并对一些依赖对象做校验。
●在性能监控方面，DB2 9.7有了极大增强。新的监控模型不仅可以快速找出问题瓶颈，而且对系统的影响（Overhead）非常小。特别是对锁的监控，通过新的Locking Event Monitor可同时监控死锁、锁等待和锁超时。
●移植性增强。在早期版本，要从Oracle或Sybase数据库迁移到DB2数据库是一个令人抓狂、痛不欲生的苦差事，不仅是数据库之间的许多数据类型不兼容，更痛苦的是程序对象的迁移，如存储过程、函数和触发器等。原因是各家厂商在过程语言的实现上都有自己独特的语法。为了支持Oracle数据库迁移，9.7版本引入了number、varchar2等数据类型，引入了很多与time、math和string相关的函数，支持package等。另外，DB2提供了一个PL/SQL编译器，可以直接编译Oracle的PL/SQL，大大减少了迁移时间（注意：这个功能是与Postgres公司合作的结果），如图1.2所示。
图1.2 DB2 9.7支持PL/SQL编译器
●HADR备机可读。HADR最早在8.2版本引入，目的是在主备机之间同步数据，当主机失败时，切换到备机，提供灾难恢复功能。但HADR存在的最大问题是主机数据库正常使用时，备机数据库不能使用，无法读/写，这对资源是极大的浪费。在9.7 fp1版本中，DB2支持主机数据库使用时，备机数据库可进行读取操作，这样就可以充分利用备机数据进行一些数据分析、报表处理等工作。
DB2的最新版本则是PureScale，也就是9.8。这个版本可以说是对底层架构的完全重构。
在DB2 9.8之前，DB2的设计一直基于Shared Nothing架构，也就是多分区系统（DPF）中的每一个分区都拥有自己独有的资源。但是在DB2 9.8中，除了DPF架构外，DB2又增加了共享磁盘（Shared Disk，SD）架构，也就是并不以分区键将数据分配到不同分区，而是所有的分区都可以访问同样的资源。这样对于高并发系统，可以有效地提高数据均匀负载平衡和高可用性的能力。
共享磁盘架构在多年前就被经典的DB2 for z/OS所使用，因此从技术的大方向上看相当成熟。但是对于一个使用了全新架构的产品来说，需要一定时间的调整与磨合。目前已经有很多行业客户对PureScale表现出浓厚兴趣，IBM一直在致力于发展与改进PureScale系统，相信在不久的将来，越来越多的生产系统会使用SD架构。