公司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！
终于想起来了，201本文来源gao@daima#com搞(%代@#码网3年11月左右一同事添加2TB的DATA4，估计是当时作业没有完成！
ASM Diskgroup添加与删除步骤见博文：http://blog.gaodaima.com/jacson_bai/article/details/17946327
至问题解决，超过了申请停机时间6分钟，属于严重生产事故，被BOSS大骂一顿！
总结一下：
1.任何DB维护需求，需DBA Team协调沟通；
2.在接受本次维护任务时，最好能看一下该DB最近维护记录，小心触发别人的错误，导致自己被K!
转载请注明原文链接：修改参数，触发“血案”
