I used dbcc shrinkfile to shrink transaction log, but it worked for only one day. When I checked the properties, transaction log was back to the size I started with. TL was 1586 MB and I set the target size to 1 MB. Any idea why it happened?...i believe the scope of the size specification is limited just to the run you executed, and as transactions build up it will grow, you may see that it is not using all of the space allocated (thru taskpad view) but what that means is that it had grown to the current size thru autogrow, to meet the needs of the log...
...two things to check, see how the tran log growth is specified (look at the databases attribute), and also look at how often the log is backed up. It could be that a batch job executes a large number of transactions causing it to grow to its current size and then releasing it once a backup has occured.
...this note assumes that the database is in "FULL" recovery mode and that tran log backups are occuring...
...given the previous statement it could be that if growth is a result of a large batch run that the log size is optimal and continued shrinking would only add overhead as it would have to repeatedly "autogrow"...
...hope this helps...sql
Thursday, March 29, 2012
dbcc shrinkfile
Labels:
back,
database,
dbcc,
log,
microsoft,
mysql,
oracle,
properties,
server,
shrink,
shrinkfile,
sql,
transaction
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment