16.10 - CheckTable and Deadlocks - Teradata Database

Teradata Database Utilities

Product
Teradata Database
Release Number
16.10
Published
June 2017
Language
English (United States)
Last Update
2018-04-26
dita:mapPath
zll1480972831047.ditamap
dita:ditavalPath
changebar_rev_16_10_exclude_audience_ie.ditaval

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.