修复由于修改主机名造成Standbalone异常（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：

现在再次检查has的配置，都已经好了：

在使用kfod检查asmdisk已经不抱错了：

使用has重新启动，把所有资源和db都带起来：

好了，都ok了。