修改参数，触发“血案”

公司2010年架设的一套10 G rac，安装当时的规划db_files设置了200，近期由于生产旺季，数据文件增大，需要将这个参数调整为1000， 接受这个case时觉得没什么难的，随即申请停机时间15分钟； 到了停机时间，登录RAC的Node2执行 SQL alter system set db_files

公司2010年架设的一套10 G rac，安装当时的规划db_files设置了200，近期由于生产旺季，数据文件增大，需要将这个参数调整为1000，

接受这个case时觉得没什么难的，随即申请停机时间15分钟；

到了停机时间，登录RAC的Node2执行

SQL> alter system set db_files=1000 scope=spfile;

随后正常关闭RAC

执行开启RAC过程，ASM,nodeapps开启后，在执行开始实例时，抛出一个CRS的错误，随后查看alter.log日志，发现DATA4没有mount，好奇怪哦

生产还等着呢，距停机时间还有8分钟呢，排错吧

方法1：

先将Node1的DATA4手动mount起来，Node1正常启用，然后再mount Node2上DATA4

这时由于大量生产客户端已经和在Node1产生连接，导致了Node2无法mount;

方法2：

依次关闭Nodeapps,ASM,根据alter.log提示，检查asm实例的pfile，问题出现了，DATA4没有被写入到文件，随后在2个节点都加入DATA4，启动OK！

终于想起来了，2013年11月左右一同事添加2TB的DATA4，估计是当时作业没有完成！

ASM Diskgroup添加与删除步骤见博文：http://blog.csdn.net/jacson_bai/article/details/17946327

至问题解决，超过了申请停机时间6分钟，属于严重生产事故，被BOSS大骂一顿！

总结一下：

1.任何DB维护需求，需DBA Team协调沟通；

2.在接受本次维护任务时，最好能看一下该DB最近维护记录，小心触发别人的错误，导致自己被K!