Red Gate forums :: View topic - Problem with Network Copy / D2D Location
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Backup 7
SQL Backup 7 forum

Problem with Network Copy / D2D Location

Search in SQL Backup 7 forum
Post new topic   Reply to topic
Jump to:  
Author Message
LehighDBA



Joined: 19 Jul 2006
Posts: 17
Location: Allentown, PA, USA

PostPosted: Mon Nov 19, 2012 4:24 pm    Post subject: Problem with Network Copy / D2D Location Reply with quote

We are using SQL Backup 7.2.1.4

We are running a backup of a database to a local drive w/ network copy to a share exposed on an HP B6200 (http://h17007.www1.hp.com/inc/whatsnew/november/B6200-en.aspx). The network copy operation results in errors on the HP B6200 indicating a problem with copying the file. For instance – “[ssid1] : Too many files open file handles on NAS share Redgate:/OurDBServer_CustomerDatabase_FULL_20121113_070000.partial”. We have noted that the recommended maximum concurrent backup streams per share on the B6200 is 12.

In this case we would have expected to see one backup stream (file copy stream) open to the B6200. Is the Network Copy functionality actually breaking the backup file into segments to transfer to the remote location in order to achieve higher bandwidth? Have you seen behavior(s) like this before with copying to a location such as the B6200? If so – what possible solution(s) would you suggest other than manually staggering the backups?
Back to top
View user's profile Send private message
petey



Joined: 24 Apr 2005
Posts: 2305

PostPosted: Tue Nov 20, 2012 1:39 am    Post subject: Reply with quote

Quote:
Is the Network Copy functionality actually breaking the backup file into segments to transfer to the remote location in order to achieve higher bandwidth?


No, SQL Backup does not split the backup file into multiple segments to copy the file.

Could you please try using the USESIMPLECOPY option in your backup command e.g.

Code:
EXEC master..sqlbackup '-sql "BACKUP ... WITH USESIMPLECOPY ..."'


This causes SQL Backup to use the Windows API to copy the file, instead of its internal copy process. The difference is that if the copying fails midway, USESIMPLECOPY will restart from the beginning, while the internal copy process tries to restart from where it last failed. For the purpose of this test, we just want to know if your issue lies with the internal copy process.
_________________
Peter Yeoh
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 7
Back to top
View user's profile Send private message Send e-mail
LehighDBA



Joined: 19 Jul 2006
Posts: 17
Location: Allentown, PA, USA

PostPosted: Tue Nov 20, 2012 11:40 pm    Post subject: Reply with quote

We tried this - and had the same result. We did it again while watching with file monitor - I'd like to send you the output of that via email so you can see what appears to be happening.
Back to top
View user's profile Send private message
petey



Joined: 24 Apr 2005
Posts: 2305

PostPosted: Wed Nov 21, 2012 2:11 am    Post subject: Reply with quote

Sure, you can send me the output, at peter.yeoh@red-gate.com.
_________________
Peter Yeoh
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 7
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group