Re: venting my spleen

Seems to me you're not getting the respect you deserve as being in charge of the operation and availability of the Oracle RDBMS in question.

Developers should not be building tablespaces, placing/naming datafiles or doing anything with the SYSTEM user. Doing so effectively removes your supervision as the DBA.

Next week they'll probably start mucking with undo and redo. Then a few days later they'll want the oracle account password ( unix ) or access as administrator ( windose ).

I've certainly had to make my stand in the past and will most like make it again. I think you should seriously consider doing just that or at the very least, document ( as has been suggested ) everything and CC the world.

-Kevin

"Ed Stevens" <spamdump_at_nospam.noway.nohow> wrote in message news:3d1883ad.4962926_at_ausnews.austin.ibm.com...
> On Tue, 25 Jun 2002 13:11:00 GMT, spamdump_at_nospam.noway.nohow (Ed Stevens)
> wrote:
>
> >An application project is getting under way that, to me, has the smell of
> >disaster written all over it. Please tell me my lack of dba experience
is
> >causing me unnecessary worry.
> >
> >Project is built around a purchased package. Said package will remain
anonymous
> >at this point, but I will say it is not SAP. As it turns out, the
package
> >requires tablespaces with specific names. And I am told that it requires
> >certain tables to be placed in specified tablespaces. This looks like a
tuning
> >disaster waiting to happen.
> >
> >My first thought is that the only SQL the app could be issuing that would
> >require a specific TS name would be a CREATE TABLE statement. Why would
an app
> >need to be creating tables? And what would be the justification for not
using
> >the default TS for the application's own userid?
> >
> >When the project was first started, we (DBA) were told to make a SYSDBA
userid
> >available to the development team. This gave me heartburn in and of
itself.
> >Then last week, while working with them on a non-DB performance problem,
it came
> >to light that they were concerned about gettng time on the server because
they
> >didn't even know they could connect with SQL*Plus from a client
machine!!!
> >
> >I'm sure some of you have seen this kind of thing before. Do I have
cause for
> >concern? If so, what problems can I anticipate, and what can I do to
minimize
> >them?
> >
> >TIA.
> >--
> >Ed Stevens
> >(Opinions expressed do not necessarily represent those of my employer.)
>
>
> Part Duex.
>
> Actually, my statement that they wanted a SYSDBA userid was not quite
accurate.
> What they asked for, and got, was the password for SYSTEM.
>
> This gets scarier by the minute! Since my first posting, the team lead
has
> called us about every 30 minutes. Now it turns out that they have scripts
for
> createing the tablespaces themselves -- even to the point that they insist
on
> naming the files . . . and scripts within scripts within scripts, so that
they
> are reluctant to ("Can't") change anything.
>
> I know from past experience that DBA will have no weight at all against
the
> development team, and yet will be expected to make this all work when it
goes to
> production. The best I can hope for is to start educating my manager and
going
> on record with the anticipated problems.
>
> Additional input anyone?
>
>
> --
> Ed Stevens
> (Opinions expressed do not necessarily represent those of my employer.)
Received on Tue Jun 25 2002 - 11:10:36 CDT