运维教程-防不胜防:一个空格在数据库里可能引发的N重血案

跨零代码为大家提供高品质的解决方案,请大家多多来访,跨零不胜感激,在此谢过。

作者:杨廷琨(网名 Yangtingkun);云和恩墨 CTO,Oracle ACE Director,ACOUG 核心专家。

编辑手记:Oracle DBA的职业生涯中,无数看似简单的一个疏忽就能够导致致命的故障和数据损失,一个空格看似很小,可是如果在脚本运行环境中,就绝对不容轻视。

你可能还记得我们分享过的一个真实案例:一个空格引发的血案。

今天我们来看另外一个和空格有关的案例,基于11.2.0.3版本的测试:

防不胜防:一个空格在数据库里可能引发的N重血案

这是一个 11.2.0.3 的 sqlplus 客户端,那么以下这个简单的查询结果是什么?

防不胜防:一个空格在数据库里可能引发的N重血案

好,我承认是在故弄玄虚,结果就是简单到不能再简单的1,那么问题来了,上面第二个查询的结果是什么?

防不胜防:一个空格在数据库里可能引发的N重血案

不要扔砖,虽然结果还是意料之内的,但是见证奇迹的时刻马上就要到了,这第三个查询的结果是什么?

防不胜防:一个空格在数据库里可能引发的N重血案

这个结果是不是很2 ?

这个语句和上面第二个语句只是相差了一个空格,结果是完全不同的。对于第二个语句而言,注释并没有对语句产生任何的影响;而对于第三个语句,实际上 Oracle 并没有把这个语句作为包含注释的语句看待,实际上 sqlplus 运行的是/,也就是将缓存中的语句再运行一次,而完全忽略了/之后的内容。

可能有些人认为这个 bug 对于系统的影响不大,而如果在数据库中运行 .sql 文件,或者通过 shell 调用 sql 脚本,那么这个问题出现的可能性就大大增加了。
考虑一下极端的情况,这个问题可能带来哪些危害。最明显的莫过于使得上一个运行的 SQL 重复执行。

防不胜防:一个空格在数据库里可能引发的N重血案

如果上一条是 SELECT,则显然对系统影响最小(事实上这个影响也不小,因为当前需要执行的 SQL 被跳过了,这可能影响这个 SQL 脚本的逻辑),而如果是 DELETE 语句,如上所示,那么表中数据就会被多删除一次。

也许有人会说,删除也无所谓,可以进行回滚,并没有数据的损失。事实上,对于 SHELL 脚本方式或者编写好的 SQL 脚本而言,是没有办法对其进行控制的。

即使不在脚本中运行,有些情况下也是没有机会回滚的,比如:

防不胜防:一个空格在数据库里可能引发的N重血案

这种想要恢复就只能通过闪回了。而如果重复执行的是 DDL,那么连闪回的机会都没有了。

重复 DDL 的一个例子:

防不胜防:一个空格在数据库里可能引发的N重血案

虽然并不会真正造成什么数据的损失,但是数据的加载以及分区 EXCHANGE 的工作就完全白做了。

上面几个例子都比较极端,但是这是为了说明对于 SHELL 或 SQL 文件中这种自动运行的脚本,要小心这个 bug 带来的不可预料的错误。
好在这个问题只是发生在 sqlplus 中,且 SQL 语句开头是以/*方式的注释开头,注释与后面的内容之间没有空格的情况下,因此想要碰到这个错误也并不容易。可是不要忘记墨菲定律,可能发生故障的地方,终究会有人掉进坑里。

从零到一,创造未来!跨零综合IT问题解决服务站,欢迎你的到来。运维教程 只为你绽放。

本文固定链接: http://kua0.com/2018/12/31/运维教程-防不胜防:一个空格在数据库里可能引发/

为您推荐

发表评论

电子邮件地址不会被公开。 必填项已用*标注