I'm running a SQL Server 2016, and connectivity to a Teradata DQ, using a Connector created in the SSIS pkg that uses the Teradata Driver and Attunity Provider to help use the TPT loader to FastLoad a SQL Server table. In running a particular monthly job its never a problem, but now we are backing this up to process 10 months of data instead of the typical 2 months. We done this before many times in the past with no issues, but now we get a failure during the step that extracts data from Teredata and fastloads into the SQL Sever table. The number of rows: 531,271,833. More on the Error messages:
"Load Error: TPT Export error encountered during Processing phase. The FastExport Select Request has been aborted."
"TPT export failed to get row. 2595 teradata source."
"SSIS Error code DTW_E_Primeoutputdfailed. The PrimeOutput method on Terada Soruce retruned a failure doe 0x80004005. The component returnbed a failure code when the pipeline engine called PrimeOutput(). The meandingf of the failure code is defined by the components, but the error is fatal and the pipeline stopped executing."
In doing some searching, I found some old mentions of this, and people altering the default blocksize within the package that deals with values that Teradata/TPT uses when moving volumes of data.
Any help in solving this problem would be great, I'll be setting back up later this evening for another run, and would like to make soe tweaks bore hand, as the 2 month run is 4 hrs, and the 10 months run is far longer, and this failure happned about 8.5 hours into the jobs run.
The 2595 is the Export operator reporting that it was aborted by something else. It would help if you could determine what was the root cause, e.g. if the abort was issued on the database side, there should be something logged in DBC.Software_Event_LogV around that time.
Tuning the blocksize may improve transfer throughput / reduce elapsed time - so might help if the problem was some sort of "timeout".
I'm more on the SQL Server Dev/DBA side not, not as much on the Teradata Dev/DBA as I used to be, so I cant see the logs. I had suspected this was a in the middle of the night abort on the TD side on my long running extract to SS. Generally the exensive logs I have on the SSIS pkg that fails it gives enough clues to knowfor sure it was no space, aborted by user, spool, etc... but this one was a first. I have been sucessful in the past to load even more data than this throgh these same load processes, as well as a 36+ hour single job run that spends half that time in extract from TD with no issues. I'm going to mark this off as systems hickup, and start it again Friday evening, and trend onto thin ice with more systems down time! :) But I have to get it run and done. Thanks for your response.