八
05
有下面一段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了,数据丢失了。
仔细考虑维护脚本,甚为重要。
很经典!
[回复]
地雷无处不在阿,防不胜防……
[回复]
老熊 回复:
8月 6th, 2009 at 10:49 上午
@wajoynece, 平时的工作中的确有很多地雷。
[回复]
所以这种SQL脚本中最好在开头加个:
whenever sqlerror exit
[回复]
受教了~~~
[回复]
很重要的表都是确认备份成功后,才敢执行truncate这种操作的.
[回复]
哦也,这种事情我们碰到过。
前面的insert由于回滚不足,回退了,(大概1亿记录)
后面直接drop表了,哦也
据说是很重要的记录
如果那个表名再少三个字母,那就损失超过千万了,因为已经销售的很多东西必须全部回收。
所以我们现在规定,不准truncate,不准drop,只能rename
出现truncate,drop等等操作在脚本中
直接退回或者拒绝执行。
[回复]
老熊 回复:
8月 14th, 2009 at 12:16 下午
@David.Guo, 你们的方法不错,这样最保险。
[回复]
受教了
[回复]
这种问题咱实际的开发中经常遇到,没有经验的开发工程师,往往只注重功能的实现,根本不考虑维护的问题,一定要提醒和培养
[回复]
老熊,真棒!!
[回复]
好问题
[回复]