FastLoad process hang with concurrent sessions

Teradata Applications
Enthusiast

FastLoad process hang with concurrent sessions

Hi,

We have an application spawns multiple FastLoad sessions to move data from Microsoft SQL server to Teradata concurrently. We are running the application on Microsoft Windows Server 2012 R2 and have been observed random errors where some FastLoad sessions in hung state. 

When the process hangs, in the FastLoad generated log file, it always stops at AXSMOD command, "0009 AXSMOD Oledb_Axsmod "noprompt jobid=1”;".

We tried to add "-v" option to FastLoad command but no usefaul information in FastLoad log file. Looks like there is an issue for multiple FastLoad sessions connect to OleDB driver at the same time but we are not sure. Is there anyway we can troubleshoot the issue other than adding "-v" option to FastLoad command?

Best,

J.D.

Tags (2)
11 REPLIES
Enthusiast

Re: FastLoad process hang with concurrent sessions

I have never loaded from SQL Server and do not have much idea. My opinion -----Anyone monitoring viewpoint? The link below gives an explanation on AXSMOD too if it helps.

http://www.info.teradata.com/HTMLPubs/DB_TTU_14_00/index.html#page/Load_and_Unload_Utilities/B035_24...

Enthusiast

Re: FastLoad process hang with concurrent sessions

Thanks for the reply! The information does not really help. Maybe I should rephrase my question...

Is there any limitation about running miltiple concurrent FastLoad sessions on Windows Server 2012?

Enthusiast

Re: FastLoad process hang with concurrent sessions

 I am bad in Windows env :) to be honest.

Teradata Employee

Re: FastLoad process hang with concurrent sessions

How many concurrent processes are you running? What I'd do is run load tests with varying levels of concurrency to see how reliably I can reproduce the error and to see if lower levels of concurrency mediates the error. 

Enthusiast

Re: FastLoad process hang with concurrent sessions

The concurrency is 5 but we observed the same issue even at 3. We are wonering if this only happens on "Windows 2012 R2" because we have another machine running "Windows Server 2008 R2" and it seems to be handling 5 concurrent FastLoad sessions without any problem. If TD can identify the issue, will be very helpful to other customers using Windows Server 2012 as FastLoad platform.

We are using td-ttu-14.10.

Teradata Employee

Re: FastLoad process hang with concurrent sessions

Thats good info. Concurrency of 5 is fairly low. If you aren't having the problem on another machine then I think we can be fairly certain its localized to your "Windows 2012 R2". The next test I'd do is to find another "Windows 2012 R2" server to run the test on and see if you have the same issue. If you don't have another server I'd try uninstalling the TTU and reinstalling it. You might also run a full diagnostic on the "Windows 2012 R2" server to see if there are any other problems. The other option is to submit a ticket with TAYS (Teradata At Your Service) or call  the Teradata GTS(Global Teradata Support)  877-698-3282 to submit a ticket. I've never seen this problem before myself. 

Enthusiast

Re: FastLoad process hang with concurrent sessions

We tried this on four different Windows Server 2102 R2 machines and they all have the same issue. Another data point is our ETL servers are on AWS and accessing the Teradata Server in our data center. We have direct connect between AWS and our data center so the latency is very small.

We will open a ticket at TAYS.

Enthusiast

Re: FastLoad process hang with concurrent sessions

hi 

can any one tell me is it compolsoury that datatype of source file in informatica should be match with datatype of table in teradata  

if i use fastload.

i am loading file to teradata table through informatica by using fastload.

Enthusiast

Re: FastLoad process hang with concurrent sessions

You could have created a new topic :).

With Td 14 onwards most of the datatypes are available/compatible with almost all ETL tools or interfaces.eg Char , varchar may work. But it may fail in certain scenarios. Why to give chance for an error to creep in.