Unlike business-critical applications that require certainty in results of read-only operations on tables, Customer Relationship Management (CRM) applications need only a snapshot, a statistical picture of the current state of the database.
Therefore, CRM and other similar applications can tolerate dirty read operations, so they can afford to relinquish a degree of accuracy in their database read operations in exchange for enhanced transaction concurrency (see Default Lock Assignments and Lock Upgradeability for details).
A dirty read is an operation that might read data written to the database by transactions that are not yet committed. If a transaction fails, the system rolls back any updates it made. If those updates include data that has been read by another concurrently running transaction, then that read is said to have been dirty, because as far as the database is concerned, it never existed. See Database Locking Levels and Severities for details about transaction integrity and some of the problems that relaxing it can bring.
Applications that can tolerate dirty reads may improve performance by specifying a default session-wide locking level instead of downgrading locks on a request-by-request basis, which can be burdensome. ACCESS-level locking achieves better performance than READ-level locking by enhancing transaction concurrency.
This is an important consideration. Carefully examine the overall qualitative workload of the session before deciding whether to default to ACCESS-level locking for read-only operations. For example, consider a session in which a MultiLoad import job is running. Because of the way MultiLoad updates table rows during its acquisition phase (see Teradata® MultiLoad Reference, B035-2409), using ACCESS locks to query the target table of the MultiLoad job during an acquisition phase can produce inaccurate results.
The SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL statement provides a mechanism for doing that, allowing you to indirectly substitute ACCESS locks for READ locks for selected read-only SELECT operations in the current session (restricted to SELECT subqueries embedded within DELETE, INSERT, or UPDATE requests). The initial default for any session remains SERIALIZABLE (meaning READ level severity locking), but you can change the default read-only locking severity to READ UNCOMMITTED (meaning ACCESS level severity locking) either interactively or, more persistently, within your application code.