Stálost pro tabulky optimalizované pro paměť

platí pro:SQL Server

In-Memory OLTP poskytuje plnou odolnost pro tabulky optimalizované pro paměť. Pokud transakce, která změnila paměťově optimalizovanou tabulku a byla potvrzena, SQL Server (tak jako u tabulek založených na disku) zaručuje, že změny jsou trvalé (přežijí restartování databáze), za předpokladu, že je k dispozici základní úložiště. Existují dvě klíčové komponenty odolnosti: protokolování transakcí a trvalé změny dat v úložišti na disku.

Podrobnosti o omezení velikosti trvalých tabulek najdete v tématu Odhad požadavků na paměť pro tabulky Memory-Optimized.

Transakční protokol

Všechny změny tabulek založené na disku nebo trvalých tabulek optimalizovaných pro paměť se zaznamenávají v jednom nebo více záznamech transakčního protokolu. Při potvrzení transakce SQL Server zapíše záznamy protokolu přidružené k transakci na disk před komunikací s aplikací nebo uživatelskou relací, že transakce potvrzena. To zaručuje, že změny provedené transakcí jsou trvalé. Transakční protokol pro tabulky optimalizované pro paměť je plně integrovaný se stejným datovým proudem protokolu používaným tabulkami založenými na disku. Tato integrace umožňuje zachovat stávající operace zálohování, obnovu a obnovení transakčních protokolů, které fungují bez nutnosti dalších kroků. Vzhledem k tomu, že In-Memory OLTP může výrazně zvýšit propustnost transakcí vaší úlohy, může se vstupně-výstupní operace protokolu stát kritickým bodem výkonu. Pokud chcete tuto zvýšenou propustnost udržet, zajistěte, aby subsystém vstupně-výstupních operací protokolu zvládl zvýšené zatížení.

Datové a rozdílové soubory

Data v tabulkách optimalizovaných pro paměť jsou uložena jako řádky dat volného tvaru ve struktuře dat haldy v paměti a jsou propojeny prostřednictvím jednoho nebo více indexů v paměti. Pro řádky dat neexistují žádné struktury stránek, například pro tabulky založené na disku. V rámci dlouhodobého uchovávání dat a umožnění zkrácení transakčního logu jsou operace s paměťově optimalizovanými tabulkami uloženy v sadě datových a delta souborů. Tyto soubory se generují na základě transakčního protokolu pomocí asynchronního procesu na pozadí. Data a rozdílové soubory jsou umístěny v jednom nebo více kontejnerech (pomocí stejného mechanismu používaného pro data FILESTREAM). Tyto kontejnery jsou součástí skupiny souborů optimalizované pro paměť.

Data se do těchto souborů zapisují přísně sekvenčním způsobem, což minimalizuje latenci disku pro rotující média. K distribuci vstupně-výstupní aktivity můžete použít více kontejnerů na různých discích. Data a rozdílové soubory umístěné v několika kontejnerech na různých discích zvyšují výkon obnovy databáze, když jsou údaje čteny z těchto souborů na disku do paměti.

Uživatelské transakce nemají přímý přístup k datům a rozdílovým souborům. Všechna čtení a zápisy dat používají datové struktury v paměti.

Datový soubor

Datový soubor obsahuje řádky z jedné nebo více tabulek optimalizovaných pro paměť, které byly vloženy více transakcemi jako součást operací INSERT nebo UPDATE. Jeden řádek může být například z tabulky T1 optimalizované pro paměť a další řádek může být z tabulky T2 optimalizované pro paměť. Řádky jsou připojeny k datovému souboru v pořadí transakcí v transakčním protokolu a umožňují sekvenční přístup k datům. To umožňuje v porovnání s náhodnými vstupně-výstupními operacemi řádově lepší propustnost.

Po zaplnění datového souboru se řádky vložené novými transakcemi ukládají do jiného datového souboru. V průběhu času jsou řádky z tabulek optimalizovaných pro odolnou paměť uloženy v jednom z více datových souborů a každý datový soubor obsahující řádky tvoří nesouvislý, ale souvislý rozsah transakcí. Například datový soubor s časovým razítkem potvrzení transakce v rozsahu (100, 200) obsahuje všechny řádky vložené transakcemi, které mají časové razítko potvrzení větší než 100 a menší nebo rovno 200. Časové razítko potvrzení je monotonicky rostoucí číslo přiřazené transakci, když je připraveno k potvrzení. Každá transakce má jedinečné časové razítko potvrzení.

Když je řádek odstraněn nebo aktualizován, v datovém souboru se fyzicky nemění ani neodstraňuje, ale smazané řádky jsou sledované v jiném typu souboru, souboru delta. Operace aktualizace se zpracovávají jako řazená kolekce operací odstranění a vkládání pro každý řádek. Tím se v datovém souboru eliminují náhodné vstupně-výstupní operace.

Velikost: Každý datový soubor má velikost přibližně 128 MB pro počítače s pamětí větší než 16 GB a 16 MB pro počítače s méně než nebo rovnou 16 GB. V SQL Serveru 2016 (13.x) může SQL Server používat rozšířený režim kontrolních bodů, pokud zjistí, že subsystém úložiště je dostatečně rychlý. V režimu velkých kontrolních bodů mají datové soubory velikost 1 GB. To umožňuje vyšší efektivitu subsystému úložiště pro úlohy s vysokou propustností.

Rozdílový soubor

Každý datový soubor je spárován s rozdílovým souborem, který má stejný rozsah transakcí a sleduje odstraněné řádky vložené transakcemi v rozsahu transakcí. Tento datový soubor a rozdílový soubor se označují jako párový soubor kontrolního bodu (CFP) a je jednotkou pro přidělování a uvolňování, stejně jako pro operace sloučení. Například rozdílový soubor odpovídající rozsahu transakcí (100, 200) ukládá odstraněné řádky vložené transakcemi v rozsahu (100, 200). Podobně jako k datovým souborům se k rozdílovému souboru přistupuje sekvenčně.

Při odstranění řádku se řádek fyzicky neodebere z datového souboru, ale reference na něj se připojí k delta souboru, který je spojený s rozsahem transakcí, kam byl tento datový řádek původně umístěn. Vzhledem k tomu, že odstraňovaný řádek již v datovém souboru existuje, rozdílový soubor ukládá pouze referenční informace {inserting_tx_id, row_id, deleting_tx_id} a následuje pořadí transakčního protokolu původní operace odstranění nebo aktualizace.

Velikost: Každý rozdílový soubor má velikost přibližně 16 MB pro počítače s pamětí větší než 16 GB a 1 MB pro počítače s pamětí menší nebo rovnou 16 GB. SQL Server 2016 (13.x) může používat režim velkých kontrolních bodů, pokud se domnívá, že subsystém úložiště je dostatečně rychlý. V režimu velkých kontrolních bodů mají rozdílové soubory velikost 128 MB.

Zaplňte data a delta soubory

Soubor dat a delta soubor jsou naplněny na základě záznamů transakčního protokolu vygenerovaných potvrzenými transakcemi v tabulkách optimalizovaných pro paměť a přidají informace o vložených a odstraněných řádcích do příslušných souborů dat a delta souborů. Na rozdíl od tabulek založených na disku, kde se při dokončení kontrolního bodu vyprázdní stránky dat a indexu náhodnými vstupně-výstupními operacemi, je trvalost tabulky optimalizované pro paměť průběžnou operací na pozadí. K více rozdílovým souborům se přistupuje, protože transakce může odstranit nebo aktualizovat libovolný řádek vložený jakoukoli předchozí transakcí. Informace o odstranění se vždy připojují na konec rozdílového souboru. Například transakce s časovým razítkem potvrzení 600 vloží jeden nový řádek a odstraní řádky vložené transakcemi s časovým razítkem potvrzení 150, 250 a 450, jak je znázorněno na následujícím obrázku. Všechny čtyři vstupně-výstupní operace (tři pro odstraněné řádky a 1 pro nově vložené řádky) jsou operacemi pouze připojení k odpovídajícím rozdílovým a datovým souborům.

Přístup k datům a rozdílovým souborům

K párům dat a rozdílových souborů se přistupuje, když dojde k následujícím událostem.

Pracovníci kontrolních bodů offline

Toto vlákno přidává operace vložení a odstranění k datovým řádkům optimalizovaným pro paměť, k odpovídajícím párům datových a rozdílových souborů. SQL Server 2014 (12.x) má jeden pracovní proces pro kontrolní bod offline. SQL Server 2016 (13.x) a novější verze mají více checkpoint pracovníků.

Operace sloučení

Operace sloučí jeden nebo více dvojic dat a rozdílových souborů a vytvoří novou dvojici dat a rozdílového souboru.

Během zotavení po havárii

Když se SQL Server restartuje nebo je databáze opět uvedena do režimu online, paměťově optimalizovaná data jsou naplněna pomocí párů datových a delta souborů. Rozdílový soubor funguje jako filtr odstraněných řádků při čtení řádků z odpovídajícího datového souboru. Vzhledem k tomu, že každá dvojice datových a delta souborů je nezávislá, tyto soubory se načítají paralelně, aby se zkrátila doba potřebná k zavedení dat do paměti. Jakmile se data načtou do paměti, modul In-Memory OLTP použije transakční záznamy protokolu, které ještě nejsou zahrnuty v souborech kontrolních bodů, aby byla data optimalizovaná pro paměť kompletní.

Během operace obnovení

Soubory kontrolních bodů In-Memory OLTP jsou vytvořeny ze zálohy databáze, po níž jsou aplikovány jedna nebo více záloh transakčních logů. Stejně jako u zotavení po havárii modul In-Memory OLTP načte data paralelně do paměti, aby se minimalizoval vliv na dobu obnovení.

Sloučení dat a rozdílových souborů

Data tabulek optimalizovaných pro paměť jsou uložená v jednom nebo více dvojicích datových a rozdílových souborů (také se označuje jako dvojice kontrolních souborů nebo CFP). Datové soubory ukládají vložené řádky a rozdílové soubory zaznamenávají odstraněné řádky. Během provádění úlohy OLTP se při aktualizaci, vložení a odstranění řádků pomocí operací DML vytvoří nové CFP k uložení nových řádků a odkaz na odstraněné řádky se přidá k souborům delta.

V průběhu času se s operacemi DML zvyšuje počet dat a rozdílových souborů, což způsobuje zvýšené využití místa na disku a vyšší dobu obnovení.

Kvůli zabránění těmto nekompiciencím se starší uzavřená data a rozdílové soubory sloučí na základě zásad sloučení popsaných dále v tomto článku, takže pole úložiště je komprimované tak, aby představovalo stejnou sadu dat s menším počtem souborů.

Operace sloučení přebírá jako vstup jeden nebo více sousedících párů zavřených souborů kontrolních bodů (CFP), které jsou páry datových a rozdílových souborů (označované jako slučovací zdroj) na základě interně definované zásady sloučení a vytvoří jeden výsledný CFP, který se nazývá cíl sloučení. Položky v každém rozdílovém souboru zdrojových CFPs se používají k filtrování řádků z příslušného datového souboru za účelem odstranění nepotřebných datových řádků. Zbývající řádky zdrojových CFP jsou konsolidovány do jednoho cílového CFP. Po dokončení sloučení nahradí výsledné sloučovací cílové CFP zdrojové CFP (slučovací zdroje). Zdrojová data pro sloučení procházejí přechodovou fází před jejich odstraněním z úložiště.

V následujícím příkladu má skupina paměťově optimalizovaných tabulek čtyři páry datových a rozdílových souborů s časovým razítkem 500, které obsahují data z předchozích transakcí. Například řádky v prvním datovém souboru odpovídají transakcím s časovým razítkem větším než 100 a menší než nebo rovnou 200; případně reprezentováno jako (100, 200]. Druhý a třetí datový soubor jsou po zohlednění řádků označených jako odstraněných zobrazeny jako zaplněné méně než na 50 %. Slučovací operace kombinuje tyto dva CFP a vytvoří novou CFP obsahující transakce s časovým razítkem větším než 200 a menším nebo rovným 400, což je kombinovaný rozsah těchto dvou CFP. Vidíte další CFP s rozsahem (500, 600] a neprázdným rozdílovým souborem pro rozsah transakcí (200, 400], což ukazuje, že operaci sloučení je možné provést současně s transakční aktivitou, včetně možnosti odstranění dalších řádků ze zdrojových CFP.

Vlákno na pozadí vyhodnocuje všechny uzavřené CFPs pomocí slučovací politiky a pak spustí jednu nebo více žádostí o sloučení pro oprávněné CFPs. Tyto žádosti o sloučení jsou zpracovávány vláknem kontrolního bodu offline. Vyhodnocení zásad sloučení se provádí pravidelně a také při zavření kontrolního bodu.

Zásady sloučení SQL Serveru

SQL Server implementuje následující zásady sloučení:

• Sloučení je naplánováno, pokud lze konsolidovat dva nebo více po sobě jdoucích CFP po zohlednění odstraněných řádků tak, aby výsledné řádky se vešly do jednoho CFP s cílovou velikostí. Cílová velikost dat a rozdílových souborů odpovídá původní velikosti, jak je popsáno výše.

• Pokud datový soubor překročí dvojnásobnou cílovou velikost a odstraní se více než polovina řádků, může být jediný CFP sloučen. Datový soubor může být větší než cílová velikost, pokud například jedna transakce nebo více souběžných transakcí vloží nebo aktualizuje velké množství dat, aby se datový soubor zvětšil nad cílovou velikost, protože transakce nemůže přesahovat více CFPs.

Tady je několik příkladů, které ukazují, že cfps, které se mají sloučit v rámci zásad sloučení:

Přilehlé zdrojové soubory CFPs (% zaplnění)	Sloučit výběr
CFP0 (30%), CFP1 (50%), CFP2 (50%), CFP3 (90%)	(CFP0, CFP1) CFP2 se nevybíral, protože výsledný datový soubor je větší než 100% ideální velikosti.
CFP0 (30%), CFP1 (20%), CFP2 (50%), CFP3 (10%)	(CFP0, CFP1, CFP2). Soubory se vybírají odleva. CFP3 se nevybíral, protože výsledný datový soubor je větší než 100% ideální velikosti.
CFP0 (80%), CFP1 (30%), CFP2 (10%), CFP3 (40%)	(CFP1, CFP2, CFP3). Soubory se vybírají odleva. CFP0 se přeskočí, protože v kombinaci s CFP1 je výsledný datový soubor větší než 100% ideální velikosti.

Ne všechny CFPs s dostupným místem se dají sloučit. Pokud jsou například dva sousední CFP z 60 % plné, nesplňují podmínky pro sloučení a každý z těchto CFP má 40 % nevyužitého úložiště. V nejhorším případě jsou všechny CFPs 50% plné, využití úložiště pouze 50%. Odstraněné řádky mohou existovat v úložišti, protože CFPs nesplňují podmínky pro sloučení, odstraněné řádky už mohly být z paměti odstraněny procesem uvolňování paměti. Správa úložiště a paměti je nezávislá na uvolňování paměti. Úložiště využívané aktivními CFP (ne všechny CFP se ve skutečnosti aktualizují) může být až dvakrát větší než velikost trvalých tabulek v paměti.

Životní cyklus CFP

"CFP procházejí několika stavy, než je lze uvolnit." Při přechodu souborů mezi fázemi je potřeba provést kontrolní body databáze a zálohování protokolů a nakonec vyčistit soubory, které už nejsou potřeba. Popis těchto fází najdete v tématu sys.dm_db_xtp_checkpoint_files.

Můžete ručně vynutit kontrolní bod a poté vytvořit zálohu protokolu, aby se urychlil proces garbage collection. V produkčních scénářích automatické kontrolní body a zálohy logů, které jsou součástí zálohovací strategie, plynule přecházejí CFPs těmito fázemi bez nutnosti jakéhokoliv ručního zásahu. Vlivem procesu uvolňování paměti je, že databáze s tabulkami optimalizovanými pro paměť můžou mít ve srovnání s velikostí v paměti větší velikost úložiště. Pokud nedojde k zálohování kontrolních bodů a protokolů, velikost diskového prostoru kontrolních souborů se zvětšuje.

Související obsah

• Vytvoření a správa úložiště pro objekty optimalizované pro paměť