2015年年终手滑造成的悲剧

2015年年终手滑造成的悲剧

2015年12月28日,我想整个16年,全部门都会记住这个日子.  

我,作为DBA部门一个资格最老的DBA,在5分钟内连续发生了2次误操作,直接导致某个核心DB发生7分钟无法正常提供服务的事故.

就让这个事情作为我的博客开端,时刻警醒我,也希望能提醒到大家,千万千万小心.

下面给大家描述一下这次事故:

有个临时任务需要到生产环境的DB上去验证一下数据(这个和本次事务没有关系),我拿到任务后直接远程登录到对应的DB服务器的操作系统中.

在操作时发现系统响应缓慢,于是检查了一下windows的任务管理器,发现操作系统可用内存仅1GB左右.

习惯性的打开实例的属性,发现实例的内存设置中,最大服务器内存设置为默认值: 2147483647MB(大约为2PB)(请注意此处单位,第一个误操作和此有关)

遂设置内存使用最大值为250GB(留6GB内存给操作系统使用),在空格中填入250后点击保存.

瞬间奔溃了好嘛!!!!!!   单位是MB啊!!!!!!

程序员立马电话过来,监控的报警也同时过来了.连接全断!!!(其实还有部分连接活动).

重新设置根本无法打开新窗口,原有窗口连接无法执行SQL.(全是连接中断)

立即重启实例.重启完毕后重新设置最大内存为250000MB.DB服务恢复可用.

影响4分钟.

此时由于实例的重启,导致此服务器上的数据库管理客户端(Sql Server Management Studio)异常,持续弹框告警.

于是进入任务管理器,找到进程ssms.exe,点击结束进程.

咦,为什么跳个弹框提示系统进程?

不管了,赶紧结束掉.于是勾上,点击关闭.

boom~~~~

服务器无响应了.

刚刚那波程序员又电话来了,监控报警疯狂响起...

不幸中的万幸,数据库存在自动故障转移,当这台DB的操作系统异常时就已经触发了故障转移机制,备用服务器已经开始接管相关服务.

3分钟后数据库服务恢复可用.

共计7分钟,第一次误操作和第二次误操作间隔不超过5分钟.

 

来总结一下这次的事情吧.

第一个误操作:

　　其实第一个修改内存设置的工作已经做了不知道多少次了,但是潜意识中就是想着GB的单位,然后再转换成MB的单位,而这次就是漏掉了转换的这步,于是悲剧鸟~~~

第二个误操作:

　　结束进程的时候把smss.exe这个系统进程误认为是ssms.exe这个客户端进程进行了结束.结果导致操作系统崩溃.

 

这完全是人祸啊,年终岁末的搞了个故障,全年的指标都没了.

希望把坏运气和失误留在2015年.

祝大家新年快乐~~