June 25, 2010 at 7:00 am
I do think some companies are of the belief that the term DBA is a catch-all and even more worrisome that if you know SQL, well hell - you must be a DBA. To me the issue is the term and something we as professionals must find a way to change. The ‘A’ of DBA as we all know is Administrator and this letter is the reason I have pressed hard not only at my present position but also during phone screens for other companies as well as when presenting at professional events and other clients, to use the term Database Engineer; within this engineering discipline there are specialist who focus on things such as: performance tuning, BI, ETL, etc… not to say that their skills do not cross several boundaries but we are not "jacks of all trades" within this arena, it is not possible anymore as we have moved far from the days of SQL 6.5 and Oracle 7, et.al. While I moved into this field via the “Accidental DBA” career ladder and while I feel it is still an avenue that does provide access to the profession at some point you must determine where your interests lie and commit to them.
That being said - yes this is still a phenomenal career with a plethora of opportunities but the delusion of a catch-all is diluting our effectiveness in some arenas and sadly there are many of us who will then have to go in and clean up the mess left by "some" of these accidental DBA's. Well at least that provides additional job security but at some cost to our collective sanity.
I will now step down off my soap box.
June 25, 2010 at 7:36 am
The company I work for has installed and maintains over 150 instances. That number will probably double in 2 - 3 years. Our customers are small businesses, anywhere from 1 to 200 users. I don't think a single one of them has or really needs a DBA on staff. However, for maintenance purposes alone, I see opportunity for DBA's working as independent contractors, teaming up with Window's networking professionals, helping customers like ours maintain their information systems. I see the proliferation of SQL Server instances in the small business market gaining momentum in the coming years, much faster than the proliferation of DBA's.
June 25, 2010 at 7:39 am
Are more companies or departments forgoing the need for a dedicated DBA?
I work for a large company and I'd say no. All our really big systems have dedicated DBAs. Our little group manages a few big databases so, as many others here have, I've become the accidental DBA. I program, write ETL, write documents, assist users and so on. We "borrow" a dedicated database guy from another group from time to time and judging by our conversions, we're doing things right. Either that or he's being kind :hehe:
Ken
June 25, 2010 at 7:43 am
For the enterprise level application I support we "require" all clients to have a DBA that manages their servers. There are a lot of the smaller shops that don't but the majority have someone that fills the role. Some even have DBA teams. Internally, we have two dedicated Database Developers on our L3 Support team which handles bug fixes. Most of the new development is .Net developers but there are several other dedicated DBAs and some of the Dev Leads are comfortable in a mixed role although most don't have great DBA skills. Our Architecture team has a dedicated DBA and one or two other people that aren't dedicated but are rather skilled in SQL. Add onto that DBAs that work with other products we develop and at least one that I'm aware of for internal support and I would say that it's a role that my company recognizes as being important.
Which isn't to say that we don't have our share of accidental DBAs or poorly managed systems. One of the tools we use has an Oracle back end and because the team that works with it doesn't have experience in that it's more cross your fingers and hope nothing goes majorly wrong.
June 25, 2010 at 7:52 am
I recently made a jump from a small-to-midsizeish company where I was the only DBA to a Fortune 20 company. The small company, which is cost-cutting and looks for any sort of way to cut costs and remove wasted headcount, hired my replacement within a month after I left. To them a DBA was essential to manage the company, both because the main prod DB was 300 GB and needed lots of care, and because quality standards require that deployment of changes be done by someone not on the development team. Not to mention that giving developers access to production is asking for trouble in that environment, both from a performance perspective as well as auditing.
As for the Fortune 20 company, they have with me 4 full time SQL DBAs, 5 consultants working as SQL DBAs, not to mention an entire team for Oracle and a team for DB2 and a team for Teradata. And the needs for DBAs keep growing. It took me five weeks from beginning of job search to turning in my two week notice. The job market here at least is wide open for DBAs because there aren't that many good candidates. By "good" I mean experienced who know what they are doing from the maintenance and admin side.
June 25, 2010 at 7:58 am
I think that I am sort of unusual, in that I am one of the rare ones who actually started as an Enterprise DBA on Oracle and DB2 and part time on SQL Server and transitioned to a full time SQL Server DBA.
Within the mindset of the people who implement and manage "Enterprise Level business critical" applications there is certainly an understanding and commitment to the need for full qualified full time DBAs. To have an application that is used by hundreds or thousands of users performing business critical functions running against a database that is setup/tuned by a someone who isn't on top of their game/fully competent is just asking for performance problems and outages that can cost a fortune 500 company a lot of money in a very short time.
Unfortunately the applications that have utilized SQL Server in the past have more often than not been the desktop/work group type of application that didn't fall into this category. As such the staff who developed and managed them don't seem to have the same kind of focus on scalability and availability, or the realization of how vital a knowledgable, dedicated DBA staff is.
The other problem as I see it is that SQL Server's ease of use is a double edged sword.
Sure, it reduces the total cost of ownership and allows a DBA to implement and manage a greater number of database in less time. However, it also makes it far to easy for someone without the kind of indepth knowledge and experience required to properly administer a complex database environment. While they think they are capable to deploying it and managing what is becoming a more and more complex environment, it takes far more than just the ability to run a wizard to do that job properly.
One of the consequences that I have seen from this is that applications that are deployed on SQL Server fail due to all kinds of performance, and availability issues.
This leaves a bad first impression and makes management more reluctant to use SQL Server to the full extent of it's capabilities. This not only "holds back" the advancement of SQL Server in it's evolution to an Enterprise level platform, it keeps companies from realizing the cost savings of SQL Server compared to Oracle, or DB2 when the problem wasn't with SQL Server but with the lack of knowledge of the "DBA" that deployed it.
June 25, 2010 at 9:02 am
Yes, I think companies, especially small ones, are foregoing hiring DBA's. I work for a university, but the department where I work, has a small 4 person IT staff. We've got 1 manager and 3 developers. No one is technically a DBA. I'm probably the closest thing to one, but believe me there is a lot more that I don't know about SQL Server, than I do. I'm talking mostly about managing SQL Server. And I'm not trying to be modest here. We just don't have the money to hire a DBA.
Kindest Regards, Rod Connect with me on LinkedIn.
June 25, 2010 at 9:16 am
To be honest this problem doesn't just exist with the lack of a DBA many smaller organisations expect you to perform multiple rolls.
For example in a recent deployment of SharePoint I was
The Bussiness Analyst
The System Architecht
The DBA
The Developer
The Trainer
The Support!!
Now I have an argument that these should all be seperate rolls but it falls on deaf ears. In general companies don't care about things being done right just that they are done now! I know they end up spending more in the long run fixing the issues.
It is what makes me consider giving up IT altogether!
June 25, 2010 at 10:14 am
Where I currently work I wear multiple DBA hats; I serve as both Oracle and SQL Server DBA, I pick and train my backup. I believe the problem stems from a lack of understanding on the part of management as to what it is the job of DBA entails. which leads IMHO to a belief they either don't need a DBA or the task can be accomplished by just about any one working in IT. Our former CIO looked me in the eye one day and told me there was no such thing as a SQL Server DBA! Try explaining your job to someone who was sold that line of garbage! I have found as long as the applications are up and running and the users are not complaining too much about slowness it is easy for management to over look our contribution to the over all effort. We all have to show value to our organization but I believe as DBAs it can be difficult to show value unless we make it clear to management exactly how important our job really is. Just my two cents....
June 25, 2010 at 10:18 am
I think the only danger with having someone who is solely a DBA is that people think their job is to look after the SQL Server side of things only - but it is imperative that this person also understands the Windows environment that the SQL Server instance is running on and had an understanding of the companies overall Business Continuity Pan. All of which makes the job even more interesting and rewarding 😀
June 25, 2010 at 10:37 am
With the exception of one IT company I worked for, none of my other employers have appreciated what a DBA is/does. Even within some of the IT departments/work groups, it seems this is an under appreciated role. I have been tasked several times as a shadow DBA, while trying to maintain a full load as a developer. When I tried to implement policies and do DBA level work, I have often been "slapped backward" and informed to just make sure the backups are fine.
June 25, 2010 at 10:42 am
Put it this way -- as long as there are things like SOX and HIPAA there will need to be some forms of DBA tiers. Developers usually don't have the mindset needed to rigorously enforce these tiers at the data level per standards.
June 25, 2010 at 10:48 am
I am also an 'accidental DBA'. I took training as an Oracle Programmer and then ended up being a SQL Server DBA in my first job. That was nine years ago and I'm still going strong as a DBA.
Is the SQL Server DBA position going away? I don't think so, nor will it.
The issue is with the company and usually a result of its size or newness. A company that is just starting out or is very small either does not have the experience to know it needs a fulltime DBA or doesn't have the money to afford one. Most large companies have been around a while and know the value of their data and the need for a DBA or a team of DBAs. I'm currently working for a company as part of a team of 14 SQL Server DBAs. We aren't developers pushed into a DBA roll - each one of us is a SQL Server DBA.
Bottom line, SQL Server DBA position is like any other position its importance is up to the company. Some companies don't have fulltime accountants. Does that mean there isn't a need for accountants in companies - no, it just means that some companies don't realize they need one or don't have the funding for one. A good company in that instance will at least know it needs to consult with one on a regular basis.
-SQLBill
June 25, 2010 at 10:54 am
dave1982 (6/25/2010)
For example in a recent deployment of SharePoint I wasThe Bussiness Analyst
The System Architecht
The DBA
The Developer
The Trainer
The Support!!
Now I have an argument that these should all be seperate rolls but it falls on deaf ears. In general companies don't care about things being done right just that they are done now! I know they end up spending more in the long run fixing the issues.
It is what makes me consider giving up IT altogether!
You can't even figure out how many times I had to walk down that road.
And how many times I will have to do it again.
Glad to see I'm not alone.
-- Gianluca Sartori
June 25, 2010 at 12:59 pm
One other thing about smaller shops is that the DBA is generally not chargeable to the client, I worked at a shop where anyone who touched the databases was called a DBA, but really they where analysts who created reports and scripts for clients. This work was changeable to the client but the everyday keeping the servers up and the data up was wasn't.
So guess what, I as the DBA ended up doing lots of this other stuff as well, the day to day DBA maintenance was seen as a drain on real client charging.
Andrew
Viewing 15 posts - 16 through 30 (of 46 total)
You must be logged in to reply to this topic. Login to reply