Re: Article about supposed "murky" future for Oracle

"Thomas Kyte" <thomas.kyte_at_oracle.com> wrote in message news:7b0834a8.0403301613.139154b0_at_posting.google.com...
> "rkusenet" <rkusenet_at_sympatico.ca> wrote in message news:<c4cifo$2h5tbc$1_at_ID-75254.news.uni-berlin.de>...
> > "Thomas Kyte" <thomas.kyte_at_oracle.com> wrote
> >
> > > Well, I didn't prove that really -- the point I made on page 35 was
> > > that
> >
> > ha ha. this is getting better. So what Daniel Morgan has been doing
> > is blindly believing oracle marketing hype. Not very smart of him.
> >
>
> I would hardly call it marketing hype. I know how the other databases
> work, I've worked with them as well

The 'hype' I was referring to was the statement by Daniel Morgan that "it is IMPOSSIBLE to get a read consistent view for a large set of rows" in sqlserver. Note the word impossible.

I am sure that few things can be done in Oracle, impossible in other products. But I don't think this is one.

> the problem is -- unless it holds the lock until it resolves the
> entire query (or locks all rows up front) you are *not* getting a read
> consistent result set. (and if it does hold the lock, i would hardly
> call that "very short" if it takes 5 minutes for my query to execute)
..
deleted.

What u have mentioned is true. no dispute there. The momentary lock is obviously dependent on the number of rows. Based on my experience a properly tuned system can return read consisten rows for many thousands of rows within few seconds. Anything more than that, it is definitely a problem and has to be solved at the application level.

> and how would a temp table (which is what a scroll cursor in informix
> is doing under the covers -- copying the data off to the side) solve
> anything?

one obvious difference between an INTO TEMP and SCROLL CURSOR is the parallelism in writing. INTO TEMP is parallel written into different dbspaces, increasing the performance by an order of magnitude. That's why I prefer INTO TEMP for a read consistent query.

However, as Serge has pointed out effectively, versioning comes at a cost. I don't have to look any further than my company where we use some tables as work flow tables. Some tables are used to only hold results from different processes inserting rows asynchorously. Almost like using objects in memory for work flow queue. it is our requirement that rows are displayed on the fly. Meaning, as the user is munching first set of rows, more rows is being pumped into the table. Using an unlogged database, with dirty read (each session queries its data only), we get very efficient performance. We just don't care about the transaction state because the data is only transient. Effectively the data is written and read directly in memory (BUFFERS).
I would like to know how this can be done as efficiently in Oracle. This is not a troll. Based on the feedback I recvd from various sources, it seems not. Received on Tue Mar 30 2004 - 19:47:33 CST