某数据库系统升级流水账记录

RAC环境迁移升级，9.2.0.8升到11g

 

12月4日下午3点到达客户现场并了解情况

之前只是告知9i的库升级到11g，客户也不清楚具体版本，好像是9206。当时去之前已经想好最恶劣的从用10g软件挂载11gASM磁盘组里的9i数据库进行一次升级，再11g软件进行升级的打算了。到现场后很幸运的发现原来数据库版本是9208！

下午查看后发现存储并没有挂好，同时操作系统为AIX 6L初始版本。11g在该版本上安装会存在bug导致软件装不上，当天下午将AIX升级到6100-07-05-1228，同时rootvg做镜像，及其他操作系统检查工作

 

12月5日上午9点到客户现场，存储未挂，下午4点存储挂好后开始安装数据库GRID和ORACLE软件。此时，由于相关参数的设置问题

no -o udp_sendspace=65536  
no -o udp_recvspace=655360 
no -o tcp_sendspace=65536  
no -o tcp_recvspace=65536  
no -o rfc1323=1            
no -o sb_max=2*655360      
no -r -o ipqmaxlen=512     
修改参数时没有加-p，导致系统重启失效。GRID装好后，CRS正常，重启系统后，始终只能起最先启动的节点CRS。并且报错不明显，crsd.log报crs没有初始化。一开始找不出原因无奈只能重装，重装后仍旧相同的错，等待许久后crsd.log开始报gipchaLowerProcessNode: no valid interfaces found to node，一查发现是相关参数的原因。郁闷的浪费了许多时间。GRID和ORACLE软件装完后，由于客户数据库有5T左右数据，并且是做迁移到新的两台服务器上。好的地方是客户可以根据时间重做迁移时的增量数据。于是准备rman后台备着。当命令运行后给客户评估系统压力，可以忍受。回家睡觉。

 

12月6日上午10点，接负责人电话，系统卡的不行。最后客户重启数据库解决。商量后决定晚上在客户那重做一次RMAN，调整minperm%，maxclient%，maxperm%相关参数，之后系统正常。原因是AIX5L上，对文件系统出现大量IO的时候，就会出现大量的换页，从而导致hdisk0,hdisk1硬盘繁忙度100%，于是便出现之前的现象了。观察到12点打道回府。

 

12月7日上午9点，为了怕系统再出现意外，赶到现场。同时备份做了60%。写速度在80M/s左右，瓶颈在该hdisk12的写上。下午2点备份完成，开始往asm里做restore，总写速度200m/s，瓶颈在hdisk12文件系统磁盘的读上。晚上10点许数据完成，准备开始做升级。

但是此时又遇到一个严重的问题，将生产的归档拷贝过来做完recover，需要resetlogs打开。但是11g的软件又无法open打开9i的库。生产库的文件存放在裸设备上。于是考虑关掉生产库，dd控制文件和redolog传到ASM磁盘里。生产库裸设备带有4k偏移量。dd拷贝后，11gASM磁盘可以直接发起从文件系统拷贝文件到磁盘组里。但是在controlfile上，拷贝时报大小不是db_block_size的整数倍，无法拷贝。于是加上count参数往大的做dd，这次直接报文件不可用。于是无奈了。后来和同事商量了下，发现dd不应该把裸设备的所有内容都拷贝出来。利用oracle提供的dbfsize工具可以查看相关信息。

如：Database file size: 409600 512 byte blocks
则：dd if=.. f=.. bs=512 count=409601 skip=8
dd的小是409600 * 512 + 512
这个问题上耗费了比较长的时候，8号凌晨两点开始将数据库起到open upgrade状态。

刷数据字典等等操作，向crs添加资源。最终升级完成。

但愿应用测试顺利。。。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24005010/viewspace-750773/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24005010/viewspace-750773/