it-swarm-eu.dev

Plán údržby serveru SQL - osvědčené postupy týkající se úkolů a plánování

Mám za úkol navrhnout plán údržby pro naše databáze Sql Server 2005. Vím, že pro zálohy chci provádět denní úplné zálohy databáze a transakční zálohy protokolu každých 15 minut. Mým problémem je zjistit, jaké další úkoly chci dělat a jak často je mám dělat.

Zatím to mám na mysli. Opravte mě, pokud se vyskytnou nějaké nedostatky v mém myšlení nebo lepší způsob, jak toho dosáhnout.

  1. Zálohování - všechny tabulky, plná záloha (denně)
  2. Záloha - vybrané tabulky, úplná záloha (hodinová)
  3. Zálohování - Protokoly transakcí (každých 15 minut)
  4. Zkontrolujte integritu databáze (denně)
  5. Reorganizovat index (denně)
  6. Aktualizovat statistiky (denně)
  7. Zmenšit databázi (týdně)
  8. Znovu vytvořit index (týdně)
  9. Úklid údržby (denně)

Před časem jsem si vzpomněl na čtení (když jsem si stanovil podobný plán v jiné práci), že některé z těchto úkolů nemusí být prováděny denně nebo by neměly být prováděny denně. Které z nich mě unikají. Mohl bych použít trochu vodítka pro vytvoření lepšího plánu údržby, který sníží ztrátu dat při katastrofě, ale nebudu zdanit systém, když běží ve špičce (a také zvýšit výkon).

44
Josh

Josh,

Toto je velmi běžný úkol pro všechny DBA a správná odpověď NENÍ stejná pro každého a pro každý server. Stejně jako mnoho dalších věcí, záleží na tom, co potřebujete.

Rozhodně nechcete spustit "Shrink Database", jak již bylo uvedeno. Jeho ZLOŽKA na výkon a níže uvedená reference vám ukáže proč. Způsobuje fragmentaci disku i indexu, což může vést k problémům s výkonem. Lepší je předběžná alokace velké velikosti pro datové a log soubory, aby se autogrowth NIKDY nezačal.

Nerozuměl jsem vašemu # 2. vybrané tabulky plná záloha. Můžete o tom více rozpracovat?

Pokud jde o reorganizaci indexu, aktualizaci statistik a nové sestavení indexu, musíte být opatrní, jak to uděláte, jinak skončí s použitím více zdrojů a také skončí s problémy s výkonem.

Když znovu sestavujete indexy, statistiky indexů se aktualizují pomocí fullscan, ale pokud aktualizujete statistiky poté, budou tyto aktualizovány znovu s výchozím vzorkem (což závisí na několika faktorech, obvykle 5% tabulky, když velikost tabulky> 8 MB), což může vést k problémům s výkonem. V závislosti na edici, kterou máte, budete moci provést online obnovu indexů. Správným způsobem provádění této činnosti je kontrola velikosti fragmentace a podle toho buď provést nové sestavení indexu, nebo indexové reorganizaci statistik + aktualizace. A také možná budete chtít zjistit, které tabulky potřebují častěji aktualizovat statistiky a zkusit aktualizovat statistiky častěji.

Plány údržby jsou v pořádku, ale je těžké z nich získat to nejlepší, když tyto úpravy provedete, pokud se nemůžete přihlásit k SSIS a Tweak MP. proto raději NEPoužívám a používám Ola Hallengrenovy bezplatné skripty , které jsou robustnější než MP. Také bych doporučil dohlédnout na odkazovaný článek Paula Randala o tomto tématu.

Odkaz: http://technet.Microsoft.com/en-us/magazine/2008.08.database.aspx

Toto není komplexní odpověď na vaši otázku, ale dobrý výchozí bod. HTH a dejte nám vědět, pokud máte nějaké další dotazy/komentáře.

30
Sankar Reddy

Podělím se o své zkušenosti, i když jste již přijali odpověď. Možná to bude užitečné :-).

  1. Plná denní záloha (denně) - skvělá, ale nezapomeňte zkontrolovat místo a odstranit staré soubory po určité předdefinované době.
  2. Zálohujte vybrané tabulky (každou hodinu) - nechápejte, proč to potřebujete, raději byste měli použít rozdílové zálohy. Jak zálohujete pouze určité tabulky: SSIS, skripty, bcp? Pokud jde o zálohy diffu, neplánujte je příliš často, protože ukradnete roli zálohování protokolu.
  3. Zálohy protokolu transakcí (každých 15 minut) - skvělé, jste si jisti, že potřebujete všechny databáze? Používají všechny databáze model plné obnovy nebo ne?
  4. Zkontrolujte integritu db - ano, ale musíte se ujistit, že prostředí nezabijete. Kontrolní příkazy DBCC jsou velmi sobecké o zdrojích a skenují kompletní dbs, takže je třeba je naplánovat v době mimo provoz.
  5. Reorganizovat index (denně) - netlačte jej, udělejte to pouze v případě potřeby. Zkontrolujte index DMV týkající se fragmentace a reorganizujte pouze na základě potřeb. Přesunul bych všechny operace indexování a statistiky na jeden týdenní úkol.
  6. Aktualizovat statistiky (denně) - viz moje odpověď k předchozí otázce. Namísto pouhé aktualizace všech statistik byste měli každý den lépe kontrolovat, kdy byly statistiky naposledy aktualizovány, a pouze v některých případech je aktualizovat.
  7. Zmenšit databázi (týdně) - Oh, ne. Přečtěte si prosím článek o zmenšování souboru.
  8. Znovu sestavit index (týdně) - viz 5.
  9. Vyčištění údržby (denně) - v pořádku.

  10. Měli byste také přidat úkol pro ověření záloh - existuje verze příkazu RESTORE (ověřte pouze .. pokud si vzpomínám správně) - řekněme týdně, i když to dávám přednost denně.

Zmiňujete, že chcete být chráněni v případě ztráty dat, takže bych řekl, že v tomto postupu údržby musíte přidat systémové databáze. A také dávejte pozor na zálohování souborů na jiném počítači než na samotném serveru. Ponechte někde soubor s tím, co dělat v případě, že potřebujete znovu vytvořit master db, msdb..etc. Hodně štěstí s vaším úkolem!

22
Marian

Pozdní odpověď, ale mohla by být užitečná i pro jiné čtenáře.

Prosím, mějte na paměti, že existuje spousta úkolů údržby nebo hlášení, které můžete vytvořit, které s sebou nesou neviditelná rizika.

Co by se stalo, kdyby se disk zaplnil během diferenciálních záloh prováděných denně? A co když úloha pro obnovu indexu běží neobvykle dlouho? Co když proces načítání dat způsobuje rozsáhlé soupeření se zdroji a přináší kolena normální operace? To vše jsou plánované události, ale přesto mohou způsobit značné narušení samotných procesů, které se snažíme zabezpečit.

Vždy zvažte, jak různé úlohy interagují, a časujte je tak, aby nedocházelo k překrývání citlivých úkolů nebo úkolů náročných na zdroje.

Doporučuji nejprve si přečíst tento článek: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

Popisuje, jak provádět důležité úkoly údržby v SQL Server - bez rizika. Například - do svých úloh údržby můžete zabudovat jednoduché kontroly, které ověřují dostupné zdroje a také to, co bude operace vyžadovat před provedením. To vám umožní zajistit, aby vaše prostředí zvládlo to, co se chystáte udělat, a zrušit významnou chybu, pokud jsou zdroje nedostatečné.

10
Alex Kirilov
  1. Vypadá dobře

  2. Můžete mít prospěch z provádění diferenciálních záloh zde. Podívejte se do nich pro jistotu

  3. Vypadá dobře

  4. Vypadá dobře

  5. Jak bylo uvedeno výše, zmenšení databáze je špatné, protože vytváří fyzickou fragmentaci vašich dat a souborů protokolu, což způsobuje více náhodných IO).

5, 6 a 8: Viz následující.

Ty skutečně jdou ruku v ruce, protože indexy spoléhají na aktuální statistiky a pořadí těchto operací je docela důležité. Základní metoda, kterou používám, což sice nemusí fungovat pro všechny, je, že provádím dvě kola údržby indexů. Nejprve provedu seskupené indexy a poté nekluzové indexy. Metoda, kterou používám pro oba, je následující. Pokud je index dostatečně velký a dostatečně fragmentovaný (sys.dm_db_index_physical_stats), budu index znovu sestavovat (což zahrnuje aktualizaci statistik s plnou kontrolou). Pokud je index příliš malý na opětovné sestavení nebo není dostatečně fragmentovaný pro opětovné sestavení (méně než 100 stránek a mezi 5% a 15% fragmentací), nejprve provedu reorganizaci indexu. Poté provedu aktualizaci statistik s úplným skenováním. Pokud není index dostatečně fragmentován pro některou z těchto částí údržby indexu, statistiku budu aktualizovat úplným skenováním.

Nyní se to týká statistik indexů, ale zanedbává se, že udělá cokoli se statistikami sloupců. Týdenně aktualizuji statistiky sloupců.

Doufám, že to nějakým způsobem pomohlo!

7
Matt M

Naklonila jsem se k vaší poznámce „Ztráta dat by mohla mít právní následky“.

Pak určitě chcete získat výkonný nástroj třetích stran (jako je DPM), který dokáže zpracovat zálohy (a zotavit se z katastrofických událostí v blesku a minimální rozruch kolem) mnohem rychleji a mnohem lépe než jakýkoli skript, který můžete vytáhnout z Internetu.

Zálohování je jedna věc. Vědět, jak je používat v případě nouze, je další.

Nezapomeňte, že pokud se chystáte obnovit zálohu po závažném selhání, pravděpodobně jste již pod tlakem stresu a tlaku. Nepotřebujete dodatečné břemeno kopat a bezchybně zapisovat příkaz RESTORE DATABASE s 12 soubory protokolů transakcí ... A modlitba vás nezklame ...

Na svém pracovišti mohu pomocí DPM obnovit nebo obnovit databázi 350 Gb do libovolného bodu během 5 minut za poslední týden. S rozhraním GUI. Stojí to za to v mé knize.

Pokud jde o zbytek, určitě se podívejte do indexového skriptu Oly Hallengrenové a upravte parametry podle svých potřeb. Osobně jsem to spojil s naplánovaným úkolem, který ho zprovozní každou hodinu na hodinu bez opětovného prohlížení, takže zpracovává nejhorší indexy pokaždé a vynucuje úplné opakování fragmentace každou sobotu, nebo když jsou všechny indexy v seznamu byli defragmentováni.

Nakonec přidám svůj hlas do skupiny „Nezmršťujte své soubory automaticky, nikdy“. File Shrink je nástroj, který se používá sporadicky, když dojde k nepravidelné události, která přeroste vaše protokoly nebo soubory DB (nekonečná smyčka nebo podobně). Neměl by to být nástroj údržby. Pokud máte tlak na disku, zmenšení zmenší nevyhnutelnou dobu.

3
Philippe