Validating Data from Teradata¶

This page covers Teradata-specific setup for Data validation. For workflow and Worker field definitions, see Data validation configuration reference. For SnowConvert AI CLI commands, see Manual Migration: Data validation.

Prerequisites¶

Before you validate Teradata data, make sure the following are in place:

• Teradata connectivity on Workers: Same as data migration. Prefer teradatasql when available; otherwise set odbc_driver to the exact registered driver name. Optional dbc_name, port 1025 by default, optional authentication (TD2, LDAP, KRB5).
• HASH_MD5 UDF (required for L3 row fingerprinting): See HASH_MD5 UDF below.
• No WRITE_NOS or TPT for validation-only Workers: Validation reads the source over SQL (L2/L3). You don’t need write_nos_* TOML or tbuild on a host solely running validation, unless the same Worker also executes migration tpt or write_nos tasks.

HASH_MD5 UDF¶

Teradata does not provide a built-in SQL function that Cloud Data Validation can use for L3 row fingerprinting. Instead, validation generates SQL that calls a custom user-defined function named HASH_MD5.

What HASH_MD5 does¶

HASH_MD5 is a C language UDF you install on Teradata. It accepts a string expression and returns an MD5 message digest (hex-encoded) for that input.

In L3 row validation (the default when row_validation is enabled), and when row_validation_mode is row, the Worker runs row-hash SQL on Teradata that normalizes each row’s cell values, concatenates them, and passes the result to HASH_MD5(...). Snowflake runs a matching MD5(...) expression on the target side. Validation compares the two digests to detect row-level mismatches before optional cell drilldown.

L1 schema validation and L2 metrics validation do not call HASH_MD5. L3 cell mode compares individual cell values and also does not depend on this UDF.

Where the UDF must be installed¶

When the Worker connects, Teradata uses the database value in Worker TOML as the session default. Unqualified HASH_MD5 resolves only in that database. Pointing the Worker at a UDF in a different database is not supported.

How to install HASH_MD5 on Teradata¶

Installation is a one-time DBA task on your Teradata system:

1. Obtain the canonical HASH_MD5 install script from your Snowflake migration support or SnowConvert deployment channel. The public documentation repository does not ship the UDF DDL.
2. Run the script as a Teradata user with privileges to CREATE FUNCTION (or REPLACE FUNCTION) in each database listed in your Worker TOML database field.
3. Grant EXECUTE FUNCTION on HASH_MD5 to the Teradata user account the validation Worker uses to connect.

If you validate tables in more than one Teradata database, repeat installation in every database the Workers connect to.

Verify HASH_MD5 before running L3 validation¶

Connect as the Worker user (or any user with EXECUTE FUNCTION on the UDF) and run:

DATABASE your_validation_db;
SELECT HASH_MD5('test');

A successful call returns an MD5 hex string. If the UDF is missing or not visible in the session default database, Teradata typically returns parser errors such as 3706 (function not found or invalid argument) or 3707 (syntax errors in generated hash SQL). Enable Worker application.debug_mode = true in TOML to log the full failing SELECT at DEBUG.

Optional catalog check (replace the database name):

SELECT DatabaseName, FunctionName
FROM DBC.FunctionsV
WHERE FunctionName = 'HASH_MD5'
  AND DatabaseName = 'YOUR_VALIDATION_DB';

Connectivity¶

Validation Workers reuse the same [connections.source.teradata] TOML as data migration.

Worker TOML example:

[connections.source.teradata]
host = "teradata.example.com"
port = 1025
database = "MY_DB"
username = "your_username"
password = "your_password"
# L3 prerequisite: install HASH_MD5 in MY_DB (see HASH_MD5 UDF section)

Validation levels and Teradata behavior¶

Schema validation on views (L1): For Teradata views, L1 is a reduced comparison (column existence and datatype via HELP COLUMN metadata). Precision, scale, length, nullability, and ordinal checks aren’t available for Teradata views. Use L2/L3 for deeper assurance.

Metrics validation (L2): Full support for tables. Full support for views.

Row validation (L3): Default L3 behavior and row_validation_mode: row require the HASH_MD5 UDF. Use index_column_list for row alignment. Set column_names_to_partition_by and target_partition_size_mb or target_partition_size_rows on wide tables.

Example validation workflow excerpt:

source_platform: teradata
target_platform: Snowflake
target_database: MY_DATABASE
validation_configuration:
  schema_validation: true
  metrics_validation: true
  row_validation: true
  max_failed_rows_number: 1000
  early_stopping: true
comparison_configuration:
  tolerance: 0.001
tables:
  - fully_qualified_name: my_database.sales_transactions
    target_schema: PUBLIC
    target_name: SALES_TRANSACTIONS
    index_column_list:
      - TRANSACTION_ID
    column_names_to_partition_by:
      - TRANSACTION_ID
    target_partition_size_mb: 200
views:
  - fully_qualified_name: my_database.sales_summary_view
    target_schema: PUBLIC
    target_name: SALES_SUMMARY_VIEW
    index_column_list:
      - ID
    target_partition_size_rows: 50000

Data type mappings¶

During validation comparisons, these Teradata source types map automatically to Snowflake types:

Use comparison_configuration.type_mapping_file_path to supply a custom mapping file when needed.

Platform-specific suggestions¶

• After tpt or write_nos migrations: Validation still reads the source over SQL. Ensure Teradata objects you validate are reachable and match the validation workflow names.
• L3 cost control: Default L3 fingerprints rows before cell drilldown, which is usually cheaper than row_validation_mode: cell on large tables. Enable early_stopping and tune max_failed_rows_number per table.
• Partitioning: Use column_names_to_partition_by so wide tables don’t time out on L2/L3 scans.
• Anti-locking: AIM DMV adds LOCKING ROW FOR ACCESS automatically on every Teradata source scan. No configuration is required. See Anti-locking and query modifiers.

Ask the Snowflake AIM Agent for Data Warehouses to run validation:

Run cloud data validation for my project

Related content¶

• Data validation
• Data validation configuration reference
• Migrating Data from Teradata
• Manual Migration: Data validation