Re: venting my spleen

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