¿Hay alguna diferencia entre commit y rollback en una transacción que solo tiene selecciones?
https://stackoverflow.com/questions/198108
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
El marco de aplicación interno que utilizamos en mi empresa hace que sea necesario poner todas las consultas SQL en transacciones, aunque sé que ninguno de los comandos realizará cambios en la base de datos. Al final de la sesión, antes de cerrar la conexión, confirmo la transacción para cerrarla correctamente. Me pregunto si habría alguna diferencia en particular si lo revirtiera, especialmente en términos de velocidad.
Tenga en cuenta que estoy usando Oracle, pero supongo que otras bases de datos tienen un comportamiento similar. Además, no puedo hacer nada sobre el requisito de comenzar la transacción, esa parte de la base de código está fuera de mis manos.
Solución
Las bases de datos a menudo conservan un diario anterior a la imagen (lo que era antes de la transacción) o un diario posterior a la imagen (qué será cuando se complete la transacción). Si mantiene una imagen anterior, debe restaurarse en una reversión. Si mantiene una imagen posterior, debe reemplazar los datos en caso de confirmación.
Oracle tiene tanto un diario como un espacio de reversión. El diario de transacciones acumula bloques que luego son escritos por los escritores de bases de datos. Dado que estos son astronómicos, casi nada relacionado con el escritor DB tiene ningún impacto en su transacción (si la cola se llena, entonces es posible que tenga que esperar).
Incluso para una transacción de solo consulta, estaría dispuesto a apostar que hay un poco de mantenimiento de registros transaccionales en las áreas de reversión de Oracle. Sospecho que una reversión requiere un poco de trabajo por parte de Oracle antes de determinar que no hay nada que realmente pueda retroceder. Y creo que esto está sincronizado con su transacción. Realmente no puede liberar ningún bloqueo hasta que se complete la reversión. [Sí, sé que no está utilizando ninguno en su transacción, pero el problema de bloqueo es por qué creo que se debe liberar completamente una reversión, entonces se pueden liberar todos los bloqueos y luego se finaliza su reversión.]
Por otro lado, el commit es más o menos el resultado esperado, y sospecho que descartar el área de reversión podría ser un poco más rápido. No creó entradas de transacciones, por lo que el escritor de db nunca se despertará para verificar y descubrir que no había nada que hacer.
También espero que aunque commit sea más rápido, las diferencias sean menores. Tan insignificante que es posible que ni siquiera pueda medirlos en una comparación lado a lado.
Otros consejos
Estoy de acuerdo con las respuestas anteriores de que no hay diferencia entre COMMIT y ROLLBACK en este caso. Puede haber una diferencia insignificante en el tiempo de CPU necesario para determinar que no hay nada que COMPROMETAR en comparación con el tiempo de CPU necesario para determinar que no hay nada que ROLLBACK. Pero, si es una diferencia insignificante, podemos olvidarlo con seguridad.
Sin embargo, vale la pena señalar que hay una diferencia entre una sesión que hace un montón de consultas en el contexto de una sola transacción y una sesión que hace las mismas consultas en el contexto de una serie de transacciones.
Si un cliente inicia una transacción, realiza una consulta, realiza un COMPROMISO o ROLLBACK, luego inicia una segunda transacción y realiza una segunda consulta, no hay garantía de que la segunda consulta observe el mismo estado de la base de datos que la primera consulta. A veces, mantener una vista única y consistente de los datos es esencial. A veces, obtener una visión más actual de los datos es esencial. Depende de lo que estés haciendo.
Lo sé, lo sé, el OP no hizo esta pregunta. Pero algunos lectores pueden preguntarlo en el fondo de sus mentes.
En general, un COMMIT es mucho más rápido que un ROLLBACK, pero en el caso de que no haya hecho nada, son efectivamente los mismos.
La documentación indica que:
- Oracle recomienda que finalice explícitamente cada transacción en sus programas de aplicación con una declaración COMMIT o ROLLBACK, incluida la última transacción, antes de desconectarse de Oracle Database. Si no confirma explícitamente la transacción y el programa finaliza de manera anormal, la última transacción no confirmada se revierte automáticamente. Una salida normal de la mayoría de las utilidades y herramientas de Oracle hace que se confirme la transacción actual. Una salida normal de un programa precompilador de Oracle no confirma la transacción y se basa en Oracle Database para revertir la transacción actual.
Si desea elegir hacer una o la otra, entonces también podría hacer la que es lo mismo que no hacer nada, y simplemente confirmarla.
Bueno, debemos tener en cuenta lo que devuelve un SELECT en Oracle. Hay dos modos Por defecto, un SELECT devuelve datos tal como se vieron en el momento en que la instrucción SELECT comenzó a ejecutarse (este es el comportamiento predeterminado en el modo de aislamiento READ COMMITTED, el modo transaccional predeterminado). Por lo tanto, si se ejecutó una ACTUALIZACIÓN / INSERTAR después de que se emitió SELECT, eso no será visible en el conjunto de resultados.
Esto puede ser un problema si necesita comparar dos conjuntos de resultados (por ejemplo, los lados de débito y crédito de una aplicación de contabilidad general). Para eso tenemos un segundo modo. En ese modo, SELECT devuelve datos tal como se veían en el momento en que comenzó la transacción actual (comportamiento predeterminado en LECTURA ÚNICA y niveles de aislamiento SERIALIZABLES).
Entonces, al menos a veces es necesario ejecutar SELECT en la transacción.
Dado que no ha realizado ningún DML, sospecho que no habrá diferencia entre un COMMIT y un ROLLBACK en Oracle. De cualquier manera, no hay nada que hacer.
Creo que un Commit sería más eficiente; ya que generalmente esperaría que se comprometieran la mayoría de las transacciones de DB; por lo que pensaría que la base de datos se optimiza para este caso (en lugar de intentar ser más eficiente para una reversión).
