按照上面的解决方法，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，细致、小心，缺一不可。
全文完。
阅读(2059) | 评论(0) | 转发(0) |
