IDS9.4到IDS11.5升级过程以及前期需要考虑的问题

平台：SunOS

 

升级的前期准备工作：

1，做好数据库的备份。对要进行升级的数据库实例要进行完全的0级备份，以及确保备份后能够成功恢复！在升级的过程中，如果完成了对数据库的检验而在数据格式的转换过程中出现失败，会导致数据不一致。这种情况下需要从备份进行恢复

2. 操作系统补丁。如果系统比较老，补丁不足，IDS11.5可能无法运行，造成升级失败；

3. 现数据库中表的extent数目，因为升级时数据转换的要求，需要每个表至少可用的extent数目为8.Solaris平台，缺省2k页，一般最大extent数目为230左右，具体数字与表的行宽有关，曾遇到的一个情况，一个超宽的表甚至最大extent数目可能只有150左右。如果数据表升级时占用的extent数目接近表最大extent数目，即>最大extent数目-8，那么数据转换会报告失败。这种情况需要重新安装旧版本的数据库程序文件即可退回旧版本，解决extent数目过大的问题后，再继续升级。

4，对老版本的informix安装目录进行备份。如果在升级过程中IDS11.5已经成功安装（假设是覆盖安装，即安装在老版本的目录），但升级过程中发现第三步的extent检查失败，这时候需要回到旧版本中，解决表的extent问题。因此这里需要从老的安装目录备份文件中还原informix的安装目录。

e.g: tar cvf  informix9.4.tar /opt/informix  (注意：如果这里用root用户tar起来的文件，解包时必须也是root，否则文件权限可能不正确，导致回退失败！)

5，对数据库实例和关键的数据库进行数据的一致性检查：

oncheck -cr   //检验数据库实例的系统保留页

oncheck -ce //检验实例中的extents

oncheck -cc <dbname> //检验数据库的系统目录表

oncheck -cDI <dbname> //检验数据库中数据以及索引的完好性

6，检查操作系统内核参数是否正确

solaris的内核配置文件为/etc/system

eg:

set semsys:seminfo_semmap=64  

       set semsys:seminfo_semmni=4096

       set semsys:seminfo_semmns=4096

       set semsys:seminfo_semmnu=4096

       set semsys:seminfo_semume=64

       set semsys:seminfo_semmsl=500

       set shmsys:shminfo_shmmax=4398046511104

       set shmsys:shminfo_shmmin=100

       set shmsys:shminfo_shmmni=500

       set shmsys:shminfo_shmseg=100

7，对数据备份恢复时间与升级失败所导致的回退时间进行评估，对升级失败要有应急预案。

 

实际升级过程中，问题2是出现比较多。所以建议列出所有数据库中extent数目超过100的表，并对其中接近最大extent数目的表提前进行数据整理或者重建，如果该表可以删除，直接删除表也可以避免升级过程中的数据转换失败的情况。
以下为计算表后续能够增加的extent数目的方法：

 

1.通过oncheck -pt 获取的物理地址 e.g:

 oncheck -pt userdb:user

TBLspace Report for userdb:informix.user

    Physical Address               2:513
    Creation date                  09/27/2010 17:00:02
    TBLspace Flags                 801        Page Locking
                                              TBLspace use 4 bit bit-maps
    Maximum row size               24       
    Number of special columns      0        
    Number of keys                 0        
    Number of extents              1        
    Current serial value           1        
    Current SERIAL8 value          1        
    Current BIGSERIAL value        1        
    Current REFID value            1        
    Pagesize (k)                   2        
    First extent size              8        
    Next extent size               8        
    Number of pages allocated      8        
    Number of pages used           2        
    Number of data pages           1        
    Number of rows                 1        
    Partition partnum              2097214  
    Partition lockid               2097214  

    Extents                      
         Logical Page     Physical Page        Size Physical Pages
                    0            2:1223           8          8

2.转换物理地址为 16 进制数 e.g:

echo "2"|nawk '{printf "%xn",$1}'

2

echo "513"|nawk '{printf "%xn",$1}'

201

3,通过onchek -pP 来获取frcnt.

oncheck -pP 0x2 0x201|more
addr             stamp    chksum nslots flag type         frptr frcnt next     prev
2:513            1546551  9b23   5      802  PARTN        172   1852  0        0  

 

4,计算后续能够增加的extent数目：

freeexts=`expr 1852  / 8`

建议对freeexts小于8的表进行重建。

进行extent数量的检查最好是通过脚本检验，因为如果数据库中表的数量非常多，手工检查的话这个工作量是很大，而且说不好就有漏网之鱼。

 

简单介绍下升级步骤：

1，上传IDS11.5安装介质

 

2，安装IDS11.5。

这一步进行覆盖安装，即安装在IDS9.4的目录，覆盖原版本的安装文件。将安装介质拷贝到$INFORMIXDIR目录，tar开，su到root用户下（利用informix的环境变量），运行：ids_install命令。

 

3，IDS11.5安装好以后，根据IDS9.4的$ONCONFIG配置文件修改新的配置文件。

 

4，启动数据库：oninit -v   并监控message log内容：

tai -f /opt/informix/log/online.log

这一步可能出现的问题：

  （1）如果在日志中发现extent检验没过关，这时候还没有开始数据的转换，则需要从原先的安装目录备份文件进行安装文件的还原（如果当初tar安装目录的时候用的是root用户，解包也要root，确保安装文件的权限正确），如果还存在原来IDS9.4的安装介质也可以，将IDS9.4重装一遍，启动数据库（oninit -v），对日志中所列出的表进行重建，适当增大extent size以及next size。

  （2）如果数据格式的转换已经开始，但在中途由于某些原因而导致转换失败，这是个比较麻烦的事情：首先需要将安装目录文件恢复到IDS9.4，然后从升级前的数据库备份中还原数据库实例。如果数据库数据量很大的话，这个时间可能要好几个小时。恢复完成后对日志进行分析，发现问题的源头后，升级从头开始。

 

对于存在双机的系统，升级前需要检查sqlhosts文件中的hostname列是否修改为浮动ip。

如果用的实际物理ip，升级完成后会出现用程序用实际ip（按理程序中也应为浮动ip）访问数据库出现权限不足的问题。这点非常重要。

 

升级后的验证工作：

1，对所有数据库（包括系统库）做低模式的统计更新: update statistics

2，使用dbaccess等工具进行验证

3，启动应用程序验证

 

数据库版本升级的过程并不复杂，但是在升级过程中所需要考虑的问题比如对升级失败的恢复工作，升级过程对业务的影响等等，却需要有一个很全面的考虑。