Re: Setting Dirty Reads or No Lock for SELECT

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:<3b161b79_at_news.iprimus.com.au>...
> Come on! To suggest that snapshot too old is an outcome of Oracle's refusal
> to do 'dirty reads' is a bit like saying that we'd prefer it if people
> karked it from communicable diseases because refrigerating the vaccines is a
> tad inconvenient on the electricity bill.

While I agree "disk space is cheap", it is meaningless.

A question was posed.

Rather than answer the question with:

"You can't do that and this is why."

It was answered with:

"You don't need to do that, and you must be a moron (or incompetent) if you THINK you really need to do that."

There is no such thing as infinite space or time. No matter how cheap disk is.

I'd REALLY like to be in the middle of a load/build/update and query the uncommitted data currently being written. From a different session. I'd also like to have a long running query to grind against the whole base for a few hours NOT abort just because it was being updated. I do "marketing" data. This means 5% of it is CRAP anyway. If I get 95% valid, and did not have to copy the base or shut it down to others, it's a major win!

Sure, I also like Oracle's usage of rbs for read consistancy, but I want to be able to choose. Just like I have the option whether to write logs. Make it safe and consistent by default, give me dirty reads as a "expert" option. Make it a "hidden" variable in init.ora, force me to bounce the instance to enable it, make it unsupported, I don't CARE, just let me do it knowing the data is in a state of flux!

And to compare this desire to allowing people to die to save a few bucks on electricity has GOT to be the height of hyperbole. Received on Thu May 31 2001 - 10:21:24 CDT