Using locks for data consistency
Locks can ensure that data remains consistent even when multiple users try to access the same data at the same time. You can use locks to ensure that only one user is privileged to change data at a given time and that no user is privileged to access uncommitted data.
About this task
If you use repeatable read (RR), read stability (RS), or cursor stability (CS) as your isolation level, DB2® automatically controls access to data by using locks. However, if you use uncommitted read (UR) as your isolation level, users can access uncommitted data and introduce inconsistent data. As an auditor, you must know the applications that use UR isolation and that can introduce inconsistent data or create security risks.

SELECT DISTINCT Y.PLNAME
FROM SYSIBM.SYSPLAN X, SYSIBM.SYSSTMT Y
WHERE (X.NAME = Y.PLNAME AND X.ISOLATION = 'U')
OR Y.ISOLATION = 'U'
ORDER BY Y.PLNAME;
SELECT DISTINCT Y.COLLID, Y.NAME, Y.VERSION
FROM SYSIBM.SYSPACKAGE X, SYSIBM.SYSPACKSTMT Y
WHERE (X.LOCATION = Y.LOCATION AND
X.LOCATION = ' ' AND
X.COLLID = Y.COLLID AND
X.NAME = Y.NAME AND
X.VERSION = Y.VERSION AND
X.ISOLATION = 'U')
OR Y.ISOLATION = 'U'
ORDER BY Y.COLLID, Y.NAME, Y.VERSION;
For dynamic SQL statements, turn on performance trace class 3 to determine which plans and packages use UR isolation.
