November 4, 2012 at 5:41 pm
What are the recommended Maintenance tasks to perform on a 2005 SQL production Database. I am thinking of the following:
1. Integrity Check - I am reading that this is resource intensive and can slow down SQL. Therefore it should be done offline.
2. Purge old data - I have a few tables that I can perform a "delete from ... " to delete data older than 6 month old as an example. What impact can this have on the database if it's done live? Is this necessarily going to reduce the size of the database? The database is set for "simple recovery".
3. Reorganize index
4. Update statistics
5. Shrink the DB. I was reading some articles that talked about the fact that this is a bad practice as it can increase fragmentation? So I guess I should not do it?
My objective is to reduce the size of the database without affecting performance. How do you do this?
Thanks
November 13, 2012 at 12:09 pm
First, backups! either with ssms maintenance plans or 3rd party product.
Second, start monitoring and reporting the db's performance, activity.
Third, then you'll know what the next step will be.
November 13, 2012 at 1:20 pm
Why do you feel you need to reduce the size of the database? Databases grow as you add data - and unless you have had an event that grew the database far beyond its normal size there is no reason to make it smaller.
Integrity Checks - should be run every day. If a database is corrupted and you don't know about it for several weeks/months you have no option to recover from a known good backup. You would end up losing data - and probably much more... There is no reason to try and run this 'offline' as it runs against a hidden snapshot of the database. Running in offline mode means the database will not be accessible to anyone while it runs.
Purge Data - this could lock the tables being purged. It can also cause performance issues during the process - depends on how it is written and what else is being run on the system at that time.
Rebuild/Reorganize indexes - use a procedure that identifies only those indexes that need to be rebuilt or reorganized. This will reduce the impact of this process on your system. If your system is Standard Edition - index rebuilds will be performed offline - meaning the index itself will not be available while it is being rebuilt.
ShrinkDB/ShrinkFile - as stated above, no reason to run this on a regular basis unless you want to cause additional performance issues and waste time. Both of these cause fragmentation in the indexes - which you just rebuilt/reorganized. And, if you do the shrink before the rebuild/reorganize - then the database is just going to grow back out.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply