Seguramente esto debería ser lo mismo que una terminación de una sesión y causar una reversión? Me parece que es lo más imposible para Oracle. De hecho, me quedé sorprendido cuando descubrí que lo hizo¿Por qué SQL * Plus se compromete al salir?
Lo que es más importante, ¿alguien se opondría si Oracle lo cambiara a reversión al salir?
Curiosamente, con el lanzamiento 11gR2 de esta semana (2009-09-03), SQL * Plus ahora tiene la opción de COMPROMETER o ROLLBACK en EXIT. Doc here
supongo que en las próximas semanas/meses, no será un cliente instantáneo 11gR2 que se puede utilizar en contra de su base de datos actual y obtener el comportamiento deseado
Una precaución a tener en cuenta. Si DISCONNECT or CONNECT a una sesión diferente, todavía se comprometerá implícitamente la transacción (de acuerdo con el documento) pero desde 11R2 puede establecer el comportamiento predeterminado.
Me gustaría ver ese enlace si me lo permite :) –
Proporcionado El enlace no funciona – Arun
¡Tendría que preguntarle a Oracle!
Debo admitir que me sorprendió la primera vez que descubrí esto, ya que pensaría que tomaría el enfoque más conservador que sería hacer un ROLLBACK.
Solo puedo adivinar que COMMIT se considera la acción más probable/predeterminada y quizás es por eso que SQL * Plus lo hace?
Pero seguramente ROLLBACK es lo más seguro. * Todo * else en Oracle parece estar configurado para proteger los datos –
Estoy de acuerdo, ¡creo que el comportamiento SQL * Plus también es extraño! – cagcowboy
Fue una decisión de diseño de Oracle, probablemente hecha hace más de 20 años. No es el diseño que hubiera usado. Tenga en cuenta que parece ser una propiedad de SQL * Plus, no del OCI subyacente.
Si la sesión finaliza abruptamente, AFAIK, la sesión se revierte, como era de esperar. Entonces, por ejemplo, si alguien envía un SIGKILL a SQL Plus, la transacción de la sesión debe revertirse. Pero si la sesión SQL Plus finaliza correctamente (EOF o exit command), SQL * Plus en su sabiduría infinita decide cometer lo que haya hecho hasta ahora.
En cuanto a por qué - Tengo una teoría. En las bases de datos SQL estándar, siempre está en una transacción, incluso si la única operación que ha realizado es una instrucción SELECT. Si no se compromete, se revierten los cambios que realice. Es fácil olvidarse de agregar compromiso al final de las operaciones con guiones, por lo que convertirlo en el comportamiento predeterminado redujo el número de veces que alguien ejecutó una secuencia de comandos para cambiar la base de datos y luego ejecutó una segunda secuencia de comandos para ver si los cambios surtieron efecto. Otros DBMS obvian la necesidad de esto con modos como 'autocompromiso', donde cada declaración es una transacción independiente, confirmada automáticamente al finalizar. Ese es un modo de operación útil. Otros sistemas proporcionan un modo en el que está en autocompromiso hasta que ejecuta una instrucción BEGIN WORK explícita, con lo cual (por supuesto), se encuentra en una transacción hasta el COMPROMISO o ROLLBACK correspondiente. Las bases de datos 'MODE ANSI' me han sorprendido al no comprometerse lo suficiente para asegurarme de que me comprometa cuando sea importante, pero el software que utilizo (no Oracle) todavía revierte el trabajo no comprometido en lugar de comprometerlo en silencio, y yo lo haría ser infeliz si fue cambiado para funcionar de otra manera. (Supongo que un valor predeterminado configurable podría estar bien, todavía creo que la reversión no comprometida es la mejor opción predeterminada, ya que es una molestia para el desconocedor, hay menos peligro de corromper accidentalmente una base de datos, y eso es de suma importancia para mí).
(Debido aviso: Esta es información de segunda mano de alguien que trabaja para otro proveedor de DBMS es, sin embargo, precisa en lo que sé, y en base a la información acumulada a lo largo de un período de más de una década. . y después de preguntar preguntas relacionadas en diversos foros)
Gracias por el comentario Jonathan - Estoy esperando a ver si alguien piensa que el compromiso es realmente una buena idea. –
Creo que la cometen es una buena idea y estoy de acuerdo con lo que Justin y Billy escribió en este tema: http://forums.oracle.com/forums/thread.jspa?messageID=3611345�
Saludos, Rob.
No estoy en desacuerdo con Justin y Billy en el hilo, sin embargo, eso no hace que el compromiso sea una buena idea. Commit on exit parece sugerir que se espera que el comportamiento no comprometa explícitamente su trabajo antes de salir de SQL * Plus, como si eso fuera algo bueno. –
Cada script debe manejar transacciones explícitamente, sin depender del comportamiento predeterminado de algunos clientes. Es por eso que creo que este comportamiento realmente no es tan importante. Y para los casos en que se deja una transacción abierta, la aplicación tiene que elegir entre confirmar, revertir o preguntar. Elegir comprometerme parece una opción lógica para mí, aunque los otros dos estarían bien también. La mayoría de las veces no se emite DML para que se revierte, por eso creo que comprometer es una buena idea. Pero como ya se dijo: no hagas que tus guiones dependan de eso en primer lugar. –
Buena pregunta.
He echado un vistazo a metalink y se ha producido un error (o solicitud de cambio) en relación con el comportamiento predeterminado de cometer una salida normal en 1998. Si tiene acceso a metalink, busque el error 633247.
Debería arreglarse cualquier día, entonces ... – cagcowboy
En realidad la semana pasada :) Está en la nueva versión 11gr2 –
Consistente con la forma en que una conexión jdbc que utiliza un controlador Oracle implícitamente confirma el txn al cerrar la conexión.
Parece que no pude encontrar donde esto está documentado No es que dude, pero ¿puedes citar tu fuente? – corsiKa
ojdbc14.jar cuando se llama a la limpieza de OracleManagedConnection, comprueba si hay una transacción válida actualmente en curso. En la situación en que una transacción está en progreso arroja una IllegalStateException. – Chad
Commitir al salir parece lo lógico para mí, generalmente ROLLBACK es la excepción, retrocedemos cuando algo sale mal, cuando insertas, actualizas o eliminas datos, entonces tienes la intención de hacerlo, es decir, COMMIT.
En cuanto al cambio, es probable que haya miles de secuencias de comandos que se romperían si se cambiara el comportamiento predeterminado. Si fuera una opción configurable (de alguna manera), tal vez estaría bien cambiar el valor predeterminado, pero no de lo contrario. Así es la vida con el software que se ha distribuido por más de 1 minuto, no se pueden cambiar las decisiones fácilmente. –
Creo que se puede cambiar fácilmente. Me he encontrado con problemas con SQL * Plus no autocommitting y eso realmente confunde a las personas, o tal vez fue porque aún no se había comprometido ya que la aplicación todavía estaba abierta. – wowest
Está disponible como una opción en el nuevo 11gR2 SQL * Plus –