Re: Is it possible to use nolock type of hint in query - RANT #2

On 8/11/06, Ethan Post <post.ethan_at_gmail.com> wrote:

> I am surprised to see so many negative reactions to this feature. First
> off, I want to be able to do what I want to be able to do. Having a feature
> like this is not a bad thing just because it can be used in bad ways.
>

I disagree, at least somewhat. Sometimes a feature can be used for bad things, despite being good. Other times its just plain bad. Here it seems to me its just ill-educated.

The first situation I'd illustrate with nuclear power in particular and nuclear research more generally. I happen to think its a good thing with very bad downsides. I might be amenable to convincing about this if someone can come up with a good objection to my third observation. Or at least a convincing objection, if not good.

The second situation I illustrate with visual basic in general (and vb script in particular). This language, prior to the .Net incarnation which I am not complaining about, does not have data types. That is a date is not constrained to be a date and so on. Plenty of programmers like this, but its just plain bad. It gives us security vulnerabilities, obscure and intermittent bugs and so on - and yes before anyone asks SYS.ANYDATA is an abomination for the same reasons. Me I think allowing dirty reads, that is decision making based on transient states that no-one is sure about, falls into this category for the reason below

I just think that requests for dirty-reads always boil down to, I want to see what might happen, not what I know has happened. This means that we are explicitly saying that we don't want ACID transactions. We don't want transactions to be autonomous, and we don't want them to be independent, arguably we don't want them durable either if my session reading uncommitted data is committed and then the power goes we lose what made the transaction happen - the data is durable, but the reasons for it aren't. This either means that we've defined our transaction scope incorrectly - quite possible, or that we don't understand what a transaction is.

so, no uncommitted reads for me. I like Norman's argument as well :(

>
> Secondly, I can think of plenty of situations where I would have like to
> have seen how many rows a session has commited into a particular table
> etc...and the calls for logging are well taken, but the fact is we all
> manage a lot of systems that don't have this and never will because
> we...don't own the source, can't herd the cats...etc...
>

The example isn't how many rows have been comitted into a table, but how many rows might be committed if the user doesn't change their mind, doesn't crash the client program or the data centre doesn't blow up. Even the transaction where the clerk has just realised that she didn't specify a where clause and is about to delete everything and so is going to press the cancel button just after you take account of the delete. Incidentally if you want to count uncommited row modifications, just turn on table monitoring.

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

--
http://www.freelists.org/webpage/oracle-l