某公司的Linux数据库双机热备故障，系统和数据库服务商争执中

某公司的主业务数据库采用的是两台红帽5服务器+1个存储磁盘阵列做成的双机热备。两台机器上均安装Oracle10.2数据库。库本身建在磁盘阵列上。一旦某个机器出现故障，就切换到另外一台。使用的是红帽的RHCS方案。
前段时间因为数据库速度有些慢，希望通过调整参数提高性能。数据库服务商认为可以将SGA_TARGT_MAX从原来的8G提高到10G，以提供更多的内存来缓解压力。因为来公司调整的时候数据库处于非空闲时间，所以只是修改了参数，准备周一早上重启。但是周一早上的启动发生了问题，数据库无法按照新修改的参数启动。通过1个多小时的折腾，数据库自己做了切换，在后备服务器上自己启动了，还好没耽误周一的业务。为此，周一晚上22点，服务商专门派人深夜进行调试。首先修改了Linux内存参数，以提高可用内存上限。然后将服务器的Oracle SGA_TARGT_MAX参数调整到10G。因为在后备服务器上运行很好，就没有切换回原来的服务器。
本以为事情到此结束。但是运行数天后，Oracle数据库突然DOWN机。Oracle数据库吃掉了所有的内存和CPU时间，而且无法切换。最后不得不冷加电重启。为此认为新的数据库参数存在问题，准备将数据库调整回原来的参数环境，包括服务器也改回原来的生产服务器。晚上进行调整，数据库参数成功返回原来的老参数。但是却发现服务器仍然无法切换回原来的生产服务器，只能使用后备服务器。在clustat命令中，始终显示后备服务器“started"（好像是这个，有点记不清楚了）。即使reboot了后备服务器，也无法切换回生产服务器。生产服务器df命令就是看不到数据库的那个磁盘阵列。但是fdisk -l可以看到。
第二天开始联系当初负责安装服务器集群的服务商，结果当时的施工人员还跳槽了，现在人在外省市。最后好歹对方派了个当初施工人员的小弟，由施工的那位友情远程指挥进行排查。得出的结论是因为生产服务器的Oracle数据库参数并没有完全还原，仍然有不正确参数，造成数据库无法启动。所以无法切换到生产服务器。
对此，数据库支持认为正好相反。是因为服务器的集群切换软件不能切换到生产服务器，挂不上磁盘阵列。所以生产服务器无法启动Oracle。双方都认为是对方的责任，目前仍然扯皮中。还好后备服务器目前工作还算正常，不然整个业务系统就杯具了，损失会非常严重。
希望大家在选择外包服务器和数据库维护的时候，一定要确认服务商的技术水平和人员稳定性。不然一旦出现问题，很可能就是这样，没有获得性能，倒惹了一大堆麻烦。早知道还不如不调整呢。
同时也希望和熟悉红帽集群和Oracle数据库的朋友一起讨论一下，到底哪家的说法是正确的。如果我们自己在日常配置服务器的时候，应该注意哪些问题呢？
我从该事件得到的就是。第一，对于自己不熟悉的机器一定要慎重，修改参数前一定要搞清楚原来的参数环境，做好备份。第二，一定要确认修改成功才能离开。第三，外包要找有足够水平的供应商，红帽+Oracle数据库是很常见的配置，居然也改出问题来，目前仍然无法确定切换的真正问题所在。

推荐链接
20-30万急聘多名天才Java/MTA软件工程师

见证又一个准百万富翁的诞生！
3G培训就业月薪平均7K+，不3K就业不花一分钱！