意外发现一个sqlplus上一个注释相关的bug。
看一个简单的例子：
solaris*orcl-/home/oracle$ sqlplus test/test
SQL*Plus: Release 11.2.0.3.0 Production ON Mon Jun 11 17:09:57 2012
Copyright (c) 1982, 2011, Oracle. ALL rights reserved.
Connected TO:
Oracle DATABASE 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
WITH the Partitioning, Oracle Label Security AND REAL Application Testing options
SQL> SET pages 100 LINES 140
SQL> SELECT 1 FROM dual; |
solaris*orcl-/home/oracle$ sqlplus test/test
SQL*Plus: Release 11.2.0.3.0 Production on Mon Jun 11 17:09:57 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Oracle Label Security and Real Application Testing options
SQL> set pages 100 lines 140
SQL> select 1 from dual;
这是一个最新的11.2.0.3的sqlplus客户端，那么这个简单的查询结果是什么？
SQL> SELECT 1 FROM dual;
1
----------
1
SQL> /* select */ SELECT 2 FROM dual; |
SQL> select 1 from dual;
1
----------
1
SQL> /* select */ select 2 from dual;
好，我承认是在故弄玄虚，结果就是简单到不能再简单的1，那么问题来了，上面第二个查询的结果是什么？
SQL> /* select */ SELECT 2 FROM dual;
2
----------
2
SQL> /*select */ SELECT 3 FROM dual; |
SQL> /* select */ select 2 from dual;
2
----------
2
SQL> /*select */ select 3 from dual;
不要扔砖，虽然结果还是意料之内的，但是见证奇迹的时刻马上就要到了，这第三个查询的结果是什么？
SQL> /*select */ SELECT 3 FROM dual;
2
----------
2 |
SQL> /*select */ select 3 from dual;
2
----------
2
这个结果是不是很2？这个语句和上面第二个语句只是相差了一个空格，结果是完全不同的。对于第二个语句而言，注释并没有对语句产生任何的影响；而对于第三个语句，实际上Oracle并没有把这个语句作为包含注释的语句看待，实际上sqlplus运行的是/，也就是将缓存中的语句再运行一次，而完全忽略了/之后的内容。
可能有些人认为这个bug对于系统的影响不大，而如果在数据库中运行.sql文件，或者通过shell调用sql脚本，那么这个问题出现的可能性就大大增加了。
考虑一下极端的情况，这个问题可能带来哪些危害。最明显的莫过于使得上一个运行的SQL重复执行。
SQL> DELETE t WHERE rownum < 11;
10 ROWS deleted.
SQL> /*select*/ SELECT COUNT(*) FROM t;
10 ROWS deleted. |
SQL> delete t where rownum < 11;
10 rows deleted.
SQL> /*select*/ select count(*) from t;
10 rows deleted.
如果上一条是SELECT，则显然对系统影响最小（事实上这个影响也不小，因为当前需要执行的SQL被跳过了，这可能影响这个SQL脚本的逻辑），而如果是DELETE语句，如上所示，那么表中数据就会被多删除一次。
也许有人会说，删除也无所谓，可以进行回滚，并没有数据的损失。事实上，对于SHELL脚本方式或者编写好的SQL脚本而言，是没有办法对其进行控制的。
即使不在脚本中运行，有些情况下也是没有机会回滚的，比如：
SQL> CREATE PROCEDURE p_sqlplus AS
2 BEGIN
3 DELETE t WHERE rownum < 5;
4 commit;
5 END;
6 /
PROCEDURE created.
SQL> BEGIN p_sqlplus; END;
2 /
PL/SQL PROCEDURE successfully completed.
SQL> /*another execute*/ SELECT COUNT(*) FROM t;
PL/SQL PROCEDURE successfully completed. |
SQL> create procedure p_sqlplus as
2 begin
3 delete t where rownum < 5;
4 commit;
5 end;
6 /
Procedure created.
SQL> begin p_sqlplus; end;
2 /
PL/SQL procedure successfully completed.
SQL> /*another execute*/ select count(*) from t;
PL/SQL procedure successfully completed.
这种想要恢复就只能通过闪回了。而如果重复执行的是DDL，那么连闪回的机会都没有了。
重复DDL的一个例子：
SQL> ALTER TABLE t_part exchange partition p1
2 WITH TABLE t_temp_part
3 UPDATE indexes;
TABLE altered.
SQL> /*count the num*/ SELECT COUNT(*) FROM t_part partition (p1);
TABLE altered.
SQL> DROP TABLE t_temp_part purge;
TABLE dropped. |
SQL> alter table t_part exchange partition p1
2 with table t_temp_part
3 update indexes;
Table altered.
SQL> /*count the num*/ select count(*) from t_part partition (p1);
Table altered.
SQL> drop table t_temp_part purge;
Table dropped.
虽然并不会真正造成什么数据的损失，但是数据的加载以及分区EXCHANGE的工作就完全白做了。
上面几个例子都比较极端，但是这是为了说明对于SHELL或SQL文件中这种自动运行的脚本，要小心这个bug带来的不可预料的错误。
好在这个问题只是发生在sqlplus中，且SQL语句开头是以/*方式的注释开头，注释与后面的内容之间没有空格的情况下，因此想要碰到这个错误也并不容易。
sqlplus注释导致语句重复执行
意外发现一个sqlplus上一个注释相关的bug。
看一个简单的例子：
这是一个最新的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语句开头是以/*方式的注释开头，注释与后面的内容之间没有空格的情况下，因此想要碰到这个错误也并不容易。