前言：
上线前检查已经是老生常谈了，通常上线前检查完后，就应该当做生产系统对待，不应该随意修改系统的相关配置，然而， 很多老司机会认为， 自己对系统很有把握，修改一些系统配置，重启系统后没有任何问题，就此认为一切正常；殊不知，很可能一个不经意的操作，给你的系统就已经带来了无法预知的隐患。
发现隐患
客户新搭建了一套11g的RAC+DATAGUARD环境，CRS、数据库已经运行了一段时间了，正准备投产上线，这天正准备帮客户进行最终的上线前检查：
问：数据库的安装配置都是按照咱们的标准规范来的吧；
答：是的，该调的参数都调了；
问：这几天数据库运行都还正常吧？
答：非常正常，到目前为止都非常正常，之前检查过配置了，而且之后重启操作系统，数据库好几次，DATAGUARD都切换过好几次了。
这样看起来应该是没有什么问题的，不过例行的上线前的检查还是必须要做的，杜绝隐患，从上线前开始；
然而，我运行了万能的巡检脚本后，检查发现大量的ASM实例参数配置不正确的情况，其中挑选几个有问题的参数如下：
这样看起来，问题还是比较大的：
比如
SGA参数
，如果设置过小，导致ASM实例出现ORA-4031的错误，那数据库就可能出现宕库的风险了；这里连asm_diskstring的参数都没有配置，它是如何读到磁盘的呢？
不过，从CRS和ASMCMD的命令行看，DISKGROUP都是正常挂载，资源正常的。
除此之外，ASM实例运行正常，数据库实例运行正常；
既然有问题，那么还是需要与客户沟通，说不定是客户修改了参数呢（虽然可能性很小）：
问：配置完之后又修改过ASM实例或者别的参数吗？
答：有修改过，但是肯定没有修改过SGA，proceses这些参数；
问：那具体修改过哪些参数呢？
答：这个并不清楚了，中间修改过好几次，但是现在运行挺正常的，所以也就没人发现这些问题。
这样，我们的上线前检查完成，沟通工作到目前为止也差不多了，问题很明显，一系列的ASM参数不符合我们的规范，问题似乎又很隐蔽---如果不是主动来检查这些参数，数据库正常运行期间，你几乎发现不了这些问题；
还好是在上线前，尽早发现了问题，接下来就需要解决问题了；如果是你，遇到了这样的问题，下一步将会怎么来分析呢？
思考一下，精彩马上呈现......
追根溯源
现在最主要的问题其实非常明显，大量ASM参数配置错误，从经验上看，极有可能是使用了错误spfile或者pfile，于是我们检查ASM实例中的spfile参数
：
果然，没有指定spfile，那看来应该使用的是pfile了，接下来就应该到ASM的alert日志中查找它使用的是哪个pfile了
：
从alert日志中看来，它并没有指定使用哪个参数文件，而是直接使用的默认参数；
而往上翻一翻，发现之前启动时都使用的是spfile；而spfile目前也是存在的，并没有被删除；
这样看起来，问题进了一步，大量参数的错误，其本质上是因为没有使用之前配置正确的spfile，而使用了ASM的默认参数，那么现在我们的问题就变成了为什么没有使用原有的spfile的问题了；
是呀，好好的spfile怎么说不用就不用了呢？它没有找到这个spfile？正常来说ASM又是如何来找到spfile的呢？作为老司机的你，有没有想过这个问题呢？
思考一下，再继续往下.....
原理解释
要想回答刚刚的问题，我们就得先明白一点，正常情况下，CRS或者ASM是如何知道启动时使用哪个spfile的呢？
这里我们就需要多理解一点原理了，我们知道启动asm是需要spfile的，但是asm的spfile是存在磁盘组的，而想读到磁盘组里的文件这个磁盘组肯定要被mount，可是磁盘组mount的前提又是asm必须启动呀。。。这感觉是不是一个死循环。Oracle为了解决这个问题，就用到了gpnp配置文件。Oracle会把一些启动asm需要的信息保存在这个xml文件里，这样在读磁盘组的情况下，就知道了一些启动需要的信息，比如spfile，集群会把ASM 实例的spfile路径记录在gpnp的profile文件里，同时，更新一个节点的gpnp信息会被gpnpd.bin进程自动同步到集群的其它节点；
我们通过gpnptool get的方式读取gpnp profile的内容如下，其中SPFILE的指向确实没有问题，跟之前asm正常启动的时候用的文件一样；
同时，在gpnp的trace文件中确认使用了这个正确的profile:
这样看来，CRS在启动ASM时指定的spfile是没有问题的，接下来就是读取spfile的内容供ASM实例使用了；
gpnp告诉了ASM它应该使用的spfile，可是diskgroup这个时候还是没有挂载啊，ASM启动的时候如何读取里面的内容的呢？是不是读取这部分内容时读到了错误的内容呢？
如果是你，你如何一步步论证上述问呢？不妨停下来，再想想.......
层层深入
首先，我们通过创建pfile来看，我们可以看到，通过命令读取spfile的内容能完全正确的读取出我们预期的内容；
spfile存储的内容是没有问题的，那么是不是CRS来读取的时候读取了错误的位置了呢？
这个时候就需要通过kfed命令来帮忙了：
我们读取各个磁盘的信息，可以知道spfile存放在/dev/raw/raw1的第58个AU，单个AU大小为1M；
接下来我们就可以dd 相关内容：
这样看起来，spfile就在那里，而spfile的内容没有什么问题，只是CRS启动ASM的时候并没有真正的去读取这个spfile的内容。
其实，问题看到这里，一般的老司机会有两种想法：一种是，“这是什么问题呀，怎么都不是我猜想的那些情况呢？”而另一种则是，“嗯，我已经把把可能的问题范围锁定到最小了！”而你，是什么想法呢？........
.........
水落石出
基本配置没有问题，却没有直接读spfile，不可理解，难道是bug？不妨上MOS去搜一搜，发现一篇note如下：
ASM Instance Not USING SPFILE EVEN SPFILE EXISTS IN DISKGROUP，：
从描述上看，与我们的CASE有几分类似，但是又有些不同：
从这个note描述来看，是因为discoverstring设置了多个值，而多个discoverstring能同时发现同一块盘！问题的关键找到了，我们看看我们的参数设置(asm_diskstring)：
没错，asm_diskstring参数包含，/dev/raw/raw*和/dev/raw/*，这两个参数都能同时找到/dev/raw/raw1的这块磁盘，在读到同样的数据后，集群认为这种设置有问题，反而不再去读spfile了，转而使用默认的参数；而正是修改了这个参数后，ASM实例启动就再也没有使用spfile了；
解决问题
确认了疑点后，我们来解决问题就简单多了，实际上我们的spfile仍然存在，只需要修改pfile中的asm_diskstring然后重建spfile即可；在sqlplus命令行中创建了spfile后，gpnp实际上会重置它的配置信息，指向新的spfile位置，而这次，没有了asm_diskstring的错误配置，启动时就能正常读取spfile了。
重启CRS，然后再看相关参数，也就恢复了原样；
总 结
从这个案例中可以看到，一个看似隐藏的错误，很可能给系统带来非常大的隐患。而一次不够严谨的系统修改，都可能会带来无法预知的后果。
整个案例分析的过程中，可以看到中亦工程师秉承着ODM的诊断方法论，一步一步的理清问题，通过扎实的原理知识，找到问题的真正原因，并最后给出了最终的解决方案。
希望这种分析问题的思路和方法论对大家有所启发，并在今后的工作中尝试实践
ODM方法论，
一定会让您的工作效率事半功倍，并体会到分析问题所带来的乐趣。
