When attempting to obtain one or more locks, Teradata ARC may be competing with another
external process for those locks. When such a situation occurs, it is possible for
both processes to get into a 'deadlock' situation where each process may obtain one
or more of the locks that it needs but is blocked because the other process owns the
remaining lock(s) that it needs. If neither process is willing to give up the locks
that is owns, then you have a 'deadlock' condition and both processes will wait forever
to get the locks that it needs from the other process. The only way to clear up such
a 'deadlock' condition is to abort one of the processes to free up the locks that
it owns so that the remaining process can obtain the remaining lock(s) that it needs
to start running. But, the main issue is how to determine if your Teradata ARC job
is in a 'deadlock' condition and what other processes are involved so that the user
can decide which process should get aborted and which should continue.
Starting with TTU 15.10, the Database Query Log (DBQL) utility provides a method for using the LOCK LOGGER utility to monitor jobs for deadlock conditions. If the Teradata ARC user is interested in setting up his system to monitor Teradata ARC jobs for deadlock conditions, please see Chapter 16 of the Database Administration manual, release 15.10, for details on how to set that up (also search for 'Lock Log' in other parts of the manual). See “Additional Information” on page 5 for a reference to the Database Administration manual.