Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Backup to device, UNC file, generates OS error Expand / Collapse
Author
Message
Posted Tuesday, August 11, 2009 2:18 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, November 16, 2012 4:39 AM
Points: 31, Visits: 104
Hi friends, family and fellow SQL dba's

I have a bit of a bother, and it's OS / SQL related. I backup to a UNC device, and frequently get a network related error - but not always. And the error is also OS related...

The scene: 64 bit Windows Server 2008 hosts 64 bit SQL 2008 Standard, and devices are created to point to 64 Server 2008 Server B (\\ServerB\SQL_backups\dvc_DB.bak). The database is backed up daily, on a job, and when run the following error is returned:
Date 2009/08/08 06:43:30 AM
Log Job History (Backup_AssetData_2009-08-08)

Step ID 3
Server SQL01
Job Name Backup_AssetData_2009-08-08
Step Name Backup Database - Second Attempt
Duration 00:05:33
Sql Severity 16
Sql Message ID 3013
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0

Message
Executed as user: COMPANY\SERVICE_USER. Processed 94096 pages for database 'AssetData', file 'AssetData' on file 1. [SQLSTATE 01000] (Message 4035) Processed 1 pages for database 'AssetData', file 'AssetData_log' on file 1. [SQLSTATE 01000] (Message 4035) The operating system returned the error '64(failed to retrieve text for this error. Reason: 15105)' while attempting 'FlushFileBuffers' on 'dvc_AssetData(\\riscsrv-dcm04\RISCSRV-SQL01_Backups\dvc_AssetData.bak)'. [SQLSTATE 42000] (Error 3634) BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013). The step failed.


The file is generated, the same size as a successful backup, but the job terminates unsuccessful.

I have tried to delete the devices' file, and then the backup usually succeeds. This may point to a permissions' type error, but the user the job is run under is a domain admin. The destination server is not unavailable during this time, and the network shares also remain active throughout the excersize - although I haven't got a way to "prove" this.

I am hoping someone can help me identify the cause of the problem, or has experience with a similar problem which has been resolved.

I have a few databases that backup to the UNC described above (different files) that don't fail... some bigger, some smaller.

My SQL2000 server backs up it's databases to the SQL2008 server, and those backups don't fail with this error.

My research has led me to understand that the 64bit OS tries to buffer the files it receives from another server, and I was wondering if this could be influencing the backups as the destination server is also 64 bit Windows Server 2008.

##20090812## UPDATE
I tried another way to do the backup; with the same results:
Backup database Infovest to disk = '\\riscsrv-dcm04\riscsrv-sql01_backups\dvc_Infovest_Z.bak' with INIT,STATS=1
...
98 percent processed.
99 percent processed.
Processed 3422232 pages for database 'Infovest', file 'InfoVest_Data' on file 1.
100 percent processed.
Processed 14383 pages for database 'Infovest', file 'InfoVest_Log' on file 1.
Msg 3634, Level 16, State 2, Line 1
The operating system returned the error '64(failed to retrieve text for this error. Reason: 15105)' while attempting 'FlushFileBuffers' on '\\riscsrv-dcm04\riscsrv-sql01_backups\dvc_Infovest_Z.bak'.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.
##Update end##

Thanks,
Habeeb


So long, and thanks for all the fishpaste
Post #768429
Posted Thursday, August 27, 2009 10:53 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 17, 2011 10:33 AM
Points: 7, Visits: 61
I am having the exact same issue. This is from an SQL 2008 Web Edition fully patched as of today running on Windows 2003 Ent. 64 bit backing up to an identical machine. I have also tried backing up to another identical machine which never had SQL 2008 installed. just to rule out extra issues.

I get the same error as you OS error 64...

I have found this happens more often when the unc path points to a slower write capacity disk but it also seems to happen every time when the disk is raid 5 72 gb 15k sas disks. I have never seen this happen on a RAID 1 pair of the same disks. I have seen it happen more often than not on a SAN which kills my idea that it is due to a disk I/O bottle neck.

Is anyone else seeing this error while you know that the disks in question are still accessible?

I know this isn't an answer however maybe this will help the community find it.

Thanks,
Post #778485
Posted Friday, August 28, 2009 2:53 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 17, 2011 10:33 AM
Points: 7, Visits: 61
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
set the value: 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
Post #779322
Posted Wednesday, October 07, 2009 4:42 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Thursday, May 23, 2013 12:53 PM
Points: 273, Visits: 451
kgerde - Can you confirm that the registry change is carried out on the backup location server?

Thanks
Jonathan
Post #799044
Posted Wednesday, November 11, 2009 4:14 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 17, 2011 10:33 AM
Points: 7, Visits: 61
Confirmed I made the change to both machines the backup target and the SQL server. I am going to attempt testing this in a non production system with just the change on the backup target and then just the change on the SQL server to figure out what the minimum required change is.
Post #817537
Posted Wednesday, November 11, 2009 4:37 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Yesterday @ 9:17 PM
Points: 21,832, Visits: 27,855
If I may, if you have room on the database server to complete your backup locally, I'd do that and THEN move the backup file to the other server. This way if there is a failure on the network or remote server it doesn't cause your backup to fail.




Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #817545
Posted Wednesday, November 11, 2009 4:40 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 17, 2011 10:33 AM
Points: 7, Visits: 61
I agree 100% with you and I do this every time. However, some people don't have this option and thus I have a job.
Post #817546
Posted Wednesday, November 11, 2009 9:38 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 17, 2011 10:33 AM
Points: 7, Visits: 61
I made the change only on the target backup server and it seems to work without having to make the change on the SQL server. I could just be getting lucky as I am not able to reliably reproduce the errors.
Post #817591
Posted Thursday, November 12, 2009 12:41 AM


SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, May 15, 2013 5:02 AM
Points: 403, Visits: 904

If I may, if you have room on the database server to complete your backup locally, I'd do that and THEN move the backup file to the other server. This way if there is a failure on the network or remote server it doesn't cause your backup to fail.

Lynn Pettis

Couldn't agree more. First do the backup to your local storage, or SAN if you have some, then move it to the other server or tape, whatever you use for backup storage.
It's faster (faster IO on local disks then through network or tape) and safer cause, like Lynn says, it's "network failure" proof..

Pedro




If you need to work better, try working less...
Post #817639
Posted Monday, November 16, 2009 10:30 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 10:09 AM
Points: 5,863, Visits: 4,886
PiMané (11/12/2009)

If I may, if you have room on the database server to complete your backup locally, I'd do that and THEN move the backup file to the other server. This way if there is a failure on the network or remote server it doesn't cause your backup to fail.

Lynn Pettis

Couldn't agree more. First do the backup to your local storage, or SAN if you have some, then move it to the other server or tape, whatever you use for backup storage.
It's faster (faster IO on local disks then through network or tape) and safer cause, like Lynn says, it's "network failure" proof..

Pedro

Now this I agree with, I hate to back it up locally so I can move it to another disk somewhere else and then to tape.. What a waste, I like to write it to SAN right from the git-go and then it can be swept off to tape from there...

CEWII
Post #819811
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse