January 27, 2011 at 2:26 pm
bcb (1/27/2011)
Well everybody, I'm pleased my comment about starting a db maintenance job with DBCC Checkdb inspired such discussion. Just to add some clarification... I have all of my sql agent jobs set to email me if a job fails. An interesting feature of SQL Server is that if a sql agent job has a checkdb step, and the step completes successfully but checkdb discovers corruption, SQL will still quit the job at that point with failure, and I get my email notification. 🙂 (Now, I assume that is still true... I'm not sure because the last time I had db corruption was ten years ago, I believe in SQL 7.0.) Anyhow, hope that clarifies.As an aside...I kinda chuckle when SQLServerCentral calls me grasshopper just because I hardly ever comment on articles. I've been a dba for 17 years.
BCB thanks for the clarification, that name gets given to you based on the number of posts you make, and number of QODs you get right, not on how long you have been 'doing the job'. Thanks for your contribution and the points you made, they are very informative.
Gethyn Elliswww.gethynellis.com
January 27, 2011 at 3:04 pm
Thanks, Gethyn. 🙂
February 17, 2014 at 8:10 am
My only comment, and concern is the clean up of the history on msdb. I would prefer to keep 8 weeks of data in the history, as that can give a good trending on how long the backups take and any other maintenance jobs for that matter. Also by keeping the 8 weeks, I can extract a report on database growth for right sizing of the system and trending.
February 17, 2014 at 1:29 pm
I would advise caution when putting your cleanup task before the backup task, I have seen this result in the tape backup running between the time of cleanup and database backup with the result of nothing being backed up to tape for offsite storage.
If you are lucky enough to have a fast server with SQL backup compression it always nice to have the SQL backup complete by the time the tape backup kicks off!
February 17, 2014 at 6:16 pm
I have to agree with the others. This would have been an absolute "must read" article, especially for newbies, if emails were sent out on the failure of any node and if it were also demonstrated as to just how easy it is to setup Point-In-Time logfile backups as well.
Still, this is a great introductory article the clearly demonstrates that it doesn't take a rocket scientist to create scheduled backups and that there's absolutely no execuse to not have full backups.
Thank you very much for taking the time to write this article.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 5 posts - 31 through 34 (of 34 total)
You must be logged in to reply to this topic. Login to reply