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.
|
|
