V tomto článku se podíváme na chyby DBA, jejichž důsledky byly docela citelné a se kterými jsem se musel vypořádat.
Účelem článku je zabránit uživatelům v opakování těchto chyb. Někdy je špatná zkušenost ještě cennější než pozitivní.
- Procentuální přírůstek databázových souborů
Vzhledem k tomu, že růst souborů v databázi je poměrně náročná operace, může se zdát, že nastavení tohoto růstu v procentech může být dobrý nápad. Souhlasím s tím, že mnoho pokynů doporučuje nastavit pevný přírůstek v MB, spíše než procento. Důvody však nevysvětlují. Na základě praxe se nedoporučuje nastavovat přírůstek databázového souboru nad 1 GB, protože MS SQL Server alokuje 2krát 1 GB místo 2 GB najednou.
Také pokud alokujete méně než 32 MB , dříve nebo později se databáze jednoduše zpomalí. Je tedy lepší nastavit pevný přírůstek databázových souborů od 32 do 1024 MB. Proč však není možné určit procentuální přírůstek databázových souborů? Ukazuje se, že jakmile je soubor menší než 1 MB, DBMS tuto hodnotu zaokrouhlí na 0 MB a přestane tento soubor zvětšovat. V důsledku toho je systém mimo provoz. Chcete-li zjistit, o kolik potřebujeme soubor zvětšit, jednoduše proveďte denní analýzu, abyste zkontrolovali, kolik každý soubor získává v MB, a nastavte příslušné číslo v rozsahu od 32 do 1024 MB. Statistiky růstu databázových souborů můžeme sbírat následujícím způsobem. - Tabulka má mnoho cizích klíčů
Zkusili jste někdy zkontrolovat plán při odstraňování alespoň jednoho řádku z tabulky, na kterou odkazují téměř stovky jiných tabulek? Budete překvapeni, kolik tam je vnořených smyček. Všechny jsou kontroly cizích klíčů. Proto, pokud jsou tabulky velké (přes jeden milion záznamů), je lepší zakázat cizí klíče pro tabulku, ve které budou data smazána. Poté budete muset vymazat všechna potřebná a související data. Poté povolte cizí klíče. Podobná situace nastává u kaskádových aktualizací a mazání. Pokud existuje mnoho externích odkazů (stovky), pak smazání byť jednoho řádku může vést k dlouhému a velmi rozsáhlému zablokování. - Mnoho zbytečných indexů
Velmi často se v pokynech můžete setkat s tím, že při vytváření cizích klíčů je nutné vytvářet indexy, zejména při použití těchto klíčů pro spojení. Musíte zkontrolovat, zda se používají indexy, jinak tyto zbytečné indexy pouze zpomalí jakékoli operace úpravy dat. Chcete-li to zkontrolovat, použijte následující dotaz:select DB_NAME(t.database_id) as [DBName] , SCHEMA_NAME(obj.schema_id) as [SchemaName] , OBJECT_NAME(t.object_id) as [ObjectName] , obj.Type as [ObjectType] , obj.Type_Desc as [ObjectTypeDesc] , ind.name as [IndexName] , ind.Type as IndexType , ind.Type_Desc as IndexTypeDesc , ind.Is_Unique as IndexIsUnique , ind.is_primary_key as IndexIsPK , ind.is_unique_constraint as IndexIsUniqueConstraint , t.[Database_ID] , t.[Object_ID] , t.[Index_ID] , t.Last_User_Seek , t.Last_User_Scan , t.Last_User_Lookup , t.Last_System_Seek , t.Last_System_Scan , t.Last_System_Lookup from sys.dm_db_index_usage_stats as t inner join sys.objects as obj on t.[object_id]=obj.[object_id] inner join sys.indexes as ind on t.[object_id]=ind.[object_id] and t.index_id=ind.index_id where (last_user_seek is null or last_user_seek <dateadd(year,-1,getdate())) and (last_user_scan is null or last_user_scan <dateadd(year,-1,getdate())) and (last_user_lookup is null or last_user_lookup <dateadd(year,-1,getdate())) and (last_system_seek is null or last_system_seek <dateadd(year,-1,getdate())) and (last_system_scan is null or last_system_scan <dateadd(year,-1,getdate())) and (last_system_lookup is null or last_system_lookup <dateadd(year,-1,getdate())) and t.database_id>4 and t.[object_id]>0 -- system databases are excluded
- Neefektivní využívání zdrojů
Často se doporučuje ukládat transakční protokol a databázový soubor na různá úložná zařízení. Pokud používáte RAID 10 se 4 a více SSD disky, pak nemá smysl izolovat soubory od sebe. Pro vyšší rychlost lze v případě potřeby databázi tempdb uložit na disk, který je rozdělen z RAM. Také příliš velké množství paměti RAM poskytované systému DBMS způsobí, že systém DBMS zaplní veškerou paměť irelevantními plány dotazů. - Špatné zálohy
Vždy je nutné vytvořené zálohy nejen zkontrolovat, ale také přesunout na zkušební stojan a obnovit. To vše je potřeba automatizovat s dalším upozorněním správců na problematické i úspěšné obnovy. - Špatná odolnost proti selhání
Před vytvořením clusteru dvou nebo více serverů se musíte ujistit, že systém ukládání dat je také odolný proti selhání. Pokud druhý selže, celá tolerance selhání se sníží na nulu. - Složité diagnostika bez jednoduchých kontrol
Pokud dojde k výpadku systému, musíte nejprve zkontrolovat protokoly MS SQL Server a poté se ponořit hlouběji. Nejprve byste měli provést jednoduché kontroly a poté přistoupit ke komplexní diagnostice. - Ztracené stoly
Tabulky lze rozšířit o nepotřebná data, která je třeba archivovat do samostatné databáze nebo smazat. Kromě toho se tabulky již nesmí používat.
To jsou situace, se kterými jsem se setkal. Proto bych rád doporučil neopakovat výše uvedené chyby.
Chcete se podělit o své zkušenosti nebo podobné chyby při správě databází, dejte mi vědět – rád je prodiskutuji.