Re: Newbie's Oracle 9i impression: it sucks

"SQLJoe" <sqljoe_at_aol.com> wrote in message news:20020522073126.21008.00000154_at_mb-fo.aol.com...
>
> >But you've still missed the point: I don't want to read uncommitted data.
> >Uncommitted data is data that's in flux for all manner of reasons. All I
> >want to be able to do is to read the *previously* committed version of
the
> >data, whilst you are in the *middle* of updating it, without being locked
> >out, and without having to code anything special to prevent the lock out.
>
> Before, a data is committed, is not in flux, the row is EXACTLY as it was
prior
> to the beginning of trasaction. Let me say this again, MS SQL perfectly
lets
> you read data when the same row is being updated. NO PROBLEM. You seem to
> indicate Oracle can do this while MS SQL cannot, this is simply not true.
>

Well, I'm afraid it is true. Read Niall's post.... he demonstrates the very fact I'm talking about. The reading session hangs because someone is updating the row.

>
> >What's more, when I start a report at 10.00am, that runs for 15 minutes,
and
> >arrives at the emp table at 10.09, I don't want that report to show me
the
> >data you committed in the emp table at 10.06, because my report should be
> >based on data that was there at 10.00am only. Oracle does that without
> >batting an eyelid. SQL Server doesn't.
> >
> >I see the block size and long running transaction issues got snipped
again.
>
> I already answered you on the block size.

Yes you did. You said you bet that no-one really bothered with it. I wasn't the only one to point out that most certainly every Oracle DBA *does* bother with it. And *that's* the bit you've conveniently snipped (or perhaps I should say simply that you chose not to reply to it?).

>MS SQL has "auto update" statisitics
> feature that automatically optimizes and updates index statistics in a run
and
> large trasnactions.

So what? That's wasn't the point. The point was, if a transaction runs for too long in SQL Server, such that it uses up more than half the transaction log, it fails, and rolls back. And that's because a transaction needs as much room in the transaction log to roll back as it needed to be rolled forward in the first place. Rollback and redo are combined into a single mechanism, which gives rise to this problem (and SQL Server isn't the only database to suffer this way). Oracle doesn't give a monkey's how long a transaction runs for, because redo and rollback are entirely separate mechanisms.

> >You asked for rational responses. How about dealing with the issues I
> >actually raised rather than talking about something I didn't? That, I
think,
> >would be rational.
> >
> >HJR
>
>
> I only replied on the issues to your post. Your ASSUMPTION that I raised
other
> issues is simply not true. Please point out any of my replies to you
which did
> not stick to the issue?

Well, mentioning that long-running transactions generate their own index statistics is one. I didn't mention statistics generation once. Describing how SQL Server can be *made* to allow concurrent reads and writes, when the point was that by default it doesn't, is another.

You really don't have much of an open mind on this, do you? You've made a decision that Oracle "sucks", and no matter what marvels of architectural design I or anyone else points out to you, you don't want to know or really address them.

Sad.
HJR
>
> Jinsoo
> MCDBA, MCSD, MCSE+I
Received on Wed May 22 2002 - 15:05:04 CDT