Michael,
No not all databases are the same but many are. DBA's as a whole are
extremely inefficient. Most of us well know that we could automate much of
what we do if we just sat down and thought about it for a second. I mean
come on, why should a DBA have to actually check dozens of V$ views to "see"
if anything is going wrong? Yes, I know that there is software out there
that will do that but since many of us are still doing this sort of thing
manually my point is made. At some point a typical installation is going to
be fine to service 80% of all databases (the old rule of 80/20). These
types of databases will not need a "live in" admin. They will run just fine
with occasional servicing much like your car. I agree that there will
always be a need for DBA's, and I agree that the knowledge a db will need to
perform in the 20% of cases will increase. The development cycle seems to
go like this:
1. New version of db released with new features, features are difficult to
use.
2. Next version is released and new features have more power and easier to
use, some more brand new features are included.
3. an so on and so on....
Everyone in the industry is working to make life simpler for the mass 80%.
Plug the box in, install Oracle, set a few settings, plug in the storage
device, sign up for a remote dba service and go....
Now it seems to me that this is the way it is going to be because:
1. It is technologically possible.
2. It is cheaper, faster, better.
3. More and more packaged applications running on databases.
Now you might think that you will in ten years still be capable of
convincing a your company that they can not live without a "real" DBA but I
say there is already a whole industry working to convince them otherwise.
In ten years they will cover a lot of ground. I'm sure we will see the
database to dba ratio change significantly and that means more remote
management, maybe still from an office, but more databases over wider areas.
Talking to your database will be as easy as talking to someone on the phone.
555-5555....shutdown abort.
- Ethan Post
- http://www.geocities.com/epost1
-----Original Message-----
Sent: Thursday, July 05, 2001 3:10 PM
To: Multiple recipients of list ORACLE-L
I wonder if a similar thought was echoed in 1991? Maybe all of the DBAs
that were former DB2, etc DBAs could offer some war stories here. It's
funny that databases have become more cumbersome to manage, not easier IMHO.
DBAs have to understand more technologies that are outside the RDBMS box
than ever before. Every time we get a new version it gets a little more
complicated to manage. I suppose we should just put everything in
autoextend mode, oversize the SGA and other memory structures and we would
be able to manage 1000's of databases. Not likely now, or ever for that
matter. All of the quick fixes leave out one particular fact: All databases
are unique and have their share of unique problems. Thank goodness for
that!
I can't wait to take a vacation and recover a standby database while adrift
on the ocean. It gives "Cast Away" a whole new meaning!
:))
--Michael
------------------------------------------------------------------------------
This e-mail is intended for the use of the addressee(s) only and may contain
privileged, confidential, or proprietary information that is exempt from disclosure
under law. If you have received this message in error, please inform us promptly by
reply e-mail, then delete the e-mail and destroy any printed copy. Thank you.
==============================================================================
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Post, Ethan
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
