Jak název napovídá, TempDB je dočasný pracovní prostor vyžadovaný SQL Serverem pro vytváření a držení přechodných a dočasných objektů.
TempDB je významným kolečkem v celkovém aparátu SQL Serveru a jako dočasný pracovní prostor – data, která uchovává, mají přechodnou povahu. Jinými slovy, vaše instance SQL Serveru znovu vytvoří TempDB pokaždé, když se restartuje, čímž si vytvoří čistý zápisník, se kterým může pracovat.
- dočasné objekty spouštěné požadavky uživatelů
- objekty vyžadované interními systémovými procesy
- informace o verzi řádku
Netřeba říkat, že pokud TempDB není nakonfigurován optimálně, může to vést k provozním úzkým místům a ke snížení výkonu. Možná se budete divit, proč vaše dotazy se složitými operacemi spojení a řazení nepřinášejí výsledky tak rychle, jak se očekávalo.
Neexistuje žádný snadný způsob, jak zobecnit osvědčené postupy pro optimalizaci TempDB, scénáře jsou příliš rozmanité a to, co funguje v dané situaci, nemusí fungovat v jiné. I když byla vaše databáze uvedena do provozu, je vždy dobré pokračovat v kontrole nastavení TempDB, abyste se ujistili, že je nakonfigurováno tak, jak má být.
Jedním z nejzávažnějších problémů ve výkonu databáze je spor o TempDB. K tomu dochází, když více zdrojů vyžaduje TempDB, ale existuje pouze jeden datový soubor TempDB, ke kterému lze přistupovat.
Spor TempDB může způsobit vážné problémy s výkonem a je často mylně chápán jako normální blokování kvůli uzamčení databáze. Mnohokrát se ve skutečnosti jedná o zablokovaný spor na alokačních stránkách souběžnými procesy. To může vést k úzkým místům, protože každý proces čeká, až na něj přijde řada. Protože řada nepřichází dostatečně rychle, vypršel časový limit pro základní připojení a procesy je třeba uvolnit.
Co dostaneš? Virtuální dopravní zácpa zablokovaných procesů.
Jak vyřešit spor o TempDB a optimalizovat výkon SQL Server? Podívejme se na základy a odtamtud postupujeme dál.
Počet datových souborů – Kolik jich mám mít?
Když nastavíte SQL Server a zachováte výchozí konfiguraci, máte pouze jeden datový soubor pro TempDB. Nespokojte se s touto konfigurací.
Jedním z často propagovaných pravidel je jeden datový soubor na jádro. V tomto případě však postupujte opatrně, pokud má váš server 12 jader, nepoužívejte 12 datových souborů TempDB, pokud to není odůvodněno požadavky aplikace a zatížení.
Nejlepší možností, vzhledem k dnešním hardwarovým konfiguracím, je začít s 8 stejně velkými primárními datovými soubory a zjistit, zda je problém sporu vyřešen. Postupujte směrem nahoru a v případě potřeby přidejte další čtyři soubory. Průvodce instalací a nastavením SQL Server 2016 má vestavěnou funkci, která zajišťuje dostatečný počet datových souborů TempDB tím, že detekuje počet jader CPU a automaticky vytvoří příslušný počet datových souborů TempDB.
Na velikosti záleží – Jak by měla být velikost datových souborů nakonfigurována?
Nyní, když jsme pokryli počet souborů, pojďme se podívat na doporučenou velikost každého souboru. Výchozí velikost je 8 MB, což poskytuje serveru SQL Server celkem 64 MB prostoru TempDB, což je nedostatečné pro většinu produkčních prostředí. Možností je také zachování automatického růstu, ale SQL Server se bude muset pozastavit a v případě potřeby alokovat více místa na disku pro soubory TempDB – což zvyšuje značnou režii pro SQL Server během produkčního běhu.
Doporučená praxe je ponechat soubory a počáteční prostor požadovaný pro každý soubor zhruba 80 až 90 % svazku, na kterém je uložena TempDB. 10 až 20 % místa na disku zbývá pro virtuální paměť OS.
Jinými slovy, přednastavte velikost datových souborů během instalace nebo změňte velikost souborů v produkčním prostředí. To zajistí, že bude pro TempDB přidělen dostatek místa na disku. V tomto okamžiku se vždy doporučuje ponechat zapnutou možnost Autogrowth, ale v ideálním případě se snažte zajistit, aby SQL Server nemusel za běhu přidělovat další místo na disku příliš často.
Zajímavý fakt, že před SQL Serverem 2017 nebylo možné alokovat více než 1 GB na datový soubor TempDB v době instalace. S nejnovější verzí je možné při nastavování alokovat až 256 GB pro datový soubor TempDB.
Což nás přivádí k další otázce:
Kde uchovám datové soubory TempDB?
Před SQL Serverem 2012 musel být TempDB v případě klastrovaného prostředí umístěn na discích sdílených mezi klastrovaným prostředím, jako je například síť úložiště (SAN). Počínaje SQL Serverem 2012 je možné uchovávat datové soubory TempDB na místním úložišti založeném na SSD. Tím se sníží objem provozu mezi sdílenou sítí SAN a instancí SQL Server.
Ve většině případů je nejlepší volbou pro umístění TempDB vyhrazený místní SSD. Pokud to není možné, pak by jeho ponechání na samostatném vyhrazeném svazku s dostatečným předem přiděleným místem na disku mělo vyřešit pravděpodobné problémy s výkonem. Ujistěte se, že neustále monitorujete stav disku, aby čtení a zápis disku probíhal na optimální úrovni.
V ideálním případě by média měla být co nejrychlejší vzhledem ke konfiguraci serveru, požadavkům aplikace a v neposlední řadě přidělenému rozpočtu.
Nyní, když jsme se podívali na základy, pojďme se podívat na relevantní a vítané přírůstky k různým přírůstkům SQL Serveru po SQL Server 2012.
Co je ještě nového?
SQL Server 2016
Vyhrazená karta během nastavení
- U této edice má SQL Server vyhrazenou kartu pro konfiguraci TempDB během pracovního postupu nastavení
- Průvodce instalací a nastavením SQL Server 2016 má vestavěnou funkci, která zajišťuje, že budete mít v době instalace SQL Serveru dostatečný počet datových souborů TempDB. Zjistí počet jader CPU a automaticky vytvoří datové soubory TempDB, maximálně však 8. Tento počet můžete zvýšit po nastavení SQL Serveru.
Okamžitá inicializace souboru
- SQL Server musí alokovat místo na disku pro TempDB během počátečního nastavení a také když velikost souboru roste v produkčním běhu. Toto rozdělení je možné dvěma způsoby. První způsob je inicializace nevyužitého místa na disku zápisem nul před přidělením místa. Druhým způsobem je okamžité přidělení souborového prostoru pro růst TempDB.
- V první metodě musí SQL Server provést diskově intenzivní operaci inicializací každého clusteru logických disků. Při této metodě mohou procesy běžící na serveru, které potřebují TempDB, čekat, což vytváří úzké místo.
- Pokud se místo toho rozhodnete okamžitě alokovat souborový prostor, SQL server okamžitě alokuje prostor pro Autogrowth bez inicializace místa na disku. To snižuje vstup/výstup disku pokaždé, když je požadavek na automatický růst, a zajišťuje lepší propustnost a výkon. Ačkoli bylo možné zapnout IFI v předchozích vydáních, byl to těžkopádný proces. V této edici SQL Server je jednodušší nastavit IFI v době nastavení serveru.
- Příznaky trasování 1117 a 1118 jsou nadbytečné
SQL Server 2017
- Před verzí SQL Server 2017 nebylo možné alokovat více než 1 GB na datový soubor TempDB v době instalace, což znamená, že velikost souboru TempDB musela být po dokončení instalace zvětšena. S touto verzí je možné při instalaci alokovat až 256 GB pro datový soubor TempDB.
Monitorování TempDB
Sledování TempDB může být obtížné. Jak můžete zjistit, zda máte spor o TempDB? Co je přidělováno uživatelským objektům, úložišti verzí nebo interním objektům? Jak se tyto trendy vyvíjejí v čase? Jaké relace spotřebovávají TempDB a do jaké míry? Spotlight Cloud usnadňuje odpovědi na tyto otázky. Monitoruje všechny aspekty výkonu vašeho SQL serveru 24/7 a poskytuje hloubkové analytické pracovní postupy pro řešení jakéhokoli problému s výkonem. Sledujte svou TempDB v průběhu času a získejte automatizované odborné rady ohledně konfigurace.
Jako řešení SaaS se Spotlight Cloud snadno nastavuje a konfiguruje. Uchovává údaje o výkonu až za rok a poskytuje nepřekonatelné poznatky o ladění. Problémy s výkonem lze vyřešit během několika sekund pomocí analýzy hlavních příčin. Už neztrácejte čas prohrabáváním se složitými skripty – zahajte 30denní zkušební verzi hned teď. Špičkové sledování výkonu SQL Serveru nyní začíná.