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

Operating system Error 112 Expand / Collapse
Author
Message
Posted Saturday, April 18, 2009 4:31 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, May 8, 2014 10:08 PM
Points: 358, Visits: 397
Look. the straight copy all from the script doesn't have any kind of sorting or anything to make a lot of overhead - do you really have production servers that are so heavily loaded they can't handle a one time copy like I've suggested at some time during the week? Sounds like an upgrade is in order! Besides, compared to the original article's suggestion, I'm sure my ideas are much better all around. Since the problem is to go to a computer that has a FAT32 drive without enough space to handle the full log, I can't think of any other ways to do it.
Post #699972
Posted Saturday, April 18, 2009 4:47 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 7:53 AM
Points: 42,822, Visits: 35,952
magarity kerns (4/18/2009)
Look. the straight copy all from the script doesn't have any kind of sorting or anything to make a lot of overhead - do you really have production servers that are so heavily loaded they can't handle a one time copy like I've suggested at some time during the week?


I've worked on databases that are mission critical, heavily used and over 1 TB in size, where a script of all the data will take some hours, during which the increased IO and the flushing of data from cache will degrade performance beyond what's acceptable.

If you DBs aren't that heavily used and are small enough that the copy won't take hours, great. I'm just pointing out that it's not the case for every system and that all methods to copy databases have some advantages and some disadvantages.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #699974
Posted Sunday, April 19, 2009 12:40 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, May 8, 2014 10:08 PM
Points: 358, Visits: 397
I never deal with anything mission critical so I'll take your word for it; my own experience is 100% data warehouses where even if there is a lot of data, they're loaded in the wee hours of the night, the reporting services grind out reports before everyone comes to work and then during the day it's all data miners and other ad-hocs who expect moderate to long query times anyway. So doing the direct connection copy all objects method is just yet another long running daytime query. That's how I used to repopulate the development database from time to time and no one ever noticed it to complain. I haven't actually done the script out including data to a .sql file on a 'real' database; I admit that would be a horrendous size text file. I was throwing it out as something to consider as a better possibility than the original.
Post #700166
Posted Sunday, April 19, 2009 2:33 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, July 25, 2014 4:20 PM
Points: 34, Visits: 643
This article was in pending for several months and posted now on how I have performed/achieved in backup and restore of a 200 GB production db to a FAT32.

Thoughts and ideas are always welcome.

Mahidhar Vattem

Post #700253
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse