DALL·E 2024 03 03 13.10.10 Imagine a 1024x1024 pixels illustration that visualizes the concept of AUTOCOMMIT in the context of Oracle versus PostgreSQL. The image should depict

AUTOCOMMIT – Oracle VS Postgres

Como DBAs muchas veces nos toca trabajar con distintas tecnologías de base de datos, y es esencial saber cómo se guardan los cambios en cada una de ellas.

Oracle y PostgreSQL difieren significativamente en sus modelos de transacciones, y AUTOCOMMIT es una de esas diferencias.

Vemos que muchos de nuestros clientes migran su código con éxito, pero aún así se encuentran con variaciones en el comportamiento e incluso errores de ejecución relacionados con el control de transacciones.

Muchos de estos problemas surgen porque la configuración de AUTOCOMMIT difiere entre Oracle y PostgreSQL.

En el artículo de hoy vamos a entender las diferencias del AUTOCOMMIT entre Oracle y PostgreSQL para ayudaros a garantizar una migración exitosa.

¡Al turrón!

¿Qué es el autocommit?

Autocommit en bases de datos se refiere a un modo en el que cada sentencia SQL se confirma automáticamente al ejecutarse, convirtiendo las sentencias individuales en transacciones independientes.

En el modo autocommit, cada sentencia de usuario se trata como una transacción independiente, y se realiza automáticamente un commit al final de la sentencia si la ejecución tiene éxito.

Si se produce un error, los cambios realizados durante la ejecución de la sentencia se revierten.

El autocommit en Oracle

Oracle no tiene un modo de autocommit como tal. Es decir, en Oracle, la configuración de AUTOCOMMIT no es una algo que se configure directamente en el propio servidor de base de datos.

En su lugar, el comportamiento de autocommit se controla normalmente a nivel de cliente o controlador.

Por ejemplo, muchos clientes SQL, herramientas de desarrollo y controladores de lenguajes de programación que interactúan con bases de datos Oracle pueden configurarse para confirmar transacciones automáticamente después de ejecutar cada sentencia SQL.

Para gestionar el comportamiento de autocommit en aplicaciones que se conectan a Oracle, lo normal es consultar la documentación específica del cliente o del controlador que estemos utilizando para ver cómo activar o desactivar autocommit.

Por ejemplo, en Java JDBC (Java Database Connectivity), podemos controlar este comportamiento llamando a setAutoCommit(true) o setAutoCommit(false) en el objeto Connection.

Por defecto, Oracle opera en un modo transaccional en el que los cambios realizados por sentencias SQL (como INSERT, UPDATE, DELETE) dentro de una transacción no se hacen permanentes en la base de datos hasta que se emite una sentencia COMMIT explícita.

Ejemplo del funcionamiento del autocommit de Oracle

Pongamos que tengo 2 sesiones abiertas de SQL Plus. En la primera sesión, insertaré 10 registros a una tabla de ejemplo:

SQL> INSERT INTO JGS.TEST VALUES(10);

1 row created.

En la segunda sesión, y sin cerrar la primera sesión, trato de consultar la tabla:

SQL> SELECT COUNT(*) FROM JGS.TEST;

  COUNT(*)
----------
         0

Como podéis ver, no podemos ver la fila insertada por la primera sesión visible para la segunda sesión. ¿Por qué? Por ese comportamiento de modo transaccional que hablábamos al principio.

Oracle da el control total al usuario/cliente sobre cuando realizar un commit y no existe el concepto de AUTOCOMMIT como tal.

Para poder ver los cambios en la segunda sesión, o bien tenemos que COMPROBAR los cambios en la primera sesión o activar AUTOCOMMIT a nivel de Cliente.

Excepciones

Las sentencias DDL en Oracle sí harán autocommit de cualquier transacción pendiente en la sesión antes de iniciarse y de nuevo después de completarse.

Esto significa que si tienes alguna operación DML (INSERT, UPDATE, DELETE) no commiteada antes de que se ejecute una sentencia DDL, Oracle hará autocommit de esos cambios.

Del mismo modo, una vez que la operación DDL se completa, se commitea de nuevo, haciendo que los cambios DDL sean permanentes.

El autocommit en Postgres

PostgreSQL opera en modo autocommit-on, y no hay opción de cambiar este comportamiento a nivel de servidor. Esto se conoce comúnmente como transacciones ejecutadas en modo unchained.

Sin embargo, PostgreSQL permite a los clientes configurar las opciones de autocommit. Estos clientes de bases de datos normalmente nos permiten desactivar autocommit en el lado del cliente, emitiendo automáticamente una sentencia BEGIN antes de la primera sentencia que sigue al final de una transacción.

Sesión 1:

postgres=# INSERT INTO jgs.test VALUES(10);
INSERT 0 1

Sesión 2:

postgres=# SELECT COUNT(*) FROM jgs.test;
 count
-------
     1
(1 row)

Es el mismo ejemplo que el caso anterior, pero somos capaces de obtener los cambios de la primera sesión en la segunda sesión. ¿Por qué? Porque el servidor PostgreSQL opera en modo autocommit on.

Como desactivar el autocommit en Postgres

Comenzaré esta sección diciéndoos que NO es recomendable desactivar autocommit.

Ahora bien, la mayoría de los clientes de bases de datos y APIs, incluyendo psql, JDBC, psycopg2, pgAdmin, y DBeaver, tienen una opción para deshabilitar autocommit.

Así que cuando usamos psycopg2, necesitamos asegurarnos de activar el modo AUTOCOMMIT usando la siguiente sentencia donde conn es la variable de conexión.

Conclusión

Resumiendo, al migrar de Oracle a PostgreSQL, la forma en que manejamos AUTOCOMMIT puede causar problemas.

Oracle se basa en commits manuales, mientras que PostgreSQL opera en modo autocommit por defecto.

Entender y ajustarse a estas diferencias es vital para una transición correcta, evitando problemas inesperados en cómo se gestionan las transacciones.

Siempre se recomienda no desactivar el autocommit, ya que al hacerlo se producen comportamientos inesperados y errores en tiempo de ejecución.

Únete a la lista de emails para no perderte nada

No tengo ningún producto, publicidad, ni nada que venderte. De hecho, aún no tengo nada que hacer con estos emails. Pero si te interesa estar en contacto o no perderte las próximas actualizaciones en el futuro… Ya sabes 😉

    ¿Quieres trabajar con nosotros?

    Ya sea que necesites mejorar el rendimiento de consultas existentes, planificar y ejecutar migraciones de datos críticas, diseñar bases de datos desde cero o mantener un entorno de base de datos estable, estamos aquí para ayudarte.

    Trabajamos con una amplia variedad de sistemas de gestión de bases de datos (DBMS) y estamos comprometidos en proporcionar soluciones adaptadas a tus necesidades específicas. Puedes consultar nuestra lista completa de servicios aquí.

    Confía en nosotros para optimizar tus bases de datos y liberar tiempo y recursos para que puedas concentrarte en lo que realmente importa: hacer crecer tu negocio.

    ¡Contáctanos hoy mismo y descubre cómo podemos ayudarte.


    Comentarios

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *