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

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!

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

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!

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.