Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««23456»»

Who wants to be a SQL Server DBA? Expand / Collapse
Author
Message
Posted Tuesday, October 16, 2007 5:58 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Yesterday @ 1:03 PM
Points: 15,729, Visits: 28,132
John Aherne (10/15/2007)
wow. I have been an informal dba (i.e. the only person willing to look into it) since SQL 6.5 but I cannot answer any of those questions. I am sure I have used (or made a conscious informed decision not to use) all of those, but I forgot the details as soon as I didn't need them anymore.

So, what does someone like me, with a terrible memory but good problem solving skills do in an interview?


The thing is, the questions we ask are conceptual in nature. I'm not going to ask syntax questions, that's what BOL is there for. I don't care if you know every possible permutation of the CREATE INDEX statement. I need to know that you understand which index is which and where they are likely to be more useful. I have to look up basic syntax all the time. I just can't keep it straight in my head, but the concepts are there (mostly, most of the time).


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #411219
Posted Tuesday, October 16, 2007 8:05 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, September 10, 2014 9:51 AM
Points: 269, Visits: 496
Having read rhat's comments, I realize one of the most important skills - interpersonal relations. As a DBA you have to work with many groups (SAN, Server, Network, Developers, Security and even the dreaded END USER!). This means you have to be flexible and able to extract what is being asked and translate it into whatever language necessary to get it done.
You may also be working with others code, it may be imperfect, in beta stages - whatever. If you can't deal with imperfection and if you can't make constructive comments - don't apply. If your not felxible enough to work with code or methods that may not be the exact way you would do it, you will likely cause more problems than solve. I'm not sure how you tease this info out of applicants, but having worked with inflexible (arrogant) DBA's in the past - I would like to avoid them.



Post #411307
Posted Tuesday, October 16, 2007 9:38 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, June 4, 2014 12:07 PM
Points: 56, Visits: 132
With regard to the statement the writer made, "so I don’t care if you have a CS vs biology degree, but having that piece of paper means you have the fortitude to get through 4 (or more) years of being abused."

I learned computer science in the Marine Corps and, when I got out, I wanted to go to college, but had the responsibility of a wife and child to consider. It has been my experience that way too many people place a premium on having gone to college. Yes, I wish I had been able to, but it has nothing whatever to do with my qualifications. As for the ability to withstand abuse, Parris Island and, later, 13 years as a contractor should be a shining testimony in my favor.
Post #411363
Posted Tuesday, October 16, 2007 11:44 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, September 10, 2014 9:51 AM
Points: 6, Visits: 184
I'm definitely not saying the piece of paper is a yes or no for hiring someone. Without the degree I look for an equivalent 4 years of experience. My big concern is when I see a DBA that has only ever had 1 job with no related degree and no certifications/coursework listed. I have to wonder how did they learn SQL Server? Trial and error is a good teacher - but not on my production boxes! And trial and error will take much longer to learn good practices.
So if you don't have a degree put a section in Training or Coursework and explain how you learned your crafts - don't make me have to guess.
Post #411404
Posted Tuesday, October 16, 2007 12:38 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, November 21, 2011 1:31 PM
Points: 5, Visits: 53
In six years, I've used them twice, and both times I had time (a minute or two) to look them up first and make sure I was using them correctly. I'd much rather memorize things I'll use constantly (the table names, for example), and things I'll use regularly (string and date functions, for example), than things I'll use twice in six years (DBCC commands). (Of course, I use DBCC commands all the time, but I use them by clicking buttons and right-click menues in management studio, etc., not by typing them out myself.)

As for losing 19 hours of data because of restoring to a last-known-good-point instead of using esoteric database commands to try to fix something, whoever thinks those are the only two options is to stay away from my databases. Far away! Please, go work for my competitors. They need you!


OK, you said it yourself, you used DBCC command 2 times in the last 6 years. Now, another thing, I don't which buttons you are clicking in management studio and how many times you use them, but I for one don't even have to do that "all the time". Why, cause my DB's are designed right. The point is to "minimize" management to begin with.

Second, if your last company went out of "business" it would seem like they could have used someone else than those who worked there.

And By the way, and not you, most BLUE CHIP companies, have some of the "slowest" DB systems even with all the money, expertise, tech, etc. Case in point, Cell Phone companies websites have been incredilble slow, not to mention, always DOWN. Ever go to there store and the person at the counter says, Sorry, you have to come back later, OUR COMPUTER IS DOWN.

Look at the FBI, virtual case file project!!! That is a massive IT project that's a complete and utter failure. It's been in the news and called in Congress and STILL after several revamps, reviews, changes, it's still NOT up. They must have lots of DBA's there that know DBCC and lots of these dumb so-called "db best practices" HA! HA! HA!

When more than 70% of the IT projects there fail, there need to be more communication.....it called communicating the BRUTAL TRUTH!!!
Post #411423
Posted Tuesday, October 16, 2007 2:01 PM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, September 11, 2014 7:58 AM
Points: 1,298, Visits: 769
Man I want to work where Rhat works! Imagine the utopia of perfectly designed databases, servers, hardware. Never had to figure out why you suddenly are starting to see corruption in data? hmm restore and 2 hours later you have corruption again?

oh look at this, this DEC Alpha box is suddenly corrupting the data. ok fine do a restore to the last known good backup. Dang it, now it is corrupt again. This one happened to me, no amount of immediate restores would have fixed your problem. Tell me Rhat, how would you fix it? Restore to an Intel box? Try again, won't work (another good interview question back in the day, why can you not restore it?).

Never had to check your inputbuffer or outputbuffer? Application hangs for no reason, what you do? Restore?? Sorry, but even the best designed system can at some point or another hit the wall when it comes to performance.

Many of the places I have worked the time it would take to do a restore would be a lot longer than me spending half an hour on research into the problem. Not to mention that half an hour of research usualy leas to me knowing enough to redo whatever made it happen in the first plave not to happen again. With your approach you would never solve your problem permanently.

And yes interpseonal skills are almost as important as your SQL skills.
Post #411448
Posted Tuesday, October 16, 2007 3:46 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 5:47 AM
Points: 6,266, Visits: 2,029
rhat (10/16/2007)
In six years, I've used them twice, and both times I had time (a minute or two) to look them up first and make sure I was using them correctly. I'd much rather memorize things I'll use constantly (the table names, for example), and things I'll use regularly (string and date functions, for example), than things I'll use twice in six years (DBCC commands). (Of course, I use DBCC commands all the time, but I use them by clicking buttons and right-click menues in management studio, etc., not by typing them out myself.)

As for losing 19 hours of data because of restoring to a last-known-good-point instead of using esoteric database commands to try to fix something, whoever thinks those are the only two options is to stay away from my databases. Far away! Please, go work for my competitors. They need you!


OK, you said it yourself, you used DBCC command 2 times in the last 6 years. Now, another thing, I don't which buttons you are clicking in management studio and how many times you use them, but I for one don't even have to do that "all the time". Why, cause my DB's are designed right. The point is to "minimize" management to begin with.

Second, if your last company went out of "business" it would seem like they could have used someone else than those who worked there.

And By the way, and not you, most BLUE CHIP companies, have some of the "slowest" DB systems even with all the money, expertise, tech, etc. Case in point, Cell Phone companies websites have been incredilble slow, not to mention, always DOWN. Ever go to there store and the person at the counter says, Sorry, you have to come back later, OUR COMPUTER IS DOWN.

Look at the FBI, virtual case file project!!! That is a massive IT project that's a complete and utter failure. It's been in the news and called in Congress and STILL after several revamps, reviews, changes, it's still NOT up. They must have lots of DBA's there that know DBCC and lots of these dumb so-called "db best practices" HA! HA! HA!

When more than 70% of the IT projects there fail, there need to be more communication.....it called communicating the BRUTAL TRUTH!!!


Honestly,

You have displayed a mirriad of "BASIC" problems that would never ever get you in my company.
I would advice you to actually check yourself a bit because many of your statements are not only wrong but also include a total lack of personal skills. If you are a "DBA" you seriously need to get traning really fast.

Good luck,




* Noel
Post #411494
Posted Tuesday, October 16, 2007 6:12 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, November 21, 2011 1:31 PM
Points: 5, Visits: 53

You have displayed a mirriad of "BASIC" problems that would never ever get you in my company.
I would advice you to actually check yourself a bit because many of your statements are not only wrong but also include a total lack of personal skills. If you are a "DBA" you seriously need to get traning really fast.
Good luck,



Seems like the companies that go "bankrupt", such as the one you previously mentioned, are the ones I want to avoid in the first place.

Believe me, I don't want to be in your company as it sounds like more "personal skills" are needed there (i.e. don't say anything negative to hurt anyone's feeling, but it's OK that the company goes bankrupt, just as long as we don't question what's wrong.)

I can just tell that this "personal skills" requirement is what happened with the contractors that hired to build the FBI's virtual case file....and maybe, Enron and Aurthur Anderson. and what about those credit card companies that lose the personal data, or JetBlue reservation system that couldn't handle surge in traffic from a snow storm pileup.....Well, there is certainly not enough room to name even a few of those I.T. failures, BUT as you can see, that 70% I.T. failure rate is pretty low, IMO.

Some people just have to learn the hard way, if that.

Post #411520
Posted Wednesday, October 17, 2007 1:43 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, June 9, 2014 6:02 AM
Points: 2,674, Visits: 697
I'd hate this to end up as a slanging match but the main reason many systems work poorly is the apalling design and implementation of third party applications - usually the more expensive it is the worse it is - and because it's expensive big companies have to buy them. If we can train developers properly to understand set theory and database technology we might have better applications. But it keeps me in work as I spend most of my time tuning poorly performing systems.
Just to throw a spanner into the dbcc arena - you must use some dbcc commands otherwise you cannot check the integrity of your database and up to sql 2005 there were some excellent dbcc commands used to diagnose performance issues , umsstats, memstatus, traceon, opentran to mention a few - so if you've never used a dbcc command you're unlikely to be the type of DBA I'd employ - course if you're just a button pushing DBA who never strays beyond the GUI then you'll likely not understand what I'm writing - and this is part of the problem I think - the job title of DBA has become diluted with not any sensible way to differentiate from the developer who's looked after a single server in a small company to a person who manages several hundred 24x7 a "always on" systems along with DR, BCP etc. etc.


The GrumpyOldDBA
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Post #411578
Posted Wednesday, October 17, 2007 6:48 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, March 4, 2008 6:53 AM
Points: 2, Visits: 12
Jack Corbett (10/15/2007)
I enjoyed reading the article as I use articles like this to help me determine what SQL Server skills I am missing that I should have. I also think this article relates to the recent editorial, The General. SQL Server has become so complex that it is difficult to answer all the questions about DBCC commands, etc.. and know all about Windows clustering, RAID, etc.. The tools for SQL Server have gotten better also, so you can maintain a SQL Server without using DBCC commands directly. When I am in an interview I am upfront that there is more I don't know about SQL Server than I do know, but I know where to go to find the answers I need to a problem, whether BOL, google, or SSC. I can do the Day to tasks security, backups, restores, etc.. and in 8 years of working with SQL Server I have never had to do a point in time restore and have only once had to restore a failed server. It was a long night, but no data was lost because we had a good backup plan in place. If I were hiring a DBA, or any IT staff, the first thing I want to see is someone who know they don't know it all, but know where to go to find the answer. Just don't use QotD in the interview. Why would I know that stored procedures can accept up to 2100 parameters!


I agree totally. I have been a DB2 Applications DBA and a SQL Server DBA for 7 years now and there is just so much stuff that it can get a bit intimidating sometimes ( CLR hosting, SSAS. SSIS, SSRS, SMO programming, SQLCmd vs. OSQL) to mention a few. How often is one going to be involved in setting-up a cluster, or perform database mirroring? What drives all this in the real world is the kind of business, the structure of the organization, the budget and the extent of data currency that the client can live with in a true disaster. This is often defined in your SLA with the client. Not all applications require immediate failover. In large corporations, with a myriad of centralized and renegade applications, that is just not feasible. A true DBA will make the best of any situation. In a perfect world, third party products should support Windows authentication and support multiple SQL instances but that is not always the case. To my mind, the ultimate interview question for a DBA would be : given this environment, and this problem, how would you go about finding a solution?
Post #411695
« Prev Topic | Next Topic »

Add to briefcase «««23456»»

Permissions Expand / Collapse