October 30, 2008 at 7:19 am
I have a 15 gig database. The end users finally decided they don't need the run time statistics in it. So they have been deleted and the application stopped adding the statistics. Now the database is using 100 meg of the data file. I have that shrinkfile script that only does x amount of shrinkage at a time. Because this thing is soo huge, I was wondering if shrinking can cause fragementation at the disk level for the data file if I run 100 meg at a time (the tran log grewto 12 gigs so I run a tran log backup to clear it up)?
October 30, 2008 at 7:39 am
Is the file fragmented now on disk? If so, this might help clean some of that up.
you can shrink to some xx level, you'd have to calculate that out. Remember this, as you shrink, internal structures get moved to new places inside the file. While that helps externally on the disk, it can whack all your indexes and get them very fragmented so that you reduce performance.
Disk is cheap. Is it hurting you to have a large file on disk? If not, I'd shelve concerns and leave it alone.
October 30, 2008 at 7:51 am
Steve Jones - Editor (10/30/2008)
Is the file fragmented now on disk? If so, this might help clean some of that up.you can shrink to some xx level, you'd have to calculate that out. Remember this, as you shrink, internal structures get moved to new places inside the file. While that helps externally on the disk, it can whack all your indexes and get them very fragmented so that you reduce performance.
Disk is cheap. Is it hurting you to have a large file on disk? If not, I'd shelve concerns and leave it alone.
Yes, I have enough disk space on that box. At end of full backup, it gets ftp'd and restored to a standby machine daily. Also, the tran logs are sent every hour or so.
ok, so probably not worth it as we are migrating to SQL 2005 in the coming months. I'll just try to ignore it and not let it bug me. :w00t: Thanks!
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply