10.1. TRANSACCIONES DE BASES DE DATOS

TRANSACCIONES EN BASES DE DATOS

Los comandos DML cambian datos en tablas. También va a cambiar datos en los índices, pero esto es automático y sucederá sin conocimiento del programador. El paradigma de base de datos relacional define la manera en que una o más declaraciones DML deben ser agrupadas en transacciones. Este no es el lugar para entrar en detalles sobre el paradigma de base de datos relacional. Existes números textos académicos sobre esto.  Pero una rápida revisión de la teoría de la transacción es necesaria antes de mirar la forma en que Oracle ha implementado la gestión de transacciones y DML.

El mecanismo de Oracle para asegurar la integridad de transacciones es la combinación de Segmentos Undo y los Redo Log Files: este mecanismo es sin duda el mejor de cualquier base de datos y se ajusta perfectamente con los estándares internaciones para procesamiento de datos. Otros proveedores de bases de datos cumplen con los mismos estándares con sus propios mecanismos, pero con diferentes niveles de eficiencia.  En resumen, cualquier base de datos relacional debe ser capaz de pasar la prueba ACID. Esta debe garantizar ATOMICIDAD, CONSISTENCIA, AISLAMIENTO y DURABILIDAD.

A es para Atomicidad.

El principio del estado de atomicidad  es que todas las partes de una transacción deben ser completadas o ninguna de ellas. Por ejemplo, si los analistas de negocio han dicho que cada vez que cambie el salario de un empleado, también debe ser cambiado su grado, entonces la transacción atómica consiste de dos actualizaciones. La base de datos debe garantizar que ambas pasan o ninguna. Si solo una de las actualizaciones fue exitosa, usted tiene un empleado con un salario que no era compatible con su grado, una corrupción de datos, en términos de negocio. Si algo va mal antes que la transacción sea completada, la base de datos misma debe garantizar que cualquier parte llevada a termino se puede invertir; esto debe suceder automáticamente. Pero aunque una transacción atómica suene pequeña podría ser muy enorme. Para poner otro ejemplo, es lógicamente imposible en términos de contabilidad para el libro mayor de una suite contable estar a la mitad en agosto y mitad de septiembre, la refinación del fin de mes es por lo tanto en términos de negocio una transacción atómica, que puede afectar millones de files en miles de tablas, y tomar horas para completarse (o para hacer roll back si cualquier cosa va mal).

El roll back de una transacción incompleta es un proceso inverso y puede ser manual (como cuando emites el comando ROOLBACK), pero este debe ser automatico e imparable en el caso de un error. Oracle garantiza la atomicidad absoluta mediante el uso de Segmentos UNDO,  esto es tratado en detalle en el capítulo 11.

C es para Consistencia.

El principio del estado de consistencia, que los resultados de una consulta deben ser consistentes con el estado de la base de datos en el momento que inicio la consulta. Imagine una simple consulta que promedia los valores de una columna de una tabla. Si la tabla es grande, tomará muchos minutos en pasar a través de la tabla. Si otro usuario está actualizando la columna mientras la consulta esta en progreso, debería la consulta incluir los nuevos o los viejos valores? ¿Debería incluir filas que fueron insertadas o eliminadas después que la consulta fue iniciada? El principio de consistencia exige que la Base de Datos asegure que los cambios a valores no sean vistos por la consulta: que le dará un promedio de la columna como cuando fue iniciada la consulta. No importa cuánto tiempo tome la consulta o que otra actividad está ocurriendo sobre las tablas concernientes.

Mediante el uso de Segmentos Undo Oracle garantiza que si una consulta tiene éxito, el resultado será consistente. Sin embargo, si su segmento Undo esta incorrectamente configurado, la consulta puede que no tenga éxito: ha y un famoso error Oracle, ORA-1555 “snapshot too old” se genera. Este solía ser un problema muy difícil de corregir con las versiones anteriores de la base de datos, pero desde la versión 9i en adelante siempre debe ser capaz de evitarlo.

I es para Aislamiento

El principio del estado de aislamiento, que una transacción incompleta (que es sin confirmar - uncommitted) debe ser invisible para el resto del mundo. Mientras la transacción este en progreso, solo la sesión que está ejecutando la transacción está permitida a ver los cambios. Todas las otras sesiones deben ver los datos sin cambios, no los nuevos valores. La lógica detrás de esto es, primero, que la transacción completa no puede ir a través (recuerde el principio de atomicidad) y por lo tanto ningún otro usuario debería estar permitido ver los cambios que podrían revertirse. Y segundo, durante el progreso de una transacción los datos son inconsistentes (en términos de negocio): hay un corto tiempo cuando el empleado tiene  el salario cambiado, pero no su grado. El aislamiento de transacción requiere que la base de datos debe ocultar las transacciones en curso de otros usuarios: se verá la versión preupdate de los datos, hasta que se complete la transacción, cuando se podrán ver todos los cambios como un conjunto consistente.

Oracle garantiza el aislamiento de transacciones a través del uso de segmentos Undo.

D es para Durable

El principio del estado de durabilidad, que una vez que una transacción sea completada, debe ser imposible para la base de datos perderla. Durante el tiempo que la transacción está en curso, el principio de aislamiento requiere que nadie (a excepción de la sesión en cuestión) pueda ver los cambios hechos hasta ese momento. Pero en el instante que la transacción sea completada, debe ser comunicado a todo el mundo, y la base de datos debe garantizar que el cambio nunca se perderá: en una base de datos relacional no se permite que se pierdan los datos: oracle llena este requisito a través del uso de archivos Log. Los Log Files  pueden ser de dos formas: Online Redo Log Files y Archive Redo Log Files. Estos son tratados en detalle en el capítulo 15, por ahora solo recuerde que es imposible que una base de datos configurada apropiadamente pueda perder datos. Los datos pueden ser perdidos por errores de usuarios. Inapropiados DML o eliminación de objetos.  Pero por lo que respecta a Oracle y Pero por lo que Oracle DBA y el se refiere, estos eventos son las transacciones como cualquier otro: de acuerdo con el principio de la durabilidad, son absolutamente irreversible.

En el Trabajo.

Si una base de datos nunca pierde datos, la primera reacción de la administración es a menudo contra el DBA. Todo el mundo sabe que Oracle no pierde datos. Es por eso que la gente lo compra. Por lo tanto debe ser error del administrador. Carreras ha sido rotas por estas razones.

Ejecutando declaraciones SQL.

El total del lenguaje SQL es solo una docena de comandos.  Los únicos que nos preocupan aquí son:

·SELECT

·INSERT

·UPDATE

·DELETE

Recuerde que el standard SQL1999(implementado con Oracle Database release 9i) introdujo una poderoso comando MERGE, que combina INSERT e UPDATE. El standard SQL2003 (introducido con Oracle Database release 10g) MERGE fue mas alla, agregando capacidad DELETE. En cuanto a bases de datos se refiere, un MERGE no nada más que una combinación de INSERT, UPDATE y DELETE que pasan a ser ejecutadas con una sola pasada a través de los datos en lugar de varias. No hay necesidad de considerar por separado aquí.

Ejecutando una declaración SELECT.

El comando SELECT recupera datos. La ejecución de una declaración SELECT es un proceso en etapas: El proceso servidor que ejecuta la declaración primero comprueba si el bloque que contiene los datos requeridos ya está en memoria, en el Database Buffer Cache. Si ya esta, la ejecución puede proceder inmediatamente, si no está, el servidor debe localizarlo en el disco, y copiarlo sobre el Database Buffer Cache.

Examen

Siempre recuerde que el servidor Lee bloques desde los Datafiles al Database Buffer Cache, DBwn escribe bloques desde EL Database Buffer Cache a los Datafiles.

Una vez que los bloques requeridos para la consulta están en el Database Buffer Cache, cualquier futuro procesamiento (tales como ordenamiento o agrupación) es llevado a cabo en la PGA de la sesión. Cuando las ejecución es completada, el conjunto de resultados es regresado al proceso usuario.

Como se relaciona esto con la prueba ACID descrita? Para mantener la coherencia, si la consulta encuentra un Block que ha sido cambiado desde el momento que la consulta inicio, el proceso servidor va al Segmento Undo que protege el cambio, localiza la versión vieja del Dato, y (para los efectos de la consulta) hace roll back el cambio. Así, cualquier cambio iniciado después que la consulta comenzó no será visto. Un mecanismo similar garantiza el aislamiento de la transacción, aunque esto es basado si el cambio ha sido confirmado (committed), no solo sobre si los datos han sido cambiados. Claramente, si los datos necesarios para hacert este roll back  ya no están en los segmentos Undo, este mecanismo no funcionara. Que es cuando se obtiene el error “snapshot too old”.

Figura 10-1 muestra una representación de la forma de procesar una sentencia SELECT. En la figura, en el paso 1 es la transmisión de la declaración SELECT del proceso usuario al proceso servidor. El servidor buscará en el database buffer cache para averiguar si los bloques necesario ya están en memoria, y si ya están, procede el paso 4. Si no están, el paso 2 que es localizar los bloques en los datafiles, y el paso 3 es copiarlos en el Database Buffer Cache. El Paso 4 transfiere los datos al proceso servidor, donde puede haber un futuro procesamiento anterior, el paso 5 regresa los resultados  de la consulta al proceso usuario.

Ejecutando una Declaración UPDATE.

Para cualquier operación DML, es necesario trabajar en ambos bloques Bloques de Datos y Bloques Deshacer. Y también genera Redo: el A, C y I de la prueba ACID requiere generación de UNDO, el D requiere generación de Redo.

El primer paso en la ejecución DML es la misma como ejecutar un SELECT: los bloques requeridos debe estar en el Database Buffer Cache, o copiados en el Database Buffer Cache desde los Datafiles. El único cambio es que un bloque vacio (o experidado) de un Segmento Undo es necesario también. Desde aquí las cosas son más complicadas.

Primero, deben bloquearse filas y llaves de índices asociadas que van a ser afectadas por la operación.

Entonces el Redo es Generado: el proceso servidor escribe al Log Buffer los change vectors que van a ser aplicados a los bloques de datos. Esta generación de Redo es aplicada tantos cambios en el bloque de la tabla y cambios en block Undo: si una columna de una fila se va a actualizar, entonces el rowid y el nuevo valor de la columna son escritos al Log Buffer (que es el cambio que será aplicado al Bloque de la tabla). Y también el viejo valor (que es el cambio que será aplicado al Block Undo). Si la columna es parte de un Index Key. Entonces el cambio que se aplicara en el índice también se escribe al Log Buffer, junto con un cambio que se aplicara aun Bloque Undo para proteger el cambio del índice.

Then the redo is generated: the server process writes to the log buffer the change vectors that are going to be applied to the data blocks. This generation of redo is applied both to table block changes and to undo block changes: if a column of a row is to be updated, then the rowid and the new value of the column are written to the log buffer (which is the change that will be applied to the table block), and also the old value (which is the change that will be applied to the undo block). If the column is part of an index key, then the changes to be applied to the index are also written to the log buffer, together with a change to be applied to an undo block to protect the index change.

Teniendo el Redo generado, la actualización es llevada a cabo en el Database Buffer Cache: el block de la tabla de datos es actualizado con la nueva versión del cambio en la columna, y la vieja versión de la columna cambiada es escrito al Block del Segmento Undo. Desde este punto hasta la actualización es confirmada (committed), todas las consultas desde otras sesión que tratan la fila cambiada serán dirigidas a los Datos Undo. Solo la sesión que está haciendo la actualización vera la versión actual de la fila en el bloque de la tabla. El mismo principio aplica para cualquier índice cambiado.

Como un simple ejemplo, considera esta declaración:

Having generated the redo, the update is carried out in the database buffer cache: the block of table data is updated with the new version of the changed column, and the old version of the changed column is written to the block of undo segment. From this point until the update is committed, all queries from other sessions addressing the changed row will be redirected to the undo data. Only the session that is doing the update will see the actual current version of the row in the table block. The same principle applies to any associated index changes.

Update emp set sal=sal*1.1 where empno=7934;

Para ejecutar esta declaración, el block de la tabla de datos que contiene la fila para el numero de empleado 7934 (y posiblemente otras filas también, si las filas son más pequeñas que el block), es copiado sobre el Database Buffer Cache, y un Block y un Block de un Segmento Undo es también copiado sobre el Cache.  Entonces sus procesos servidor escriben al Log Buffer la vieja versión del la columna SAL (Que es el cambio a ser aplicado al Block Undo) y la nueva versión de la columna SAL (que es el cambio a ser aplicado al block de la tabla de datos), por último, los mismos bloques son actualizado en el Database Buffer Cache y recuerda que  SQL es un lenguaje orientado a conjunto. Si hay muchas filas en la tabla EMP con el mismo EMPNO, todos serian actualizadas por una declaración. Pero debido a EMPNO será la clave principal, esto no va a suceder.

Ejecutando declaraciones INSERT y DELETE.

Conceptualmente, INSERT y DELETE son manejados de la misma forma como un UPDATE. El primer paso es localizar el Block relevante en el Database Buffer Cache, o copiarlo si no está allí.

La Generación de Redo es exactamente la misma: Todos los change vectors a ser aplicados a los datos y Undo Blocks son primero escritos al Log Buffer. Para un insert, el Change Vector a ser aplicado al bloque de la tabla (y posiblemente block index) son los bytes que componen la nueva fila (y posiblemente el nuevo index key). El Vector a ser aplicado al Undo Block es el rowid de la nueva fila. Para un DELETE, el change vector a ser escrito al Undo Block es la fila entera.

Una diferencia crucial entre INSERT y DELETE es en la cantidad de Undo generado. Cuando una fila es insertada, el único Undo generado es escribiendo el nuevo ROWID al Undo Block. Esto es porque para un Roll Back de un INSERT, la única información que Oracle requiere es el ROWID, por lo que esta declaración puede ser construida, como sigue:

delete from table_name where rowid=rowid_of_the_new_row ;

Ejecutando esta declaración regresaría al cambio original.

Para un DELETE, toda la fila (que pueden ser varios kilobytes) debe ser escrita a un Block Undo, de modo que la eliminación puede revertirse Roll Back mediante la construcción de una declaración que insertara la fila completa de nuevo a la tabla.

EXAMEN

INSERT genera una cantidad minima de Datos Undo; DELETE genera mucho más.

EXAMEN.

Undo no es lo contrario de Redo. Redo protege todos los cambios en los Bloques, no importa si es un cambio a un block de un Segmento Tabla, un segmento Index o un Segmento Undo, en cuanto a Redo se refiere, un Segmento Undo es solo otro segmento y cualquier cambio  debe ser duradero.

CONTROL DE TRANSACCIONES: COMMIT, ROLLBACK, SAVEPOINT.

Oracle implementa el Paradigma de Base de Datos relacional iniciando una transaccion implicitamente con la primera declaracion DMLK ejecutada. La transacción continúa hasta una declaración COMMIT o ROLLBACK. El comando SAVEPOINT no es parte de SQL standard y es realmente solo una manera fácil para que los programadores regresen algunas declaraciones, en orden inverso. No tiene que ser considerado separadamente. Ya que no termina una transacción.

Escenarios y Soluciones
Si se ejecuta una aplicación lenta y Control de la base de datos muestra que el bloqueo es el problema, lo que podría hacer para resolver el problema?	En el corto plazo, puede intentar matar a las sesiones. Pero eso no es una especie de solución real. La respuesta por lo general se encuentran ya sea en una mala programación o diseño deficiente del sistema. Los problemas de programación debe ser discutido con la que los desarrolladores son tomando más seguros de lo necesario, o no ponerlos en libertad con la suficiente rapidez? Los problemas de diseño se debe discutir con los analistas de negocio. Tal vez la estructura de la transacción entera se podría mejorar.
Si se ejecuta una aplicación lenta y los administradores del sistema dicen que el sistema es de E / S de la envolvente, lo que podría hacer para resolver el problema?	El Disco no es un problema. Es sólo un síntoma de un problema. La pregunta que debemos hacernos no es "¿cómo puedo mejorar el disco I / O", sino "¿cómo puedo reducir la necesidad de disco E / S?" Esto a menudo implica el ajuste de SQL y el uso de memoria de ajuste. Puesta a punto / S de disco es el último recurso.

EJECUTANDO UN ROLL BACK

Recuerde que si algo sale mal, Roll Back de transacciones en progreso es completamente automático y es realizado por procesos background. Por ejemplo, si la sesión que inicio la transacción falla (tal vez una pc corriedno un proceso usuario se reinicia o la red baja), el PMON detectara que hay un problema con la sesión, y hará Roll Back de la transacción. Si el servidor es reiniciado mientras la base de datos esta en uso, entonces al iniciar SMON detectara el problema e iniciara un Roll Back de todas las transacciones activas.

Un Roll Back manual requiere que el usuario emita el comando ROLLBACK. Pero sin embargo el Roll Back es iniciado, el mecanismo es idéntico:   en el caso de un UPDATE, la versión preupdate de la columna, como se almacena en el block del segmento Undo, esto es utilizado para construir otro comando UPDATE que establece la columna de la fila en el bloque de la tabla a su valor original. Para un Roll Back de un INSERT, Oracle recupera el rowid de la fila insertada desde el Bloque Undo y lo utiliza como la llave de una declaración DELETE sobre la tabla. Para hacer u Roll Back de un DELETE, Oracle construye una declaración completa INSERT desde los datos en el Block Undo. Por lo tanto. La implementación de Oracle del comando Roll Back es el uso de Datos Undo para construir y ejecutar otra declaración que reverse el efecto de la primera declaración. Entonces Oracle emitirá un COMMIT que confirme ambas el Cambio Original y el cambio Roll back, como una transacción.

En el trabajo

Un Roll Back generara mas Redo por lo que ejecuta, tal vez algo más que la declaración original.

Si usted emite un comando DML y omite la clausula WHERE, como este:

delete from emp;

y así elimina todos los varios millones de files en la tabla cuando usted pretendía eliminar uno, puede revertir los cambios. Durante el borrado o eliminación, su proceso servidor copiara las filas a un segmento Undo borradas entonces de la tabla: ROLL BACK insertara de nuevo a la tabla, y nadie sabrá que cometió el error. A menos, claro, que escribió un COMMIT.

EJECUTANDO UN COMMIT

El proceso COMMIT es donde mucha gente (e incluso algunos experimentados DBAs) muestran una incompleta, inexacta o incluso por completo, la comprensión de la arquitectura Oracle. Cuando usted dice COMMIT, todo lo que sucede físicamente es que LGWR fluye el Log Buffer a Disco, DBWn no hace absolutamente nada. Este es uno de las mayores importancias de rendimiento de la Base de Datos Oracle.

Para hacer una transacción durable, todo lo que es necesario es que los cambios que se hicieron la transacción estén sobre disco: no hay ninguna necesidad de que los datos actuales de la tabla para estar en disco, en los datafiles. Si los cambios están sobre disco, en la forma de multiplexar redo log files, entonces, en caso de daño a la base de datos la transacción puede ser reinstanciada para restaurar los datafiles desde un backup tomando antes del daño ocurrido y aplicar los cambios desde los logs. Este proceso se cubre en detalle en capítulos posteriores, por ahora,  simplemente no es el hecho que un commit involucre nada más que fluir el Log buffer a disco y abanderar la transacción como completa. Este es porque una transacción involucra millones de actualizaciones en miles de archivos a través de minutos u horas se pueden confirmar en una fracción de segundo. Porque LGWR escribe en tiempo casi real, prácticamente todos los cambios de la transacción están en el disco ya. Cuando usted dice COMMIT, LGWR actualmente escribe en tiempo real: la sesión se bloqueara hasta que la escritura se complete. Este retraso será el tiempo que toma el ultimo bit de redo desde el log buffer a disco, que tomara mili segundos. Su sesión es entonces libre de seguir, y desde entonces todas las otras sesiones ya no serán redirigidas a los bloques undo cuando la dirige el cambio de tabla, a menos el principio de consistencia.

To make a transaction durable, all that is necessary is that the changes that make up the transaction are on disk: there is no need whatsoever for the actual table data to be on disk, in the datafiles. If the changes are on disk, in the form of multiplexed redo log files, then in the event of damage to the database the transaction can be reinstantiated by restoring the datafiles from a backup taken before the damage occurred and applying the changes from the logs. This process is covered in detail in later chapters—for now, just hang on to the fact that a COMMIT involves nothing more than flushing the log buffer to disk, and flagging the transaction as complete. This is why a transaction involving millions of updates in thousands of files over many minutes or hours can be committed in a fraction of a second. Because LGWR writes in very nearly real time, virtually all the transaction’s changes are on disk already. When you say COMMIT, LGWR actually does write in real time: your session will hang until the write is complete. This delay will be the

length of time it takes to flush the last bit of redo from the log buffer to disk, which will take milliseconds. Your session is then free to continue, and from then on all other sessions will no longer be redirected to the undo blocks when they address the changed table, unless the principle of consistency requires it.

Examen.

Que hace Database Write cuando usted dice COMMIT? Absolutamente nada.

Los change vectors escritos al Redo Log son todos los change vectors: que se aplican a los Data Block (tablas e indices) y las aplicadas a los segmentos Undo.

Examen.

El Redo Log Stream incluye todos los cambios: aplicados a los Segmentos de Datos y a los Segmentos Undo, para transacciones committed y uncommitted.

Habiendo dicho eso DBWn no tiene nada que ver con el proceso de commit, por su puesto escribe cambios o bloques “sucios” a disco – eventualmente. El algoritmo utilizado  está destinado a garantizar que mientras cambia block se llega a disco. No serán escritos con tanta rapidez como para impactar en el funcionamiento normal. Si DBWn nunca escribió los Block a disco, habría una enorme cantidad de trabajo para hacerlo cuando un checkpoint es finalmente necesario. La excepción es cuando un checkpoint se emite: estas son las raras ocasiones (típicamente, solo durante un cierre ordenado de la base de datos e instancia) cuando CKPT instruye al DBWn escribir todos los block sucios a los datafiles. El proceso checkpoint es cubierto en detalle en capitulo 15.

Examen

En ejecución normal. DBWn escribe solo pocos buffers sucios a disco; cuando un checkpoint es señalado, escribe todos los buffer sucios a disco.

Donde a menudo hay confusión es que el stream de redo es escriben en los archivos log por el LGWR  contendrá cambios para ambas transacciones committed y uncommitted. Por otra parte, en cualquier momento dado DBWn puede o no puede escribir bloques cambiados de Segmentos de Datos o Segmentos Undo a los Datafiles para transacciones committed y uncommitted. Por lo tanto, su base de datos en disco está dañada: los datafiles pueden estar almacenando trabajo uncommitted, y faltar los cambios committed. Pero en el evento de un accidente, el stream de redo sobre disco siempre tiene suficiente información para re instanciar cualquier transacción committed que no está en los Datafiles (por el uso de cambios aplicados a los data blocks) y para re instanciar los segmentos undo (por el uso de los cambios aplicados a los block undo) necesarios para regresar (rollback) cualquier transacción que está en los datafiles.

DDL y Control de Transacciones.

Las declaraciones COMMIT y ROLLBACK solo aplican a DML. Usted no puede hacer rollback a declaraciones DDL: una vez ejecutada es inmediatamente durable. Si fuera posible ver el código fuente por ejemplo el comando CREATe TABLE, seria obvio porque. Cuando usted crea una tabla, usted de hecho está realizando una transacción contra algunas tablas del diccionario de datos: por lo menos, insertando un registro en SYS.TAB$ que es una tabla del diccionario de datos con una fila para definir cada tabla en la base de datos, y una o más filas en la tabla SYS.COL$ una tabla del diccionario de datos con una fila para la definición de cada columna de cada tabla en la base de datos. Entonces el comando concluye con un commit. Esto es para proteger el diccionario de datos: si el commit no fuera incorporado en el comando CREATE TABLE, la posibilidad de una transacción incompleta surgen y una transacción incompleta en el diccionario de datos puede tener terribles efectos secundario. Desde que no es posible anidar las transacciones (el standard sql no lo permite) la ejecución de uno o más comandos DML seguidos por un comando DDL  commit el lote completo. Las declaraciones DML asi como las declaraciones DDL.

Examen.

Cualquier comando DDL o un GRANT o REVOKE hace commit a la transacción actual.

El llamado “Autocommit”

Para concluir esta discusión del procesamiento de commit, es necesario eliminar cualquier confusión acerca  de lo que llamamos aitocommit, o a veces commit implícito. Usted a menudo oirá que en algunas situaciones oracle autocommit.  Una de estas situaciones es cuando se hace un DDL, que es descrito en la sección anterior. Otra es cuando usted sale de un proceso usuario tales como SQLPLUS. Sencillamente, no hay tal como un commit automatico. Cuando usted ejecuta una declaración DDL, hay un commit incluido en el código fuente que implementa el comando DDL. Pero que cuando usted sale de un proceso usuario? Si está utilizando SQL*PLUS sobre una terminal Windows (no importa qué sistema operativo  del servidor de base de datos  esta en ejecución) y se emite una declaración DML seguida por un EXIT, su transacción será committed. Esto es porque el comando EXIT de sqlplus  tiene una declaración COMMIT; si pudiéramos ver el código fuente seria obvio. Pero qué pasa si da click en el botón cerrar de la ventana.

La ventana se cerrara, y si vuelve a iniciar otra vez, vera que la transacción fue hecha rollback. Esto es porque los programadores que escribieron SQLPLUS para Windows incluyeron una declaración ROLLBACK en el código que es ejecutado cuando usted cierra la ventana.  El comportamiento de SQLPLUS en otras plataformas puede ser muy diferente; la única forma de estar seguro es que lo pruebe. Asi que si usted recibe un autocommit cuando sale de un programa de varias maneras es totalmente dependiente como los programadores escribieron su proceso usuario. Oracle server simplmenete hace lo que se le dijo.

Hay un comando SQLPLUS SET AUTOCOMMIT ON. Esto hara que SQLPLUS modifique su comportamiento: se añade un commit a cada declaración DML emitida. Así que todas las declaración son committed inmediatamente tan pronto son ejecutadas y no pueden ser regresadas. Pero esto sucederá en lado del proceso usuario, todavía no hay un autocommit en la base de datos y los cambios realizados por una declaración de larga duración será aislado de las otras sesiones hasta que la transacción sea completada. Por supuesto, una salida desordenada de SQLPLUS en esta circunstancias tales como matar con una utilidad mientras la transacción esta ejecutándose, será detectada por PMON y la transacción activa siempre se hará rollback.

Ejercicio 10-1

Gestionando Datos utilizando DML.

En este ejercicio se demostrara el aislamiento y control de transacciones. Utilice dos sesiones SQLPUS. Cada una conectada con el usuario SYSTEM.