Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Amen to the Goulet Speech!

Amen to the Goulet Speech!

From: Mohan, Ross <MohanR_at_STARS-SMI.com>
Date: Fri, 16 Mar 2001 13:42:03 -0800
Message-ID: <F001.002CF780.20010316131152@fatcity.com>

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: dgoulet_at_vicr.com [mailto:dgoulet_at_vicr.com] 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 <Jacques.Kilchoer_at_quest.com> Date:       3/15/2001 1:46 PM
> -----Original Message-----
> From: dgoulet_at_vicr.com [mailto:dgoulet_at_vicr.com]
> 
> 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>


<P><FONT SIZE=2>&gt; -----Original Message-----</FONT> <BR><FONT SIZE=2>&gt; From: dgoulet_at_vicr.com [<A HREF="mailto:dgoulet_at_vicr.com">mailto:dgoulet_at_vicr.com</A>]</FONT> <BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; HUMMM, It looks to me like you've given the keys to the kingdom to the</FONT>
<BR><FONT SIZE=2>&gt; developers, namely the system account.&nbsp; Well, I don't know </FONT>
<BR><FONT SIZE=2>&gt; about you folks, but</FONT> <BR><FONT SIZE=2>&gt; over here no one, and I mean NO ONE outside of the DBA crew </FONT>
<BR><FONT SIZE=2>&gt; has the passwords</FONT> <BR><FONT SIZE=2>&gt; for sys, system or the Oracle unix account.&nbsp; Basically if any </FONT>

<BR><FONT SIZE=2>&gt; of the developers</FONT>
<BR><FONT SIZE=2>&gt; wants something done at the Unix level, like deleting a
</FONT>
<BR><FONT SIZE=2>&gt; datafile, or the Oracle</FONT>
<BR><FONT SIZE=2>&gt; system level like starting or shutting down the DB, they
come </FONT>
<BR><FONT SIZE=2>&gt; to us, PERIOD.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Now I can understand why some folks get so stressed
out.&nbsp; Our </FONT>
<BR><FONT SIZE=2>&gt; developers have a</FONT> <BR><FONT SIZE=2>&gt; schema or two that they can trash around in all they want in </FONT>
<BR><FONT SIZE=2>&gt; development. </FONT>
<BR><FONT SIZE=2>&gt; Outside of that the DB belongs to me.</FONT>
</P>


<P><FONT SIZE=2>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. </FONT></P>

<P><FONT SIZE=2>So there will be some changes now that I'm here, MWAHAHAHAHA! I'm thinking of having a big sign printed up that says &quot;All your databases are belong to us.&quot;</FONT></P>

<P><FONT SIZE=2>------</FONT>
<BR><FONT SIZE=2>any ignorant comments made are the sole responsibility of J. R. Kilchoer and should not reflect adversely upon my employer.</FONT></P>

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

</BODY>
</HTML>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: dgoulet_at_vicr.com


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: ListGuru_at_fatcity.com (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).
Received on Fri Mar 16 2001 - 15:42:03 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US