Restoring SQL DB to alternate node

[droach]

I am running a 6.4.1 client and am trying to restore a SQL database taken on on TSMServerA, Client A and restore to ClientB that is usually connected to TSMServerB. CLientB can "see" both TSM servers on the network, and I have done the usual modification of ClientB's dsm.opt file to present itself as ClientA to TSMServerA and sync'ed the TSM passwords.

This all appears to be working, but when I start a full SQL DB restore it runs for a while then the session goes into SendW state. It usually transfers about 3MB to 10MB up to this point. It sits there doing nothing until my CommTimeOut limit (3600) is reached and the session is terminated. In the tdpsql.log I see this at the end of the run:

06/16/2015 17:02:56 ACO5436E A failure occurred on stripe number (0), rc = 118
06/16/2015 17:02:56 ANS1017E (RC-50) Session rejected: TCP/IP connection failure
06/16/2015 17:02:56 Restore of XYZ_APP_D failed.
06/16/2015 17:02:56 ANS1017E (RC-50) Session rejected: TCP/IP connection failure​

So it appears to me that the client is not responding to some acknowledgement that the TSM server is expecting. There are no prompts on the client side and during the one hour wait for the timeout the client just sits there.

Any ideas what might be going on here?

 

[moon-buddy]

When you modified the dsm.opt file (both for BA and TDP for SQL, I hope) did you just change the node name, and then update password locally on the node?

 

[droach]

moon-buddy, thanks for your reply. Yes I did all that and still no joy, but a colleague of mine figured it out. He found a Technote article that described our situation. Here is a link

Problem(Abstract)
ACO0302E rc = 418, ANS1017E (RC-50) TCP/IP connection failure, and ANR0481W on the Tivoli Storage Manager Server during a Data Protection for SQL restore operation.

Cause
Exceeding the COMMTIMEOUT setting on the Tivoli Storage Manager Server is a common problem during Data Protection for SQL restores. The problem occurs because the SQL Server spends time rebuilding and formatting the new physical files that the backup data will be restored into. For large databases, this process can take over an hour, and the Tivoli Storage Manager session will remain in a SendW (Send Wait) state for this time period which is counted against the COMMTIMEOUT option.

Resolving the problem
For the restore to be successful, increase the COMMTIMEOUT value on the Tivoli Storage Manager Server using the command SETOPT COMMTIMEOUT. This value should be increased to at least 3600, and may need to be set over 10000 seconds for very large databases.​

We set the CommTimeOut to 18000 (was at 3600) and the restore completed.