Re: Would READ Be Block

DA Morgan wrote:
> joel-garry_at_home.com wrote:
> > In addition to what the others say, Oracle's read-consistency mechanism
> > may mean it could take a while for Oracle to actually get all the stuff
> > it needs together to present the data to you. So your read is not
> > blocked, but you might have to _wait_ a long time. Perhaps longer than
> > a client software timeout, for example.
> >
> > See also ORA-1555 discussions.
> >
> > A properly configured system shouldn't have such problems. But always
> > is a long time.
> >
> > jg
> > --
> > @home.com is bogus.
> > http://www.thenonist.com/downloads/thenonist_blog_depression.pdf
>
> I'm confused by your response. I can't see any possible way an ORA-01555
> relates to the question nor what you refer to when you stay "wait a long
> time" nor do I see how a client time-out setting relates. Can you
> clarify your thinking? Thanks.

ORA-01555 - Just have a long transaction with a too-short undo retention. Read near end of transaction fails. Because something else wrote to something in the block after the long transaction started. I could see a newby being confused by that, but it should be obvious.

9iAS Portal on "remote" DB's had some pretty severe issues with returning large result sets. It wouldn't wait as long as a patient user, and it could be confusing what one had to set to reduce the timeout.

Then of course there's all the internal stuff like running out of transaction slots and all the wait stuff one might see with traces that could prevent a read from being returned in a timely manner, really BAD SQL, thrashing on the undo, general bad tuning, sort and tempfile issues, and the general MTS architecture... So, a read doesn't have to be technically blocked by a writer to not be returned by the db. The phraseology about readers not being blocked is true, but is not the whole story. One usually reads a row for a purpose. And recall the OP was "...absolutely no other factors could really block a read?" That expands the meaning of "blocked" beyond what we mean with the usual phraseology, to "will I definitely get the data when I need it?" The answer to that is, not necessarily, partly handled by error trapping, partly handled by proper administration, sometimes its just one of those things called a "learning experience."

And then there's bugs 'n hardware.

I do not understand why I'm being accused of FUD, these are not secrets, and all brands have idiosyncratic issues, and all are worse than Oracle for most multiuser business programming cases. MS sucks so bad its advocates can't even see why.

jg

-- 
@home.com is bogus.
http://shop.store.yahoo.com/lv/