Transaction vs. Utility Locks - Teradata Tools and Utilities

Teradata® Archive/Recovery Utility Reference

Product
Teradata Tools and Utilities
Release Number
16.20
Published
March 2019
Language
English (United States)
Last Update
2019-06-05
dita:mapPath
fac1527114221922.ditamap
dita:ditavalPath
Audience_PDF_include.ditaval
dita:id
B035-2412
Product Category
Teradata Tools and Utilities

From a blocking perspective, the behavior of a HUT lock is the same as a transaction lock. For example, a read lock prevents another job from claiming a write lock or exclusive lock. Conversely, a write lock prevents a read lock, write lock, or exclusive lock. An exclusive lock prevents any other type of lock. Conflicting HUT and transaction locks on an object block each other, just as if both were transaction locks or both were HUT locks.

The two differences between transaction locks and HUT locks are:
  • Permanence

    A transaction lock exists only for the duration of a transaction; after the transaction completes or is aborted, the lock is released. A HUT lock is more permanent. It is only removed if an explicit RELEASE LOCK command is issued, or if the locking operation (for example, execution of an ARCHIVE or RESTORE command) completes successfully and has the RELEASE LOCK option specified. The lock remains even if the command fails, the ARC job terminates, or if the Teradata system has a restart.

  • Scope

    A transaction lock has session scope, meaning that it applies to any command submitted by the session running the locking transaction. Another session running against the same object(s) must claim its own locks, even if it is running under the same user.

    A HUT lock has user scope, meaning that it applies to any Teradata ARC operation that the user is performing on the object. A user must have only one HUT lock against an object at a time. The HUT lock allows any Teradata ARC operation from that user to access the locked object(s), but blocks other users from acquiring a conflicting HUT lock on the object(s). Additionally, the HUT lock blocks all conflicting transaction lock attempts on the object, even if the transaction locks are from the same user. There is only one HUT lock. Therefore, a RELEASE LOCK operation for that user on an object always releases an existing HUT lock, even if other jobs for that user are still accessing the object.

Releasing a utility lock on a database or table that is being accessed by another Teradata Archive/Recovery Utility job could result in data corruption and unexpected errors from ARCMAIN or the database.

HUT locks that are not released are automatically reinstated following a restart.

For information on transaction locking and processing, refer to SQL Request and Transaction Processing (B035-1142).