September 17, 2013 at 12:10 am
Hi Guys,
I've recently been appointed to maintain my companies internal DB's. Must also stress the point that the DB's are quit critical, in the sense of CRM, Payroll etc.
I'm also very new to the administration environment of sql, however i've been working on it for the past 4 years now. But my experience was purely based on writing queries, scheduling backups, really basic stuff.
My purpose of this posting is, what can i do to be pro active in this new position? There is no handovers from previous dba's as all were actually outsourced. I'm the first internal dba appointed. I've got a chart of SQL Duties which is daily, weekly, monthly and yearly checks. I can also schedule the outsourced dba to be onsite, but i want to be prepared for that visit.
Any suggestions or advise? And i'm busy doing SQL 2012 courses and exams, but the process is "slowly but surely"
Would be nice for professional advise.
September 17, 2013 at 12:55 am
I'm no DBA myself, but this book has got some good comments:
Troubleshooting SQL Server: A Guide for the Accidental DBA
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
September 17, 2013 at 12:59 am
Thanks Koen,
Will most definitely look into this book.
Much appreciated!!!
September 17, 2013 at 4:00 am
Since the data is critical to the business, I'd suggest two things. First, ensure that the backups are meeting the business requirements. Talk to someone from the business side of things to ensure that they know what your agreed on Recovery Point Objective is and your Recovery Time Objective. That is the amount of data you can recover and the amount of time it's going to take to recover. That's one. Two, test a restore of the most critical machines. Make sure you can get the data back.
After that, you have time to figure everything else out.
"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
September 17, 2013 at 5:55 am
Grant Fritchey (9/17/2013)
Since the data is critical to the business, I'd suggest two things. First, ensure that the backups are meeting the business requirements. Talk to someone from the business side of things to ensure that they know what your agreed on Recovery Point Objective is and your Recovery Time Objective. That is the amount of data you can recover and the amount of time it's going to take to recover. That's one. Two, test a restore of the most critical machines. Make sure you can get the data back.After that, you have time to figure everything else out.
I'd like to second what Grant said. Taking backups are the most part of what you do because they enable you to recover data. I've heard it said that "you don't need a backup plan, you need a recovery plan". This shifts the focus a bit, but still means that your backups have to be in place. What the statement adds is that you need to know (and I mean really know) that you can recover databases from the backups. The only way you're really going to know is to practice.
I know, practicing is not fun or exciting, but you don't want your first recovery to be when you need it and the boss is breathing down your neck asking when it's going to be done. By that point, you want to be comfortable with the process.
Just my two cents.
September 17, 2013 at 5:57 am
Oh yeah...I forgot to say "congratulations and good luck" with the new position. 🙂
September 17, 2013 at 7:49 am
Ed Wagner -
I know, practicing is not fun or exciting, but you don't want your first recovery to be when you need it and the boss is breathing down your neck asking when it's going to be done. By that point, you want to be comfortable with the process.
I would add when comfortable with the process write down EVERY STEP NO MATTER HOW TRIVAL IT APPEARS TO BE[/B]. Keep that as a printed document in your desk at work, take a copy home. So that no matter how nervous you might be you can refer to it as you perform the recovery.
September 17, 2013 at 8:16 am
I really appreciate the advise and comments....
I'm taking note 🙂
September 17, 2013 at 11:28 am
I would add that it is good that you are on SQL Server Central. Use this site; it's a great resource! Ask questions, read through the forums and the articles. Take a look at Stairway to Transaction Log Management in SQL Server[/url]; you will find it very useful.
Get involved in the SQL community, network with the pros. If you (or preferably your company) can send you to SQL PASS, go! Check out the local SQL user groups. If there is a nearby SQL in the City, SQL Saturday, SQL Rally, etc... go!
I second Coen's recommendation to read Troubleshooting SQL Server: A Guide for the Accidental DBA. It's worth noting that you can download it for free at http://www.red-gate.com/community/books/[/url]. There are many other great books there. That's my $0.02.
-- Itzik Ben-Gan 2001
September 17, 2013 at 1:02 pm
Check out the Free eBook called "SQL Server Tacklebox: Essential Tools and Scripts for the Day-To-Day DBA".
http://www.red-gate.com/community/books/sql-server-tacklebox
September 18, 2013 at 11:43 am
Take your time and go through each SQL Server and look at the databases, the jobs, the SQL Server log, run times of jobs, CPU usage etc... to get a feel for how the system runs on a daily basis. So... if someone, in 2 months comes to you saying so and so is slow or whatever you have some idea of how things normally run.
Also, make sure Database Integrity jobs are running nightly during a slow time.... and make sure you have Update Stats jobs scheduled weekly or monthly.
Look at the server and make sure you aren't low on disk space as well.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply