This article provides a high-level overview of the process involved in moving to Teradata 13. Teradata 13 offers many new features and some of the highlights are covered in other articles on DEV/X. The focus here is how to get to Teradata 13.0.

Authors: Carrie Ballinger, Rama Krishna Korlapati, Paul Sinclair

Looking for a fresh perspective on collecting statistics, or just want a confirmation that you’re on the right track? Either way, you’ll want to read this quick summary of recommendations for Teradata 12 stats collection.

More than likely, you need to keep track of the beginning and ending of some kind of an event. Maybe you track how long employees have been with your company, how much time users spend on a particular web site, or the duration of insurance policies.

In other words, you need to track temporal data. And you probably use a couple of DATE or TIME or TIMESTAMP columns to do just that.

Consider the following employee table that tracks the job duration of employees by using two DATE columns: start_date and end_date.

Some of you may be familiar with relational databases other than Teradata and how those other RDBMs utilize indexes.

In Teradata, an “Index” is a physical mechanism that is used to distribute, store, and access data rows. Indexes provide a physical access path to the data and their use can avoid unnecessary full-table scans to locate rows.

The purpose of the new Teradata 13.0 feature that allows you to create tables with no primary index is improved performance of FastLoad and Teradata Parallel Data Pump Array INSERT data loading operations.
 

Middle-tier applications may stand between end-users and Teradata Database; accepting requests from users, constructing queries from those requests, passing the queries to the database, and then returning results to the users. The middle-tier application logs on to the database, is authenticated as a permanent database user, and establishishes a connection pool. The application then authenticates the individual application end-users, some of whom may request access to the database through the connection pool.

I’ve been telling you for years to transform your short all-AMP queries into single-AMP queries, whenever you can. I’ve even given you pointers on using stored procedures, join indexes and smart application design to achieve that goal.

But when it comes to random AMP sampling, I’m asking you to ignore all that, and give some thought to converting your random AMP sampling from one to all-AMPs.