Re: Re[2]: Dirty reads

From: <Frank.Dodgers_at_janus.com>
Date: Wed, 4 Oct 2000 10:14:33 -0600
Message-Id: <10639.118483@fatcity.com>

--0__=OknPDI6teGCozTkV4WuoTVENBtFN10k47UpntOeWnLclhYuxQjWeGv96
Content-type: text/plain; charset=us-ascii Content-Disposition: inline

I'm happy to see this post - I've been confused for some time too. But I think it has to do with BIG-BLUE, BIG-IRON, DB2, SERIALIZATION (reads are not by the way), and the mind-set of antique CICS, DB2, OLTP application end-users and programmers. UDB, the modern version of DB2, looks more like Oracle than DB2, especially when it comes to pessimistic vs. optimistic locking.

The basic model in IBM BIG IRON land is that once a JOB, TRANSACTION, LOGICAL UNIT OF WORK, etc. starts, it shouldn't be interrupted. This is based upon the notion that there is a BIG ASS CPU that churns out serialized work like "doodoo through a goose". Of course, latency, two-phase-commit, replication, etc. all tend to foul this up. And, IBM says that you can tune and tailor DB2 to not serialize if you want, but no one in MVS land knows how (or even why) because they just now got IP connectivity and they have no hope of figuring out non-persistency. But that BIG-IRON is expensive...........and hay some of my best friends are IBMers

Big picture..............Oracle started a couple of years ago pushing to make ORACLE work on MVS. Why? Because that is where all (or most) the real data in the world lives. So voile, we now have DIRTY READS in ORACLE. Thank you, so much, IBM.

Frank

"Jim Conboy" <Jim.Conboy_at_trw.com> on 10/04/2000 10:15:26 AM

Please respond to ORACLE-L_at_fatcity.com

To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> cc: (bcc: Frank Dodgers/Janus)
Subject: Re: Re[2]: Dirty reads

Am I the only one with no imagination? How is uncommitted data of any practical value? Of course I can see the desire to read data as up-to-date as possible, but if the possibility exists that the data read is 'wrong' I can't see any advantage to this, and loads of potential harm.

Jim

>>> dgoulet_at_vicr.com 10/04/00 11:06AM >>> The subject of "dirty reads" has been around for as long as I've worked with Oracle, which started back in 1985. It's basically a forbidden subject. I know DB2 allows this and there are others who would like it since rollback segments would become unnecessary from their point of view (it would also make some batch processing a little more error free). But in looking at the ANSI SQL standard book that I've got here, dirty reads are NOT standard behavior, actually it's prohibited!!

Dick Goulet.

____________________Reply Separator____________________
Author: "Ron Rogers" <RROGERS_at_galottery.org>
Date:       10/3/00 1:11 PM

I don't think that Oracle would allow it because until the commit is issued the other users see the "old" data and the user making the changes sees the new data. If the user wants to see both copies of the data have them login twice. One to make the changes and the other to view the original data. To circumvent Oracle's method of data integrity would destroy the foundation building blocks of the database
ROR
--0__=OknPDI6teGCozTkV4WuoTVENBtFN10k47UpntOeWnLclhYuxQjWeGv96

Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable

=AA=BF=AA

>>> turner_at_tellme.com 10/03/00 03:51PM >>> Is there any way to say I want a select that won't look at the rollback=

segment? The user doesn't care if it's a dirty read.

Dave Turner

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: David Turner
INET: turner_at_tellme.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Ron Rogers
INET: RROGERS_at_galottery.org

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author:
INET: dgoulet_at_vicr.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

--

Please see the official ORACLE-L FAQ: http://www.orafaq.com
--

Author: Jim Conboy
INET: Jim.Conboy_at_trw.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message