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

"SQLJoe" <sqljoe_at_aol.com> wrote in message news:20020522184228.24233.00000378_at_mb-dh.aol.com...
> HJR wrote:
>
> >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.
>
> I was going to respond to nail's post but I got disconnected. Let me
respond
> now..
>
> AGAIN, you can read a row that is being updated in MS SQL using a read
> uncomitted isolation level.
>
> In the sesion 2 in his example, you can use the following
>
> use northwind
> select "query" with (readuncomitted)
>
> Here is the Microsoft's documentation on read uncomitted isolation level.
>
>
> READ UNCOMMITTED
>
> Implements dirty read, or isolation level 0 locking, which means that no
shared
> locks are issued and no exclusive locks are honored. When this option is
set,
> it is possible to read uncommitted or dirty data; values in the data can
be
> changed and rows can appear or disappear in the data set before the end of
the
> transaction. This option has the same effect as setting NOLOCK on all
tables in
> all SELECT statements in a transaction. This is the least restrictive of
the
> four isolation levels.

I DON'T WANT TO READ UNCOMMITTED DATA. I WANT A CONSISTENT IMAGE OF MY DATA, AT THE TIME MY REPORT BEGAN.
>
> >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.
>
> I think you are too stuck in your Oracle mind.

Nothing like ducking the issue, is there?

>The fact is MS SQL beats Oracle
> in performance.

Who said anything about performance? What's the use of running at the speed of light of my long-running transaction konks out half way through lack of rollback space?

>Here is the link if you want to know the truth.
>
> http://www.tpc.org/tpcw/results/tpcw_perf_results.asp
>
>
> I think it is sad you are still in denial. But that is your loss
>

I think it is obvious what your loss is. Something that usually resides between the ears and behind the forehead.

HJR
> Jinsoo
Received on Thu May 23 2002 - 06:37:42 CDT