Thanks, Del I've increased COMMTIMEOUT up to 5 hrs. Restore went OK.
----- Original Message ----- From: "Del Hoobler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 30, 2003 10:24 PM Subject: Re: TDP 4 MSSQL restore > Vladimir, > > Yes. I know what the problem is. > > There is a known situation that you must handle > when restoring very large SQL databases. > > Basically, this is what happens: > > 1. The database is started to be restored. > A small amount of data is restored from the TSM Server. > > 2. The SQL server looks at that data and sets up the database > according to the information that it finds in first part > of the backup data. The SQL Server preformats the files. > If the database is large... the preformatting and initialization > of the files could take a long time. The SQL Server is spending > most of the time preformatting the files. > > 3. After the SQL Server is done preformatting the files, > it continues restoring the rest of the data. > > The SQL Server is still working to preformat the files > when the COMMTIMEOUT on the server times out and cancels > the operation. > > > The way to get around this issue is to increase the > COMMTIMEOUT value to something very large. > It needs to be large enough to allow the SQL Server > to finish preformatting the files. > > Increase the COMMTIMEOUT to something very large > (like 5 hours which is 18000 seconds) > > then... retry the restore. > > > This is known issue and there is a requirement opened > against the TSM Server to allow COMMTIMEOUT > to be set on a NODENAME basis... since you don't > normally want to set COMMTIMEOUT that large > for all nodes. > > By the way, it is also documented in the IBM Support Solutions > Database under reference # 1079494. > > Thanks, > > Del -- This message was sent with an unlicensed evaluation version of Novell NetMail. Please see http://www.netmail.com/ for details.
