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 Monday, October 15, 2007 2:09 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, October 22, 2007 9:18 AM
Points: 7, Visits: 11
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?
Post #411017
Posted Monday, October 15, 2007 2:35 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 10:01 AM
Points: 10,282, Visits: 13,266
Yes. But it actually brings us to a different point - that we can't have one set of ideals for the DBA candidate. No doubt each of us needs something different from such a position. You may need someone who can do a textbook job of admining one platform for the next 4 years. Or you may need someone who can take full charge of Database Services for your firm or department - who may from time to time not offhand know this or that implementation detail, but is a "professional learner" who can keep up as the changes happen, as hardware and software and IO changes tilt practice in one direction or another?

For example - not just know the answer to "can you" on your question, but recognizes when to change the indices to do so - and then when to change them back.

Obviously, not either/or. Despite all my experience with similar platforms, when I first started working with SQL Server I would have been a darned poor candidate for any pure SQL Server shop that needed someone to hit the ground running on a list of issues - but the background I have meant I knew how to get good at it pretty quickly. But that's the standard DBA/DBE answer, isn't it: IT DEPENDS!


You are right you would not have been a good candidate for a SQL Server DBA position originally, just like I would not be a good candidate for a Sybase or Oracle DBA position. The whole premise of the article is that you are looking for a SQL Server DBA and these are questions a SQL Server DBA should be able to answer.

I think that anyone who is in the IT field should be a "professional learner" and if they aren't they should move to another field. I mean SQL Server 2008 is coming fast and I am still catching up with 2005, so I need to know where to go to find the answers, but I should already know the SQL Server DBA basics.




Jack Corbett

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming

Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Post #411022
Posted Monday, October 15, 2007 2:54 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, October 15, 2014 11:38 AM
Points: 6, Visits: 189
(not to mention the failure to realize how large organizations do have dedicated SANs teams)


Actually we have an established 7 person SAN team. And just last week, I had to work with them for many days laying out and establishing a new multi-cluster system. DBA's don't need to be able to administer the SAN, but we do need to understand I/O. And this means being able to talk the talk with the SAN team. As SAN's replace internal RAID arrays, it will be more important to at least know what a LUN is and how your disks are configured in the SAN, regardless if you know how to administer the SAN itself.
Post #411028
Posted Monday, October 15, 2007 4:07 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
R L Reid (10/15/2007)
Posts: 1, huh? It's obviously a troll, but I'll bite.
[quote]rhat (10/15/2007)

DBCC commands are wild goose chases when a siimple restore of backup is what's needed and needed ASAP.


Yes, let's just throw away the past 19 hours worth of data and overwrite. (Knock wood - I don't have issues like this because of the many layers of replication we use...but when it used to happen, there was usually discussion about how long to work on recovery before bailing out, based on business needs).


A *PROPERLY* designed system doesn't find out problems 19 hours later. A good system knows instantly, in seconds, when an error has occurred, Windows or Web, and sends an alert message to the admin and/or developer via e-mail, text message, etc......

ALSO, a properly designed database and application doesn't keep sticking bad data in the database and not let those users not know that something wrong has happening to begin with. OR, for that matter keep letting them work with a bad database for 19 hours!!!!

Secondly, it's best to go to the last known good backup just for reliability reasons. Just because you got a DBA that knows how to use DBCC doesn't' mean the database will be 100% normal again. And it could take the DBA days, weeks to figure it out and get all the errors and bad data out regardless of expertise and experience. Errors that require DBCC almost always don't just happen. There is a reason for it and it's usually BAD. And after that, there still could be problems.....i.e. wild goose chase.

Thirdly, who is to say that those 19 hours of data is GOOD data to begin with? How can one be 100% sure without rechecking it with the user who put it in there?

Four, restore is *like* using the last know good Windows OS image or the *appropriate" backup data instead of trying to get the virus out or running repair commands or wizards. In the real world, we get fast enough hardware to get this done ASAP.

Five, All that money spent on some clueless DBA that's an expert in DBCC could have been spent on faster hardware and backups to complete the job a lot faster in the end. Not to mention make the system as a whole more reliable.

But of course, DBCC, DTS and JOB SECURITY seem to go hand in hand:D





Post #411044
Posted Monday, October 15, 2007 4:31 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 13,872, Visits: 9,596
rhat (10/15/2007)
R L Reid (10/15/2007)
Posts: 1, huh? It's obviously a troll, but I'll bite.
[quote]rhat (10/15/2007)

DBCC commands are wild goose chases when a siimple restore of backup is what's needed and needed ASAP.


Yes, let's just throw away the past 19 hours worth of data and overwrite. (Knock wood - I don't have issues like this because of the many layers of replication we use...but when it used to happen, there was usually discussion about how long to work on recovery before bailing out, based on business needs).


A *PROPERLY* designed system doesn't find out problems 19 hours later. A good system knows instantly, in seconds, when an error has occurred, Windows or Web, and sends an alert message to the admin and/or developer via e-mail, text message, etc......

ALSO, a properly designed database and application doesn't keep sticking bad data in the database and not let those users not know that something wrong has happening to begin with. OR, for that matter keep letting them work with a bad database for 19 hours!!!!

Secondly, it's best to go to the last known good backup just for reliability reasons. Just because you got a DBA that knows how to use DBCC doesn't' mean the database will be 100% normal again. And it could take the DBA days, weeks to figure it out and get all the errors and bad data out regardless of expertise and experience. Errors that require DBCC almost always don't just happen. There is a reason for it and it's usually BAD. And after that, there still could be problems.....i.e. wild goose chase.

Thirdly, who is to say that those 19 hours of data is GOOD data to begin with? How can one be 100% sure without rechecking it with the user who put it in there?

Four, restore is *like* using the last know good Windows OS image or the *appropriate" backup data instead of trying to get the virus out or running repair commands or wizards. In the real world, we get fast enough hardware to get this done ASAP.

Five, All that money spent on some clueless DBA that's an expert in DBCC could have been spent on faster hardware and backups to complete the job a lot faster in the end. Not to mention make the system as a whole more reliable.

But of course, DBCC, DTS and JOB SECURITY seem to go hand in hand:D


As far as DTS/SSIS goes, yes, you can use T-SQL to accomplish many of the same tasks, but a well-built DTS package can accomplish repeated ETL tasks more efficiently, assuming you are moving data from things like flat files (.txt or .xls, for example) into complex relational structures. The ability to map different transformations/actions to different results of actions, using a flow-chart style structure, combined with easily set up things like ForEach loops, complex error-handling and alerts, and ease to maintain, which can be moved from server to server simply by changing a single connection string, does have its advantages.

I've used both solutions (pure T-SQL stored procs and SSIS) and there are advantages and disadvantages to each. The choice isn't about job security (the company I worked for went out of business, and in a matter of days, the biggest competitor wanted me to take over the same job, but for them; I've got all the job security I could ever want). The choice is about effectiveness and efficiency and ROI (always ROI).

Just in the last 2 weeks, I've taken tasks that were taking man-days of labor, and using SSIS, turned them into "drop an Excel file in this folder and the server will do the rest". One went from 2 people working full time for 4 days, to under 2 minutes. With SSIS, it took me about 2 hours to set the whole thing up. And it will be used dozens of times in the coming months. Setting it all up in T-SQL would have taken much, much longer, and would be much more difficult to port to other servers.

Another task, a year or two ago, I set up in T-SQL for similar results, but it was cleaner to do that one without DTS. Simple .txt bulk import and then a bunch of set-based parsing and transformations.

On the other hand, I completely agree with you about memorizing rarely used DBCC commands in SQL 2000/2005. 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!


- Gus "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
Post #411056
Posted Monday, October 15, 2007 5:43 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, September 30, 2014 7:59 AM
Points: 28, Visits: 43
Your article was very good.

I am newbie when it comes to being a DBA. My experience of databases has been extracts from Oracle into MS Access for reporting purpose. My strengths are more in reporting than actual DBA work, but would like to be more proficient at being a DBA. I have been on my current job for two years maintaining two production databases. The vendors have setup and configured the databases to backup nightly and the net work manager performs further backups on the total network. It is fortunate that I am able to learn on the job but have reach a fork in the road. I started with SQL Server 2K but now in the process of migrating databases to SQL Server 2K5. For now I am relying the vendor to keep the database running, but would like to move this responsibility more to myself. I understand SQL but having a hard of knowing where to begin as being a DBA for SQL Server.

What advice does anyone have?
Post #411070
Posted Monday, October 15, 2007 8:43 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, October 15, 2014 11:38 AM
Points: 6, Visits: 189
A reporting role is a great starting point for a DBA. Probably time for more education -take (or do a self paced) SQL admin class. See if you can get an ER diagram from the vendor to start to understand structures. It will take some time, but once you start showing your merit, talk to your supervisor about taking over more bits of the DBA role. See if there are other things needed from the system or other holes (reporting services, analysis services ...) that you would work on. I learned a ton going through vendor scripts and using their programmers as mentors (just don't dink with their code!).
Good luck
Post #411095
Posted Monday, October 15, 2007 11:44 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, April 28, 2010 2:02 PM
Points: 1, Visits: 6
This was indeed a good article, but I think many hiring managers have wants that are not well targeted. There are job descriptions out there asking candidates to have five years of SSIS experience. Unless you were beta testing 2005 in the Microsoft Labs, thats impossible.

I do think that the top tier DBA skillsets are not offering much seperation between .NET, Web development, security and SQL Skills, so I think I have had my best luck where I can show myself as a Microsoft engineer who has focused on SQL development and administration. Other than that, if your system is setup and managed properly, the DBA mostly can focus on occasional performance tuning, data integrity, and reporting reqs.

Candidates will say they know anything to get hired. I feel like the best measure of someone's IT skills is how they handle it when they DONT know something.
Post #411122
Posted Tuesday, October 16, 2007 2:09 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, June 9, 2014 6:02 AM
Points: 2,674, Visits: 697
consider that I work for blue chips and I assist in recruiting production DBA's. The roles always ask for performance tuning and diagnostic skills, if you don't know what a bookmark lookup is or if a PK can be clustered or not then you will certainly not get hired. As I say I don't ask about syntax of dbcc but I might expect a dba to know how to extract cpu/worker thread information , if not the exact commands where it can be, likewise if the value of page life expectancy should be high or low ( another good question many get wrong).
However if a candidate writes in their cv that they tuned the disk subsystem to improve performance then they better sure as hell know about random and sequential io, throughput , spindles and raid performance. I'd expect any dba to know the difference between raid 0, 10 and 5.
The fact that the product is so good, SQL Server, is perhaps the reason that to a certain extent the quality of some dba candidates is disappointing.
btw the reasoning behind the PK question is that if you've only ever used the GUI to manage and work with SQL Server then you'd not know you can create a non clustered PK.


The GrumpyOldDBA
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Post #411151
Posted Tuesday, October 16, 2007 4:42 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, June 30, 2009 9:30 AM
Points: 1, Visits: 60
I liked the author's approach except there are also some other factors that should be considered as other replies have alluded to. Any Database Administrator must also consider the impact of any given logical model to the physical model of the database. This can indeed affect performance and in turn other problems when business units have to wait several minutes to get one simple report. A DBA may have all the DBCC commands memorized but may not understand the impact of having both the log and data files on the same disk array. Also in terms of normalization a DBA worth their salt must also know when to use denormalization and understand the two models of data warehousing and when to apply these models.

I myself have worked many years in the Database Administration field and have noted that these days most of the organizations I have worked for or have visited the developers are now picking up the task of DBA as well. These shops are mostly MS SQL based however opposed to Oracle and DB2 shops where the DBA's are separated from the developers which I personally prefer. The current organization I work with identified the developers as the DBA's. Thus to find a pure MS SQL DBA which duties is purely a DBA may be limited. As for myself, I am trying to move on and focus on being more involved with the business units to better leverage IT to accomplish organizational short and long term goals.

As a side note, I am a Senior Software Engineer who is also one of three DBA's for the shop I work within. So for the folks looking for a pure MS SQL DBA I say good luck. They may indeed be out there, but I suspect they are wearing more than one hat these days. I myself have just finished an SQL 2000 to SQL 2005 conversation which was an experience all into itself I must say. None the less the above are my own view and may not apply to all shops.

Thank you;

Codexena
Post #411189
« Prev Topic | Next Topic »

Add to briefcase «««23456»»»

Permissions Expand / Collapse