Greetings,

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,

Randy