Klíče faktory při vyhodnocování third-party souborová mezipaměť v systémech s SQL Server je třeba vzít v úvahu

Překlady článku Překlady článku
ID článku: 917043 - Produkty, které se vztahují k tomuto článku.
Rozbalit všechny záložky | Minimalizovat všechny záložky

Na této stránce

Souhrn

Tento článek popisuje některé klíčové faktory by zákazníci měli znát při vyhodnocování výrobců souboru, ukládání do mezipaměti systému.

Third-Party souborová mezipaměť implementace může zvýšit výkon databází Microsoft SQL Server při řádně prováděny. Konfigurace těchto produktů a konkrétní implementace však opustit vysoké riziko ztráty dat databáze serveru SQL Server. Zákazníci by zcela Vyzkoušejte konfiguraci integritu dat správné.

Informace v tomto dokumentu, včetně adres URL a jiných odkazů na webové servery, představují podléhají změnám bez předchozího upozornění. Pokud není uvedeno jinak, společností, organizací, produktů, názvy domén, e-mailové adresy, loga, osoby, místa či události použité v ukázkách jsou smyšlené. Žádnou spojitost s jakékoli skutečnou společností, organizace, produktu, název domény, e-mailovou adresu, loga, osoby, místo nebo události je určen, nebo by měla být odvodit. Dodržování všech platných zákonů na ochranu autorských práv je zodpovědný uživatel. Bez omezení autorských práv, žádná část tohoto dokumentu může být reprodukována, uložené v nebo zavedena do archivačního systému nebo v jakékoliv formě nebo jakýmikoliv prostředky (elektronické, mechanické, fotokopírováním, záznamem nebo jinak) ani za žádným účelem bez výslovného písemného povolení společnosti Microsoft Corporation.

Společnost Microsoft může vlastnit patenty, patentové přihlášky, ochranné známky, autorská práva a další práva týkající se duševního vlastnictví, které se vztahují k předmětu tohoto dokumentu. Výslovně v písemné licenční smlouvě od společnosti Microsoft, poskytnutím tohoto dokumentu nedává vám žádnou licenci na uvedené patenty, ochranné známky, autorská práva nebo jiné duševní vlastnictví.

© 2007 Microsoft Corporation. Všechna práva vyhrazena.

Microsoft, Windows, Windows Server a SQL Server jsou registrované ochranné známky nebo ochranné známky společnosti Microsoft Corporation ve Spojených státech amerických a v dalších zemích.

Tento článek je napsány specificky pro SQL Server, ale obecně platí pro databáze Jet, použité výrobky služby Active Directory a Exchange Server.

Další informace

Tato část popisuje požadavky a poskytuje podrobné příklady, které by měly být projednány zcela jiného dodavatele před zavedením žádné řešení. Zákazníci také brát zvláštní péče testování různých scénářů zotavení zkontrolujte, zda je správně udržována integrita dat.

Požadavky na vstupu a výstupu (I/O) serveru SQL Server

Libovolný soubor databáze nebo zálohování serveru SQL Server vyžaduje základy úložiště podporující protokol zápisu napřed protokolování (WAL). Tyto základy jsou popsány v následujících článcích:
Základy pro SQL Server 2000 v/V
http://technet.microsoft.com/en-us/library/cc966500.aspx
Poznámka: V článku platí také pro SQL Server 2005.
230785Protokolování serveru SQL Server 7.0, SQL Server 2000 a SQL Server 2005 a algoritmy úložiště dat rozšířit spolehlivost dat
Následuje seznam některých důležitých požadavků:
  • Řazení zápisu musí být zachována.
  • Musí být zachována konzistence závislé zápisu.
  • Zápisy musí být zabezpečeny, vždy v nebo na stabilní média.
  • Potrhané I/O prevence se může vyskytovat.

Partnerské certifikace produktu nejsou záruka kompatibility nebo bezpečnosti

Produkt třetí strany nebo konkrétního dodavatele lze získat potvrzení logo Microsoft. Však Partnerské certifikace nebo zvláštní logo společnosti Microsoft není certifikovat kompatibility nebo vhodnosti pro určitý účel pro SQL Server Exchange Server a služby Active Directory.

FILE_FLAG_WRITETHROUGH a FILE_FLAG_NO_BUFFERING

Databázi produktů společnosti Microsoft konkrétně pomocí zápisu prostřednictvím a bez příznaků vyrovnávací paměti při otevírání souborů databáze zabránit ztrátě dat. Každá žádost zápisu k těmto souborům musí být zabezpečeny na stabilní média. V opačném případě může dojít ke ztrátě dat. Níže uvedené příklady konkrétní, může vystavit mezipamětí systému souborů:
  • Zápis kombinování a změna pořadí zápisu
    Snížit fyzické vstupně-výstupních požadavků, závislosti mezipaměti nabití baterie často kombinovat a uspořádat operace zápisu ihned rozdělení požadavky protokolu WAL.
  • Velikost bloku operací
    Podobné zápisu kombinování a pořadí jsou velikost bloku operací. Mezipaměti bude pokus o dokončení operací na základě velikosti bloku vstupně-výstupní cestu. Znovu to může poskytnout boost výkon, ale otevře až do poškození databáze a okamžitě přeruší požadavky protokolu WAL.

Čtených body a příklady

Následující část obsahuje příklady klíčů a čtených bodů týkajících se integrity dat a bezpečnost. Použije jako společný bod selhání a jasnosti výpadku napájení, ale to může být často nahrazeny různé problémy vedoucí k podobné databázi integrity problémy.

Příklad 1: Ztrátu dat a fyzické nebo logické poškození

Zvažte následující scénář:
  1. Záznam protokolu zapsána pro stránku 100 v databázi.
  2. Záznam protokolu je držena v mezipaměti bez baterií systémem, ale databázový stroj je určen že zápis protokolu je kompletní "zabezpečené na stabilní média".
  3. Databázový stroj považuje LSN podobu a zápisu pro stránku 100 problémy.
  4. Také se koná stránky 100 v závislosti mezipaměti nabití baterie.
  5. Potvrzení transakce dokončena bez chyb.
Databázový stroj pokračuje zpracování, jako by ji úspěšně společnost zápisy stabilní média. Výpadek napájení v tomto okamžiku však bude mít za následek ztrátu dat okamžité protože změny nikdy fyzicky existuje mimo mezipaměť zálohovaných nabití baterie. Zotavení systému po chybě neznamená chybu, protože zotavení systému po chybě neví o záznamu protokolu ztraceny a se nebude pokoušet znovu práce. O různých typech poškození databáze, ke kterým může dojít, rozbalte položku více scénářů změny objektu (například primární klíč, vloží cizího klíče).

Existují různé další problémy, které by mohly vzniknout s malým změnám ke zpracování operací mezipaměti. Stručný odvození předpokládá, že transakce byla vrácena zpět, ale stránky 100 provedené na fyzické médium. Zotavení systému po chybě znovu neví o záznam protokolu (nikdy proveden na stabilní média), tak 100 bude stránka neobdrží operace zpět během zotavení systému po chybě opuštění logicky a případně i fyzické poškození databáze.

Příklad 2: Podezřelých databáze

Někteří dodavatelé povolit "odhlásit soubory" a často doporučujeme ponechat databázového souboru protokolu (LDF pro SQL Server) zvolil z mezipaměti. Zásada "opt" je taková, aby správce výslovně musí označit soubory, které mají být ignorovány softwarem pro ukládání do mezipaměti. V opačném případě je soubor automaticky zahrnuty.

Toto je špatná předpokladů, zvýrazněte následující příklady. Společnost Microsoft doporučuje se z takových mezipaměti zvolil všechny databáze a záložních souborů.
  1. Soubor protokolu je zvolil, tak zápisy se zobrazuje na stabilní média.
  2. Stránka 100 se mění.
  3. Databázový stroj spouští operace na kontrolního bodu.
  4. Modul je určen všechny stránky databáze a jsou záznamy protokolu zabezpečení (podobu časovému okamžiku až považováno za kontrolní bod). Však datových stránek nejsou všechny uložené na nebo v stabilní média.
  5. Databáze serveru SQL Server je v režimu obnovení "SIMPLE,", tak kontrolních bodů nyní zkrátí záznamy protokolu.
  6. Stránky 100, která byla pouze kontrola označenou je upravit znovu.
Tato situace má vystavena databáze ztrátu dat a obvykle vede podezřelé databáze. Znovu pokud provádí k výpadku napájení, zotavení systému po chybě má žádné záznamy protokolu, protože již existují kvůli zkrácení. Databázový stroj neobsahuje informace označující, že stránky databáze chybí data, která by byla zabezpečena během kontrolní bod. Zotavení systému po chybě se pokusí analyzovat druhý změny na stránce 100, ale nezdaří, protože stránky 100 nebyl správně zabezpečen na stabilní média v době kontrolní bod.

Zotavení systému po chybě používá k určení potřeb obnovení LSN hodnota uložená v záhlaví stránky.
  • Pokud LSN na stránce se rovná nebo je novější než u záznamu protokolu, obnovení nemá žádné další práce na stránce, protože je již konzistentní s záznam protokolu na základě porovnání LSN na stránce.
  • Pokud je starší než u záznamu protokolu LSN na stránce, musí obnovení řádné operacím vrátit na stránku do řádného stavu. Obnovení se nezdaří, pokud obnovení má chladit podmínku chybějící data a nemůže správně vrátit na stránku do správného stavu.
V příkladu předchozí LSN uložené v záznamu protokolu o změně druhé stránky 100 neexistuje v záhlaví stránky, a neexistuje žádný záznam předchozího protokolu přítomen na stránku znovu. Proto databáze je označen jako podezřelý, jako pro obnovení nemůže pokračovat bez obav.

Příklad 3: Zálohování nejsou platné - Silent záložní řetězci přerušení

Příklad 2 je pouze zlomek tyto typy potíží, které by mohly být došlo. V tomto příkladu namísto režimu obnovení "SIMPLE", dejte nám umístit databázi v režimu "FULL RECOVERY" ale trvat pravidelné zálohování databáze a protokolu. Zpočátku se zdá, že by to bylo lépe protože jste řetězci beze změny protokolu a mohl pouze spustit sekvenci obnovení k odstranění problému.

To není pravděpodobně platný předpokladů, jako některé implementace mezipaměti používat zásady "opt" tak, že záložní soubor nebo jeho části může být neočekávaně mezipaměti. Když SQL Server vyprázdnění záložní soubor, SQL Server vyžaduje, že jsou všechny zápisy na záložní médium správně uloženy na stabilní média pomocí funkce rozhraní Win32 API FlushFileBuffers nebo. Tedy pokud dodavatele mezipaměti všechny zápisy jsou správně zapsány, během volání funkce FlushFileBuffers, nezajišťuje na stabilní média před úspěšné dokončení operace databáze motoru může zkrátit protokolu bez zabezpečené zálohy. Znovu výpadku napájení v tomto okamžiku výsledkem podmínka kde záznamy protokolu řádné chybí a mohou způsobit selhání obnovení se nezdaří. Co je důležitější je, že zotavení systému po chybě, nebude možné zjistit to z důvodu chybějící záznamy protokolu v databázi a záložní řetězce může být bez zásahu uživatele poškozen. Pouze v případě, že dojde k pokusu o obnovení zálohy databázový stroj nebude označíte že zálohy byl poškozen.

Příklad 4: Neplatná databáze stavy

Databázové soubory obsahují závislosti mezi sebou vyžaduje přísné průběžným zápisem a objednávání shody, které chcete použít u všech těchto jako skupina. Kontrolní bod, změní velikost souboru, rozdílové zálohování, operace nejsou protokolovány a obnovení model loženo PROTOKOLOVÁNY jsou mezi několik klíče databáze činností vyžadujících zápis setkáte na datové soubory zásad jako opting pouze soubor protokolu neplatný předpokladu provedení.

Příklad 5: Snímek ztrátu dat databáze – může být pasivní

SQL Server 2005 se zavádí snímek databáze bodu v času dotazy. To zabezpečit kopii datovou stránku v databázi snímek dat před nové změny datovou stránku v základní databáze používá technologii kopírování při zápisu databáze. Tento proces vyžaduje být před pokračováním transakce na stránce v databázi snímku zabezpečeny. Je-li na stránce není zabezpečena na stabilní média nebo, problémy integrity dat bude trvat. Snímek databáze neobsahuje transakčního protokolu, proto je důležité zápisu stránky. Pokud něco jako následek výpadku napájení došlo, je možné že stránka hlavní databáze byl změněn, ale snímek neodráží předchozí obrázek, protože zápisu mezipaměti byla ztracena.

Postup při konfiguraci

Konfigurace produktu poskytování souborová mezipaměť z něco jako non-battery zálohovaných mezipaměti je specifické pro dodavatele provádění. Několik pravidel, však mohou být použity:
  • Všechny zápisy musí být dokončen v nebo na stabilní média před mezipaměti udává operačního systému, aby vstupně-výstupní dokončení.
  • Data lze uložit do mezipaměti, tak dlouho, dokud se žádost o přečtení obsluhovány z mezipaměti vrátí stejný obraz jako umístěné v nebo na stabilní média.
Tato pravidla v podstatě rozumí, může být efektivní pro operace čtení mezipaměti zálohovaných nabití baterie, ale by neměl být použit pro požadavky na zápis. Při správné konfiguraci to mohou stanovit zisku výkonu databázového stroje. To by však měly, zkouší, pečlivě, protože nastavení vyhrazené něco jako paměť RAM, které by mohly být využity serverem SQL Server může snížit celkový výkon. SQL Server pravděpodobně moci pomocí přesněji než mezipaměti obecný mechanismus dodatečnou paměť.

Databáze jen pro čtení

Jen pro čtení databáze může být vhodný příklad kde aplikace excel těchto typů výrobků. Pokud databáze byla nejprve vytvořené a uložené na nebo v médiích stabilní k zajištění integrity dat, používaný k označení databáze READ ONLY příkazu ALTER DATABASE a následně přiřazen mechanismus ukládání do mezipaměti databáze, může být zjištěna nárůst výkonu. Některé implementace ponechat v mezipaměti, umožňující další fyzické data načtena z mezipaměti a snížení fyzických vstupně-výstupní komprimované obrazy stránek databáze.

Upozornění: Databáze je třeba přijmout nikdy READ zápisu, pokud je přiřazen k mezipaměti, které bude udržovat protokol WAL.

Zabezpečení

Úvod do mezipaměti, jako je například systémové mezipaměti souborů založených na paměť RAM, zavádí jinam "v paměti" pro data. Produkty, jako jsou například databázový stroj může převzít důležitých dat bylo skladováno v nebo na stabilní média a správně zachovat přístup ovládacího prvku seznamu (ACL) ochrany. Mezipaměti v paměti RAM může vystavit data, která mají být sada problémy se zabezpečením, které jsou jedinečné v porovnání s stabilní média. Jestliže aplikace je konstruován tak, že něco jako funkce SecureZeroMemory použít pokaždé, když se, že byla dokončena pomocí důležitých informací, například aplikace má očekávání, že data již neexistuje v paměti RAM. Pokud formě data mohou zůstat v mezipaměti aplikace očekával jednat v nebo na médiu stabilní, ji však může změnit důležité informace o zabezpečení.

Kontroly integrity dat

Společnost Microsoft vždy doporučuje strategii integrity silné a jasné údaje. By měl zahrnovat, ale není omezen na, obnovení záloh a pravidelných operací DBCC CHECKDB obnovenou databázi a výroby.

Společnost Microsoft také doporučuje při hodnocení a provádění změn životního prostředí, nebo všechny obavy, které vyvstanou, týkající se stability životního prostředí-li zvýšit četnost těchto bezpečnostních zkoušek.

Další informace o použití SQLIOStress nástroj, článek znalostní báze Microsoft Knowledge Base:
231619Jak pomocí nástroje SQLIOStress zdůrazňují diskový podsystém, jako je například SQL Server

Databáze TEMPDB

Je možné vyhledat databázi TEMPDB v některých systémech ukládání do mezipaměti. Několik faktorů, by měly pečlivě považovány za a testovány při vyhodnocování umístění úložiště databáze TEMPDB v této konfiguraci. Následujícím článku znalostní báze Microsoft Knowledge Base popisuje vstupně-výstupní požadavky, hranice související podpory a nárůst výkonu možné.
917047Microsoft SQL Server vstupně-výstupní požadavky podsystém databáze TEMPDB

Podpora

Microsoft SQL Server podpora bude napomáhat Zákazníci, používající standardní data technik pro obnovení. Pokud produkty nainstalované na počítači kreslit integritu dat do otázku, Microsoft SQL Server, služby Active Directory a podpora serveru Exchange, může požádat odinstalovat produkt a budou není zapojit se do analýzy kořenové příčiny až do doby lze problém reprodukovat bez uvedeného výrobku.

Microsoft neprovádí potvrdí nebo ověřit, že produkty jiných výrobců správně fungovat se serverem SQL Server. Navíc společnost Microsoft neposkytuje žádné záruky, záruky nebo prohlášení o libovolný produkt třetí strany vhodnosti pro použití se serverem SQL Server.

Odkazy

Pečlivě zvažte dalších informací poskytnutých k vyhodnocení zlepšení výkonu serveru SQL Server v následujících odkazech:

826433Další Diagnostika SQL Server přidán do zjišťování problémů nedovoleném, nehlášeném I/O
828339Chybová zpráva 823 může znamenat potíže s hardwarem nebo problémy se systémem SQL Server
234656Použití ukládání do mezipaměti disku se serverem SQL Server
110352Optimalizace výkonu Microsoft SQL Server
304261Popis podpory pro síťové soubory databáze serveru SQL Server
910716Podpora pro třetí strany vzdálené zrcadlení roztoky s SQL Server 2000 a 2005 uživatelských databází
913945Microsoft není potvrzuji produkty třetích stran, bude pracovat Microsoft SQL Server
SQL Server vyžaduje systémy pro podporu ‘ zaručené doručení na stabilní média ’ podle programu zkontrolovat řešení úložiště Always-On Microsoft SQL Server. FODalší informace o požadavcích vstupní a výstupní databázového stroje SQL Server získáte následujícím článku znalostní báze společnosti Microsoft:
967576Microsoft SQL Server databáze stroj vstupní a výstupní požadavky

Vlastnosti

ID článku: 917043 - Poslední aktualizace: 2. listopadu 2007 - Revize: 1.5
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Workgroup Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Klíčová slova: 
kbmt kbexpertiseadvanced kbinfo KB917043 KbMtcs
Strojově přeložený článek
Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.
Projděte si také anglickou verzi článku:917043

Dejte nám zpětnou vazbu

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com