I'm currently testing TTU 14.00 and experienced an issue when using tdload to move a table (5.3b rows, 600gb) from one system to another. Unfortunately, I'm not sure if the table load actually completed (log indicate it did but only applied 965m rows) as another user dropped/recreated the table and restarted the job. The UV, ET and LOG tables were deleted by the job. I was able to catch the table size before it was dropped and it was much smaller than expected so looks like it probably took the 965m rows.
Anyone have any idea what my issue may be here? Thanks.
Teradata Load Utility Version 14.00.00.09
executed via (initial run didn't include a checkpoint interval but one was included when it was restarted):
tdload -j myjob.var
SourceTdpId = 'sys1',
SourceWorkingDatabase = 'test',
SourceTable = 'spr',
SourceUserName = 'testuser',
SourceUserPassword = 'xxxxxxxx',
TargetTdpId = 'sys2',
TargetWorkingDatabase = 'test',
TargetTable = 'spr',
TargetUserName = 'testuser',
TargetUserPassword = 'xxxxxxxx',
TargetMaxSessions = 16,
TargetMinSessions = 8
Job error output:
LOAD: RDBMS Warning: 6813 Numeric overflow in internal counters. The number of rows returned is actual number of rows returned, modulo 2^32.
$LOAD: Statistics for Target Table: 'spr'
$LOAD: Total Rows Sent To RDBMS: 5259745852
$LOAD: Total Rows Applied: 964778556
$LOAD: Total Rows in Error Table 1: 0
$LOAD: Total Rows in Error Table 2: 0
$LOAD: Total Duplicate Rows: Unknown due to RDBMS 6813 warning code
$LOAD: disconnecting sessions
$EXPORT: disconnecting sessions
The number of rows returned is actual number of rows returned, modulo 2^32.
5259745852 MOD 2**32 = 964778556 :-)
Regarding the smaller size, e.g. this might be caused by:
- copy to an appliance with block level compression
- less secondary indexes
Thanks Dieter, next time I will read what the message says rather than freaking out about a warning :) Thanks again.