CheckTable and Deadlocks - Advanced SQL Engine - Teradata Database

Database Utilities

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
July 2021
Language
English (United States)
Last Update
2021-07-27
dita:mapPath
xha1591998860283.ditamap
dita:ditavalPath
xha1591998860283.ditaval
dita:id
B035-1102
lifecycle
previous
Product Category
Teradata Vantage™

Because the system does not detect deadlocks that exist between utility functions, CheckTable has a built-in timeout feature to prevent long-standing deadlocks. However, this feature makes it difficult for CheckTable to apply a lock on a table that has frequent lock requests.

For non-concurrent mode, the first time a lock is requested, the time-out interval is one minute. Each subsequent retry adds one minute to the interval until the interval is five minutes. Then, all subsequent retries employ a five-minute time-out. The number of times CheckTable can attempt a lock request is not limited.

If you specify the SKIPLOCKS option, then CheckTable requests a lock on a table only once. If CheckTable does not obtain the lock the first time, then CheckTable does not request any further locks and does not check the table.

To determine the current status of CheckTable, type status at the CheckTable command prompt.

To abort the table check, enter “abort table” to abort the current table check, or “abort” to abort the current CHECK command and all pending table checks.

For more information, see CheckTable and System Activity.

For non-concurrent mode, when the CheckTable Table Lock Retry entry in the DBS Control General fields is set to a positive number, CheckTable will retry the lock request until this specified time in minutes is exhausted. CheckTable will display that the table is skipped due to pending lock and will continue to check the next table. For more information, see ChecktableTableLockRetryLimit in DBS Control (dbscontrol)

For concurrent mode, the first time a table lock is requested, the timeout interval is 15 seconds. CheckTable will skip the locked table and continue to check the remaining tables. All subsequent retries employ a five-minute timeout interval per table. All skipped tables will be retried forever if RETRY LIMIT is not specified. If RETRY LIMIT is positive, all skipped tables will be retried until CheckTable reaches the RETRY LIMIT. For more information on concurrent mode, see CheckTable and System Activity.