按照上面的解决方法,CRS可以顺利安装,数据库也成功建立。问题是解决了,下面要来分析一下问题出在什么地方。经过检查,发现所有建立的裸设备都有坏块的现象发生,而裸设备都存在于共享卷组中,这说明在建立共享卷组的时候有问题。
于是就要开始回忆建立共享卷组的过程了。为了图省事,在重新安装操作系统之前,对之前建立的卷组信息做了备份(以.map文件形式存在,并ftp到其他分区上),也就是做了vgexport的操作。待操作系统安装完成之后,重新ftp回来之前备份的.map文件,并做了vgimport操作,对除vg00之外的卷组进行了还原。这样操作有一个问题,通过strings /etc/lvmtab这个命令可以发现出来,那就是重装操作系统之后,存储上的盘的标识符发生了变化(硬件路径并没有改变),比如说一块盘在重装操作系统之前是/dev/dsk/c6t1d0,重装之后变成了/dev/dsk/c8t1d0,这样就比较混乱了。
因此,为了存储上的磁盘能够正确使用,我放弃了这种简便的方法,决定重新建立共享卷组,并vgexport、vgimport到副节点。按理说方法是正确的,因为一切都是采用全新的步骤,没有图简便,这样不容易出错。但是后来还是发生了这样的故障,归根结底是忽略了一个重要的步骤,那就是没有对之前存储上的盘做“pvcreate”操作,致使之前共享盘上残存的信息保存了下来,并进入到新建的卷组中,这样一来,划分裸设备的时候,难免存在坏块的情况。这样一来,错误原因就比较明显了,所以在项目实施过程中务必小心谨慎,否则就会马失前蹄,功亏一篑。
故障解决和故障分析过程都结束了,下面要总结几个注意事项:
1,当数据库发生问题的时候,眼光要放开,不能只从数据库着手去寻找问题。类似于RAC这样的环境,出现故障之后,数据库、系统、存储、网络很有可能都是故障发生点,所以要全面看问题,不能过于片面;
2,新建卷组时,记得对添加到卷组中的磁盘提前进行格式化,也就是pvcreate操作;
3,裸设备ocr和vote磁盘对CRS有很重要的作用,前者是用来保存cluster信息和配置信息,后者用来监听节点间的通讯是否顺畅,缺一不可。CRS的安装抑或是CRS的进程出了问题,ocr和vote应当是重点关注对象;
4,建立共享卷组之前,一开始就要把需要建立的裸设备规划好(数据库全部使用裸设备),比如说数据文件、日志文件、控制文件、spfile文件等,因为要安装CRS,还要提前建立ocr和vote裸设备,尽量不要有所遗漏,否则到建库的时候发现缺少文件,那就比较麻烦了。通常到了这样的情况下,需要退出图形界面,停下各节点的CRS进程,停掉双机,把除主节点之外所有备节点上的共享卷组信息export掉,然后在主节点上添加遗漏的设备文件,然后对备节点做vgimport导入操作、启动双机、启动CRS等。
5,细致、小心,缺一不可。
全文完。
阅读(2068) | 评论(0) | 转发(0) |