<ctcgag_at_hotmail.com> wrote in message
news:20030127150608.862$S9_at_newsreader.com...
> "Paul Brewer" <paul_at_paul.brewers.org.uk> wrote:
> > "vlad" <bulk_at_sfatcu.com> wrote in message
> > news:me7Y9.15345$_s4.14132_at_rwcrnsc54...
> > > > > Now, I understand, that given the time and resource limitations we
> > > > > all
> > > live
> > > > > under, Oracle maybe couldn't do all this and still charge a
> > > > > reasonable
> > > price
> > > > > for its software. Still, an architecture liable to abstruse errors
> > like
> > > > > "delayed block cleanout" simply sounds incomplete to me.
> > > >
> > > >
> >
> > 1555 with 'delayed block cleanout' really means:
> > "I'm sorry, so much has changed since you asked, that I'd rather not
> > answer the question than give you a false or misleading answer".
>
> Or, 1555 (with or without delayed block cleanout) really means:
> "I'm sorry, I've failed to maintain sufficient information to give you
> an accurate answer to your question."
>
>
> > This means (as Jonathan put more succinctly), that you need to decide on
> > what are your particular definitions of 'now' and 'the truth'.
>
> The particular definitions that Oracle uses for when it
> doesn't respond with 1555 would suffice, I think.
>
> > How do you
> > propose reporting on other users' uncommitted transactions? Or those
> > which have been committed since the start of your query?
>
> I don't think Vlad is asking Oracle to return inconsistent data in lieu
> of 1555s, but rather asking it to realize what's going on and take
> appropriate actions to prevent the need for 1555s in the first place.
>
> I don't know whether he thinks this can be done without a major
> performance impact, or if he has such a puritanical view that he doesn't
> care about the impact.
>
>
Fair enough, on most counts. But for how long does Vlad feel that Oracle
should retain the old data on transactions committed after his query has
started?
I fear we are back to square one..."until all queries needing these data
have finished".
Regards,
Paul
Received on Tue Jan 28 2003 - 15:21:16 CST
