Cómo las Bases de Datos Populares Manejan los Comandos DDL en Transacciones

La integración de comandos DDL en las transacciones es una de las características más poderosas que proporcionan las bases de datos. Pero no todas las bases de datos son capaces de revertir los cambios de DDL. Oracle, PostgreSQL, MySQL, MariaDB, DB2, MSSQL, Teradata, Greenplum, Netezza, Redshift, Aurora son las bases de datos relacionales más populares y este artículo describe su capacidad para soportar comandos DDL en transacciones.

Una transacción es una secuencia de comandos incorporados en una unidad lógica. Por lo tanto, una transacción se ejecuta como una entidad. Cuando una ejecución de transacción se interrumpe, la transacción no se ejecuta en absoluto. Las transacciones se usan para preservar la integridad de la base de datos, la ejecución singular de todos los comandos que la transacción incluye, significa guardar las restricciones de integridad y la imposibilidad de dejar la base de datos en un estado transitorio y no consistente.

DDL (Lenguaje de Definición de Datos) es una familia de elementos del lenguaje SQL que se utiliza para definir la estructura de la base de datos (incluyendo operaciones con bases de datos, tablas, columnas, índices, vistas, procedimientos almacenados, restricciones).

Para entender qué es DDL, es importante saber que las sentencias DDL juegan un papel crucial en los sistemas de gestión de bases de datos (DBMS) al permitir a los usuarios definir y modificar la estructura de la base de datos. La capacidad de ejecutar DDL en sistemas de gestión de bases de datos es esencial para mantener la integridad y consistencia de los datos almacenados dentro de la base de datos. Sin embargo, el comportamiento de las sentencias DDL dentro de las transacciones varía entre diferentes implementaciones de DBMS. Comprender cómo se comportan las sentencias DDL dentro de las transacciones en su DBMS específico es crucial para asegurar la integridad de los datos y aplicar mecanismos de manejo de errores adecuados.

Nuestra Suite de Seguridad de Base de Datos DataSunrise está diseñada para la protección de bases de datos relacionales contra el acceso no autorizado y fugas de datos. Para realizar esta tarea, se implementa un potente sistema de políticas de seguridad (las reglas) para la restricción de acceso a la base de datos y el enmascaramiento dinámico de datos. Para emplear esta funcionalidad, nuestro programa debe conocer el estado de los metadatos de la base de datos en todo momento. Los metadatos son el esquema de la base de datos y conjuntos de valores de variables del sistema, que afectan la ejecución de consultas e interpretan resultados. Los metadatos se pueden obtener enviando una serie de consultas al servidor de la base de datos.

DataSunrise también admite el seguimiento de cambios incrementales, registra los resultados de ejecución de los comandos DDL procesados por nuestro producto. Pero la parte realmente interesante comienza cuando necesitas soportar cambios de metadatos dentro de la transacción. Algunos RDBMSs soportan la transaccionalidad de los comandos DDL, es decir, puedes revertir estos comandos al revertir la transacción. Otros RDBMSs no soportan DDLs en transacciones. Los comandos DDL en tales RDBMSs terminan la transacción actual implícitamente o causan un error en el servidor SQL.

Sin embargo, los RDBMSs más populares están en un punto intermedio: soportan la transaccionalidad de los comandos DDL pero no para todos los comandos. Por lo general, los comandos más globales usados para crear y eliminar objetos del sistema de archivos en el almacenamiento de la base de datos, no pueden soportar el procedimiento de reversión, por lo tanto se soporta la transaccionalidad para comandos menores cuya reversión no causa cambios en la estructura del sistema de archivos. Las transacciones en todos los RDBMSs son similares solo en general. Pero en la práctica, cada base de datos presenta una sintaxis única de comandos de control de transacciones y cada RDBMS tiene sus propios mecanismos de control de transacciones únicos. Llamamos a esto un modelo de transacción de un RDBMS determinado.

Para el procesamiento correcto de los cambios de metadatos, nuestro programa debe ser capaz de revertir los cambios de DDL abortados al revertir la transacción. Es una tarea algorítmica bastante compleja: requiere el soporte del delta de metadatos (diferencial) que corresponde a los cambios DDL dentro de la transacción actual de cada conexión a la base de datos. Tal delta existe antes de que la transacción se cierre y podría revertirse como una pieza o en partes (para aquellos RDBMSs que soportan transacciones de varios niveles o puntos de salvaguarda).

Ahora echemos un vistazo a las características que las bases de datos populares pueden ofrecer en el contexto de DDL transaccional.

Base de Datos Oracle

Oracle no soporta DDL transaccional: la transacción se considera cerrada cuando se ejecuta el comando CREATE, DROP, RENAME o ALTER. Si la transacción contiene comandos DML, Oracle confirma la transacción en su totalidad y luego confirma el comando DDL como una transacción separada.

PostgreSQL

PostgreSQL soporta DDL transaccional: todos los comandos DDL excepto las operaciones de gran calibre destinadas a la creación y eliminación de objetos como DATABASE, TABLESPACE, CLUSTER. PostgreSQL soporta transacciones de varios niveles a nivel de puntos de salvaguarda. A diferencia de SQL estándar, PostgreSQL soporta puntos de salvaguarda homónimos. Esto significa que los puntos más antiguos no están disponibles mientras existan los más recientes.

Si ocurre un error dentro de una transacción, PostgreSQL revierte toda la transacción pero requiere un comando para completar la transacción actual (COMMIT, ROLLBACK, ABORT) en cualquier caso. PostgreSQL inicia una transacción implícita al principio de la multisentencia y transforma la transacción en explícita cuando hay un comando BEGIN dentro de una multisentencia (la transacción se considera iniciada con el comienzo de la multisentencia).

MySQL

MySQL no soporta DDL transaccional. No hay transacciones disponibles para MyISAM en absoluto. Para InnoDB, los comandos DDL causan una confirmación implícita de la transacción actual.

MariaDB

MariaDB hereda su comportamiento en términos de DDL transaccional de MySQL y no lo soporta.

DB2

DB2 soporta transacciones de varios niveles tanto a nivel de transacción anidada como a nivel de puntos de salvaguarda. Los puntos de salvaguarda se proporcionan con espacios de nombres independientes en cada nivel de anidamiento.

Microsoft SQL Server (MS SQL)

El soporte de transacciones de varios niveles en MS SQL se expresa en el soporte de puntos de salvaguarda. En SQL Server, las llamadas transacciones anidadas solo sirven como un contador de llamadas de BEGIN TRANSACTION. Para confirmar la transacción es necesario llamar a un determinado número de COMMIT TRANSACTION, y el comando de ROLLBACK revierte toda la transacción sin importar el nivel de anidamiento. El primer BEGIN TRANSACTION siempre se considera como el inicio de la transacción y al mismo tiempo habilita el trabajo completo con transacciones de varios niveles a través de puntos de salvaguarda. Los puntos de salvaguarda podrían usarse a través de los comandos SAVE TRANSACTION y ROLLBACK TRANSACTION.

Teradata

Teradata no soporta DDL transaccional. DDL podría colocarse dentro de una transacción, pero no más de un comando por transacción y solo como el último comando en la transacción. El comportamiento de Teradata es similar al de Oracle en este aspecto. Por lo tanto, un DDL podría ejecutarse con la ejecución de la transacción o no ejecutarse en absoluto con la reversión de la transacción. Esto significa que los cambios DDL que pueden existir durante un cierto tiempo y luego ser revertidos no están disponibles.

Greenplum

El comportamiento de Greenplum es similar al de PostgreSQL.

Netezza

Netezza también se originó de PostgreSQL pero hace mucho tiempo. Y presenta algunas diferencias importantes con respecto al soporte de transacciones. Netezza soporta DDL en transacciones también, pero no proporciona soporte de transacciones de varios niveles (puntos de salvaguarda) y es imposible comenzar una transacción desde el principio de una multisentencia, si la multisentencia ya contiene comandos DDL.

Amazon Redshift

Similar a PostgreSQL.

Amazon Aurora

Similar a MySQL.

Todo el conocimiento sobre las características mencionadas se implementa en la Suite de Seguridad de Base de Datos DataSunrise. Siempre sabemos cómo se ve su esquema de base de datos y podemos proporcionar su protección perfecta.

DataSunrise soporta todas las bases de datos y almacenes de datos principales, incluidos Oracle o Exadata. También soporta IBM DB2, IBM Netezza, MySQL, MariaDB, Greenplum, Amazon Aurora, Amazon Redshift, Microsoft SQL Server, Azure SQL, Teradata y más. Lo invitamos a descargar una prueba gratuita si desea instalarlo en sus instalaciones. En caso de ser usuario de la nube y ejecutar su base de datos en Amazon AWS o Microsoft Azure puede obtenerlo desde AWS market place o Azure market place.