it-swarm-eu.dev

Kdy je v pořádku zmenšit databázi?

Vím, že zmenšení je ďábel: zvrátí pořadí stránek a je zodpovědný za rakovinu kůže, fragmentaci dat a globální oteplování. Seznam pokračuje ... Řekněme, že mám databázi o kapacitě 100 GB a smažu 50 GB dat - ne na jedné tabulce, ale na obecné prořezávání starých dat na úrovni celé databáze, které pokrývá 90% tabulky - jedná se o vhodný případ použití pro zmenšení databáze?

Pokud ne, jaké jsou vhodné kroky k vyčištění domu po odstranění tak vysokého procenta dat z databáze? Mohu myslet na dva: Znovu sestavit indexy a aktualizovat statistiky. Co jiného?

44
bumble_bee_tuna

Reorganizace a zmenšení se nikdy nedoporučuje.

Pokud můžete použít aplikace, které databáze slouží offline, můžete urychlit proces a snížit fragmentaci indexu odstraněním všech indexů a omezení primárních/cizích klíčů před smrštěním (to znamená, že se bude pohybovat pouze méně dat jako pouze datové stránky budou zamíchány, nikoli nyní neexistující indexové stránky, což urychlí proces), a poté znovu vytvoří všechny indexy a klíče.

Opětovné vytvoření indexů po zmenšení znamená, že by neměly být významně fragmentovány, a nechat je během zmenšování zmizet znamená, že jejich opětovné sestavení nezanechá mnoho malých „děr“ v alokaci stránky v souborech, které mohou později vyvolat fragmentaci.

Další možností, pokud můžete aplikace offline, je migrovat všechna data do nové databáze stejné struktury. Pokud je váš proces sestavení solidní, měli byste být schopni sestavit tuto prázdnou DB rychle, pokud ji nevytvoříte z aktuální DB (obnovit zálohu aktuální, zkrátit/odstranit veškerý obsah v tabulkách a provést úplné zmenšení).

Možná budete chtít zrušit všechny indexy v cíli a poté je znovu vytvořit, protože to může být mnohem efektivnější, když změníte hodně indexovaných dat (v tomto případě 100%). Chcete-li zrychlit proces kopírování, nechte datové soubory cílové databáze na různých fyzických jednotkách ke zdroji (pokud nepoužíváte SSD, v takovém případě nemusíte starat o omezení pohybů hlavy), můžete je přesunout až budete hotovi.

Také pokud vytvoříte cíl jako nový (namísto vyprázdnění kopie zdroje), vytvořte jej s počáteční velikostí, která bude obsahovat všechna aktuální data plus několik měsíců v růstu - to způsobí, že se kopírování dat opět zrychlí, protože během tohoto procesu nebude přidělovat nový prostor každou chvíli.

To může být lepší než použití zmenšení, protože migrace dat do nové databáze replikuje zamýšlenou akci operace zmenšení, ale potenciálně s mnohem menší fragmentací (což je nezamýšlený důsledek reorganizace a zmenšení). Zmenšení jednoduše vezme bloky od konce souboru a umístí je na první místo blíže k začátku, aniž by se snažilo udržovat související data pohromadě.

Mám podezření, že výsledek bude také efektivnější z hlediska prostoru, protože pravděpodobně bude později méně použitých stránek. Zmenšení pouze přesune stránky, které byly použity, kolem, přesunutí dat s větší pravděpodobností povede k úplným stránkám, zejména pokud vložíte do cíle v pořadí seskupeného klíče/indexu tabulky (kde tabulka obsahuje) a vytvoříte další indexy. poté, co všechna data migrovala.

Samozřejmě, pokud nemůžete aplikace přenést do režimu offline vůbec, stačí provést zmenšení, což je vaše jediná možnost, takže pokud opravd potřebujete získat zpět prostor, který s tím souvisí. V závislosti na vašich datech, přístupových vzorcích, běžné velikosti pracovní sady, kolik RAM server má atd.), Vnitřní interní fragmentace nemusí být nakonec tak významná.

Pro operaci kopírování by fungoval buď SSIS nebo základní T-SQL stejně dobře (volba SSIS může být méně efektivní, ale později snadněji udržovatelná). Pokud vytvoříte vztahy FK na konci spolu s indexy, můžete v obou případech udělat jednoduchý „pro každou tabulku, kopii“. Samozřejmě, že pro jednorázové použití je zmenšení + reorganizace pravděpodobně také v pořádku, ale ráda jsem lidi vyděsit, aby nikdy nebrali v úvahu pravidelné smršťování! (Znám lidi, kteří je plánují denně).

14
David Spillett

Bude databáze opět růst? Pokud ano, pak úsilí, které budete věnovat operacím smršťování, bude jen plýtvání, protože když máte zmenšenou velikost souboru a přidáte další data, soubor bude muset znovu růst a transakce musí počkat, až k tomuto růstu dojde. Pokud máte suboptimální nastavení automatického růstu a/nebo pomalou jízdu, bude tato růstová aktivita docela bolestivá.

Pokud databázi zmenšíte, na co budete využívat uvolněné místo na disku? Znovu, pokud si jen chcete tento prostor ponechat volný pro případ, že by se tato databáze znovu rozrostla, pak jen otáčíte koly.

To, co byste mohli zvážit, nyní, když už máte v souboru všechny volné místo, znovu vytvoří vaše indexy tak, aby byly lépe optimalizovány (a bude to mnohem méně bolestivé, když to budete mít, -) přemýšlejte o pokusu o změnu svetrů v malém šatníku oproti velké ložnici).

Takže pokud se nejednalo o významnou operaci vyčištění a vy opravdu nebudete znovu stoupat na stejnou úroveň dat, prostě bych to nechal tak, jak je, a zaměřil se na další oblasti optimalizace.

16
Aaron Bertrand

Pokud vám dochází nedostatek místa a vaše data by neměla být tak velká, pak se zmenší, ale poté znovu vytvořte své indexy pomocí vhodných faktorů plnění, které umožňují typický růst.

Pokud je vaším konečným cílem snížení velikosti zálohy, ujistěte se, že implementujete komplexní strategii zálohování, abyste vyčistili protokol transakcí a při zálohování db použijte možnosti komprese.

Nedoporučoval bych automatický růst o 5 GB, pokud obvykle nebudete očekávat růst 5 GB často. Jinak byste mohli mít občasné problémy s výkonem. Velikost vašich dat by měla být nejprve nastavena na to, co si myslíte, že je požadováno, řekněme, rok, a automatický růst by měl být nastaven na velikost, kterou jste testovali, neovlivní provozní výkon. Viz Nedotýkejte se tlačítka Zmenšit databázi na serveru SQL! od Mike Walsh.

Obnovení indexů před smrštěním způsobí, že indexy budou špatně rozloženy. Není dobré znovu stavět a zmenšovat. Zmenšování způsobuje, že indexy musí být upraveny, aby se obnovil prostor - takže přestavba předem, pak zmenšení je zbytečné. Viz Kdy použít automatické zmenšení Thomas LaRock.

2
GilesDMiddleton

Návrat k tomuto zpoždění. Stále však dlouho přemýšlíme a testujeme použití smršťování v našich testovacích prostředích. Podle tématu existuje jso časy, kdy je smršťování schůdnou možností. Ale vědět, kdy a jak ji použít, je životně důležité pro správné provedení jak z dlouhodobého, tak z krátkodobého hlediska.

V našem scénáři jsme nedávno přidali četné změny do naší velké databáze, včetně komprese, rozdělení, archivace a prostého starého odstranění nadbytečných dat. V důsledku toho klesla použitá část našeho primárního datového souboru na méně než polovinu toho, co bývala. Jaký je ale smysl přenášet veškerá ta zavazadla? Zejména proto, že na rozdíl od některých článků na webu, velikost vašich datových souborů PŘÍMO SOUVISEJÍ S DOBOU ZÁLOHOVÁNÍ/OBNOVENÍ. Je tomu tak proto, že na rozdíl od mnoha článků předpokládají scénáře skutečného života na každé stránce více dat než jen věci, které jste možná odstranili.

Přesněji řečeno, toto otevírá skvělý scénář pro zmenšování:

  1. Vytvořte skript, který najde všechny objekty a jejich filegroups ve vaší databázi (spousta příkladů online), použijte toto k vytvoření klauzulí přetažení a také k vytvoření definic pro každý z vašich indexů a omezení.
  2. Vytvořte nový soubor a skupinu souborů a proveďte výchozí nastavení.
  3. Vypusťte všechny neclusterované indexy (některé indexy mohou být omezení).
  4. Vytvořte své seskupené indexy v nové skupině souborů pomocí DROP_EXISTING = ON (což je btw, což je nesmírně rychlá, minimálně protokolovaná operace, která začíná v porovnání s mnoha alternativami).
  5. Znovu vytvořte své nekluzivní indexy.
  6. Nakonec SHRINK starý datový soubor (obvykle PRIMÁRNÍ).

Tímto způsobem zůstanou jediná data, která tam zůstanou, systémové objekty, statistiky, procedury a další. Zmenšování by mělo být mnohem, rychlejší a není potřeba žádná další údržba indexů na vašich hlavních datových objektech, které budou vytvořeny úhledně v pořadí a minimální riziko pro budoucí fragmentaci.

1
Kahn

Nevím, jestli by to nefungovalo lépe než reindexování po zmenšení, ale další možností by bylo vytvořit nový datový soubor, který je přiměřeně veliký, a přesunout do něj všechna data. V tom případě bych nejprve udělal reindex, abyste věděli, jaká je skutečná velikost dat. Jeden úlovek je, že pokud je to první soubor v primárním datovém souboru, nemyslím si, že jej můžete vyprázdnit. Měli byste být schopni je zmenšit, poté posunout data zpět a tím by se zabránilo obrácení stránky. Pokud se však díváte na přechod do solidního stavu, nemělo by to nijak výrazně změnit.

1
cfradenburg