SQL Server 7.0, SQL Server 2000 a SQL Server 2005 zapisovania a údajov skladovanie algoritmy rozšíriť spoľahlivosť údajov

Preklady článku Preklady článku
ID článku: 230785 - Zobraziť produkty, ktorých sa tento článok týka.
Rozbaliť všetko | Zbaliť všetko

Na tejto stránke

SUHRN

SQL Server 7.0, SQL Server 2000 a SQL Server 2005 reštrukturalizovať a redesign algoritmy zapisovanie do denníka a údaje z predchádzajúcich vydaniach programu Microsoft SQL Server zlepšiť spoľahlivosť údajov a integrity.

Sa dozvedieť viac o základné koncepty SQL Server 7.0 a SQL Server 2000 motory, pozri "ARIES (algoritmus zhodnotenia a izoláciu Exploiting Sémantika): metódu transakcie vymáhanie podporné. pokuty-Granularity Zamknutie a čiastočné závažnom Using písať dopredu zapisovania", ACM transakcií na databázových systémov. Tento dokument bol napísaný Chunder Mohan.

Tento dokument sa zaoberá SQL Server 7.0, SQL Server 2000 a SQL Server 2005 techniky rozšíriť spoľahlivosť údajov a integrity týkajúce zlyhania.

Sa odporúča prečítať si nasledujúce články v databáze Microsoft Knowledge Base na ďalšie objasnenie do vyrovnávacej pamäte a alternatívny zlyhanie režim diskusie:
86903 Popis caching radiče diskov v SQL Server
46091 Pomocou radič pevného disku do vyrovnávacej pamäte s SQL Server
234656 Pomocou disku do vyrovnávacej pamäte s SQL Server

DALSIE INFORMACIE

Pred začatím hĺbkové diskusie, niektoré pojmy sa používa v celom tomto článku sú definované v nasledujúcom oddiele.
Zbaliť túto tabuľkuRozbaliť túto tabuľku
PojemDefinícia
Záložné batérieOddelené a lokalizované batérie zálohovacie zariadenia priamo k dispozícii a kontrolovaná caching mechanizmu na zabránenie straty údajov.
Poznámka Toto nie je neprerušiteľný zdroj napájania (UPS). UPS nezaručuje zápis činnosti a môže byť odpojený od caching zariadenia.
Vyrovnávacia pamäťPoužíva na optimalizáciu fyzických vstupno-výstupných operácií a zlepšiť výkon sprostredkovateľ skladovaniu.
Špinavé stránkuStránky obsahujúce údaje zmeny, ktoré ešte výpusty stabilné skladovania. Ďalšie informácie vzťahujúce sa na špinavé stránku medzipamätí nájdete v zdroji SQL Server Books Online dokumentácii.
ZlyhanieČokoľvek, ktoré by mohli spôsobiť neočakávané výpadok procesu servera SQL Server. Príkladmi sú: napájanie, výpadok, počítač vynulovať, chyby pamäte, iné hardvérové problémy, chybné sektory, jednotka výpadky, OS zlyhania a podobne.
FlushNúti medzipamäte vyrovnávacia pamäť k stabilnému skladovania.
ZámkaSynchronizácia objekt používaný na ochranu fyzického konzistentnosť prostriedku.
Nonvolatile skladovanieAkomkoľvek médiu, ktorý zostáva k dispozícii cez zlyhania systému.
Přišpendlený stránkuStránku, ktorá zostáva v údajoch vyrovnávacej pamäte a nemôže spláchnuť stabilné skladovania, kým všetky pridružené denníka záznamy sú zabezpečené v stabilné ukladací priestor.
Stabilné skladovanieRovnaké ako nonvolatile skladovania.
Nestáleho úložnéhoAkomkoľvek médiu, ktoré bude nie zostať neporušená cez zlyhania.
SQL Server 2005, SQL Server 2000, SQL Server 7.0, staršie verzie programu SQL Server a mnohých bežných databázy výrobkov na trh dnes použite protokol písať dopredu Logging (WAL).

Zápis dopredu Logging (WAL) protokolu

Termín protokol je vynikajúci spôsob, ako opísať WAL. Je to osobitný a vymedzenými implementácie kroky potrebné na zabezpečenie údajov uložené a vymieňajú správne a môže byť obnovená do známeho stavu v prípade zlyhania. Rovnako ako sieť obsahuje definované protokolu výmeny údajov konzistentné a chránených spôsobom, tak príliš WAL opísať protokolu na ochranu údajov.

ARIES dokument definuje WAL ako:
WAL protokolu tvrdí, že záznamy denníka zastupujúcich zmeny na niektoré údaje musia byť už stabilné uskladnenia pred zmenené údaje je umožniť vymeniť predchádzajúcu verziu údaje v nonvolatile skladovania. To je systém nie je povolené písať aktualizované stránky na nonvolatile skladovanie verziu stránky, kým aspoň späť porcií denník záznamov, ktoré opisujú aktualizácie na stránku bolo napísané stable skladovania.
Ďalšie informácie o zapisovaní Write-dopredu, nájdete v zdroji SQL Server Books Online dokumentácii.

Server SQL Server a WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 a predchádzajúcich vydaniach SQL Server používať protokol WAL. Na zabezpečenie riadnu uväznenie transakcie, musia byť zabezpečené všetky záznamy denníka spojené s transakciou stabilné uskladnenia.

Na objasnenie, zvážte nasledujúce špecifické príklad (pre tento príklad predpokladať, že neexistuje index a stránka ovplyvnené je stránka 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
Teraz rozbořím činnosť do zjednodušujúce zapisovania kroky:
Zbaliť túto tabuľkuRozbaliť túto tabuľku
VyhlásenieAkciách vykonaných
BEGIN TRANSAKCIEZapíše do denníka vyrovnávacej pamäte oblasti však netreba splachovacími stabilné skladovania, pretože server SQL Server neurobila žiadne fyzické zmeny.
VLOŽIŤ do tblTest1. Údaje stránky 150 sa načítajú do SQL Server Dátová cache, ak sú už dostupné.

2. Je stránka naklonený, vždy dostupné offline, a označia ako špinavé, a ktoré sú získané vhodné zámky.

3 Vložiť Log zaznam je postavená a pridaný do denníka cache.

4. Nový riadok sa pridáva k stránke údaje.

5 Zámka sa uvoľní.

6. Záznamy denníka spojené s transakciou alebo stránka nie je potrebné spláchnuť na tomto mieste, pretože všetky zmeny zostanú v prchavých skladovania.
POTVRDENIE TRANSAKCIE1. Commit denníka záznam je tvorený a záznamy denníka spojené s transakciou musí byť napísané stable skladovania. Transakcie sa nepovažuje za spáchané kým záznamy denníka sú správne priradené stabilné skladovania.

2. Údaje stránky 150 zostáva v SQL Server Dátová cache a nie je okamžite spláchnuť stabilné skladovania. Keď záznamy denníka sú riadne zabezpečené obnovenia môžete opakovať operácie potreby.

3. Transakčné zámky sú uvoľnené.
Nesmie zamieňať s blokovania a zapisovanie. Aj keď dôležitá, blokovanie a zapisovania samostatné emisie pri riešení WAL Vo vyššie uvedenom príklade SQL Server 7.0, SQL Server 2000 a SQL Server 2005 vo všeobecnosti podržte západku na stránke 150 krát je potrebné uskutočniť fyzickú vložiť zmeny na stránke nie celý čas transakcie. Typu vhodné uzamknutia sa zriaďuje chrániť riadok, rozsah, stránky alebo tabuľky podľa potreby. Nájdete SQL Server Books Online blokovacieho sekciách ďalšie podrobnosti o zámok typy.

Pri pohľade na príklade podrobnejšie, môžete požiadať čo sa stane pri LazyWriter alebo CheckPoint procesov spustiť. SQL Server 7.0, SQL Server 2000 a SQL Server 2005 vydať všetky vhodné flushes stable skladovanie transakčné denník záznamov spojených s špinavé a přišpendlený stránku. To zaručuje WAL protokolu stránku údaje môžu byť napísané nikdy k stabilnému skladovania, kým vyprázdnila transakčné denník záznamov.

Server SQL Server a stabilné skladovanie

SQL Server 7.0, SQL Server 2000 a SQL Server 2005 zvýšiť denníka a údaje stránku operácie vrátane vedomostí o veľkosti sektorov disku (bežne 512 bajtov).

Na zachovanie kyseliny vlastností transakciu, SQL Server musí predstavujú zlyhania bodov. Výpadku mnohých disk drive špecifikácie zaručiť iba obmedzené množstvo operácie zapisovania sektora. Väčšina špecifikácie zaručiť dokončenie jednotného sektora zapisovať, keď dôjde k.

SQL Server 7.0, SQL Server 2000 a SQL Server 2005 použite 8 KB dát stránky a denník (ak spláchnuť) na násobky veľkosť sektoru. (Väčšina diskových jednotiek použite 512 bajtov ako predvolená veľkosť sektora.) V prípade zlyhania, server SQL Server môže tvoriť operácie zapisovania väčšie ako sektor plateným denníka parita a rozsápáno písať techník.

Torn page detection

Nasledujúca časť pochádza z SQL Server 7.0 kníh Online popisujúci torn page detection:
Táto možnosť umožňuje SQL Server zistiť neúplné vstupno-výstupných operácií spôsobené poruchou napájania alebo inými výpadkami systému. Keď pravda, spôsobuje trochu prevrátený pre každý sektor 512-bajtové v 8-kilobajtové (KB) databázy stránke vždy, keď sa stránka je napísaná na disk. Ak trochu je v stave keď stránky je neskorší čítať SQL Server, potom stránke bol napísaný nesprávne; torn page zistí. Rozstrapkaná strany sa zvyčajne zistia počas obnovovania, pretože akúkoľvek stránku, ktorá bola napísaná nesprávne pravdepodobne čítať vymáhania.

Hoci sú stránky databázy SQL Server 8 KB, disky vykonať vstupno-výstupných operácií pomocou 512-bajtové sektora. Preto 16 sektory sú napísané na databázu stranu. Torn page sa môže vyskytnúť, ak systém zlyhá (napríklad kvôli výpadku) medzi časom operačný systém píše prvý 512-bajtové sektor na disk a ukončení 8 KB vstupno-výstupné operácie. Ak prvý sektor stránku databáza sa úspešne píše pred zlyhaním stránke databázy na disku sa zobrazia aktualizované, hoci môžu mať neuspela.

Pomocou záložné batérie disketu radič cache môže zabezpečiť, že údaje úspešne zapisuje na disk alebo nie napísaný vôbec. V tomto prípade nenastavujte torn page detection pravda, pre nie je potrebná.
Poznámka Torn page detection nie je povolené v SQL Server 7.0 predvolene. Pozri sp_dboption ako zapnúť zisťovanie vo vašom systéme.

Denník parita

Kontrola parity denník je veľmi podobné torn page detection. Každý sektor 512-bajtové obsahuje paritné bity. Tieto paritné bity sú vždy napísané s záznam denníka a vyhodnotené keď záznam denníka sa načítajú. Podľa núti denníka píše o 512-bajtovú hranicu, SQL Server 7.0, SQL Server 2000 a SQL Server 2005 môžu zabezpečiť, že civilný operácie sú úplne napísané fyzického disku odvetviach.

Zmeny poskytujú zvýšené údajov konzistencie, aj v predošlých verziách servera SQL Server.

Verzie staršie ako 7.0 SQL Server

Verzií SQL Server, ktoré sú staršie ako 7.0 neposkytli denníka parita alebo roztrhané bitové detekčných zariadení. V skutočnosti tieto verzie môžete napísať na rovnakej stránke denníka viackrát kým záznamy denníka vyplňte stránke 2 KB denníka. Toto môže vystaviť transakcií, ktoré sa úspešne dopustili. Ak stránka denníka je sú prepísané výpadku, môžu dostať sektora s spáchaný transakcie prepísané nie správne.

Výkon vplyvy

Všetky verzie SQL Server otvoriť denník a údaje súborov pomocou Win32 CreateFile Funkcia. The dwFlagsAndAttributes zahŕňa členské FILE_FLAG_WRITE_THROUGH možnosť po otvorení SQL Server.
FILE_FLAG_WRITE_THROUGH
Dá pokyn systému písať cez akékoľvek priebežné vyrovnávacej pamäte a ísť priamo na disk. Systém môže stále vyrovnávacej pamäte operácie zapisovania, ale nedá sa vyprázdniť mladí ľudia líně na nich.

FILE_FLAG_WRITE_THROUGH možnosť zabezpečuje, že keď písať prevádzka vráti úspešné ukončenie údaje správne uložené v stabilné skladovania. To sa zarovná s protokolom WAL zabezpečenie údajov.
Mnohé disky (SCSI a IDE) obsahovať palubným cache 512 KB, 1 MB, alebo viac. Avšak, disk cache zvyčajne spoliehať na kondenzátor a nie záložné batérie roztoku. Tieto caching mechanizmy nemôže zaručiť píše cez výkonom cyklu alebo podobné zlyhanie bod. Iba zaručiť ukončenie operácie zapisovania sektora. Je to konkrétne, prečo rozsápáno písať a denníka parita detekcie boli postavené do SQL Server 7.0, SQL Server 2000 a SQL Server 2005. Jednotky naďalej rastú vo veľkosti, cache sa zväčšiť a môže vystaviť väčším množstvom údajov počas zlyhania.

Mnohí dodávatelia hardvéru poskytujú záložné batérie disku radič riešenia. Tieto cache radič môžete zachovať údajov vo vyrovnávacej pamäti na niekoľko dní a dokonca umožňujú caching hardvér do druhého počítača. Keď energie je správne obnovená, nepísané údajov je úplne spláchnuť pred ďalšie prístup k údajom je povolený. Mnohí z nich umožňujú percento čítanie verzus vyrovnávacia pamäť zápisu ustanoví na dosiahnutie optimálneho výkonu. Niektoré obsahujú veľké pamäte skladovacích priestorov. V skutočnosti za veľmi špecifických segment trhu, niektorí dodávatelia hardvéru poskytujú high-end záložné batérie disku do vyrovnávacej pamäte radič systémy s 6 GB vyrovnávacej pamäte. Tieto môžu výrazne zlepšiť výkon databázy.

Rozšírené caching implementácií bude spracovávať FILE_FLAG_WRITE_THROUGH požiadať vypnutím nie cache radič pretože môžu poskytnúť pravdivé prepísať schopnosti v prípade príkaz na obnovenie systému, výpadku elektrickej energie alebo poruchy bodom.

Vstupno-výstupné transfery bez použitia cache môže byť značne dlhšia kvôli mechanické čas presunutie jednotky hláv, spin sadzby a iné obmedzujúce faktory.

Sektor objednávanie

Spoločné technika používaná na zvýšenie vstupno-výstupný výkon je sektor objednávanie. Vyhnúť sa mechanické hlavy pohyb na čítanie a zápis žiadosti sú zoradené, umožňujúceho konzistentnejšie pohyb vedúcemu prevziať alebo uložiť údaje.

Cache môže pojať viac denníka a údaje písať žiadostí v rovnakom čase. WAL protokolu a SQL Server vykonávanie protokolu WAL vyžadujú splachovanie denníka píše stable skladovania pred písať stránky môžu byť vydané. Však využiť cache môže vrátiť úspech z napísať žiadosť denník bez údaje zapisujú skutočných jednotku (je napísané stable skladovanie). To môže viesť k SQL Server vydanie údaje stránky písať žiadosti.

S zapísať vyrovnávaciu pamäť zapojenie, údaje stále považuje prchavých uskladnenia. Avšak z rozhranie API systému Win32 WriteFile hovor, presne ako SQL Server vidí činnosti, boli získané úspešné Návratový kód. SQL Server alebo akéhokoľvek procesu pomocou WriteFile Volanie API iba dedukovať údaje správne získala stabilné skladovania.

Na účely diskusie predpokladať, že všetky sektory stránke údaje sú zoradené písať pred sektory zhodné záznamy denníka. To okamžite porušuje WAL protokolu. Cache je písomne údajov stranu pred záznamy denníka. Pokiaľ cache je plne podporovaný batérie, zlyhanie môže spôsobiť katastrofické výsledky.

Pri hodnotení faktorov optimálny výkon pre databázový server, existuje mnoho faktorov zvážiť. Predovšetkým týchto úvah je "Robí môj systém umožní platné FILE_FLAG_WRITE_THROUGH spôsobilostí?"

Poznámka Akékoľvek vyrovnávacej pamäte používate musí plne podporujú batérie záložné riešenie. Všetky ostatné caching mechanizmy sú podozrivé poškodenia dát a strate údajov. SQL Server robí všetko úsilie na zabezpečenie WAL umožnením FILE_FLAG_WRITE_THROUGH.

Testovanie ukázalo, že mnohých konfiguráciách disku môže obsahovať písať caching bez riadneho batérie zálohovanie. Disky SCSI, IDE, EIDE a využívať napísať cache.

V mnohých konfiguráciách je jediný spôsob, ako správne vypnúť písať caching IDE alebo EIDE jednotky s pomôckou konkrétneho výrobcu alebo pomocou jumper nachádza v samotnej jednotke. Aby sa zabezpečilo, že je vypnutá vyrovnávacia pamäť zápisu na disk sám, obráťte sa na výrobcu jednotky.

Jednotky SCSI tiež majú napísať cache, ale tieto cache bežne možno vypnúť operačný systém. Ak existuje akékoľvek otázky, obráťte sa na výrobcu jednotky sa vhodné pomôcky.

Napísať Cache stohovania

Napísať Cache stohovania je podobný sektora objednávanie. Toto vymedzenie bolo prijaté priamo z popredných IDE jednotky výrobca webovej lokality:
Normálně, tento režim je aktívna. Napísať, režim vyrovnávacej akceptuje hostiteľského písať dáta do medzipamäte, kým medzipamäť je plný alebo prevod hostiteľskej nie je úplný.

Úlohu zapisovať disku začne ukladanie hostiteľskej údajov na disk. Hostiteľský písať príkazy naďalej akceptovať a údaje prenášať do medzipamäte kým buď napísať príkaz zásobník je plný alebo medzipamäť je plný. Jednotka môže zmeniť poradie písať príkazy na optimalizáciu jednotky priepustnosť.

Automatický zápis prerozdelenie (wR)

Iné spoločné technika používaná na ochranu údajov je odhaliť chybné sektory počas manipuláciu dát. Nasledujúce vysvetlenie pochádza z rovnakej popredných IDE jednotky výrobca webovej stránky:
Táto funkcia je súčasťou vyrovnávacia pamäť zápisu a znižuje riziko straty údajov počas operácie odložené zapisovania. Ak chyba disku dôjde počas procesu zápisu disku, disku úlohy zastaví a sektore podozrivý je realokované tomu poolu alternatívny sektorov, ktoré sa nachádza na konci jednotku. Po prerozdelení úlohu zapisovať disku pokračuje, kým je kompletná.
Môže to byť veľmi silný feature, ak batéria zálohovanie cache, umožňujúce správne modifikácia po reštarte. Je vhodnejšie na zistenie chýb na disku, ale bezpečnosti údajov protokolu WAL by vyžadovalo opäť to urobiť reálnom čase a nie odložené spôsobom. V rámci WAL parametre WR technika nemôže predstavujú situáciu, keď denník zapisovať zlyhá kvôli chybe sektore ale disk je plný. Databázový nástroj musí okamžite poznať o zlyhaní, takže transakcie môžu byť správne prerušené, správca môže upozornené, a náležité kroky na zabezpečenie údajov a nápravu zlyhanie médií.

Bezpečnosť dát

Existuje niekoľko bezpečnostné opatrenia, ktoré správca databázy by mala prijať na zabezpečenie bezpečnosti údajov.
  • Je vždy dobrý nápad, aby vaše záložnej stratégie dostatočné zotaviť sa z katastrofického zlyhania. Mimo skladovania a iné opatrenia sú primerané.
  • Test databázy obnoviť operáciu v sekundárnej alebo testovacej databázy na základe časté.
  • Zabezpečiť, že zariadenia caching zvládne všetky zlyhania situácie (výpadok, chybné sektory, zlé jednotky, systém výpadok, blokovanie, moc špice, a podobne).
  • Zabezpečiť, aby vaše caching zariadenie:
    • Má integrované batérie zálohovanie.
    • Môžete reedícia píše o moc.
    • Je možné úplne vypnúť potreby.
    • Kľučky chybný sektor re-mapping reálnom čase.
  • Zapnúť torn page detection; má malý dosah výkon.
  • Konfigurovať RAID jednotky umožňujúce horúce swapu na zlé disk, ak je to možné.
  • Použite novšie caching radiče, ktoré umožňujú pridanie viac miesta na disku bez reštartovania OS. Môže to byť ideálnym riešením.

Testovanie jednotky

Plne zabezpečiť vaše údaje, by mali zabezpečiť, že všetky dáta caching je správne zaobchádzať. V mnohých situáciách, to znamená, musíte vypnúť písať caching diskovej jednotky.

Poznámka Zabezpečiť, že alternatívny caching mechanizmu správne zvládne viaceré typy poruchy.

Microsoft vykonal, testovanie na niekoľko IDE a SCSI jednotky pomocou SQLIOStress pomôcka. Táto pomôcka simuluje ťažkých asynchrónne čítanie a zápis činnosť simulovaný údajov a denníka zariadením. Skúška výkon štatistiky ukazujú priemerné písať operácií za sekundu medzi 50 a 70 pre jednotku s zdravotne postihnutých písať caching a rozsah RPM medzi 5,200 a 7,200.

Pre viac informácií a podrobnosti o SQLIOStress pomôcka, pozri nasledujúci článok v databáze Microsoft Knowledge Base:
231619 Ako používať pomôcku SQLIOStress zdôrazniť disku subsystému ako napríklad SQL Server
Mnohí výrobcovia počítačov vybavia (napríklad, Compaq, Dell, brány, HP a tak ďalej) nariadiť jednotky s vypnutá vyrovnávacia pamäť zápisu. Však testovanie ukazuje, že to nemusí byť vždy v prípade tak, aby vždy otestujte úplne.

Dátových zariadení

V situáciách, ale všetko non-logged, server SQL Server bude vyžadovať iba záznamy denníka výpusty. Keď robiť-logged operácií, údajových stránok musí tiež výpusty stabilné skladovania; nie sú žiadne záznamy denníka pre regeneráciu kroky v prípade jeho poruchy.

Údajových stránok môžu zostať vo vyrovnávacej pamäti, až do procesu LazyWriter alebo CheckPoint vyprázdni ich stabilné skladovania. Pomocou protokolu WAL zabezpečiť, že záznamy denníka sú správne uložené zabezpečuje, že vymáhanie môžete obnoviť stránku údaje do známeho stavu.

To však neznamená, že je vhodné umiestniť súbory údajov na jednotke vo vyrovnávacej pamäti. Keď SQL Server vyprázdni údajov stany stabilné skladovania, záznamy denníka môžete skrátiť z denník transakcií. Ak údaje stránky sú uložené v prchavých vyrovnávacej pamäte, je možné skrátiť denník záznamov, ktoré by sa použili na obnoviť stránku v prípade zlyhania. Zabezpečiť, že vaše údaje a denníka pomôcky ubytovať stabilné skladovanie správne.

Zvýšenie výkonu

Počiatočné otázka, ktorá vzniká je: "Mám IDE jednotku, ktorá bola do vyrovnávacej pamäte, ale keď som so zdravotným postihnutím je, môj výkon stal významne nižšia než očakávané--prečo?"

Mnohé z jednotky IDE testované spoločnosťou Microsoft, spustenie rýchlosťou RPM 5,200 a SCSI disky ot/min 7,200. Ak vypnete písať caching IDE disk mechanického výkonu stala faktorom.

Existuje veľmi jasné oblasti riešiť výkon rozdiel: "Adresa kurz transakcia."

Existuje mnoho spracovania (databázy OLTP) systémy, ktoré vyžadujú vysoké transakčné kurzu on-line transakcií. Pre tieto systémy, zvážte použitie caching radič, ktorý môže riadne podporu vyrovnávacia pamäť zápisu a poskytnúť zvýšiť výkon pri zabezpečení integrity údajov.

Výrazne stretnúť zmeny výkonu s SQL Server na jednotke caching, kurz transakcia bola zvyšovať pomocou malé transakcie.

Testovanie ukazuje, že vysoké písať činnosť medzipamätí menších než 512 KB alebo nad 2 MB môžu spôsobiť pomalý výkon.
Zvážte nasledovný prí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 testu vzorky pre SQL Server sú:
SCSI(7200 rpm) 84 sekúnd
SCSI(7200 rpm) 15 sekúnd (kontrolórovi Caching)

IDE(5200 rpm) 14 sekúnd (disk cache povolené)
IDE(5200 rpm) 160 sekúnd
Balenie celý rad vložiť operácie v jediná transakcia spustí v približne 4 sekúnd vo všetkých režimoch.

Dôvodom je počet denníka flushes požadované. Bez transakcie, každý vložiť je transakcia, a to samo o a vždy, keď denník záznamov pre transakcie musia spláchnuť. Každý splachovacími je 512 bajtov vo veľkosti, ktorá vyžaduje významné mechanické jednotku intervencie.

Keď sa použije jedna transakcia, záznamy denníka pre transakcie môžu byť zviazané a jednotný, väčších písať možno použiť na splachovacími zozbieralo denník záznamov. Výrazne sa znižuje mechanického zásahu.

Upozornenie To sa neodporúča, môžete zvýšiť svoj rozsah transakcie. Dlho-bežiaci transakcie môžu viesť k nadmernému a nežiaducim blokovanie, ako aj zvýšiť režijné náklady. Použite počítadlá výkonu SQL Server 7.0, SQL Server 2000 a SQL Server 2005 SQL databáz servera: Ak chcete zobraziť počítadlá založené na denníka transakcií. Konkrétne, Denník bajtov spláchnuť/s môžete uviesť mnoho malých transakcie, ktoré vedú k vysokej mechanické disku činnosti.

Pozrite sa na závierky súvisiace s log splachovacími a určiť, ak počet denníka flushes je možné znížiť. V uvedenom príklade bol implementovaný jediná transakcia. Však v mnohých scenároch to môže viesť neželanému blokovacieho správanie. Pozrite sa na konštrukcii transakcie. Snad niečo podobného nasledujúce vykonávať šarží znížiť časté a malé denníka splachovacími č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 rovnaké vplyvu na výkon z častých a malé transakcie denníka píše sa nemusí zobrazovať. SQL Server 6.x prepíše na rovnakej stránke 2 KB denníka transakcií sú spáchané. To môže znížiť veľkosť denníka výrazne v porovnaní s 512-bajtové sektora hranice flushes v SQL Server 7.0, SQL Server 2000 a SQL Server 2005. Zmenšenie veľkosti denníka priamo týka čiastky mechanické jednotky aktivity. Avšak, ako bolo vysvetlené vyššie, SQL Server 6.x algoritmus môže vystaviť spáchaný transakcií.
SQL Server vyžaduje systémov na podporu "garantované dodávka na stabilné médiá", ako je uvedené v Microsoft SQL Server Always-On skladovanie roztoku recenzi program. FOĎalšie informácie o vstupných a výstupných požiadavkách pre databázový nástroj SQL Server nájdete po kliknutí na nasledovné číslo článku databázy Microsoft Knowledge Base:
967576Microsoft SQL Server databázu motora. vstupné/výstupné požiadavky

Vlastnosti

ID článku: 230785 - Posledná kontrola: 23. októbra 2011 - Revízia: 3.0
Informácie v tomto článku sa týkajú nasledujúcich produktov:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Workgroup
  • 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
Kľúčové slová: 
kbhowto kbinfo kbmt KB230785 KbMtsk
Strojovo preložené
DÔLEŽITÉ: Tento článok bol preložený pomocou softvéru na strojový preklad od spoločnosti Microsoft, nie prekladateľom. Spoločnosť Microsoft ponúka články preložené prekladateľmi aj strojovo preložené články, vďaka čomu máte možnosť prístupu ku všetkým článkom databázy Knowledge Base vo svojom jazyku. Strojovo preložený článok však nie je vždy perfektný. Môže obsahovať chyby týkajúce sa slovnej zásoby, syntaxe alebo gramatiky, podobne ako cudzinec môže robiť chyby, keď rozpráva vašim jazykom. Spoločnosť Microsoft nenesie zodpovednosť za akékoľvek nepresnosti, chyby alebo škody spôsobené akýmkoľvek nepresným prekladom obsahu alebo jeho použitím zo strany zákazníkov. Spoločnosť Microsoft softvér na strojový preklad pravidelne aktualizuje.
Pokiaľ chcete vidieť anglickú verziu článku, kliknite sem:230785

Odošlite odozvu

 

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