The following collection of letters to the editor originally appeared on SearchOracle.com. What's your take on this issue? Email us your comments and we'll post a new collection on SearchSQLServer.com.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The increasing automation of the DBMS and the evolving role of the DBA has, not surprisingly, been a hot topic among you database professionals. Our coverage of the debate at the recent IOUG conference, Are DBAs needed anymore? sparked much conversation in our Sound Off! forum. We highlighted a few emails in a recent column (see sidebar below) and heard from many more of you. Here is a small sample of your feedback.
Automation frees time
All this DBMS automation has allowed me to write more scripts and programs to further automate things. We have over 200 SQL Server databases spread across 40 physical servers. If I had to check every server, every morning for stopped SQL Agents, failed jobs, drives running out of space, etc., it would be all I would have time for during the day. I wrote a VB.NET program to check and list (email, page) all these things for me. In Oracle, I have similar scripts: check when tablespaces are going to run out of extents, if backups were successful, check error logs, statistics, etc. But I still have to do a few things manually, like data mining, provide connectivity to users, make sure that the databases are secure, among other things ...
Eudoro van der Biest, DBA, Wellmont Health System
What happens when automated tasks fail?
I believe everything is as good as a person using it. To say DBAs are disappearing is like saying databases are disappearing. Wait until the so-called "automated task" fails. Will it auto fix itself?
I may say that the DBA role is moving to a more active than proactive role because one gets the time to learn and understand the internals of how things are done.
Norman Maphankgane, Data architect, Telkom Directory Services
Evolve to survive and thrive
In response to your editorial ("DBA's are like air"), I can only add that in my three-plus decades of experience with software engineering, those who survive and thrive are the people who evolve. In all honestly, the day will come when "database administrator" will have disappeared from the landscape, as have many other titles and duties in IS since its birth in the 1950s. Those who cling to the notion of "I've always done these things, and done them in exactly this way ..." will need to reinvent themselves.
One of the best quotes I ever heard was from the CIO of a company I worked at a long time ago: "There are two kinds of people in IT: those with twenty years of experience, and those who have repeated the same year for twenty years."
Edd Trettel, Database administration specialist
People created it, people needed to run it
I don't think that a DBA is like air, but find it funny how everyone feels so confident in a self-manned database, as if a database of itself is worth anything.
People come up with the concepts and because of this there is an inherent need for interpretation. How many of us as DBAs have come upon a supposedly easy schema that has been bastardized and misused by the "users", "management" or "consultants". We then get the database to fix and no one takes ownership because they did it with a wizard, or Oracle said it was simple in their class.
It is humanity's great endeavor to do nothing and have some machine do it all to their betterment. Reality has shown us various times where that is not so and rather foolish. The automation of the database should be looked at with great glee for the DBAs. It frees you up to hopefully connect with the people you are servicing. It allows you to be proactive and not reactive. It does not exonerate you from all ownership or responsibility for the database.
Ileana DiPina, Consultant and senior DBA
As a DBA, other tasks that have fallen on me include:
- Resident SQL tuning expert
- Logical modeler and business rule analyst
- Physical data designer responsible for data synchronization and integrity
- Systems capacity planner/ performance monitor in charge of locking, deadlock and concurrency issues
- Systems software installation configuration and tuning
- Operational systems trouble shooter
- Assistant security administrator
- Assistant storage management administration
- Assistant scheduling system administration
- Assistant change control systems administration
- JAD facilitator
- Hardware and software systems designer
So please do take the backups and logging and reorgs and runstats rebinds and binds then automate all of it, and the job will still be too big. The next thing to off load should be the operating system dependent scripting. What a misuse of skills that is!
David Colbourn, Consultant
Who's going to do the work?
I definitely relate to developers blaming the database for poor performance of their badly designed applications. I'm to the point now where I hate for hear our developers to even utter the word database...
From my point of view, I pose this question: What if your application is not finished or does not have all the tools needed by the end user? Who is going to perform all the manual changes and produce all the one-off reports needed?
Also, what if you're a smaller company/start-up running Standard Edition and/or an older version? Who is going to do that work?
Keith M. Cutler, Oracle database administrator, Etix.com
DBAs need to go above and beyond
I read with interest your article titled "DBAs are like air". Certainly all databases are moving towards self managing and self tuning, although in reality this is far from perfect. Just ask any DBA who works in a mission critical environment.
I think the idea of self-tuning and self-adjusting databases stems from the fact that the customers are putting more emphasis on expecting RDBMSs to behave like commodities software. Hence having less in-house specialists and black-art magicians is a popular trend these days. Most medium or large scale companies, for example the majority in the financial sector, have traditionally had heterogeneous systems spanning multiple vendors and multiple databases such as Oracle, Sybase, MSSQL and so forth, dealing with one line of business. Nowadays these companies expect their DBAs to support all these databases, in short the DBA to be multi-disciplined and jack of all trades. However, it takes time to learn the ins and outs of these databases and hence every bit of automation and masking helps.
I believe that for a DBA to be successful these days, he or she has to add value to the client/employer above and beyond of what is expected of him or her. It is no longer sufficient to be basically a glorified production support DBA come operator. The DBA needs to go beyond of what is happening on a day-to-day basis in a support role, and start looking at what can be done to improve and streamline the information flow. It may not be very surprising to mention that as a consultant, I have come across many DBAs who are not even familiar with the new functionalities within their current production environment. To go stale in these day and age is certainly a recipe for disaster, because companies are constantly looking at outsourcing their mundane production support work including database related stuff.
You brought up an important point that the developers are increasingly treating their databases as a black box, capable of digesting and handling poorly written code. They expect, in my opinion wrongly, that these automation tools will help resolve performance bottlenecks. With fast CPUs, 64-bit computing with no upper bound on memory and Storage Area Networks with large cache, why should one bother about spending time with scalable design and optimized indexes etc? The problem, as always, has been that poor initial design and work always manifests itself into a sluggish and struggling system in production. Performance has always been a deployment issue and bad design is always a nightmare with or without automation tools. Automation tools may help identify the potential performance bottlenecks easier, but any form of tuning of the database as opposed to the application itself, will hit the laws of diminishing returns sooner or later. A smart DBA needs to understand his/her primary application and work closely on developing effective backend design and strategies with the developers. It is not just sufficient to understand his/her own primary database area, but also the interfaces, the feeds and the method of interface to other systems as well. For example, questions need to be asked whether these interfaces can be made seamless by deploying the relevant products as opposed to relying on the traditional techniques such as import/export, FTP etc. Developers often have no clues about these products and hence a DBAs knowledge and input is very welcome.
In short DBAs have to show that they can add value to the projects. They should not only be capable of supporting many disciplines, but capable of coming up with innovative solutions in order to reduce cost and deliver goods in a timely manner. Just being another production support guy is no longer a necessary criterion to keep one's job.
Mich Talebzadeh, Principal consultant, Peridale Ltd.
DBAs needed more than ever
Are DBAs needed anymore? Perhaps more than ever before!
Database vendors are undoubtedly automating many processes while stepping down the amount of professional experience required, in an effort to bring ease-of-administration to the DBA's role. This also creates a false sence of security for growth companies who think they may be able to get by without the professional experience of a strong DBA -- a common misconception.
While the database vendor enjoys the marketing edge this creates, the company who has sacrificed have an expert DBA for this GUIstacally made-to-work-right-out-of-the-box database software will have to bear the the cost of outsourcing and data-warehousing. A good DRP may not be a good first line of defense here! This view is especially true for large to enterprise WANs. SMBs may be able to absorb disruptive costs a lot easier than large WANs. The DBA's job is becoming easier because of the ever increasing automated business processes while at the same time his experience suffers because of it. As a consequence the DBA's true experience may come into play only if and when disaster strikes!
No matter what may come, keep on sharpening your DBA skills!
Anthony Serieux, Information systems specialist
DBAs not needed on iSeries
Not if you are on iSeries. Read Section 2.9: Differences between iSeries and Unix implementations of their Redbook, "Implementing SAP R/3 on OS/400" for where the industry might be heading and where the iSeries had arrived long ago. The document is at: http://www.redbooks.ibm.com/redbooks/pdfs/sg244672.pdf
Does a country need a president?
Can you answer my questions:
- Can 10g upgrade by itself?
- Can datafiles/tables be restored by itself in 10g?
- Can 10g do explain plan by itself and tune the query with magic?
- Can 10g tune the database by itself?
- Who is the coordinator between developers and system admins?
- Who controls the security?
In other words, does any country need a president? All the work is done by others.
DBAs roles have expanded
To even consider the idea that DBAs will no longer be needed is simply naÏve and short-sighted. A DBA's role has expanded to so much more than just a database tuner. A DBA architects the database, helps users/developers fine tune their queries, recovers lost data (can any database engine restore itself without a DBA?) and 'fixes' or backs-out data posted incorrectly. Fine tuning the database is just one of many jobs a DBA performs. Also, have we ever known a database engine to work exactly the way it should at all times? To think that Oracle, or any other database engine, can account for any and every type of database circumstance that will ever occur in the real world is ridiculous. I have yet to see a database designed solely by developers or architects that is set up appropriately.
DBAs are an integral part of the system itself
I have been following your recent discussions on "who needs the DBAs" with interest. The way I see it, the issues currently stacked up against local DBAs are: 1) far sourcing of DBA tasks and 2) the ongoing addition of the new self-tuning and optimization tools either by the database vendors or the third party tool makers.
First let us look at far sourcing. This is all started by companies outsourcing their mundane and repetitive IT tasks to countries of low cost base such as the ones in South Asia and to a lesser extend in Eastern Europe. Well there is nothing surprising about this approach. A lot of industries have gone this way in the past decade. However, if we look at the databases, these remote outsourcing seems to cover the so called "low touch" areas, i.e. the peripherals of databases. To make this point clear by "peripherals" I am referring to any task that can be handled generically; such as backing up, restoring and cloning of databases, building standard servers from a pre-packaged specification and acting as a first line of contact for infrastructure support. However, the assertion that support and up-keep of databases end in here is very misleading.
There is no doubt that the addition of new features such as Oracle's server-based advisors and Sybase's cache wizards have made the monitoring and tuning of databases simpler and less human intensive. All database vendors are striving to increase their market share in the highly competitive database market, and project their product as the one with lower Total Cost of Ownership (TCO).
The problem is that it will be naive to consider or project an enterprise class database management system as commodities software where the product is assumed to be easily dispensable and an end to itself. The database itself is almost always a component of the business solution and has to be integrated well with what the application is trying to achieve. You cannot simply build a mission critical application independent of the database. Further an application that claims to be database independent is automatically an application that will perform badly at high levels of concurrency or large data volumes. Thus you will need closer collaboration between the developers and DBAs all way through from development to deployment. A DBA is thus an integral part of the system itself. The developers tend to treat the database more of a black box these days and hence it is crucial to get the expertise from the DBA at every stage of development. Without the knowledgeable DBA and just considering the automated tools and off shore DBAs with little or no exposure to the application itself, what the customer gets is a type of support that is pre-packed, shallow, generalistic and inflexible.
Mich Talebzadeh, again
What's your take on this issue? Email us your comments and we'll post a new collection on SearchSQLServer.com.