Popis možnosti zotavení po havárii pro Microsoft SQL Server

Souhrn

Tento článek pojednává o různých řešení pro obnovení dat z databáze Microsoft SQL Server, pokud dojde k selhání. Tento článek také popisuje výhody a nevýhody každého roztoku.

Zotavení po havárii je proces, který můžete použít k obnovení informačních systémů a dat, pokud dojde k selhání.

Několik příkladů katastrof zahrnout přírodních nebo umělých havárie, například požár nebo technické havárie, například selhání disku dvě pole pole z nezávislých disků RAID (Redundant) 5.

Plánování obnovení po havárii je práce, která je věnována přípravě akce, které se musí vyskytovat v reakci na katastrofy. Plánování zahrnuje výběr strategie pomoci obnovit cenná data. Výběr strategie vhodné po havárii zotavení závisí na obchodní požadavky.

Poznámka: Řešení, které jsou zmíněny v tomto článku poskytují pouze obecný popis technologií, které můžete použít. Tyto obecné popisy jsou pro porovnání různých metod zotavení po havárii a plány obnovy po havárii. Před rozhodnutím o katastrofě, která je pro vás nejvhodnější řešení pro zotavení, ujistěte se, že se podíváte na každé řešení obnovení po havárii navrhované podrobněji. Po zabývat každou řešení pro zotavení po havárii, tento článek obsahuje odkazy, kde můžete najít další informace o řešení.

Převzetí služeb při selhání clustering

Microsoft SQL Server 2000 převzetí služeb při selhání služby clusterů je určena k převzetí služeb při selhání automaticky dojde k selhání hardwaru nebo selhání softwaru. Můžete použít SQL Server 2000 převzetí služeb při selhání služby clusterů k vytvoření clusteru převzetí služeb při selhání pro jednu instanci serveru SQL Server 2000 nebo pro více instancí serveru SQL Server 2000. Převzetí služeb při selhání clustering umožňuje databázový systém automaticky přepne na zpracování instance serveru SQL Server ze serveru došlo k chybě na pracovní server. Proto převzetí služeb při selhání služby clusterů je užitečné, pokud dojde k selhání operačního systému nebo plánovanou upgradu databáze systémových prostředků. Převzetí služeb při selhání také zvyšuje dostupnost serveru s žádné prostoje.

Protože převzetí služeb při selhání je určena pro server vysokou dostupnost s téměř žádný výpadek serveru, uzly clusteru by měl být geograficky blízko vedle sebe. Převzetí služeb při selhání clusterů nemusí být užitečné, pokud dojde k selhání disku pole.

Poznámka: K implementaci služby clusterů převzetí služeb při selhání, je nutné nainstalovat Microsoft SQL Server 2000 Enterprise Edition.

Následující operační systémy podporují převzetí služeb při selhání:
  • Microsoft Windows NT 4.0, Enterprise Edition
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
  • Microsoft Windows Server 2003, Enterprise Edition
  • Microsoft Windows Server 2003, Datacenter Edition
Tyto operační systémy patří Instalovatelná komponenta Microsoft Cluster Service (MSCS). K provedení překlopeného clusteru SQL Server, je nutné nainstalovat MSCS.

Další informace o serveru MSCS a jeho instalace klepněte na následující číslo článku databáze Microsoft Knowledge Base:

Prostředky instalace Clusterové služby společnosti Microsoft 259267

Výhody a nevýhody použití clusterů převzetí služeb při selhání

Výhody
Máte server vysokou dostupnost. Pokud primární server selže, dojde k převzetí služeb při selhání clustering automaticky.
Nevýhody
  • Jste vystaveni větší výdaje. Údržba dvou serverů je dvakrát náklady udržovat jediný server. Vzhledem k tomu, že je třeba udržovat dva servery ve stejné době, je dražší, nainstalovat a spravovat uzly clusteru.
  • Servery by měly být ve stejném umístění. Pokud jsou pobočky organizace po celém světě a clustery aktivní/aktivní musí být zavedena do větví, se výrazně liší od serverový cluster zařízení s kvorem standardní vytváření sítí a úložiště infrastruktury, který chcete použít. Ačkoli je možné, je tedy nepoužívejte geograficky vzdálené servery.
  • Nemáte žádnou ochranu proti selhání disku pole.
  • Převzetí služeb při selhání neumožňuje vytvořit clustery převzetí služeb při selhání na úrovni databáze nebo na úrovni objektu databáze, například na úrovni tabulky.
Další informace o vytváření clusterů převzetí služeb při selhání naleznete na následujícím webu společnosti Microsoft:Další informace o převzetí služeb při selhání služby clusterů klepněte na následující čísla článku zobrazení v článcích znalostní báze Microsoft Knowledge Base:

243218 pořadí instalace pro SQL Server 2000 Enterprise Edition na serveru Microsoft Cluster Server

822250 webové vysílání podpory: Microsoft SQL Server 2000 převzetí služeb při selhání clustering postupy pro zotavení po havárii

Další informace o zásady podpory společnosti Microsoft pro převzetí služeb při selhání clusteru serveru SQL Server klepněte na následující číslo článku databáze Microsoft Knowledge Base:

327518 Microsoft zásady podpory clusteru převzetí služeb při selhání serveru SQL Server

Zrcadlení databáze

Zrcadlení databáze je především softwarové řešení pro zvýšení dostupnosti databáze. Můžete implementovat pouze na základě jednotlivé databáze zrcadlení. Zrcadlení pracuje pouze s databází, které používají model obnovy celé. Jednoduché a Hromadně zaevidované obnovení modely nepodporují zrcadlení databáze. Proto jsou vždy plně zaznamenány všechny hromadné operace. Zrcadlení databáze pracuje s jakoukoli úroveň kompatibility podporované databáze.

Výhody a nevýhody použití zrcadlení databáze

Výhody
  • Zrcadlení databáze zvyšuje ochranu dat.
  • Zrcadlení databáze zvyšuje dostupnost databáze.
  • Během inovace databáze zrcadlení zlepšuje dostupnost produkční databázi.
Nevýhody
  • Zrcadlení databáze musí být identické v hlavní databázi. Například všechny objekty, přihlášení a oprávnění musí být identické.
  • Zrcadlení databáze zahrnuje přenos informací z jednoho počítače do jiného počítače v síti. Proto je velmi důležité zabezpečení serveru SQL Server přenáší informace.

Transakční replikace peer-to-peer

Transakční replikace peer-to-peer je určena pro aplikace, které může číst nebo může měnit data databáze, která se účastní replikace. Navíc nejsou k dispozici žádné servery, které jsou hostiteli databází, můžete upravit aplikaci ke směrování dat na zbývající servery. Zbývající servery obsahují shodné kopie data.

Výhody a nevýhody použití transakční replikace peer-to-peer

Výhody
  • Lepší výkon pro čtení vzhledem k tomu, že činnosti se mohou šířit přes všechny uzly.
  • Souhrnné aktualizace výkonu, výkonu vložit a odstranit výkonu pro topologii připomíná výkon jednoho uzlu, protože všechny změny jsou šířeny do všech uzlů.
Nevýhody
  • Peer-to-peer replikace je k dispozici pouze v SQL Server 2005 Enterprise Edition.
  • Všechny zúčastněné databáze musí obsahovat stejná schémata a data.
  • Doporučujeme, aby každý uzel použijte vlastní distribuční databáze. Tato konfigurace eliminuje potenciál pro SQL Server 2005 mít jediný bod selhání.
  • Ve více publikacích peer-to-peer v rámci jedné publikace databáze nesmí obsahovat tabulky a další objekty.
  • Musíte mít publikace povolena replikace peer-to-peer před vytvořením žádné odběry.
  • Je třeba inicializovat odběry pomocí zálohování nebo nastavení synchronizace typu předplatného na hodnotu pouze podporu replikace.
  • Transakční replikace peer-to-peer neposkytuje zjišťování konfliktů a konfliktů.
  • Doporučujeme používat sloupce identity.

Udržovat teplé rezervní server

Můžete vytvořit a udržovat teplé rezervní server pomocí buď z následujících metod:
  • Námořní protokolu
  • Transakční replikace
Následuje další informace o každé z těchto dvou metod.

Námořní protokolu

Dodávky protokolu je součástí sady resource kit pro Microsoft SQL Server 7.0 a je plně začleněna v Microsoft SQL Server 2000 Enterprise Edition a Microsoft SQL Server 2000 Developer Edition. Protokol dodávky využívá rezervní server, který není použit během běžné operace. Rezervní server je užitečné při obnovení dat, pokud dojde k selhání. Námořní protokolu lze použít pouze na úrovni databáze. Nelze ji použít na úrovni instance.

Při rezervní server je obnovení protokolů transakcí, je databáze ve výhradním režimu a nepoužitelná. Však můžete spustit dávkové úlohy mezi transakce protokolu obnovení sestav nebo příkazy konzoly databáze (DBCC) zkontroluje nepřetržitě ověřit integritu rezervní server. Pro aplikace jako jsou například servery podporu rozhodnutí, které vyžadují nepřetržité zpracování na databázovém serveru protokolu expedice není vhodná možnost.

Čekací doba na rezervní server vychází jak často jsou přijata záloh protokolu transakce na primárním serveru a potom použita na rezervní server. Pokud primární server selže, může dojít ke ztrátě změn, které byly provedeny transakce, které nastaly po vaší poslední transakce protokolu zálohování.

Například pokud každých 10 minut byla přijata záloh protokolu transakce, transakce během posledního 10 minut mohou být ztraceny. To však nemusí znamenat, že budou ztracena data aktualizace, které jsou prováděny na primární server během období latence. Obvykle nové aktualizace v primární transakce protokolu lze obnovit a použít v teplé rezervní server s malým zpožděním v přepínání z primárního serveru na rezervní server. Hlavním účelem dodávky protokolu je zachovat teplé rezervní server. Pokud udržovat teplé rezervní server je hlavním cílem, je pravděpodobně vhodnější než jiná řešení, které tento článek popisuje protokol expedice.

Výhody a nevýhody použití protokolu expedice

Výhody
  • Můžete obnovit všechny činnosti databáze. Pro obnovení obsahuje všechny objekty, které byly vytvořeny jako jsou tabulky a zobrazení. Zahrnuje také změny zabezpečení, jako jsou noví uživatelé, kteří byly vytvořeny a jakékoli změny oprávnění.
  • Databázi můžete obnovit rychleji. Obnovení databáze a transakční protokol je založen na formáty stránek nižší úrovně. Proto protokolu dodávky urychluje proces obnovy a má za následek rychlé obnovení dat.
Nevýhody
  • Databáze nepoužitelná během procesu obnovení, protože je databáze ve výhradním režimu na úsporný režim serveru.
  • Je zde nedostatek podrobností. Během procesu obnovení jsou použity všechny změny v primárním serveru na rezervní server. Námořní protokolu nelze použít použít změny do několika tabulek a zbývající změny odmítnout.
  • Není k dispozici žádné automatické přepojení při selhání aplikace. Pokud primární server selže z důvodu katastrofy, rezervní server automaticky provede není převzetí služeb při selhání. Proto je nutné explicitně přesměrovat aplikací, které se připojují k primární server úsporném režimu (převzetí služeb při selhání) Server.
Poznámka: Pokud je hlavním účelem je zachovat teplé rezervní server, společnost Microsoft doporučuje použití protokolu expedice. Teplé rezervní server odráží všechny transakce, ke kterým dochází na primárním serveru. Nelze však použít rezervní server je k dispozici primární server.


Další informace o tom, jak nastavit teplé rezervní server pomocí protokolu expedice získáte v následujícím článku znalostní báze Microsoft Knowledge Base:

323135 Microsoft SQL Server 2000 - jak nastavit protokol (dokument white paper)

325220 webové vysílání podpory: Microsoft SQL Server 2000 protokolu dodávky

Další informace o protokolu expedice naleznete na následujících webech společnosti Microsoft:

Transakční replikace

Transakční replikace můžete použít také udržovat teplé rezervní server. Transakční replikace replikuje data na jednom serveru (vydavatel) na jiný server (odběratel) s kratší čekací doby než protokolu expedice. Můžete implementovat transakční replikace na úrovni objektu databáze, například na úrovni tabulky. Proto společnost Microsoft doporučuje používat transakční replikace v případě, že máte méně dat k ochraně a musí mít rychlé obnovení plánu.

Odběr push lze vynutit transakční replikaci mezi dvěma servery s primární server jako vydavatel a rezervní server jako účastníka. Transakční replikace replikace dat je zajištěno. Pokud vydavatel nezdaří, lze účastníka.

Toto řešení je zranitelný vůči selhání vydavatele a odběratele ve stejnou dobu. V tomto případě nelze chránit data. Ve všech ostatních scénářích například selhání distributora nebo předplatitele je nejvhodnější k synchronizaci dat odběratele s daty aplikaci publisher.

Měli byste použít transakční replikace udržovat teplé rezervní server pouze v případě, že nelze provádět změny schématu nebo jako replikace změny zabezpečení neimplementují jiné změny databáze nepodporuje.

Poznámka: Replikace není určen pro údržbu teplé rezervní servery. Replikace můžete pomocí replikovaná data u odběratele ke generování sestav. Replikace můžete použít také pro jiné obecné použití bez museli provádět zpracování relativně zaneprázdněn vydavatele.

Výhody a nevýhody použití transakční replikace

Výhody
  • Při provedení změn si můžete přečíst data na odběratele.
  • Změny budou použity s kratší čekací doby.

    Poznámka: Tato výhoda nemusí být k dispozici, pokud je splněna jedna z následujících akcí:
    • Agenti replikace není nastavena na kontinuální.
    • Agenti replikace byla zastavena z důvodu chyby, ke kterým může dojít během replikace.
Transakční replikace může trvat déle, chcete-li změny použít, protože velké dávkové aktualizace musí být provedeny při replikaci.
Nevýhody
  • Změny schématu nebo změny zabezpečení, které jsou prováděny aplikace publisher po stanovení replikace není k dispozici u odběratele.
  • Distributor v transakční replikace distribuce dat pomocí připojení Open Database Connectivity (ODBC) nebo připojení databáze OLE (OLEDB). Námořní protokolu však používá nižší úrovně příkaz Transact-SQL obnovení transakce k distribuci protokolů transakcí. Příkaz obnovení transakcí je mnohem rychlejší než připojení ODBC nebo OLEDB připojení.
  • Přepínání serverů obvykle vymaže konfiguraci replikace. Proto je nutné konfigurovat replikaci dvakrát:
    Při přepnutí na odběratele.
    Při přepnutí zpět na vydavatele.
  • Pokud dojde k selhání, musí ručně přepnout serverů přesměrováním všech aplikací na odběratele.
Další informace o replikaci klepněte na následující číslo článku databáze Microsoft Knowledge Base:

195757 často kladené dotazy - SQL Server 7.0 - replikace

Funkce zálohování a obnovení

Funkce zálohování a obnovení serveru SQL Server obsahuje ochranných důležité k ochraně důležitých dat, které jsou uloženy v databázích serveru SQL Server. Můžete vytvořit kopii databáze (záložní kopie) pomocí funkce zálohování a obnovení a potom uložit kopii databáze v umístění, které jsou chráněny před potenciální selhání serveru, na kterém je spuštěna instance serveru SQL Server. Pokud dojde k selhání systému databáze nebo poškození databáze, můžete záložní kopií znovu vytvořit databázi nebo obnovení databáze.

Při plánování zotavení po havárii pomocí zálohování a obnovení funkce, také určete, jak důležité je data v databázi. Kromě toho určete požadavky na obnovení databáze. Například určete požadavky na následující obnovení:
  • Místo obnovení databáze. Musíte se rozhodnout, které z následujících dvou chcete provést:
    Obnovení databáze do stavu noc před selháním.
    Podmínky bodu čas co nejtěsněji k době selhání obnovení databáze.
  • Jak dlouho může být databáze není k dispozici. Zda nutné obnovení databáze okamžitě.
Po určení požadavky na obnovení můžete naplánovat zálohování proces, který udržuje sadu záloh pro splnění požadavků

Databázi lze obnovit pouze do stavu bodu kde provedení poslední zálohy. Transakce, které nastaly po této zálohy mohou být ztraceny. Společnost Microsoft proto doporučuje použít funkci zálohování a obnovení pouze pro non kritické databázové aplikace.

Výhody a nevýhody použití funkce zálohování a obnovení

Výhody
  • Můžete zálohovat databázi na vyměnitelná média k ochraně proti selhání disku.
  • Nemáte závisí na síti, stejně jako při pomocí převzetí služeb při selhání nebo protokolu expedice.
Nevýhody
  • Při zálohování databáze nelze provést operace, například vytvoření tabulka, vytvoření indexu, zmenšením databáze nebo nonlogged operací.
  • Pokud dojde k selhání, může dojít ke ztrátě nejnovější data.
  • Pokud dojde k selhání, je třeba ručně obnovit databázi.
Poznámka: Než použijete zálohování a obnovení procedury v provozním prostředí, doporučujeme důkladně testovat postup v testovacím prostředí.

Další informace o funkci zálohování a obnovení získáte v následujícím článku znalostní báze Microsoft Knowledge Base:

325257 webové vysílání podpory: obnovení databáze SQL Server 2000: zálohování a obnovení

Popis 281122 obnovení souboru a skupina souborů zálohování serveru SQL Server

Další informace o funkci zálohování a obnovení naleznete na následujících webech společnosti Microsoft:

Disku redundanci dat pomocí redundantní pole nezávislých disků (RAID)

RAID ukládá redundantní data na více disků, chcete-li dosáhnout větší spolehlivosti a méně prostojů pro servery. RAID úrovně 0, 1 a 5 jsou obecně používány jako možnosti obnovení serveru SQL Server. Technologie RAID, které jsou zmíněny umožnit selhání a následnému nahrazení jednoho disku bez server je offline. Pokud dojde k více chybám disku, nemusí být možné obnovit data. Společnost Microsoft proto doporučuje, že zkombinujete správu redundantních dat s pomoci, ujistěte se, že není ztrátě dat, pokud selhání hardwaru nebo jiné havárie dojde k zálohování a obnovení postup.

RAID 0 používá technologii prokládání pro rychlejší přístup, že RAID 1 používá zrcadlení technologii pro spolehlivost údajů. Běžné technika používaná v řízení relační databáze zahrnuje společně pomocí RAID 0 a RAID 1. V této techniky jsou dva identické prokládané pole jednotek průběžně aktualizovány tak, aby informace, které jsou uloženy na obě pole stejný. Pokud dojde k selhání jednoho pole, ostatní pole automaticky převezme do původního pole přepnut do režimu online.

Paritní bity zapsán společně s daty používá jediný prokládané diskové pole RAID 5 (také známé jako prokládání s paritou). Při jakékoli jeden disk selže, paritní bity lze použít k výpočtu chybějící data, dokud vyměnit disk. Při výměně disku slouží paritní informace a zbývající data znovu vytvořit data z vadného disku a znovu vytvořit data zkopírovat na nový disk. Tyto operace dojít bez jakéhokoli výpadku systému databáze. RAID poskytuje mnoho možností a funkcí můžete pomoci zajistit, že dochází k databázových systémů jako málo prostoje co nejvíce.

Výhody a nevýhody použití RAID

Výhody
Pokud jakékoli jeden disk selže, není ztratit data.
Nevýhody
  • Může trvat dlouhou dobu obnovit data.
  • Pokud více disků, nebude možné obnovit cenná data.
Další informace o RAID klepnutím na následující číslo článku databáze Microsoft Knowledge Base:

Přehled 100110 redundantní pole RAID (RAID)

Odkazy

Chcete-li stáhnout aktualizovanou verzi SQL Server 2000 Books Online, navštivte následující Web společnosti Microsoft:Další informace o jiných možnostech zotavení po havárii naleznete klepnutím na následující číslo článku databáze Microsoft Knowledge Base:

Články zotavení po havárii 307775 pro Microsoft SQL Server

Další informace o převzetí služeb při selhání služby clusterů klepněte na následující čísla článku zobrazení v článcích znalostní báze Microsoft Knowledge Base:

195761 často kladené dotazy - SQL Server 7.0 - převzetí služeb při selhání

260758 často kladené dotazy - SQL Server 2000 - převzetí služeb při selhání clustering

274446 upgrade na SQL Server 2000 převzetí služeb při selhání řešení vhodné pro všechny virtuální servery SQL Server 2000

Weby Windows clustering a geograficky vzdálených 280743

Další informace o funkci zálohování a obnovení naleznete na následujícím webu společnosti Microsoft:Další informace o funkci zálohování a obnovení získáte v následujícím článku znalostní báze Microsoft Knowledge Base:

253817 jak zálohovat poslední protokolu transakcí při hlavním a databázové soubory jsou poškozeny v serveru SQL Server

Jak 314546 přesunutí databází mezi počítači se systémem SQL Server

Další informace o katalog fulltextového vyhledávání složek a souborů klepněte na následující číslo článku databáze Microsoft Knowledge Base:

240867 jak přesunout, kopírovat a zálohovat soubory a složky fulltextového katalogu

Vlastnosti

ID článku: 822400 - Poslední kontrola: 16. 1. 2017 - Revize: 1

Váš názor