SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Shrink large database


Shrink large database

Author
Message
terry.home
terry.home
SSC-Enthusiastic
SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)

Group: General Forum Members
Points: 136 Visits: 188
I have been asked to look a a sql 2000 database that has been neglected for some time.

It has an audit database linked to the system and no maintenance has been done on this database on over three years,

The database has grown to around 322Gb

I have started doing some maintenance on the table and deleted over 9million entries for just one months worth of auditing data for back in 2010 and I will need to continue doing this on a nightly basis until we only have around 6 month worth of audit data left.

Since I am deleting so much data, from the database, I thought it might be a good idea to shrink the database. I started shrinking the database and left it to run. The next day back at work it was still running and I had complaints from users using the system. I was reluctant to stop the shrink as I felt it woild stop soon. It continued to run and the next day before work started I decided to cancel the shrink.

Any suggestions on how to get this done more efficiently?
sqlsurfing
sqlsurfing
SSC Eights!
SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)

Group: General Forum Members
Points: 994 Visits: 1190
I'm curious has your database full backups taken longer to backup after removing/deleting all that data? We deleted Terabytes of data (though we have less data our backups take longer)

I'm considering moving all the data in current FileGroup and moving it to another FileGroup. if you have a big enough window that might be something that could be done?

--------------------------------------------------
...0.05 points per day since registration... slowly crawl up to 1 pt per day hopefully :-D
terry.home
terry.home
SSC-Enthusiastic
SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)

Group: General Forum Members
Points: 136 Visits: 188
Sorry I cannot really answer that.... as the server had been neglected, the backups appear to have failed for some time now.

Not sure it helps, but I noted as soon as I had cancelled the shrink that had been running a couple of days, the log file backup was much bigger.

I have been executing must of my commands to this server from a remote machine with SSMS 2008 installed. Today I decided to re-visit sql 2000 query analyser and fired that up on the server in question. I ran the shrink from there but instead of shrinking to 0% free I set it to 50% first.


The shrink ran suprisingly quick and freed up around 10gig. I ran another and this time set it to 40% and this ran quick also. I have now kicked off another delete to run over the weekend.

I feel confident that I will manage to get the space down significantly in this way.
sqlsurfing
sqlsurfing
SSC Eights!
SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)

Group: General Forum Members
Points: 994 Visits: 1190
terry.home (5/17/2013)
Sorry I cannot really answer that.... as the server had been neglected, the backups appear to have failed for some time now.

Might not be a bad idea to setup some backups, especially if it's important data. You could use the SQL Server maintenance plan feature as an option.


Not sure it helps, but I noted as soon as I had cancelled the shrink that had been running a couple of days, the log file backup was much bigger.


Thanks for the info. I've noticed that when running shrink there is some log growth, possible after log grew too when stopping? Good information, I don't use shrink often so that last part is interesting. Documentation on Shrink is not so good online. I wonder if Sybase docs would be better?... Mostly everything on internet just states "don't shrink" not really internals of how it works.


I have been executing must of my commands to this server from a remote machine with SSMS 2008 installed. Today I decided to re-visit sql 2000 query analyser and fired that up on the server in question. I ran the shrink from there but instead of shrinking to 0% free I set it to 50% first.


The shrink ran suprisingly quick and freed up around 10gig. I ran another and this time set it to 40% and this ran quick also. I have now kicked off another delete to run over the weekend.

I feel confident that I will manage to get the space down significantly in this way.


How did it go with shrinking 50% to 40%.. and lower? Did it get progressively slower to shrink as you got closer to the actual data size?

--------------------------------------------------
...0.05 points per day since registration... slowly crawl up to 1 pt per day hopefully :-D
Joie Andrew
Joie Andrew
SSCertifiable
SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)

Group: General Forum Members
Points: 6247 Visits: 2032
First thing's first, you need to get a good backup of that database. Next run a DBCC CHECKDB to ensure that after years of neglect that it is still consistent.

After that, if you can temporarily change the database to simple recovery then your deletes will go much faster, as they are not getting logged.

Joie Andrew
"Since 1982"
terry.home
terry.home
SSC-Enthusiastic
SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)

Group: General Forum Members
Points: 136 Visits: 188
Thank you for the responses.

The backups are no longer failing. They were failing due to lack of disk space and this has now been sorted, partly down to allocating more disk space, and partly down to shrinking the file. Also found a very old, huge backup file which I deleted..

Both the shrink to 50% and 40% ran quick and as I am deleting more data every night (10's of millions) the database is progressively getting smaller.

Since I am deleting one months worth of data at a time, I expect to take another couple of weeks to get to a point where I only have 6 months worth of data left and will continue to shrink to 50% as I continue.
pnauta
pnauta
SSC Rookie
SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)SSC Rookie (25 reputation)

Group: General Forum Members
Points: 25 Visits: 178
After doing a shrink, also rebuild your indexes, as they will probably be invalidated by the shrink.

I don't do a shrink often, but in this case it was a valid choice. Only, one should indeed start with a slight decrease, and in most cases you're looking at days of decreased performance. Also, in my inderstanding, a shrink can not be cancelled, but I may be wrong. The reason why it finished quickly the next time tound, is because all the data had been moved already, so it's simply a matter of decreasing file size.
sqlsurfing
sqlsurfing
SSC Eights!
SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)SSC Eights! (994 reputation)

Group: General Forum Members
Points: 994 Visits: 1190

The backups are no longer failing. They were failing due to lack of disk space and this has now been sorted, partly down to allocating more disk space, and partly down to shrinking the file. Also found a very old, huge backup file which I deleted..

Both the shrink to 50% and 40% ran quick and as I am deleting more data every night (10's of millions) the database is progressively getting smaller.

Since I am deleting one months worth of data at a time, I expect to take another couple of weeks to get to a point where I only have 6 months worth of data left and will continue to shrink to 50% as I continue.


This might be a moot point, since you're gone so far down this path "shrinking" and "deleting"....

I wonder if it's not too late to update add a thought. Have you considered.. copying the "6 months" of data needed into another table/filegroup instead of deleting 10's of millions in the database? I'm assuming last 6 month set is much smaller.

--------------------------------------------------
...0.05 points per day since registration... slowly crawl up to 1 pt per day hopefully :-D
terry.home
terry.home
SSC-Enthusiastic
SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)SSC-Enthusiastic (136 reputation)

Group: General Forum Members
Points: 136 Visits: 188
Not a bad suggestion. I have considired this, but not done it.
I dont know whether the last six months worth of data is any smaller in comparison to previous.
My original problem was a lack of disk space which caused performance issues. Therefore deleting and shrinking helped to free up some space and allowed the database to respond.

I could potentially now move the last 6 months to a new file, but once this is done, I assume I will still need to get the data older than 6 months deleted.

Am I wrong to think that I will therefore be adding another step into my process but still end up with the same result at the end of the process?


Regards
T
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)SSC Guru (209K reputation)

Group: General Forum Members
Points: 209671 Visits: 41973
sqlsurfing (5/26/2013)

The backups are no longer failing. They were failing due to lack of disk space and this has now been sorted, partly down to allocating more disk space, and partly down to shrinking the file. Also found a very old, huge backup file which I deleted..

Both the shrink to 50% and 40% ran quick and as I am deleting more data every night (10's of millions) the database is progressively getting smaller.

Since I am deleting one months worth of data at a time, I expect to take another couple of weeks to get to a point where I only have 6 months worth of data left and will continue to shrink to 50% as I continue.


This might be a moot point, since you're gone so far down this path "shrinking" and "deleting"....

I wonder if it's not too late to update add a thought. Have you considered.. copying the "6 months" of data needed into another table/filegroup instead of deleting 10's of millions in the database? I'm assuming last 6 month set is much smaller.



+1 to that. It might also be a good time to consider partitioning the table to make future once-per-moth deletes easier.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search