Re: Setting Dirty Reads or No Lock for SELECT

"broom" <broom_at_voicenet.com> wrote in message news:c948eb61.0105301836.270a0096_at_posting.google.com...
> While the others state you don't "need" to specify
> "dirty", they must not have ever gotten the message
> "snapshot too old" and had a select abort because
> of it.
>

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.

Yes, as you go on to say, rollback segments need to be managed carefully, and there needs to be sufficient rollback to allow read-consistent images of the data always to be generated, but (a) there's no excuse for an insufficiency of rollback segment these days (disks are cheap); (2) what are you doing that requires vast amounts of read consistent data in an OLTP database?, because whatever it is, it's probably inappropriate and (3) visit ixora.com.au, and you will discover some scripts that guarantee never another 1555 in your life-time (disk space willing).

The fact that we don't sit around for ever waiting for people to commit is an unmitigated blessing.

The fact that we don't have to force a read on data we know to be likely incorrect is likewise.

The extra management involved in 'making it so' is worth it, and isn't really that dramatic.

Regards
HJR
> If you are doing very large reads against an updating
> table, make sure your RBS allocation can hold the whole
> thing. If you find a way to do dirty reads, let me know.
Received on Thu May 31 2001 - 05:22:20 CDT