Transazioni in Fabric Data Warehouse

Applica a:✅ endpoint di analisi SQL e Warehouse in Microsoft Fabric

Analogamente al comportamento in SQL Server, le transazioni consentono di controllare il commit o il rollback delle query di lettura e scrittura.

Fabric Data Warehouse supporta transazioni conformi a ACID. Ogni transazione è atomica, coerente, isolata e durevole (ACID). Tutte le operazioni all'interno di una singola transazione vengono trattate in modo atomico, tutte le operazioni hanno esito positivo o negativo. Se un'istruzione all'interno della transazione fallisce, l'intera transazione viene annullata.

Transazioni esplicite

È possibile modificare i dati archiviati nelle tabelle di un warehouse usando transazioni esplicite per raggruppare le modifiche.

Ad esempio, è possibile completare il commit degli inserimenti in più tabelle, oppure non completarlo in nessuna delle tabelle se si verifica un errore. Se si modificano i dettagli relativi a un ordine di acquisto che influisce su tre tabelle, è possibile raggruppare tali modifiche in una singola transazione. Ciò significa che quando vengono eseguite delle query su tali tabelle, o tutte hanno le modifiche oppure nessuna. Le transazioni sono una procedura comune per quando è necessario assicurarsi che i dati siano coerenti tra più tabelle.

È possibile usare meccanismi di controllo della sintassi T-SQL standard (BEGIN TRAN, COMMIT TRANe ROLLBACK TRAN) per le transazioni esplicite. Per altre informazioni, vedere: BEGIN TRANSACTION - COMMIT TRANSACTION - ROLLBACK TRANSACTION

Ad esempio, Fabric Data Warehouse considererà queste modifiche dello schema come una singola unità atomica:

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

Se un'istruzione nella transazione ha esito negativo, viene eseguito automaticamente il rollback di tutte le modifiche dello schema.

Fabric Data Warehouse supporta l'esecuzione di quanto segue all'interno di una transazione esplicita:

• ALTER TABLE aggiungere colonne annullabili
• ALTER TABLE eliminare colonne
• ALTER TABLE aggiungere o eliminare PRIMARY KEYvincoli , UNIQUEe FOREIGN KEY con la NOT ENFORCED parola chiave
• Diverse ALTER TABLE istruzioni
• ALTER TABLE nelle tabelle temporanee distribuite

Supporto delle transazioni di query tra database

Il magazzino in Microsoft Fabric supporta transazioni che si estendono su più magazzini all'interno della stessa area di lavoro, inclusa la lettura dall'endpoint SQL di analisi del Lakehouse. Per un esempio, vedere Scrivere una query SQL tra database.

Comprendere il blocco e il blocco in Fabric Data Warehouse

Fabric Data Warehouse utilizza il locking a livello di tabella, indipendentemente dal fatto che una query tocchi una riga o molte righe. La tabella seguente fornisce un elenco dei lock utilizzati per diverse operazioni T-SQL.

È possibile eseguire query sui blocchi attualmente mantenuti con la vista di gestione dinamica (DMV) sys.dm_tran_locks.

Per altre informazioni sui blocchi, l'escalation dei blocchi e la compatibilità dei blocchi, vedere Guida al blocco delle transazioni e al controllo delle versioni delle righe.

Isolamento dello snapshot

Fabric Data Warehouse applica l'isolamento dello snapshot a tutte le transazioni. L'isolamento dello snapshot è un livello di isolamento basato su righe che fornisce coerenza a livello di transazione per i dati e usa le versioni di riga archiviate in tempdb per selezionare le righe da aggiornare. La transazione utilizza le versioni delle righe di dati esistenti all'inizio della transazione. In questo modo ogni transazione opera su uno snapshot coerente dei dati così come esisteva all'inizio della transazione.

In isolamento dello snapshot, le query di una transazione osservano la stessa versione, ovvero lo snapshot, in base allo stato del database all'inizio della transazione. Nell'isolamento dello snapshot, le transazioni che modificano i dati non bloccano le transazioni che leggono i dati e le transazioni che leggono i dati non bloccano le transazioni che scrivono dati. Questo comportamento ottimistico e non bloccante riduce anche significativamente la probabilità di deadlock per transazioni complesse.

Se si usa T-SQL per modificare il livello di isolamento, la modifica viene ignorata in fase di esecuzione della query e viene applicato l'isolamento dello snapshot.

Nell'isolamento dello snapshot sono possibili conflitti di scrittura o aggiornamento, per altre informazioni, vedere Informazioni sui conflitti di scrittura/scrittura in Fabric Data Warehouse.

Blocchi dello schema

Blocchi di schema impediscono conflitti nelle istruzioni DDL, come la modifica dello schema di una tabella mentre le righe vengono aggiornate in una transazione. Tenere presente che le operazioni DDL, ad esempio le modifiche dello schema e le migrazioni, possono bloccarsi o bloccarsi da carichi di lavoro di lettura attivi.

• Durante le operazioni DDL (Data Definition Language), il motore di database usa blocchi di modifica dello schema (Sch-M). Durante il periodo di attesa, il Sch-M blocco impedisce l'accesso simultaneo alla tabella fino al rilascio del blocco.
• Durante le operazioni DML (Data Manipulation Language), il motore di database usa blocchi di stabilità dello schema (Sch-S). Le operazioni che acquisiscono Sch-M blocchi vengono bloccate dai Sch-S blocchi. Altre transazioni continuano a essere eseguite durante la compilazione di una query, ma le operazioni DDL vengono bloccate fino a quando non possono ottenere l'accesso esclusivo allo schema.
• Le operazioni DDL acquisiscono anche un blocco esclusivo (X) sulle righe nelle viste di sistema come sys.tables e sys.objects associate alla tabella di destinazione, per tutta la durata della transazione. Questo blocca le istruzioni simultanee SELECT in sys.tables e sys.objects.

Procedure consigliate per evitare il blocco

• Evitare transazioni a esecuzione prolungata o pianificarle durante periodi di attività concorrente bassa o assente.
• Pianificare le operazioni DDL solo durante le finestre di manutenzione per ridurre al minimo il blocco.
• Evitare di inserire istruzioni DDL all'interno di transazioni utente esplicite (BEGIN TRAN). Le transazioni a esecuzione prolungata che modificano le tabelle possono causare problemi di blocco per altre operazioni DML e SELECT query, sia nelle tabelle utente che nelle viste del catalogo di sistema, come sys.tables. Per monitorare e risolvere potenziali conflitti di blocco, usare sys.dm_tran_locks.
• Monitorare i blocchi e i conflitti nel magazzino.
  • Usare sys.dm_tran_locks per ispezionare i blocchi correnti.
• Fabric Data Warehouse supporta alcune istruzioni DDL all'interno di transazioni definite dall'utente, ma non sono consigliate nelle transazioni a esecuzione prolungata. All'interno delle transazioni, le istruzioni DDL possono bloccare transazioni simultanee o causare conflitti di scrittura.Inside transactions, DDL statements can block concurrent transactions or cause write-write conflicts.

Informazioni sui conflitti di scrittura/scrittura in Fabric Data Warehouse

I conflitti di scrittura/scrittura possono verificarsi quando due transazioni tentano di UPDATE, DELETE, MERGE o TRUNCATE sulla stessa tabella.

I conflitti di scrittura/scrittura o i conflitti di aggiornamento sono possibili a livello di tabella, poiché Fabric Data Warehouse usa il blocco a livello di tabella. Se due transazioni tentano di modificare righe diverse nella stessa tabella, possono comunque essere in conflitto.

I conflitti di scrittura-scrittura si verificano principalmente in due scenari:

• Conflitti di carico di lavoro indotti dall'utente
  • Più utenti o processi modificano simultaneamente la stessa tabella.
  • Può verificarsi nelle pipeline ETL, negli aggiornamenti batch o nelle transazioni sovrapposte.
• Conflitti indotti dal sistema
  • Le attività di sistema in background, ad esempio la compattazione automatica dei dati, riscrivono i file con scarsa qualità.
  • Questi possono entrare in conflitto con le transazioni degli utenti, anche se la prevenzione della compattazione dei dati impedisce attivamente i conflitti di scrittura tra utenti di questo tipo.

Se si verifica un conflitto di scrittura/scrittura, potrebbero essere visualizzati messaggi di errore come:

• Errore 24556: transazione di isolamento dello snapshot interrotta a causa di un conflitto di aggiornamento. L'uso dell'isolamento dello snapshot per accedere alla tabella '%.*ls' direttamente o indirettamente nel database '%.*ls' può causare conflitti di aggiornamento se le righe della tabella sono state eliminate o aggiornate da un'altra transazione simultanea. Ripetere la transazione.
• Errore 24706: transazione di isolamento dello snapshot interrotta a causa di un conflitto di aggiornamento. Non è possibile utilizzare l'isolamento dello snapshot per accedere alla tabella '%.*ls' direttamente o indirettamente nel database '%.*ls' per aggiornare, eliminare o inserire la riga modificata o eliminata da un'altra transazione. Ripetere la transazione.

Se si verificano questi messaggi di errore, una o più transazioni riuscite e una o più transazioni in conflitto hanno avuto esito negativo. Ripetere le transazioni non riuscite.

Procedure consigliate per evitare conflitti di scrittura/scrittura

Per evitare conflitti di scrittura/scrittura:

• Evitare operazioni simultanee UPDATE, DELETE, MERGE nella stessa tabella.
  • Prestare attenzione alle UPDATE operazioni DELETEMERGE all'interno di transazioni a più fasi.
• Usare la logica di ripetizione dei tentativi in tutte le applicazioni e query.
  • Implementare la logica di ripetizione dei tentativi nelle stored procedure e nelle pipeline ETL.
  • Aggiungere la logica di tentativi ripetuti con ritardo nelle pipeline o nelle app per gestire i conflitti temporanei.
    • Usare il backoff esponenziale per evitare tempeste di tentativi ripetuti che peggiorano le interruzioni temporanee della rete. Per altre informazioni, vedere Modello di ripetizione dei tentativi.
• I conflitti di scrittura/scrittura con il servizio di compattazione dei dati di background del Fabric Data Warehouse sono possibili, ma in genere vengono evitati dalla funzionalità di preemzione della compattazione dei dati.

Blocco di file di tabella e parquet

I conflitti di due o più transazioni simultanee che aggiornano una o più righe in una tabella vengono valutati alla fine della transazione. La prima transazione che esegue il commit si completa con successo, mentre le altre transazioni vengono annullate e viene restituito un errore. Questi conflitti vengono valutati a livello di tabella e non a livello di singolo file Parquet.

Le istruzioni INSERT creano sempre nuovi file Parquet, il che comporta un minor numero di conflitti con altre transazioni, ad eccezione delle istruzioni DDL, poiché lo schema della tabella potrebbe cambiare.

Limiti

• Le transazioni distribuite non sono supportate, ad esempio BEGIN DISTRIBUTED TRANSACTION.
• I punti di salvataggio non sono supportati.
• Le transazioni nominate non sono supportate.
• Le transazioni marcate non sono supportate.
• In questo momento, è disponibile una funzionalità T-SQL limitata nel warehouse. Per un elenco di comandi T-SQL attualmente non disponibili, vedere l'ambito di utilizzo T-SQL in Fabric Data Warehouse.
• Se una transazione include l'inserimento di dati in una tabella vuota ed esegue un'istruzione SELECT prima del rollback, le statistiche generate automaticamente possono comunque riflettere i dati di cui non è stato eseguito il commit, causando statistiche non accurate. Le statistiche imprecise possono causare piani di query e tempi di esecuzione non ottimizzati. Se si esegue il rollback di una transazione con dei SELECT dopo un'operazione INSERT di grandi dimensioni, aggiornare le statistiche per le colonne menzionate nei vostri SELECT.

Contenuto correlato

• Interroga l'endpoint di analisi SQL o il magazzino dati in Microsoft Fabric
• Tables