Momentálne ste offline a čaká sa, kým sa znova pripojíte na internet

Denníka transakcií rastie nečakane alebo zaplneniu v SQL Server

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.

317375
Súhrn
Ak je jeho voľba nastavená v Microsoft SQL Server 2005 a neskoršie verzie SQL Server 2000 a SQL Server 7.0, súbory denníka transakcií môžu automaticky rozšíriť, aby maximálna veľkosť súboru denníka z 2 terabajtov (TB) za súbor denníka.

Zvyčajne, veľkosť súboru denníka transakcií stabilizuje keď to môže mať maximálny počet transakcií, ktoré môžu nastať medzi transakcia denníka truncations, ktoré sú vyvolané kontrolné stanovište alebo zálohy denníka transakcií.

Však, v niektorých prípadoch transakcia denníka môže stať veľmi veľké a beží nedostatok miesta alebo stať sa plnohodnotnými. Zvyčajne dostanete nasledovné chybové hlásenie, keď súbor denníka transakcií používa voľné miesto na disku a nemôže rozbaliť dlhšie:
Chyba: 9002, závažnosť: 17, štát: 2
Súbor denníka pre databázu "%. * ls' je plný.
Ak používate SQL Server 2005, zobrazí chybové hlásenie, nasledovnému:
Chyba: 9002, závažnosť: 17, štát: 2
Denník transakcií databázy "%. * ls' je plný. Chcete zistiť, prečo miesto v denníku nemožno opätovne použiť, pozri log_reuse_wait_desc kolóny v sys.databases
Popri tomto chybovom hlásení servera SQL Server môže označiť databáz podozrivý z dôvodu nedostatku miesta pre transakciu denníka rozšírenia. Ďalšie informácie o tom, ako sa zotaviť sa z tejto situácie, "Nedostatok miesta na disku" téme v SQL Server Books Online.

Navyše transakcia denníka rozšírenia môžu vyskytnúť jeden z nasledujúcich dôvodov alebo v jednom z týchto scenárov:
  • Súbor denníka transakcií veľmi veľké.
  • Transakcie môžu zlyhať a môže začať vrátiť späť.
  • Transakcie môže trvať dlhú dobu na dokončenie.
  • Môžu nastať problémy s výkonom.
  • Blokovanie môže dôjsť.
  • Databáza sa zúčastňujú skupiny dostupnosti AlwaysOn.
Ďalšie informácie
Transakcia denníka expanzia môže dôjsť z jedného z nasledujúcich dôvodov alebo scenáre.


Poznámka V SQL Server 2005 a novšie verzie, môžete skontrolovať log_reuse_wait a log_reuse_wait_desc stĺpy z pohľadu sys.databases katalóg zistiť prečo priestor denníka transakcií, sa nesmú opätovne použiť a prečo nemôže byť skrátené denník transakcií.


Nezapojené transakcie
Explicitných transakcií zostávajú nezapojené ak nevydá príkaz výslovne potvrdiť alebo ODVOLAŤ. To sa vyskytuje najviac často, keď žiadosť vydá zrušiť alebo Transact-SQL zabiť príkaz bez zodpovedajúceho príkazu vrátenia. Zrušení transakcie nastane, ale to nie vrátiť. Preto SQL Server nemôže skrátiť Každá transakcia že vyskytuje po tomto, pretože bolo prerušené transakcia je stále otvorený. DBCC OPENTRAN Transact-SQL odkaz môžete použiť na Skontrolujte, či je aktívna transakcia v databáze v určitom čase. Ďalšie informácie o tejto konkrétnej situácii, po kliknutí na nasledovné číslo článku publikovaného v databáze Microsoft Knowledge Base:
295108 Neukončenie transakcie môžu mať veľký počet zámkov a prípad blokovanie
171224 Pochopiť, ako funguje príkaz Transact-SQL zabiť
Okrem toho nájdete v téme "DBCC OPENTRAN" v zdroji SQL Server Books Online.

Scenáre, ktoré môžu viesť k nezapojené transakcií:
  • Aplikácia dizajn, ktorý predpokladá, že všetky chyby causerollbacks.
  • Aplikácia dizajn, ktorý úplne nezohľadňuje SQL Server správanie keď vykonáva vrátenie pomenované transakcie alebo špeciálne-vnorené pomenované transakcie. Ak sa pokúsite vrátiť na transakcie s názvom vnútorné, dostanete nasledovné chybové hlásenie:
    Server: Msg 6401, úroveň 16, štát 1, linka 13 nemožno vrátiť späť InnerTran. Zistilo, Notransaction alebo uloženia tohto mena.
    SQL Servergenerates chybové hlásenie, že naďalej po nasledujúceho výkazu. Je to One. Ďalšie informácie nájdete v téme "Vnorené transakcie" alebo "Vnútri SQLServer" tému v zdroji SQL Server Books Online.

    Pri navrhovaní aplikácie, odporúčame nasledovné:
    • pero iba jedna transakcia jednotky (zvážiť možnosť, že iný proces môže volať vy).
    • Skontrolujte @@TRANCOUNT pred vydaním zaviazať, ROLLBACK, návrat, alebo podobný príkaz alebo vyhlásenie.
    • Zapíšte svoj kód, za predpokladu, že ďalší @@TRANCOUNT mohli "hniezdo" vy a plán pre vonkajšie @@TRANCOUNT na vrátená späť, keď sa vyskytne chyba.
    • Najpravdepodobnejšou recenziu a pridávanie značiek možnosti pre transakcie. (Toto neuvoľňujú zámky!)
    • Vykonať úplné testovanie.
  • Aplikácia, ktorá umožňuje interakciu používateľa vnútri transakcie. To spôsobí, že transakcia zostať otvorené po dlhú dobu, a to spôsobuje zablokovanie a transakcie prihlásiť rast pretože otvorené transakcia nemôže byť skrátené a nové transakcie sú pridané do denníka po otvorené transakcie.
  • Aplikácia, ktorá nekontroluje @@TRANCOUNT na verifythat nie sú žiadne otvorené transakcie.
  • Siete alebo iné chyby, ktoré blízko klient applicationconnection na server SQL Server bez toho, aby ho o tom informoval.
  • Združovanie pripojení. Po vytvorení pracovné podprocesy SQL Server opätovné im ak oni nie sú servis pripojenie. Ak pripojenie používateľa spustí transakciu a odpojí pred spáchaním alebo vrátenie transakcie a pripojenie potom, že opätovné použitie rovnakej vlákno, predchádzajúce transakcie stále zostáva otvorená. Táto situácia vedie zámky, ktoré zostávajú otvorené od predchádzajúcej transakcie a zabraňuje skrátenia spáchaný transakcií do denníka. To vedie k veľkej log súbor veľkostí. Ďalšie informácie o združovanie pripojení, kliknite na nasledovné číslo článku publikovaného v databáze Microsoft Knowledge Base:
    164221 Ako povoliť združovanie pripojení v aplikácii ODBC


Veľmi veľké transakcie
Denník záznamov súborov denníka transakcií sa skrátia na báze jednotlivých transakcií. Ak transakcia rozsah je veľký, že transakcie a transakcie začal po to neodstraňujú z denník transakcií, pokiaľ je dokončená. To môže viesť k veľkej log súbory. Ak transakcia je dostatočne veľký, súbor denníka možno využiť voľné miesto na disku a spôsobiť typu "transakcia denníka úplný" chybové hlásenie, napríklad chyba 9002. Ďalšie informácie o tom, čo robiť, keď obdržíte tento druh chybového hlásenia, nájdete v časti "Ďalšie informácie" tohto článku. Navyše, to trvá veľa času a SQL Server réžii vrátiť veľkých transakcií.

Operácie: DBCC DBREINDEX a vytvorenie indexu
Z dôvodu zmien v modeli obnovy v SQL Server 2000, keď použijete režim úplné uzdravenie a spustíte DBCC DBREINDEX, denník transakcií môžu rozšíriť podstatne viac porovnaní s SQL Server 7.0 v rovnocenných recovery mode SELECT INTO alebo voľne KÓPIU a s "Trunc. Odhlásiť na chkpt.".

Hoci veľkosť denník transakcií po DBREINDEX prevádzky môže byť problém, tento prístup poskytuje lepší výkon denníka obnovenia.

Pri obnovení zo zálohy denníka transakcií
To je popísané v nasledujúcom článku databázy Microsoft Knowledge Base:
232196 Priestor denníka používa zdá rast po obnovení zo zálohy

Ak nastavíte SQL Server 2000 používať Bulk-Logged režim a vydať hromadne KÓPIU alebo SELECT INTO vyhlásenie, každý zmenených rozsahu je označené a potom zálohované pri zálohovaní denník transakcií. Hoci to umožňuje späť hore denníky transakcií a zotaviť sa z porúch aj po vykonať hromadné operácie, to pridáva k veľkosti denníky transakcií. SQL Server 7.0 neobsahuje túto funkciu. SQL Server 7.0 iba záznamy, ktoré rozsahov sa zmenil, ale nie je zaznamenať skutočný rozsahov. Preto protokolovanie používa podstatne viac priestoru v SQL Server 2000 ako v SQL Server 7.0 režime hromadného-Log, ale nie toľko ako to robí v úplnom režime.

Klientske aplikácie nemôže spracovať všetky výsledky
Ak vydáte dotaz na server SQL Server a nemáte zaobchádzať výsledky okamžite, môžete byť držiteľom zámky a znížiť súbežnosti na serveri.

Predpokladajme napríklad, že vydáte dotaz, ktorý vyžaduje riadky z dvoch strán na vyplnenie vášho množiny. SQL Server analyzuje skompiluje a spustí dotaz. To znamená, že zdieľané zámky sú pridaná na dve stránky, ktoré obsahujú riadky, ktoré musíte mať na uspokojenie vašej dotaz. Navyše, Predpokladám, že nie všetky riadky vošli jeden SQL Server TDS paket (metóda, ktorú server komunikuje s klientom). TDS pakety sú vyplnená a odoslaná klientovi. Ak všetky riadky z prvej stránky vhodné na TDS paket, SQL Server správy zdieľaných zámok na tejto stránke ale ponecháva zdieľané zámok na druhej strane. SQL Server potom čaká na klient požadovať ďalšie údaje (môžete to urobiť pomocou DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults alebo FetchLast/FetchFirst napríklad).

To znamená, že zdieľané zámky sa koná až klient požiada o zvyšok údajov. Ďalšie procesy, ktoré údaje požiadať druhú stranu môže byť blokovaný.

Dotazy time out pred denníka transakcií ukončí expanzia a dostanete falošné "Log plný" chybové hlásenia
V tejto situácii, aj keď nie je dostatok miesta na disku, stále "z miesta" chybové hlásenie.

Táto situácia sa líšia pre SQL Server 7.0 a SQL Server 2000.

Dotaz môže spôsobiť denník transakcií sa automaticky rozbaliť ak denník transakcií je takmer plná. To môže trvať dlhšie, a dotaz môže byť zastavená alebo prekročiť jeho časový kvôli tomu. SQL Server 7.0 vráti chybu 9002 v tejto situácii. Táto otázka sa nevzťahuje na SQL Server 2000.

V SQL Server 2000, ak máte auto-zmenšiť možnosť zapnutá pre databázu, tam je veľmi malý čas počas ktorého denníka transakcií sa pokúsi automaticky rozbaliť. Však nemožno rozšíriť, pretože funkcia auto-zmenšiť beží v rovnakom čase. To môže tiež spôsobiť falošne inštancie chyby 9002.

Typicky, automatické rozšírenie súbory denníka transakcií dochádza rýchlo. V nasledovných situáciách však môže trvať dlhšie ako zvyčajne:
  • Rast prírastky sú príliš malé.
  • Tento server je pomaly z rôznych dôvodov.
  • Disky nie sú dost rýchle.


Unreplicated transakcie
Veľkosť denníka transakcií databázy programu publisher môžete rozšíriť Ak používate replikácie. Transakcie, ktoré ovplyvňujú objekty, ktoré sa replikujú sú označené ako "Pre replikáciu." Tieto transakcie, ako napríklad nezapojené transakcií, neodstránia po kontrolný bod alebo po vás späť hore denník transakcií do denníka-reader úlohy skopíruje transakcií do databázy distribúcie a odstráni ich. Ak problém s denníka-reader úlohy bráni čítanie týchto transakcií v databáze programu publisher , veľkosť denníka transakcií môžu naďalej rozširovať počet non-replikované transakcií zvyšuje. DBCC OPENTRAN Transact-SQL odkaz môžete použiť na identifikáciu najstarších non-replikované transakcií.

Ďalšie informácie o riešení problémov s unreplicated transakcií, pozri "sp_replcounters" a "sp_repldone" témy v zdroji SQL Server Books Online.

Ďalšie informácie nájdete po kliknutí na nasledovné číslo článku publikovaného v databáze Microsoft Knowledge Base:
306769 FIX: Denník transakcií z publikovanej databázy snímka nemôže byť skrátené
240039 OPRAVIŤ: DBCC OPENTRAN nie je správa replikácia informácií
198514 FIX: Obnovenia na nový server spôsobí zostať v denník transakcií


AlwaysOn "AVAILABILITY_REPLICA" použitie záznamy denníka transakcií na sekundárne databázy

V SQL Server 2012 s podporou skupiny dostupnosti AlwaysOn, môže sa zobraziť nasledujúca správa v denníku chyba SQL:

Chyba: 9002, závažnosť: 17, štát: 9.
Denník transakcií databázy "%. * ls' je celý z"AVAILABILITY_REPLICA"

AVAILABILITY_REPLICA log_reuse_wait označuje skupiny dostupnosti AlwaysOn sekundárne replika aplikuje záznamy denníka transakcií databázy na príslušné sekundárne databázy.

Existujú dva scenáre, ktoré môžu viesť k rastu prihlásiť databázy dostupnosť a AVAILABILITY_REPLICA "log_reuse_wait:

Scenár č.1: Čakacia doba prináša prihlásený zmeny sekundárne

Keď je transakcia vykonáva primárnym, prihlásený bloky musia byť dodané a kalenej log súboru databázy v strednej. Akékoľvek oneskorenie spôsobí skracovania denníka zmeny v databáze primárne replika.

Scenár 2: Znova latencie

Po vytvrdnutí do súboru denníka sekundárne databázy vlákno venovanej znova platí záznamov denníka.

Ak nie je schopný držať krok s denník transakcií generované opakovať operáciu, môže potenciálne viesť k log rast. Primárnym bude schopný skrátiť denník transakcií, ak je sekundárne repliku znova za pri uplatňovaní týchto zmien na príslušné sekundárne databázy. Ak existuje viac ako jednu sekundárne, určiť, ktoré sekundárne databázy je oddialenie denníka skracovania, porovnať stĺpci truncation_lsn zobrazení dynamická správa sys.dm_hadr_database_replica_states cez viacero Pobočníci.

Môžete použiť AlwaysOn tabule a sys.dm_hadr_database_replica_states zobrazení dynamická správa pomôcť monitorovať denník poslať frontu a prerobiť frontu. Niektoré kľúčové polia sú:

PolePopis
log_send_queue_sizeMnožstvo záznamy denníka nie dorazili sekundárne replika
log_send_rateKurz ktorý log záznamy sú zaslané na sekundárne databázy
redo_queue_sizeMnožstvo denníka záznamov v súbore denníka sekundárne replika nie ešte bol prepracovaný, v kilobajtoch (KB)
redo_rateRýchlosť akou záznamy denníka sú je prerobená na danom sekundárne databázy, v kilobajtoch (KB) / druhá
last_redone_lsnSkutočné denníka poradové číslo posledného záznamu denníka ktorá bola prerobená na sekundárne databázy. last_redone_lsn je vždy menšia ako last_hardened_lsn
last_received_lsnPrihlásenie bloku identifikácia bodom ku ktorému boli prijaté všetky bloky denníka sekundárne replika, ktorý hosťuje tento sekundárne databázy. Odráža blok denníka ID polstrovaný nulami. To nie je skutočné denníka poradové číslo.

Poznámka Ďalšie informácie o sys.dm_hadr_database_replica_states názor, pozrite si nasledujúce webovú lokalitu TechNet:

http://technet.Microsoft.com/en-us/library/ff877972.aspx



Rozšírené informácie
Denník transakcií pre ľubovoľnú databázu spravuje ako množinu súborov virtuálnej denníka (VLFs). SQL Server určuje VLF súbor veľkosti interne na základe celkovej veľkosti súboru denníka a rastu prírastok, ktorý sa používa pri rozšírení log. Denník vždy rozširuje v jednotkách celý VLFs a komprimovať môžete iba VLF hranicu. VLF môže existovať v niektorom z troch štátov: aktívny a NEOPRAVITEĽNÁ OPAKOVANE.
  • Aktívny: Aktívna časť z denníka začína minimálne log poradové číslo (LSN) predstavujúci aktívne (nepotvrdené) transakcie. Aktívna časť z denníka končí posledný-písomné LSN. Akékoľvek VLFs, ktoré obsahujú akúkoľvek časť aktívneho denníka sú považované za aktívny VLFs. (nevyužitý priestor v denníku fyzickej nie je súčasťou akejkoľvek VLF.)
  • NEOPRAVITEĽNÁ: časť denníka, ktorý prichádza pred najstaršie aktívne transakcia je len potrebné zachovať postupnosť denníka zálohovanie pre obnovenie.
  • OPAKOVANE: Ak nie si zachovávajú transakciu denníka zálohy, alebo ak youalready zálohované log, SQL Server opätovné VLFs pred najstaršie activetransaction.
Keď SQL Server dosiahne koniec fyzického súboru denníka, začne opätovné použitie priestor v súbore fyzickej vydaním KRÚŽI späť fungovanie na začiatku súborov. V skutočnosti, recykluje SQL Server priestor v súbore denníka, ktoré už nie je potrebné pre obnovenie alebo zálohovanie účely. Ak denník zálohovania postupnosť je zachovaná, časť denníka pred minimálne LSN nemôže byť prepísané kým zálohovať alebo skrátiť tieto záznamy denníka. Po zálohovanie denníka, server SQL Server môže kruh späť na začiatok súboru. Po servera SQL Server kruhy späť na začať písať denník záznamov skôr v súbore denníka, opakovane súčasťou denníka je potom medzi koniec logického záznamu a aktívna časť z denníka.

Ďalšie informácie nájdete v téme "Transakcia denníka fyzickej architektúry" tému v zdroji SQL Server Books Online. Okrem toho môžete vidieť diagramu a diskusia o to na strane 190 "vnútri SQL Server 7.0" (Soukup, Ron. Vnútri Microsoft SQL Server 7.0, Microsoft Press, 1999), a tiež na stránkach 182 až 186 "vnútri SQL Server 2000" (Delaney, kalenie. Vnútri Microsoft SQL Server 2000, Microsoft Press, 2000). Databázy SQL Server 2000 a SQL Server 7.0 majú možnosti autogrow a autoshrink. Tieto možnosti môžete použiť na pomoc môžete komprimovať alebo vaše prihlásenie rozširovacej transakcie.

Ďalšie informácie o tom, ako tieto voľby môžu ovplyvniť server, po kliknutí na nasledovné číslo článku publikovaného v databáze Microsoft Knowledge Base:
315512 Úvahy o Autogrow a Autoshrink konfigurácie v SQL Server
Skracovanie na veľkosť súboru denníka transakcií sa líši od kompresie súboru denníka transakcií. Ak server SQL Server skráti súbor denníka transakcií, to znamená, že obsah tohto súboru (napríklad dopustil transakcií) sa vypúšťajú. Avšak, keď si prezeráte veľkosť súboru z hľadiska miesta na disku (napríklad v programe Windows Prieskumník alebo pomocou príkazu dir ), veľkosť zostáva nezmenený. Však priestor vo vnútri .ldf súbor môže teraz byť opätovne nových obchodov. Len keď SQL Server sa zmenšuje veľkosť súboru denníka transakcií si skutočne vidieť zmenu fyzickú veľkosť súboru denníka.

Ďalšie informácie o tom, ako zmenšiť denníky transakcií, kliknite na nasledovné číslo článku publikovaného v databáze Microsoft Knowledge Base:
256650 Ako zmenšiť SQL Server 7.0 denníka transakcií
272318 Zmenšuje protokol transakcií v SQL Server 2000 s DBCC SHRINKFILE
Ďalšie informácie o používaní SQL Server 6.5 transakcia denníka, kliknite na nasledovné číslo článku publikovaného v databáze Microsoft Knowledge Base:
110139 Príčiny transakcia denníka SQL zapĺňajú

Ako nájsť dotazy, ktoré konzumujú veľké množstvo priestor denníka SQL Server 2005 a novšie verzie

V SQL Server 2005 a novšie verzie, môžete použiť zobrazenie dynamická správa sys.dm_tran_database_transactions (DMV) vyhľadajte dotazy, ktoré konzumujú veľké množstvo priestor denníka. Nasledujúce stĺpce v sys.dm_tran_database_transactions DMV môže byť užitoč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
Môžete dotaz stĺpci sql_handle z sys.dm_exec_requests DMV získať text samotný výkaz, ktorý spotrebuje veľké množstvo priestor denníka. Môžete to urobiť spojením sys.dm_tran_database_transactions DMV a sys.dm_tran_session_transactions DMV v stĺpci transaction_id, a potom pridať ďalšie spojenie s sys.dm_exec_requests na session_id kolóne.

Ďalšie informácie o sys.dm_tran_database_transactions DMV, prejdite na SYS.dm_tran_database_transactions (Transact-SQL) webová lokalita Microsoft Developer Network (MSDN) webovej stránky.

Ďalšie informácie o sys.dm_tran_session_transactions DMV, prejdite na SYS.dm_tran_session_transactions (Transact-SQL) Webovej lokalite MSDN.

Ďalšie informácie o sys.dm_exec_requests DMV, prejdite na SYS.dm_exec_requests (Transact-SQL) Webovej lokalite MSDN.

Upozornenie: Tento článok bol preložený automaticky

Vlastnosti

ID článku: 317375 – Posledná kontrola: 01/15/2014 01:01:00 – Revízia: 5.0

  • Microsoft SQL Server 2012 Standard
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Express
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Express
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Workgroup
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • kbsqlsetup kbinfo kbmt KB317375 KbMtsk
Pripomienky
ex="0" id="language-">