LDF File tegroot > Forum > PASS Nederland

Forum

Forums

Subject: LDF File tegroot

You are not authorized to post a reply.

Author

Messages

Danny Gobardhan User is Offline

Posts:8

15-04-2009 14:07:58	Alert
Hoe kan ik achterhalen wat de boosdoener is waarbij een ldf file te groot wordt. En wordt maar niet kleiner sterker nog hij groeit. Recovery model staat op simple, dus zou je verwachten dat deze alles opruimt na elke transactie. Ik heb met 'DBCC opentran' gekeken maar er blijkt geen open transacties te zitten. Ik heb een tijdje profiler gebruikt maar komt het niet op dat moment voor. Hij treedt onverwachts en niemand kan mij vertellen of er iets bijzonders is gebeurd. Vraag: 1. Hoe kan ik zien wat er in de weg zit van de ldf file. 2. Hoe kan ik achterhalen wat de boosdoener is geweest. (query etc.) Kan ik eventueel browsen in de ldf file? Er zijn wel wat 3de partij tools maar die moet je kopen. Ik heb ook DBCC LOG gebruikt maar wordt er niet wijzer van.

André Kamman User is Offline

PASS Nederland

Posts:137

17-04-2009 09:51:01	Alert
Hoi Danny, Een transactie log file zal niet vanzelf kleiner worden. Als hij ruimte nodig heeft en groeit dan blijft hij op die grootte hangen. Je kunt kijken hoeveel van de logfile daadwerkelijk in gebruik is op een bepaald moment met : DBCC SQLPERF(LOGSPACE) Met het recovery model op simple komt de beschikbare ruimte na een tijdje inderdaad beschikbaar. (niet direct na elke transactie) De logfile zelf zal echter niet kleiner worden. Het is niet makkelijk om in de logfile te kijken om te achterhalen wat de groei heeft veroorzaakt. Je zou wel bijvoorbeeld kunnen kijken naar de tijden waarop de autogrow de logfile vergroot heeft. (Bijvoorbeeld via Management Studio. Klik op de gewenste database, rechtermuis knop, Reports, Standard Reports, Disk Usage. Klik op het plusje voor Data/Log Files Autogrow/Autoshrink Events) (Hetzelfde rapport geeft overigens ook een mooi overzicht van de hoeveelheid logfile in gebruik etc.) Wellicht dat de tijden waarop de file begint te groeien je iets zeggen... (Een reindex kan bijvoorbeeld flink wat log nodig hebben als je 1 of meerdere grote tabellen in je database hebt) Groeten, André

Eduard Beijnes User is Offline

Posts:37

20-04-2009 14:15:55	Alert
Bij sommige van onze ldf bestanden wordt de grootte niet bepaald door applicatieactiviteiten maar door onderhoudstaken. Voorbeeld bij defraggen. Dit kun je vaststellen door voordat onderhoud gestart wordt de ldf file te krimpen en te kijken wat de grootte is na onderhoud. Overigens kunnen de groei resultaten iets verschilllen doordat de hoeveelheid "werk" voor sql server kan verschilllen. Na verloop van tijd stabiliseert zich dat. Als je reguliere maintenance de oorzaak is zou ik de ldf ook niet meer krimpen wegens diskfragmentatie.

An ape in an suit stays an ape.

Danny Gobardhan User is Offline

Posts:8

20-04-2009 15:46:53	Alert
Ik heb DBCC SQLPERF(LOGSPACE) gebruikt en je ziet wat ik al ook dacht dat er veel ruimte in beslag is genomen door de ldf file maar zelf weinig gebruikt. LogfileSize=12991 MB en Log Space Used 0.4 % (ongeveer 65 MB) .Met de rapportage Door te shrinken wordt deze wel kleiner maar dan kom je nog steeds niet achter wat de boosdoener is geweest en waarom geeft hij de ruimte niet vrij? Als je wacht dan blijft de ldf file groot. Hij is al dagen (bijna een week) boven de 12 GB. en MDF is maar 4 GB! Ik denk niet dat het verstandig is (MS raad het ook af) om een shrink job te draaien vanaf een bepaalde grote. Helaas kan ik het plusje voor Data/Log Files Autogrow/Autoshrink Events niet vinden in SQL Server 2005. NB. Er zijn ook performace problemen als de ldf file te groot wordt en blijft.

Danny Gobardhan User is Offline

Posts:8

21-04-2009 15:20:58	Alert
Dit is wat er hoogstwaarschijnlijk echt gebeurt in mijn situatie(source: http://msdn.microsoft.com/en-us/library/ms189573.aspx) : -Long-Running Transactions The active log must include every part of all uncommitted transactions. An application that starts a transaction and does not commit it or roll it back prevents the Database Engine from advancing the MinLSN. This can cause two types of problems: 1. If the system is shut down after the transaction has performed many uncommitted modifications, the recovery phase of the subsequent restart can take much longer than the time specified in the recovery interval option. 2. The log might grow very large, because the log cannot be truncated past the MinLSN. This occurs even if the database is using the simple recovery model, in which the transaction log is generally truncated on each automatic checkpoint. Nogmaals, het blijft lastig om te achterhalen wat/wie de boosdoener is geweest. Heren,in elk geval bedankt voor de hulp.

You are not authorized to post a reply.

Forums > Forums > DBA > LDF File tegroot