DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

3.1.4 Performance
Update 10 rows using a positioned Multi-row FETCH/UPDATE
on a rowset cursor
EXEC SQL
UPDATE TABLE1
SET COL3=COL3+1
WHERE CURRENT OF C1;
Delete 10 rows using a positioned Multi-row FETCH/DELETE
EXEC SQL
DELETE FROM TABLE1
WHERE CURRENT OF C1;
Figure 3-3 Example of multi-row cursor update and delete
To update in SQL, if only the nth row in the rowset instead of the whole rowset needs to be
updated, which might be more common, you specify ‘FOR ROW n OF ROWSET’, as shown
here:
EXEC SQL
UPDATE TABLE1
SET COL3=COL3+1
WHERE CURRENT OF C1 FOR ROW n OF ROWSET;
All constraint checks are effectively made at the end of the statement. In the case of a
multi-row update, this validation occurs after all the rows are updated. The only place it can be
different is in AFTER UPDATE FOR EACH ROW triggers that have an external action. In all
other cases, the whole UPDATE is an atomic operation. Either all changes are made or no
changes are made.
In this section we discuss the environment and measurements related to multi-row operations
when executed locally.
Performance measurement scenario
► Configuration
– DB2 for z/OS V8 and V7
– z/OS Release 1.4.0
– 2-way processors 2084 z990
– ESS 800 DASD with FICON® channels
– Non-data sharing
► Non-partitioned table space, 100,000 rows table, 26 columns, 1 index
34 DB2 UDB for z/OS Version 8 Performance Topics