Re: Is it possible to use nolock type of hint in query - RANT #2
- From: "Niall Litchfield" <niall.litchfield@xxxxxxxxx>
- To: post.ethan@xxxxxxxxx
- Date: Mon, 14 Aug 2006 12:51:28 +0100
On 8/11/06, Ethan Post <post.ethan@xxxxxxxxx> 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
Other related posts:
