标签归档：ORA-29701 raised in ASM I/O path

前不久，我同事修改standbalone的主机名，只是单纯的从主机层面修改了，has等并没有做调整，虽然数据库奇迹般的open了（有些时候，数据库在此情况下是不能open的，直接就会报错），但是数据库更改主机名以后，ASM和数据库的alert都有报错，而且分析后，觉得这个报错不解决，会在后期使用中造成数据库crash。 修复这个问题的程很简单，有几点说明： 1，8i和8i以前叫做OPS，Oracle Parallel Server，9.0.1~11.1之间叫做RAC（Real Application Cluster），11.2以后叫做GI（Grid Infrastructure） 2，Standbalone结构就是单实例数据库使用ASM的场景，他只需要db和asm通信的cssd等结构，不需要crs。 3，启动，关闭和管理has流程类似rac，但是千万别混淆，Standbalone的叫做crsctl start/stop has，RAC的叫做crsctl start/stop crs(整套架构中所有进程由ohasd创建)，如果弄错了，会出现一些异常情况，在其他案例中，我们遇到过直接ASM报错的，后续在总结了那个案例分享出来。 4，不管是Standbalone还是RAC，修改主机名和IP等都需要特别小心，因为他们不像单机数据库一样，单纯的主机层面就该就可以，他们需要分别在has和crs中进行重配或者修改。 5，无论发生了什么，只要没有动ASM和DB，那么不用担心丢数据。因为has或者crs的结构都跟db是独立的，一般不会丢数据，最差的结果，重装一下，也可以把asm和db拉起来。 6，很多时候，在做类似该ip或者主机名，或者升级crs或者has的版本，或者升级数据库软件时，都建议对现有环境进行备份，要么借助NBU之类的工具，要么使用tar命令。千万别用ftp或者直接copy，这类的否不靠谱，不能用于文件恢复。 具体过程如下： ASM ALERT: 数据库的日志，DB ALERT: CRS和ohasd也有明显报错： 我猜测，此时如果做类似增加/删除文件数据库都会crash，果然，我让同事做rman备份，数据库就crash了。 处理的方法很简单，就是修改has的相关配置，讲新主机名配置进去。具体步骤如下： 首先记录当前的系统关键信息，因为修改完has后，需要将asm，db，diskgroup等关键信息重新注册到has中： 这里还发现了一个问题，这个库的ASM的在has中的信息和实际使用的spfile不一致 在所有的磁盘组中，我们发现实际上是找不到在has中注册的ASM实例使用的spfile的： 使用kfod检查会发现，大量磁盘的报错： 接下来，我就开始重建has了，首先是使用force都无法停止has，因为已经异常了，这个在意料之中的，没关系： 这些进程已经停不掉了，于是只能重启主机（kill ocssd.bin 一样会导致主机重启，因此直接手工reboot了）。 起来后，先删除现有的has配置： 然后执行重新配置： 这过程很快，比GI快多了，HAS还是结构简单啊，O(∩_∩)O哈哈~。 配置完成后，检查一下，服务都正常，只是需要将下面的服务改为自动启动： 使用NETCA重建监听: 添加asm： 在has中添加db： … 继续阅读 →