Using QueryID for Joins on DBQL Tables - Analytics Database - Teradata Vantage

Database Administration

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
VMware
Product
Analytics Database
Teradata Vantage
Release Number
17.20
Published
June 2022
Language
English (United States)
Last Update
2024-10-04
dita:mapPath
pgf1628096104492.ditamap
dita:ditavalPath
qkf1628213546010.ditaval
dita:id
ujp1472240543947
lifecycle
latest
Product Category
Teradata Vantageā„¢

Because each DBQL table has its own separate cache, the system may fill up the cache for one table and log to that DBQL table before it logs into another DBQL table. This results in slightly different CollectTimeStamp values. Therefore, do not include CollectTimeStamp fields in joins.

If you need to join different DBQL tables, use the QueryID field. If you plan on comparing values between different DBQL tables, you can flush the DBQL caches to the dictionary tables. See Options for Flushing the DBQL Cache.

Although it is rare, you may see orphan rows in join results involving the DBQLObjTbl, DBQLExplainTbl, or DBQLXMLTbl tables. An orphan row is one that does not appear in the default log table (DBQLogTbl), but has an entry in one of the three other tables.

Teradata recommends that you ignore the orphan rows and do not copy them over when you copy the DBQL tables out of DBC and into temporary or history tables in another database.