v úvodní kapitole knihy Craiga Mullina správa databází říká: „v mnoha ohledech je podnikání dnes daty“. Ve většině organizací je osobou odpovědnou za ochranu dat správce databáze … vy.

to je pravda; celý podnik je ve vašich schopných rukou, běží na tomto serveru, který nikdy nespadne, se všemi těmi koncovými uživateli, kteří nikdy nedělají chyby pomocí aplikací, vytvořených těmi vývojáři, kteří píší bezchybný kód poprvé, pokaždé, s pomocí této nové kooperace, která má díky vašemu šéfovi privilegia „sa“.

OK. Přestaň brečet. Existují věci, které můžete udělat pro ochranu dat serveru SQL pod vaší péčí a jedním z nejdůležitějších je pravidelné zálohování databáze.

zálohy

Microsoft v SQL Server Books Online definuje zálohy jako:

kopie dat, která se používá k obnovení a obnovení dat po selhání systému

zálohy SQL mohou být vytvořeny mnoha způsoby a mohou zahrnovat všechna nebo některá data, stejně jako část protokolu transakcí. Zatímco tento článek je zaměřen na syntaxi 2005, většina konceptů je použitelná pro 2000. To je obrovské téma. V nejlepším případě poškrábám povrch a dám vám dostatek informací, abyste znovu nezačali plakat. Po přečtení tohoto, měli byste být schopni nastavit přiměřenou sadu záloh pro váš systém.

modely obnovy

aby bylo možné začít pracovat na zálohách, obchodní potřeby definují model obnovy databáze. V podstatě model obnovy definuje, co budete dělat s daty protokolu transakcí.

existují tři modely obnovy: plné, jednoduché a hromadné. To je docela snadné definovat:

• Simple-v jednoduchém režimu obnovení, protokol transakcí není zálohována, takže si můžete obnovit pouze na nejnovější plné nebo diferenciální zálohování.
• Full-v režimu plné obnovy můžete zálohovat databázi a protokol transakcí, takže můžete obnovit databázi na libovolném místě v čase.
• hromadné přihlášení-v režimu hromadného přihlášení je většina transakcí uložena v protokolu transakcí, ale některé hromadné operace, jako je hromadné zatížení nebo vytváření indexů, nejsou zaznamenány.

dva nejčastěji používané režimy jsou jednoduché a plné. Nemusíte nutně předpokládat, že k ochraně svých dat musíte vždy použít úplné zotavení. Je to obchodní rozhodnutí. Podnik vám řekne, zda se potřebujete zotavit do určitého časového okamžiku nebo zda potřebujete pouze poslední úplnou zálohu. Bude definovat, zda jsou vaše data obnovitelná jinými prostředky, jako je ruční zadávání, nebo pokud musíte chránit co nejvíce, jak to přijde přes drát. Jednoduché obnovení používáte, pokud si můžete dovolit ztratit data uložená od posledního úplného nebo diferenciálního zálohování a / nebo prostě nepotřebujete obnovu do určitého okamžiku. V jednoduchém režimu musíte Obnovit všechny sekundární skupiny souborů pro čtení/zápis při obnovení primárního souboru. Jednoduché používáte většinou na sekundárních databázích, které nejsou absolutně důležitou součástí podniku nebo systémů hlášení, s přístupem pouze pro čtení, takže se nemusíte obávat protokolu transakcí. Používáte plně, pokud je každý bit dat životně důležitý, musíte se obnovit do určitého časového okamžiku nebo, obvykle v případě velmi velkých databází (VLDB), musíte obnovit jednotlivé soubory a skupiny souborů nezávisle na jiných souborech a skupinách souborů.

s jednoduchými i úplnými modely obnovy můžete nyní spustit zálohu pouze pro kopírování, která vám umožní zkopírovat databázi do záložního souboru, ale neovlivní protokol, diferenciální plány zálohování nebo obnovení dopadu do určitého časového bodu. Pokusím se v článku prozkoumat co nejvíce těchto témat, ale ne soubory a skupiny souborů.

práce s jednoduchým obnovením

dost mluvit. Pojďme se pustit do spouštění záloh. Předpokládejme, že jsme v jednoduché obnově na malé až středně velké databázi. Budu používat AdventureWorks pro všechny ukázkové skripty. Chcete-li jej nastavit na jednoduché zotavení:

nejjednodušší strategií zálohování je v pravidelných intervalech spouštět následující příkaz SQL Server backup, který provede úplnou zálohu databáze:

co je to za psaní, na které se ptáš? Nemáme GUI nástroje pro zpracování práce za nás? Ano, nejjednodušší zálohy lze provádět pomocí SQL Server Management Studio. Pokud se však chcete dozvědět a pochopit, co pro vás Management Studio dělá, nebo pokud chcete nějakou jemnozrnnou kontrolu nad tím, co je zálohováno, jak a kde, pak budete muset vylomit klávesnici a odložit myš.

výše uvedený příkaz vyvolá základní zálohu na disk. Většina DBA znám zálohování do souboru a pak škrábání souborů na pásku nebo jiné médium. Je to proto, že soubory na disku se snadno a rychle obnovují, zatímco média mohou být někdy trochu bolestivá. Například obecně máme v našich souborových systémech zálohy za dva až tři dny pro okamžité obnovení. Do páskových systémů jdeme pouze v případě, že potřebujeme spustit obnovení starších záloh.

co ten příkaz udělal? Udělal kopii všech odevzdaných dat v databázi. To také zkopírovány nezávazné položky protokolu. Používají se během obnovy k odevzdání nebo vrácení změn, ke kterým došlo v datech během procesu zálohování.

zálohování pouze pro kopírování

zálohování databáze obvykle ovlivňuje další procesy zálohování a obnovy. Například po spuštění předchozího příkazu by všechny rozdílné zálohy (záloha, která pouze kopíruje data změněná od poslední zálohy) používala jako výchozí bod pro změny dat, nikoli zálohu, kterou jste spustili včera v noci. Jak již bylo uvedeno výše, SQL 2005 zavádí nový koncept záloh, copy_only zálohy, které nám umožňují zabránit přerušení cyklu:

už jsme našli jeden z těch podrobnějších okamžiků, kdy by vám manažerské Studio nepomohlo. Pokud chcete kopii pouze zálohovat, musíte použít příkazový řádek.

diferenciální zálohy

Předpokládejme na chvíli, že jsme stále v jednoduché obnově, ale máme co do činění s větší databází, řekněme něco nad 100 GB. Úplné zálohy mohou skutečně začít proces trochu zpomalit. Místo toho jsme se po konzultaci s firmou rozhodli provést týdenní úplné zálohování a denní diferenciální zálohy. Diferenciální zálohy zálohují pouze datové stránky, které se změnily od poslední úplné zálohy. Následuje příkaz SQL backup pro provedení diferenciální zálohy:

nyní, pokud bychom museli obnovit tuto databázi, nejprve bychom šli na poslední úplnou zálohu, obnovili ji a poté obnovili diferenciální zálohy v pořádku (více o tom později).

existuje řada dalších možností zálohování, které zde nebudu podrobně popisovat. Přečtěte si knihy on-line vidět podrobnosti o BLOCKSIZE, EXPIREDATE, RETAINDAYS, heslo, jméno, statistiky, a tak dále.

můžete také spustit příkaz, který zkontroluje integritu zálohy databáze. Nekontroluje integritu dat v rámci zálohy, ale ověřuje, zda je záloha správně naformátována a přístupná.

úplné obnovení a zálohování protokolu

primárně jsme pracovali na databázi, která byla v jednoduchém režimu obnovy (dříve se tomu říkalo zkrácený protokol na kontrolním stanovišti). V tomto režimu nezálohujeme protokoly transakcí pro pozdější obnovu. Každá záloha v rámci tohoto mechanismu je zálohování databáze. Zálohování protokolu prostě není možné.

data jste však chránili pouze od poslední dobré zálohy, ať už plné nebo diferenciální. Změňme naše předpoklady. Nyní máme co do činění s velkou, kritickou aplikací a databází. Chceme být schopni obnovit tuto databázi až do poslední minuty. To je velmi důležitý bod. Teoreticky, protože záznamy protokolu jsou uloženy a zálohovány, jsme chráněni až do okamžiku selhání. Některé poruchy však mohou způsobit poškození protokolu, což znemožňuje obnovení do určitého časového bodu. Musíme tedy určit, jaká bude přiměřená minimální doba mezi zálohami protokolu. V tomto případě můžeme žít s ne více než 15 minut v hodnotě ztracených dat.

Začněme tím, že naši databázi uvedeme do režimu úplné obnovy:

poté, na plánovaném základě, v tomto případě každých 15 minut, spustíme příkaz SQL backup pro protokol transakcí:

tento skript bude zálohovat odevzdané transakce z protokolu transakcí. Má značky v souboru, které ukazují čas zahájení a zastavení. Po úspěšném dokončení se protokol zkrátí a z protokolu transakcí se vyčistí odevzdané transakce, které byly zapsány do záložního souboru. V případě potřeby můžete použít příkaz s NO_TRUNCATE k zachycení dat z protokolu transakcí bez ohledu na stav databáze, za předpokladu, že je online a není v nouzovém stavu. To je pouze pro případ nouze.

Všimněte si, že v tomto případě nepoužíváme příkaz INIT, ale můžete tak učinit, pokud se rozhodnete. Při zálohování protokolu máte možnosti:

1. spusťte všechny zálohy do jednoho souboru, kde se stohují a vše, co musíte udělat při obnovení (později), je procházet je.
2. pojmenujte zálohy jednoznačně, pravděpodobně pomocí data a času v řetězci.

v tomto druhém případě bezpečnost říká, použijte INIT, protože vykonáváte maximální kontrolu nad tím, co se zálohuje, a budete moci přesně vědět, co je záloha, kdy byla pořízena a odkud na základě názvu. To je další místo, kde operační zálohy z příkazového řádku vám dává větší kontrolu než GUI. Oba přístupy jsme použili v našich systémech z různých důvodů. Můžete se rozhodnout, co je nejlepší pro vaše technologické a obchodní požadavky.

většina možností dostupných pro zálohování databáze je zahrnuta v zálohování protokolu, včetně COPY_ONLY. To by vám umožnilo zachytit sadu transakčních dat, aniž by to ovlivnilo protokol nebo další naplánovanou zálohu protokolu. To by bylo užitečné pro přenos výrobních dat do jiného systému pro řešení problémů atd.

pokud máte databázi nastavenou na úplné obnovení, musíte spustit zálohy protokolu. Někdy lidé zapomínají a protokol transakcí roste do té míry, že zaplní diskovou jednotku. V tomto případě můžete spustit:

připojení NO_LOG k záloze protokolu a neurčení umístění protokolu způsobí odstranění neaktivní části protokolu a provede to bez samotného záznamu protokolu, čímž porazí celou diskovou jednotku. To se absolutně nedoporučuje, protože přeruší řetězec protokolu, řadu záloh protokolu, ze kterých byste databázi obnovili do určitého časového okamžiku. Společnost Microsoft doporučuje spustit úplnou zálohu ihned po použití tohoto příkazu. Dále varují, že toto prohlášení může být v budoucím vydání zastaralé.

obnovení databází

stejně důležité jako zálohy serveru SQL jsou a jsou životně důležité, jsou zbytečné bez možnosti obnovení databáze.

obnovení úplné zálohy databáze

obnovení úplné zálohy databáze je stejně jednoduché jako vytvoření:

je to opravdu tak jednoduché-pokud, jak jsme zálohovat vše do souboru, jako by to bylo záložní zařízení. V takovém případě budete muset určit, který soubor v „zařízení“ přistupujete. Pokud nevíte, který soubor, budete muset vygenerovat seznam:

to vám dá stejný seznam, jaký jsem ukázal výše z Management Studio. Pokud bychom tedy chtěli obnovit druhý soubor ve skupině, zálohu COPY_ONLY, vydali byste následující příkaz:

Bohužel, Pokud sledujete, možná zjistíte, že jste právě vygenerovali tuto chybu:

to znamená, že vaše databáze je v režimu úplné obnovy, ale nezálohovali jste „ocas protokolu“, což znamená transakce zadané od posledního spuštění zálohy. Tento požadavek můžete přepsat, pokud změníte předchozí syntaxi na:

to je poprvé, co jsme naskládali klauzule S (S FILE=2 a nahrazením je reprezentováno jako s FILE=2, nahradit), ale nebude to poslední. Přečtěte si knihy online. Většina příkazů s klauzulí může být použita v kombinaci s ostatními.

co se stane, pokud chceme obnovit jinou databázi než původní? Například chceme vytvořit kopii naší databáze ze samostatné zálohy. Možná to chceme přesunout na server podpory výroby, kde na tom budeme dělat nějakou práci, odděleně od produkční kopie databáze. Pokud vezmeme jednoduchý přístup, studna, zkuste to:

v takovém případě byste měli vidět celou řadu chyb týkajících se souborů, které nejsou přepsány. Opravdu můžete vytvářet nové databáze ze záloh, ale pokud to děláte na Serveru s existující databází, budete muset změnit umístění fyzických souborů pomocí logických názvů. Chcete-li znát logické názvy souborů pro danou databázi, spusťte to před pokusem o přesun souborů:

to pak může být použito k identifikaci příslušných logických jmen za účelem generování tohoto skriptu:

obnovení diferenciální zálohy

poslední metodou je použití diferenciální zálohy. To vyžaduje dva kroky. Nejprve obnovíme databázi, ale s kroucením a pak použijeme diferenciální zálohu:

většina z toho je pravděpodobně samozřejmá na základě toho, co jsme již pokryli. Jedním vráskem je zahrnutí klíčového slova NORECOVERY. Velmi jednoduše, během obnovení, transakce mohly být zahájeny během procesu zálohování. Některé z nich jsou kompletní a některé ne. na konci obnovení jsou dokončené transakce vráceny do databáze a neúplné transakce jsou vráceny zpět. Nastavení NORECOVERY udržuje transakce otevřené. To umožňuje, aby další sada transakcí byla vyzvednuta z další zálohy v pořadí.

v tomto článku se zabýváme hlavně jednoduchými zálohami a obnovami, ale pokročilejší obnovení v roce 2005 umožňuje obnovení sekundárních skupin souborů, zatímco databáze je online. Jeho primární skupina souborů musí být během operace online. To bude užitečnější pro velmi velké databázové systémy.

obnovení databází SQL Serveru do určitého časového bodu

obnovení protokolů není mnohem obtížnější než obnovení diferenciální databáze, které jsme právě dokončili. Je jen o něco více zapojeno do obnovy na okamžik v čase. Za předpokladu, že zálohujete protokoly do jednoho souboru nebo zařízení:

v opačném případě stačí jít a získat názvy souborů, které potřebujete. Nejprve spusťte obnovení databáze a dbejte na to, aby byla ponechána v neobnoveném stavu. V návaznosti na to s řadou log obnoví do určitého časového bodu.

nyní máme databázi, která je přesná, Poslední potvrzená transakce 23.října ve 14:30:29. Nezapomeňte, že během vícestupňových obnovení, jako je tato, musíte databázi ponechat ve stavu obnovení. To znamená připojit NORECOVERY ke každému příkazu, dokud nedokončíte proces obnovení. Pokud jste z nějakého důvodu přidali NORECOVERY ke všem svým příkazům, nebo se jednoduše zastavíte uprostřed a chcete databázi vrátit zpět do režimu online, můžete tento příkaz použít k dokončení procesu:

databázové snímky

SQL Server 2005 představil koncept snímku nebo statického zobrazení databáze pouze pro čtení. Snímky jsou primárně vytvořeny za účelem poskytnutí verze databáze pouze pro čtení pro účely podávání zpráv. Fungují však podobným způsobem jako zálohy. Jediným primárním rozdílem je, že všechny nezávazné transakce jsou vráceny zpět. Neexistuje žádná možnost pro posun vpřed, zachycení protokolů atd., které zálohy poskytují, ani se vůbec nepoužívá mnoho prostředků serveru SQL. Spíše se používá disková technologie k vytvoření kopie dat. Z tohoto důvodu jsou mnohem rychlejší než zálohy jak pro vytváření, tak pro obnovu.

poznámka:
další podrobnosti o SQL 2005 Snapshot naleznete v http://www.simple-talk.com/sql/database-administration/sql-server-2005-snapshots/.

dobrým využitím snímků, kromě hlášení, může být vytvoření jednoho před údržbou poté, co jste již odstranili všechny aktivní uživatele (a jejich transakce) ze systému. Zatímco snímky nepodporují volatilitu živých záloh, jejich rychlost a snadnost obnovy jsou skvělým nástrojem pro rychlé zotavení ze zpackaného zavádění. Snímky jsou uloženy na serveru, takže se musíte ujistit, že máte dostatečné úložiště.

syntaxe je jiná, protože nezálohujete databázi; vytváříte novou:

nyní bude přístupný pouze pro čtení. Vzhledem k tomu, že se primárně zabýváme použitím tohoto mechanismu jako zálohovacího mechanismu, zahrnujme metodu pro návrat databáze do databázového snímku.

nejprve identifikujte snímek, který chcete použít. Pokud je v databázi více než jedna, kterou chcete vrátit, budete muset odstranit všechny kromě té, kterou používáte:

poté můžete databázi vrátit spuštěním příkazu obnovení (smíšené metafory, není dobré):

to je ono. V mém systému trvalo spuštění databázových snímků Adventureworks 136 ms. úplná záloha trvala 5,670 ms. obnovení snímku trvalo 905ms a obnovení databáze trvalo 13,382 ms. Začlenění do procesu zavádění výroby by mohlo mít za následek významné výhody

opět stojí za zmínku, že existují určité námitky k použití snímku. Musíte mít dostatek místa na disku pro druhou kopii databáze. Při práci se snímky musíte být opatrní, protože většina syntaxe je podobná syntaxi používané samotnými databázemi. Poslední, zatímco tam jsou snímky připojené k databázi nelze spustit obnovení ze zálohy databáze této databáze.

osvědčené postupy

způsob, jakým provádíte zálohování databáze, by neměl být technickým rozhodnutím. Mělo by to být diktováno obchodem. Malé systémy s nízkými transakčními sazbami a / nebo systémy hlášení, které jsou načteny pravidelně, budou potřebovat pouze úplnou zálohu databáze. Středně velké systémy a velké systémy se stávají závislými na typu dat spravovaných k určení, jaké typy záloh jsou vyžadovány.

u středně velkého systému by denní zálohování se zálohami protokolu během dne pravděpodobně odpovědělo na většinu požadavků na data včas.

pro velkou databázi je nejlepším přístupem kombinovat zálohy, aby byla zajištěna maximální obnovitelnost v minimálním čase. Například spusťte týdenní úplnou zálohu. Dvakrát denně během týdne spusťte diferenciální zálohu. Každých 10 minut během dne spusťte zálohu protokolu. To vám dává velké množství mechanismů obnovy.

u velmi velkých databází budete muset spustit zálohování souborů a souborů, protože úplné zálohování nebo dokonce diferenciální zálohování celé databáze nemusí být možné. V této oblasti je k dispozici řada dalších funkcí, které vám pomohou, ale nebudu do nich jít.

měli byste mít čas na vývoj některých skriptů pro spuštění záloh a obnovení. Konvence pojmenování, abyste věděli, jaká databáze, ze kterého serveru, od kterého data, v jaké konkrétní záloze a formátu bude velmi příznivé pro váš zdravý rozum. Mělo by být definováno společné umístění pro zálohy, protokol, úplné nebo přírůstkové. Každý odpovědný by měl být vyškolen v oblasti zálohování i obnovy a řešení problémů. Existuje mnoho způsobů, jak toho dosáhnout, ale můžete najít několik návrhů v Pop zálohuje a Pop obnovuje.

skutečným testem je spuštění zálohovacích mechanismů a spuštění obnovení. Pak zkuste jiný typ obnovení a další a další. Ujistěte se, že jste nejen provedli náležitou péči při definování způsobu zálohování systému, ale že jste udělali další krok, abyste zajistili, že tyto zálohy můžete obnovit. Pokud jste to nepraktikovali a zdokumentovali praxi a poté dokument otestovali, ve skutečnosti nejste připraveni na katastrofu.

shrnutí

zálohy ve vašem podniku by měly být jako hlasování v Chicagu, brzy a často. Nastavení základních záloh je poměrně jednoduché. Přidání záloh protokolu a diferenciálů je také snadné. Prozkoumejte možnosti, jak přidat zálohy a obnovení skupiny souborů a souborů, abyste zvýšili rychlost záloh a obnovili obě, což zvýší dostupnost systému a čas. Udržujte společný standard pojmenování. Při používání snímků buďte opatrní, ale určitě je zaměstnejte. Uložte soubory na standardní umístění mezi servery. Procvičte si zotavení. A konečně, aby vaše zálohy skutečně zpívaly, stáhněte si bezplatnou zkušební verzi Red Gate SQL Backupâ¢. Nabízí vysoce výkonnou kompresi a odolnost sítě, aby byl proces zápisu nebo kopírování záloh přes šupinaté sítě odolný proti chybám.