防不胜防：一个空格在数据库里可能引发的N重血案
编辑手记： 在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 语句开头是以/*方式的注释开头，注释与后面的内容之间没有空格的情况下，因此想要碰到这个错误也并不容易。 可是不要忘记墨菲定律，可能发生故障的地方，终究会有人掉进坑里。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
