Welcome! Teradata Developer Exchange is a community-oriented website that connects Teradata Associates with Customers and others interested in the related technologies. Think of it as a technical collaborative community for sharing ideas, asking questions, learning, and solving problems related to Teradata solutions and beyond. Sounds great doesn't it? So sign up and join the community now!

Expand All Subscribe to Teradata Developer Exchange - All content The Latest
Deploying Advanced Analytics: Managing the Data, Processes & Environment


Historically, those who work in the world of advanced analytics and data mining have done their work in a separate environment that they control. This approach made sense in the days before Teradata Enterprise Data Warehouses made most, or all, of the needed data available in a scalable environment ...

New opportunities for statistics collection in Teradata 14.0

Teradata 14.0 offers some very helpful enhancements to the statistics collection process.   This posting discusses a few of the key ones, with an explanation of how these enhancements can be used to streamline your statistics collection process and help your statistics be more effective.

For more detail on these and other statistics collection enhancements, please read the orange book titled Teradata 14.0 Statistics Enhancements, authored by Rama Korlapati, Teradata Labs. 

Introducing TDM into a production Dual System environment

Teradata Data Mover can be a valuable product to add into a dual system production environment either as a scheduled / triggered step in your load process or for ad-hoc re-synchronization of tables.

Unity 13.10 Foundation - Catalog Deploy Examples

Teradata Unity 13.10, the latest enabling technology of the Teradata Analytical Ecosystem was formally announced at PARTNERS Conference 2011. The product’s focus is to simplify the analytical ecosystem by removing the everyday complexities involved in query management and data synchronization across multiple Teradata systems. Teradata Unity delivers on this strategy by way of product automation.

Teradata Unity serves as an abstraction layer for users and applications making multiple Teradata systems appear as a single Teradata database instance. Unity dynamically manages all the traditional activities around query routing and data synchronization creating a single integration layer for the Teradata ecosystem.

Utility Session Management - It's Inside the Database in Teradata 13.10! (UPDATED)

How do you pick the number of sessions to assign to your utility jobs?  Chances are you guess.  In Teradata 13.10 the task of deciding the number of sessions has been moved inside the database, meaning one less thing for you to worry about.  Read on for a quick intoduction to how this feature works.

Is your Internal Monitor monitoring (TMSM 13.10)?

The Teradata Multi-System Manager (TMSM) product monitors and controls hardware components, processes, and data loads.  Ever wonder who is monitoring the monitor? The Internal Monitor should not be confused with the external fail over monitor, the fail over monitor is responsible for monitoring the TMSM Master.

This article would be useful to anyone attempting to better understand the TMSM Internal Monitor.

The NPAM Fallback file

The Teradata Named Pipe Access Module (NPAM) provides an inter-process communication link between a writer process (such as FastExport) and a reader process (such as FastLoad).  The NPAM can also be used by Teradata Parallel Transporter (TPT) for data transfer activity.

This article discusses the Fallback file that is used by the NPAM.

Ten Practical Steps for Building Data Quality into Your Data

This session will review current best practice for building data quality into data warehouses.

Hot 'n Cold Data, Fast 'n Slow Storage: Get Performance Using Teradata Virtual Storage

Teradata Virtual Storage supports the newest Teradata Platforms – 6650 and 6690.

Intrepreting DBQL DelayTime in Teradata 13.10

Starting in Teradata 13.10, there is a single delay queue for all throttles.  This means that queries delayed by system throttles will reside in the same queue as queries delayed by workload throttles.  In earlier releases, delay queues were set up independently by type of throttle, and each workload throttle had its own dedicated queue.   

Bringing together all delayed objects into a single queue streamlines the entire throttling experience and makes it easier and more accurate to manage internally.  However, as a side-effect, the DelayTime field in DBQL needs a second look.  DelayTime takes requires slightly different interpretation in 13.10 than you gave it in earlier releases.