Intro....plus....What do your SQL Maintenance Plans look like?
-
I was recently tasked by my company to take on the DBA roll for a new SQL 2005 set of servers. I'm the Systems Admin by default but since they dont want to hire a DBA i was given the roll. I'm looking forward to learning SQL and it doesnt hurt to have another item to add to my resume.....BUT....learning curve is getting in the way of my many other tasks which is why I'm hoping to rely on newsgroups like this one
I've stocked up on books and added about 25 new Favorite Websites to my list for references but please bear with me as I will more than likely be posting a lot of questions over the next couple of weeks. The servers I'm responsible for (Production and Dev) are new running MS Server 2003 and SQL 2005 but I was not given the responsibility until a couple weeks after they were built and put in place. THere are still a LOT of things that need to be done to them. One of which is to setup Maintenance Plans. I was planning on making several. System plans and User plans. Daily plans, weekly plans and monthly plans.....and maybe a couple misc plans that I would only run when needed. For you professional DBA's out there....what do your daily and weekly plans look like? Do you check DB integrity each day? Whats the real difference between a Full Backup Transaction Log Backup and Full DB Backup? I've been using the Admin Pocket Consultant for MS SQL 2005 and its been a great help for most things and the websites are helpful too but I'd really like to hear from people who do this every day with real world examples of Maintenance Plans.
As I mentioned I'm reading up on this as much as I can but being the only DBA here and being under the pressure of getting these tasks in place before disaster strikes I'm posting to the forum for some tips. Thanks again!
-
This was removed by the editor as SPAM
-
Your maintenance and backup jobs should be inline with business requirements.
Ask the business how much data loss is acceptable - what down time is acceptable for recovery?
Ask the current application support or dev guys what procedures are slow so you can look at performance solutions before they impact service. Get a handle from the incumbents on reindexing requirements (based on frequency of updates or inserts), and current regular problems.
Once you know the problems, *then* start to develop your solutions.
-
Have you gotten any good responses to this? Are you still looking for info on maintenance plans? Since you're still posting, I'm guessing that nothing has blown up on you too badly.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply