Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2008
»
SQL Server 2008 - General
»
Backup to device, UNC file, generates OS...
13 posts, Page 1 of 2
1
2
»»
Backup to device, UNC file, generates OS error
Rate Topic
Display Mode
Topic Options
Author
Message
Alocyte
Alocyte
Posted Tuesday, August 11, 2009 2:18 AM
SSC 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
kgerde
kgerde
Posted Thursday, August 27, 2009 10:53 AM
Forum 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
kgerde
kgerde
Posted Friday, August 28, 2009 2:53 PM
Forum 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
Fatherjack
Fatherjack
Posted Wednesday, October 07, 2009 4:42 AM
SSC 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
kgerde
kgerde
Posted Wednesday, November 11, 2009 4:14 PM
Forum 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
Lynn Pettis
Lynn Pettis
Posted Wednesday, November 11, 2009 4:37 PM
SSC-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
kgerde
kgerde
Posted Wednesday, November 11, 2009 4:40 PM
Forum 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
kgerde
kgerde
Posted Wednesday, November 11, 2009 9:38 PM
Forum 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
PiMané
PiMané
Posted Thursday, November 12, 2009 12:41 AM
SSC-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
Elliott Whitlow
Elliott Whitlow
Posted Monday, November 16, 2009 10:30 PM
SSCertifiable
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 »
13 posts, Page 1 of 2
1
2
»»
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.