Parsing time is often an afterthought. But sometimes there is a concern because parsing is taking longer than expected. But whether the time to accomplish parsing is becoming an issue for you or not, there are small benefits that can be enabled by creating a special workload to manage the parsing activity for all your queries. This blog posting explains why and how to set that up on your system.
Back in 14.10, some new fields related to Capacity on Demand (COD) and other types of hard limits were quietly added to ResUsage tables. You might be interested in these fields today, because they report how long queries were delayed due to hard limit enforcement. This can give you insights into whether a hard limit, like WM COD is ever being reached, and its actual impact on activity on the platform when it is reached.
Temperature-based block-level compression, also known as "Compress on Cold" was introduced in Teradata Database 14.0. Temperature-based block-level compression (TBBLC) automatically compresses infrequently accessed data and decompress frequently accessed data. The access frequency is determined by statistics collected by TVS. TBBLC may be applied on a table-by-table basis or by default on all user tables.
This blog posting provides a little background and describes the easiest way to enable TBBLC on just a few selected tables in your database.
If I told you there was a way you might be able to speed up parsing time for your queries, would you be interested?
If yes, consider "expediting" express requests. This blog posting explains what that means, how it works, and when it can help you. The goal of expediting express requests is to get the best performance you can from parsing when the system is being fully utilized.
Note: This is a rewrite of an earlier blog posting ("Expediting Express Requests") with a similar name that I posted back in 2014. Enhancements have been made to this capability since then, so it's worth giving this posting a read even if you are familiar with how the option used to work.
This is an update to an earlier posting in which data dictionary statistics to collect in Teradata Database 15.10 were recommended. This posting makes recommendations for dictionary statistics from the Teradata Database 16.10 perspective. You may not require all these statistics, but they cover the tables and columns most likely to be accessed in the data dictionary views.
On the Enterprise platforms, Teradata Active System Management (TASM) workload management offers a priority level called the SLG Tier, composed of five levels. Workloads that have a service level goal (SLG) or that are special for some reason can be placed in one of the SLG Tiers. Workloads in the SLG Tier get access to resources ahead of workload placed in Timeshare, which is lower in the priority hierarchy.
Workloads assigned to SLG Tiers have a richer set of workload options and require different setup techniques than workloads placed on other levels of the priority hierarchy, such as Timeshare. This posting describes a not-well-understood characteristic of SLG Tiers that limit the maximum and minimum resource allocations that workloads on such a tier will receive.
When a “Workload” is defined in Teradata Workload Management’s TASM feature it may be given a supplemental capability called a “workload exception”. When a workload exception is defined, it will cause characteristics of each running request that classifies to the workload to be monitored. The action taken when a workload exception reaches a specified threshold will depend on the type of exception being defined. There is one peculiarity in what exception actions can be associated with a workload exception, and that will be discussed in this posting.
I came across an interesting behavior concerning statistics histograms that has to do with NULL values. This posting explains and illustrates this behavior. If you observe this phenomena at your site, know that things are working as designed.