Re:RE: RE: Oracle DBA evolution path

From: <Srini.Chavali_at_Cummins.com>
Date: Fri, 16 Mar 2001 13:44:03 -0800
Message-ID: <F001.002CF703.20010316125646@fatcity.com>

Amen !!!!!!!!!!

dgoulet_at_vicr.com_at_fatcity.com on 03/16/2001 10:26:43 AM

Please respond to ORACLE-L_at_fatcity.com

Sent by: root_at_fatcity.com

To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> cc:

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>

> -----Original Message----- > From: dgoulet_at_vicr.com [<A HREF="mailto:dgoulet_at_vicr.com">mailto:dgoulet_at_vicr.com</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

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

<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.  Our 
 > developers have a > schema or two that they can trash around in all they want
in

<BR><FONT SIZE=2>&gt; development. </FONT>
<BR><FONT SIZE=2>&gt; Outside of that the DB belongs to me.</FONT>
</P>

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.

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

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



-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: Srini.Chavali_at_Cummins.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:44:03 CST

Re:RE: RE: Oracle DBA evolution path - please share your opi