Transacciones en Fabric Data Warehouse

Aplica a:✅ el punto de conexión de análisis SQL y el Almacén en Microsoft Fabric

De forma similar a su comportamiento en SQL Server, las transacciones permiten controlar la confirmación o reversión de las consultas de lectura y escritura.

Fabric Data Warehouse admite transacciones compatibles con ACID. Cada transacción es atómica, coherente, aislada y duradera (ACID). Todas las operaciones dentro de una sola transacción se ejecutan de manera atómica, ya sea que todas tengan éxito o todas fallen. Si se produce un error en alguna instrucción de la transacción, se revierte toda la transacción.

Transacciones explícitas

Puede modificar los datos almacenados en tablas de un almacén mediante transacciones explícitas para agrupar los cambios.

Por ejemplo, podría realizar inserciones en varias tablas, o en ninguna de ellas si se produce un error. Si cambia los detalles sobre un pedido de compra que afecta a tres tablas, puede agrupar esos cambios en una sola transacción. Eso significa que cuando se consultan esas tablas, o todas tienen los cambios o ninguna los tiene. Las transacciones son una práctica habitual cuando se necesita garantizar la coherencia de los datos en varias tablas.

Puede usar mecanismos de control de sintaxis de T-SQL estándar (BEGIN TRAN, COMMIT TRAN, y ROLLBACK TRAN) para transacciones explícitas. Para obtener más información, vea: - BEGIN TRANSACTION - COMMIT TRANSACTION - ROLLBACK TRANSACTION

Por ejemplo, Fabric Data Warehouse tratarán estos cambios de esquema como una sola unidad atómica:

-- Sample Syntax--- 
BEGIN TRAN; 
ALTER TABLE <table_name> ADD <column_name> <type>; 
ALTER TABLE <table_name> DROP COLUMN <column_name>; 
COMMIT; 

Si se produce un error en alguna instrucción de la transacción, todos los cambios de esquema se revierten automáticamente.

Fabric Data Warehouse admite la ejecución de lo siguiente dentro de una transacción explícita:

• CREATE TABLE
• DROP TABLE
• TRUNCATE TABLE
• CTAS
• sp_rename
• ALTER TABLE agregar columnas anulables
• ALTER TABLE eliminar columnas
• ALTER TABLE agregar o quitar PRIMARY KEY restricciones, UNIQUE, y FOREIGN KEY con la NOT ENFORCED palabra clave
• Varias ALTER TABLE instrucciones
• ALTER TABLE en tablas temporales distribuidas

Compatibilidad con transacciones de consulta entre bases de datos

El almacén en Microsoft Fabric admite transacciones que abarcan almacenes dentro de la misma área de trabajo, incluida la lectura desde el punto de conexión de análisis de SQL del Lakehouse. Para obtener un ejemplo, consulte Escritura de una consulta SQL entre bases de datos.

Comprender el bloqueo y la obstrucción en Fabric Data Warehouse

Fabric Data Warehouse usa el bloqueo de nivel de tabla, independientemente de si una consulta toca una fila o varias. En la tabla siguiente se proporciona una lista de los bloqueos que se usan para diferentes operaciones de T-SQL.

Puede consultar bloqueos mantenidos actualmente con la vista de administración dinámica (DMV) sys.dm_tran_locks.

Para obtener más información sobre los bloqueos, la extensión de bloqueo y la compatibilidad de bloqueos, consulte la Guía de bloqueo de transacciones y control de versiones de fila.

Aislamiento de instantáneas

Fabric Data Warehouse aplica el aislamiento de instantáneas en todas las transacciones. El aislamiento de instantáneas es un nivel de aislamiento basado en filas que proporciona coherencia a nivel de transacción para los datos y usa versiones de fila almacenadas en tempdb para seleccionar las filas que se van a actualizar. La transacción usa las versiones de fila de datos que existen cuando comienza la transacción. Esto garantiza que cada transacción se ejecute en una instantánea coherente de los datos tal como estaba al principio de la transacción.

En el aislamiento de instantáneas, las consultas en la transacción ven la misma versión o instantánea, en función del estado de la base de datos cuando comienza la transacción. En aislamiento de instantáneas, las transacciones que modifican los datos no bloquean las transacciones que leen datos y las transacciones que leen datos no bloquean las transacciones que escriben datos. Este comportamiento optimista y sin bloqueo también reduce significativamente la probabilidad de interbloqueos para transacciones complejas.

Si utiliza T-SQL para cambiar el nivel de aislamiento, el cambio no surte efecto durante la ejecución de la consulta y se aplica el aislamiento de instantáneas.

En aislamiento de instantáneas, los conflictos de escritura-escritura o de actualización son posibles, para obtener más información, consulte Comprender los conflictos de escritura-escritura en Fabric Data Warehouse.

Bloqueos de esquema

Los bloqueos de esquema impiden conflictos en instrucciones DDL, como cambiar el esquema de una tabla mientras las filas se actualizan en una transacción. Tenga en cuenta que las operaciones DDL, como los cambios de esquema y las migraciones, pueden bloquear o ser bloqueadas por cargas de trabajo de lectura activas.

• Durante las operaciones del lenguaje de definición de datos (DDL), el Motor de base de datos usa bloqueos de modificación de esquema (Sch-M). Durante el tiempo en que se mantiene, el Sch-M bloqueo impide todo el acceso simultáneo a la tabla hasta que se libere el bloqueo.
• Durante las operaciones del lenguaje de manipulación de datos (DML), el Motor de base de datos usa bloqueos de estabilidad de esquema (Sch-S). Las operaciones que obtienen bloqueos de Sch-M se ven bloqueadas por los bloqueos de Sch-S. Otras transacciones siguen ejecutándose mientras se compila una consulta, pero las operaciones DDL se bloquean hasta que pueden obtener acceso exclusivo al esquema.
• Las operaciones DDL también adquieren un bloqueo exclusivo (X) en filas en vistas del sistema como sys.tables y sys.objects asociadas a la tabla de destino, mientras dure la transacción. Esto bloquea la ejecución de instrucciones simultáneas SELECT en sys.tables y sys.objects.

Procedimientos recomendados para evitar el bloqueo

• Evite transacciones de larga duración o programe durante períodos de poca actividad o ninguna actividad simultánea.
• Programe las operaciones DDL solo durante las ventanas de mantenimiento para minimizar el bloqueo.
• Aunque las instrucciones DDL se pueden ejecutar dentro de transacciones de usuario explícitas (BEGIN TRAN), deben usarse con precaución en cargas de trabajo simultáneas. Debido al comportamiento de bloqueo, DDL dentro de una transacción puede bloquear operaciones DML o SELECT simultáneas en las tablas afectadas, así como consultas SELECT en vistas de catálogo del sistema como sys.tables o sys.objects. Para supervisar y solucionar posibles conflictos de bloqueo, use sys.dm_tran_locks.
• Supervise bloqueos y conflictos en el almacén.
  • Use sys.dm_tran_locks para inspeccionar los bloqueos actuales.

Comprender los conflictos de escritura-escritura en Fabric Data Warehouse

Los conflictos de escritura simultánea pueden producirse cuando dos transacciones intentan hacer UPDATE, DELETE, MERGE o TRUNCATE a la misma tabla.

Los conflictos de escritura-escritura o los conflictos de actualización son posibles en el nivel de tabla, porque Fabric Data Warehouse usa el bloqueo a nivel de tabla. Si dos transacciones intentan modificar filas diferentes en la misma tabla, todavía pueden entrar en conflicto.

Los conflictos de escritura simultánea surgen principalmente de dos escenarios.

• Conflictos de carga de trabajo provocados por el usuario
  • Varios usuarios o procesos modifican simultáneamente la misma tabla.
  • Puede producirse en canalizaciones de ETL, actualizaciones por lotes o transacciones superpuestas.
• Conflictos provocados por el sistema
  • Tareas del sistema en segundo plano, como la compactación automática de datos, reescriben archivos de baja calidad.
  • Estos pueden entrar en conflicto con las transacciones de usuario, aunque la preempción de compactación de datos evita activamente los conflictos de escritura-escritura de este tipo.

Si se produce un conflicto de escritura y escritura, es posible que vea mensajes de error como:

• Error 24556: transacción de aislamiento de instantánea anulada debido a un conflicto de actualización. El uso del aislamiento de instantáneas para acceder directa o indirectamente a la tabla "%.*ls" en la base de datos "%.*ls" puede provocar conflictos de actualización si otra transacción simultánea ha eliminado o actualizado filas de esa tabla. Vuelva a repetir la transacción.
• Error 24706: transacción de aislamiento de instantánea abortada debido a un conflicto de actualización. No se puede usar el aislamiento de instantáneas para acceder a la tabla "%.*ls" directa o indirectamente en la base de datos "%.*ls" para actualizar, eliminar o insertar la fila modificada o eliminada por otra transacción. Vuelva a intentar la transacción.

Si encuentra estos mensajes de error, una o varias transacciones se realizaron correctamente y se produjo un error en una o varias transacciones en conflicto. Vuelva a intentar las transacciones que fallaron.

Prácticas recomendadas para evitar conflictos de escritura-escritura

Para evitar conflictos de escritura simultánea:

• Evite las operaciones simultáneas UPDATE, DELETE, MERGE en la misma tabla.
  • Preste atención a las operaciones UPDATE, DELETE, MERGE dentro de transacciones de paso múltiple.
• Use Lógica de reintento en todas las aplicaciones y consultas.
  • Implemente la lógica de reintento en procedimientos almacenados y canalizaciones de ETL.
  • Agregue lógica de reintento con retraso en aplicaciones o canalizaciones para manejar conflictos transitorios.
    • Utiliza el retroceso exponencial para evitar una avalancha de reintentos que pueden empeorar las interrupciones transitorias de la red. Para obtener más información, vea Patrón de reintentos.
• Los conflictos de escritura-escritura con el servicio de compactación de datos en segundo plano de Fabric Data Warehouse son posibles, pero normalmente se evitan gracias a la característica de Preempción de compactación de datos.

Bloqueo de archivos de tipo tabla y parquet

Los conflictos de dos o más transacciones simultáneas que actualizan una o varias filas de una tabla se evalúan al final de la transacción. La primera transacción para confirmar se completa correctamente y las demás transacciones se revierten con un error devuelto. Estos conflictos se evalúan a nivel de tabla y no a nivel de archivo parquet individual.

Las instrucciones INSERT siempre crean nuevos archivos parquet, lo que implica menos conflictos con otras transacciones, excepto con DDL, ya que el esquema de la tabla podría estar cambiando.

Limitaciones

• No se admiten transacciones distribuidas, por ejemplo, BEGIN DISTRIBUTED TRANSACTION.
• No se admiten puntos de guardado.
• No se admiten transacciones con nombre.
• No se admiten transacciones marcadas.
• En este momento, hay una funcionalidad limitada de T-SQL en el almacenamiento. Consulte T-SQL surface area in Fabric Data Warehouse para obtener una lista de comandos T-SQL que no están disponibles actualmente.
• Si una transacción tiene inserción de datos en una tabla vacía y emite una instrucción SELECT antes de revertirla, las estadísticas generadas automáticamente pueden reflejar los datos no confirmados, lo que provoca estadísticas inexactas. Las estadísticas inexactas pueden dar lugar a planes de consulta no optimizados y tiempos de ejecución. Si revierte una transacción con SELECT después de una instrucción INSERT grande, actualice las estadísticas de las columnas mencionadas en su instrucción SELECT.

Contenido relacionado

• Consulta el punto de conexión del análisis SQL o el almacén de datos en Microsoft Fabric
• Tables