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
teradatasqlwhen available; otherwise setodbc_driverto the exact registered driver name. Optionaldbc_name, port 1025 by default, optionalauthentication(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 (metrics and row-level validation). You don’t need
write_nos_*TOML ortbuildon a host solely running validation, unless the same Worker also executes migrationtptorwrite_nostasks.
HASH_ MD5 UDF¶
Teradata does not provide a built-in SQL function that Cloud Data Validation can use for 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. Row-level validation uses it to fingerprint each source row and compares the result against a matching hash on the Snowflake target. Schema and metrics validation don’t use it.
Where the UDF must be installed¶
| Requirement | Detail |
|---|---|
| Function name | Must be exactly HASH_MD5 |
| Database | Same database as [connections.source.teradata].database in the Worker TOML |
| Name qualification | Generated SQL calls HASH_MD5(...) without a database prefix |
| Multiple source databases | Install the UDF in each Teradata database used as a Worker source database |
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:
- Obtain the canonical
HASH_MD5install script from your Snowflake migration support or SnowConvert deployment channel. The public documentation repository does not ship the UDF DDL. - Run the script as a Teradata user with privileges to
CREATE FUNCTION(orREPLACE FUNCTION) in each database listed in your Worker TOMLdatabasefield. - Grant
EXECUTE FUNCTIONonHASH_MD5to 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:
A successful call returns an MD5 hex string. If the call fails, the UDF is likely missing from the session’s default database. Reinstall it there and retry.
Optional catalog check (replace the database name):
Prompt:
Connectivity¶
Validation Workers reuse the same [connections.source.teradata] TOML as data migration.
Worker TOML example:
| Topic | Data migration (load) | Cloud Data Validation |
|---|---|---|
| Purpose | Move data with regular, write_nos, or tpt | Compare live Teradata tables/views to Snowflake with schema, metrics, and row-level validation |
write_nos_* TOML | Required when strategy is write_nos | Not required for validation-only workloads |
tbuild / TTU | Required for tpt migration tasks | Not required for validation-only Workers |
Validation levels and Teradata behavior¶
Schema validation on views: For Teradata views, schema validation 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 metrics and row-level validation for deeper assurance.
Metrics validation: Full support for tables. Full support for views.
Row validation: Requires the HASH_MD5 UDF. Use indexColumnList 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:
Data type mappings¶
During validation comparisons, these Teradata source types map automatically to Snowflake types:
| Teradata type | Snowflake target type | Supported for validation | Notes |
|---|---|---|---|
| BYTEINT, SMALLINT, INTEGER, BIGINT | NUMBER | Yes | |
| NUMERIC, NUMBER, DECIMAL | NUMBER | Yes | |
| FLOAT, REAL, DOUBLE PRECISION | FLOAT | Yes | |
| DATE | DATE | Yes | |
| TIME | TIME | Yes | |
| TIME WITH TIME ZONE | TIME | Yes | |
| TIMESTAMP | TIMESTAMP_NTZ | Yes | |
| TIMESTAMP WITH TIME ZONE | TIMESTAMP_TZ | Yes | |
| CHAR, VARCHAR | VARCHAR | Yes | |
| BOOLEAN | No | ||
| CLOB | No | ||
| BYTE, VARBYTE, BLOB | No | ||
| JSON, XML | No | ||
| ST_GEOMETRY | No | ||
| INTERVAL types | INTERVAL | Yes | Native INTERVAL comparison by default. See INTERVAL data type handling. |
| PERIOD types | No | ||
| ARRAY | No | ||
| LONG VARCHAR, GRAPHIC, VARGRAPHIC, UNICODE types | VARCHAR | Partial | Row-level and metrics validation not supported |
Use comparison_configuration.type_mapping_file_path to supply a custom mapping file when needed.
Platform-specific considerations¶
-
Starting validation: Ask the agent to generate a validation workflow with the depth you need (schema validation, metrics validation, and row-level validation, per table).
Prompt:
-
After
tptorwrite_nosmigrations: Validation still reads the source over SQL. Ensure Teradata objects you validate are reachable and match the validation workflow names. -
L3 cost control: Enable
early_stoppingand tunemax_failed_rows_numberper table to avoid scanning partitions on a table that has clearly failed. -
Partitioning: Use
column_names_to_partition_byso wide tables don’t time out on metrics and row-level validation scans.Prompt:
-
Anti-locking: AIM DMV adds
LOCKING ROW FOR ACCESSautomatically on every Teradata source scan. No configuration is required. See Anti-locking and query modifiers.