|
|
|
SSChampion
Group: General Forum Members
Last Login: Today @ 12:10 PM
Points: 14,134,
Visits: 8,527
|
|
Yes, environmental knowledge is good, but if I have time to study something job-related, I'd rather spend it on something directly within the SQL Server domain. Better ROI on my time, in my experience thus far.
If I have, for example, a day to study something for work, and get to choose between Active Directory, and SQL Denali's new partitioned aggregates, I'm going to study the Denali piece (SQL 2012 or whatever they're calling it this week).
I find there's never a lack of SQL Server material to learn, or get better at.
For example, I just recently was presented with a question on these forums about a moderately complex use of T-SQL's implementation of XQuery. In working out a solution for it, I figured out a way to speed up a couple of XQuery procedures that I use on a routine basis. I'm talking about the difference between glaciers and lightning on the speed.
I could easily have spent that time trying to figure out why a NET USE connection from one server to another is failing. Our domain admin is already working on it, but it would certainly have been a learning experience for me to at least ghost him on the solution.
The AD question is more likely to be useful in more situations, but it's also one outside my responsibility domain. The XQuery piece is only useful in a few situations, but it directly relates to database performance, and is thus squarely inside my domain. Which should I spend my day researching/learning? The XQuery one.
And I find that, no matter how much I know about SQL Server, my ignorance remains infinite and always open to reduction.
And that's why I disagree with your hypothesis. I'd rather spend my education time on what is more likely to pay the bills for me. And my boss would rather I spent that time that way too. As, I'm sure, any future employers will agree.
- GSquared, RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
|
|
|
|
|
SSC-Enthusiastic
Group: General Forum Members
Last Login: Today @ 12:27 PM
Points: 112,
Visits: 385
|
|
GSquared, there really are no wrong answers here. 
There are different types of "senior" DBAs. We all study and read what happens to interest us on a given day.
There are many SQL Server Central articles that I skip (sorry Steve Jones).
There are also many that I read when it is a topic that interests me.
I think that once you reach a certain level, then you have enough of a foundation to figure out just about anything SQL Server related with some modest search skills.
|
|
|
|
|
SSCertifiable
Group: General Forum Members
Last Login: Yesterday @ 1:32 PM
Points: 5,802,
Visits: 4,783
|
|
GSquared (11/2/2011)
And I find that, no matter how much I know about SQL Server, my ignorance remains infinite and always open to reduction.Amen, no matter how much I have learned there is an infinite amount I still have to learn. And the smartest people I know, know what they DON'T know.
CEWII
|
|
|
|
|
SSCrazy
Group: General Forum Members
Last Login: Today @ 5:34 AM
Points: 2,491,
Visits: 2,115
|
|
Elliot
Amen, no matter how much I have learned there is an infinite amount I still have to learn. And the smartest people I know, know what they DON'T know.
So true - unfortunately there are many who can't/won't admit their limitations, which helped me to build a great business at one time just following them around.
I also agree, there is always much more to learn.
I would agree that also there should be a requirement to learn about SAN's, how they work and how you need it to work. I wasted a lot of time contradicting what the sales people were saying which worked fine if it was used solely for file servers.
I think that not knowing how networks work, AD, OS, etc can only make you more attractive especially if you are a consultant. Otherwse you are trusting that everyone else is at your level.
Steve Jimmo
Sr DBA
It is a narrow mind that cannot see things from more than one point of view. — George Eliot
|
|
|
|
|
SSCertifiable
Group: General Forum Members
Last Login: Yesterday @ 1:32 PM
Points: 5,802,
Visits: 4,783
|
|
sjimmo (11/2/2011)
Elliot
Amen, no matter how much I have learned there is an infinite amount I still have to learn. And the smartest people I know, know what they DON'T know. So true - unfortunately there are many who can't/won't admit their limitations, which helped me to build a great business at one time just following them around. I also agree, there is always much more to learn. I would agree that also there should be a requirement to learn about SAN's, how they work and how you need it to work. I wasted a lot of time contradicting what the sales people were saying which worked fine if it was used solely for file servers. I think that not knowing how networks work, AD, OS, etc can only make you more attractive especially if you are a consultant. Otherwse you are trusting that everyone else is at your level. I think having a good amount of knowledge of TCP/IP, AD, various windows versions, windows networking, basic networking and connectivity, SAN basics, all in addition to strong database engine knowledge. As a junior DBA or even just a DBA I would strive to build this experience.
I always wonder why it is so hard to admit our limitations, there is no shame in it. I've had a few interviews in the past where a particular aspect of SQL was being used in that environment that I didn't have any or much experience with. Back in '99 it was transactional replication, never used it, never had a reason, the company I was interviewing with did and would. I was completely upfront about it but I was also happy to learn it.
A broad range of experience outside of just SQL adds to your value and provides you with valuable insight to evaluate different paths to solve a problem.
CEWII
|
|
|
|
|
SSCarpal Tunnel
Group: General Forum Members
Last Login: Yesterday @ 8:00 PM
Points: 4,767,
Visits: 4,984
|
|
L' Eomot Inversé (11/2/2011)
I guess that if you are fighting that one you've decided what tha A in DBA stands for? Depending what you want DBA to mean, you and I might be on the opposite sides of that fight.
Part of the reason it's a wide ranging job title is that the A can stand for Administrator, Architect, Assistant, or a wide range of other things.
99% of the time people assume it means 'DataBase Administrator'. It's rarely thought of as the initials meaning something else.
So in that essence, I'm just going with the flow on that one. But I'd like our section of IT to be less generic. There's Web Designers, Middle Tier architects... etc... in Front end, but in the back, we're all just DBAs.
- Craig Farrell
I'm out of patience with my patients, so I've wound their wounds with paper, and they've seen red from what they've read, so they left to the left and found solace with my neighbor.
For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables
Twitter: @AnyWayDBA
|
|
|
|
|
Mr or Mrs. 500
Group: General Forum Members
Last Login: Thursday, May 10, 2012 2:58 PM
Points: 537,
Visits: 973
|
|
As said by others - there is so much involved in SQL server now (and different DBA roles concentrate on different areas depending on the business/systems/projects) that it would be rare for even a Senior DBA to know EVERYTHING.
You would probably expect them to be great at performance tuning BUT remember that someone with 7 years 2000/2005/2008 might not have used DMVs much or still be using 2000 legacy stored procs. I'm guilty of that to some extents.
Also as someone just above mentioned - people need to admit their failings. "I'm not sure on that one, but I would know where to look" or "I haven't touched merge replication, I've concentrated on Transactional but I don';t think it would take me long to pick that up" or "We didn't really get to use Service Broker, but I have read about it and I wouldn't have a problem taking that on board" are much better answers than spending 5 to 10 minutes umming and arring and trying to bullshit your way through the door.
|
|
|
|
|
Valued Member
Group: General Forum Members
Last Login: Today @ 2:27 PM
Points: 71,
Visits: 278
|
|
Wow - it took me a couple of days in between othe tasks, but I finally finished reading the thread, and I feel the need to add my two cents:
- There's a lot of bravado among technical people about our skills "I can install SS and build an entire DBMS system from the command line!" So what! MSSQL often offers 2, sometimes 3 ways to do the same thing. The GUI or wizards may be faster for some tasks. Other times script commands offer options not available in the GUIs. I would think a Senior DBA would know the difference, and which interface is best used in which situation used can often be a matter of personal preference.
- One thing I've decided is that I enjoy working in IT most when I have 85-90% of the knowledge and skills I need for my job. The fun part is figuring out the other 10-15 percent. When I reach 100 percent, I'm bored, and I should either look for new things to take responsibility or initiative on, or look for a more challenging job.
- On a related note, the MSSQL suite is vast enough that almost no one is expert at all of it. And most DBA jobs require that you only know part of it. I know longer feel that I need to know everything, but I do need to be able to learn whatever I need know quickly.
- This is where the value of certification comes in. I'm studying for that now, and that's forcing me to study and experiment with parts of MSSQL I have not used in my jobs. The value of that is that while passing an exam won't make me an expert at everything, I'll know enough about everything to open the right tool in one monitor, BOL in the other monitor, and figure it out.
- So where are the good Senior Level DBAs? As someone pointed out, they tend to be too busy working to actively job hunt, which is why interviewers might have trouble finding them. That's why I'm also putting more effort into becoming one.
|
|
|
|
|
SSCoach
Group: General Forum Members
Last Login: Today @ 2:19 PM
Points: 17,226,
Visits: 21,248
|
|
Oliiii (10/15/2010)
Usualy a DBA does not work in "Project" mode, so once they start somewhere they usualy work there for some time (years).
So in the end finding a SQL DBA is not an easy thing and the good known ones are constantly busy.
You have to be a little bit lucky and have some kind of test to make sure they are really what they say (your test is a very good idea), being a sql DBA is very broad, even developer who worked with SQL Server could say he's a DBA just because he think he know some SQL statement.
On top of your test i would add the good old Fizz Buzz, ask them to tune a single query on 2-3 tables (with an index with an include or two missing), backup and restore a DB, create 100 Logins (to see if he can automate things), nothing that couldn't be done in less than 5 mins and look how they do it.
If the guy end up with a rbar solution for FizzBuzz it wouldn't be too bad but one that ends up with a set based solution will have a nice bonus on the final review.
Anyone doing a backup/restore with SSMS wizzard will have a (very) bad point (unless he uses it just to generate the script, then he's lazy -> good point).
Anyone opening the books online will have a good point.
Anyone creating more than 2 Logins without a script will have a bad point.
Anyone tuning the query by not looking at IO and Time statistics and query plan would immediately fail.
With that kind of test it's kinda easy to see if someone is used to work with SQL Server full time or if it's just a hobby.
Anyone tuning the query by not looking at IO and Time statistics and query plan would immediately fail.
Guess I'd fail here. First things I look at are the code, the indexes, and the data. Amazing what you can learn from just looking at those before you even look at IO and Time statistics or the query plan.
Lynn Pettis
For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs
SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
|
|
|
|
|
SSCertifiable
Group: General Forum Members
Last Login: Yesterday @ 1:32 PM
Points: 5,802,
Visits: 4,783
|
|
Lynn Pettis (5/10/2012)
Anyone tuning the query by not looking at IO and Time statistics and query plan would immediately fail. Guess I'd fail here. First things I look at are the code, the indexes, and the data. Amazing what you can learn from just looking at those before you even look at IO and Time statistics or the query plan.
+1 Lynn..
Had a wonderful PASS meeting last night where the presenter Joe Webb did his presentation on Writing Better Queries. My point is that just looking at some of the queries, an experienced developer can see problems without even having to look at the IO or plans, you knew they would be bad. And the queries shown were largely ones I'd seen ACTUALLY used before.
So a little observation goes a long way..
CEWII
|
|
|
|
