1. Community Tip: Please Give Thanks to Those Sharing Their Knowledge.
    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.
    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

Problem restoring TDPSQL DB...

Discussion in 'TDP/Application Layer Backup' started by spiffy, Jul 5, 2007.

  1. spiffy

    spiffy ADSM.ORG Member

    Feb 9, 2007
    Likes Received:
    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, TDPSQL client is

    any suggestions on what I can do would be appreciated.

  3. dms19

    dms19 ADSM.ORG Member

    Jan 4, 2006
    Likes Received:
    TSM Admin
    In your head...
    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?
  4. spiffy

    spiffy ADSM.ORG Member

    Feb 9, 2007
    Likes Received:
    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...

Share This Page