Handling Blocked Internal DBQL Requests - Teradata Database - Teradata Vantage NewSQL Engine

Teradata Vantage™ - Database Administration

Product
Teradata Database
Teradata Vantage NewSQL Engine
Release Number
16.20
Published
March 2019
Language
English (United States)
Last Update
2019-05-03
dita:mapPath
tgx1512080410608.ditamap
dita:ditavalPath
TD_DBS_16_20_Update1.ditaval
dita:id
ujp1472240543947
Product Category
Software
Teradata Vantage

DBQL uses express requests to do internal work on DBQL log tables. If you are performing work on the same log tables, such as deleting rows, this may block DBQL internal requests because you have a lock on the table. The internal requests will then consume AMP worker tasks until your work finishes or until you disable the DBQL logging.

You cannot abort or otherwise do anything to this internal session record. It exists only to show that internal DBQL requests are blocked.

If DBQL internal requests remain blocked, the system deadlock detection may abort them. If the system aborts these internal sessions, the logging data will be lost. You must submit the appropriate END QUERY LOGGING statement to end logging before you do any kind of maintenance on DBQL tables.

If you notice frequently blocked DBQL internal requests reported by the internal session, consider scheduling your queries (such as table maintenance) on DBQL tables when there is no logging activity. Or use locks that hold the logging tables for a minimal amount of time.