Re: venting my spleen

Kevin is right, that is just actually what will happen. Their code will never be considered poor - they worked on it for hours.... They will insist on setting up more and more things themselves using their scripts.

You could wash your hands of the whole thing I guess, saying that they obviously can set the system up without you and your constant questions about everything seems to slow the install down etc, so suggest that they provide all DBA activity themselves, or if you are to provide it they should provide detailed instructions that you'll just follow word for word. Team managers normally see through this ploy however since they know for experience that if all hell breaks loose (as it often does) the on-site DBA is a good scape goat.

Alternatively make a stand and refuse to do it (my preferred option). This is best for two main reasons.

1. It's your job to prevent bogus shit it the production DB and by shouting and making a stand you're being proactive and stopping it before it screws up. I usually suggest that they think about why I am there costing a fortune and refusing to do work. I mean, it's not normal is it? I'm usually a nice guy afterall ;)
2. The worst scenario is that the production system will be fubar and you'll be blamed and fired. "It's your job to stop this sort of thing" they'll say. And they'll be right. So say it now and be loud, documented and completely professional. Have arguments, procedures and a solution worked out first. OFA is a real good place to start (the FNG's won't have heard about it), then security.

If they force you to continue without listening, get it in writing, and then do it. Then see personnel (if you are permanent) about escalation procedures, your responsibilities and company policy. Look for another job. Nothing sucks arse more than tending a sick black box production system.

"Kevin Brand" <kevin.brandx_at_tel.gte.com> wrote in message news:afa4ke$51b$1_at_news.gte.com...
>
> 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 - 12:15:34 CDT