INF: Príčiny transakcia denníka SQL zapĺňajú

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

Na tejto stránke

Súhrn

Denník transakcií SQL Server sa môže stať plný, ktorý zabraňuje ďalšie aktualizáciu, Odstráneniealebo Vloženie aktivity v databáze, vrátane CHECKPOINT. To je zvyčajne vnímané ako chyba 1105:
Nemôže vyhradiť priestor pre syslogs objekt v databáze dbname, pretože logsegment je plný. Ak ste spustili v syslogs miesto, výpis do denníka transakcií. Inak pomocou vlastnosti databázy alebo sp_extendsegment zväčšiť veľkosť segmentu.
To sa môže stať na akékoľvek databázy, vrátane predlohy alebo tempdb. Tento článok popisuje možné príčiny a riešenia pre tie problémy, ktoré viedli k chybe 1105. Ak denník transakcií sa naplnila a v súčasnosti dostávajú chyba 1105, budete musieť prázdny log pomocou príkazu Výpis transakcií . Ďalšie informácie o používaní Výpis transakcií, nájdete v dokumentácii servera SQL Server.

Ďalšie informácie

Základnou charakteristikou pravda relačných databáz, ako je napríklad Microsoft SQL Server, je, že transakčné integrity. Každá transakcia musí byť úplne atómovej (t.j. funkčne nedeliteľný) v tom všetky zmeny musia byť buď uplatňuje alebo neuplatňuje, aj v prípade zlyhania systému. V rámci používateľom definované transakcie, všetky vyhlásenia uzávorkovaný BEGIN TRANSACTION a SPÁCHAŤ transakciu vyhlásenia sú uplatňuje alebo neuplatňuje. V implicitná transakcia, je považovaný za každý jeden príkaz SQL Atómový jednotka.

Táto schopnosť umožňuje SQL Server zažiť výpadku, havárie operačného systému, a tak ďalej pri výrobe a po reštarte, tak automaticky obnovenie databázy konzistentný stav, žiadne ľudské interakcie s vyžaduje. Toto je v kontraste s nie-relačné systémy, ktoré často vyžadujú zdĺhavé manuálne postupy skontrolovať databázu pre konzistentnosť problémov po zlyhaní systému.

Transakcia denníka mechanizmus je čo poskytuje túto schopnosť. Pretože transakčné integritu považuje za základné, vnútornú vlastnosť SQL Server, sa nedá vypnúť zapisovanie do denníka. Určitý nástroj alebo údržby, ako rýchlo BCP a SELECT INTO, urobiť minimálne ťažba dreva, ale aj balíkmi denníka miery tak, že je možné vrátenie.

Priestorov pre zapisovanie do denníka môžu byť značné. Napríklad, vo väčšine prípadov pred a po obrázku každého aktualizované riadok údajov sa musí zaznamenať plus že všetkých postihnutých indexu riadkov. Keďže pevné určitú transakciu záznam nadzemného musia byť zaznamenané pre každý riadok denníka, pomer aktualizované údaje do denníka miesta spotreby bude závisieť od šírku riadka. Úzky riadok, množstvo priestor denníka spotrebované konkrétnu aktualizáciu, Odstránenie alebo Vloženie by mohlo byť desaťkrát priestore dáta spotrebované. Širších riadkov, množstvo priestor denníka spotrebované bude úmerne menej. Spotrebe priestor denníka je nevyhnutný dôsledok poskytuje kvalifikované integritu. Správcu databázy musia poskytovať dostatočný priestor denníka pre jeho alebo jej konkrétnu inštaláciu.

Množstvo priestor denníka vyžaduje môže líšiť v závislosti od mnohých faktorov a je veľmi ťažké presne vopred odhadnúť. Zatiaľ čo všeobecné pravidlo-o-palec osobností, ako 15 až 30 percent veľkosti databázy, sú niekedy spomínaný ako východiskový bod pre dimenzovanie denníku, v skutočnosti to značne líšia. Úspešné inštalácie SQL Server často urobiť nejaké jednoduché empirické testy zhruba posúdiť požiadavky priestoru denníka pre ich konkrétne dáta a aplikácie a potom veľkosť ich log na základe tohto. Pokus o veľkosti denníka výlučne na výpočty a bez skúšky je ťažké a často nepresné.

Niekoľko ťažké predpovedať faktorov môže účet za rozdiely v spotrebe priestor denníka. Jedným z faktorov je ukazovateľa. Pre dané údaje modifikácia príkaz SQL, prístup k plánu môže líšiť podľa toho štatistické rozdelenie dát. Rôzne prístup plány môžu konzumovať rôzne sumy priestor denníka. Ďalším faktorom je nevyhnutnej vnútornej databáze fragmentácie, ktorá môže postihnúť číslo stránky rozdelí vykonané. Neexistuje nič, čo môže byť vykonané alebo malo by sa preskúmať alebo vplyv na tento proces, ako SQL Server automaticky spravuje údaje pre používateľa.

Príklad jednoduchého testu bude spúšťať DBCC CHECKTABLE(syslogs), ktorá vráti počet strán 2048-bajtové bloky dát v denníku pred a po vykonaní reprezentatívna vzorka údajov úpravu dotazov. To môže dať približnú predstavu o rázov denníka tieto typy dotazov. To je zvyčajne lepšie chybovať na strane prebytok pri poskytovaní log alebo dáta na disku pre relačné databázy, ako napríklad SQL Server.

Pre SQL Server 7.0 a 2000 triedy servery, denník transakcií má schopnosť rozširovať podľa potreby. Miera rastu možno riadi užívateľa alebo povolené využívať všetky dostupné diskovej kapacity. Súbor denníka je zložený z niekoľko súborov virtuálnej denníka. Počet a veľkosť tieto virtuálne log súborov sú určované SQL Server a nie je možné konfigurovať. Pri prvom vytvorení databázy každý fyzický súbor denníka má minimálne 2 virtuálne Log súborov. Niekedy na správcu databázy a umožní "skrátiť denník na Checkpoint pozorovanie" možnosť databázy v snahe zabrániť vyčerpanie priestoru denníka. Zámerom tejto možnosti je poskytnúť automatickú metódu skrátenia denníka, hlavne pre rozvoj alebo testu databázy, ktoré sa nespoliehajú na denník skládky pre zálohovanie. Túto možnosť zakázať zapisovanie alebo transakčné integrity. To len spôsobuje kontrolný bod handler pokus denníka skracovania približne každých 60 sekúnd. Všimnite si, že v denníku nie skráti pri vydávaní príkazu manuálne kontrolné stanovište v databáze s "skrátiť denník na Checkpoint pozorovanie" na. Táto voľba je vždy na tempdb databázy, hoci nie je uvedený v stĺpci Stav sp_help uložené postup produkcie.

Aj s "skrátiť denník na Checkpoint pozorovanie" možnosť aktivovaný, celý rad faktorov môže spôsobiť vyčerpanie priestoru denníka. Tieto sú uvedené nižšie:
  1. Veľké Atómový transakciu, najmä hromadnej aktualizácie, vložiť alebo odstrániť: považuje za každý jeden príkaz SQL Atómový jednotka thatmust uplatňuje alebo neuplatňuje v plnom rozsahu. Z tohto dôvodu, všetky rowalterations, musíte byť prihlásení a transakcie nemôže byť skrátené nad itsduration. Napríklad, ak veľké hromadnej vložiť bol vydaný že doba spustenia päť minút, log spotrebovanej tejto transakcie nemôže byť truncatedfor tohto obdobia. Správcu databázy musia poskytnúť dostatočné denníka spacefor najväčšia hromadná operácia očakáva alebo musí vykonávať hromadné operácie insmaller skupín.
  2. Nezapojené transakcie: denník môže byť len truncatedprior najstarší nezapojené transakcie. Existuje niekoľko možných causesof nezapojené transakcie, z ktorých väčšina sú chyby aplikácií. Theseinclude:
    1. Hromadné transakcie: považované za vyššie, po dobu trvania veľkú väčšinu transakcia denníka nemôže byť skrátené záznamy generované to. Však takáto transakcia takisto bráni denníka skracovania ďalšie kratšie transakcií, ktoré spáchať počas toho istého obdobia.

      Povedzme správcu databázy má veľké log je dostatočná pre najväčšie predstavil si hromadné transakcie. Ešte počas spustenia tejto transakcie iných shorter vyhlásenia dáta zmena môže tiež byť náročné priestor denníka. Tento priestor denníka nemôže byť skrátené nakoľko veľkom voľne ložené transakcie začal prvý a teda sa stane najstaršie nezapojené transakcie. Správca musíte byť vedomí súbežnosť a denníka vplyvu transakcie veľkom voľne ložené, a veľkosť denníka vhodne.
    2. Zle navrhnutá aplikácia, ktorá umožňuje vstup používateľa alebo iné zdĺhavé aktivity v rámci používateľom definované transakcie. Napríklad po vydaní BEGIN TRANSACTION, aplikácia môže zobraziť výzvu používateľa pre vstup, ktoré môže trvať dlhú dobu, v závislosti od správania používateľov. Kým používateľ nezareaguje, a žiadosť vydá potvrdenie denníka skracovania nebude možné.
    3. Chyby aplikácie v ktorom transakcia nie je spáchané: spoločnú príčinou toho je nesprávna manipulácia s DB knižnice hovoru dbcancel() rámci používateľom definované transakcie. Keď dotaz je zrušený s dbcancel(), v súčasnosti vykonávajúci SQL vyhlásenie je zrušená a vrátená späť, ale nie je vonkajšie transakcie. Žiadosť musí byť vedomí tohto a vydať príkaz potrebné Zroluje transakciu alebo SPÁCHAŤ transakciu uzavrieť transakciu. Neschopnosť robiť tak môže často viesť k chybové 3902:
      Vykonaním transakcie nemá žiadne zodpovedajúce BEGIN TRANSACTION.
      To môže byť užitočné pre aplikáciu poslať vyberte @@TRANCOUNT určiť akú úroveň vnorenia transakcie existuje. Však aplikácie by nie slepo to a potom vydá potvrdenie alebo vrátenie späť na dosiahnutie @@TRANCOUNT = 0. To je, pretože ak @@TRANCOUNT je niekedy odlišné od čo očakáva žiadosť, znamená uplatňovanie stratilo sledovať úroveň vnorenia transakcie, ktorá je dizajn chyby aplikácie. Vydávanie potvrdenia alebo vrátenie späť na tomto mieste môže spôsobiť uplatňovanie alebo prerušuje nezamýšľané transakcie, pretože aplikácia nevie, ktoré transakcie za následok úroveň nezamýšľané transakcie. Namiesto toho programátor by mali ladiť aplikácie a všetky uložené procedúry zapojiť určiť príčinu neplánovaných transakcia úroveň.
    4. Sieťová chyba, ktorá neinformuje SQL Server rozbité sieťového pripojenia: Ak klienta visí, reštartuje alebo vypne v rámci používateľom definované transakcie, Sieťová vrstva by mala informovať SQL Server to. Ak sieť nemá správne robiť to, z perspektívy SQL Server klient sa zdajú byť prítomný, a otvorené transakcie od tohto klienta zostanú zachované. To je problém so sieťou a, musia byť sledované ako také. Ako riešenie, správca môže byť schopní určiť, aj keď používa sp_who, sp_lock alebo sieťový nástroj ktoré klientská relácia stále existuje a manuálne ho zabiť.
    5. Transakcia nedopustili kvôli blokovanie: V multi-užívateľské prostredie je možné otvorené transakcie k zablokovaniu na zámky držané iným procesom. Transakcie v tomto prípade však zostávajú otvorené, prevencia denníka skracovania. Odhaliť to, programátor alebo správcu databázy musieť použiť sp_who, sp_lock alebo iné nástroje na analýzu prostredia súbežnosti. Vo väčšine prípadov blokovanie problémy môžu byť znížené alebo eliminované prostredníctvom riadne dotazu a index návrh databázy.
    6. Neúspešný pokus o zrušenie modifikácia dotazu údaje: Ak aplikácia otázky dbcancel() a dotaz nie je zrušený siete alebo SQL problém, dotaz bude pokračovať a transakcie zostane otvorené. Ak máte podozrenie na problém tu, použite sp_who vidieť Ak dotaz je zrušený. Ak pokus o zrušenie TCP/IP sockets klienta, vyskúšať test pomenované presmerovanie klienta, alebo spustiť klientsku aplikáciu v počítači servera pomocou miestne potrubia. Pomôže rozoznať, či siete alebo SQL problém zabraňuje zrušiť.
  3. Kontrolný bod handler skracovania pásma prekročená: Althoughthe denník je skrátený každých 60 sekúnd, rýchlosť akou toto skrátenie takesplace je konečný. Tento scenár je nezvyčajné a ďalšie možné príčiny logoverflow posudzovať a vylúčiť prvý pred kontrolou thispossibility. Je však možné prekročiť maximálnu skracovania sadzba ifmany klientov súčasne vydávajú rozsiahle aktualizácie. To je podobné ako afunnel, ktorý môže len odtok tekutiny v určitej miere, a môže byť preplnená evenwhile odvodnenie. V tomto scenári žiadosti reštrukturalizovať reducethe počtu riadkov aktualizovaná, ktorá by mala byť vždy primárne dizajn goalfor akéhokoľvek relačnej databázy tak ako tak.

    Ak to nie je uskutočniteľné, môže byť znovu thesystem pre zvýšenú disk i/o pásma hoci striping, ďalšie ovládače, a tak ďalej. To je bežné v tomto prípade vidieť thecheckpoint proces manipulátora stráviť zvyšuje množstvo času v DUMPTRANSACTION stave, pretože sa snaží držať krok s denníka skracovania. Akonáhle je prekročená thetruncation (pozri nižšie) sa nemusia zobraziť vôbec pokus skracovania v databáze do denníka iscleared checkpointhandler.
  4. Skracovania prah prekročený: checkpoint handleressentially nemá výpis transakcií s TRUNCATE_ONLY. Rovnako, ako keby tento wasissued manuálne, to nebude vždy úspešná ak denník je už plný acertain bodu. Napríklad roztrhnutiu aktualizácia činnosti mohol vyplniť denníka to95% medzi návštevami popisovačom checkpoint. Keď kontrolný bod handlerattempts skrátenie, kým denník nie je úplne plný, môže byť príliš fullto umožniť skracovania. To je preto skracovania denníka musí sám belogged. Jediným riešením v tomto prípade je použitie výpisu transakcie s NO_LOGto ručne skrátiť log. Pomocou NO_LOG sa neodporúča exceptwhen absolútne nevyhnutné, ako to je non-logged operáciu počas ktorej systemfailure mohol predstaviť databázy chyby.
  5. Interakcie medzi ktorejkoľvek z uvedených: napríklad undernormal podmienok v prostredí aktualizácia náročných checkpoint handlertruncation sadzba môže viesť denník od vypĺňanie. Ak je dočasne opentransaction spôsobené niektorou z vyššie uvedených podmienok (napríklad zámok sváru) spôsobuje denník vyplniť povedať, 50%, tam bude oveľa menej zvažovaním forhandling iné aktualizácie situácie, takže je oveľa pravdepodobnejšie dosiahne thetruncation hranicu, na ktorom mieste Automatická skracovania nebude možné.Transakcie s tempdb ste prihlásení ako ľubovoľnú inú databázu. Pretože Skrátiť denník na CHECKPOINT je v tempdb, vo väčšine prípadov skráti sa protokole a notoverflow. Však niektorý z uvedených okolností môže spôsobiť tempdb denníka tofill hore. Tempdb je zvyčajne nakonfigurovaný pre zmiešané log a data(sysusages.segmap=7) tak údajov a log činnosti sa navrhujú pre sameavailable priestor. Určité Transact-SQL konštrukcie ako Skupina, Poradie podľa DESCa tak ďalej, bude automaticky požadovať tempdb pre pracovný priestor.Tiež to spôsobí záznamu implicitné BEGIN TRANSACTION v tempdb pre pracovný priestor. Tento tempdb transakcie willcontinue po dobu trvania transakcie v používateľ db, ktoré môžu defertempdb denníka skracovania pre toto obdobie. Ak transakcie v db ishalted užívateľ z akéhokoľvek dôvodu, vrátane blokovanie zámku, alebo notprocessing dbnextrow() žiadosti až do jeho ukončenia, transakcie s tempdb likewisebe vľavo otvorená, prevencia tempdb denníka skracovania. Programátor musí ladiť žiadosť o povoleniena alebo riešenie problémov súbežnosti, ktoré sú príčinou tejto.
  6. Skracovania denníka transakcií v SQL Server 7.0 and2000 triedy servery je dosiahnuť upravením virtuálne Log súborov. Ak anyportion aktívneho denníka je bydliskom na danom VLF, že virtuálne Log Filecannot skrátené. Ak aktívneho denníka je bydliskom na všetky virtuálne Log súborov, denníka nemôže byť skrátené. Ak autogrowth zapnutá a nie je priestor na thevolume kde býva denník transakcií a maximálnu veľkosť súboru nemá nie beenreached, denník transakcií rastie v rozsahu stanovenom v denníku fileproperties.
Takto opisuje denníka skracovania správanie pri spustení SQL na základe či Skrátiť denník na CHECKPOINT nastavená.
  • Ak je nastavená Skrátiť denník na CHECKPOINT a log sa zistí plné pri štarte, to bude automaticky vysype s no_log.
  • Skráťte denník na CHECKPOINT je teraz predvolenú predlohu, pretože jeho denníka nemôžete dať druhému zariadenia, tak to môže nikdy byť naložené. Jedinou schodnou možnosťou je todiscard denníku, keď sa dostane plné.
  • Ak Skrátiť denník na CHECKPOINT nie je nastavená, a denníku zistí, že sa úplne na štarte, obnovenie dokončí, ale konečný kontrolný bod nie je napísané. Administratorcan dostať do databázy a výpis denníka s no_truncate na uloženie dát, potom výpis s no_log očistiť ju (alebo jednoducho vymazať).

ODKAZY


Pre viac informácií, označovať nasledujúci Microsoft Training & Certification kurz:
Spoločnosť Microsoft Corporation 2072 správu databázy Microsoft SQL Server 2000
Problémy špecifické pre SQL Server 7l 0 a neskôr, pozri nasledujúci článok Microsoft Knowledge Base:
317375 INF: Transakcií rastie nečakane alebo zaplneniu na serveri SQL Server

Vlastnosti

ID článku: 110139 - Posledná kontrola: 18. júna 2014 - Revízia: 4.0
Informácie v tomto článku sa týkajú nasledujúcich produktov:
  • Microsoft SQL Server 6.5 Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 4.21a Standard Edition
Kľúčové slová: 
kbsqlsetup kbinfo kbother kbmt KB110139 KbMtsk
Strojovo preložené
DÔLEŽITÉ: Tento článok je preložený pomocou softvéru na strojový preklad od spoločnosti Microsoft a možno ho opraviť prostredníctvom technológie Community Translation Framework (CTF). Microsoft ponúka strojovo preložené články, články upravené komunitou aj články preložené prekladateľmi, aby zabezpečil prístup ku všetkým článkom databázy Knowledge Base vo viacerých jazykoch. Strojovo preložené články aj upravené články môžu obsahovať chyby týkajúce sa slovnej zásoby, syntaxe alebo gramatiky. Microsoft nenesie zodpovednosť za akékoľvek nepresnosti, chyby alebo škody spôsobené neprávnym prekladom obsahu alebo jeho použitím zo strany našich zákazníkov. Ďalšie informácie o technológii CTF nájdete na lokalite http://support.microsoft.com/gp/machine-translation-corrections/sk.
Pokiaľ chcete vidieť anglickú verziu článku, kliknite sem: 110139
Upozornenie na neaktuálny obsah článku databázy KB
Tento článok obsahuje informácie o produktoch, pre ktoré spoločnosť Microsoft už neposkytuje technickú podporu. Z tohto dôvodu je tento článok publikovaný ako nezmenený a už nebude aktualizovaný.

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