Path: news.easynews.com!easynews!news-xfer.siscom.net!news.stealth.net!novia!novia!sequencer.newscene.com!not-for-mail From: Galen Boyer Newsgroups: comp.databases.oracle.server Subject: Re: Another angle on this.... Date: 3 Mar 2002 22:30:06 -0600 Lines: 40 Sender: Galen@GALEN Message-ID: References: <3C7144EB.7CA04F3A@ci.seattle.wa.us> Original-Sender: galenboyer@rcn.com User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Xref: easynews comp.databases.oracle.server:137338 X-Received-Date: Sun, 03 Mar 2002 22:01:45 MST (news.easynews.com) On 3 Mar 2002, ganesh@gtfs-gulf.com wrote: > Galen Boyer wrote in message >> Can you point me to where this was written about? I was under the >> impression that once data was committed it was able to be seen by >> all. I'd like to be aware of when this isn't the case. > > Take the Case of a Select Stmt that Started at Time A. And an Update > Stmt that Started A+1. The Update Stmt Updated the Records and > commited the same at A+2 Butthe select is still Running and once the > select see the ITL on the Block it goes to The Rollback to get the > Consitent View as of Time A and will not return u the commited record. > > This is also given as an example for Ora-01555 Errors that arise out > of select stmts. After thinking about your response for a bit, it made total sense. Oracle is just making sure that you have the consistent state based on the time your query started. For it to figure out that the commit happened before the actual row was read by the select seems like it could get hairy but this behaviour seemingly would give you the most current data possible. Plus, you can figure out when a query began and then you could figure out when an update happened, but you couldn't figure out when Oracle actually made it to the row in question during the query. Hm... well someone much more skilled than I probably could based on a raw trace file and looking at the non-current reads of data blocks but I don't think you actually see the reading of blocks broken down by time anywhere in any trace file no matter what event you might have enabled. (This would be one monster trace file if you did) Therefore, the reading process result's could get confusing and unreliable if you tried to go back and figure something out about the retrieved data. The reading of that committed row after your select started could also violate some Codd principle, and Ellison (Oops I mean God) knows we wouldn't want to do that. :-) -- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.