April 22, 2010 at 6:39 am
So what would you do if everything died? Fix what you know of and wait for the users to yell about whatever you didn't know of?
Anyway, if it's not your job to know that, or has been agreed upon that you are not focusing on that, that's one thing. Recommending that it's not necessary to know that is something else.
---------------------------------------------------------
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 22, 2010 at 6:46 am
jcrawf02 (4/22/2010)
So what would you do if everything died? Fix what you know of and wait for the users to yell about whatever you didn't know of?Anyway, if it's not your job to know that, or has been agreed upon that you are not focusing on that, that's one thing. Recommending that it's not necessary to know that is something else.
Of course not. We have lists of the servers that are maintained. We also have all the managed servers being monitored by Microsofts System Center Operations Manager. And we have a few DBA's whose sole responsibility is to management of servers. I might be stupid, but I'm not crazy.... well, too crazy.
But, at the end of the day, I still don't know all the servers we have under management.
"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 22, 2010 at 8:44 am
Grant Fritchey (4/22/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.
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.
It does make a difference with what your job responsibilities are. I was speaking from the approach that a dba is responsible for all the database servers. If you're job is strictly doing development/design work, then obviously this doesn't apply to you.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 22, 2010 at 11:14 am
WayneS (4/21/2010)
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.
SQLPing works in many scenarios but not all (especially when networking has done a good job of segmenting the network and limiting traffic, protocols, and ports.
That said, I believe there should be a good inventory of the servers under management. DO I know off hand every server - no. However, I do have the servers all inventoried and refer back to notes if need be. I also like to try and discover new instances from time to time to make sure I have control on the environment.
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
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply