Re: venting my spleen

This sounds all too familiar. If when the development team arrive and the first thing that they ask for is a DBA priv. account (or the SYS password) and then need help using SQL*Plus (or as is usual, insist the TOAD be installed because they have scripts that only work in it etc etc), then almost always you have a team with no experience, usually graduates from a big consultancy and a month of Oracle training. Or maybe I have bad luck that way.

There is little that you can do at this point. Talk to your client / your boss and tell them you are concerned about security / stability / your future share values etc. Then make sure that you test the backup and recovery procedures. Really. Test them. Alot.

I was working at a client in your position a couple of years ago (although not with the team in question) where they were implementing customisations for Oracle Applications in a working system. They had all the passwords changed back to the defaults on the production system because they'd spent 3 months writing scripts with the passwords from the (default) development system hardcoded in them. THE SAME DAY this happened one of them (we never found who because they all logged on with the same generic user id APPS) dropped a production table. Lots of overtime for me, lots of unhappiness for the client.

I'd put everything I was unhappy about DBA wise in a document to the client and the development team manager beforehand, so instead of roasting me for poor DBAing, everything that I'd said needed to be changed was. Perhaps you'll fair better and get them into good habits before something is lost.

"Ed Stevens" <spamdump_at_nospam.noway.nohow> wrote in message news:3d186843.90515654_at_ausnews.austin.ibm.com...
> 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.)
Received on Tue Jun 25 2002 - 09:20:49 CDT