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?
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Del Hoobler Sent: Wednesday, October 04, 2006 10:28 AM To: [email protected] Subject: Re: TDP for SQL Large DB Restoration Pranav, The SQL Server is performing the "preformat" of your SQL database files. The amount of time it will take depends on the types of disks, speed of disks, and database file layout. Data Protection for SQL is "blocked" until the SQL Server finishes the database preformat. I would boost COMMTIMEOUT to a very high number to find out what you will need to set the value at. For example, start with: SETOPT COMMTIMEOUT 99999 and then examine the operations to find out how long it actually takes. Thanks, Del ---------------------------------------------------- "ADSM: Dist Stor Manager" <[email protected]> wrote on 10/04/2006 12:00:10 AM: > Hi, > > We are facing peculiar problem and request help to resolve it on war-foot > basis. > > > We had a SQL DB running as a back-end to SAP in Win2k cluster. We are able > to successfully backup of our on-line SQL DB of 180GB approx. using > TDP For SQL 5.3 on the autoloader connected to TSM server on LAN everyday. > However, restoring same fails with an error: > > ANR0481W Session 609 for node DBGRP (TDP MSSQL) terminated - client > did not respond within 800 seconds. > > Restore process continue to format db for a long hours and then > restore ends prematurely dismount the volume mounted in the drive. We > have already increased committimeout option from various values to as > large as > 28800. Even at such high value, restore operation ends after 6 to 8 > hrs of > long wait. > > We are not sure what value we should use as a committimeout to restore > approx. 180GB DB. > > Any help will be highly appreciated. > > Regards > Pranav
