November 4, 2011 at 12:39 pm
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.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
January 19, 2012 at 2:05 pm
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.
May 10, 2012 at 10:21 am
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.
May 10, 2012 at 11:16 am
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.
May 10, 2012 at 12:06 pm
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
May 10, 2012 at 12:23 pm
Elliott Whitlow (5/10/2012)
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
It's not always possible to look at a SQL query and know intuitively that it's won't perform well for some reason. However, there are occasions where the SQL is written in a convoluted way or contains an obvious problem, for example: functions on WHERE or JOIN clause predicates or inline co-related subqueries.
Senior level developers will unit test queries as they write them, so the DBA doesn't have come along behind doing damage control. Knowing and practicing good unit testing techniques; that's a mark of a senior level SQL developer.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 10, 2012 at 12:48 pm
Eric M Russell (5/10/2012)
Elliott Whitlow (5/10/2012)
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
It's not always possible to look at a SQL query and know intuitively that it's won't perform well for some reason. However, there are occasions where the SQL is written in a convoluted way or contains an obvious problem, for example: functions on WHERE or JOIN clause predicates or inline co-related subqueries.
Senior level developers will unit test queries as they write them, so the DBA doesn't have come along behind doing damage control. Knowing and practicing good unit testing techniques; that's a mark of a senior level SQL developer.
Code, indexes and table structures, data. All three together (even just the first two) can go a long way to identifying what is or isn't effecient. Maybe the query needs to be restructured (do that a lot) to help see what is going on. If you have been doing this enough, some things just stand out.
I've worked with Senior SQL Developers, they aren't always looking for the most performant way to write code. Many times all they are looking for is that it returns the correct result set and is performant in the test environment (which usually has much less data than the production environment).
May 10, 2012 at 1:28 pm
Eric M Russell (5/10/2012)
Elliott Whitlow (5/10/2012)
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
It's not always possible to look at a SQL query and know intuitively that it's won't perform well for some reason. However, there are occasions where the SQL is written in a convoluted way or contains an obvious problem, for example: functions on WHERE or JOIN clause predicates or inline co-related subqueries.
Senior level developers will unit test queries as they write them, so the DBA doesn't have come along behind doing damage control. Knowing and practicing good unit testing techniques; that's a mark of a senior level SQL developer.
I wasn't seeking an ALWAYS point Eric. I have found many performance issues with no more information than this sproc performs slow, a quick look revealed code that would all but guarantee poor performance. I didn't need to see the plan, I didn't need to see IO for this. Is this ALWAYS what happens, no, but it certainly happens quite a bit. And if you know the table structures and the indexes in place you can predict in many cases what the plan will look like. This is not to say that looking at the plan and getting the IO counts don't have value, but the original poster seemed to indicate that if you didn't do that you had already failed, which I categorically disagree with.
There are no hard rules, if you want to look at the plan and the IO first, go right ahead. If you want to look over the code for obvious errors, go right ahead. But don't take the position that either of this automatically the absolute first step and that those not following your order are wrong..
CEWII
May 10, 2012 at 1:37 pm
Elliott Whitlow (5/10/2012)
Eric M Russell (5/10/2012)
Elliott Whitlow (5/10/2012)
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
It's not always possible to look at a SQL query and know intuitively that it's won't perform well for some reason. However, there are occasions where the SQL is written in a convoluted way or contains an obvious problem, for example: functions on WHERE or JOIN clause predicates or inline co-related subqueries.
Senior level developers will unit test queries as they write them, so the DBA doesn't have come along behind doing damage control. Knowing and practicing good unit testing techniques; that's a mark of a senior level SQL developer.
I wasn't seeking an ALWAYS point Eric. I have found many performance issues with no more information than this sproc performs slow, a quick look revealed code that would all but guarantee poor performance. I didn't need to see the plan, I didn't need to see IO for this. Is this ALWAYS what happens, no, but it certainly happens quite a bit. And if you know the table structures and the indexes in place you can predict in many cases what the plan will look like. This is not to say that looking at the plan and getting the IO counts don't have value, but the original poster seemed to indicate that if you didn't do that you had already failed, which I categorically disagree with.
There are no hard rules, if you want to look at the plan and the IO first, go right ahead. If you want to look over the code for obvious errors, go right ahead. But don't take the position that either of this automatically the absolute first step and that those not following your order are wrong..
CEWII
Sort of goes like this, what is the first step in performance tuning a database?
Many people will start by saying to establish monitoring, look at current performance against a base-line, look at the DMV's for the worst performing queries. All good answers if you think about it. But guess what, it misses an important point.
First step in performance tuning a database, ask the users what is slow. That is where you should focus your attention first.
May 10, 2012 at 3:01 pm
I do think most of the good senior DBAs have jobs. If you know of one, and they become available, you should hire them.
If you need one, contact a few and ask them to ping you if they need a new job.
May 10, 2012 at 3:24 pm
Steve Jones - SSC Editor (5/10/2012)
I do think most of the good senior DBAs have jobs.
That is certainly the case where I live. The recruiters are constantly trying to lure us away from current jobs because there are no DBAs unemployed available. The salary offers are certainly drifting higher.
May 11, 2012 at 12:02 pm
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.
Me too; Sturgeons law (90% of everything is crud) definitely applies to SQL code, to schema design, and to choice of indexes to maintain, and it's therefor often possible to be pretty sure what needs doing before looking at a query plan.
So we can fail side by side if Oliiii ever gets to to interview us.
Tom
May 12, 2012 at 9:52 am
I have to say, in defense of these "senior dba's that can't answer textbook questions" ... being one of these people who has recently gone through lots of technical interviews... I really hate the interviews where people just sit me down and start asking me textbook test questions. I feel that sometimes they are either 1. not technical themselves and they need to ask me test questions because they can't just converse with me on a technical level or 2. they already know that I'm a good candidate and they probably have others too and lets just ask her some textbook questions to see if she's better than the others.
I may not like it of course but I have to be prepared for it. And I know of course I can't not expect to get grilled in this fashion... but I hate interviewing (I think I said that already!) and it is very stressful. A lot of times they will start asking me all these nitty gritty technical questions and I may know the answer and how to handle it just not in a textbook definition sort of way and with all the "key words" they are trying to get me to say. A lot of times I will know the answer but they have me so nervous and stuff that I either forget to say it or I stumble around something I already know.
Just this week I had 2 interviews. One was a phone interview and the second was in person. Both technical but both totally different. The first phone interview was straight up test questions. The other thing that bugs me is they ask these test questions in context to their work environment... I'm the kind of person that likes to ask tons of questions, get all the facts and then formulate answers... so on this phone interview I would answer these questions in the way that my current company or ones I've worked in before handled the situation/question they gave me. But then she would correct me and say oh well we don't do it like that here, we do it this way... so, this was really frustrating to me because there isn't one way to do something and I really felt put off right away. They were also asking me some very obscure questions that were just mostly I think to see if I was clever enough to know said obscure question. I must have done well because they emailed me back 15 minutes after the phone interview to set up a face to face.
The second interview I had, the in person one, was like night and day compared to the phone interview. This one was laid back, I was sitting on a sofa and was sitting with the project manager, the VP and a SQL guru. They had my resumes in front of them and we just had a conversation. It was a very technical conversation and I had to get into detail about how I would handle situations but it was so much less stressful. It also allowed me to call upon my current experiences and be able to just "talk". The SQL guru and I even really had a fun time dishing about coding practices we can't stand and new features we were looking forward to. It was a really "nice" interview. It also felt more personable and that they really wanted to know me and my background and not just how many textbook questions I could answer. I got an offer for this job yesterday too! Yay! 🙂
I think that was the biggest thing for me... they wanted to know me and my experiences and how I would handle stuff. Not my ability to get an A on a test. Although I do understand the desire to weed out bad candidates I really think you can do it without making people sit through an exam. People are also less likelly to be nervous and stumble all over themselves if they aren't pressured to get questions right.
May 12, 2012 at 11:48 am
I absolutely do understand about the type of "test" interviews that you're talking about but being nervous under fire is all a part of what it means to be a DBA. Of course, it's also a good measure as to whether or not you think the company might be good to work for. If they come off in the interview as short and "testy", then they might not be someone you'd want to work for. Perhaps they actually did you a great favor.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 12, 2012 at 11:59 am
Lynn Pettis (5/10/2012)
First step in performance tuning a database, ask the users what is slow. That is where you should focus your attention first.
Well said. That's actually one of the answers I look for on interviews.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 106 through 120 (of 187 total)
You must be logged in to reply to this topic. Login to reply