Sparse maps are one of the new functionalities available in the MAPS Architecture feature that is part of the Teradata Database 16.10 release. All Teradata deployment platforms will support the use of sparse maps as soon as the platform gets onto 16.10 software.
Sparse maps are simple to understand, easy to use, and can provide benefit when a very small table is frequently or repetitively accessed. Basically, sparse maps allows you to move very small tables onto one or a few AMPs on the system, rather than thinly spreading the table’s rows across all AMPs.
Most sites have a few (or many) very small tables with fewer rows than AMPs in the configuration. Having to perform an all-AMP operation every time those types of tables are read involves some level of activity across all AMPs. Some of those AMPs will be wasting their resources because they have no rows. That can add up, especially on systems that include a large number of AMPs.
This posting discusses key points to keep in mind before you begin moving your small tables into sparse maps.
I came across an interesting behavior related to Teradata workload management. This behavior is reflected in both TASM and TIWM. It has to do with using throttles to delay all queries that include access to a certain table (or set of tables) at times when those tables are being dropped and recreated.
Statistical information is vital for the optimizer when it builds query plans. But collecting statistics can involve time and resources. By understanding and combining several different statistics gathering techniques, users of Teradata can find the correct balance between good query plans and the time required to ensure adequate statistical information is always available.
Teradata Database workload management offers a new feature starting in Teradata Database 15.10 for managing the throttle delay queue. It’s called “Prioritized Delay Queue”. This posting looks at how the Prioritized Delay Queue feature works and some things to keep in mind if you begin to use it. The intent of this enhancement is to ensure that higher priority work is able to be released from the delay queue ahead of lower priority work.
The ResUsageSAWT logs detailed information about AMP worker tasks (AWTs). Because AWTs are a finite resource, most sites keep on eye when they are close to running out.
ResUsageSAWT reports in-use and max AWT counts for all of the 16 message work types on each AMP and reports them at the end of each logging interval. It also includes a column InuseMax that reflects the maximum number of AWTs in combination that were in use at any one time during the log period. This posting is intended to clear up any confusion over what InuseMax offers, when it’s useful, and when other AWT metrics are more suitable.
A new feature in Teradata Database 15.0 gives the optimizer the choice to bypass all-AMP row redistributions under certain circumstances. This can be a good thing for queries that are redistributing just a few rows and the system has many AMPs. Without this feature all row redistributions, no matter of what size, would require that an AMP worker task be spawned and started up on each AMP in preparation for receiving rows.
If you are someone who uses Database Query Log (DBQL) to keep on top of how much resource your users and applications are consuming, you are probably aware that there are different DBQL tables that collect information related to usage. Starting in Teradata Database 15.0, if you are tracking usage for utilities, that detail is carried in two places: The DBQLogTbl and the DBQLUtilityTbl.
Which should you use? Should you combine usage from both tables? Or only consider the usage in one of the two tables?
Teradata Workload Management comes in two versions: Teradata Integrated Workload Management (TIWM) which includes basic functionality, and Teradata Active System Management (TASM) which has a richer set of capabilities. Both TIWM and TASM come with several system-defined workloads. This blog explains what these workloads are, why they are there, and whether you can ignore them or not.
AMP worker tasks (AWT) are a critical resource in the Teradata Database. In previous blog postings I’ve explained how the load and export utilities, as well as ARC backup and restore, use AMP worker tasks. In this posting we’ll consider the replacement for ARC, Data Stream Architecture (DSA), and its use of AWTs.