2

我的脚本使用SQL*Plus 错误日志来跟踪安装过程中的错误。脚本像这样开始 - 它们启用错误日志记录并截断任何现有条目：

SQL> set errorlogging on truncate
SQL> select * from table_does_not_exist;
select * from table_does_not_exist
              *
ERROR at line 1:
ORA-00942: table or view does not exist

然后在最后我查询sperrorlog看看出了什么问题：

SQL> select statement from sperrorlog;

STATEMENT
--------------------------------------------------------------------------------
select * from table_does_not_exist

但是时不时地truncate不起作用，并且我从以前的安装中得到错误。为什么不起作用truncate？

4

2 回答 2

2

尽管它的名字，SQL*Plus 错误日志截断实际上并没有截断表。它删除数据并且不提交。

此 SQL*Plus 会话启用错误记录并创建错误。另一个启用错误记录和截断的调用确实会清除数据，但回滚会撤消截断。

SQL> set errorlogging on truncate
SQL> select * from table_does_not_exist;
select * from table_does_not_exist
              *
ERROR at line 1:
ORA-00942: table or view does not exist


SQL> commit;

Commit complete.

SQL> set errorlogging on truncate
SQL> select statement from sperrorlog;

no rows selected

SQL> rollback;

Rollback complete.

SQL> select statement from sperrorlog;

STATEMENT
--------------------------------------------------------------------------------
select * from table_does_not_exist

SQL>

为了安全起见，您应该始终commit在set errorlogging on truncate.

于 2013-06-08T22:16:46.247 回答
0

为了安全起见，您应该始终在设置错误日志后立即发出提交 truncate

或者，执行一个显式 TRUNCATE，它会执行一个隐式提交，即DDL 语句。当然，这就像不使用该truncate选项一样，但是rollback. 我找到了回滚问题的解决方法，并在我的博客SQL*Plus 错误日志记录中分享了它——ROLLBACK 问题的解决方法

回到您的问题，我更信任显式截断：

SQL> set errorlogging on
SQL> select * from table_does_not_exist;
select * from table_does_not_exist
              *
ERROR at line 1:
ORA-00942: table or view does not exist


SQL> select statement from sperrorlog;

STATEMENT
----------------------------------------
select * from table_does_not_exist

SQL> truncate table sperrorlog;

Table truncated.

SQL> select statement from sperrorlog;

no rows selected

SQL> rollback;

Rollback complete.

SQL> select statement from sperrorlog;

no rows selected

SQL>

或者，您可以将全局临时表用于sperrorlogtable 并使其on commit delete rows.

于 2015-04-07T06:20:21.230 回答