Transacciones en Fabric Data Warehouse

Se aplica a:✅ punto de conexión de análisis SQL y Almacén de 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 confirmar 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

Compatibilidad con transacciones de consulta entre bases de datos

Warehouse en Microsoft Fabric admite transacciones que abarcan almacenes que se encuentran dentro del mismo área de trabajo, incluida la lectura del punto de conexión de SQL Analytics de Lakehouse. Para obtener un ejemplo, consulte Escritura de una consulta SQL entre bases de datos.

Entender el bloqueo y los conflictos 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.

Tipo de instrucción	Bloqueo empleado
DML
SELECT	Schema-Stability (Sch-S)
INSERT	Intención exclusiva (IX)
DELETE	Intención exclusiva (IX)
UPDATE	Intención exclusiva (IX)
FUSIONAR	Intención exclusiva (IX)
COPIAR EN	Intención exclusiva (IX)
DDL
CREATE TABLE	Modificación de Esquema (Sch-M)
ALTER TABLE	Modificación de Esquema (Sch-M)
DROP TABLE	Schema-Modification (Sch-M)
TRUNCAR TABLA	Modificación del Esquema (Sch-M)
CREATE TABLE AS SELECT	Modificación de esquema (Sch-M)
CREAR TABLA COMO CLON DE	Modificación de Esquema (Sch-M)

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 el aislamiento de instantáneas, los conflictos de escritura-escritura o de actualización son posibles, para obtener más información, consulte Entender 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.
• Evite colocar instrucciones DDL dentro de transacciones de usuario explícitas (BEGIN TRAN). Las transacciones de larga duración que modifican tablas pueden provocar problemas de bloqueo para otras operaciones DML y consultas, tanto en las tablas de usuario como en las vistas de catálogo del sistema como sys.tables. 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.
• Fabric Data Warehouse admite algunas instrucciones DDL dentro de transacciones definidas por el usuario, pero no se recomiendan en transacciones de larga duración. Dentro de las transacciones, las instrucciones DDL pueden bloquear transacciones simultáneas o provocar conflictos de escritura.

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 concurrentes o los conflictos de actualización son posibles en el nivel de tabla debido al uso de bloqueo a nivel de tabla por Fabric Data Warehouse. 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 tener acceso 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.

Nota:

Incluso cuando MERGE las transacciones solo producen cambios que solo añaden, todavía crean un conflicto de escritura-escritura. Cuando la transacción de MERGE afecta a filas diferentes de otras transacciones DML simultáneas, puede encontrarse con este error si MERGE no es la primera transacción en confirmar: "Transacción de aislamiento por instantánea anulada debido a un conflicto de actualización".

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 con el servicio de compactación de datos en segundo plano de Fabric Data Warehouse son posibles, pero normalmente se evitan mediante 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 en el nivel de tabla y no en el 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.
• ALTER TABLE no se admite dentro de una transacción explícita.
• 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 el Área de superficie de T-SQL en Fabric Data Warehouse para obtener una lista de comandos de 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

• Consultar el punto de conexión de análisis SQL o Warehouse en Microsoft Fabric
• Tables