Amen to the Goulet Speech!

Mohan, Ross Fri, 16 Mar 2001 13:42:03 -0800

Title: Amen to the Goulet Speech!

Dick,

I couldn't agree more. In my experience, the majority of
COTS dbms products are extremely poorly thought out and
executed.

As a wise man once said: "Developers are the crabgrass on
the emerald green of the database."

If we all had to walk a mile in each others' mocassins, we'd
probably do a whole lot better. Really, the most satisfying
thing in the world is working with a savvy developer who has
the right stuff and *wants* to know how things work best in
his environment ( e.g. the database! ). I have had the
benefit of doing that once, and it ruined me for dealing with
all the multi-certified microcephalics who are squirting their
pathetic, reeking pseudopods all over my pristine freaking database.

Not that I am wrapped around the axle about this issue.

Yours in Data Totalitarianism,

-Ross

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 16, 2001 10:27 AM
To: Multiple recipients of list ORACLE-L
Subject: Re:RE: RE: Oracle DBA evolution path - please share your opi

Jacques,

First things first, DON'T TAKE THIS PERSONAL. I am not trying to brow beat
anyone, just venting a common problem I have with third party software
applications. I've had a couple interactions with Quest which for the most part
have been uneventful.

Over the last 5 years I've had run-ins with a lot of third party
applications, like PeopleSoft, Support Magic, Etrade, and now CoCreate. To say
the least they all have NOT been pleasant, actually some are down right too
painful and really get my blood pressure up.

Around here we build a lot of software for in house use & I have always
mandated that the applications "behave" themselves as users, not abusers of the
database. That means in a nutshell that they are clients of MY database and no
developer can expect more than that. They get one or more tablespaces as the
two of us jointly decide and some public privileges, like "create public
synonym". Note they do not get "drop public synonym". The application is also
not created to be platform specific from a database view. In other words they
can be installed into a database on any platform so long as we can access the
required client tools. Today's install may be on Unix from an NT client,
tomorrow's could be in reverse. Keep it generic & simple.

This I know is not the case at all third party shops, actually I've talked
to an Oracle DBA at Support Magic who was informed by the CTO that he could
either "do as the developers want or clean out your desk". I've also had the
unpleasant experience of talking to one of those developers. At the end of the
conversation, if you want to call it that it was more of a lecture from his end,
I informed him I wanted to know when his funeral was and was hoping it would be
sooner(like tomorrow) vs. later.

Why? you'll ask. The reason was that according to this particular
duhveloper all of the database instance was his to manipulate as he desired
without regards for the consequences. I quote: "Recovery of a failed database
is your task, not mine. And if I did something that makes that task harder on
you that it should, tough s&^t". Not an attitude that I appreciate, but then I
did not appreciate the sales person either when he said "if you don't like our
installation method, go somewhere else. I've other things to do." An attitude
that was recently featured in ComputerWorld saying that many software vendors
see a sale as a one off item or as the author put it "a drive by sale". You
know, something like a "drive by shooting".

One other reason that has been raised is that the "application was ported
from <name of a data management scheme>". In this case you can replace the <>
with either AllBase, Xbase, flat files, etc.... In any case porting is in my
mind a VERY poor excuse for a bad DB implementation. Lets face facts, we're
buying the software from you because we can't/don't want to create it or try
re-inventing your wheel. Therefore I expect that a good DB development job was
done. Lets just say that those expectations have been very heavily dashed.
Also, I recently (like a month ago) rejected a job offer at a third party shop
mainly because they did not feel it was their place to consider how those who
support the product look at it.

Now I understand that some shops work on the premise that "the client will not
have a trained Oracle staff". All well and good, yes it would be good in these
cases to have the appropriate scripts in hand to handle that, but if they have
why "impose" your views on the in place folks. Give them the system
requirements (Tablespaces, Names, sizes) & get out of Dodge. Why does this
rattle my cage so badly, Lets look at some of that CoCreate recently (like two
weeks ago) did:

First they asked that I run orainst & let it create the basic database. OK then
they went in & created some tablespaces on their own as follows:

TABLESPACE_NAME FILE_NAME ALLOCATED FREE_BYTES
--------------- ---------------------------------------- ---------- ----------
RBS_HP_DMS /users/cocreate/database/wm_rbs_.dat 2 1
ROLLBACK_SEGS /ora2/roll01.dbf 100 92
SYSTEM /ora2/system01.dbf 100 58
TEMP /ora2/temp.dbf 150 150
TOOLS /ora2/tools.dbf 15 15
USERS /ora2/users01.dbf 75 75
WM_ARCHIVEFS /users/cocreate/database/wm_arch_.dat 12 12
WM_CLASSINFOS /users/cocreate/database/wm_eles_.dat 24 24
<-
 /users/cocreate/database/wm_erels_.dat 24 23
<-
 /users/cocreate/database/wm_files_.dat 20 20
<-
 /users/cocreate/database/wm_frels_.dat 7 7
<-
 /users/cocreate/database/wm_infos_.dat 22 22
<-
WM_CNC_FILSET /users/cocreate/database/wm_cncs_.dat 7 7
WM_HISTORY /users/cocreate/database/wm_hist_.dat 24 24
WM_MAINTENANCE /users/cocreate/database/wm_iacc_.dat 22 22
<-
 /users/cocreate/database/wm_maints_.dat 0.4 0
<-

Interesting isn't it. Now who in their right mind is going to go looking for
Oracle database datafiles in the /users mount point? And why would one use the
extension dat for a dbf file? Also these file names have almost nothing in
their names to associate them with their tablespace and why have multiple small
files in one tablespace especially on the same spindle and controller? Why,
this was ported from AllBase that's why. They also did the "dumb" thing of
letting Oracle set the default storage parameters and then not having any
storage set for the individual tables. Can you say logarithmic growth!

OH, how about some interesting object names:

B99Y1IB5C87J7P TABLE
B99Y1IBDC87J7P TABLE
B99Y1IBHC87J7P TABLE
PATTERN TABLE

What are these?? I certainly haven't the foggiest.

Now, would I rein in those developers and take away their sys/system level
privileges, IN A HEART BEAT. Believe me you'll be doing those of us out here,
like me, a real "BIG" favor.

Dick Goulet

____________________Reply Separator____________________
Author: Jacques Kilchoer <[EMAIL PROTECTED]>
Date: 3/15/2001 1:46 PM

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> HUMMM, It looks to me like you've given the keys to the kingdom to the
> developers, namely the system account. Well, I don't know
> about you folks, but
> over here no one, and I mean NO ONE outside of the DBA crew
> has the passwords
> for sys, system or the Oracle unix account. Basically if any
> of the developers
> wants something done at the Unix level, like deleting a
> datafile, or the Oracle
> system level like starting or shutting down the DB, they come
> to us, PERIOD.
>
> Now I can understand why some folks get so stressed out. Our
> developers have a
> schema or two that they can trash around in all they want in
> development.
> Outside of that the DB belongs to me.

Well, I've only been here a couple of months so I don't want to make a lot
of enemies (yet). To be fair all the developpers in my group are very
knowledgeable. Several of them know details about Oracle internals that even
I didn't know (for example some of my colleagues are the people that wrote
Shareplex.) Most of these databases were originally created by the
developers and all of them still had the default passwords for sys and
system. Since we're a software shop and support many version of Oracle there
is a large number of development databases on many platforms, and most of
the developpers have also created Oracle dbs on their individual Windows
machines. So they are used to the laissez-faire attitude. But if I'm in
charge of making sure the databases are always available and that test
environments can be recreated rapidly, I'll have to tell them that we need
to be a little more careful.

So there will be some changes now that I'm here, MWAHAHAHAHA! I'm thinking
of having a big sign printed up that says "All your databases are belong to
us."

------
any ignorant comments made are the sole responsibility of J. R. Kilchoer and
should not reflect adversely upon my employer.

Jacques R. Kilchoer
(949) 754-8816
Quest Software, Inc.
8001 Irvine Center Drive
Irvine, California 92618
U.S.A.
http://www.quest.com
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: RE: Oracle DBA evolution path - please share your opinion</TITLE>
</HEAD>
<BODY>

> -----Original Message-----
 > From: [EMAIL PROTECTED] [<A
HREF="mailto:[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]</A>]
 > 
 > HUMMM, It looks to me like you've given the keys to the
kingdom to the
 > developers, namely the system account.  Well, I don't
know 
 > about you folks, but
 > over here no one, and I mean NO ONE outside of the DBA
crew 
 > has the passwords
 > for sys, system or the Oracle unix account. 
Basically if any 
 > of the developers
 > wants something done at the Unix level, like deleting a

 > datafile, or the Oracle
 > system level like starting or shutting down the DB, they
come 
 > to us, PERIOD.
 > 
 > Now I can understand why some folks get so stressed
out.  Our 
 > developers have a
 > schema or two that they can trash around in all they want
in 
 > development. 
 > Outside of that the DB belongs to me.

Well, I've only been here a couple of months so I don't want to
make a lot of enemies (yet). To be fair all the developpers in my group are very
knowledgeable. Several of them know details about Oracle internals that even I
didn't know (for example some of my colleagues are the people that wrote
Shareplex.) Most of these databases were originally created by the developers
and all of them still had the default passwords for sys and system. Since we're
a software shop and support many version of Oracle there is a large number of
development databases on many platforms, and most of the developpers have also
created Oracle dbs on their individual Windows machines. So they are used to the
laissez-faire attitude. But if I'm in charge of making sure the databases are
always available and that test environments can be recreated rapidly, I'll have
to tell them that we need to be a little more careful.

So there will be some changes now that I'm here, MWAHAHAHAHA!
I'm thinking of having a big sign printed up that says "All your databases
are belong to us."

------
 any ignorant comments made are the sole responsibility of J. R.
Kilchoer and should not reflect adversely upon my employer.

Jacques R. Kilchoer
 (949) 754-8816
 Quest Software, Inc.
 8001 Irvine Center Drive
 Irvine, California 92618
 U.S.A.
 <A HREF="http://www.quest.com"
TARGET="_blank">http://www.quest.com</A>

</BODY>
</HTML>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
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).

Amen to the Goulet Speech!

Reply via email to