Re: Is Oracle deliberately difficult?

Comments inline

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 8/29/00, 9:55:36 AM, jxs_at_wolpoff nospm law.com (Jay M. Scheiner) wrot e
regarding Re: Is Oracle deliberately difficult?:

> Based on my 3 years experience with a mainframe database (Unisys
> DMSII) and my 1 year self-taught and part time experience with Oracle,
 

> I can give a few specific examples of things about Oracle that I am
> finding difficult. Perhaps they are second nature to more
> experienced, or more formally trained, Oracle people, but here they
> are:
 

> 1) Rollback segments and related issues.
 

> I don't know if it's an ANSI standard, or just the way things
> developed, that when you do a SELECT it is supposed to be consistent
> with the state of the database when the query started, but I don't
> think it makes the best sense. Say you're going to look through your
> whole customer list for everyone who has a bill over 90 days due and
> send them a nasty letter. You start the select, then someone in
> bookkeeping posts a payment on an account. However, your select
> doesn't see that. I KNOW that it could have happened that the
> statement was past that account by chance anyway, but if it WASN'T,
> then why is the Oracle way the best way?

        I won't claim that Oracle's way is the best way, but it tends to reflec t
the way most organizations operate. Things like dunning letters are sen t
out at the end of the accounting cycle to those whose payments weren't received in time to be included in the current period statements. In general organizations operate on a cyclical basis with reports being generated at fixed points in the cycle.

> 2) Space management
> Oracle makes you do too much work with worrying about extents, block
> sizes, etc. You can justify some of it by saying you can tweak your
> performance, but not for what the effort seems to be.

        Block sizes are set when you create a database. The big issue is whether or not to go with the maximum block size Oracle supports. The general consensus is that for most databases you should go as big as Oracle will support. You can avoid extent issues by adopting Uniform Sizing for your tablespaces. This involves making every extent in a tablespace the same size. Incidentally, don't worry about the number of  

extents too much. Ideally you should put tables in tablespaces that wil l
hold them in five or less extents, but even if you go way over your database won't crash and you probably won't see to big a performance hit .
 (Earlier this year I was working with a client who has a table with 350 0
extents and -- much to my surprise -- the system didn't crash and burn and performance wasn't too bad.)

> 3) Process management
> It seems to be someone of a chore to deal with who is locking the
> database, what is running at what priority, batch vs. online
> transactions at the same time, etc.

        In general you shouldn't try to second guess the Oracke database engine  

• it's like trying to fool Mother Nature. In other words don't explicitly lock anything.

        Priorities are an operating system issue and again the best rule is unless you really understand the system software, your applications, and  

your organizations needs extremely well you are better off to just let everything run at the same priority.

        Batch vs. online is a performance issue. If it gives you problems buy a
bigger box.

> I know there are solutions to these, but they are some of the big ones
 

> that I have dealt with.
 

> On Mon, 28 Aug 2000 22:16:25 +0100, Sid James <sid.james_at_virgin.net>
> wrote:
 

> >I've been learning Oracle for a while now and I do think of it as qui
 te
> >challenging in an enjoyable way. I don't use Enterprise Manager, I'd
> >rather get to to know the 'nuts and bolts'. However, having done a SQ
 L
> >Server administrator's course, I can't help thinking that Oracle is
> >rather more difficult to use than maybe it should be.
> >
> >Sensible, rational responses that shoot me up in flames are always
> >preferable!
> >
> >e d

>
> Jay M. Scheiner
> Programmer/Analyst
> Wolpoff & Abramson, LLP
> remove nospm from email address
> Opinions are my own only!
                  Received on Wed Aug 30 2000 - 00:03:51 CDT