Comments on: Superfluous Updates ?

By: Nathan

Nathan — Tue, 17 Jul 2007 23:08:36 +0000

This is obviously an old post, but thought I would enter my 2 cents…

There are some very specific cases where “only updating modified rows” is very valuable, but I agree that (in general) it is not advisable.
Currently the only method to guarantee that a large update (think 60 columns) only updates rows where values change is to compare all of the columns in the “WHERE” clause. Developers have to do this themselves, which gets nasty with a large number of columns. I can’t help but think that if this were built into the kernal (and added as an optional keyword or hint, similar to how the APPEND() hint significantly alters how Oracle performs its work), that Oracle would probably be able to do this somewhat more efficiently internally (and would save developers the hassle of manually checking every column)…

While on the subject of annoying Oracle things – when Oracle is rolling back data, why does it not provide any way to either TRUNCATE or DROP the affected object and abort the rollback? Oracle can obviously detect which objects are affected (based on the locks), so why not let the affected objects be dropped and save the database resources for something useful?

By: Antonio

Antonio — Tue, 13 Mar 2007 11:33:16 +0000

@Wirasat J. Paracha

Because, sometimes, “divede et impera” is a good idea. :)

By: Wirasat J. Paracha

Wirasat J. Paracha — Tue, 13 Mar 2007 07:59:31 +0000

Why use many not-so-powerful processors working in parallel? Why not just design a single, really powerful processor?

By: Bind Variables « Oracle Scratchpad

Bind Variables « Oracle Scratchpad — Fri, 05 Jan 2007 22:17:45 +0000

[...] variables and some of the peripheral details that can introduce surprises; and in the article on superfluous updates I made a throwaway comment about getting multiple child cursors for a single statement if you had [...]

By: Jonathan Lewis

Jonathan Lewis — Thu, 04 Jan 2007 23:02:20 +0000

Robert, that’s a valid point – and once upon a time (ca. 5.1/6.0) there were noises coming out of Oracle about “column level locking” – i.e. you could update one column in a row whilst I was updating another column in the same row. Nothing ever came of it but if they had developed the theme then your comments would be more than just theoretically correct.

In fact my statement was concerned more about what currently happens and how I wouldn’t want it to change. That, of course, introduces the old argument – how much of our code works because of side effects of the current implementation rather than the specified effects. (Shades of the “group by”/”order by” argument – except the manuals were always pretty strong on warning that “group by” does not imply “order by”.)

By: Robert V

Robert V — Thu, 04 Jan 2007 22:40:16 +0000

Please consider this off-topic comment in response to a single, isolated statement of yours (ie. not in any way a response to your overall point). This one:

“If I update a row in a way that changes none of the columns I have still managed to lock the row and no-one else can modify it. If Oracle bypasses my update simply because it appears to be redundant then it may be subverting my intentions by leaving rows modifiable by other sessions when I want them locked.”

Wait a minute. You think that an update statement should GUARANTEE a certain row gets locked?

Update means update. It doesn’t mean lock. Locking is a means to an end.

Oracle promises you that the data integrity and consistency will be maintained while you do an update. It does not promise you that it will lock the rows. Locking the rows is simply the method in which they fulfill that data consistency promise.

When you say “I want to update these rows” I don’t think Oracle should imply “I want you to lock these rows.” Maybe more like “I accept that you may deem it necessary to lock these rows.”

No?

By: Colin 't Hart

Colin 't Hart — Thu, 04 Jan 2007 10:22:06 +0000

Not sure if this is interesting but a TRUNCATE on an empty table leaves the LAST_DDL_TIME field intact so it seems to be skipped. But altering a table and modifying the datatype of a column to the same datatype does reset the LAST_DDL_TIME (on 10.2.0.2)

Cheers,

Colin

By: Antonio

Antonio — Thu, 04 Jan 2007 08:46:07 +0000

I was trying to figure if (for some reason) Oracle move to the undo/redo the entire db-block (i.e some rows) or only the row and then mark (in some way) the row and the value to modify.

By: Jonathan Lewis

Jonathan Lewis — Wed, 03 Jan 2007 18:47:32 +0000

Antonio, I don’t quite understand your question – to update a row Oracle rewrites it with the new values, copying the old values to the undo record and (implicitly) to the redo vector for the undo record, and copying the new values to the redo vector for the table.

By: SeanMacGC

SeanMacGC — Wed, 03 Jan 2007 10:01:34 +0000

Great Jonathan,

And I’ve used the

“update HISTORY SET FLAG=0 WHERE CLASS = ‘X’ and FLAG != 0;”

more than just a few times, though usually as NVL(FLAG,-1) != 0 or similar, where it wasn’t possible to not-null the column, or just in case that not-null constraint would disappear at some future point.

Not so straightforward when we’re updating multiple columns of course, and it does get messy OR-checking each.

And yes, an ‘off-switch’ would be a very good idea should Oracle introduce such a smart update ‘feature’.