Hello Gentlemen,

I have a table which is the highest level table in my DB
design...ie...all tables have foreign keys that if the chain is
followed,  lead to this table.

This table had quite a few indexes (8) as well, however we have balanced
the issue of SELECT performance to INSERT performance and we have
internaly justified each indexe and removed some redundant ones.

Originaly my programmers would write UPDATE statments that updated all
the columns of the table, even though only 2 columns on that table could
ever have been affected by that code snipet.  This update, because of
the load on that table, would take sometimes over a minute to complete,
if it didn't rollback because of a timeout.

My first step was to have them rewrite their code to only update the 2
columns that could ever change in that snipet of code.  My logic behind
that was because some other columns, even though they didn't change,
would force the indexes to update themselves, causing a longer transaction.

None of the 2 columns left in the update are referenced by FKs, so I
assumed there is no need for an integrity check, all the way down the
pipeline.

However, its this assuption I am questioning.  When DB2 UDB 7.2 (NO
fixpak....so 7.1 FP3) does an update.....in the background, is it doing
a "phantom" DELETE/INSERT which is forcing a check of the integrity of
all the FKs underneath it?  Or is it doing just an UPDATE on the columns
specified in the command?

Any ideas?

Thank you in advance

Christos Kalantzis