关于DB2版本、补丁升级和回退的总结[转载]

首先介绍几个概念

RELEASE的升级就是版本升级，例如9.1→9.5→9.7→10.1，可以跳版本升级，例如9.1→10.1

FIX PACK简称FP，就是打补丁，例如9.7.1→9.7.2，每个版本里的补丁是累加的，所以可以直接从9.7.1→9.7.6

PRODUCT，我们这里叫副本，就是拿着DB2安装文件安装到某一个地方，安装几个就是有几个副本。

实例目录，我们是在副本里的instance目录下执行./db2icrt -u xxx xxx 来创建实例的，实例创建后有自己的目录结构

 

版本升级

版本只能越升越高，不能降级。例如我拿着9.5、9.7两个版本的安装文件，分别安装到两个路径，叫副本1和副本2，然后我创建一个副本1的实例db2inst1，它的版本肯定是9.5咯，怎么给它升级呢，就是用ROOT进入副本2的instance目录，执行

./db2iupgrade db2inst1 然后这个实例就会升级到9.7，注意，这条命令只是修改了实例目录的东西，并没有影响到我们副本1里的内容，因为我们可以再用副本1创建一个实例，会发现新建的实例还是9.5版本。

版本升级不能回退，唯一的办法就是升级前做好备份，升级后有问题了删掉数据库，删掉实例，重新建一个9.5版本的实例，然后还原数据库。

 

打补丁

补丁就比较随意了，高低版本随意换。但是有两种方法:

方法1：

例如我现在有9.7.5、9.7.6两个版本的安装文件，分别安装到两个路径，叫副本1和副本2，然后创建副本1的实例db2inst1，它目前的版本是9.7.5，现在我想把它升级到9.7.6，只需要进入副本2，然后还是到instance 目录下，执行./db2iupdt db2inst1就行了。那反过来，如果我想把实例从9.7.6降到9.7.5，就进入9.7.5的副本里的instance目录下，执行./db2iupdt -D db2inst1就行了。这种方法的特点就是两个副本保持原样，不受影响，升级和降级都是只在实例自己的目录发生。

方法2：

例如我现在有一个9.7.5的副本，并且创建了一个实例，然后我手上还有9.7.5和9.7.6的安装文件。那我现在想把当前的实例升级到9.7.6，我可以进入9.7.6的安装文件里，找到installFixPack这个可执行程序，然后运行它，它会让你指定你想升级的实例所属的副本的安装路径，指定后就可以打补丁了。如果要从高补丁降到低补丁，即9.7.6→9.7.5，则需要到9.7.5的安装文件里面，运行installFixPack -f level，然后也会让你指定你要降的那个实例所属的副本的目录，执行完后可以看到那个副本的实例等级都下降了，方法2的升级和降级作用的是实例所属的副本，相当于那新版本的东西覆盖老版本的东西，升级或降级后，这个副本下的所有实例都会受到影响，而且以后新创建的实例等级也会受到影响。方法2相对于方法1，由于有文件的覆盖，并且作用范围较大，可能会有潜在的危险，所以建议使用方法1.

 

再往细里说一点，其实每个实例的版本都是基于创建这个实例的副本，可以进到实例目录下去看一下，可执行命令和很多信息都是连接文件，连接到创建它的副本中的可执行命令。给实例升级，其实就是修改实例目录下这些文件连接到的目的地，从9.5升级到9.7，其实就是把实例目录下的这些跟版本相关的连接文件重新指向9.7的副本，升级前后通过db2level可以看到其实在升级的过程中，实例所属的副本已经改变了。但用installFixPack就不一样了，它直接改变的是副本里的内容。