有下面一段SQL脚本,朋友们看能不能找出问题所在?

create table t1_bak as select * from t1 order by col_1,col_2;
truncate table t1;
insert /*+ append */ into t1 select * from t1_bak;

先不看这段SQL代码的效率如何,我们来关注一下这段代码存在的严重的安全问题。

这段代码从语法上看完全没有问题,然而....
假如这段代码是用sqlplus来运行,而第1条create table语句由于空间不足,或者由于数据量太大,临时表空间不够,排序出错,那么t1_bak的创建就会失败,而紧接着,t1会被truncate掉,结果可想而知。

这不是我临时想来的问题,而是真真实实发生在现实中的。现实中发生的这件事,比我提到的隐含的问题就明显,就是第1条create table语句,存在语法问题,结果,表被truncate了,数据丢失了。

仔细考虑维护脚本,甚为重要。

Trackback

12 comments untill now

  1. 很经典!

    [回复]

  2. 地雷无处不在阿,防不胜防……

    [回复]

    老熊 回复:

    @wajoynece, 平时的工作中的确有很多地雷。

    [回复]

  3. 所以这种SQL脚本中最好在开头加个:
    whenever sqlerror exit

    [回复]

  4. 受教了~~~

    [回复]

  5. brucewoo @ 2009-08-11 21:22

    很重要的表都是确认备份成功后,才敢执行truncate这种操作的.

    [回复]

  6. 哦也,这种事情我们碰到过。
    前面的insert由于回滚不足,回退了,(大概1亿记录)
    后面直接drop表了,哦也
    据说是很重要的记录
    如果那个表名再少三个字母,那就损失超过千万了,因为已经销售的很多东西必须全部回收。
    所以我们现在规定,不准truncate,不准drop,只能rename
    出现truncate,drop等等操作在脚本中
    直接退回或者拒绝执行。

    [回复]

    老熊 回复:

    @David.Guo, 你们的方法不错,这样最保险。

    [回复]

  7. 受教了

    [回复]

  8. 这种问题咱实际的开发中经常遇到,没有经验的开发工程师,往往只注重功能的实现,根本不考虑维护的问题,一定要提醒和培养

    [回复]

  9. victor1010 @ 2010-03-08 15:51

    老熊,真棒!!

    [回复]

  10. wolforever @ 2011-12-01 16:31

    好问题

    [回复]

Add your comment now