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

"SQLJoe" <sqljoe_at_aol.com> wrote in message news:20020520171940.09238.00000763_at_mb-mq.aol.com...
>
> >If I update the emp table, in Oracle, you can read the emp table, and you
> >will see the data as it was before I started updating it. That's the
> >rollback mechanism being used to generate read-consistent images of data.
> >
> >Try that in SQL Server (or Sybase etc etc), and you will discover that,
> >unless you force the issue, your select is blocked by my update. Only
when I
> >commit can you read.
>
>
> Actually, you are factually incorrect. MS SQL does provide INSERTED and
DELETED
> tables which allow you to view either inserted or deleted data BEFORE it
is
> comitted.
>

Actually, which of the words 'unless you force the issue' didn't you understand? I'm sure that inserted and deleted tables can be created to allow you to see the data before it is committed. That wasn't my point. What happens when you have a single emp table, I do an update and you do a select? You hang, that's what. Sure you can "deal" with the issue. But by DEFAULT, you hang. Which is not the case in Oracle at all. As I said: the issue with MS SQL Server and most other database products out there is concurrency. By default, out of the box, without effort, they lack it and Oracle doesn't.

As for someone else seeing *my* UNcommitted data : that isn't a particularly good idea in the first place. Whatever happened to the idea of transactions?

> As far as rollback is concerned, MS SQL does allow partial rollbacks and
have
> savepoints etc.
>

I would certainly hope so. But that wasn't what I was talking about either.

>
>
> >That's an architectural issue of the rdbms itself, and no amount of O/S
> >improvement or hardware will deal with it.
> >
> >Also architecturally-related is SQL Server 2000's insistence on 8Kb
blocks
> >("pages" if you prefer). That's performance limiting. Also it has a
problem
> >with long-running transactions (as does Informix amongst others) because
the
> >same mechanism is used for both transaction recovery and transaction
> >rollback. If your transaction takes up more than half the log, it
> >automatically fails, because it needs as much room to roll the
transaction
> >back as it took to generate it in the first place. Oracle's separation of
> >redo from rollback means that this simply isn't an issue for it.
>
>
> I bet this is one of the 20-30% of features in Oracle that most Oracle DBA
and
> Developers never end up changing or using.

You lose the bet, as a simple glance at the google archives for this group would have shown. Getting the block size right is a crucial step that every Oracle DBA thinks carefully about (if they're any good).

And I noticed you completely missed the point about long-running transactions.

>Chaning the page (or block) size
> rarely makes much difference.

Totally and utterly wrong, I'm afraid. It makes a huge difference. To contention, to concurrency, to speed of access to the data, to row migration, row chaining. You name it, block size is at the back of it somewhere.

>But I will admit Oracle allows you to configure
> the page (or block) size while MS SQL does not (set at 8KB).
>
> Jinsoo
> MCDBA, MCSD, MCSE+I
You seem well qualified in MS stuff. Good for you. But you also don't seem to know the ins and outs of Oracle DBAing yet (which I realise the thread title indicates). You can't really knock the stuffing out of a product ("it sucks") until you really know it.

For the record, I run a SQL Server database at home alongside 9i and 8i. It's quick to set up, dead simple to work with, and hasn't failed in about three months. It's a good product. But Oracle doesn't suck in comparison. They're completely different beasts.

Regards
HJR Received on Tue May 21 2002 - 03:53:49 CDT