[mssql] size ldf-logfile wordt niet kleiner bij backuppen?

Pagina: 1
Acties:
  • 197 views sinds 30-01-2008
  • Reageer

  • haroldd
  • Registratie: April 2004
  • Laatst online: 22-03 21:11
ik heb verscheidene databases waarbij de ldf file even groot of zelfs groter is dan de mdf file, dus dat is niet zo goed. Ik ben niet zo'n sql server wizard maar heb eens wat zitten nalezen hoe ik die log file kleiner kan krijgen. Nou dacht ik te hebben begrepen dat als ik de database backup de logfile zou shrinken. Nou heb ik de database geback-upt door in de enterprise manager via "alle taken" en dan "backup database" te klikken maar die ldf file is nog steeds zo groot.

als ik nu via "alle taken" op "shrink database" klik zie ik wel dat er opeens 88% free space is terwijl dit voor het backuppen iets van 10% was. Kan ik de database dan nu veilig shrinken? en is dit uberhaupt een correcte manier (zonder risico) voor wat ik wil bereiken?

het betreft trouwens sql server 2000

Werken is gezond, laat het daarom over aan de zieken!


  • bigbeng
  • Registratie: Augustus 2000
  • Laatst online: 26-11-2021
En wat heeft dit met programmeren te maken?
Lijkt me meer een topic voor SA o.i.d

En als antwoord op je vraag: Waarom zou de logfile verkleinen als je backupt? Ik kan me er iets bij voorstellen dat je logfile wordt gereset als je een backup terugzet. Het lijkt me ook raar als een backup maken iets met de current state van je database zou doen. Maar goed, het zou een 'feature' van MSSQL kunnen zijn.

[ Voor 23% gewijzigd door bigbeng op 27-10-2005 11:19 ]


  • P_de_B
  • Registratie: Juli 2003
  • Niet online
Als je het LOG backupped word alleen de 'logische' bestandsgrootte aangepast. De reeds naar de database weggeschreven queries worden verwijdert uit het logische .ldf bestand. Het is echter wel zo dat SQL Server de reservering op filesystem niveau blijft houden waardoor het fysieke bestand nog steeds even groot blijft. Door het log te shrinken (via EM of via een DBCC commando) wordt ook het fysieke bestand aangepast. In principe moet je dit gewoon kunnen doen.

Dat het log zo groot geworden is geeft wel aan dat het niet regelmatig gebackupped wordt. Ik zou echt willen aanraden iemand met wat kennis van zaken even naar de server te laten kijken om een backup en maintenance plan in te stellen.

Oops! Google Chrome could not find www.rijks%20museum.nl


  • haroldd
  • Registratie: April 2004
  • Laatst online: 22-03 21:11
P_de_B schreef op donderdag 27 oktober 2005 @ 11:20:
Als je het LOG backupped word alleen de 'logische' bestandsgrootte aangepast. De reeds naar de database weggeschreven queries worden verwijdert uit het logische .ldf bestand. Het is echter wel zo dat SQL Server de reservering op filesystem niveau blijft houden waardoor het fysieke bestand nog steeds even groot blijft. Door het log te shrinken (via EM of via een DBCC commando) wordt ook het fysieke bestand aangepast. In principe moet je dit gewoon kunnen doen.

Dat het log zo groot geworden is geeft wel aan dat het niet regelmatig gebackupped wordt. Ik zou echt willen aanraden iemand met wat kennis van zaken even naar de server te laten kijken om een backup en maintenance plan in te stellen.
ok bedankt, ik zal de serverhost er eens na laten kijken (zij doen ook stuk os-beheer). Bij de properties van de database staat wel dat de db deel uit maakt van een maintenance plan. nu maar hopen dat ze daar weten wat ze doen he :+

Werken is gezond, laat het daarom over aan de zieken!


  • haroldd
  • Registratie: April 2004
  • Laatst online: 22-03 21:11
nog ff een daaraan gerelateerd vraagje. Kan die grote logfile met 88% lege ruimte voor vertragingen zorgen? want site is laatste paar dagen nogal traag, vandaar dat ik ben begonnen met zoeken naar oorzaken hiervan.

Werken is gezond, laat het daarom over aan de zieken!


  • P_de_B
  • Registratie: Juli 2003
  • Niet online
haroldd schreef op donderdag 27 oktober 2005 @ 11:27:
nog ff een daaraan gerelateerd vraagje. Kan die grote logfile met 88% lege ruimte voor vertragingen zorgen? want site is laatste paar dagen nogal traag, vandaar dat ik ben begonnen met zoeken naar oorzaken hiervan.
Dat zou best eens kunnen ja.

Om verder te zoeken kun je ook de Profiler gebruiken, mits je tenminste rechtstreeks toegang hebt tot de server. Als je de clienttools van SQL Server niet hebt kun je een SQL Server trial versie downloaden, de clienttools kun je dan mooi gebruiken, deze blijven ook na de 180 dagen werken.

Oops! Google Chrome could not find www.rijks%20museum.nl


  • NMe
  • Registratie: Februari 2004
  • Laatst online: 19-08 12:58

NMe

Quia Ego Sic Dico.

Dit heeft niet echt wat met programmeren te maken. :)

PW>>SA

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

Pagina: 1