This is expected behavior. This is documented in the DP/SQL User's Guide:
Note: When restoring large SQL databases, specifying a value of
at least 10000 in the commtimeout option will help prevent
a restore operation from ending prematurely. If the restore
operation is performed in a LAN free environment, this value
must be specified for the Storage Agent.
And it is also documented in the following IBM Technote:
http://www-1.ibm.com/support/docview.wss?uid=swg21114216
SQL Server backups are a stream of bytes. At restore time,
the SQL Server will ask for a very small amount of that
stream first. The SQL Server looks at the stream of bytes
to be able to know exactly how to rebuild that database.
The SQL Server then goes off and preformats the files
and whatever else it needs to do in order to restore
the remainder of the bytes. During this preformat time,
the TSM Server remains in SendW state.
I hope this helps.
Thanks,
Del
----------------------------------------------------
"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 10/04/2006
05:41:01 PM:
> We are also experiencing this same issue with the TDP SQL client. We
> just restored a 41 GB database in about an hour and a half. We
> previously had cancelled the restore several times because the session
> was in a SendW, and we thought it was hung. Then it failed because it
> timed out after an hour. I finally tried maxing out the commtimeout,
> and we just let it go. The session remained in a SendW the entire time.
> Yet when it completed, all of the data had been transferred. Is it
> normal for the session to remain in a SendW even while data is being
> transferred?
