ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 某数据库系统升级流水账记录

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

原创 Linux操作系统 作者:大米嗵嗵 时间:2012-12-08 07:11:42 0 删除 编辑

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/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2010-07-31

  • 博文量
    75
  • 访问量
    134957