sql >> Databáze >  >> RDS >> Sqlserver

Časté chyby DBA v MS SQL Server

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í.

  1. 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.
  2. 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í.
  3. 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

  4. 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ů.
  5. Š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.
  6. Š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.
  7. 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.
  8. 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.


  1. MySQL - vynutit nepoužívat cache pro testování rychlosti dotazu

  2. ORA-00947 Při globální deklaraci typu není dostatek hodnot

  3. Jak mohu provést porovnání řetězců SQL s rozlišováním malých a velkých písmen na MySQL?

  4. Mám použít pravidlo CASCADE DELETE?