V mém předchozím článku o SQL Server System Databases jsme se dozvěděli o každé systémové databázi, která je součástí instalace SQL Serveru. Aktuální článek se zaměří na často se vyskytující problémy kolem databáze tempdb a na to, jak je správně vyřešit.
SQL Server TempDB
Jak název této systémové databáze napovídá, tempdb obsahuje dočasné objekty vytvořený SQL Serverem. Týkají se několika operací a fungují jako globální pracovní oblast pro všechny uživatele připojující se k instancím SQL Server.
Databáze Tempdb bude obsahovat níže uvedené typy objektů, zatímco uživatelé provádějí své operace:
- Dočasné objekty jsou vytvářeny explicitně uživateli. Mohou to být buď místní nebo globální dočasné tabulky a indexy, proměnné tabulky, tabulky používané ve funkcích s hodnotou tabulky a kurzory.
- Interní objekty vytvořené databázovým strojem jako
- Pracovní tabulky ukládající mezivýsledky pro řazení, kurzory, řazení a dočasné velké objekty (LOB).
- Pracovní soubory při provádění operací Hash Join nebo Hash agregace.
- Postupné výsledky řazení při vytváření nebo přestavbě indexů, pokud je SORT_IN_TEMPDB nastaveno na ON, a další operace, jako jsou dotazy GROUP BY, ORDER BY nebo SQL UNION.
- Obchody verzí, které podporují funkci správy verzí řádků, buď úložiště běžných verzí, nebo úložiště verzí sestavení online indexu, používají databázové soubory tempdb.
Databáze Tempdb se vytvoří při každém spuštění služby SQL Server. Čas vytvoření databáze tempdb lze tedy považovat za přibližný čas spuštění služby SQL Server. Můžeme jej identifikovat z sys.databases DMV pomocí níže uvedeného dotazu:
SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'
Skutečné spuštění služby SQL Server Service však zahrnuje spouštění všech systémových databází v určitém pořadí. Může k tomu dojít o něco dříve, než je čas vytvoření databáze tempdb. Hodnotu můžeme získat pomocí sys.databases DMV provedením níže uvedeného dotazu na sys.dm_os_sys_info DMV .
SELECT ms_ticks, sqlserver_start_time_ms_ticks, sqlserver_start_time
FROM sys.dm_os_sys_info
ms_ticks sloupec udává počet milisekund od spuštění počítače nebo serveru. sqlserver_start_time_ms_ticks sloupec udává počet milisekund od ms_ticks číslo při spuštění služby SQL Server.
Více informací o pořadí databází, které se spustily při spouštění služeb SQL Server, najdeme v protokolu chyb SQL Server.
V SSMS rozbalte Správa > Protokoly chyb serveru SQL > otevřete aktuální protokol chyb. Použijte Spuštění up databáze filtrovat a klikněte na Datum chcete-li jej seřadit vzestupně:
Při spouštění služby SQL Server vidíme, že hlavní databáze se spustila jako první. Poté následovaly všechny databáze uživatelů a všechny ostatní systémové databáze. Nakonec se tempdb spustil. Tyto informace můžete také načíst programově spuštěním xp_readerrorlog systémový postup:
Poznámka :Oba výše uvedené přístupy nemusí zobrazovat potřebné informace, pokud služba SQL Server nebyla nedávno restartována a protokol chyb SQL Server byl recyklován, což mohlo způsobit přesunutí starších protokolů chyb do starších souborů. V takovém případě možná budeme muset naskenovat data v archivovaných souborech protokolu chyb serveru SQL.
Časté problémy v databázi SQL TempDB
Protože databáze tempdb poskytuje globální pracovní oblast pro všechny uživatelské relace nebo aktivity, může se stát překážkou výkonu pro uživatelské operace, pokud není pečlivě nakonfigurována. V mém předchozím článku jsme diskutovali o doporučených doporučených postupech implementace v databázi tempdb. I po jejich implementaci se však můžeme často setkat s problémy:
- Nerovnoměrný růst souborů mezi datovými soubory tempdb.
- Datové soubory Tempdb nabývají na obrovské hodnotě a potřebují zmenšit Tempdb.
Nerovnoměrný růst souborů mezi datovými soubory TempDB
Počínaje SQL Server 2000 je výchozím doporučením mít více datových souborů na základě počtu logických jader dostupných na serveru.
Když máme více datových souborů, například 4 datové soubory tempdb jako na obrázku níže, dojde k automatickému nárůstu datových souborů tempdb o 64 MB v režimu round-robin počínaje tempdev> temp2> temp3> temp4> tempdev> a tak dále.
Pokud se jedna z velikostí souborů nemůže z nějakého důvodu automaticky zvětšit, bude to mít za následek velké velikosti určitých souborů ve srovnání s jinými soubory. To vede k dodatečnému přetížení velkých souborů a negativnímu dopadu na výkon databáze tempdb.
Potřebujeme ručně zajistit, aby všechny datové soubory tempdb měly stejnou velikost v kterémkoli okamžiku ručně, abychom se vyhnuli sporům nebo problémům s výkonem až do SQL Server 2014. Microsoft toto chování změnil počínaje SQL Server 2016 a novějšími verzemi implementací několika funkcí, které budou diskutováno dále v tomto článku.
K překonání výše uvedených problémů s výkonem zavedl SQL Server 2 příznaky trasování s názvem 1117 a 1118 abyste se vyhnuli problémům s tempdb.
- Trace Flag 1117 – umožňuje automatický růst všech souborů v rámci jedné skupiny souborů
- Trace Flag 1118 – umožňuje UNIFORM FULL EXTENTS pro tempdb
Trace Flag 1117
Bez povoleného příznaku trasování 1117, kdykoli je tempdb nakonfigurována s více datovými soubory, které mají stejnou velikost, a datové soubory se potřebují automaticky zvětšovat, SQL Server se ve výchozím nastavení pokusí zvětšit velikosti souborů způsobem cyklicky všechny soubory. Pokud datové soubory nemají stejnou velikost, pak se SQL Server pokusí zvětšit velikost největšího datového souboru tempdb a použije tento větší soubor pro většinu uživatelských operací, což vede k problémům s tempdb.
K vyřešení tohoto problému zavedl SQL Server příznak trasování 1117. Po povolení, pokud jeden soubor ve skupině souborů potřebuje automaticky růst, automaticky naroste všechny soubory v této skupině souborů. Řeší problémy sporu tempdb. Háček je však v tom, že jakmile je povolen příznak trasování 1117, je automatický růst nakonfigurován také pro všechny uživatelské databáze.
Trace Flag 1118
Trace Flag 1118 se používá k aktivaci UNIFORM FULL EXTENTS. Vraťme se o krok zpět, abychom pochopili, jak SQL Server ukládá data od základu.
Stránka je základní jednotkou úložiště na serveru SQL Server o velikosti 8 kilobajtů (KB).
Rozsah je sada 8 fyzicky na sebe navazujících stránek o velikosti 64KB(8*8KB). Na základě toho, kolik objektů nebo vlastníků ukládá data v rámci oblasti, lze oblast rozdělit do:
- Uniformní rozsahy je 8 souvislých stránek používaných nebo přístupných jedním objektem nebo vlastníkem;
- Smíšené Rozsahy – je 8 souvislých stránek používaných nebo přístupných minimálně 2 a maximálně 8 objekty nebo vlastníky
Povolení Trace Flag 1118 umožní tempdb mít jednotné rozsahy, což povede k lepšímu výkonu.
Jak povolit příznaky trasování 1117 a 1118
Trace Flags lze aktivovat několika způsoby. Vhodný způsob můžete definovat z níže uvedených možností:
Parametry spouštění služby SQL Server
Trvale k dispozici i po restartu služby SQL. Doporučený způsob je povolit příznaky trasování 1117 a 1118 prostřednictvím parametrů spuštění služby SQL Server .
Otevřete SQL Server Configuration Manager a klikněte na Služby SQL Server pro seznam dostupných služeb na tomto serveru:
- Klikněte pravým tlačítkem na SQL Server (MSSQLSERVER) > Vlastnosti > Parametry spouštění .
- Typ –T do prázdného pole označte Trace Flag .
- Zadejte hodnoty 1117 a 1118 jak je uvedeno níže.
- Klikněte na Přidat aby byly Trace Flags přidány jako parametry spouštění.
Poté klikněte na OK aby byly trvale přidány příznaky trasování pro tuto instanci SQL Server. Restartujte službu SQL Server, aby se změny projevily.
DBCC TRACEON (<číslo příznaku trasování>, -1)
Globálně povolit příznak trasování. Služba SQL Server ztratí příznaky trasování po restartování služby. Chcete-li globálně povolit příznak trasování, spusťte níže uvedený skript v novém okně dotazu:
DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);
DBCC TRACEON ()
Povolte příznak trasování na úrovni relace. Platí pouze pro aktuální relaci vytvořenou uživatelem. Chcete-li povolit příznak trasování na úrovni relace, spusťte níže uvedený skript v novém okně dotazu:
DBCC TRACEON(1117);
DBCC TRACEON(1118);
Chcete-li zobrazit seznam příznaků trasování povolených v instanci serveru SQL Server, můžeme použít DBCC TRACESTATUS příkaz:
DBCC TRACESTATUS();
Jak vidíme, Trace Flags 1117 a 1118 jsou v mém případě povoleny globálně spolu s Session .
Chcete-li vypnout příznak trasování, můžeme použít příkaz DBCC TRACEOFF jako:
DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);
Vylepšení TempDB SQL Server 2016
Ve všech verzích SQL Server SQL Server 2000 až SQL Server 2014 musíme povolit příznaky trasování 1117 a 1118 spolu s kompletním monitorováním databáze tempdb, abychom se vyhnuli problémům s tempdb. Počínaje SQL Serverem 2016 a novějšími verzemi jsou ve výchozím nastavení implementovány příznaky trasování 1117 a 1118.
Nicméně na základě mých osobních zkušeností je lepší předem narůst tempdb na obrovskou velikost, abyste se vyhnuli potřebě vícenásobného automatického růstu a eliminovali nerovnoměrné velikosti souborů nebo jednotlivé soubory, které SQL Server extenzivně používá .
Můžeme ověřit, jak jsou Trace Flag 1117 a 1118 implementovány v SQL Server 2016:
Trace Flag 1117 která nastavuje automatický růst všech souborů v rámci skupiny souborů je nyní vlastností skupiny souborů . Můžeme ji nakonfigurovat při vytváření nové skupiny souborů nebo při úpravě stávající.
Chcete-li ověřit vlastnost automatického růstu skupiny souborů , spusťte níže uvedený skript z sys.filegroups DMV :
SELECT name Filegroup_Name, is_autogrow_all_files
FROM sys.filegroups
Chcete-li upravit vlastnost auto-growth databáze Primary Filegroup of AdventureWorks , spustíme níže uvedený skript buď pomocí AUTOGROW_ALL_FILES, aby se všechny soubory automaticky rozrostly rovnoměrně, nebo AUTOGROW_SINGLE_FILE, aby se umožnil automatický růst pouze jednoho datového souboru.
ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE
-- AUTOGROW_ALL_FILES is the default behavior
GO
Trace Flag 1118 který nastavuje vlastnost Uniform Extent datových souborů je ve výchozím nastavení povolena pro tempdb a všechny uživatelské databáze počínaje SQL Server 2016 . Nemůžeme změnit vlastnosti databáze tempdb, protože nyní podporuje pouze možnost Uniform Extent.
U uživatelských databází můžeme tento parametr upravit. Hlavní databáze systémových databází, model a msdb ve výchozím nastavení podporují smíšené rozsahy a nelze je také změnit.
Chcete-li upravit hodnoty vlastnosti přidělení smíšené stránky pro databáze uživatelů, použijte níže uvedený skript:
ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON
-- OFF is the default behavior
GO
Chcete-li ověřit vlastnost Mixed pagelocation, můžeme se zeptat na is_mixed_page_allocation_on sloupec z sys.databases DMV s hodnotou 0, která označuje jednotné přidělení stránky s rozsahem, a 1 pro označení smíšeného přidělení stránky s rozsahem.
SELECT name, is_mixed_page_allocation_on
FROM sys.databases
Datové soubory TempDB rostou na obrovskou hodnotu vyžadující zmenšení TempDB
Pokud v SQL Server 2014 nebo dřívějších verzích nejsou příznaky trasování 1117 a 1118 správně nakonfigurovány spolu s více datovými soubory vytvořenými pro databázi tempdb, některé z těchto souborů se nevyhnutelně zvětší. Pokud k tomu dojde, správce databází se obvykle pokusí zmenšit datové soubory tempdb. Ale je to nevhodné přístup k řešení tohoto scénáře.
Existují další možnosti, jak zmenšit databázi tempdb.
Podívejme se na příkazy DBCC dostupné pro Shrink tempdb a dopady provádění těchto operací.
DBCC SHRINKDATABASE
DBCC SHRINKDATABASE konzolový příkaz funguje tak, že zmenší konec Data\Log Files .
K úspěšnému zmenšení databáze potřebuje příkaz volné místo na konci souboru. Pokud jsou na konci souboru nějaké aktivní transakce, databázové soubory nelze zmenšit.
Dopad spuštění DBCC SHRINKDATABASE spočívá v tom, že se pokusí uvolnit dostupné volné místo na konci každého datového souboru nebo souboru protokolu, který mohl být rezervován pro budoucí růst tabulkových dat. Spuštění tohoto příkazu tedy může vést k nerovnoměrným velikostem souborů vedoucím k problémům se spory o tempdb.
Syntaxe pro zmenšení uživatelské databáze, například databáze Adventureworks, by byla
DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);DBCC SHRINKFILE
Soubor DBCC SHRINKFILE konzolový příkaz funguje podobně jako DBCC SHRINKDATABASE, alezmenšuje zadaná data databáze nebo soubory protokolu .
Pokud zjistíte, že konkrétní datový soubor tempdb je velký, můžeme zkusit tuto konkrétní položku zmenšit pomocí DBCC SHRINKFILE, jak je uvedeno níže.
Při používání tohoto příkazu na tempdb buďte opatrní, protože pokud je soubor zmenšen na hodnotu nižší nebo vyšší než u jiných datových souborů, daný datový soubor nebude efektivně využit. Nebo bude používán častěji, což povede k problémům tempdb soupeření.
Syntaxe pro provedení operace DBCC SHRINKFILE na datovém souboru AdventureWorks na 1 GB (1024 MB) by byla:
DBCC SHRINKFILE (AdventureWorks, 1024);
GO
DROPCLEANBUFFERS DBCC
DROPCLEANBUFFERS DBCC příkaz console se používá k vymazání všech čistých vyrovnávacích pamětí z fondu vyrovnávacích pamětí a objektů columnstore z fondu objektů columnstore .
Jednoduše spusťte níže uvedený příkaz:
DBCC DROPCLEANBUFFERSDBCC FREEPROCCACHE
DBCC FREEPROCCACHE příkaz vymaže veškerou mezipaměť plánu provádění uložené procedury .
Mezipaměť plánu provádění procedur používá SQL Server k rychlejšímu provádění stejných volání procedur. Po provedení DBCC FREEPROCCACHE se mezipaměť plánu vymaže. SQL Server tedy musí tuto mezipaměť znovu vytvořit, když je v instanci spuštěna uložená procedura. Při provádění v instancích produkční databáze to zanechává vážný negativní dopad.
Nedoporučuje se spouštět DBCC FREEPROCCACHE na instanci produkční databáze!
Syntaxe pro spuštění DBCC FREEPROCCACHE je níže:
DBCC FREEPROCCACHEDBCC FREESESSIONCACHE
DBCC FREESESSIONCACHE příkaz vymaže mezipaměť připojení distribučního dotazu z instance SQL Server . Bude užitečné, když se na konkrétní instanci SQL Serveru spouští mnoho distribuovaných dotazů.
Syntaxe pro provedení DBCC FREESESSIONCACHE by byla:
DBCC FREESESSIONCACHEDBCC FREESYSTEMCACHE
DBCC FREESYSTEMCACHE příkaz vymaže všechny nepoužívané položky mezipaměti ze všech mezipaměti . SQL Server to dělá ve výchozím nastavení, aby bylo k dispozici více paměti pro nové operace. Můžeme jej však spustit ručně pomocí níže uvedeného příkazu:
DBCC FREESYSTEMCACHEJak víme, tempdb ukládá všechny dočasné uživatelské objekty nebo interní objekty včetně mezipaměti plánu provádění, dat fondu vyrovnávací paměti, mezipaměti relací a mezipaměti systému. Spuštění výše uvedených 6 příkazů DBCC proto pomůže vymazat datové soubory tempdb, které brání normálnímu procesu zmenšování.
I když jsme prošli kroky, jak zmenšit tempdb různými přístupy, doporučené osvědčené postupy pro práci s databází tempdb jsou uvedeny níže:
a. Pokud je to možné, restartujte službu SQL Server Services, abyste znovu vytvořili datové soubory tempdb rovnoměrně. Potenciálním dopadem by bylo, že ztratíme všechny plány provádění a další informace o mezipaměti, o kterých jsme hovořili výše.
b. Předem rozšiřte datové soubory tempdb na obrovskou velikost souboru dostupnou na jednotce obsahující datové soubory tempdb. To zabrání SQL Serveru nerovnoměrně zvětšovat velikost souborů v SQL Server verze 2014 a starší.
c. Pokud služby SQL Server nelze restartovat kvůli RTO nebo RPO, zkuste po jasném pochopení dopadů výše uvedené příkazy DBCC.
d. Zmenšení databáze tempdb nebo datových souborů není doporučený přístup, a proto to nikdy nedělejte ve svém produkčním prostředí, pokud jinak neexistují žádné jiné možnosti.
Závěr
Dozvěděli jsme se více o tom, jak tempdb funguje, abychom mohli nakonfigurovat tempdb pro lepší výkon a vyhnout se problémům s konflikty na tempdb. Prošli jsme také často se vyskytující problémy v databázi tempdb, opatření dostupná na serveru SQL Server v různých verzích a jak s nimi efektivně zacházet. Kromě toho jsme zkoumali, proč zmenšení databáze tempdb nebo datových souborů není doporučeným přístupem při práci s databází tempdb.