问为什么SQL*Plus在退出时提交？

EN

有趣的是，随着本周11gR2的发布(2009-09-03)，SQL*Plus现在可以选择在退出时提交或回滚。文档here

我猜在接下来的几周/几个月里，将会有一个11gR2即时客户端，你可以在你当前的数据库上使用它来获得你想要的行为

需要注意的是。如果您使用DISCONNECT or CONNECT连接到不同的会话，它仍然会隐式地提交事务(根据文档)。

这是甲骨文的设计决定，可能是在20多年前做出的。这不是我会使用的设计。请注意，它似乎是SQL*Plus的属性，而不是底层OCI的属性。

如果会话突然终止，AFAIK，会话将回滚，正如您所预期的那样。因此，例如，如果有人向SQL_Plus发送SIGKILL，则会话的事务应该回滚。但是，如果SQL_Plus会话优雅地终止(EOF或exit命令)，那么SQL_Plus就会以其无限的智慧决定提交您到目前为止所做的任何事情。

至于为什么-我有个理论。在SQL标准数据库中，即使您执行的唯一操作是SELECT语句，您也始终处于事务中。如果您不提交，那么您所做的任何更改都将被回滚。很容易忘记将commit添加到脚本操作的末尾，因此将其设置为默认行为可以减少运行脚本以更改数据库的次数，然后运行第二个脚本以查看更改是否正确生效。其他DBMS则通过“自动提交”等模式消除了这方面的需求，在这种模式下，每个语句都是一个独立的事务，在完成时自动提交。这是一种有用的操作模式。其他系统提供了一种模式，在这种模式下，您处于自动提交状态，直到您运行显式的BEGIN WORK语句，然后(当然)，您处于事务中，直到相应的COMMIT或ROLLBACK。我曾被“模式ANSI”数据库经常提交的问题所困扰，但我使用的软件(不是Oracle)仍然会回滚未提交的工作，而不是默默地为您提交-如果它被更改为其他方式工作，我会很不高兴。(我认为可配置的缺省值可能是可以的；我仍然认为未提交的回滚是更好的缺省值，因为它对不知情的人来说是一种麻烦；意外损坏数据库的风险较小，这对我来说是最重要的。)

(注意:这是为其他DBMS供应商工作的人提供的二手信息。然而，据我所知，这是准确的，是基于十多年来积累的信息，以及在各种论坛上提出相关问题之后。)

你得去问甲骨文！

我必须承认，当我第一次发现这一点时，我很惊讶，因为你可能认为它会采用更保守的方法，即进行回滚。

我只能猜测，COMMIT被认为是最有可能的/默认操作，也许这就是SQL*Plus这样做的原因？