DDL & DCL Requests, Dictionary Access, Locks | VantageCloud Lake - DDL and DCL Requests, Dictionary Access, and Locks - Teradata VantageCloud Lake

Lake - Working with SQL

Deployment
VantageCloud
Edition
Lake
Product
Teradata VantageCloud Lake
Release Number
Published
February 2025
ft:locale
en-US
ft:lastEdition
2025-11-21
dita:mapPath
jbe1714339405530.ditamap
dita:ditavalPath
pny1626732985837.ditaval
dita:id
jbe1714339405530

The execution of a DDL or DCL request causes the data dictionary to be updated and appropriate locks to be placed on system tables while that request is processing.

Optimizing the Locking Granularity for Data Dictionary Access

To improve concurrency, DDL and DCL processing use the finest locking granularity that is practical and delay placing their locks as long as possible. Depending on the dictionary table, the system may downgrade rowhash READ lock requests made on the dictionary to ACCESS locks to prevent the query from being blocked by WRITE locks placed on those tables by ongoing DDL operations.

If not blocked, these rowhash READs use the standard READ locks.

The following dictionary views and tables are affected by this locking downgrade on a blocked READ lock request:
  • DBC.AccLogRuleTbl
  • DBC.ConstraintNames
  • DBC.Indexes
  • DBC.TableConstraints
  • DBC.TextTbl
  • DBC.TriggersV
  • DBC.TVFields
  • DBC.TVM
  • DBC.UDFInfo
The only SQL statements eligible for a dictionary access READ lock-to-ACCESS lock downgrade on being otherwise blocked are the following:
  • SELECT
  • HELP COLUMN
  • HELP CONSTRAINT
  • HELP INDEX
  • HELP STATISTICS
  • SHOW FUNCTION/JOIN INDEX/MACRO/METHOD/PROCEDURE/TABLE/TRIGGER/TYPE/VIEW

These are system-initiated lock downgrades that you cannot specify using the LOCKING request modifier.