June 25, 2010 at 2:05 pm
I sure think so. It does not matter what title is called, VP of DBA or something else.
The demand for data and server professionals will still be there. The sales exec VP can outsource to offshore for a dime a day, but they soon will suffer and the company will be toppled over by offshore entrepreneurs.
When there is a local corporation on your ground, there is a need for people who have the right skill-set to work on it.
Jason
http://dbace.us
😛
June 25, 2010 at 2:36 pm
I think the role of SQL Server DBA is under-rated and over-used. My title is Senior Database Developer and I help our sole DBA with performance issues and setup. IMHO, our DBA is very over-worked; managaing over 100 database servers in development, QA, and production with also one or more DB servers at 11 remote sites. I've said from the beginning that he needed a junior DBA to help him with the more mundane tasks, but management here does not see it that way.
I'm happy in my job as it mainly consists of performance tuning and that is what I like. The few times I've had to back up our DBA (on vacation), I was just not happy with all the responsibility (and blame) when something went wrong -- even when it was the OS and/or hardware that had problems.
Unfortunately SQL Server has the stigma of being "easy" to maintain. While this is probably true of a single DB server, when you had a mutiltude of DB servers it just becomes a chore. Granted Microsoft has made some tremendous strides recently.
I remember once at a PASS training session Kalen Delaney saying something to the effect that she was an expert in indexes and tuning, but SS was getting so complex that she could not be an expert in SSIS, etc. Unfortunately management still believes that anyone can manage SS.
Mike Byrd
June 25, 2010 at 3:09 pm
Hi! my view regarding the DBA profession is that it's a growing field and most managers and CEOs are beginning to realize that DATA is their most valuable asset. So, there has to be a dedicated professional like a DBA to ensure that there is integrity, security and proper means of recoverability regarding the DATA. I admit that in most shops, there ia a tendency to have Developers to call the shots regarding database architecture. It may be Ok to do that in some cases where a Deveoper understands the intricasies regarding the proper logical/physical Model of the Database, physical architecture of the Database environment i.e. number of processors, Disk Type (RAID System), Recoverability. However, my experience with this type of situation is that, it is always a good thing to have a seasoned DBA who can perform these tasks from the beginning to ensure that the database is well designed and the physical environmnent is well built to accomodate any futures growth. Most Developers are mainly concerned about getting the application to work and not the performance of the Database as the Data grows. So, the management will only realize the importance of a well designed Database environment when the system is down and the business come to a standstill. That is the point when you start seeing DBA positions being advertised to come and fight fires. You can actually compare this to the current BP oil spill where redundancy was not built into the sysytem because Oceanographic Engineers advice was to taken into account.
June 25, 2010 at 4:18 pm
If your company has SQL Server databases, then SOMEONE is acting as a DBA. But there is a vast difference between knowing HOW to take a backup, and understanding WHY you need that backup, and what kind of backup, and when to create that backup.
June 25, 2010 at 4:29 pm
I am hoping more and more companies are looking for SQL Professionals. This is my career field. I would like to make it last.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
June 25, 2010 at 5:44 pm
What is the average number of servers or dbs that a dba is responsible for?
June 27, 2010 at 4:31 pm
There seems to be two basic roles, application developer and database administrator (DBA).
In my experience, a "typical" application developer creates database tables as needed, often with very little concern for normalization, declarative referential integrity (DRI), and indexing.
In my experience, a "typical" database administrator cares for disaster recovery, high availability, performance monitoring, and fighting fires caused by misguided database design decisions.
If my experience is any indication of the general reality then there's a big gap between these roles. The gap is almost never filled, especially in a smaller company, and the result is chaos in the database environment. The DBA role often gets filled after the chaos has begun, but by then it's too late to really fix the problems because application code has been written to depend upon the misguided database design decisions. The DBA role usually deploys more and bigger servers to handle an ever-increasing load. The load is partially due to increased business activity, but it's also partially due to inefficiencies which could/should have been prevented long ago. The prevention can be provided by somebody filling the gap and focusing on data modeling, normalization, table structure, DRI, indexes, data types, naming conventions, triggers, stored procedures, views, functions, code generation, data import/export, archiving, purging, auditing, and (above all) consistency.
Creator of SQLFacts, a free suite of tools for SQL Server database professionals.
June 27, 2010 at 6:38 pm
andrewkane17 (6/25/2010)
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
Actually, it IS chargeable in one of two ways...
1. Task the DBA (and others) with keeping a detailed log of start/stop times and server names. Anytime the DBA touches basic infrastructure that touches all clients, log that as well. Have an accountant reconcile the costs at the end of each week or month.
2. Instead of the complexity of #1 above, realize that you can probably cast a charge on clients known as "G&A". It's typically charged much like a tax would be charged. Even small shops can do it.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 28, 2010 at 8:13 am
I think part of the problem is that people don't really know how a DBA differs from a DB Architecht or DB Programmer. I'm a consultant and I can't count the number of times I've gotten calls to do DBA work even though I tell them over and over that I do Architecture, Design and Programming. I've also gotten calls where they tell me they're looking for a strong DBA and then describe job duties that are all ETL, Programming and Redesign. I'd bet a lot of these companies think they have DBAs even though they don't.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
June 28, 2010 at 9:37 am
akarczewska (6/25/2010)
What is the average number of servers or dbs that a dba is responsible for?
The number of servers/databases just depends on the size of the company and what they do.
My first job, we only had two servers with a single database on each. (1 DBA - me)
My second job, we had about 100 servers with a total of 400 databases. (2 DBAs)
My current job, I don't even want to try and guess the number of servers and/or databases. We add quite a few each year, just this month we added three new servers. (11 DBAs).
-SQLBill
June 28, 2010 at 3:42 pm
Jeff,
Let me rephrase, at the smaller shops I have worked in or had dealing with, the DBA role was not considered as a chargeable resource to clients. I know there is plenty of ways small shops could pass on the cost, but I have found they find charging for services, other than support, easier to account and charge for.
Andrew
June 28, 2010 at 3:47 pm
I agree that it's hard to charge for a DBA as a support person in many cases. There are companies that just don't want to pay for this from a consulting service.
June 28, 2010 at 3:55 pm
Amen to this post.. exactly what I have experienced. So much of what I have had to do did not always entail the database. I had to troubleshoot server,network and db as all part of a problem and many times it varied between the three. Unfortunately it is like what is stated below. The company sees SQL as being easily managed and outsource the position to a offshore contractor. Then when a real problem crops up the outsourced position does know where to look other than the database and a problem goes on forever until someone that looks at it from all sides figures it out. Then the outsourced dba role becomes nothing more than a script pusher and backup taker..but when a company sees that a dba role will only cost them 5k a year all they see is the money savings.. granted the first time the system goes down for a couple of hours while the finger pointing goes around and "its not my thing".. they lost any cost savings they got from outsourcing...maybe one day they will figure this out.. I hope.. Not seeing that being the case yet though.. I think the outsourcing of the support DBa role will only continue.
Richard Bradford-339699 (6/25/2010)
I started as an IT Analyst/Developer about 20 years ago (the analyst part was system and server admin, the Developer was mainly SQL and 'C' ), then moved to Network/Server admin and then moved to the DBA role, I'm still what I'd call a hybrid DBA.What I have experienced is that the introduction of specialisms i.e. splitting serverdamin, SQL developer and DBA roles entirely has reduced the flexibility of the DBA role and reduced the value of the role. This seems to have been exacerbated by the transfer of IT skills to large IT corporates driven by the IT outsourcing market. As time goes on there seem to be more and more DBA's who not only have limited knowledge about the o/s, AD and infrastructure on which the DB Servers sit but also seem to lack understanding how all these elements tie together. IMO a DBA needs strong server and network admin skills as well as DB Server specific skills, but by isolating these skills into different functional areas you not only reduce flexibility and devalue the worth of each IT resource but also introduce information silos and complexity.
I have had numerous experiences where "issues" have been passed between these differently specialised groups like a hot potato that no one wants to eat. This is just not an efficient way of doing things.
Although I'm sure that most of us who work as DBA's still wear many hats I think that we DBA's are beginning to specialise ourselves out of the mid to low end market, this is exacerbated by the higher end market forcing us into niches of overspecialisation.
June 30, 2010 at 12:47 pm
When I first started with my company, there were 32 SQL Server 2005 instances in existence with around 600 databases. They had never hired a DBA prior to my coming onboard. Because of the lack of a DBA, it was extremely easy for me to show them the benefits of the expense of my hiring. Since then, the number of SQL instances has grown to 65 with over 1200 databases. Prior to March, I managed 100% of those on my own. Most are now SQL 2008, with only a few legacy systems mandating the need to remain at 2005 until all testing has been completed to move forward. We hired an additional DBA in March that was to be my equivalent. However, that has not quite panned out, and he is being spun into the new Oracle initiatives that we have for our ERP systems targed for 2012.
Tomorrow we will absorb another DBA when we complete the buyout of one of our third-party app/database providers. So in the span of 19 months we will have gone from zero to three DBAs. Are three needed? At the moment, no. Do I mind the fact that I will finally have two additional DBAs? Not at all. Aside from the fact that I'm still the go-to guy on a 24-7 basis.
Do I think companies are moving away from a dedicated DBA? I hope not. But if they are, some of us are available to come in and help clean up the messes. 😉
btw... everyone planning on going to SQLPASS 2010.... today is the last day to save 600!!!
June 30, 2010 at 1:04 pm
btw... everyone planning on going to SQLPASS 2010.... today is the last day to save 600!!!
I thought today was the last day to save $200.
Viewing 15 posts - 31 through 45 (of 46 total)
You must be logged in to reply to this topic. Login to reply