SQL Server 7.0, SQL Server 2000 a SQL Server 2005 protokolování a algoritmy úložiště dat rozšířit spolehlivost dat

Překlady článku Překlady článku
ID článku: 230785 - 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

SQL Server 7.0, SQL Server 2000 a SQL Server 2005 Restrukturalizovat a změnit návrh algoritmy protokolování a data ze starší verze Microsoft SQL Server zlepšit spolehlivost dat a integrity.

Další informace o základní pojmy stroje SQL Server 7.0 a SQL Server 2000 naleznete v tématu "ARIES (algoritmus pro obnovení a sémantiky Exploiting izolace): způsob obnovení transakcí jemné Granularita podpora uzamykání a částečně vrácení provedených změn pomocí zápisu napřed protokolování", z ACM transakcí v systémech databáze. Tento dokument byla zapsána Chunder Mohan.

Tento dokument adresy techniky SQL Server 7.0, SQL Server 2000 a SQL Server 2005 rozšířit spolehlivost dat a integrity jako související selhání.

Je doporučeno přečíst následujících článcích v databázi Microsoft Knowledge Base pro další vysvětlení v mezipaměti a alternativní selhání režimu diskuse:
86903Popis ukládání do mezipaměti disku řadiče v SQL Server
46091Řadič pevného disku do mezipaměti se serverem SQL pomocí
234656Pomocí disku do mezipaměti se serverem SQL

Další informace

Před zahájením hlouběji diskusní některé podmínky jako používán v celém tomto článku jsou definovány v následující části.
Zmenšit tuto tabulkuRozšířit tuto tabulku
TermínDefinice
Zálohován baterie Samostatné a lokalizované baterie zálohovací zařízení přímo k dispozici a řízený mezipaměti mechanismem zabránit ztrátě dat.
Poznámka: Není zdroj nepřerušitelného zdroje napájení (UPS). Zařízení UPS nezaručuje aktivit zápisu a může být odpojen z mezipaměti zařízení.
Mezipaměť Mechanismus zprostředkující úložiště používá k optimalizaci Fyzický I/O operací a zlepšit výkon.
Nevyřízený stránky Stránka obsahující změny dat ještě muset být vyprazdňována stabilní úložiště. Další informace týkající se vyrovnávacích pamětí dirty stránky naleznete v dokumentaci SQL Server Books Online.
Selhání Cokoli, co může způsobit neočekávané výpadek procesu serveru SQL. Příklady: napájení výpadek, resetování počítače, chyby paměti, jiné problémy s hardwarem, chybné sektory, výpadky jednotky, selhání OS a tak dále.
Vyprázdnění Vynucení mezipaměti vyrovnávací paměti pro úložiště stabilní.
Latch Synchronizace objekt použitý k ochraně fyzické konzistence prostředku.
Nonvolatile úložiště Střední, která zůstává k dispozici prostřednictvím selhání systému.
Připojené stránky Stránka zůstane data mezipaměti a nemůže být vyprazdňována do úložiště stabilní, dokud všechny záznamy přidružené protokolu jsou zabezpečeny v umístění úložiště stabilní.
Stabilní úložiště Stejné jako nonvolatile úložiště.
Nestálá úložiště Médium, které není přes selhání zůstanou beze změny.
SQL Server 2005, SQL Server 2000, SQL Server 7.0, starší verze serveru SQL a mnoho produktů mainstream databáze na trhu dnes používat protokol zápisu napřed protokolování (WAL).

Protokol zápisu napřed protokolování (WAL)

Termín protokol je vynikajícím způsobem popisují WAL. Je konkrétní a uloženy a vyměňovaných správně definovaná sada implementace kroky nezbytné k zajištění dat a lze obnovit známý stav v případě selhání. Stejně jako sítě obsahuje definovaný protokol pro výměnu dat konzistentní a chráněný způsobem, takže příliš provede WAL popisují protokol chránit data.

Dokument ARIES definuje WAL jako:
Protokol WAL nepodmíněných výrazů, záznamy protokolu představující změny některá data musí již být v stabilní úložiště před nahradit předchozí verze v nonvolatile úložiště dat změněných dat je povoleno. To znamená systému není povoleno zapisovat na aktualizovanou stránku nonvolatile úložiště verze stránky, dokud alespoň k stabilní úložiště napsané částí vrácení záznamů protokolu, které popisují aktualizace na stránku.
Další informace o zápisu napřed protokolování naleznete v dokumentaci SQL Server Books Online.

SQL Server a WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 a dřívější verze SQL Server používat protokol WAL. Chcete-li zajistit správné committal transakci, musí být zabezpečeny všechny záznamy protokolu spojené s transakcí v stabilní úložiště.

Upřesňující informace, zvažte následující příklad konkrétní (pro tento příklad předpokládá neexistuje žádný index a ovlivněny stránka je stránka 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
Nyní přerušit aktivitu do kroků simplistic protokolování:
Zmenšit tuto tabulkuRozšířit tuto tabulku
VýkazAkce provedena
POČÁTEČNÍ TRANSAKCE Zapsat do mezipaměti oblasti protokolu ale existuje je není nutné vyprázdnění stabilní úložiště, protože SQL Server není provedl fyzické změny.
INSERT INTO tblTest1. Data stránky 150 je načíst do mezipaměti data serveru SQL, pokud není již k dispozici.

2. Je stránka latchedpřipojené a označeny dirty a získat příslušné zámky.

3. Záznamu protokolu vložit je vytvořena a přidána do mezipaměti protokolu.

4. Nového řádku je přidán do datové stránky.

5. Latch vydána.

6. Záznamy protokolu spojené s transakcí nebo stránky nemusí v tomto okamžiku vyprázdněna protože zůstávají všechny změny v nestálé úložiště.
POTVRZENÍ TRANSAKCE1. Záznam potvrzovací protokol je tvořen a musí být transakce přidružené záznamy protokolu zapsány do stabilní úložiště. Transakce není považován potvrzena dokud stabilní úložiště správně přiřazeny záznamy protokolu.

2. Data stránky 150 zůstane mezipaměť dat SQL Server a není okamžitě vyprázdněn do úložiště stabilní. Když jsou záznamy protokolu správně zabezpečené obnovení můžete znovu operace potřeby.

3. Transakční uzamčení jsou vydány.
Není třeba zaměňovat s zamykání a protokolování. Ačkoli je důležité, protokolování a uzamčení jsou samostatné problémy při obchodování WAL. Ve výše uvedeném příkladu SQL Server 7.0, SQL Server 2000 a SQL Server 2005 obecně podržte latch na stránce 150 pro čas potřeby provádět změny fyzické vložit na stránce, nikoli celou dobu transakce. Typ zámku příslušné navázání chránit řádek, rozsah, stránky nebo tabulky podle potřeby. Naleznete v oddílech SQL Server Books Online uzamčení Další podrobnosti o uzamčení typy.

Vzhled příklad podrobněji je pravděpodobně požádat co se stane při spouštění LazyWriter nebo CheckPoint procesy. SQL Server 7.0, SQL Server 2000 a SQL Server 2005 vydat všechny příslušné vyprázdnění stabilní úložiště přidružené stránce dirty a připojených záznamů transakční protokolu. Tím zajistíte datové stránky lze zapsat nikdy na stabilní úložiště, dokud vyprázdněna záznamy protokolu přidružené transakční protokol WAL.

SQL Server a stabilní úložiště

SQL Server 7.0, SQL Server 2000 a SQL Server 2005 vylepšit operací stránky protokolu a dat včetně znalostní velikostí sektorů disku (běžně 512 bajtů).

Udržovat vlastnosti ACID transakce musí selhání body účtu serveru SQL. Při selhání zaručit mnoho specifikace disku pouze omezené množství operací zápisu sektoru. Většina specifikace zaručit dokončení zápisu jednoho sektoru, když dojde k selhání.

SQL Server 7.0, SQL Server 2000 a SQL Server 2005 používat 8 KB datových stránek a protokolu (Pokud vyprázdněna) v násobcích velikosti sektoru. (Většina diskové jednotky použít jako výchozí velikost sektoru 512 bajtů.) Z selhání SQL Server můžete účtu pro operace zápisu větší než sektoru podle využívající parity protokolu a techniky roztržené zápisu.

Zjišťování Roztržené stránky

Následující část pochází z SQL Server 7.0 Books Online popisující zjišťování Roztržené stránky:
Tato možnost umožňuje zjistit nedokončené operace I/O způsobeny výpadkem proudu nebo jinou poruchou systému SQL Server. Po hodnotu true, způsobí bit k Překlopeno pro každého sektoru 512 bajtů v stránka databáze (KB) 8-kilobyte kdykoli stránky zapsány na disk. Pokud bitu je v chybném stavu při vyšší stránky číst serverem SQL, klepněte na stránku byl zapsán nesprávně; zjistil Roztržené stránky. Roztržené stránky jsou obvykle zjištěny během zotavení, protože stránky nesprávně napsané je pravděpodobně číst zotavení.

Přestože stránek databáze SQL Server jsou 8 KB, disky provádět operace I/O pomocí sektoru 512 bajtů. 16 Sektory jsou proto zapsány za stránka databáze. Roztržené stránky může dojít, pokud systém nezdaří (například z důvodu selhání napájení) mezi časem operační systém zapíše první sektoru 512 bajtů na disk a dokončení operace 8 KB I/O. Pokud první sektor stránka databáze úspěšně zapsána před selháním, stránka databáze na disku budou zobrazeny aktualizována, přestože jej pravděpodobně nebudou mít úspěšně.

Pomocí zálohy baterie diskové mezipaměti řadiče můžete zajistit, že data úspěšně zapsány na disk nebo není vůbec zapsány. V tomto případě proveďte není sada torn page detection na hodnotu true, pro není nutný.
Poznámka: Zjišťování Roztržené stránky není povolena ve výchozím nastavení SQL Server 7.0. Viz sp_dboption jak povolit zjišťování v systému.

Parity protokolu

Kontrola parity protokolu je velmi podobné zjišťování Roztržené stránky. Každého sektoru 512 bajtů obsahuje paritní bity. Tyto paritní bity jsou vždy zapsány záznamu protokolu a vyhodnocovány při načítání záznamu protokolu. Vynucením protokolu zapíše na hranici 512 bajtů SQL Server 7.0, SQL Server 2000 a SQL Server 2005 zajistíte, že operace committal zcela zapsány do sektory fyzického disku.

Změny poskytují konzistence dat zvýšenou i přes předchozí verze serveru SQL.

Verze serveru SQL starší než 7.0

Verze serveru SQL starší než 7.0 neposkytl protokolu parity nebo roztržené bit zjišťování vybavení. Ve skutečnosti tyto verze lze zapsat stejnou stránku protokolu několikrát dokud záznamy protokolu vyplnit stránky 2 KB protokolu. To může vystavit transakce úspěšně potvrdily. Pokud stránka protokolu je právě nezměněn při selhání, sektor s potvrzených transakcí pravděpodobně není získat nezměněn správně.

Vlivy výkonu

Soubory protokolu a dat pomocí funkce Win32 CreateFile otevřete všechny verze serveru SQL. Člen dwFlagsAndAttributes zahrnuje možnost FILE_FLAG_WRITE_THROUGH při otevření serverem SQL.
FILE_FLAG_WRITE_THROUGH
Pokyn systém zápisu prostřednictvím jakékoli zprostředkující mezipaměti a přejít přímo na disku. Systém stále mezipaměti operace zápisu, ale nelze je lazily vyprázdnění.

Možnost FILE_FLAG_WRITE_THROUGH zajišťuje, že při zápisu operace vrátí úspěšné dokončení data správně uložena v stabilní úložiště. Je zarovnán s protokolem WAL zajištění data.
Mnoho diskových jednotek (SCSI a IDE) obsahovat integrovanou mezipamětí 512 KB, 1 MB, nebo větší. Mezipamětí jednotka však obvykle spoléhají na kondenzátorový a není řešení zálohován baterie. Tyto mechanismy mezipaměti nezaručuje cyklu zápisů přes výpadku napájení nebo selhání podobné bodu. Dokončení operace zápisu sektor jejich pouze zaručit. Je to konkrétně Proč byly roztržené zápisu a zjišťování parity protokolu integrována do serveru SQL Server 7.0, SQL Server 2000 a SQL Server 2005. Jako jednotky pokračovat zvětšit velikost, mezipaměti se stanou větší a jejich můžete vystavit větší objemy dat při selhání.

Mnoho dodavatelů hardwaru poskytují řešení řadiče disku zálohován baterie. Tyto řadiče mezipaměti mohou udržovat data v mezipaměti pro několik dní a dokonce povolit ukládání do mezipaměti hardwaru umístěny do druhého počítače. Po obnovení napájení správně unwritten dat zcela vyprázdněny před další data přístup povolen. Procento čtení mnoho z nich povolit versus zapisování mezipaměti vytvořeno pro optimální výkon. Některé obsahovat velké paměťové oblasti úložiště. Pro velmi specifické segment trhu ve skutečnosti některé dodavatelé hardwaru poskytují mezipaměti systémy řadič s 6 GB mezipaměti výstupu disku zálohován baterie. Tyto může výrazně zlepšit výkon databáze.

Rozšířené ukládání do mezipaměti implementacích bude úchyt FILE_FLAG_WRITE_THROUGH požadavku není zákazem mezipaměti řadiče, protože poskytují true přepsat schopnosti v případě obnovení systému, výpadku napájení nebo jiných bod selhání.

Přenosy I/O bez použití mezipaměti mohou být kvůli mechanické čas potřebný k přesunutí hlavy jednotky, Otočný sazby a dalších faktorech omezení podstatně delší.

Objednání sektor

Běžné technika používaná ke zvýšení výkonu I/O je sektor objednání. Předejít mechanické hlava přesunu jsou řazeny požadavky čtení a zápisu povolení konzistentnější pohybu hlavy načíst nebo uložit data.

Mezipaměť může pojmout více protokolu a zapisovat data požadavků současně. Protokol WAL a SQL Server implementace protokolu WAL vyžadují vyprázdnění protokolu zapíše stabilní úložiště před vystavením zápisu stránky. Však použití mezipaměti může vrátit úspěch z požadavku protokolu zápisu bez dat zapisovaných skutečnou jednotku (která je, zapsány do stabilní úložiště). To může vést k serveru SQL vydáním požadavku zápisu dat stránky.

S zapojení zápisu mezipaměti jsou data považována stále být v nestálé úložiště. Však z volání Win32 API WriteFile přesně, jak vidí aktivity, SQL Server úspěšné návratový kód byl získán. SQL Server nebo jakýkoli proces pomocí pouze mohou volání API WriteFile odvodit data správně získal stabilní úložiště.

Pro účely diskuse předpokládají, že všechny sektory datové stránky jsou seřazeny zapisovat před sektory odpovídající záznamy protokolu. Toto porušuje okamžitě protokol WAL. Mezipaměť zápisu dat stránky před záznamy protokolu. Pokud není mezipaměť plně bateriovým, může způsobit selhání katastrofální výsledky.

Při vyhodnocování faktory optimálního výkonu databáze serveru jsou mnoho faktorů zvažte. Foremost tyto aspekty je "můj systém povolit platné možnosti FILE_FLAG_WRITE_THROUGH?"

Poznámka: Jakékoli mezipaměti používáte musí plně podporují řešení zálohován baterie. Všechny jiné mechanismy mezipaměti jsou podezřelý poškození dat a ztrátu dat. SQL Server provádí každých úsilí WAL zajistit povolením FILE_FLAG_WRITE_THROUGH.

Testování má zobrazeny, může obsahovat mnoho konfigurací disku zápis do mezipaměti bez zálohy správné baterie. Jednotky SCSI, IDE a EIDE využít výhod zápisu mezipaměti.

V mnoha konfiguracích je jediným způsobem správně zakázat mezipaměť zápisu jednotky IDE nebo EIDE s konkrétní výrobce nástroje nebo pomocí můstků umístěn na jednotce samotného. Chcete-li zajistit, že je zakázána mezipaměť zápisu pro vlastní jednotce, obraťte se na výrobce jednotky.

Jednotky SCSI také mít zápisu mezipaměti, ale tyto mezipaměti lze zakázat běžně podle operačního systému. Pokud je libovolný otázku, obraťte se na výrobce jednotky příslušné nástroje.

Zápis mezipaměti stohování

Zapisovat stohování mezipaměti je podobný sektor řazení. Následující definice byla převzata přímo ze serveru WWW výrobce jednotky úvodní IDE:
Obvykle tento režim je aktivní. Zapisovat režim mezipaměti přijímá hostitele dokud vyrovnávací paměť je plný nebo hostitele Přenos byl dokončen zápis dat do vyrovnávací paměti.

Úkol zápisu disku začíná ukládání dat hostitele na disk. Příkazy zápisu hostitele pokračovat být přijímány a data přenesena do vyrovnávací paměti, dokud zásobníku příkazu zápisu je plná nebo vyrovnávací paměť dat je plný. Jednotku může uspořádat příkazy zápisu k optimalizaci jednotky propustnost.

Přerozdělení automatického zápisu (AWR)

Další běžné technika používaná k ochraně dat je během manipulaci dat rozpoznat chybné sektory. Následující vysvětlení pochází z stejné úvodní IDE jednotky výrobce webu:
Tato funkce je součástí mezipaměť zápisu a snižuje riziko ztráty dat během operací odložené zápisu. Pokud během procesu zápisu disku dojde k chybě disku, přestane disk úkolu a podezřelých sektor reallocated fondu alternativní sektory umístěn na konci jednotky. Následující přerozdělení úkol disku zápis pokračuje, dokud je dokončena.
Pokud baterie zálohování je k dispozici pro mezipaměť, povolení správné změny při restartování to může být velmi výkonné funkce. Je vhodnější zjišťovat chyby na disku, ale zabezpečení dat protokol WAL by znovu vyžadují to být provedeno reálném čase a není odložené způsobem. V rámci parametry WAL nelze technika AWR účtu pro situaci, kde zápis protokolu selže kvůli chybě sektoru, ale jednotka je plný. Databázový stroj musí okamžitě vědět o selhání, takže transakce mohou být správně přerušena, upozorňování správce a správné kroky převzaty zabezpečení dat a opravit situaci selhání média.

Bezpečnost dat

Existuje několik opatření správce databáze by měl zajistit bezpečnost data.
  • Je vždy vhodné zajistit strategii zálohování je dostatečná k obnovení z Katastrofální selhání. Jsou příslušné Offsite úložiště a další opatření.
  • Testování operace obnovení databáze v vedlejší nebo testovací databáze na základě časté.
  • Zajistit, že žádné zařízení pro ukládání do mezipaměti můžete zpracovat všechny selhání situacích (výpadku napájení, chybné sektory, chybný jednotek, výpadku systému, lockups, Hřeb napájení a tak dále).
  • Zajistit mezipaměti zařízení:
    • Má integrované zálohování baterie.
    • Můžete reissue zapíše na napájení.
    • Může být zakázáno plně podle potřeby.
    • Zpracovává chybný sektor re-mapping reálném čase.
  • Povolit zjišťování Roztržené stránky; má minimální vliv na výkon.
  • Konfigurovat jednotky RAID povolení hot odkládací chybné diskové jednotky, pokud je to možné.
  • Použijte novější mezipaměti řadiče povolit přidání více místa na disku bez restartování operačního systému. To může být ideální řešení.

Testování jednotek

Plně zabezpečit data, je třeba zajistit, že všechna data do mezipaměti je správně zpracována. V mnoha situacích to znamená, je nutné zakázat mezipaměť zápisu na disk.

Poznámka: Zajistit alternativní mechanismus ukládání do mezipaměti lze správně zpracovávat více typů selhání.

Microsoft provedl testování několik jednotek SCSI a IDE pomocí nástroje SQLIOStress. Tento nástroj simuluje Tučná asynchronní čtení a zápis činnost zařízení simulované dat a zařízení protokolu. Zobrazit statistiku testu výkonu operací zápisu Průměrný za sekundu mezi 50 a 70 pro jednotku s zakázáno ukládání do mezipaměti a rozsah RPM mezi 5,200 a 7,200.

Další informace a podrobnosti o nástroj SQLIOStress naleznete v následujícím článku databáze Microsoft Knowledge Base:
231619Jak pomocí nástroje SQLIOStress zátěžový podsystém disku, jako je například SQL Server
Mnoho výrobců (například Compaq, Dell, brána, HP a tak dále) objednávky jednotky s zakázána mezipaměť zápisu. Testování ukazuje, že to nemusí být vždy případ takže vždy však test zcela.

Data zařízení

V situacích, všechny ale non přihlášen SQL Server bude vyžadovat pouze záznamy protokolu k být vyprazdňována. Při provádění operací není přihlášen, datových stránek musí být také vyprázdněna do úložiště stabilní; nejsou žádné záznamy protokolu jednotlivé vygenerovat akce z selhání znovu.

Datových stránek lze zůstávají v mezipaměti, dokud proces LazyWriter nebo CheckPoint vyprázdní do úložiště stabilní. Pomocí protokolu WAL zajistit, že jsou správně uloženy záznamy protokolu zajišťuje, že obnovení můžete obnovit data stránky známého stavu.

To neznamená, že je vhodné umístit datové soubory na jednotce v mezipaměti. Při serveru SQL vyprázdní stránky data do úložiště stabilní, záznamy protokolu zkráceny z protokolu transakce. Pokud datových stránek jsou uloženy v nestálé mezipaměti, je možné zkrátit záznamy protokolu by být použita k obnovení stránky v případě selhání. Zajistit dat a protokolů zařízení správně přizpůsobená stabilní úložiště.

Zvýšení výkonu

Je počáteční otázku, který vznikl: „ mít jednotka IDE, který byl do mezipaměti však při I zakázána, Moje výkonu stal výrazně menší než očekávané--Proč? „

Mnoho společností Microsoft testovány jednotky IDE spustit při sazbě RPM 5,200 a SCSI jednotek při RPM z 7,200. Když zakážete zápisu mezipaměti jednotka IDE mechanické výkonu mohou stát koeficient.

Je adresa rozdíl výkonu velmi Vymazat oblast: "Adresy rychlost transakce"

Existuje mnoho online (OLTP) systémy, které vyžadují transakce vysokou rychlost zpracování transakcí. Tyto systémy zvažte použití mezipaměti řadič, lze podporu zápisu mezipaměti správně a poskytují zvýšení výkonu při zajištění integrity dat.

Výrazně setkáte výkonu změny se serverem SQL na jednotce mezipaměti byl zvýšit rychlost transakce pomocí malé transakce.

Testování ukazuje, že zápis vysoká aktivita menší než 512 KB nebo nad 2 MB vyrovnávací paměti může způsobit snížení výkonu.
Zvažte následující příklad:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
   INSERT INTO tblTest VALUES ('Test')
				
výsledky ukázkového testu pro SQL Server jsou následující:
Sekund 84 SCSI(7200 RPM)
SCSI(7200 RPM) 15 sekund (řadič mezipaměť)

IDE(5200 RPM) 14 sekund (jednotka mezipaměť povolena)
Sekund 160 IDE(5200 RPM)
Obtékání celé řady operace INSERT v jediné transakci spustí v všech konfigurací přibližně 4 sekundy.

Důvodem je počet vyprázdnění protokolu požadováno. Bez transakce transakce a sebe sama je každý INSERT a při každém záznamy protokolu transakce musí být vyprazdňována. Každý vyprázdnění je velikosti vyžaduje významné mechanické jednotky zásahu 512 bajtů.

Při použití jedné transakce instalován záznamy protokolu transakce a jeden větší zápis lze použít k vyprázdnění záznamy získaného protokolu. Mechanické zásahu výrazně snížena.

Upozornění Zvýšit obor transakcí není vhodné. Dlouhotrvající transakce může vést k blokování nadměrné a nežádoucí stejně jako zvýšit režii. Slouží k zobrazení čítačů transakce založené na protokolu SQL Server 7.0, SQL Server 2000 a SQL Server 2005 čítače výkonu Databáze: server SQL. Konkrétně Flushed protokolu bajty/s mohou označovat mnoho transakcí malé úvodní činnosti vysoké mechanické disku.

Prohlédněte příkazy přidružené vyprázdnění protokolu a určit sníží počet vyprázdnění protokolu. Ve výše uvedeném příkladu byla implementována jediné transakce. Však v mnoha případech to může vést k nežádoucímu uzamčení chování. Podívejte se na návrh transakce. Možná něco jako vyprázdnění listy snížit protokolu časté a malé provádět následující činnosti:
BEGIN TRAN
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
BEGIN
   INSERT INTO tblTest VALUES ('Test')

   if(0 = cast(@@IDENTITY as int) % 10)
   BEGIN
      PRINT 'Commit tran batch'
      COMMIT TRAN
      BEGIN TRAN
   END
END
GO

COMMIT TRAN
GO
				
SQL Server 6. x nemusí zobrazit stejné dopad výkonu z časté a zapíše malé transakčního protokolu. SQL Server 6. x přepíše stejnou stránku 2 KB protokolu, jako jsou potvrzených transakcí. To může snížit velikost protokolu výrazně porovnání vyprázdnění hranici sektoru 512 bajtů v SQL Server 7.0, SQL Server 2000 a SQL Server 2005. Zmenšení velikosti protokolu přímo spojuje částka mechanické jednotky aktivity. Však jako explained nad SQL Server 6. algoritmus x může vystavit potvrzených transakcí.
SQL Server vyžaduje systémy podporují ‘ zaručené doručení stabilní média ’ podle pokynů v části program Microsoft SQL Server Always-On úložiště řešení revize. FODalší informace o požadavcích vstupní a výstupní databázového stroje SQL Server klepněte na následující číslo článku databáze Microsoft Knowledge Base:
967576Microsoft SQL Server Database Engine vstupní a výstupní požadavky

Vlastnosti

ID článku: 230785 - Poslední aktualizace: 9. února 2006 - Revize: 5.3
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard 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 kbhowto kbinfo KB230785 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:230785

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