Údržba systémových databází serveru SQL Server

Instalace SQL Server ve výchozím nastavení vytváří několik systémových databází na instanci pro údržbu a správu této instance. V tomto článku prozkoumáme tyto systémové databáze a pochopíme jejich odpovědnosti.

Systémové databáze SQL Server

Na serveru SQL Server jsou během procesu instalace vytvořeny systémové databáze pro uložení podrobností konfigurace specifické pro instanci SQL Server, aby fungovaly normálně. Každá instalace SQL Serveru vytvoří minimálně 5 systémových databází a 1 systémovou databázi související s replikací s názvem distribuční databáze který bude vytvořen uživateli, pokud je v této instanci nakonfigurována replikace. Každá systémová databáze má svůj účel a podrobně to prozkoumáme později v tomto článku.

Systémové databáze jsou:

Hlavní – nainstalováno ve výchozím nastavení
Msdb – Ve výchozí instalaci
Model – Výchozí instalace
Tempdb – Ve výchozí instalaci
Zdroj – Ve výchozí instalaci . Zavedeno v SQL Server 2005 a dostupné v pozdějších verzích SQL Server, a proto není dostupné v SQL Server 2000 a starších verzích.
Distribuce – Vytvořeno akcí uživatele . Uživatelé mohou vytvořit distribuční databázi pro konfiguraci Replikace.

Pro zobrazení systémové databáze nainstalované v SQL Serveru můžeme použít SSMS.

Připojte se k instanci SQL Serveru, rozbalte Databáze > Systémové databáze :

Všimli jste si, že zdroj chybí databáze ve výše uvedeném seznamu? Jde o to, že zdrojová databáze je speciální systémová databáze, která není uvedena v Průzkumníku objektů SSMS. Můžeme se však dotázat na podrobnosti databáze zdrojů ze systému DMV s názvem sys.sysaltfiles a spusťte dotaz:

SELECT dbid, db_name(dbid) database_name, fileid, name, filename
FROM sys.sysaltfiles
WHERE dbid NOT BETWEEN 5 AND 11

Ve výsledcích můžeme vidět systémové databáze v pořadí:master, tempdb, model, msdb, distribution a nakonec dbid 32767 což je zdrojová databáze. Tato databáze zdrojů však nezobrazuje žádný název databáze, protože nemá záznam v sys.databases . Vyloučil jsem několik uživatelských databází mezi dbid 5 a 11 a zahrnul jsem AdventureWorks_REPL jako příklad ukázat, že DMV může zobrazit i databáze uživatelů. O databázi zdrojů a dalších systémových databázích se budeme podrobněji věnovat později.

Omezení databází systému SQL

Vzhledem k tomu, že systémové databáze obsahují kritické podrobnosti konfigurace systému, měla by být zavedena správná bezpečnostní opatření, aby se zabránilo náhodnému smazání dat. Systémové databáze mají tedy ve srovnání s databázemi uživatelů níže uvedená omezení:

Systémové databáze nelze přepnout do režimu offline

Uživatelskou databázi můžeme převést do režimu offline pomocí příkazu ALTER DATABASE, jak je ukázáno níže:

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

Pokud se však pokusíme převést kteroukoli ze systémových databází do režimu OFFLINE pomocí výše uvedeného příkazu, obdržíme chybu, jak je uvedeno níže:

Nelze zahodit systémové databáze

I když můžeme zrušit uživatelské databáze provedením příkazu DROP DATABASE

DROP DATABASE AdventureWorks

Pokud se pokusíme ZRUŠIT kteroukoli ze systémových databází, zobrazí se chyba, jak je uvedeno níže:

Vlastníka systémových databází nelze změnit

Vlastníkem systémové databáze je sa ve výchozím stavu. nelze to změnit. Pokusy o přejmenování vlastníka systémové databáze způsobí chyby.

Existuje však výjimka. Je možné upravit vlastníka msdb databáze.

use [master];
GO
ALTER AUTHORIZATION ON DATABASE::[master] TO [RRJ\RRJ]
GO

Název databáze systémových databází nelze změnit

Pokud se pokusíme přejmenovat systémové databáze, zobrazí se chybová zpráva, jak je uvedeno níže:

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

Řazení systémových databází nelze změnit

Systémové databáze jsou vytvořeny s názvem Collation zvoleným během instalace SQL Server. Po instalaci nelze řazení systémových databází změnit. Jediný způsob, jak změnit řazení systémových databází, je přeinstalovat instanci SQL Server se správným řazením.

Primární skupinu souborů systémových databází nelze nastavit na režim READ_ONLY

Protože systémová databáze zachycuje kritické informace související s instancemi SQL Server, SQL Server neumožňuje, aby primární datové soubory umístěné v primární skupině souborů byly nastaveny jako pouze pro čtení. .

V systémových databázích nelze povolit funkci zachycování dat

Tato funkce se používá ke sledování každé změny DML v databázi na sledovaných tabulkách. Pokud se pokusíme povolit funkci Change Data Capture v jakékoli systémové databázi, dojde k chybě:

use master
GO
exec sys.sp_cdc_enable_db

Nyní, když je nám jasný rozdíl mezi systémovými databázemi a databázemi uživatelů, můžeme podrobněji prozkoumat účely každé systémové databáze.

Hlavní databáze v SQL Server

Databáze hlavního systému obsahuje podrobnosti o konfiguraci klíče související s instancí SQL Server . SQL Server se na ně spoléhá při spuštění konkrétní instance. Pokud z nějakého důvodu není možné spustit hlavní databázi, nelze spustit ani instanci SQL Server.

Tyto klíčové údaje uložené v hlavní databázi zahrnují přihlašovací účty, podrobnosti o propojeném serveru, koncové body, nastavení konfigurace systému a podrobnosti o všech databázích uživatelů.

Nyní přichází otázka. Jak služba SQL Server ví, kde jsou k dispozici data a soubory protokolu hlavní databáze? Odpověď spočívá v konfiguračních parametrech spuštění služby SQL Server.

Chcete-li zobrazit parametry konfigurace spouštění instance SQL Server, měli bychom nejprve vědět o vestavěném nástroji s názvem SQL Server Configuration Manager . Pomáhá spravovat všechny služby související s SQL Serverem všech instancí dostupných na konkrétním serveru. Chcete-li zobrazit tato data, otevřete SQL Server Configuration Manager a zobrazí se seznam, jak je znázorněno níže:

Klikněte na Služby serveru SQL pro zobrazení seznamu Služeb dostupných na tomto serveru nebo PC:

Počkejte chvíli! Vypadá povědomě na services.msc výpis všech služeb dostupných na serveru, ale zobrazení pouze služeb souvisejících s SQL Serverem.

Otevřeme services.msc abyste viděli, jak to vypadá, a ověřili rozdíly mezi SQL Server Configuration Manager a services.msc porovnat, který z nich je lepší.

SQL Server Configuration Manager zobrazuje ID procesu služeb, které jsou aktuálně spuštěny. V services.msc jsme to nenašli . Tyto informace samozřejmě můžeme získat ze Správce úloh systému Windows, ale SQL Server Configuration Manager nám pomohl zobrazit je na jediném místě.

Nyní se podívejme na podrobný pohled. Klikněte pravým tlačítkem na službu SQL Server z services.msc . Zobrazí se následující nabídky:Obecné , Přihlásit se , Obnovení a Závislosti .

V SQL Server Configuration Manager klikněte pravým tlačítkem na SQL Server (MSSQLSERVER) služba> Vlastnosti . Uvádí níže uvedené nabídky – Přihlášení, Služba. FileStream, Advanced, Alwayson OnHigh Availability a Parametry spouštění .

Parametry spouštění služby, která ukládá umístění dat hlavní databáze a souborů protokolů byla dostupná pouze v SQL Server Configuration Manager .

Klikněte na Parametry spouštění pro zobrazení podrobností – pro stávající Parametry . Uvidíte následující informace:

Fyzické umístění hlavní databáze Datový soubor
Fyzické umístění hlavní databáze Soubor protokolu transakcí
Fyzické umístění Složky ErrorLog kde jsou umístěny chyby související se službou SQL Server.

Můžeme přidat další spouštěcí parametry, jako je Režim jednoho uživatele (-m) atd. K tomu musíme zadat potřebné hodnoty v Určení parametru při spuštění a klikněte na Přidat .

Všimli jsme si, že SQL Server Configuration Manager nejen zobrazuje pokročilé podrobnosti, ale také nám umožňuje provádět mnoho pokročilých konfigurací souvisejících se službou SQL Server. Osobně bych tedy doporučil používat SQL Server Configuration Manager k zastavení/spuštění služeb souvisejících s SQL Serverem ve srovnání s výchozí možností Services.msc.

Doporučené postupy pro hlavní databázi

Vzhledem k tomu, že hlavní databáze uchovává kritické podrobnosti o instanci SQL Serveru, doporučuje se při manipulaci s touto databází dodržovat osvědčené postupy.

Každá změna konfigurace na instanci serveru SQL bude uložena v hlavní databázi. V případě, že podle potřeby obnovujeme hlavní databázi z úplné zálohy, musíte vždy vytvořit úplnou zálohu hlavní databáze pro obnovení do nejnovějšího stavu.

I když SQL Server umožňuje uživatelům vytvářet uživatelské tabulky nebo jiné objekty v hlavní databázi, nedoporučuje se to dělat. Hlavní databáze by měla zůstat jednoduchá a čistá. Pokud potřebujete vytvořit uživatelské objekty v hlavní databázi, měli byste častěji provádět úplné zálohy hlavní databáze.

SQL Server podporuje možnost procedury spouštění k provedení určitých uložených procedur při spuštění instance SQL Server. Používá sp_procoption postup. Při používání této možnosti buďte opatrní, protože neoptimální kód nebo rekurzivní logika může ovlivnit dobu spuštění instance SQL Server.

Pokud se SQL Server nemohl spustit kvůli problémům s hlavní databází, musíme obnovit hlavní databázi z poslední známé dobré zálohy.

Databáze modelů na serveru SQL Server

Jak název napovídá, Modelová systémová databáze funguje jako model nebo šablona pro vytváření jakékoli uživatelské databáze, pokud jde o cestu k souboru, počáteční velikost, nastavení automatického růstu a model obnovy a další možnosti konfigurace .

Jakékoli uživatelské objekty, jako jsou tabulky, procedury atd., které jsou vytvořeny v modelových databázích, budou také automaticky vytvořeny v nových uživatelských databázích v dané instanci SQL Serveru.

Pojďme si to ověřit vytvořením nové tabulky v modelové databázi:

Pojďme zkontrolovat, zda je tato tabulka přítomna v databázi modelů:

Databáze modelu také ukládá výchozí cestu k souboru uživatelských databází, jak je uvedeno níže v části Vlastnosti databáze z msdb databáze.

Podle aktuální konfigurace Počáteční velikost souboru obou dat a Soubory protokolu je nastaveno na 8 MB s automatickým růstem pro oba nastaveným na 64 MB.

Pokud potřebujete vytvořit databázi uživatelů v jiné cestě k souboru namísto umístění souboru modelové databáze, můžeme ji upravit v Vlastnostech serveru této instance SQL Server.

V SSMS klikněte pravým tlačítkem na Server > Vlastnosti > Nastavení databáze . Zobrazit výchozí umístění databáze:

Změňte cestu k souboru na požadovanou cestu a klikněte na OK . Databáze uživatelů Data a Protokol soubory budou vytvořeny v nové cestě, kterou jste zadali.

Vytvořme novou databázi s názvem model_test a zkontrolujte cesty k novým databázovým datům a souborům protokolu spolu s vlastnostmi souboru Initial a Autogrowth a model_verify tabulky v nové databázi.

Pojďme ověřit model_test Cesty k datům a souborům protokolu. Klikněte pravým tlačítkem na model_test databáze> Vlastnosti > Soubory :

Jak vidíme, Data a Protokol soubory model_test databáze jsou vytvořeny podle cesty dostupné v modelové databázi. Hodnota počáteční velikosti souboru dat a souborů protokolu je 8 MB. Hodnota automatického růstu je 64 MB. Tyto hodnoty odpovídají konfiguraci modelové databáze.

Nyní zkontrolujeme, zda model_verify tabulka je vytvořena v testu modelu databáze. Můžeme vidět tuto novou databázi.

Kromě tabulek to platí pro pohledy, uložené procedury, funkce a jakékoli objekty vytvořené v modelových databázích.

Doporučené postupy pro databázi modelů

Vzhledem k tomu, že modelová databáze funguje jako šablona pro vytváření jakékoli nové uživatelské databáze, měli bychom při práci s ní implementovat níže uvedené postupy:

Kdykoli budete chtít implementovat jakékoli změny do konfigurace modelové databáze (např. počáteční velikost souboru, velikost automatického růstu, vytvoření, úpravu nebo odstranění uživatelských objektů), okamžitě proveďte úplnou zálohu modelové databáze.

Vzhledem k tomu, že všechny uživatelské objekty vytvořené v modelových databázích jsou vytvořeny v libovolných uživatelských databázích, přidávejte pouze požadované objekty. V opačném případě se ve všech uživatelských databázích vytvoří spousta nepotřebných objektů a vy strávíte spoustu času jejich tříděním a čištěním databází.

Nakonfigurujte parametry Počáteční velikost souboru a Autogrowth pro datové soubory a soubory protokolu. Pomáhá lépe spravovat velikost souborů dat a protokolů v uživatelských databázích a zlepšit výkon.

Databáze MSDB

Systémová databáze msdb ukládá níže uvedené důležité informace napříč systémovými tabulkami:

Položky související s SQL Server Agent, jako jsou úlohy, historie úloh, upozornění, operátoři, proxy atd.
Funkce SQL Server, jako je Service Broker a Database Mail s podrobnostmi o konfiguraci a historii.
Podrobnosti o zálohování a obnovení serveru SQL jsou uloženy v tabulkách databáze msdb.
Protokolovat konfigurace odesílání, profily replikačních agentů a konfigurace sběrače dat.
Plány údržby, balíčky SSIS a některé další podrobnosti.

Jinými slovy, systémová databáze msdb uchovává všechny důležité informace související se službami SQL Server Agent Services a některými dalšími souvisejícími službami.

Doporučené postupy pro databázi msdb

Databáze msdb ukládá mnoho důležitých konfiguračních informací souvisejících s SQL Server Agents, Jobs a Database Mail. Ukládá také historické detaily. Proto bychom měli při práci s databází msdb implementovat níže uvedené postupy:

V instanci serveru SQL Server s mnoha konfigurovanými databázemi nebo úlohami se velikost databáze msdb bude po určitou dobu neustále zvyšovat. Úplné zálohy by proto měly být implementovány pro databáze msdb denně spolu s jinými databázemi uživatelů. Pokud msdb obdrží mnoho důležitých informací, můžeme změnit model obnovy databáze msdb na Úplný a poté implementovat také zálohování protokolu transakcí.

I když SQL Server umožňuje uživatelům vytvářet uživatelské objekty v databázi msdb, doporučuje se nevytvářet žádné uživatelské tabulky ani objekty v databázi msdb a dále zvětšovat velikost databáze msdb.

Provádějte pravidelné čištění systémových tabulek msdb, abyste udrželi velikost databáze msdb pod kontrolou a předešli dopadům na výkon způsobeným velkým množstvím dat v několika tabulkách.

Databáze Tempdb

Systémová databáze tempdb lze považovat za globální pracovní oblast dostupnou všem uživatelům připojeným k instanci SQL Serveru k provádění jejich SELECT nebo jiných operací .

Databáze Tempdb bude obsahovat níže uvedené typy objektů, zatímco uživatelé provádějí své operace:

Dočasnými objekty vytvořenými explicitně uživateli mohou 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, například:
- Pracovní tabulky používané pro průběžné výsledky pro řazení, kurzory, řazení a dočasné velké objekty (LOB)
- Pracovní soubory pro operace Hash Join nebo Hash agregace
- Přechodné 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 UNION
Obchody verzí, které podporují správu verzí na řádcích, mají buď společné úložiště verzí, nebo online úložiště verzí sestavení indexu.

Při každém spuštění nebo restartu služby SQL Server bude databáze tempdb vytvořena znovu pomocí modelové databáze. tempdb je tedy jediná systémová databáze, kterou nelze zálohovat .

Pokud se jej pokusíme zálohovat, zobrazí se chyby:

Vzhledem k tomu, že používáme databázi tempdb téměř ve všech uživatelských operacích, představuje tato databáze významné omezení výkonu v několika verzích SQL Server. Počínaje SQL Serverem 2016 bylo společností Microsoft implementováno několik optimalizačních technik – probereme je později.

Než přejdeme k doporučeným postupům pro databázi tempdb, pojďme se rychle podívat na její datové soubory ve výchozí konfiguraci, jak je uvedeno níže:

Pro moji aktuální instanci SQL Server máme 4 datové soubory a jeden soubor protokolu pro databázi tempdb.

Počínaje SQL Serverem 2016 máme instalační program SQL Server, který nám umožňuje přidat více souborů do databáze tempdb. Výše uvedené 4 soubory s počáteční velikostí 8 MB a velikostí automatického růstu 64 MB byly vytvořeny pomocí výchozích možností uvedených níže.

Pokud máme v databázi tempdb jeden datový soubor, všechna logická jádra dostupná na serveru se pokusí o přístup ke stejnému datovému souboru tempdb, což vede k omezení výkonu.

Mít více datových souborů logicky spojí určitá jádra do jednoho souboru. Máme tedy menší spor o datové soubory tempdb. To zlepší dopad na výkon datových souborů tempdb.

Doporučené postupy pro databázi tempdb

Vzhledem k tomu, že databáze tempdb je jako globální pracovní oblast pro všechny aktivity uživatele, velikost databáze tempdb se zvyšuje na základě aktivit uživatele. Může to být problémové místo výkonu pro celou instanci SQL Server.

Proto bychom měli zavést následující postupy:

Umístěte soubory dat a protokolů tempdb na vysoce výkonné úložiště, abyste získali vyšší IOPS pro lepší výkon.
Zajistěte, aby byla databáze tempdb rozdělena do více datových souborů, abyste omezili spory a předešli problémům s výkonem v databázi tempdb.
- Pokud je počet logických jader menší než 8, můžeme mít na každé logické jádro jeden datový soubor tempdb. V naší testovací instanci jsme měli 4 logická jádra. 4 datové soubory na tempdb by tedy měly být dostatečné.
- Pokud je počet logických jader větší než 8, začněte s 8 datovými soubory a zvyšte o 4 datové soubory, pokud v databázi tempdb zaznamenáte problémy se spory a výkonem.
- Pokud je počet logických jader na serveru 32 nebo 64, můžeme začít s 8 datovými soubory. To znamená, že k jednomu datovému souboru jsou logicky přidružena 4 jádra nebo 8 jader.
  
  Pro větší srozumitelnost ohledně více datových souborů tempdb bych vám doporučil vynikající článek Paula Randala.
Ujistěte se, že datové soubory tempdb jsou nakonfigurovány s optimální počáteční velikostí souboru. V ideálním případě by toho mělo být dosaženo metodou pokusů a omylů. Tempdb s optimální počáteční velikostí souboru má tendenci narůstat méněkrát ve srovnání s tempdb konfigurovanou s menší počáteční velikostí souboru, která má tendenci se zvětšovat několikrát, což vede k fragmentaci. Například v aktuální konfiguraci jsou všechny soubory nakonfigurovány s počáteční velikostí souboru 8 MB, což je příliš málo pro zpracování zátěže SQL. Použijte tedy metodu Trial and Error a nastavte počáteční velikost souboru na 512 MB nebo 1 GB nebo na nějakou jinou hodnotu.
Ujistěte se, že všechny datové soubory tempdb jsou nastaveny na stejnou velikost. Vlastnosti automatického růstu musí být definovány stejně. V našem scénáři jsou všechny soubory nastaveny na automatický růst 64 MB. Nastavení velikosti automatického růstu na 512 MB nebo 1 GB nebo jakoukoli jinou vhodnou hodnotu pomáhá snížit častý automatický růst datových souborů tempdb.
Ujistěte se, že velikost počátečního souboru a automatický růst pro soubor protokolu tempdb jsou nakonfigurovány na optimální hodnotu podobnou datovým souborům tempdb. Vzhledem k tomu, že model obnovy tempdb je ve výchozím nastavení nastaven na Jednoduchý a nelze jej upravit, měla by stačit konfigurace počáteční velikosti souboru a vlastnosti autogrowth souboru protokolu tempdb.

Tempdb je zásadní pro výkon instance SQL Server. V našich dalších článcích se podrobně podíváme na časté problémy, se kterými se setkáváme na tempdb, a na to, jak jej optimálně zmenšit.

Databáze prostředků na serveru SQL Server

Databáze systému prostředků je jedinou systémovou databází pouze pro čtení, která není uvedena v seznamu systémových databází v SSMS, jak bylo vidět dříve.

ID databáze (dbid) databází prostředků ve všech instancích bude 32767, což je také maximální počet databází podporovaných v rámci instance SQL Server. Lze jej vyhledat ze souboru sys.sysaltfiles systém DMV. Provedení níže uvedeného SELECT dotazu na sys.sysaltfiles vrátí výsledkovou sadu zobrazující, kde jsou umístěny soubory dat a protokolů databáze prostředků:

Ve výše uvedené cestě můžeme vidět fyzické soubory databáze zdrojů. Datum změny udává čas instalace instance SQL Server nebo čas posledního použití aktualizací Service Pack (SP) nebo Kumulativní aktualizace (CU) na tuto instanci.

Databáze prostředků obsahuje všechny systémové objekty, například sys.objects , sys.databases , sys.sysaltfiles atd. fyzicky uvnitř něj. Tato databáze logicky uvádí všechny tyto objekty pod schématem sys napříč všemi databázemi dostupnými v instanci . Vzhledem k tomu, že zdrojová databáze je pouze pro čtení, nelze v ní vytvářet žádné uživatelské objekty ani data.

Databáze systému zdrojů byla zavedena počínaje SQL Serverem 2005, aby byl upgrade SQL Serveru na novou verzi SP nebo CU rychlejší. Před zavedením této možnosti všechny takové upgrady a aktualizace znamenaly, že se změny budou vztahovat na všechny databáze, takže proces upgradu bude komplikovanější a časově náročnější. Nyní jakýkoli upgrade verze SQL Server nebo aktualizace SP nebo CU pouze upgraduje nebo nahradí databázi prostředků.

Protože je databáze zdrojů pouze pro čtení a není viditelná pro uživatele, nevyžaduje žádný zásah uživatele. Pokud si přejete zahrnout záložní databázi prostředků do svého plánování vysoké dostupnosti nebo obnovy po havárii, proveďte zálohu souborů mssqlsystemresource.mdf a mssqlsystemresource.ldf po zastavení služeb SQL Server Services (služba SQL Server nedovolí kopírovat soubory, zatímco Služba SQL Server je spuštěna) a uložte ji na bezpečné místo. Dávejte pozor, abyste jej neaktualizovali na žádné instanci SQL Serveru s jinou verzí SP nebo úrovní CU, protože by to mohlo způsobit neočekávané problémy.

Distribuční databáze na serveru SQL Server

Databáze distribučního systému je srdcem replikace. Uživatelé mohou vytvořit nebo nakonfigurovat distribuční databázi jako součást nastavení replikace pomocí buď Průvodce konfigurací distribuce nebo Průvodce vytvořením publikace. Kroky vytvoření distribuční databáze jsme podrobně popsali jako součást mého předchozího článku o SQL Server Transactional Replication Internals.

Doporučené postupy pro distribuční databázi

Protože je distribuční databáze nezbytná pro funkci replikace, měli bychom implementovat následující postupy:

Přesuňte data a soubory protokolu distribuční databáze na disk s dobrým IOPS, abyste předešli problémům s výkonem distribuce.

Nakonfigurujte vlastnosti Initial File Size a Autogrowth distribuční databáze na lepší hodnotu, abyste předešli problémům s fragmentací.

Zahrňte distribuční databázi do úloh údržby plné zálohy databáze.

Zahrňte do úloh údržby indexu distribuční databáze, abyste se vyhnuli fragmentaci a problémům s výkonem.

V mém článku o vnitřních částech transakční replikace serveru SQL Server také naleznete doporučení ohledně dalších účinných postupů.

Závěr

Děkujeme, že jste si prošli další nabitý článek!

Doufám, že vám to pomohlo objasnit podstatu a účely systémových databází SQL Server a naučit se osvědčené postupy, jak se vyhnout problémům s výkonem u těchto databází.