Mike Ault's thoughts on various topics, Oracle related and not. Note: I reserve the right to delete comments that are not contributing to the overall theme of the BLOG or are insulting or demeaning to anyone. The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer.

Wednesday, May 04, 2005

On the Demise of DBAs

Much is being said recently about how much the DBA job is changing. How soon there won't be a real need for hard-core DBAs. In a recent keynote (I was unfortunately called to a client site and it was given in my stead by David Scott, the President of the GOUSER (Georgia Oracle User) group) I addressed this issue. In an analysis of the changing DBA role I was able to identify that we have gone from the basic 13 items listed in the Version 6 Oracle Administrators guide for a description of the DBA job, to at least 2 dozen responsibilities as of 10g. The original list looked like so:

1. Installing and upgrading Oracle server and application tools.
2. Allocating system storage and planning future storage requirements for the database.
3. Creating primary database storage structures once developers have designed an application.
4. Creating primary database objects (tables, views, indexes) once the application designers have designed an application.
5. Modifying the database structure as necessary, from information given by application developers.
6. Enrolling users and maintaining system security.
7. Ensuring compliance with Oracle licensing agreements.
8. Controlling and monitoring user access to the database.
9. Monitoring and optimizing the performance of the database.
10. Planning for backup and recovery of database information.
11. Maintaining archived data on appropriate storage devices.
12. Backing up and restoring the database.
13. Contacting Oracle Corporation for technical support

The revised list:

1. Installing and upgrading Oracle server and application tools.
2. Allocating system storage and planning future storage requirements for the database.
3. Creating primary database storage structures once developers have designed an application.
4. Creating primary database objects (tables, views, indexes) once the application designers have designed an application.
5. Modifying the database structure as necessary, from information given by application developers.
6. Enrolling users and maintaining system security.
7. Ensuring compliance with Oracle licensing agreements.
8. Controlling and monitoring user access to the database.
9. Planning for backup and recovery of database information.
10. Maintaining archived data on appropriate storage devices.
11. Contacting Oracle Corporation for technical support.
12. Management of object related features.
13. Determination of LOB storage options.
14. Assistance with RAID configuration.
15. Determination of proper index strategy (normal, reverse, IOT, bitmapped)
16. Education of Developers in Oracle features and their use.
17. Management of distributed environments.
19. Management of parallel server and parallel query.
20. Determine and manage partitions and sub-partitions.
21. Determine proper use of outlines and SQL profiles
22. Create, manage and maintain resource groups,
23. Create manage and maintain global temporary tables.
24. Create and manage materialized views, summaries and snapshots.
25. Monitoring and managing the automatic and dynamic sizing parameters.
26. Monitoring and managing the automated UNDO (it isn’t set and forget)
27. Monitoring and tuning RAC environments, especially the cluster interconnect.
28. Manage and maintain fine grained auditing (HIPPA/SOX requirements)
29. Manage and maintain row level security28. Manage and maintain fine grained access controls.

Add to the above: Monitor and maintain application servers, web servers, connection managers, LDAP and other servers as well as the entire client to database environment in many shops the DBA does it all.

Now there may be arguments on both sides about some of the above rolling into some of the original listed general categories, but when some commands require multiple pages to just describe (CREATE TABLE for example), let alone show meaningful examples for, well, they need to be broken out as a responsibility.

However, as the features are improved I have no doubt they will automate the complete management of SQL, tables and indexes and tablespaces as well as some memory and tuning parameters. So the DBA will give up on items 12, 13, 24 and 25. Gee, how will the other 25 (26 if you include the final one added above) items fill our time? The death of the DBA has been greatly overstated.

A case in point. I am involved in producing some roll ups for use in feeding the Oracle Warehouse builder for a 10g DWH project. The roll ups are used to pe-flatten and tune the feeds, tuning is difficult if you use 100% OWB to do the flattening. Anyway during verification that the flattening was being effective I decided to test the Enterprise Manager SQL Tuning Advisor. Before tuning, the particular view being examined required 10 minutes to produce a count of its records, I put the SQL Tuning Advisor onto it and 8 minutes later it came up with its recommendations. I implemented them and then tried the count again. 39 minutes later it came back with the count. It didn't exactly produce the desired performance improvement. To be fair, on the one I ran through before this, it cut a 4 minute run to a 2 minute run on a different view. Could I have done a better job tunng it manually? We shall see (as soon as I figure out how to get the "SQL Profile" it created removed!)

So, needless to say, I feel safe in saying the imminent demise of the DBA though much sought after by Oracle Corporate (I kid you not, I was at a ECO conference and sat through a keynote by a VP of Oracle who obviously didn't realize he was talking to a room full of DBAS, which with great relish described how Oracle was attempting to do away with the job of DBA) is still a long way off. It seems for each job they "take away" they give us three more.

12 comments:

David Aldridge said...

>> I ... sat through a keynote by a VP of Oracle ... which with great relish described how Oracle was attempting to do away with the job of DBA <<<

Tom Kyte! Was it Tom Kyte!?

:)

Mike said...

No, it was not! :) I can't remember the fellows name, but a quick search of the ECO archives should reveal it!

Don Burleson said...

I remember that Cullinet tried this back in 1987 with a Charlie Bachman tool.

They advertized it as a tool wher you could fire half the DBA staff (to justify the cost of the tool).

Let's not forget that the "no DBA" nonsense is for the scaled-down Oracle, to complete with SQL Server. . . .

I think that hiding the complexity with unbrellas is very smart, actually, as it give clients a full-growth path. . .

Jeff Hunter said...

If you are a 10g DBA and you do half of those things you are wasting your time and your employers money.

2. Monitor storage? I automated that 4 years ago.
3. Creating storage structures? C'mon, I have developers. Why should the DBA be the bottleneck in the development process.
4. Creating tables? See above.
5. ditto
7. I don't do legal. My lawyer or managers asks me for numbers, I give them to him.
12. What does that even mean?
13. use LMTs
14. keep it simple, 0+1 everywhere
15. and assume the developers don't know what they're doing?
20. Partitioned tables don't into production until they have an automated management policy.
23. what's there to maintain? It's an empty table.

Mike said...

Sure, not all of the items listed apply to all shops. As far as automated sotrage, sure, you can automate it to a certain degree but you still need to monitor it. Afraid they don't have automatically extending arrays...yet!

So Jeff, are you saying your company could do without you?

Mike

Niall said...

Hi Don

I can't agree with you on the 'no DBA' nonsense being for the versions of Oracle priced to compete with SQLServer. The tools in 10g that are used in that argument (with the exception of ASM), things like AWR, the advisors, patch management etc aren't actually available to SE and SE One users. Well technically they are, but legally they are not, as they are extra cost options to EE only.

Installing 10g SE and disabling all the packs and navigating EM is a surprisingly depressing experience.

John Hurley said...

Sorry guys but the DBA whole enchilada was around way before oracle. It's kind of narrow minded thinking to equate DBA with "oracle DBA". Anyone remember IMS? Most DBA's advance into the position with considerable experience in other areas. Any kind of person that attempts to operate off a list of what they are supposed to do is doomed to failure in my opinion

Mike said...

I couldn't agree more. That is were the checklists fall down, if you train for only what is on a checklist somewhere you are doomed. The list was more of a "see, we have more to do, not less" than a hard and fast these are the tasks of a DBA. I wish those were the only things we have to do!

Jeff Hunter said...

So Jeff, are you saying your company could do without you?

If the only things I was responsible for were the things on that list, then yes, I should be replaced. Clearly the DBA position is not going away, it is (or at least should be) evolving as the technology evolves. There were times when people worried about segment fragmentation, the size of the SGA, and rebuilding indexes on a regular basis. While these "old school" tasks may be relavent for Oracle 6&7, the technology in recent versions has made these concerns obsolete.

Tarry said...

Don,

What is that tendency of pushing/going the other way?

You know this behavior of yours is contagious.

I personally(partially) disagree with the continuity of a DBA. That role is indeed evolving. Most DBA's are(if they aren't then they should) getting out of the back-end and trying very hard(it's darn upside-down, the whole summarization logic against OOP = if you want to learn some language like java) to get a better understanding of the front-end.

Mak said...

Haven't some folks suggested in 90s that no one would need developers with advent of Case-Tool and code generators.. Did you see that happening???

Mike said...

Nope, more developers and DBAs than ever before, in fact we are still showing growth.