April 9, 2007 at 11:09 am
Hello, I am running into an error while trying to backup a database from one server to another using sql 2000. I have correct permissions and plenty of space on the drive but at the end of the backup job it fails? The backup job will run completely 100 percent but terminates abnormally at the end. Here is the error I receive after about 15minutes into the job.
Executed as user: UserName\admin. 10 percent backed up. [SQLSTATE 01000] (Message 3211)
20 percent backed up. [SQLSTATE 01000] (Message 3211)
30 percent backed up. [SQLSTATE 01000] (Message 3211)
40 percent backed up. [SQLSTATE 01000] (Message 3211)
50 percent backed up. [SQLSTATE 01000] (Message 3211)
60 percent backed up. [SQLSTATE 01000] (Message 3211)
70 percent backed up. [SQLSTATE 01000] (Message 3211)
80 percent backed up. [SQLSTATE 01000] (Message 3211)
90 percent backed up. [SQLSTATE 01000] (Message 3211)
Processed 678768 pages for database 'PROD', file '_Data' on file 1.
[SQLSTATE 01000] (Message 4035) 100 percent backed up. [SQLSTATE 01000] (Message 3211)
Processed 76 pages for database 'PROD', file '_Log' on file 1. [SQLSTATE 01000] (Message 4035)
BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed.
The sql server logs show this error as well:
BackupDiskFile::RequestDurableMedia:
failure on backup device '\\"ip_address"\e$\mssql\backup\PROD_FULLBACKUP'.
Operating system error 64(The specified network name is no longer available.).
Any ideas?
April 9, 2007 at 1:32 pm
I'm not a network person, but it looks like you have lost connection to the remote server you are trying to backup the database to. If you have the space, I would backup to a local drive first, then move the file across the network to the remote server.
April 9, 2007 at 1:52 pm
The connection is up and fine? We are currently backing up to a local drive but wish to backup to another server for a failover situation. Any more suggestions.
April 9, 2007 at 2:09 pm
I would recheck your connection...SQL Server says it can't see the remote drive. If it is even a momentary drop of the connect, it's gone as far as SQL is concerned. Another thing to check though, is there an antivirus program running? Could it have started checking the file while the backup was going on?
-SQLBill
April 9, 2007 at 2:18 pm
Even if you want to backup to a network server for failover purposes, I would still do the backup to a local drive and then move it seperately. The backup will (or should) complete much quicker when done locally than if done over the network. Also, if you have a network failure, it won't affect the actual backup from completing.
April 9, 2007 at 2:31 pm
Are you getting this error often??
If so check the server you are backing up to and look for mrxSMB erors and LAN redirector errors in the event log if this is the case you could be suffering from overflowing the unc connection. This was supposed to be fixed in Server 2003 SP1 but I still occasionally see this.
I would however say that sql server backups seem to be quite sensitive to network errors and I still occassionally see this error on my servers but it does appear to be a windows issue.
hth
David
April 10, 2007 at 6:58 am
I have a job that on step 1 backs up the databases on a scheduled time and on the next step moves those databases to another server. I have not received an error in the last 4 months at all. So I recommend this kind of set up instead backing up to network location directly.
July 28, 2009 at 9:59 am
I don't have a spare TB to use for the initial file creation. On a different server I have 2+ TB available.
I cannot get a full backup using M$ tools at this client except once. 🙁
I am attempting to replace an AVAMAR tool set for the current backup.
There are HIPPA compliance issues that need to be addressed.
July 29, 2009 at 4:32 pm
On the destination server . . . for a test . . .
Can you manually copy a large file through the network share?
i.e. Use any workstation and connect to the destination share point and copy over a test 1TB file to it?
(Some file that's really really big - a few hundred GB at least.)
Is that something the destination server can handle?
You may find the destination server has an issue with allocating resources for such a large file(s.)
(For whatever reason . . . AV software, file handles, etc.)
I had a similar issue (not really the same, but ya never know - I'm throwing this out to see if it'll stick) with our primary file server (W2K3.)
I'd performed backups to the local disk on the SQL server and then try to copy the backup file (via script or manually) to the primary file share.
No matter what . . . that file server wouldn't accept any files of that size.
Simple copy/paste to a network share would die if the file was too large.
But, copying/pasting the same file worked on other servers / workstations . . .
(But of course the primary file server is the only one that is backed up to tape.)
Maybe . . . maybe . . . maybe . . .
(and the test shouldn't hurt anyways.)
Free Expert Advice . . .
http://xkcd.com/627/
Mark
August 28, 2009 at 2:49 pm
I have called Microsoft on this issue and found that the following does work
open regedit
navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters
Create a New DWORD value with the name SessTimeout
the value to 360 keep it Hexadecimal
(This value might not work for your backup but it was high enough for mine. If this doesn't work increase the value and try again.)
I hope this helps.
Thanks,
kgerde
August 31, 2009 at 8:39 am
If nothing works from all the suggestion, then you need to verify that the sql server account should have write access to the network share.
Thanks
Swarndeep
http://talksql.blogspot.com
September 9, 2009 at 9:18 pm
On which server should we edit registry... ?
kgerde (8/28/2009)
I have called Microsoft on this issue and found that the following does workopen regedit
navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters
Create a New DWORD value with the name SessTimeout
the value to 360 keep it Hexadecimal
(This value might not work for your backup but it was high enough for mine. If this doesn't work increase the value and try again.)
I hope this helps.
Thanks,
kgerde
September 9, 2009 at 9:39 pm
Microsoft recommended editing the registry on both the SQL server and the backup location. If you find you do not have to edit this on one or the other please let me know. I just went ahead and did both before finding the issue was fixed.
February 4, 2010 at 7:13 am
Did this solutiion work for you? We tried it and we still have a case open with MSFT. We're now trying to get a NetMon trace when the intermittent error occurs.
KU
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply