Sdílet prostřednictvím

Plánování přijetí funkcí In-Memory OLTP na SQL Serveru

  • Článek

platí pro:SQL ServerAzure SQL Databaseazure SQL Managed Instance

Tento článek popisuje způsoby, jak přijetí funkcí v paměti v SQL Serveru ovlivňuje další aspekty vašeho obchodního systému.

Poznámka

A. Přijetí funkcí OLTP In-Memory

Následující pododdíly probírají faktory, které je nutné zvážit při plánování přijetí a implementaci funkcí In-Memory.

Požadavky A.1

Jedním z předpokladů pro použití funkcí In-Memory může být edice nebo úroveň služby produktu SQL. Informace o těchto a dalších požadavcích najdete v těchto tématech:

A.2 Prognóza množství aktivní paměti

Má váš systém dostatek aktivní paměti pro podporu nové tabulky optimalizované pro paměť?

Microsoft SQL Server

Tabulka optimalizovaná pro paměť, která obsahuje 200 GB dat, vyžaduje vyhrazenou pro podporu více než 200 GB aktivní paměti. Než implementujete tabulku optimalizovanou pro paměť obsahující velké množství dat, musíte předpovědět množství další aktivní paměti, kterou možná budete muset přidat do serveru. Pokyny k odhadu najdete tady:

Podobné pokyny jsou k dispozici pro službu Azure SQL Managed Instance:

Azure SQL Database

U databáze hostované v cloudové službě Azure SQL Database má vybraná úroveň služby vliv na množství aktivní paměti, kterou vaše databáze může využívat. Měli byste naplánovat monitorování využití paměti databáze pomocí výstrahy. Podrobnosti najdete tady:

Proměnné tabulek optimalizované pro paměť

Proměnná tabulky, která je deklarována jako optimalizovaná pro paměť, je někdy vhodnější než tradiční #TempTable, která se nachází v databázi tempdb. Proměnné tabulky můžou poskytovat zvýšení výkonu bez použití významných objemů aktivní paměti.

Tabulka A.3 musí být offline, aby mohla být převedena na optimalizovanou pro paměť.

Některé funkce ALTER TABLE jsou k dispozici pro tabulky optimalizované pro paměť. Nemůžete ale vydat příkaz ALTER TABLE, který převede tabulku založenou na disku na tabulku optimalizovanou pro paměť. Místo toho je nutné použít ručnější sadu kroků. Následující možnosti jsou různé způsoby, jak převést tabulku založenou na disku tak, aby byla optimalizována pro paměť.

Ruční skriptování

Jedním ze způsobů, jak převést tabulku založenou na disku na tabulku optimalizovanou pro paměť, je naprogramovat potřebné Transact-SQL kroky sami.

  1. Pozastavit aktivitu aplikace.

  2. Proveďte úplné zálohování.

  3. Přejmenujte tabulku založenou na disku.

  4. Vytvořte novou tabulku optimalizovanou pro paměť a vytvořte příkaz CREATE TABLE.

  5. INSERT INTO do tabulky optimalizované pro paměť s dílčím výběrem z diskové tabulky.

  6. Smažte svoji tabulku na disku.

  7. Proveďte další úplné zálohování.

  8. Pokračovat v aktivitě aplikace

Poradce pro optimalizaci paměti

Nástroj Memory Optimization Advisor může vygenerovat skript, který pomáhá implementovat převod tabulky založené na disku na tabulku optimalizovanou pro paměť. Nástroj se nainstaluje jako součást SQL Server Data Tools (SSDT).

Soubor .dacpac

Místní databázi můžete aktualizovat pomocí souboru .dacpac spravovaného pomocí SSDT. V SSDT můžete zadat změny schématu zakódovaného v souboru .dacpac.

Pracujete se soubory .dacpac v kontextu projektu sady Visual Studio typu Database.

A.4 Pokyny k tomu, zda In-Memory funkce OLTP jsou pro vaši aplikaci vhodné

Pokyny k tomu, jestli In-Memory funkce OLTP můžou zlepšit výkon konkrétní aplikace, najdete tady:

B. Nepodporované funkce

Funkce, které nejsou podporovány v určitých scénářích In-Memory OLTP, jsou popsány v následujících případech:

Následující pododdíly zvýrazňují některé z důležitějších nepodporovaných funkcí.

B.1 SNÍMEK databáze

Po prvním vytvoření jakékoli tabulky nebo modulu optimalizované pro paměť v dané databázi se nikdy nedají pořizovat žádné SNAPSHOT databáze. Konkrétní důvod je následující:

  • První položka optimalizovaná pro paměť znemožňuje vyhodit poslední soubor ze skupiny FILEGROUP optimalizované pro paměť; a
  • Žádná databáze, která má soubor v paměťově optimalizovaném FILEGROUP, nemůže podporovat SNAPSHOT.

Za normálních okolností může být snímek užitečný pro rychlé iterace testování.

B.2 Dotazy napříč databázemi

Tabulky optimalizované pro paměť nepodporují transakce mezi databázemi. Nelze získat přístup k jiné databázi ze stejné transakce nebo stejného dotazu, který také přistupuje k tabulce optimalizované pro paměť.

Proměnné tabulky nejsou transakční. Proto proměnné tabulek optimalizované pro paměť lze použít v dotazech napříč databázemi.

B.3 Nápověda k tabulce READPAST

Žádný dotaz nemůže použít nápovědu tabulky READPAST pro libovolnou tabulku optimalizovanou pro paměť.

Náznak READPAST je užitečný ve scénářích, kdy několik relací přistupuje a upravuje stejnou malou sadu řádků, například při zpracování fronty.

B.4 RowVersion, Sequence

  • Pro RowVersion v tabulce optimalizované pro paměť nelze označit žádný sloupec.

  • SEQUENCE nelze použít s omezením v tabulce optimalizované pro paměť. Nelze například vytvořit omezení DEFAULT s klauzulí NEXT VALUE FOR. SeQUENCEs lze použít s příkazy INSERT a UPDATE.

C. Správa údržby

Tato část popisuje rozdíly ve správě databáze, kde se používají tabulky optimalizované pro paměť.

C.1 Počáteční resetování identity, zvýšení > 1

DBCC CHECKIDENTnelze pro obnovení sloupce IDENTITY použít v tabulce optimalizované pro paměť.

Hodnota přírůstku je omezena na přesně 1 pro sloupec IDENTITY v tabulce optimalizované pro paměť.

C.2 DBCC CHECKDB nemůže ověřit tabulky optimalizované pro paměť

Příkaz DBCC CHECKDB nic nedělá, pokud je cílem tabulka optimalizovaná pro paměť. Následující postup je alternativní:

  1. zálohujtetransakční protokol.

  2. Zálohujte soubory v souboru FILEGROUP optimalizovaném pro paměť na zařízení s hodnotou null. Proces zálohování vyvolá ověření kontrolního součtu.

    Pokud se najde poškození, pokračujte dalšími kroky.

  3. Zkopírujte data z tabulek optimalizovaných pro paměť do tabulek založených na disku pro dočasné úložiště.

  4. Obnovte soubory z FILEGROUP optimalizovaného pro paměť.

  5. VLOŽTE DO tabulek optimalizovaných pro paměť data, která jste dočasně uložili v tabulkách založených na disku.

  6. Odstraňte tabulky založené na disku, které dočasně uchovávaly data.

D. Výkon

Tato část popisuje situace, kdy je možné pod úplným potenciálem uchovávat vynikající výkon tabulek optimalizovaných pro paměť.

Důležité informace o indexu D.1

Všechny indexy v tabulce optimalizované pro paměť se vytvářejí a spravují pomocí příkazů souvisejících s tabulkami CREATE TABLE a ALTER TABLE. Tabulku optimalizovanou pro paměť nelze cílit pomocí příkazu CREATE INDEX.

Tradiční neclusterovaný index B-tree je často rozumnou a jednoduchou volbou při první implementaci tabulky optimalizované pro paměť. Později, jakmile uvidíte, jak vaše aplikace funguje, můžete zvážit prohození jiného typu indexu.

Poznámka

Dokumentace používá termín B-tree obecně v odkazu na indexy. V indexech rowstore databázový stroj implementuje strom B+. To neplatí pro indexy columnstore ani indexy v tabulkách optimalizovaných pro paměť. Další informace najdete v SQL Serveru a architektuře indexu Azure SQL a průvodci návrhem.

V kontextu paměťově optimalizované tabulky je potřeba prodiskutovat dva speciální typy indexů: Indexy Hash a indexy Columnstore.

Přehled indexů v tabulkách optimalizovaných pro paměť najdete tady:

Hashové indexy

Indexy hash mohou být nejrychlejším formátem pro přístup k jednomu konkrétnímu řádku pomocí přesné hodnoty primárního klíče pomocí operátoru "=".

  • Neexactní operátory, jako je!=,>neboBETWEEN, by při použití s indexem hash poškodily výkon.

  • Index hash nemusí být nejlepší volbou, pokud se míra duplicity klíčových hodnot stane příliš vysoká.

  • Chraňte se před podceňováním toho, kolik kbelíků může váš hashovací index potřebovat, abyste se vyhnuli dlouhým řetězcům v jednotlivých kbelících. Podrobnosti najdete tady:

Neclusterované indexy columnstore

Tabulky optimalizované pro paměť poskytují vysokou propustnost typických obchodních transakčních dat v paradigmatu, které voláme online zpracování transakcí nebo OLTP. Indexy Columnstore poskytují vysokou propustnost agregací a podobného zpracování, které nazýváme Analytics. V minulých letech byl nejlepší přístup k uspokojení potřeb OLTP i analytiky mít samostatné tabulky s velkým přesunem dat a určitou mírou duplikace dat. Dnes je k dispozici jednodušší hybridní řešení: mít columnstore index na tabulce optimalizované pro paměť.

  • Index columnstore lze vytvořit na tabulce založené na disku, a to i jako clusterovaný index. Na paměťově optimalizované tabulce však nelze index columnstore shlukovat.

  • Sloupce LOB nebo off-row pro tabulku optimalizovanou pro paměť zabraňují vytvoření columnstore indexu na tabulce.

  • V tabulce optimalizované pro paměť nelze spustit žádný příkaz ALTER TABLE, zatímco v tabulce existuje index columnstore.

    • Od srpna 2016 má Microsoft krátkodobé plány na zlepšení výkonu opětovného vytvoření indexu columnstore.

D.2 Sloupce LOB a sloupce mimo řádek

Velké objekty (LOB) jsou sloupce takových typů, jako je varchar(max). Vytvoření několika sloupců s velkými objekty v tabulce optimalizované pro paměť pravděpodobně neovlivní výkon natolik, aby to mělo význam. Ale vyhněte se tomu, abyste měli více LOB sloupců, než je potřeba pro vaše data. Stejné rady platí pro sloupce, které nejsou v hlavní řadě. Nedefinujte sloupec jako nvarchar(3072), pokud bude stačit varchar(512).

Další informace o sloupcích LOB a off-row najdete tady:

E. Omezení nativních procedur

Konkrétní prvky Transact-SQL nejsou podporovány v nativně kompilovaných modulech T-SQL, včetně uložených procedur. Podrobnosti o podporovaných funkcích najdete tady:

Důležité informace o migraci modulu Transact-SQL, který používá nativně kompilované nepodporované funkce, najdete tady:

Kromě omezení některých prvků jazyka Transact-SQL existují také omezení pro operátory dotazů podporované v nativně kompilovaných modulech T-SQL. Z těchto omezení nejsou nativně zkompilované uložené procedury vhodné pro analytické dotazy, které zpracovávají velké datové sady.

Žádné paralelní zpracování v nativním prostředí proc

Paralelní zpracování nemůže být součástí žádného plánu dotazů pro nativní proc. Nativní procesy jsou vždy jednovláknové.

Typy spojení

Spojení hash i slučovací spojení nemohou být součástí žádného plánu dotazu pro nativní proceduru. Používají se vnořené smyčky pro spojování.

Žádná agregace hodnot hash

Pokud plán dotazu pro nativní proc vyžaduje fázi agregace, je k dispozici pouze agregace datových proudů. Agregace hodnot hash není podporována v plánu dotazu pro nativní proceduru.

  • Agregace hash je lepší, když je potřeba agregovat data z velkého počtu řádků.

F. Návrh aplikace: Transakce a logika opakování

Transakce zahrnující tabulku optimalizovanou pro paměť se může stát závislá na jiné transakci, která zahrnuje stejnou tabulku. Pokud počet závislých transakcí dosáhne povoleného maxima, všechny závislé transakce selžou.

V SQL Serveru 2016:

  • Povolené maximum je osm závislých transakcí. Osm je také limit transakcí, na které může být každá daná transakce závislá.
  • Číslo chyby je 41839. (V SQL Serveru 2014 je číslo chyby 41301.)

Pomocí přidání logiky opakování do vašich skriptů můžete vytvořit robustnější Transact-SQL skripty proti možné chybě transakce. Logika opakování bude pravděpodobně pomoct, když jsou volání UPDATE a DELETE časté nebo pokud je tabulka optimalizovaná pro paměť odkazována cizím klíčem v jiné tabulce. Podrobnosti najdete tady:

Související obsah