Protokol transakcí neočekávaně roste nebo naplnění v počítači, který je spuštěn SQL Server

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

Na serveru SQL Server 7.0, SQL Server 2000 a serveru SQL Server 2005, s nastavením automatické zvětšování souborů protokolu transakcí můžete rozšířit automaticky.

Obvykle se velikost souboru protokolu transakcí nestabilizuje při maximální počet transakcí, které se mohou vyskytnout může uchovávat mezi truncations protokolu transakcí, aby kontrolní body nebo transakce protokolu Spustit zálohování.

Nicméně v některých situacích může protokolu transakcí velmi velké a spustit místo nebo zaplnění. Obvykle se zobrazí následující chybová zpráva v případě, že soubor protokolu transakcí zabírá k dispozici místo na disku a nelze rozšířit o:
Chyba: 9002, Závažnost: 17, stav: 2
V souboru protokolu databáze ' %. * ls' je plná.
Používáte-li SQL Server 2005, se zobrazí chybová zpráva, je podobná následující:
Chyba: 9002, závažnosti: 17, Stav: 2
Transakčního protokolu databáze ' %. * ls' je plná. Chcete-li zjistit, proč místo v protokolu nelze znovu použít, viz sloupec log_reuse_wait_desc v sys.Databases
K této chybě může označit serveru SQL Server databáze podezření z důvodu nedostatku místa pro rozšíření protokolu transakce. Pro Další informace o obnovení z této situace Téma "Nedostatek místa na disku" v dokumentaci SQL Server Books Online.

Rozšíření protokolu transakcí může dále vést v následujících situacích:
  • Soubor protokolu transakce velmi velké.
  • Transakce může selhat a může začít vrátit zpět.
  • Transakce může být časově náročná.
  • Dochází k problémům s výkonem.
  • Může dojít k zablokování.

Příčiny

Rozšíření protokolu transakcí může dojít z následujících důvodů z důvodů nebo scénářů: Poznámka: SQL Server 2005, můžete zkontrolovat log_reuse_wait a log_reuse_wait_desc sloupce zobrazení katalogu sys.databases určit následující akce:
  • Proč nejsou opakovaně místo protokolu transakcí
  • Proč nemůže být zkráceny protokolu transakcí

Nepotvrzený transakce

Explicitní transakce zůstat nepotvrzené, pokud není explicitní příkaz POTVRDIT nebo vrácení zpět. Tato situace často dochází, když ZRUŠENÍ nebo příkaz Transact SQL KILL bez problémy s aplikací odpovídající příkaz vrátit zpět. Zrušení transakce dojde, ale jeho nelze vrátit zpět; proto serveru SQL Server nelze zkrátit každé transakce dochází-li toto přerušení transakce je stále otevřen. Je možné Ověřte, zda je aktivní pomocí odkazu OPENTRAN DBCC Transact-SQL transakce v databázi v určitém čase. Další informace o této konkrétní situaci získáte naleznete v následujících článcích znalostní báze společnosti Microsoft:
295108Neúplné transakce mohou držet velký počet zámků a blokování případu
171224 Principy fungování příkazu Transact-SQL KILL
Dále naleznete v tématu "dbcc opentran" v SQL Server knihy Online.

Scénáře, které může mít za následek nesvěřené transakce:
  • Návrhu aplikace, která předpokládá, že všechny chyby způsobit vrácení zpět.
  • Návrhu aplikace, který nebere v úvahu zcela název účtu serveru SQL Server chování, když se vrátí zpět do transakce nebo speciálně vnořené s názvem transakce. Pokusíte-li se vrátit vnitřní názvem transakce, zobrazí se následující chybová zpráva:
    Server: Msg 6401, úroveň 16, stav 1 řádek 13 nelze vrátit zpět InnerTran. Ne byla nalezena transakce nebo otevřeny tohoto názvu.
    Po serveru SQL Server generuje chybovou zprávu a pokračuje další příkaz. Jedná se o návrh. Další informace naleznete v tématu "Vnořené transakce" nebo "SQL uvnitř Server"téma v SQL Server Books Online.

    Společnost Microsoft doporučuje Po při návrhu aplikace:
    • Otevřít pouze jednu jednotku transakce (zvažte možnost jiný proces může volat Tvé).
    • Kontrola @@ TRANCOUNT před vydáním potvrzení, Vrácení zpět, vrácení, nebo podobné příkazu nebo prohlášení.
    • Napište kód za předpokladu, že jiný @@ TRANCOUNT může být "vnořit" Tvé a plán vnější @@ TRANCOUNT zahrnuty zpět, když dojde k chybě.
    • Zkontrolujte otevřeny a označit možnosti pro transakce. (Tyto uvolnit zámky!)
    • Proveďte úplné testování.
  • Aplikace, která umožňuje interakci uživatele uvnitř transakce. To způsobí, že transakce zůstat otevřené po dlouhou dobu, která příčiny, blokování a transakce protokolu růst, protože nelze otevřít transakci zkrácen a nové transakce jsou přidány do protokolu po otevření transakce.
  • Aplikace, která nekontroluje ověřit TRANCOUNT @@ že neexistují žádné otevřené transakce.
  • Síť nebo jiné chyby, které zavřete aplikaci klienta připojení k serveru SQL Server bez ji.
  • Sdružování připojení. Po pracovních podprocesů vytvoření SQL Server znovu použije je, pokud jsou neposkytují připojení. Pokud připojení uživatele spustí transakci a odpojí před potvrzením nebo vrácení zpět transakce a připojení poté opakovaně používá stejné zřetězení, předchozí transakce zůstane stále otevřené. Tato situace vede zámky, které zůstávají otevřené z předchozí transakce a zabraňuje zkrácení o potvrzené velikosti souborů s protokoly transakcí v protokolu, které má za následek velké.Další informace o připojení sdružování, klepnutím na následující číslo článku databáze Microsoft Knowledge Base:
    164221Jak povolit sdružování připojení ODBC aplikace

Extrémně velké transakce

Záznamy protokolu do souborů protokolu transakcí, které jsou zkráceny na základ podle jednotlivých transakcí. Pokud je velký, obor transakcí, po jeho nejsou odebrány z se spuštěna transakcí a transakcí transakce protokolu, pokud jej dokončí. To může mít za následek velké soubory protokolu. Pokud transakce je dostatečně velký, soubor protokolu, může využít dostupné místo na disku a způsobit typu "celé transakce protokolu" chybová zpráva typu Chyba 9002. Další informace, jak postupovat, když se zobrazí tento typ chyby zprávy je uveden v části "Další informace" v tomto článku. Navíc trvá hodně času a zatížení serveru SQL Server vrátit zpět velké transakce.

Operace: DBCC DBREINDEX a vytvořit INDEX

Z důvodu změn v modelu pro zotavení v systému SQL Server 2000 Při použití režimu úplné obnovení a spustit DBCC DBREINDEX, transakce protokolu mohou rozšířit podstatně více, SQL Server 7.0 v porovnání ekvivalentní obnovení režimu pomocí SELECT INTO nebo HROMADNÉ kopírování a s "USEKNOUT. Odhlásit na chkpt.".

Ačkoli se velikost transakce protokolu Po DBREINDEX operace může být problém, tento přístup přináší lepší výkon obnovení protokolu.

Při obnovení ze zálohy protokolu transakce

To je popsáno v následujících Microsoft Knowledge Base článek:
232196 Využité místo protokolu zobrazí růst po obnovení ze zálohy

Pokud nastavíte na serveru SQL Server 2000 pomocí Hromadně zaevidované režim a vydání HROMADNÉ kopírování nebo vyberte příkaz INTO, každé změně rozsahu je označen a zálohován při zálohování protokolu transakce. Přestože To umožňuje zálohovat protokoly transakcí a obnovení v případě selhání i Po provedení hromadné operace se tím zvětší velikost transakce protokoly. SQL Server 7.0 neobsahuje tuto funkci. Pouze záznamy pro SQL Server 7.0 rozsahy, které jsou změněny, ale nezaznamenává skutečné rozsahy. Proto protokolování zabere podstatně více místa na serveru SQL Server 2000 než SQL Server 7.0 v režimu hromadných protokolu, ale není tolik, jako je tomu v plné režim.

Klientské aplikace zpracovat všechny výsledky

Jestliže vydáváte dotazu serveru SQL Server a zpracovat výsledky okamžitě, můžete být zámky a snížení souběžnosti na vašem Server.

Například Předpokládejme, že vydávání dotaz vyžadující řádků ze dvou stránek k naplnění sady výsledků. SQL Server analyzuje kompiluje, a Spustí dotaz. To znamená, že sdílené uzamčení jsou umístěny na dvě stránky, které obsahovat řádky, které jsou nutné k uspokojení dotazu. Navíc Předpokládejme, že ne všechny řádky nevejde se na jeden paket SQL Server TDS (metoda podle který server komunikuje s klientem). Jsou pakety TDS vyplnit a odeslat klientovi. Pokud všechny řádky z první stránky velikost paketu TDS SQL Server odemkne sdílené stránky, ale ponechá na sdílený zámek druhá stránka. SQL Server počká klientovi požadovat další údaje (můžete To lze provést pomocí DBNEXTROW/DBRESULTS SQLNextRow/SQLResults, nebo Například FetchLast/FetchFirst).

To znamená, že sdílený zámek zadrženy, dokud klient požaduje zbývající data. Jiné procesy, které data požadavku na druhé stránce může být zablokován.

Dotazy časový limit před protokolu transakce dokončí rozšíření a false "Protokolu plný" chybové zprávy

V této situaci i když je dostatek místa na disku, stále Zobrazí se chybová zpráva "nedostatek místa".

Tato situace se liší pro SQL Server 7.0 a SQL Server 2000.

Dotaz může způsobit, že transakce přihlásit automaticky rozbalte protokol transakce je téměř plná. Může to zabere více času a dotaz může být zastavena nebo pravděpodobně překročí jeho vypršení časového limitu období, z tohoto důvodu. SQL Server 7.0 vrátí chybu 9002 v této situaci. Tento problém se nevztahuje na serveru SQL Server 2000.

SQL Server 2000, máte-li Auto shrink zapnutá možnost pro databázi, je je velmi malý čas během které protokolu transakcí, které se pokusí automaticky rozbalovat, ale nemůže protože Auto shrink funkce je souběžně spuštěna. To může způsobit také false instance 9002 došlo k chybě.

Soubory protokolu transakcí obvykle automatické rozšíření rychle dochází. Avšak v následujících situacích, může trvat déle než obvyklé:
  • Přírůstek jsou příliš malé.
  • Server je pomalý z různých důvodů.
  • Diskové jednotky nejsou dostatečně rychlý.

Nereplikovaných transakce

Velikost protokolu transakcí aplikace Publisher databáze můžete rozšířit, pokud používáte replikaci. Transakce které ovlivňují objekty, které jsou replikovány jsou označeny jako "Pro replikaci." Tyto transakce, například nesvěřené transakce, nejsou odstraněny po kontrolní bod nebo po protokolu transakcí do protokolu čtení úlohy zálohování transakce se zkopíruje do distribuční databáze a zruší jejich označení. Pokud problém s úkolem protokolu čtení zabrání čtení těchto transakcí v na aplikace Publisher databáze, velikost protokolu transakce může pokračovat v rozšiřování jako počet zvyšuje nereplikovaných transakce. Můžete použít DBCC OPENTRAN Transact-SQL reference k identifikaci nejstarší nereplikovaných transakce.

Další informace o odstraňování potíží nereplikovaných transakce, naleznete v tématech "sp_replcounters" a "sp_repldone" serveru SQL Server Knihy Online.

Další informace získáte klepnutím na tlačítko naleznete v následujících článcích znalostní báze společnosti Microsoft:
306769Oprava: Protokolu transakce snapshot publikované databáze nemůže být zkráceny
240039 Oprava: DBCC OPENTRAN podávat informace o replikaci
198514 Oprava: Obnovení na nový server způsobí transakce zůstat v protokolu

Další informace

Protokol o transakcích databáze je spravována jako sada virtuální soubory protokolu (VLFs) na základě velikosti serveru SQL Server určuje interně Celková velikost souboru protokolu a přírůstek v použití protokolu rozbalí. Protokol je vždy rozšiřuje v jednotkách celé VLFs a pouze lze komprimovat VLF hranici. VLF může existovat v jednom ze tří stavů: aktivní, OBNOVITELNÉ a znovu použitelné.
  • AKTIVNÍ: Začíná aktivní část protokolu v sekvenci protokolu minimální číslo (LSN), které představuje aktivní transakci (nepotvrzené). Aktivní část protokolu končí LSN posledního zápisu. Všechny VLFs, které obsahují libovolné části aktivního protokolu se považují za aktivní VLFs. (nevyužité místo v protokolu fyzické není součástí žádné VLF.)
  • OBNOVITELNÉ: Část protokolu, který předchází nejstarší aktivní transakce je nezbytné zachovat posloupnost záloh protokolu pro účely zotavení.
  • ZNOVU POUŽITELNÝ: Pokud jsou nezůstala záloh protokolu transakce, nebo pokud je Protokol již zálohován, SQL Server znovu použije VLFs před nejstarší aktivní transakce.
Dosáhne konce fyzického souboru protokolu serveru SQL Server, Spustí opakovaného použití příslušné místo v souboru fyzické vydáním CIRCLING zpět operace na začátek soubory. Ve skutečnosti recykluje serveru SQL Server místa v souboru protokolu, který již není nutné pro obnovení nebo zálohování účely. Pokud záložní sekvenci protokolu je uchovávána, část protokolu před minimální LSN nemůže být přepsána, dokud zpět nahoru nebo zkrátit ty protokolu záznamy. Po provedení protokolu zálohování serveru SQL Server můžete zpět kruhu na začátek souboru. Po serveru SQL zpět začít psát kruhy záznamy protokolu dříve v souboru protokolu se opakovaně část protokolu je pak mezi koncem logického protokolu a aktivní část protokolu.

Pro Další informace naleznete v tématu "Architektura fyzické transakce protokolu" v SQL Server Online. Navíc uvidíte vynikající diagramu a Diskuse o této stránce 190 "Uvnitř SQL Server 7.0" (Soukup, Ron. Uvnitř Microsoft SQL Server 7.0, Microsoft Press, 1999) a také na stránkách 182 prostřednictvím 186 "Uvnitř SQL Server 2000" (Delaney, Kalen. Vnitřní Microsoft SQL Server 2000, Microsoft Press, 2000). Databáze serveru SQL Server 7.0 a SQL Server 2000 mají Možnosti automatické zvětšování a autoshrink. Tyto možnosti lze použít k pomoci Komprimovat nebo rozšířit svůj soubor protokolu transakcí.

Další informace o způsobu těchto možnosti mohou ovlivnit váš server, klepněte na následující číslo článku databáze Microsoft Knowledge Base:
315512Důležité informace pro automatické zvětšování a Autoshrink konfigurace serveru SQL Server
Je rozdíl mezi zkrácení versus komprese souborů protokolu transakcí. Když se zkrátí serveru SQL Server soubor protokolu transakcí, to znamená, že obsah tohoto souboru (například potvrzené transakce) se zrušují. Ale při zobrazení velikosti souboru z hlediska místa na disku (například v programu Průzkumník Windows nebo pomocí dir příkaz) velikost zůstane beze změny. Však prostor uvnitř Soubor LDF může opětovně nyní nové transakce. Pouze v případě serveru SQL Server Zmenší velikost souboru protokolu transakcí, se ve skutečnosti zobrazí změna fyzická velikost souboru protokolu.

Další informace o tom, jak zmenšit protokoly transakcí, klepněte na tlačítko naleznete v následujících článcích znalostní báze společnosti Microsoft:
256650Jak zmenšit transakčního protokolu SQL Server 7.0
272318 Zmenšením protokolu transakcí v SQL Server 2000 s DBCC SHRINKFILE
Další informace o protokolu transakce SQL Server verze 6.5 použití, klepněte na následující číslo článku databáze Microsoft Knowledge Base:
110139Způsobí, že protokol transakce SQL zaplnění

Jak najít dotazů, které spotřebovávají velké množství prostoru protokolu SQL Server 2005

SQL Server 2005 použijete k zobrazení dynamickou správu sys.dm_tran_database_transactions (DMV) vyhledejte dotazů, které spotřebovávají velké množství místa protokolu. Následující sloupce v sys.dm_tran_database_transactions DMV může být užitečné:
  • database_transaction_log_bytes_used
  • database_transaction_log_bytes_used_system
  • database_transaction_log_bytes_reserved
  • database_transaction_log_bytes_reserved_system
  • database_transaction_log_record_count
Dotaz lze ve sloupci sql_handle sys.dm_exec_requests DMV získat skutečné příkazu text, který spotřebuje velké množství místa protokolu. Lze provést sys.dm_tran_database_transactions DMV a sys.dm_tran_session_transactions DMV ve sloupci transaction_id a potom ve sloupci session_id přidáním další spojení s sys.dm_exec_requests.

Další informace o sys.dm_tran_database_transactions DMV naleznete na webu Microsoft Developer Network (MSDN):
http://msdn2.microsoft.com/en-us/library/ms186957.aspx
Další informace o sys.dm_tran_session_transactions DMV naleznete na webu MSDN:
http://msdn2.microsoft.com/en-us/library/ms188739.aspx
Další informace o sys.dm_exec_requests DMV naleznete na webu MSDN:
http://msdn2.microsoft.com/en-us/library/ms177648.aspx

Vlastnosti

ID článku: 317375 - Poslední aktualizace: 19. května 2011 - Revize: 8.0
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
Klíčová slova: 
kbsqlsetup kbinfo kbmt KB317375 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:317375

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