[MSSQL2k] maximale. log file wordt steeds kleiner

[foske]

een goedennacht,

(Hoewel het een beheer vraag is, zitten bij P&W de meeste SQL experts denk ik, dus vandaar dat ik hem hier post)

Het probleem is als volgt:
Ik heb een SQL database die nu ong. 350mb is. (met 50 mb vrij). Het database bestand staat op 350mb en het log bestand op 2mb. Beide zijn ingesteld op unlimited growth en growth by 10%.

's nachts worden er een aantal jobs gedraaid die de gegevens van de afgelopen dag berekenen en in de daarvoor bestemde tabellen zet. Daarnaast worden ook de indexes van de veel gebruikte tabellen opnieuw geindexeerd.

Als dat allemaal is gedaan voor ik deze code als laatste uit:

BACKUP LOG DBNAAM WITH TRUNCATE_ONLY
go
DBCC SHRINKFILE(DBNAAM_log,2)
go
dbcc shrinkdatabase (DBNAAM, 200)

Dit werkte ruim 8 maanden goed tot gisteren. Toen kreeg ik de error dat mijn logfile vol zat, terwijl deze maar 100mb op dat moment was.

Na het verwijderen van wat oude gegevens uit de tabellen en het weer draaien van het bovenste script, kon ik alle bewerkingen weer uitvoeren.

Maar vandaag is het nog erger, nu zegt hij al bij een grootte van 10mb dat het de log files vol zitten, en kan ik niet eens wat oude gegevens verwijderen (tenzij ik het in het hele kleine groepen doe, en iedere keer het log trunc. maar dat is niet de bedoeling...)

Maar hoe kan een logfile nou vol zitten, als hij maar 2mb is, en in het verleden ruim 1gb geweest is geweest... Ik word een beetje moedeloos...

Weet er iemand wat ik hier over het hoofd zie? bedankt!

[Gé Brander]

Heb je wel genoeg schijfruimte vrij op de schijf van je LOG file? Dat kan ook wel eens niet zo heel duidelijke foutmeldingen geven.

En waarom doe je het shrink commando? SQL Server is sneller als je een goede inschatting maakt hoe groot de files moeten zijn. Je kan dus beter de data en log files dusdanig groot maken dat ze zelden of nooit vergroot hoeven te worden. Dit voorkomt fragmentatie op je filesysteem.
Denk maar na. Elke keer dat je bestanden moet uitbreiden, moet er op je schijf ruimte gezocht worden voor die uitbreiding.

[ Voor 61% gewijzigd door Gé Brander op 25-08-2004 06:28 ]

[foske]

Jup ik was mij hiervan bewust, maar omdat we op een shared webhosting omgeving zitten (nog voor maar een paar weken helaas) en de kosten per per mb relatief hoog zijn, hadden we hiervoor gekozen... daarnaast heeft onze webhoster gezegd dat er voldoende schijfruimte is... Zo meteen nog maar weer bellen

[Verwijderd]

"growth by 10%" zou weleens een probleem kunnen zijn. Vaak is het volgens mij verstandig om een growth van een vaste waarde nemen. Het was voor mij ook weleens de oplossing geweest. Er werd toen gewoon veelste veel ruimte vrijgehouden voor de db zelf zodat de logfile in de problemen kwam.

Waarom laat je 200% ruimte over na het shrinken van de db? Lijkt mij ook wat vaag...

/me Sooterd had beter de post moeten lezen van c70070540 voordat hij ging blaten

[ Voor 13% gewijzigd door Verwijderd op 25-08-2004 08:15 ]

[foske]

Nou pfff gelukkig....Net weer gebeld, na flink zeuren dat het eigenlijk niet anders kan zijn de de HD, zijn ze eens gaan kijken (kreeg eerst iemand van de helpdesk die zij dat als het vol kwam alles ging rinkelen enzo, dus niet ..) en er bleek een andere klant te zijn die 22gig aan log files had... En die drukte ons langzaam weg...

Iig bedankt voor het meedenken, weet ik iig dat mijn kennis van SQL toch nog een beetje up to date is Ben blij dat de dedicated server is besteld

[ Voor 6% gewijzigd door foske op 25-08-2004 08:46 ]