Sql Server Maintenance Plan - Best Practices on Tasks and Scheduling

Josh,

This is a very common task for all DBAs and the right answer is NOT the same for every one and for each server. As lot of other things, it depends on what you need.

Most definitely you don't want to run "Shrink Database" as already suggested. Its EVIL to performance and the below ref will show you why. It causes disk and as well as index fragmentation and this can lead to performance issues. You are better off by pre-allocationg a big size for the data and log files so that autogrowth will NOT kick-in.

I didn't understand your #2. selected tables full backup. Can you elaborate more on this?

Coming to Index reorganize, update statistics and index rebuilds, you need to be careful on how you do this otherwise you will end up using more resources and also end up with performance issues.

When you rebuild indexes the statistics of the indexes are updated with fullscan but if you do update statistics after that, then those will be updated again with a default sample (which depends on several factors, usually 5% of the table when table size > 8 MB) which may lead to performance issues. Depending on the edition you have, you may be able to do online index rebuilds. The right way of doing this activity is check the amount of fragmentation and depending on that either do index rebuild or index reorganize + update statistics. And also you may want to identify which tables need to update stats more frequently and try to update stats more often.

Maintenance Plans are OK but its hard to get the best out of them doing these customizations unless you can login to SSIS and tweak the MP's. that's why I prefer NOT to use them and use Ola Hallengren's free scripts that are more robust than MP's. Also, I would recommend to catch up on the referenced article by Paul Randal on this topic.

Ref: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

This is NOT a comprehensive answer to your question but a good starting point. HTH and let us know if you have any additional questions/comments.

I'll share my experience, even if you already accepted an answer. Maybe it will be helpful :-).

1. Full daily backup (daily) - great, but don't forget to check for space and remove old files after some predefined time.
2. Backup selected tables (hourly) - don't understand why you'd need this, you'd better go with differential backups. How do you backup only certain tables: SSIS, scripts, bcp? Regarding diff backups, don't schedule it too often, as you'll steal the log backups role.
3. Transaction log backups (every 15 minutes) - great, are you sure you need for all databases? Do all databases use full recovery model or not?
4. Check db integrity - yes, but you need to make sure that you don't kill you environment. The DBCC check statements are pretty selfish on resources and scan complete dbs, so they need to be scheduled during off hours.
5. Reorganize index (daily) - don't force it, do it only if needed. Check the index DMV's regarding fragmentation and reorganize only based on needs. I'd move all index and statistics operations on a single weekly task.
6. Update statistics (daily) - Please see my answer to a previous question. Instead of just forcing update of all statistics, every day, you'd better check when statistics were lastly updated and only in some cases update them.
7. Shrink database (weekly) - Oh, no. Please read Paul Randal's article regarding file shrinking.
8. Rebuild index (weekly) - see 5.

9. Maintenance cleanup (daily) - ok with that.

10. You'd better also add a task to verify your backups - there's a version of RESTORE command (verifyOnly.. if I recall correctly) - let's say weekly, though I prefer it daily.

You mention you want to be shielded in case of data loss, so I'd say you need to add the system databases in this maintenance procedure. And also take care to backup the files on a different machine than the server itself. Keep somewhere a file with what to do in case you need to rebuild master db, msdb..etc. Good luck with your task!

Late answer but could be of use to other readers.

Please, have in mind that there are lots of maintenance or reporting tasks, you can create, that carry unseen risks associated with them.

What would happen when a drive gets filled up during differential backups performed daily? And what if an index rebuild job runs unusually long? How about if a data load process causes extensive resource contention, bringing normal operations to their knees? All of these are planned events, yet can cause considerable disruption to the very processes we are trying to safeguard.

Always consider how different jobs interact and time them such that there is no overlap in sensitive or resource intensive tasks.

I suggest reading this article first: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

It describes how to perform important maintenance tasks in SQL Server – risk free. For example – you can build simple checks into your maintenance jobs that verify available resources as well as what an operation will require prior to execution. This allows you to ensure that your environment can handle what you are about to do, and abort with a meaningful error if resources are inadequate.