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

杨廷琨（网名 Yangtingkun）

云和恩墨 CTO，Oracle ACE Director，ACOUG 核心专家

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

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

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

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

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

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

这个结果是不是很2 ？

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

可能有些人认为这个 bug 对于系统的影响不大，而如果在数据库中运行 .sql 文件，或者通过 shell 调用 sql 脚本，那么这个问题出现的可能性就大大增加了。

考虑一下极端的情况，这个问题可能带来哪些危害。最明显的莫过于使得上一个运行的 SQL 重复执行。

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

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

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

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

重复 DDL 的一个例子：

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

上面几个例子都比较极端，但是这是为了说明对于 SHELL 或 SQL 文件中这种自动运行的脚本，要小心这个 bug 带来的不可预料的错误。

好在这个问题只是发生在 sqlplus 中，且 SQL 语句开头是以/*方式的注释开头，注释与后面的内容之间没有空格的情况下，因此想要碰到这个错误也并不容易。可是不要忘记墨菲定律，可能发生故障的地方，终究会有人掉进坑里。