Understanding Teradata Parsing Engine and Access Rights: Impact on System Performance

Understanding the relationship between Teradata’s parsing engine (PE) and system performance requires knowledge of the PE’s tasks within the Teradata architecture.

The Teradata parsing engine manages access rights, parsing the statement, optimizing the SQL, creating processing steps, and dispatching to the AMPs.

Knowledge of the specific dependencies between roles and access rights in a Teradata system is unnecessary to address our issue. Instead, it is important to note that individual object permissions are saved in the DBC.AccessRights table.

When creating a table, various permissions will be assigned to your user account (the one used for logging into the system).

CREATE TABLE <DATABASE>.< TABLE>(
PK INTEGER NOT NULL
) PRIMARY INDEX (PK);

To verify the statement above, we will utilize the view DBC.AllRights rather than DBC.AccessRights for ease of use. This view utilizes object names instead of the object identifiers internally utilized by Teradata, simplifying the process for us.

SELECT
UserName,DatabaseName,TableName,AccessRight,GrantorName,CreatorName
FROM
dbc.allrights
WHERE
DatabaseName = ” AND tablename = ”;

UserNameDatabaseNameTableNameAccessRightGrantorNameCreatorName
<USER><DATABASE><TABLE>ST<USER><USER>
<USER><DATABASE><TABLE>DG<USER><USER>
<USER><DATABASE><TABLE>RS<USER><USER>
<USER><DATABASE><TABLE>U<USER><USER>
<USER><DATABASE><TABLE>DP<USER><USER>
<USER><DATABASE><TABLE>RF<USER><USER>
<USER><DATABASE><TABLE>IX<USER><USER>
<USER><DATABASE><TABLE>R<USER><USER>
<USER><DATABASE><TABLE>I<USER><USER>
<USER><DATABASE><TABLE>D<USER><USER>
<USER><DATABASE><TABLE>DT<USER><USER>
<USER><DATABASE><TABLE>CG<USER><USER>

The result set above displays that the DBC.AccessRights table stores 12 permission records, including permissions for updating, retrieving, deleting, restoring, and dropping triggers, among others, following the creation of a table.

The number of permissions stored varies based on the Teradata release and potentially other parameters.

Grants are typically retrievable from the cache, but when the cache cannot satisfy the necessary permits, the parsing engine must reference the DBC.AccessRights table (refer to the DDL provided):

CREATE SET TABLE DBC.AccessRights
(
UserId BYTE(4) NOT NULL,
DatabaseId BYTE(4) NOT NULL,

) PRIMARY INDEX (UserId,DatabaseId);

Hashing is utilized in DBC tables to distribute table records amongst all AMPs. However, skewing may pose an issue, as is the case with DBC.AccessRights where the primary index is {UserId, DatabaseId}.

Your daily batch process may result in a vast number of tables being generated in the staging area by a single user, causing significant skewing in the DBC.AccessRights table.

Verifying user permissions within the parsing engine will result in longer parsing times and, subsequently, a decrease in overall system performance.

How can this problem be reduced in scope?

By definition, the user who creates an object already possesses all access rights, rendering the records written to DBC.AccessRights superfluous.

We can delete these records using the following SQL method:

SELECT
‘REVOKE ALL ON ‘|| TRIM(a.databasename)|| ‘.’ || trim(a.tablename) || ‘ from ‘|| trim(a.username) || ‘;’ (TITLE ”)
FROM dbc.allrights a
INNER JOIN
DBC.TABLES b
ON
a. DatabaseName = b. DatabaseName
and a.tablename = b.tablename
where   a.grantorname = ‘<USER>’
and   a. DatabaseName
in     (
select d.databasenameI
from   dbc.dbase d
where   d.rowtype = ‘D’)
and   a.username   = a.grantorname
and a.accessright not in (‘IX’,’RF’)
and b.tablekind = ‘T’
GROUP BY 1;

If UserName matches GrantorName, then delete the record from DBC.AccessRights.

Cleaning the DBC.AccessRights table can yield faster parsing times, as confirmed by checking the DBC.DBQLOGTBL.

Note that performing a DROP & CREATE action on the table results in the permissions being added to DBC.AccessRights again. Removing the contents from your target tables is advisable instead of using this method.

Related Services

🏗️ Planning a Data Platform Migration?

Architecture-first approach: we design before a single line of code is written. Zero data loss across every migration delivered.

Our Migration Services →

📊 Data Platform Migration Survey

Help us map where the industry is heading. Results are public — see what others chose.

1. What is your current data platform?

2. Where are you migrating to (or evaluating)?

Migrating FROM
Migrating TO

Thanks for voting! Share this with your network.

Follow me on LinkedIn for daily insights on data warehousing and platform migrations.

Stay Ahead in Data Warehousing

Get expert insights on Teradata, Snowflake, BigQuery, Databricks, Microsoft Fabric, and modern data architecture — delivered to your inbox.

1 thought on “Understanding Teradata Parsing Engine and Access Rights: Impact on System Performance”

  1. Good post! our table is skewed 99%. I guess the real question is, why is Teradata inserting these redundant rows and why is such a bad PI in use? (in Teradata 15 they change it to just user_id and partition the dbid)

    PRIMARY INDEX ( UserId )
    PARTITION BY ( RANGE_N((ID2BIGINT(DatabaseId )) MOD 1073741824 BETWEEN 0 AND 1073741823 EACH 1 ),
    RANGE_N(ID2BIGINT(TVMId ) BETWEEN 0 AND 4294967295. EACH 1 )ADD 2 );

    Reply

Leave a Comment

DWHPro

Expert network for enterprise data platforms. Senior consultants, project teams built for your challenge — across Teradata, Snowflake, Databricks, and more.

📍Vienna, Austria & Jacksonville, Florida

Quick Links
Services Team Teradata Book Blog Contact Us
Connect
LinkedIn → [email protected]
Newsletter

Join 4,000+ data professionals.
Weekly insights on Teradata, Snowflake & data architecture.