Re: Is Oracle deliberately difficult?

"Jay M. Scheiner" <jxs_at_wolpoff_nospm_law.com> wrote in message news:39ae62ac.406675506_at_news.erols.com...
> See inline comments, this is response to the 2 previous posts:
>
> On Wed, 30 Aug 2000 20:01:52 +1100, "Howard J. Rogers"
> <howardjr_at_iprimus.com> wrote:
>
>
> >As for the bill stuff -I guess your objection is that our customer is
 going
> >to be sent a reminder letter despite the fact that they've paid up. That
> >sounds like normal business practice to me: "Payments received after Xth
> >September will be included on your next statement" is a phrase I see
> >constantly. Along with "If you have already made payment, please
 disregard
> >this reminder".
> The principle should be considered here, not the specific example.
> You've got a database record that you shouldn't be doing something
> with (logically) and you are doing it. I could create examples where
> that is a REAL problem, but the point is the theory, not 1 specific
> example.

Hang on. The fact is someone is doing something to a record. The question is: do you not want to see that record at all whilst it is under update, do you want to see its prior value, do you want to see its current value, or do you want to see something that says 'something dodgy is going on with that record right now so I don't know what to show you'.

I'm happy with any of those responses, but I wish you people would tell me what the *right* response is. Personally, and thinking as abstractly as I can, it seems reasonable to me to show me the value that we all had agreed earlier to be the correct one. The fact that it is currently undergoing change -well, you could be doing anything, and I wouldn't want my reports to pick up on experimentation you're about to roll back.

> >>
> >> 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.
> >>
> >
> >I don't know about effort. But then I take a cavalier approach to these
> >things: I aim for one giant extent per segment, and am happy to rest
 content
> >with all that space sitting there empty for most of the time, knowing
 that
> >it will be used eventually. Hard disks are cheap, and I'd throw more
 hard
> >disks at the problem rather than worry about extent management. All
 extents
> >within a given tablespace should be the same size anyway, and 8i's local
> >management of tablespace makes that a painless task these days.
> >
> >And there's really no debate about block size these days (despite what
 some
> >people would have you believe). For most Unixes it's 8Kb without
 thinking,
> >and same for NT. www.ixora.com.au has the details.
> >
> In the previous reply, Jerry Gitomer wrote:
> 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.
>
> So, we've got 2 Oracle experts, 1 says 'no debate- 8K' and 1 says 'max
> that Oracle supports'. This is easy? Right?
>

I don't claim to be an expert, and I can't speak for Jerry. But there's no fundamental dispute, except that Jerry (as characterised by you) has rather forgotten the operating system. You *should* go for the biggest blocks you can get (and hence that Oracle supports). It just so happens that most operating systems don't support direct I/O and that for sundry assorted technical reasons that Steve Adams will happily explain, you end up with a decision for 8K or 16K blocks (and for most o/ses you opt for the 8K option). It's a compromise between what Oracle would prefer, and what the operating system can effectively manage.

Your characterisation of the debate as being between two completely and contradictory different views is wrong.

Regards
HJR Received on Fri Sep 01 2000 - 10:39:22 CDT