回到人间，聊聊数据表误删的防止

经过艰苦的跋涉，前天下午终于走出没有信号、没有人、没有污染的阿布吉山区。走到九龙牧场的山脊的时候，远远可以看见公路和公路上偶尔驶过的汽车时，心情还是有点小激动的。

本次徒步五天四夜，实际上是5天，第一天下午从洗脸盆垭口出发只走了4公里就宿营了，最后一天13公里的下撤也只走了差不多五小时，总体来说还是比较轻松的一次徒步。走阿布吉措之前，我一直认为这是一条两星级左右的入门线路，因此本次除了三个大学生和准大学生小朋友外，都是50多岁到60多岁的老朋友。

没想到走下来，线路难度还是不低的，领队说线路难度在3星到3星半之间，我觉得这个评价还是准确的，有些事情，不亲自去体验一下，光是纸上谈兵，会谬之千里的。十分高兴的是在4417米的金柱垭口上居然能够收到中国移动的信号，正好这个时候收到了儿子被北京化工大学化学与生物工程双学位专业录取的短信，还是很高兴的。

一出山就收到不少消息，其中有一起数据库被误删数据，导致业务中断的案例。这是我在7月份看到的第二个误删数据影响业务的案例了。误删数据现在已经是对系统运行安全较大的威胁了，今天出山后恢复写公众号的第一天，我们就来讨论讨论这个问题吧。

防止误删数据这个永恒的话题我是从20多年前就在关注了，1999年的时候一家银行找到我们，让我们帮助写了一个C/S架构的小工具，所有的数据库维护操作都必须通过这个工具连到数据库上去做，并且内置了危险SQL的执行确认告警，以及删除数据操作的审批等流程。工具很简单，1个POWERBUILDER工程师花了不到一个月就完成了。这个工具一套卖几十万，居然也卖出去好几套。

从防止误操作的角度去看，可以从制度上去约束，制定严格的检修流程，不过这种制度化的手段往往百密一疏，一次疏漏足以酿成大错。因此纯粹依靠制度是不行的。必须通过一些技术手段来防范。

技术手段分为外部防护和内部防护两种。外部防护可以通过数据库防火墙和类似我们二十多年前做的数据库运维工具等方式来加强管理。对于误操作能够自动提醒甚至自动阻断。对于核心业务数据的查询和修改操作可以通过双岗确认甚至上级审批才能执行（很多行业实际上对于重要变更操作都有这个要求，只是通过制度无法确保效果）。

仅仅采用外部防护还不够完整。因为总会有高权限的DBA能够绕过一切外部防护，直接到数据库服务器上用最高权限的账号去操作数据库。因此还需要有一些内在防护的手段。20多年前，我们就帮很多客户利用Oracle系统级触发器构建了一些数据库防误删表的防护加固系统，实际使用效果还是很好的。

文章的最后，我介绍一下在Oracle上实现数据保护的一个简单的例子，在支持系统级触发器的数据库上，都可以采用类似的方法来实现。二十多年前，我们帮助不少客户实施过类似的数据库关键数据加固保护，也利用这种小技巧赚了不少钱。

create table base$del_check(
tab_owner vachar2(100),
tab_name varchar2(100),
 state         number(10)
 );

首先定义一张基础表，用于需要保护的表的信息。这里我们创建了一张base$del_check的表。然后用下面的系统级触发器来保护。我稍微做了简化，没有带上Owner等信息。

CREATE OR REPLACE TRIGGER del_check
BEFORE DROP or truncate ON DATABASE
declare
vs_tab        varchar2(100);
cursor cur_tab is
select LOWER(tab_name) from base$del_check
where stat=1;
BEGIN
   open cur_tab;
   loop
   fetch cur_tab into vs_tab;
           if cur_tab%notfound then
                   exit;
           end if;
   IF LOWER (ora_dict_obj_name ()) = vs_tab
   THEN
      raise_application_error (num => -20000,
                               msg => '你傻啊，这张表都敢删！！！！');
   END IF;
end loop;
close cur_tab;
END;

上述工作做完后，只要是base$del_check中state为1的表，你要去做DROP/TRUNCATE等危险操作的时候，就可以直接被系统禁止了。大家有兴趣的话可以继续优化这个脚本，并用于生产环境。