been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.
i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.
surfed this group and google, but couldn't find anything.
the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.
seems to be the worst possible performance scenario??
16  3832 
"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om... been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.
i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.
surfed this group and google, but couldn't find anything.
the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.
seems to be the worst possible performance scenario??
I'm a Java developer but I've never used Data Access Objects so I may not be
qualified to comment on this question.
However, I would be quite astonished if "the engine" _EVER_ "just decides,
screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party add-on
to DB2.)
Frankly, I've never heard so much as a whisper of a hint of a rumour of a
suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or another
for 20 years.
As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change from
one to the other.
Of course, I *could* be wrong....
Having said that, an *application* which uses DB2 should be able to turn an
update statement into a delete/insert. For instance, if a user submitted a
query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'
I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10% raise in
salary.
Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that they
could be copied to the new row during the insert.
However, there could easily be important side-issues with respect to related
data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows in
tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)
By the same token, the delete in the Employee table would fail if there was
a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if you
chose to convert an Update into a Delete/Insert combination.
After all, you wouldn't want an update in one table to cause all sorts of
data to be deleted just because you thought you might get a slight advantage
by turning one Update into a Delete followed by an Insert.
Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you are
after. Then I - or others on this newsgroup - could try again.
Rhino
I'd beg to differ just a little bit here.
IN DB2 UDB for LUW:
Multi Dimension Clusterd tables.
If one updates one of the columns chosen as a dimension, the only way
DB2 can deal with this to maintain clustering is to delete the row where
it lived in its block and insert the row with the new dimension in its
proper block.
Apart from this I'd totally agree with Rhino.
Rhino wrote: "robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...
been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.
i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.
surfed this group and google, but couldn't find anything.
the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.
seems to be the worst possible performance scenario??
I'm a Java developer but I've never used Data Access Objects so I may not be
qualified to comment on this question.
However, I would be quite astonished if "the engine" _EVER_ "just decides,
screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party add-on
to DB2.)
Frankly, I've never heard so much as a whisper of a hint of a rumour of a
suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or another
for 20 years.
As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change from
one to the other.
Of course, I *could* be wrong....
Having said that, an *application* which uses DB2 should be able to turn an
update statement into a delete/insert. For instance, if a user submitted a
query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'
I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10% raise in
salary.
Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that they
could be copied to the new row during the insert.
However, there could easily be important side-issues with respect to related
data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows in
tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)
By the same token, the delete in the Employee table would fail if there was
a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if you
chose to convert an Update into a Delete/Insert combination.
After all, you wouldn't want an update in one table to cause all sorts of
data to be deleted just because you thought you might get a slight advantage
by turning one Update into a Delete followed by an Insert.
Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you are
after. Then I - or others on this newsgroup - could try again.
Rhino
--
Pierre Saint-Jacques - Reply to: sesconsjunk at attglobaljunk dot com
Reconstruct address: Remove the two junk and replace at and dot by
their symbols.
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.
I'd beg to differ just a little bit here.
IN DB2 UDB for LUW:
Multi Dimension Clusterd tables.
If one updates one of the columns chosen as a dimension, the only way
DB2 can deal with this to maintain clustering is to delete the row where
it lived in its block and insert the row with the new dimension in its
proper block.
Apart from this I'd totally agree with Rhino.
Rhino wrote: "robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...
been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.
i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.
surfed this group and google, but couldn't find anything.
the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.
seems to be the worst possible performance scenario??
I'm a Java developer but I've never used Data Access Objects so I may not be
qualified to comment on this question.
However, I would be quite astonished if "the engine" _EVER_ "just decides,
screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party add-on
to DB2.)
Frankly, I've never heard so much as a whisper of a hint of a rumour of a
suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or another
for 20 years.
As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change from
one to the other.
Of course, I *could* be wrong....
Having said that, an *application* which uses DB2 should be able to turn an
update statement into a delete/insert. For instance, if a user submitted a
query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'
I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10% raise in
salary.
Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that they
could be copied to the new row during the insert.
However, there could easily be important side-issues with respect to related
data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows in
tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)
By the same token, the delete in the Employee table would fail if there was
a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if you
chose to convert an Update into a Delete/Insert combination.
After all, you wouldn't want an update in one table to cause all sorts of
data to be deleted just because you thought you might get a slight advantage
by turning one Update into a Delete followed by an Insert.
Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you are
after. Then I - or others on this newsgroup - could try again.
Rhino
--
Pierre Saint-Jacques - Reply to: sesconsjunk at attglobaljunk dot com
Reconstruct address: Remove the two junk and replace at and dot by
their symbols.
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.
"Rhino" <rh****@NOSPAM.sympatico.ca> wrote in message news:<Yc********************@news20.bellglobal.com >... "robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om... been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.
i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.
surfed this group and google, but couldn't find anything.
the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.
seems to be the worst possible performance scenario??
I'm a Java developer but I've never used Data Access Objects so I may not be
qualified to comment on this question.
However, I would be quite astonished if "the engine" _EVER_ "just decides,
screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party add-on
to DB2.)
i have this irrepressible lower brain stem memory that some databases
(not for certain db2, hence the question), do just that.
Frankly, I've never heard so much as a whisper of a hint of a rumour of a
suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or another
for 20 years.
As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change from
one to the other.
Of course, I *could* be wrong....
Having said that, an *application* which uses DB2 should be able to turn an
update statement into a delete/insert. For instance, if a user submitted a
query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'
I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10% raise in
salary.
Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that they
could be copied to the new row during the insert.
thus handing over the responsibility for data concurrency to the application.
just the sort of thing that irritates my piles. see following.
and preceding.
However, there could easily be important side-issues with respect to related
data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows in
tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)
By the same token, the delete in the Employee table would fail if there was
a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if you
chose to convert an Update into a Delete/Insert combination.
After all, you wouldn't want an update in one table to cause all sorts of
data to be deleted just because you thought you might get a slight advantage
by turning one Update into a Delete followed by an Insert.
Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you are
after. Then I - or others on this newsgroup - could try again.
two, related concerns (sorry if my OP was obtuse):
- updating every column of each updated row has *got* to be too expensive
for words; far more (if it's ever been quantified) than the 1 or 2 or 3
columns actually changed. are there published stats on the performance
impact?? that is: at what point, either number/type of columns, or
average byte count, etc. is the penalty so large that whatever (coder)
time saved in development by relying on a code generation tool is
overwhelmed by the run-time penalty of updating all columns?? OR, is
DB2 smart enough to see that the incoming column data matches in
table data, and says, "screw it. it ain't different. i ain't
touching it"???? in this scenario, using code generating tools is
not a bad thing, beyond the fact that folks soon forget what their
data looks like.
- if DB2 sees that the row is being nuked, does it escalate (as it does do
with locks) to insert/delete (or vice versa, of course). and, another
if, so is this more or less expensive than doing the in-place insert?
an optimizer might consider "all aspects", and thus, basically, make
a mistake from a performance point of view??
clearer? somewhat existential and theoretical. antidote for RNC
blathering.
Rhino
"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om... "Rhino" <rh****@NOSPAM.sympatico.ca> wrote in message
news:<Yc********************@news20.bellglobal.com >... "robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om... been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.
i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.
surfed this group and google, but couldn't find anything.
the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.
seems to be the worst possible performance scenario??
I'm a Java developer but I've never used Data Access Objects so I may
not be qualified to comment on this question.
However, I would be quite astonished if "the engine" _EVER_ "just
decides, screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party
add-on to DB2.)
i have this irrepressible lower brain stem memory that some databases
(not for certain db2, hence the question), do just that.
That's quite possible but I don't know the other databases well enough to
say yes or no with any certainty.
Frankly, I've never heard so much as a whisper of a hint of a rumour of
a suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or
another for 20 years.
As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change
from one to the other.
Of course, I *could* be wrong....
Having said that, an *application* which uses DB2 should be able to turn
an update statement into a delete/insert. For instance, if a user submitted
a query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'
I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10%
raise in salary.
Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that
they could be copied to the new row during the insert.
thus handing over the responsibility for data concurrency to the
application. just the sort of thing that irritates my piles. see following.
and preceding.
However, there could easily be important side-issues with respect to
related data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows
in tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)
By the same token, the delete in the Employee table would fail if there
was a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if
you chose to convert an Update into a Delete/Insert combination.
After all, you wouldn't want an update in one table to cause all sorts
of data to be deleted just because you thought you might get a slight
advantage by turning one Update into a Delete followed by an Insert.
Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you
are after. Then I - or others on this newsgroup - could try again.
two, related concerns (sorry if my OP was obtuse):
- updating every column of each updated row has *got* to be too expensive
for words; far more (if it's ever been quantified) than the 1 or 2 or 3
columns actually changed. are there published stats on the performance
impact?? that is: at what point, either number/type of columns, or
average byte count, etc. is the penalty so large that whatever (coder)
time saved in development by relying on a code generation tool is
overwhelmed by the run-time penalty of updating all columns?? OR, is
DB2 smart enough to see that the incoming column data matches in
table data, and says, "screw it. it ain't different. i ain't
touching it"???? in this scenario, using code generating tools is
not a bad thing, beyond the fact that folks soon forget what their
data looks like.
I don't know precisely what happens in DB2 with respect to updates; after
all, IBM doesn't publish the source code so I wouldn't know.
However, I have always understood that DB2 stores data as rows, that rows
are stored in pages, and DB2 works with pages of data in its bufferpools. In
other words, DB2 isn't doing separate I/Os to get each value on a row.
Furthermore, I've always believed that DB2 only updates the columns that are
in the SET clause of the Update statement and doesn't attempt to rewrite
columns that aren't changed. Again, that is just my *belief*; I can't say
that with certainty without looking at the source code. If anyone who is
absolutely certain can confirm or deny that belief, I'd appreciate it.
So I think the actual behaviour of an application depends on the Update
statement that it generates. If an application - or application generator -
puts every column of the table in the SET clause of its Update statements,
even if the column value isn't being changed, I'd expect that to be slower.
But that would be the fault of the application or generator, not DB2.
- if DB2 sees that the row is being nuked, does it escalate (as it does do
with locks) to insert/delete (or vice versa, of course). and, another
if, so is this more or less expensive than doing the in-place insert?
an optimizer might consider "all aspects", and thus, basically, make
a mistake from a performance point of view??
DB2's Lock Manager can certainly escalate locks and does that when that is
required. However, you should understand that the Lock Manager works at the
row (or page, or table, or tablespace, or database level), not at the level
of individual fields. I'm not aware of any circumstances where it can lock
less than a full row. Lock escalation is always about locking more rows (or
pages), never about locking more fields on one row.
Again, I don't think it is possible for DB2 to convert an Update to a
Delete/Insert, except in that one special case that Pierre noted.
As always, I assume that others on this newsgroup will correct me if I've
inadvertently said anything wrong.
Rhino
Pierre Saint-Jacques wrote: I'd beg to differ just a little bit here.
IN DB2 UDB for LUW:
Multi Dimension Clusterd tables.
If one updates one of the columns chosen as a dimension, the only way
DB2 can deal with this to maintain clustering is to delete the row where
it lived in its block and insert the row with the new dimension in its
proper block.
The same applies for updating the partitioning key for a table in
a partitioned database -- this may result in a delete/insert if the
row would need to be migrated to a different database partition.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Things may have changed but I've always understood DB2's update to deal
with the undo/redo info required and only that for an update.
I used to know(?), things may have changed, that DB2 would pick up the
first column of a row to be changed and all columns from there to the
last column mentioned in the set. Not to deal with the whole row.
As Rhino mentions, in DB2 UDB for LUW, for updates, tables get locked
and rows may get locked. If rows do get locked, locklist and maxlocks
(cfg parms) will govern whether or not there is escalation. Escalation
is always to a strict table lock.
HTH, Pierre.
Rhino wrote: "robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.google.c om...
"Rhino" <rh****@NOSPAM.sympatico.ca> wrote in message
news:<Yc********************@news20.bellglobal.com >...
"robert" <gn*****@rcn.com> wrote in message
news:da**************************@posting.googl e.com...
been ruminating on the question (mostly in a 390/v7 context) of
whether, and if so when, a row update becomes an insert/delete.
i assume that there is a threshold on the number of columns of
the table, or perhaps bytes, being updated where the engine just
decides, screw it, i'll just make a new one.
surfed this group and google, but couldn't find anything.
the context: we have some java folk who like to parametize/
generalize/exersize into what they call Data Access Objects, and
end up looping through a database result set based on column
metadata (thus not having to write any table specific code),
resetting all columns. makes for generatable code, but i for one
don't like it.
seems to be the worst possible performance scenario??
I'm a Java developer but I've never used Data Access Objects so I may
not be
qualified to comment on this question.
However, I would be quite astonished if "the engine" _EVER_ "just
decides,
screw it, I'll just make a new one". (I assume that when you say "the
engine" you mean the DB2 code itself, as opposed to some third party
add-on
to DB2.)
i have this irrepressible lower brain stem memory that some databases
(not for certain db2, hence the question), do just that.
That's quite possible but I don't know the other databases well enough to
say yes or no with any certainty.
Frankly, I've never heard so much as a whisper of a hint of a rumour of
a
suggestion that DB2 could transform an SQL Update statement to an Insert
and/or a Delete and I've been working with DB2 in one capacity or
another
for 20 years.
As far as I know, an Update is always an Update, a Delete is always a
Delete, and an Insert is always an Insert and none of these can change
from
one to the other.
Of course, I *could* be wrong....
Having said that, an *application* which uses DB2 should be able to turn
an
update statement into a delete/insert. For instance, if a user submitted
a
query like this through an interface that I wrote:
update Employee
set salary = salary * 1.1
where empno = '000010'
I could imagine converting that to:
1) a delete that removed the current row for employee 000010
2) an insert to create a new row for employee 000010 but with a 10%
raise in
salary.
Of course, the code to do this would also need a select to determine the
current values of all of the other columns in the original row so that
they
could be copied to the new row during the insert.
thus handing over the responsibility for data concurrency to the
application.
just the sort of thing that irritates my piles. see following.
and preceding.
However, there could easily be important side-issues with respect to
related
data. For instance, if the Employee table in the example had dependent
tables, such as Employee_Health_Claims, doing the delete in the Employee
table could cause all rows of Employee_Health_Claims that relate to that
Employee to be deleted if a DELETE CASCADE rule was in effect. (And rows
in
tables dependent on Employee_Health_Claims might also be deleted if the
DELETE CASCADE rule was in effect on this foreign keys.)
By the same token, the delete in the Employee table would fail if there
was
a DELETE RESTRICT rule between Employee and Employee_Health_Claims. You
would have to consider Referential Integrity issues very carefully if
you
chose to convert an Update into a Delete/Insert combination.
After all, you wouldn't want an update in one table to cause all sorts
of
data to be deleted just because you thought you might get a slight
advantage
by turning one Update into a Delete followed by an Insert.
Since I'm not sure if I really understood the intent of your question, I
don't know if this answers it. If not, perhaps you can clarify what you
are
after. Then I - or others on this newsgroup - could try again.
two, related concerns (sorry if my OP was obtuse):
- updating every column of each updated row has *got* to be too expensive
for words; far more (if it's ever been quantified) than the 1 or 2 or 3
columns actually changed. are there published stats on the performance
impact?? that is: at what point, either number/type of columns, or
average byte count, etc. is the penalty so large that whatever (coder)
time saved in development by relying on a code generation tool is
overwhelmed by the run-time penalty of updating all columns?? OR, is
DB2 smart enough to see that the incoming column data matches in
table data, and says, "screw it. it ain't different. i ain't
touching it"???? in this scenario, using code generating tools is
not a bad thing, beyond the fact that folks soon forget what their
data looks like.
I don't know precisely what happens in DB2 with respect to updates; after
all, IBM doesn't publish the source code so I wouldn't know.
However, I have always understood that DB2 stores data as rows, that rows
are stored in pages, and DB2 works with pages of data in its bufferpools. In
other words, DB2 isn't doing separate I/Os to get each value on a row.
Furthermore, I've always believed that DB2 only updates the columns that are
in the SET clause of the Update statement and doesn't attempt to rewrite
columns that aren't changed. Again, that is just my *belief*; I can't say
that with certainty without looking at the source code. If anyone who is
absolutely certain can confirm or deny that belief, I'd appreciate it.
So I think the actual behaviour of an application depends on the Update
statement that it generates. If an application - or application generator -
puts every column of the table in the SET clause of its Update statements,
even if the column value isn't being changed, I'd expect that to be slower.
But that would be the fault of the application or generator, not DB2.
- if DB2 sees that the row is being nuked, does it escalate (as it does do
with locks) to insert/delete (or vice versa, of course). and, another
if, so is this more or less expensive than doing the in-place insert?
an optimizer might consider "all aspects", and thus, basically, make
a mistake from a performance point of view??
DB2's Lock Manager can certainly escalate locks and does that when that is
required. However, you should understand that the Lock Manager works at the
row (or page, or table, or tablespace, or database level), not at the level
of individual fields. I'm not aware of any circumstances where it can lock
less than a full row. Lock escalation is always about locking more rows (or
pages), never about locking more fields on one row.
Again, I don't think it is possible for DB2 to convert an Update to a
Delete/Insert, except in that one special case that Pierre noted.
As always, I assume that others on this newsgroup will correct me if I've
inadvertently said anything wrong.
Rhino
--
Pierre Saint-Jacques - Reply to: sesconsjunk at attglobaljunk dot com
Reconstruct address: Remove the two junk and replace at and dot by
their symbols.
IBM DB2 Cerified Solutions Expert - Administration
SES Consultants Inc.
I think an update on a Union ALL view WITH ROW MOVEMENT can also do that.
PM
Correct and also update to a range-clustered table.
When range partitioning become availbale, that too will have the same
behaviour.
To comment on the question what DB2 really updates in a "real" update.
DB2 actually ahndles teh fact that more elements are mentioned in the
SET clause (or before trigger) than ar eactually changed (SET c1 = c1).
By default these smarts are ON. There is a Db2 registry variable called
ASSUMEUPDATED (or something like that) which can be set to disable the
smarts (to shave some codepath in well behaved high performance
environments).
The requirement to be that smart indeed coems from teh fact that many
Apps don't bother to find out what was updated. They simply update all
the columns.
The savings, btw is not in the writing of the page. It's in the logging.
And DB2 indeed logs the stripe from the first changed column to the last
changed column.
Cheers
Serge
Serge Rielau <sr*****@ca.eye-bee-em.com> wrote in message news:<fB********************@twister01.bloor.is.ne t.cable.rogers.com>... Correct and also update to a range-clustered table.
When range partitioning become availbale, that too will have the same
behaviour.
To comment on the question what DB2 really updates in a "real" update.
DB2 actually ahndles teh fact that more elements are mentioned in the
SET clause (or before trigger) than ar eactually changed (SET c1 = c1).
By default these smarts are ON. There is a Db2 registry variable called
ASSUMEUPDATED (or something like that) which can be set to disable the
smarts (to shave some codepath in well behaved high performance
environments).
The requirement to be that smart indeed coems from teh fact that many
Apps don't bother to find out what was updated. They simply update all
the columns.
The savings, btw is not in the writing of the page. It's in the logging.
And DB2 indeed logs the stripe from the first changed column to the last
changed column.
kind of figured that part <G>
this is an LUW facility? or DB2 wide? (my case study is NT, so it
doesn't, for the moment, affect 390).
robert
Cheers
Serge
I have no clue whether DB2 for z/OS has a similar implementation.
Cheers
Serge
> many Apps don't bother to find out what was updated. They simply update all
the columns.
Just wanted to add that there may be a strong reason not to bother.
Let's assume I'm performing an array update, and I've bound 40
parameters. Should I be figuring out what's actually changed and
what's not, and issuing individual dynamic updates for each row, that
would be much slower. Keeping 2^40 prepared updates is also out of
question, is it not ak************@yahoo.com (AK) wrote in message news:<46**************************@posting.google. com>... many
Apps don't bother to find out what was updated. They simply update all
the columns.
Just wanted to add that there may be a strong reason not to bother.
Let's assume I'm performing
an array update
real relational databases (even just 1st normal form ones) don't
have arrays. don't you read date, or even celko? <G>
, and I've bound 40 parameters. Should I be figuring out what's actually changed and
what's not, and issuing individual dynamic updates for each row, that
would be much slower. Keeping 2^40 prepared updates is also out of
question, is it not
Real relational systems don't have cleint side logic ;-)
I think SQL is SQL and procedural is procedural.
But those two conecpts must talk with each other.
Wherher the academics like it or not.
And neither Java nor .Net are SQL friendly.
Cheers
Serge
gn*****@rcn.com (robert) wrote in message news:<da*************************@posting.google.c om>... ak************@yahoo.com (AK) wrote in message news:<46**************************@posting.google. com>... many
Apps don't bother to find out what was updated. They simply update all
the columns.
Just wanted to add that there may be a strong reason not to bother.
Let's assume I'm performing
an array update
real relational databases (even just 1st normal form ones) don't
have arrays. don't you read date, or even celko? <G>
you probably don't know yet about binding arrays to parameters.
if you wish to learn a little bit, start here: http://www-106.ibm.com/developerwork...04pooloth.html ak************@yahoo.com (AK) wrote in message news:<46**************************@posting.google. com>... gn*****@rcn.com (robert) wrote in message news:<da*************************@posting.google.c om>... ak************@yahoo.com (AK) wrote in message news:<46**************************@posting.google. com>... > many
> Apps don't bother to find out what was updated. They simply update all
> the columns.
Just wanted to add that there may be a strong reason not to bother.
Let's assume I'm performing an array update
real relational databases (even just 1st normal form ones) don't
have arrays. don't you read date, or even celko? <G>
you probably don't know yet about binding arrays to parameters.
if you wish to learn a little bit, start here:
http://www-106.ibm.com/developerwork...04pooloth.html
it was a pun on array (there was a <G>, after all). we use a framework,
pre-Struts but much like it, and jdbc, and indexed parameters to the
servlets. an interesting article, nonetheless.
<G><G>
bumps This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jason |
last post by:
I have a table that matches up Securities and Exchanges. Individual
securities can belong on multiple exchanges. One of the columns, named
PrimaryExchangeFlag, indicates if a particular exchange is...
|
by: Google Mike |
last post by:
I have one table of new records (tableA) that may already exist in
tableB. I want to insert these records into tableB with insert if they
don't already exist, or update any existing ones with new...
|
by: Philip Boonzaaier |
last post by:
I want to be able to generate SQL statements that will go through a list of
data, effectively row by row, enquire on the database if this exists in the
selected table- If it exists, then the colums...
|
by: Tinius |
last post by:
I am trying to update a field of type IMAGE.
I am able to do this by deleting the record and then INSERTing a new record
as shown below in the commented section.
But I really want to do this...
|
by: Neo Geshel |
last post by:
This works:
<form>
<asp:TextBox id="name" />
<%= name.ClientID %>
</form>
But this DOES NOT work:
<form>
|
by: Shapper |
last post by:
Hello,
I have created 3 functions to insert, update and delete an Access
database record. The Insert and the Delete code are working fine.
The update is not. I checked and my database has all...
|
by: abhi81 |
last post by:
Hello All,
I have a table on which I have created a insert,Update and a Delete trigger. All these triggers write a entry to another audit table with the unique key for each table and the timestamp....
|
by: =?Utf-8?B?VmVybm9uIFBlcHBlcnM=?= |
last post by:
I am using VS2005. I created a Windows Appication project. Inside the
Server Explorer, I created a new SQLExpress database, and then created a new
table. I added the rows, making my first row an...
|
by: magnolia |
last post by:
i created a trigger that will record the changes made to a table .everything works fine except the insert query.whenerever i try to insert a record it fires insert and update triger at the same time...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
