Sdílet prostřednictvím

Transakce v datovém skladu Fabric

Platí pro:✅ Koncový bod sql Analytics a sklad v Microsoft Fabric

Podobně jako jejich chování v SQL Serveru umožňují transakce řídit potvrzení nebo vrácení zpět čtení a zápisu dotazů.

Datový sklad Fabric podporuje transakce kompatibilní s ACID. Každá transakce je atomická, konzistentní, izolovaná a odolná (ACID). Všechny operace v rámci jedné transakce jsou považovány za atomické, všechny se podaří nebo všechny selžou. Pokud jakákoliv deklarace v transakci selže, celá transakce se vrátí zpět.

Explicitní transakce

Data uložená v tabulkách ve skladu můžete upravit pomocí explicitních transakcí pro seskupení změn.

Můžete například potvrdit vložení do více tabulek nebo žádná z tabulek, pokud dojde k chybě. Pokud měníte podrobnosti o nákupní objednávce, která ovlivňuje tři tabulky, můžete tyto změny seskupit do jedné transakce. To znamená, že když jsou tyto tabulky dotazovány, všechny mají buď změny, nebo žádné z nich. Transakce jsou běžným postupem, kdy potřebujete zajistit, aby vaše data byla konzistentní napříč více tabulkami.

Pro explicitní transakce můžete použít standardní mechanismy řízení syntaxe T-SQL (BEGIN TRAN, COMMIT TRANa ROLLBACK TRAN) . Další informace naleznete v tématu: - BEGIN TRANSACTION - COMMIT TRANSACTION -

Podpora transakcí mezi databázemi

Sklad v Microsoft Fabric podporuje transakce, které probíhají mezi sklady ve stejném pracovním prostoru, včetně čtení z SQL analytického koncového bodu Lakehouse. Příklad najdete v tématu Zápis dotazu SQL napříč databázemi.

Pochopení zamykání a blokování ve Fabric Data Warehouse

Datový sklad Fabric používá zamykání na úrovni tabulky bez ohledu na to, jestli se dotaz dotkne jednoho řádku nebo mnoha řádků. Následující tabulka obsahuje seznam zámků používaných pro různé operace T-SQL.

Typ příkazu Uzamčení pořízené
DML
SELECT Schema-Stability (Sch-S)
INSERT Výhradní záměr (IX)
DELETE Výhradní záměr (IX)
UPDATE Výhradní záměr (IX)
MERGE Výhradní záměr (IX)
KOPÍROVAT DO Výhradní záměr (IX)
DDL
CREATE TABLE Schema-Modifikace (Sch-M)
ALTER TABLE Úprava schématu (Sch-M)
DROP TABLE (vymazat tabulku) Schema-Modification (Sch-M)
TRUNCATE TABLE Schema-Modification (Sch-M)
VYTVOŘIT TABULKU JAKO VÝBĚR Úprava schématu (Sch-M)
VYTVOŘENÍ TABULKY JAKO KLON Schema-Modification (Sch-M)

Zámky aktuálně uchovávané pomocí zobrazení dynamické správy (DMV) můžete dotazovat sys.dm_tran_locks.

Další informace o zámkech, eskalaci zámku a kompatibilitě zámků naleznete v průvodci zamykáním transakcí a verzování řádků.

Izolace snímků

Fabric datový sklad vynucuje izolaci snímků u všech transakcí. Izolace snímku je úroveň izolace na základě řádků, která zajišťuje konzistenci dat na úrovni transakcí a používá verze řádků uložené v tempdb k výběru řádků k aktualizaci. Transakce používá verze datového řádku, které existují při zahájení transakce. Tím se zajistí, že každá transakce funguje na konzistentním snímku dat, jak existovalo na začátku transakce.

V režimu izolace snímků dotazy prováděné v rámci transakce vidí stejnou verzi nebo snímek, který je založen na stavu databáze v okamžiku zahájení transakce. Při izolaci snímků transakce, které upravují data, neblokují transakce, které čtou data, a naopak transakce, které čtou data, neblokují transakce, které zapisují data. Toto optimistické, neblokující chování také výrazně snižuje pravděpodobnost zablokování u složitých transakcí.

Pokud ke změně úrovně izolace použijete T-SQL, změna se při provádění dotazu ignoruje a použije se izolace snímků.

V izolaci snímků jsou možné konflikty zápisu nebo aktualizace, kde najdete další informace v tématu Vysvětlení konfliktů zápisu a zápisu v datovém skladu Fabric.

Zámky schématu

Zámky schématu brání konfliktům u příkazů DDL, jako je změna schématu tabulky při aktualizaci řádků v transakci. Mějte na paměti, že operace DDL, jako jsou změny schématu a migrace, můžou blokovat nebo být blokovány aktivními čtecími úlohami.

  • Během operací jazyka DDL (Data Definition Language) používá databázový stroj zámky úprav schématu (Sch-M). Po dobu, kdy je držen, Sch-M zámek zabrání veškerému souběžnému přístupu k tabulce, dokud není zámek uvolněn.
  • Během operací jazyka DML (Data Manipulat Language) používá databázový stroj zámky stability schématu (Sch-S). Operace, které získávají Sch-M zámky, jsou blokovány Sch-S zámky. Ostatní transakce se budou dál spouštět během kompilace dotazu, ale operace DDL se zablokují, dokud nebudou moct získat výhradní přístup ke schématu.
  • Operace DDL také získávají exkluzivní zámek na X řádcích v systémových zobrazeních, jako jsou sys.tables a sys.objects, které jsou přidružené k cílové tabulce, po dobu trvání transakce. Tím se zablokují současné SELECT příkazy na sys.tables a sys.objects.

Osvědčené postupy pro zabránění blokování

  • Vyhněte se dlouhotrvajícím transakcím nebo plánování během období s nízkou nebo žádnou souběžnou aktivitou.
  • Naplánujte operace DDL pouze během časových období údržby, abyste minimalizovali blokování.
  • Vyhněte se umísťování příkazů DDL do explicitních uživatelských transakcí (BEGIN TRAN). Dlouhotrvající transakce, které upravují tabulky, můžou způsobit problémy s blokováním jiných operací a SELECT dotazů DML, a to jak v uživatelských tabulkách, tak v zobrazení systémového katalogu, jako je sys.tables. Chcete-li monitorovat a řešit potenciální konflikty zámků, použijte sys.dm_tran_locks.
  • Monitorujte zámky a konflikty ve skladu.
  • Datový sklad Fabric podporuje některé příkazy DDL uvnitř uživatelem definovaných transakcí, ale nedoporučuje se v dlouhotrvajících transakcích. Uvnitř transakcí můžou příkazy DDL blokovat souběžné transakce nebo způsobit konflikty při zápisu.

Porozumět konfliktům při současném zápisu ve Fabric Data Warehouse

Konflikty při souběžném zápisu mohou nastat, když se dvě transakce pokusí o UPDATE, DELETE, MERGE nebo TRUNCATE stejnou tabulku.

Konflikty zápisu nebo konflikty aktualizací jsou možné na úrovni tabulky, protože Fabric Data Warehouse používá zamykání na úrovni tabulky. Pokud se dvě transakce pokusí upravit různé řádky ve stejné tabulce, mohou být stále v konfliktu.

Konflikty zápisu většinou vznikají ze dvou scénářů:

  • Konflikty úloh vyvolané uživatelem
    • Stejnou tabulku současně upravuje více uživatelů nebo procesů.
    • Může nastat v kanálech ETL, dávkových aktualizacích nebo překrývajících se transakcích.
  • Konflikty vyvolané systémem
    • Úlohy systému na pozadí, jako je automatické komprimace dat, přepisují soubory s nízkou kvalitou.
    • To může být v konfliktu s uživatelskými transakcemi, ačkoli preempce komprimace dat aktivně zabraňuje konfliktům zápisu a zápisu tohoto typu.

Pokud dojde ke konfliktu při souběžném zápisu, mohou se zobrazit chybové zprávy, například:

  • Chyba 24556: Transakce izolace snímku byla přerušena kvůli konfliktu při aktualizaci. Použití izolace snímků pro přístup k tabulce%.*ls přímo nebo nepřímo v databázi%.*ls může způsobit konflikty aktualizací, pokud byly řádky v této tabulce odstraněny nebo aktualizovány jinou souběžnou transakcí. Zkuste transakci zopakovat.
  • Chyba 24706: Transakce s izolací snímků byla přerušena kvůli konfliktu aktualizace. Izolaci snímků nelze použít pro přístup k tabulce%.*ls přímo nebo nepřímo v databázi%.*ls k aktualizaci, odstranění nebo vložení řádku, který byl změněn nebo odstraněn jinou transakcí. Zkuste transakci zopakovat.

Pokud narazíte na tyto chybové zprávy, jedna nebo více transakcí byla úspěšná a jedna nebo více konfliktních transakcí selhala. Zkuste transakce, které selhaly.

Poznámka:

I když transakce MERGE vedou pouze ke změnám typu append-only, stále vytvářejí konflikt zápisu. Pokud MERGE transakce ovlivňuje různé řádky než které jsou ovlivněny jinými souběžnými transakcemi DML, může dojít k této chybě, pokud transakce MERGE není první, která potvrdí: Transakce při izolaci snímku byla přerušena kvůli konfliktu aktualizace.

Osvědčené postupy pro zabránění konfliktům při zápisu

Aby nedocházelo ke konfliktům při současném zápisu:

  • Vyhněte se souběžným UPDATE, DELETE a MERGE operacím ve stejné tabulce.
    • Věnujte pečlivou pozornost operacím UPDATEDELETEMERGE v rámci vícestupňových transakcí.
  • Použijte logiku opakování ve všech aplikacích a dotazech.
    • Implementujte logiku opakování v uložených procedurách a kanálech ETL.
    • Přidejte opakovací logiku se zpožděním do datových toků nebo aplikací pro řešení přechodných konfliktů.
      • Pomocí exponenciálního navýšení čekací doby se vyhnete bouřím pokusů, které se zhoršují z důvodu přechodných přerušení sítě. Další informace najdete v tématu Vzor opakování.
  • Konflikty zápisu s pozadí službou komprimace dat v datovém skladu Fabric jsou možné, ale obvykle jim brání funkce preempce komprimace dat.

Blokování tabulek a souborů Parquet

Konflikty ze dvou nebo více souběžných transakcí, které aktualizují jeden nebo více řádků v tabulce, se vyhodnocují na konci transakce. První transakce, která se úspěšně potvrdí, a ostatní transakce se vrátí zpět s vrácenou chybou. Tyto konflikty se vyhodnocují na úrovni tabulky, nikoli na úrovni jednotlivých souborů Parquet.

Příkazy INSERT vždy vytvářejí nové soubory parquet, což znamená, že méně konfliktů s jinými transakcemi s výjimkou DDL, protože schéma tabulky může být změněno.

Omezení

  • Distribuované transakce nejsou například BEGIN DISTRIBUTED TRANSACTIONpodporovány .
  • ALTER TABLE není podporován v rámci explicitní transakce.
  • Body uložení nejsou podporovány.
  • Pojmenované transakce nejsou podporovány.
  • Označené transakce nejsou podporovány.
  • V tuto chvíli je ve skladu omezené funkce T-SQL. Seznam příkazů T-SQL, které aktuálně nejsou k dispozici, najdete v části Plocha T-SQL v Datovém skladu fabric .
  • Pokud transakce obsahuje vložení dat do prázdné tabulky a před vrácením zpět vydá select, automaticky generované statistiky můžou stále odrážet nepotvrzená data, což způsobuje nepřesné statistiky. Nepřesné statistiky můžou vést k neoptimalizovaným plánům dotazů a časům provádění. Pokud vrátíte transakci se SELECTs po velkém INSERT, aktualizujte statistiky pro sloupce uvedené v select.

Související obsah

  • Last updated on