Problem restoring TDPSQL DB...

[spiffy]

I am seeing a weird issue when I am trying to restore a SQL DB.
I am using the TDPSQL GUI, i do the usual restore steps to restore the DB(not overwriting existing DB) and it starts. It loads the tape needed, then it gets to 3.5MB restored and just holds there.
the DB is 80GB, i have checked the TSM server log, no errors, drives are online, no errors on them, TSM server is fine, it just will not continue along.
DB is being restored to the same server that hosts the DB,same drive, HD space is 126GB.
The restore was done 2 days ago on the same DB from an earlier day, it ran to almost complete and failed at the end with ANE4993E

ANyone else see this before? TSM is not too busy either.
TSM is 5.3.0.0, TDPSQL client is 5.2.1.0

any suggestions on what I can do would be appreciated.

Thanks
JAmes

 

[dms19]

The act log shows nothing in regards to authentication, space, or tape issues?

Was the SQL DB setup with a recovery database that can accomodate the 80gb database?

 

[spiffy]

I ended up having to change my dsmserv.opt file from commtimeout from 3600 to like 18000 or something like that, it equated to 300 minutes or so.

THis is what TSM support saw when a trace was initiated


From the trace, it looks like TSM is still waiting for a response from the SQL server. We can see in the API trace that there is no communication at all after we restore the first chunk of data until the timeout is hit an hour later
1. The database is started to be restored.
A small amount of data is restored is from the TSM Server. This is the 3.5 MB you see in the q sess output.
2. The SQL server looks at that data and sets up the database.
The SQL Server preformats the files.
If the database is large, as in your case, the initialization of the file could take a long time.
3. After the SQL Server is done preformatting the files, it continues restoring the rest of the data. It looks like the SQL Server is still working to preformat the files when one of two things happen:
1. You cancel the restore or
2. COMMTIMEOUT on the server hits and cancels the operation.
The way to get around this issue is to increase the COMMTIMEOUT value to something very large (5 hours?). It needs to be large enough to allow the SQL Server to finish preformatting the files.
After upping the COMMTIMEOUT, try the restore again. After it succeeds, decrease the COMMTIME back to an hour

Make sure you set your commtimeout back to what it was, apparently if this is not done, the tsm server can have sessions waiting for a long time, tying things up...