Uncommitted Read (UR) -- also known as "dirty read" or "read through locks" -- is one of the most useful features of DB2 V4.1.

Two ways to invoke UR:

• Bind the plan or package with ISOLATION(UR). All read-only statements in in the plan or package will execute with UR.
  
  
• Specify WITH UR in the select statement. This will override the isolation level with which the plan or package was bound. (Note: The WITH clause can also be used to specify RR or CS isolation.)

Notes on using UR:

• UR requires Type 2 indexes if an index access path is to be used.
  
  
• Please note that using UR can produce strange results. Use it only if you are sure it can do no damage. An example of strange results follows:

NOTE: Contrary to popular belief (to coin a phrase) queries using UR do acquire locks, though not the kind that are likely to cause contention. First, they acquire a special "mass delete" lock in share (S) mode on the target table or tablespace; this is not the same as a normal share (S) lock on a table or tablespace. The special mass delete S lock prevents any other process from issuing a mass delete (a delete statement without a WHERE clause) while the query is running. Thus, it is possible to have contention between a UR query and a mass delete. Second, UR queries acquire IX locks on any tablespace they may happen to use in the temporary work file database. This lock prevents the work file tablespace from being dropped while the query is running; it is of no concern to the developer because the work file tablespaces are dropped, if at all, only during DB2 subsystem maintenance, and no queries would be running while such maintenance was in progress.