从业DBA相关工作已有10多年了，有个案例一直让我记忆犹新，难以忘怀，该案例不仅涉及到技术问题，而且涉及管理以及公司与员工的关系。 2011-2012年的时候，移动互联网还没有兴起，还没有出现微信等移动即时通信工具，当时办公主要使用腾讯QQ 进行工作交流，而移动营销手段主要通过手机短信，当时短信群发业务非常的火爆，短信群发应用广泛的行业有房地产、金融、商业促销，当时房地产业正当头，房价刚刚开始飙升，房地产短信群发推广非常重要，业务量十分庞大，往往一个房地产楼盘一次短信群发促销就发几十万条起步，而且主要集中在周末的时候群发。
在这里顺便说一下当时短信的发送模式，首先给客户开通短信发送账号，然后客户下载我们短信发送客户端软件（彩翼），输入账号和密码后登录彩翼客户端，接着批量导入手机号码和编辑好群发短信内容，然后彩翼客户端对接短信平台接口程序，接口接收客户端发送过来的短信后再分发到各个短信网关进行发送，网关是对接各大运营商的，有移动、电信和联通，短信最终由运营商发送出去给各个手机号码的。整个业务流程中，数据库存储包括账号、充值扣费、短信内容接收、网关分发等数据。
当时短信客服不仅处理客户日常问题、投诉还包含二次销售，销售人员开发客户为首次销售，而客户遇到问题需要处理或投诉就会联系客服处理，待熟悉后需要再次购买短信或需要充值，就会联系客服，这样就给客服人员创造了销售的机会，所以客服人员既充当客服角色也是二次销售人员。由于业务繁忙，客户刁难，客服姐姐的脾气往往都不好，平时受了客户的气和委屈的时候，会直接发泄到我们技术人员身上，对我们责骂、河东狮吼是很平常的交流模式，当时技术人员的地位低下，任劳任怨，可以被客服、销售随意践踏，唉！说起都是泪……
2012年9月14日的早上到公司，刚好那天是周五，我记得当天因为起床晚了一点，为了赶时间不迟到（迟到一分钟扣款5元），来到公司带了标配的两个鸡蛋、一个叉烧包和一杯豆浆，还未来得及吃早餐，就被好几个客服围困在办公桌的周围，她们非常焦急大声诉说，说短信后台无法登录，客户反应发不了短信，赶紧排查问题。
首先尝试登录短信平台的后台，果然上不了。通过远程连接服务器，发现tomcat应用程序报错，主要是报连接数据库错误，具体错误如下：
09:47:06 [SQLException] getConnection SQLException...数据库链接有误！Cannot create PoolableConnectionFactory (ORA-00257: archiver error. Connect internal only, until freed.
从报错判断，是因为应用程序连接不上数据库引起的。当时系统架构是由tomcat 集群+Oracle 10g RAC的架构来承当短信、彩信平台的群发业务，由于业务量大以及设备资源原因，当时并没有数据库备份。
通过连接数据库其中一个节点，用crs_stat -t -v查询集群实例情况，发现Oracle 10g RAC集群后台进程都显示出来，但是数据库进程ora.orcl.db处于offline状态，查看实例 alert_orcl.log告警日志如下：Fri Sep 14 01:26:09 2012
alter database datafile '+DG1/smsdb/datafile/system2.dbf' offline drop
Fri Sep 14 01:26:09 2012
ORA-1541 signalled during: alter database datafile '+DG1/smsdb/datafile/system2.dbf' offline drop...
Fri Sep 14 01:27:18 2012
alter database datafile '+DG1/smsdb/datafile/undotbs2.264.767471293' offline drop
Fri Sep 14 01:27:20 2012
Completed: alter database datafile '+DG1/smsdb/datafile/undotbs2.264.767471293' offline drop
Fri Sep 14 01:27:23 2012
通过告警日志可以看出，在2012年9月14日凌晨，有人远程连接数据库，进行了drop 数据文件的操作，用 alter database xxx offline drop两个数据文件，一个是系统表空间 system的数据文件system2.dbf，一个是undo表空间的数据文件（undotbs2.264.767471293），其中由于system为系统表空间，offline drop 的时候Oracle进行了自我保护报ORA-1541错误，并没有删除成功，而undo表空间数据库文件是成功删除了，日志输出为：Completed: alter database datafile '+DG1/smsdb/datafile/undotbs2.264.767471293' offline drop。
这分明是有人搞破坏，这个时刻脑海一下子闪过操作人应该是谁了。
在这里说一下插曲，2012年前由于短信群发没有受到管控，短信群发普遍，往往每人每天手机都能收到很多的垃圾信息，主要是房地产、金融推广，商场促销等内容，甚至还有很多诈骗、色情类内容，引起了大家的反感和投诉，从2012年起国家开始了短信群发的整顿，所以业务较往年下滑了一些，不过当时来说还是很不错的，但就是因为这个原因，公司副总就念念不忘了，一个待遇稍高的DBA 同事在毫无过错的前提下被公司副总约谈，约谈的内容是因为他的待遇高，然后公司业务下降，需要进行裁员，其实真实的原因是已经有人可以代替他的职位了，离开他公司业务一样可以正常运行。可是当时公司并没有按照裁员的正常流程走，该辞退就辞退，该赔偿就赔偿。私人无良公司却想辞退员工又不以N+1的补偿作为条件，人力资源经理还自信满满地声称在他手下没有一个员工能拿到被辞退后的补偿的。
最终在各种软硬措施后，那个DBA只能怏怏不快地离开，想当初为了解决短信平台群发性能瓶颈时的绞尽脑汁，为了适应业务初期井喷需求时，熬夜加班进行数据库集群部署和测试的精疲力竭，待业务稳定以及业务稍不如意时，公司就卸磨杀驴，这非常形象地阐释了资本家的丑恶嘴脸，这样为公司卖力被辞退后却未能受到合理的对待，心里肯定充满了各种的不服。
回到当前，这时客服人员在包围并责骂正在排查、解决问题的我，同时也惊动了那个公司副总，我只能在惊恐中尽力平静下来，集中精力处理问题。幸好Oracle数据库有系统表空间被删除数据文件时的保护机制，也感谢破坏者的手下留情，没有删除其他的非系统数据文件，只有一个undo回滚表空间被删除而已，通过recover datafile命令指定已经被offline drop的数据文件后，竟然可以通过归档正常恢复，一场灾难却被我轻易地化解了。
事后我编写事故原因及处理过程说明，并跟那个副总说明情况，故障的原因是人为远程对数据库文件进行破坏，但是破坏不彻底，未达到无法挽救的结果，同时揣测破坏人可能是刚刚离开公司的那个DBA。虽然当时那个DBA离开公司的时候，我们也预先作了一些安全操作，例如修改服务器密码，变更服务器远程端口等，但由于他预留了访问漏洞，可以通过远程操作。经过这个事情后，及时将所有的数据库用户密码都修改了，所有风险都尽可能做了修复。
副总听了我的解释后，他也知道理亏，也认识到不按规则办事的后果，虽然还未能完全确认是那个离职的 DBA做的操作，但是还是担惊受怕的，刚好适逢中秋节，公司在给客户送礼品的同时，也给那位员工邮寄了中秋礼品，以表心意。
公司辞退员工要遵守法律法规，按照正常流程进行，该赔偿就要赔偿，确保员工的权益得到保障，如果没有按照正常流程行使，不仅严重伤害员工，受到员工的报复性行为，可能还会面临法律风险和声誉损失，作为管理者，必须切记！
