InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 21 May 2013 18:30:59 GMT20http://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxheh forest management? :)Mon, 16 Feb 2009 14:51:48 GMTmikes067http://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxSQL server has become such a robust compliment of tools that it is hard to say exactly what a SQL server DBA really is. I don't think the author was denying that, but simply stating that before posting, employers should assess their needs - and determine the type of DBA they need.I've recently been pushed to my max trying to develop an ETL process in SSIS. And I'm realizing that SSIS could be a speciality by itself - you could hire an ETL DBA that may never run a backup script - ever! Same goes for SSAS, SSRS ... But I think the point still stands that employers try too hard to find the perfect jack of all trades. I saw a DBA posting today asking for 5 yrs of Exchange administration, web programming, VLAN admin, IDS, C#... If you hired a DBA and set them to do hefty Exchange administration and intrusion detection, their DBA skills would deteriorate within a year as they are forced to implement email filters...Sun, 05 Oct 2008 17:37:52 GMTbnordberghttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxGreetings,This has been an interesting read for me, as I am a newcomer to SQL Server (1 year), having been an application developer for database-centric applications with my company since 1994. It appears that there definitely are different perspectives on what a "DBA" is. Some seem to focus primarily on the pure "admin" stuff - installation, configuration, backup/restore, performance, security, etc., and asking rather specific questions on interviewees on those topics. Some include using SSIS, SSRS, SSAS. A few mentioned database design, normalization, stored procedures, views, etc.I can understand that in an organization that primarily uses purchased software, that a "DBA" would be basically focused on what I listed as the admin stuff, with possibly some SSIS, etc. to interconnect data between software systems. In organizations that do application/database development in-house, the "admin" stuff is important, but there is also more need for database design skills. What you can do with SQL Server is so broad, that I am thinking that few companies use it to its full potential (probably b/c they don't need to.) The types of questions asked or skills focused on in interviewing candidates, also should vary based on what the company actually does with SQL Server.In our company, I am being phased in to be our first full-time DBA, but the admin stuff is only a portion of what I do. I would not (at least currently) get some of the listed interview questions right (without a few minutes to look up the answers on the web.) I would not be the best candidate for those looking for a DBA to fully administer SQL Servers running only packaged software.But, I do think my role fully qualifies as a DBA. My focus areas in SQL Server are simply balanced differently. I am doing the admin tasks - but since we have a systems adminstrator, our roles overlap. For instance, I have defined the setup configurations that will be used for all of our SQL Server installations, while our system administrator sets up the virtual servers, installs the software and guarantees the server environment. I schedule backups, but primarily so that the systems adminstrator has an offline database copy to backup as part of his overall system backups (which includes user documents and files, e-mail systems, etc.) We both monitor various aspects of performance, activity, and error logging. I oversee several SQL Servers on which packaged software is running.However, much of my time is spent on database design and development. This aspect of SQL Server didn't seem adequately represented in the discussion. We write in-house a significant portion of the software used by our company. I develop the database design, make sure it's all normalized properly, set up the databases, tables, indexes, and relationships. I construct the SSIS packages to properly import data from our existing non-SQL Server data files. I construct the stored procedures and views by which the application developers and users will access the database, and set up the database roles for such access. I also develop the Visual FoxPro or .NET interfaces to simplify developers' access to the stored procedures. I write the SSIS tasks to perform nightly data posts, generate reports, etc. Understanding the data and overseeing the accuracy of what comes out or goes into the database, is a big part of what I do.But, as of yet, I don't do anything with SSAS, I don't even know much about it. I don't yet do replication, I don't do log shipping or have mirrored databases. I haven't explored Notification Services or Service Broker. I am learning, but I'll probably never use some of SQL Server's features. SQL Server is BIG!So, what am I saying? I guess, that "DBA" can encompass a lot of things, with varying aspects being more or less important, depending on the structure of your IT department and what exactly SQL Server is used for within your company. Although admin functions are vital, I wanted to flesh out some of the other aspects that can also be important.Best wishes,RandyFri, 19 Sep 2008 08:57:39 GMTrandy.witthttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxHello,I've been working in IT since 1993 and as a SQL Server DBA since 2001.I got my first Microsoft Certification in 2002, MCDBA in 2004, MCTS SQL2k5 in 2006, and so on. But I agree that certifications is not enough. I am recognized as a Senior DBA in my region (Brazil, São Paulo), but I don't think so, because I know that I need to learn more and get real experience about clustering, SAN, etc.I want to be recognized as a true DBA and not just a tourist. Professionals that have been done just basics tasks are only surviving, and we need to looking for our evolution as a DBA, developers, System Administrators, and so on.Sun, 21 Oct 2007 14:38:11 GMTAlex Rosahttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]Jack Corbett (10/15/2007)[/b][hr]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!:w00t:[/quote]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?Wed, 17 Oct 2007 06:48:00 GMTRaymond Pehttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxI'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.Wed, 17 Oct 2007 01:43:23 GMTcolin.Leversuch-Robertshttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote]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,[/quote]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.Tue, 16 Oct 2007 18:12:43 GMTrhathttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]rhat (10/16/2007)[/b][hr][quote] 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![/quote]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!!![/quote]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,Tue, 16 Oct 2007 15:46:37 GMTnoeldhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxMan 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.Tue, 16 Oct 2007 14:01:08 GMTAnders Pedersenhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote] 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![/quote]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!!!Tue, 16 Oct 2007 12:38:16 GMTrhathttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxI'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.Tue, 16 Oct 2007 11:44:25 GMTedu-dbahttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxWith 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.Tue, 16 Oct 2007 09:38:43 GMTMichael D. Foxhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxHaving 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.Tue, 16 Oct 2007 08:05:18 GMTbnordberghttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]John Aherne (10/15/2007)[/b][hr]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?[/quote]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).Tue, 16 Oct 2007 05:58:59 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxI 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;CodexenaTue, 16 Oct 2007 04:42:08 GMTLori Carrighttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxconsider 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.Tue, 16 Oct 2007 02:09:47 GMTcolin.Leversuch-Robertshttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxThis 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.Mon, 15 Oct 2007 23:44:27 GMTClaude Lewishttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxA 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 luckMon, 15 Oct 2007 20:43:40 GMTedu-dbahttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxYour 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?Mon, 15 Oct 2007 17:43:13 GMTMaurice D Baileyhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]rhat (10/15/2007)[/b][hr][quote][b]R L Reid (10/15/2007)[/b][hr]Posts: 1, huh? It's obviously a troll, but I'll bite.[quote][b]rhat (10/15/2007)[/b][hr]DBCC commands are wild goose chases when a siimple restore of backup is what's needed and needed ASAP.[/quote]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).[b]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......[/b]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.[b]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.[/b]But of course, DBCC, DTS and JOB SECURITY seem to go hand in hand:D[/quote]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!Mon, 15 Oct 2007 16:31:37 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]R L Reid (10/15/2007)[/b][hr]Posts: 1, huh? It's obviously a troll, but I'll bite.[quote][b]rhat (10/15/2007)[/b][hr]DBCC commands are wild goose chases when a siimple restore of backup is what's needed and needed ASAP.[/quote]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).[b]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......[/b]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.[b]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.[/b]But of course, DBCC, DTS and JOB SECURITY seem to go hand in hand:DMon, 15 Oct 2007 16:07:58 GMTrhathttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote] (not to mention the failure to realize how large organizations do have dedicated SANs teams) [/quote]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.Mon, 15 Oct 2007 14:54:53 GMTedu-dbahttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote]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: [b]IT DEPENDS![/b][/quote]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 [b]SQL Server[/b] 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.Mon, 15 Oct 2007 14:35:08 GMT Jack Corbetthttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxwow. 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?Mon, 15 Oct 2007 14:09:19 GMTJohn Ahernehttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]Jack Corbett (10/15/2007)[/b][hr]I would actually agree with Colin on this one. You need to know that, yes you can have a non-clustered primary key and, depending on what your primary key is, you may want it to be non-clustered. [/quote]Fair enough. I actually did so with Sybase 11/12 when there were ever-increasing true primary keys,because those got badly unbalanced. By clustering on something more random (but non-unique), you didn't end up rebuilding indices as often.When I moved those tables to SQL Server, I found we did better to go bad to using the unique identifier as the primary key usually - and it just feels better. A little research showed that in 2005, the internals people dealt with the fact that ever-increasing primary keys were common, and they don't end up so out of balance so easily. I like it when the database engine lets you do things the "right" way and not force you to munge it just to get the performance. That said:[quote][b]Jack Corbett (10/15/2007)[/b][hr]This is a SQL Server basic that someone with any SQL Server DBA experience should know.[/quote]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: [b]IT DEPENDS![/b]Mon, 15 Oct 2007 14:09:12 GMTRoger L Reidhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]and what's a bookmark lookup?[/quote]Interesting - I just learned something. Bookmark lookup? Sometimes in SQL Server they come up with new names. My guess was it was index coverage - maybe I'd have gotten partial credit. I just looked it up - an interesting feature, and I realize I've seen this in action on queries that surprised me with their speed.Another example of how MS is getting a LOT of things right in database engines these days.Mon, 15 Oct 2007 13:53:52 GMTRoger L Reidhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]R L Reid (10/15/2007)[/b][hr][quote][b]colin Leversuch-Roberts (10/15/2007)[/b][hr] non clustered PK, I'd say 75% of candidates have got this wrong - .[/quote]How about "Gee, I'm not sure. I don't see a good reason to do it and I've never tried it, but since we're talking about MS SQL Server, for all I know it was added as a feature in the last SP and I didn't notice - and since they've dropped calling themselves 'relational' even though they are as much or more so than Oracle or Access, it may be part of the feature expansion".After all, sometimes all you need is a bag, not a relation.I'd feel an understanding of the concept and the issues would be more important than knowing the exact right answer at this time (for which I'd say "I can probably find out in uner 60 seconds if you give me a web browser or my 5 favorite books - or a system to try it and see).[/quote]I would actually agree with Colin on this one. You need to know that, yes you can have a non-clustered primary key and, depending on what your primary key is, you may want it to be non-clustered. In instances where you are using a surrogate key (in SQL Server most likely an Identity column, let's not argue their use or value here) it may not be a good candidate for clustering. This is definitely something the DBA needs to know as the DBA is responsible for design and performance tuning, not the developer. This is a SQL Server basic that someone with any SQL Server DBA experience should know.Mon, 15 Oct 2007 13:46:48 GMT Jack Corbetthttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxPosts: 1, huh? It's obviously a troll, but I'll bite.[quote][b]rhat (10/15/2007)[/b][hr]DBCC commands are wild goose chases when a siimple restore of backup is what's needed and needed ASAP.[/quote]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).[quote][b]rhat (10/15/2007)[/b][hr]Any DBA that thinks they need DBCC commands spends more time on DBA CERTIFICATION TESTING instead of producing reliable databases in a production environment that doesn't need constant maintenance. (By the way, that what SQL Server is designed for, to ELIMINATE this MAINTENANCE and HENCE the use of DBCC commands in the first place.)[/quote]One appeal for me of moving from Sybase to SQL Server (Post SP3 SQL Server 2000 on Windows Server 2003 post SP1) was the far better maintanence tools. Good thing too, because unlike Sybase - it NEEDS them![quote][b]rhat (10/15/2007)[/b][hr]And by the way, DTS is total crap. If you are a DBA that says his shop uses it, it means they are ANTIQUATED and have to constantly support some legacy app with some GUI interface when t-SQL and SQL Server Agent will be far more powerful and more easily diagnosed.[/quote]I don't use that modern DTS stuff yet. For the sake of interoperability, reusabililty, and scriptability, I do most of the ETL with Perl and FreeTDS and the Sybase(sic) :: DBI modules. Sometimes I drop into C and straight to dblib (FreeTDS dblib of course). I do look forward someday to using SSIS.See, we do have ANTIQUATED LEGACY APP. A very well designed client database that - because those who designed it understood relational design and applied it as best they could - has been quite extensible over the decades; and I am now porting the backend from Sybase to SQL Server. The front end isn't changing. Little VT200 terminals displayed in a Windows desktop! Or, view the reports on the SharePoint site.[quote][b]rhat (10/15/2007)[/b][hr]Bottom line, t-sql will have a CLEANER import and less hassle. i.e. it's all in the code.[/quote]Bottom line, S.Q.L. is a lousy DML - but we're stuck with it. I'd love to ask an applicant "what do you think is wrong with S.Q.L." - not even because the exact answer matters, just to see if they know the difference between "SQL" and "database". But honestly, I'm not sure how relevant it is anymore.Mon, 15 Oct 2007 13:41:23 GMTRoger L Reidhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]colin Leversuch-Roberts (10/15/2007)[/b][hr] non clustered PK, I'd say 75% of candidates have got this wrong - .[/quote]How about "Gee, I'm not sure. I don't see a good reason to do it and I've never tried it, but since we're talking about MS SQL Server, for all I know it was added as a feature in the last SP and I didn't notice - and since they've dropped calling themselves 'relational' even though they are as much or more so than Oracle or Access, it may be part of the feature expansion".After all, sometimes all you need is a bag, not a relation.I'd feel an understanding of the concept and the issues would be more important than knowing the exact right answer at this time (for which I'd say "I can probably find out in uner 60 seconds if you give me a web browser or my 5 favorite books - or a system to try it and see).Mon, 15 Oct 2007 13:27:29 GMTRoger L Reidhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxYou are right on the mark SSCommitted. The breadth and depth of knowledge that the author's DBA is supposed to have mastered is almost ridiculous. If someone has this "ideal skill set", I doubt an organization would have the budget to pay for it. I can see it now- the candidate must have all of these areas of expertise, and the company will pay a whopping 85K a year!Also, the author does not seem to be aware of the fairly well established practice of differentiating between DBAs and database developers (not to mention the failure to realize how large organizations do have dedicated SANs teams). I returned last month from the SQL Pass conference. Almost all of the experts in SQL Server were saying that the product is so big, so complicated that no one person can really be an expert in it. Finally, I got a kick out of how using SQL Server 2005 is so easy- just clicking buttons and things are done. This comment really made me realize that the author is just trying to be provocative (I hope).Mon, 15 Oct 2007 12:53:30 GMTBen Orlowitzhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]Grant Fritchey (10/15/2007)Not the strict textbook answer, but WAY closer than the drivel I'm usually fed. When can you start?[/quote]Can I be a part-time remote DBA? I just moved from NH to FL and don't have any plans on moving back north. I have read up on Bookmark Lookups several times, but for some reason I cannot remember specifics. I do know to try to avoid them.Out of all your questions that is the one I would struggle most with. Although giving a concise answer on what is a Deadlock would be tough, too. I understand the concept and know they are different from a block (which happen all the time), but to give a good explanation would be difficult for me. When I say a good explanation, I mean one my non-technical wife would be able to understand.Mon, 15 Oct 2007 12:45:41 GMT Jack Corbetthttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote][b]Jack Corbett (10/15/2007)[/b][hr[quote]and what's a bookmark lookup?".[/quote]I have to admit to not being confident on this one. I would define it by saying it occurs when SQL uses an index that doe snot include all the columns requested, but has to then get the row id to return the other columns. I do know that the fix is to return only the columns you need and to, if possible, create a covering index. BTW-I just learned about the Include clause on the create index statement last week. [/quote]Not the strict textbook answer, but WAY closer than the drivel I'm usually fed. When can you start?Mon, 15 Oct 2007 11:51:30 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxMaybe it's Rhode Island? But we ask these questions:What's the difference between clustered & non-clustered indexWhat's the difference between blocks and deadlocksWhat kind of recovery models does a database have (and we'll give hints on this one)What kind of backups are available (and yes, we'll give hints on this one too)What's the difference between UNION & UNION ALLAssuming they pass these, in the phone interview was how they go about performance tuning an unknown situation on a server, and what they know about query hints.That's it. Most of this information hasn't changed radically since SQL Server 6.5, so anyone with any degree of real experience should be able to answer the stuff... I've got sheets & sheets of interviews with wrong answers on most of those questions.Mon, 15 Oct 2007 11:49:24 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspx[quote]I've seen many knocked out with the "how do you return the identity value (post 2000)? [/quote]I guess that would depend on what identity value you are looking for? The one created by that session on the specific table (Scope_Identity), the last one created by that session (@@Identity), or the last one created for that table (Ident_Current('table'))?[quote]and what's a bookmark lookup?".[/quote]I have to admit to not being confident on this one. I would define it by saying it occurs when SQL uses an index that doe snot include all the columns requested, but has to then get the row id to return the other columns. I do know that the fix is to return only the columns you need and to, if possible, create a covering index. BTW-I just learned about the Include clause on the create index statement last week. Mon, 15 Oct 2007 11:47:26 GMT Jack Corbetthttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxWow, Grant, you're getting some good candidates there. I've seen many knocked out with the "how do you return the identity value (post 2000)? and what's a bookmark lookup?".What's more amazing is that many of these candidates were actually DBAs for some other company. Makes me appreciate how resilient and tolerant SQL Server can be.Mon, 15 Oct 2007 10:58:14 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxGrant I do so agree, the lack of basic stuff is truly frightening and even more so when you look to see where they work and how much they get paid!! I now have 10 basic questions for the agent to ask over the phone, the candiadte may drop maybe two answers otherwise no further.You should try asking if you can have a non clustered PK, I'd say 75% of candidates have got this wrong - this is fail level for anyone reading - I'd never progress a candidate further who got this wrong.Mon, 15 Oct 2007 10:26:51 GMTcolin.Leversuch-Robertshttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxI've been involved with hiring DBA's where I work for the last three years. It's been a frightful experience. We eliminate most candidates in a ten minute phone call. While I hate trivia tests, I think knowing the difference between a clustered and a non-clustered index or the difference between blocks, locsk and deadlocks are DBA 101 level stuff and not trivia. We knock out more people with those two questions. It's scary the lack of depth of knowledge in most of the candidates. As to college degrees... It matters when the person has less than five years of experience in the industry. If they've been working for 5+ years and can demonstrate 5+ years of knowledge, who cares where or if they went to Podunk U and majored in underwater basket weaving. I have almost 20 years experience in IT now and I'm a college drop-out. I don't want a sheepskin, I want an experienced, knowledgeable human being.Mon, 15 Oct 2007 10:05:51 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxGetting experience is always the key. But I see many people doing application support of some system, with a database backend, yet they do no SQL with it. For example, if I was a network engineer curious about SQL, I would get a trial license of SQL server, import a the CDB file from a router and start writing queries against it. Look for trends in time, dropped packets, problems on the network ... Maybe you would even find something that you need to adjust on your network. Impress your boss with a graph of trends on the network. I started out many years ago doing data entry, there were no reports on the system and nobody to do them, so I learned OS-400 query. I agree I don't want someone to rattle off DBCC commands - but I would want them to know about books online... Knowing where to go to get answers is extermely valuable and I expect to get responses like "I don't know the answer to that question, but I would look it up on BOL".If your relying solely on the GUI to administer your servers, your missing out on many functions. I've had servers running so badly that the GUI will not function, if that was all I knew I would never have been able to kill any process that were bringing the server down.The issue of too much experience and in essence pricing yourself out of a position is a problem. I don't know the answer to that issue - start turning down raises so you remain competitive? Or start lowering your salary requirements - or maybe accept that you make a lot and need to enjoy the current diggs?Mon, 15 Oct 2007 09:14:56 GMTedu-dbahttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxedu-dba - You specifically mentioned looking for experience. Sometimes, experience can be a problem.I have 25 years experience with the relational database lineage that MS SQL Server is part of (Britton Lee IDM, Sybase, MS SQL Server). I have a good job, but was interested in exploring other possibilities.I found some fascinating positions available - especially in the field of integrating diverse datasources across alliances of companies without impacting the underlying systems or exposing data inappropriately.However, with 25 years experience, the problem becomes that they've budgeted for someone with 10 years experience. If they find the RIGHT person with 10 years experience, they've made a good move. For the right job, the exact salary isn't an issue - but I can't take a 40% pay cut. That's when I understood that my current pay was a reflection of the fact that my experience is at one company - since I know the company, I can literally do the work of 3 or 4 people. Were I to take a new position, I'd be doing the work of one person - and as good as that person would need to be, s/he's not going to make as much.Obviously, the choice is up to me. I'm happy at my current position and they seem happy with me. I'm not suggesting anything "ought to be done" about this - it doesn't make business sense. If I really want to change, I can sell my house and move an hour farther north.Mon, 15 Oct 2007 09:02:39 GMTRoger L Reidhttp://www.sqlservercentral.com/Forums/Topic410689-1001-1.aspxJohn - I so agree - trouble was the post wasn't ironic enough to be properly funny!!btw. I'd never ask the format of a dbcc command in an interview and would take a dim view of anyone who asked me!Getting experience? Yeah it's a problem, I've tried to tell clients they should consider looking at training up people so that they have a chance of having skills on hand, sadly mostly they think only of promoting someone from another area of iT which often does not work as skills in one area don't usually cross to another, and dba skills are somewhat of an art form I sometimes think.Mon, 15 Oct 2007 08:53:39 GMTcolin.Leversuch-Roberts