October 21, 2016 at 8:01 am
Hey all,
I actually just got promoted to our DBA position, which has been vacant for quite a while. There is very little documentation on our set up and what certain jobs, etc do. I have some SQL experience, but just on the query side. I've JUST started studying to get my MCSA (still preparing for exam 1).
While I've found plenty of resources in preparing to become a DBA, I've run into a problem: yesterday we changed all of the email recipients for SQL Agent job failures to me. I don't mind getting emails, the problem is I have 0 idea what to do with them. I've been told that a lot of those emails are probably noise, but I'm getting quite a few and I'm really not sure where to even begin looking to tackle the errors/failures. I've found the Log File Viewer and the Job Activity monitor, but A) some of the error descriptions are vague (and I have little general IT experience. I come from software support) and B) I can't see anything prior to 7 AM. Changing the filter date does nothing to change that.
Do you all have any suggestions or resources to look at that would help me figure these errors out, or even just help me start in the right direction?
Thanks!!!
October 21, 2016 at 8:07 am
First, be sure to understand backup and restore. Then make sure that's working fine.
Then, get this book (the pdf is free): http://www.sqlservercentral.com/articles/books/76296/
October 21, 2016 at 11:12 am
Another vote for that fine book.
I'm also going to pile on and say that you need to ensure your backups are in place. More than that, you need to ensure that the backups will meet the business Recovery Point Objectve and Recovery Time Objective. You can read more about those here[/url].
In terms of those emails, if you're getting emails that are not actionable, it's noise. I would absolutely eliminate them. You need as much signal and as little noise as possible. If your server contacts you, it's because you MUST do something. Otherwise, it should be quiet. Here's an article[/url] I wrote on that topic.
Also, as a DBA in general, here's the approach I advocate for now[/url].
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 21, 2016 at 11:37 am
Now that two people have stressed the importance of knowing your backups, let me emphasize the recovery. You should practice restoring from a backup to a non-production database. This makes sure your backups are viable so you can restore a database if you need to. It also gives you practice restoring a database. You don't want your first restore to be a real one with the boss breathing down your neck. Get familiar with it so you can execute when needed.
After that, work towards disabling the 'sa' SQL login. Once it's disabled, leave it disabled.
Let me also echo what Grant said about eliminating the noise email. The less useless things you have to look at, the sooner you'll see the important ones.
October 21, 2016 at 1:22 pm
let me emphasize the recovery. You should practice restoring from a backup to a non-production database. This makes sure your backups are viable so you can restore a database if you need to. It also gives you practice restoring a database. You don't want your first restore to be a real one with the boss breathing down your neck.
+1000
Amen! I have had the lovely experience of discovering a problem with the backup while a key person watching. It's a bummer.
-- Itzik Ben-Gan 2001
October 21, 2016 at 3:11 pm
scarr030 (10/21/2016)
Hey all,I actually just got promoted to our DBA position, which has been vacant for quite a while. There is very little documentation on our set up and what certain jobs, etc do. I have some SQL experience, but just on the query side.
...
As you say, the position has been open for quite some time, so there is no telling what issues like failed maintenance jobs or disk errors have gone unattended in the interim or even if the last DBA was giving them proper attention. It's time your organization pay the piper and spend some money to catch up. Given what you've stated above, I would recommend that your organization hire a local consultant with a strong SQL Server DBA background to come on-site for a couple of weeks so they can assess the situation, show you the ropes, and basically be a point of contact going forward in the event of an emergency. That would be the rational way to deal with this.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 21, 2016 at 3:34 pm
Wow! Thanks for the tips, everyone. I'll definitely be giving those a read tomorrow over some coffee. Got a lot of work to do!
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply