Condividi tramite

Transazioni in Fabric Data Warehouse

Si 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 eseguire il commit degli inserimenti in più tabelle o 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

Supporto delle transazioni di query tra database

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

Comprendere il blocco e il bloccaggio in Fabric Data Warehouse

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

Tipo di istruzione Blocco preso
DML
SELECT Schema-Stability (Sch-S)
INSERT … Finalità esclusiva (IX)
DELETE Finalità esclusiva (IX)
UPDATE Finalità esclusiva (IX)
MERGE Finalità esclusiva (IX)
COPY INTO Finalità esclusiva (IX)
DDL
CREATE TABLE Schema-Modification (Sch-M)
ALTER TABLE Modifica Schema (Sch-M)
DROP TABLE Modifica dello Schema (Sch-M)
TRUNCATE TABLE Modifica dello Schema (Sch-M)
CREATE TABLE AS SELECT Schema-Modification (Sch-M)
CREA TABELLA COME CLONE DI Schema-Modification (Sch-M)

È possibile eseguire query sui blocchi attualmente mantenuti con il sys.dm_tran_locks DMV (Dynamic Management View).

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-scrittura o di aggiornamento. Per ulteriori 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.
  • 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.

Comprendere i 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.

Annotazioni

Anche quando le transazioni generano solo modifiche di sola accodamento, vengono comunque create un conflitto di scrittura.Even when MERGE transactions only result in append-only changes, they are still create a write-write conflict. Quando MERGE la transazione influisce su righe diverse rispetto ad altre transazioni DML simultanee, può verificarsi questo errore se MERGE non è la prima transazione di cui eseguire il commit: "Transazione di isolamento dello snapshot interrotta a causa di un conflitto di aggiornamento".

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 con il servizio di compattazione dei dati in background di Fabric Data Warehouse sono possibili, ma in genere vengono impediti dalla funzione di pre-emption 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 di cui eseguire il commit viene completata correttamente e viene eseguito il rollback delle altre transazioni con un errore restituito. Questi conflitti vengono valutati a livello di tabella e non a livello di singolo file Parquet.

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

Limiti

  • Le transazioni distribuite non sono supportate, ad esempio BEGIN DISTRIBUTED TRANSACTION.
  • ALTER TABLE non è supportato all'interno di una transazione esplicita.
  • 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. Vedere Superficie T-SQL in Fabric Data Warehouse per un elenco di comandi T-SQL attualmente non disponibili.
  • 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 indicate in SELECT.

Contenuto correlato

  • Last updated on