Re: venting my spleen

Comments embedded
"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.

Maybe, maybe not. They don't say how you spread the datafiles for the tablespaces I presume. At least you can revoke quotas on other tablespaces.

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

Or create index.... I tend to agree though.Almost certainly you will find that the app creates 'temporary' which is to say permanent tables on the fly. It probably drops them as well. I can't for the life of me work out why you would need a pre-existing table in a specific tablespace unless you drop and recreate it in a procedure.

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

Indeed. why do they need to start and stop the instance. That is your job.

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

Hmm yes well.

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

It sounds like you have an app that is coded 'generically' IE to run on multiple db platforms. That almost certainly will mean that some of your problem sql could be coded better but would use Oracle specific features. It might mean that a lack of understanding of how Oracle works leads to logical flaws in the code (but this is less likely).

It also sounds like you have a development team that have little or no Oracle experience. This really would give me cause for concern but ought to be soemthing you can find out. Note having team members with little Oracle experience isn't something I'd shout about - we all need to learn - having a team where no-one knows what sql*plus is does scare me.

HTH

--
Niall Litchfield
Oracle DBA
Audit Commission UK
*****************************************
Please include version and platform
and SQL where applicable
It makes life easier and increases the
likelihood of a good answer

******************************************