April 21, 2010 at 9:25 am
Greetings all!!
I hope to find an answer to my question(s) here. If not, I will continue my quest.
Due to a lay-off from my former job of a programming tech-support position I started looking into the world of being a DBA. Long story short a few months ago I was given an opportunity to be the 2nd DBA of a growing financial company. The company operates over 40 servers with over 50 SQL Server instances that I work with. And that's only what I work with. The lead DBA guy handles all of them. I quite honestly don't know how many instances are running but many, many more.
Anyways...the guy that set up all of these instances is good. He's real good! He's got them working so well that my day consists mostly of monitoring drive space due to sql server logs, linked servers, access rights...and that's on a good day. On a bad day (i.e. slow) I do nothing...absolutely nothing! Mostly because he is handling things without involving me unless I force myself upon him. He doesn't volunteer information willingly or what he's working on unless I do become a pest. But on the positive side of that, he is very willing to show me what he's working on IF[/b] I ask. Therefore I am pretty much left to fend for myself throughout the day of looking for things to do.
My questions are as follows:
1. Is this the "norm" for a well run company to have a DBA work more as reactive then proactive[/b] ??
2. If so...what are some of the daily routines I can work on to help out? I'm not used to just sitting around waiting for stuff to break. Don't get me wrong, I can do that with no problems. I just want to know from other DBA's that this is the norm. I'm open to hearing anything regarding this.
I may have more questions after I get replies to this. Hope to hear from you all soon!
Thanks!!
April 21, 2010 at 9:34 am
John, I would say that is not normal, but not that uncommon. If the lead DBA would ever like to take some time off, he should make sure you know a lot more about the systems.
It will probably be up to you however, to insert yourself into the daily operations since it doesn't sound like the lead is much of a teacher/trainer. Ask lots of questions, document as much as you can of the systems and procedures. Develop a training guide yourself as if you will be training others in the ins and outs of the operations.
April 21, 2010 at 9:51 am
Hi,
Almost I experienced the same when I started my career as DBA 3 1/2 years ago. Running periodic checks (daily, monthly etc.,), running the release scripts, simple access issues etc., and then nothing. The rest was dealt by senior people. When mails come from developers and other users, they were responded by senior people as I was not very sure of acions to be taken.
But gradually, as I get to know the environment, the critical DBs and how they are maintained and why they are configured in certain way..... I started taking intiatives on replying mails, making suggestions etc.,
I believe, it all depends on how comfortable you are with the environment you are dealing with. The rest falls in place eventually. After a while, when a new DBA joins, you would be the mentor and then the new comer might feel the same considering you as the senior DBA 🙂
[font="Verdana"]Renuka__[/font]
April 21, 2010 at 10:55 am
John Waclawski (4/21/2010)
he is very willing to show me what he's working on IF[/b] I ask.
so... keep asking 🙂
On the other hand, 90% of the time a DBA has to work in a reactive way is because DBA failed to be proactive.
Always remember...
- Database has to be available.
- Database has to be recoverable.
- Database has to perform well.
- Database has to be secure.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.April 21, 2010 at 12:18 pm
John Waclawski (4/21/2010)
Greetings all!!I hope to find an answer to my question(s) here. If not, I will continue my quest.
Due to a lay-off from my former job of a programming tech-support position I started looking into the world of being a DBA. Long story short a few months ago I was given an opportunity to be the 2nd DBA of a growing financial company. The company operates over 40 servers with over 50 SQL Server instances that I work with. And that's only what I work with. The lead DBA guy handles all of them. I quite honestly don't know how many instances are running but many, many more.
Anyways...the guy that set up all of these instances is good. He's real good! He's got them working so well that my day consists mostly of monitoring drive space due to sql server logs, linked servers, access rights...and that's on a good day. On a bad day (i.e. slow) I do nothing...absolutely nothing! Mostly because he is handling things without involving me unless I force myself upon him. He doesn't volunteer information willingly or what he's working on unless I do become a pest. But on the positive side of that, he is very willing to show me what he's working on IF[/b] I ask. Therefore I am pretty much left to fend for myself throughout the day of looking for things to do.
My questions are as follows:
1. Is this the "norm" for a well run company to have a DBA work more as reactive then proactive[/b] ??
I wish I could tell you that it's abnormal, but I think it's probably just shy of being completely the majority of systems and shops that only react. I've been strugling within my company for years to get people to worry about the servers BEFORE they go offline. We're getting there, but it's a struggle.
2. If so...what are some of the daily routines I can work on to help out? I'm not used to just sitting around waiting for stuff to break. Don't get me wrong, I can do that with no problems. I just want to know from other DBA's that this is the norm. I'm open to hearing anything regarding this.
I may have more questions after I get replies to this. Hope to hear from you all soon!
Thanks!!
I'd keep asking the guy too. But, the first question I'd ask is, "Can I go out and capture some performance metrics?" Then see how the servers are performing, what they're doing, how they're doing it and start looking for tuning opportunities or process improvements. There are ALWAYS places that can be improved. If you're working with sQL Server 2008, start looking into Policy Based Management. You can get a lot of silly make-work out of the way automatically... Oh, there's tons of stuff to do. If nothing else, swing by here and take a shot at answering a few questions.
"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
April 21, 2010 at 4:35 pm
Heh... move your chair into his cube and tell him you'll leave when he's taught you to know as much as him. Be sure to let your deoderant fail. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
April 21, 2010 at 4:57 pm
Me, and many of my friends do spend a few hours surfing the web during the day.
When that get's boring, I do thing like admin scripts (you learn alot about the internals of SQL and you can improves workflow and process)
Then, see if there are any sandbox servers. 2008 is really fun to play with in a sandbox environment (PBM, data/backup compression, resource governor, the DataWarehouse (Data Collection Stats, not a DW), Central Management).
While he is out fighting the fires on current production, you can formulate plans for upgrading to 2008, knowing the in's and out's of the new platform. This will definately give you an advantage with management (management loves to hear that data/backup compression saves a crap load of SAN space and can improve performance while lowering netowrk traffic and physical disk IO).
Learn as much about the environment as you can (don't worry about not knowing how many instances/servers there are, every where I have ever worked, no one know all of them, there are some that are barely touched, there are new ones, there are some that were put up that you don't administer), but learn as much as you can about all aspects of SQL, it will make you more marketable to your employer and future employers.
Then, to kill the time surf the web. For most DBA's work is feast or famine, in 13 years as a DBA, that has been the case at every company I have ever worked at.
/* ----------------------------- */
Tochter aus Elysium, Wir betreten feuertrunken, Himmlische, dein Heiligtum!
April 21, 2010 at 5:12 pm
John Waclawski (4/21/2010)
1. Is this the "norm" for a well run company to have a DBA work more as reactive then proactive[/b] ??2. If so...what are some of the daily routines I can work on to help out? I'm not used to just sitting around waiting for stuff to break. Don't get me wrong, I can do that with no problems. I just want to know from other DBA's that this is the norm. I'm open to hearing anything regarding this.
I'm going to take a different spin than the others. It sounds like you have a pretty slow day with 50 instances. If he has another 50 instances - is he really doing anything more than you or is he working on projects?
Maybe, it appears that things are reactive because most of the work has already been done in a proactive fashion so as to limit the reactive work.
I would certainly keep asking him what he is working on or various things. Find out if you can work on a project.
Daily routine type stuff - create some projects for the slow times. I like the idea of working on admin type tasks - you learn a lot more that way.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 21, 2010 at 6:44 pm
GregoryF (4/21/2010)
Me, and many of my friends do spend a few hours surfing the web during the day.
Then, to kill the time surf the web.
Might I suggest instead of just surfing the web, that you visit sites such as this one. Try answering questions before you look at the answers, then compare your answers to those already posted. Read the other answers, and learn all that you can from them. Answering all of these questions will help you learn, and stay sharp.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 21, 2010 at 6:51 pm
WayneS (4/21/2010)
GregoryF (4/21/2010)
Me, and many of my friends do spend a few hours surfing the web during the day.Then, to kill the time surf the web.
Might I suggest instead of just surfing the web, that you visit sites such as this one. Try answering questions before you look at the answers, then compare your answers to those already posted. Read the other answers, and learn all that you can from them. Answering all of these questions will help you learn, and stay sharp.
Sufring the web certainly does include http://www.sqlservercentral.com and http://www.microsoft.com/sql. It's amazing how much you can learn my going through technet and just looking at reserved SQL words and commands and all the options. In fact, in my case, I spend more time surfing IT sites than CNN and Drudge 🙂
/* ----------------------------- */
Tochter aus Elysium, Wir betreten feuertrunken, Himmlische, dein Heiligtum!
April 21, 2010 at 8:04 pm
GregoryF: "don't worry about not knowing how many instances/servers there are, every where I have ever worked, no one know all of them, there are some that are barely touched, there are new ones, there are some that were put up that you don't administer"
Really? I mean, I'm not a DBA, but if I was your manager and asked you how many instances or servers we had, and you DIDN'T know? You'd be taking an indefinitely-long lunch break.
I would suggest taking a look at Tom LaRock's recent book - DBA Survivor[/url]. It's got a great checklist of things to get you started. I would think once you could answer the questions in that list, you'd have a pretty good sense of what your lead DBA has done/has not done and where you fit in. Then you could work with them to prioritize who does what.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
April 21, 2010 at 9:11 pm
This is great information everyone! Thanks!!
To go beyond a few things here I will elaborate as to what I do do to keep busy.
1. Run Traces...hehe...gotten into a bit of trouble with those but he gave me a thumbs up for being proactive and owing up to the issue.
2. Watch video tutorials on things regarding SS2k5 & beyond.
3. Babysit log files on very small hard drives.
4. Read - Read - Read. I have a number of books I reference & use examples from
5. Monitor server usage.
6. Try to figure out a way to use my SQL coding ability to help out. Suggestions there? I like working with triggers.
On a side note regarding me being a newb....Roles & Security & Rights. I'm still having an issue grasping this concept. Does anyone have any good links, notes, etc. that explain these in a way that a newb can understand them? I have an idea of what they all do but for the most part when I set something up, I'm basically just mimicking another user' rights.
Thanks again everyone! This is very much appreciated!
April 21, 2010 at 9:25 pm
jcrawf02 (4/21/2010)
GregoryF: "don't worry about not knowing how many instances/servers there are, every where I have ever worked, no one know all of them, there are some that are barely touched, there are new ones, there are some that were put up that you don't administer"
Really? I mean, I'm not a DBA, but if I was your manager and asked you how many instances or servers we had, and you DIDN'T know? You'd be taking an indefinitely-long lunch break.
I would suggest taking a look at Tom LaRock's recent book - DBA Survivor[/url]. It's got a great checklist of things to get you started. I would think once you could answer the questions in that list, you'd have a pretty good sense of what your lead DBA has done/has not done and where you fit in. Then you could work with them to prioritize who does what.
Define an instance you don't know about:
1) An instance the NT group put up for themselves, and you don't support it until somthing goes wrong
2) An DB server and an App on the same server that you never heard about because the "App takes care of everything"...Until something goes wrong.
3) An Server that has been running for three years without out being rebooted that only a handful of people know even exists.
I've seen them all, there are core servers (that we know about and are pro-actively engaged in), secondary servers (we know they exist, but require little maintenance), and tertiary servers (only the dude who has been there eigh years has ever heard of them, and he might not even be aware).
When you work in an envoronment that is very large (I once worked at at Fortune 100 firm with 18 SQL DBA's), there are many, many, many servers that any individual does not know of.
/* ----------------------------- */
Tochter aus Elysium, Wir betreten feuertrunken, Himmlische, dein Heiligtum!
April 21, 2010 at 9:59 pm
GregoryF (4/21/2010)
jcrawf02 (4/21/2010)
GregoryF: "don't worry about not knowing how many instances/servers there are, every where I have ever worked, no one know all of them, there are some that are barely touched, there are new ones, there are some that were put up that you don't administer"
Really? I mean, I'm not a DBA, but if I was your manager and asked you how many instances or servers we had, and you DIDN'T know? You'd be taking an indefinitely-long lunch break.
I would suggest taking a look at Tom LaRock's recent book - DBA Survivor[/url]. It's got a great checklist of things to get you started. I would think once you could answer the questions in that list, you'd have a pretty good sense of what your lead DBA has done/has not done and where you fit in. Then you could work with them to prioritize who does what.
Define an instance you don't know about:
1) An instance the NT group put up for themselves, and you don't support it until somthing goes wrong
2) An DB server and an App on the same server that you never heard about because the "App takes care of everything"...Until something goes wrong.
3) An Server that has been running for three years without out being rebooted that only a handful of people know even exists.
I've seen them all, there are core servers (that we know about and are pro-actively engaged in), secondary servers (we know they exist, but require little maintenance), and tertiary servers (only the dude who has been there eigh years has ever heard of them, and he might not even be aware).
When you work in an envoronment that is very large (I once worked at at Fortune 100 firm with 18 SQL DBA's), there are many, many, many servers that any individual does not know of.
One word: SQLPing.
You should have a very good idea of how many instances are installed on how many servers. And if any of those are clusters, how many physical computers make up the clusters.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 22, 2010 at 5:14 am
jcrawf02 (4/21/2010)
GregoryF: "don't worry about not knowing how many instances/servers there are, every where I have ever worked, no one know all of them, there are some that are barely touched, there are new ones, there are some that were put up that you don't administer"
Really? I mean, I'm not a DBA, but if I was your manager and asked you how many instances or servers we had, and you DIDN'T know? You'd be taking an indefinitely-long lunch break.
I would suggest taking a look at Tom LaRock's recent book - DBA Survivor[/url]. It's got a great checklist of things to get you started. I would think once you could answer the questions in that list, you'd have a pretty good sense of what your lead DBA has done/has not done and where you fit in. Then you could work with them to prioritize who does what.
I hate to say this, but I don't know how many servers & instances we have either. It's near one hundred under management. They come & go too. If it was my job to know all the servers, I would, but since I have to focus on development & design, with management a second teir responsibility, I just don't track that stuff. I'd sure hate to get fired because of it though.
"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
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply