How can we help you today? How can we help you today?
davidfreye
Activity overview Badges (0) Posts (1) Comments (2)

Activity overview

Latest activity by davidfreye

I was having this same issue which lasted 2 days before I found the USESIMPLECOPY command to put into my script..My question now is, should I leave it in there or now that all my processes have caught up and everything looks to be the way it should? I want to make sure that this 'fix' is something that can be used long term or if its just something to use to fix the issue. Thanks / comments
  1. Community
  2. SQL Backup Previous Versions
  3. Infinite copy loop
I was having this same issue which lasted 2 days before I found the USESIMPLECOPY command to put into my script..My question now is, should I leave it in there or now that all my processes have cau...
0 votes
Log backup for a database failing to get copied to the log shipping share Category: Troubleshooting & error messages Date: 18 Feb 2010 Product: SQL Backup During the process of a log shipping job, SQL Backup may log something similar the following error: "COPYTO error: Unable to copy F:\backup\SVR_LOG_DB_xxxxx.sqb to \\SERVER\Transactionlogs\SVR\DB\SVR_LOG_DB_xxxxx..sqb (Source file does not exist: F:\backup\SVR_LOG_DB_xxxxx..sqb)." In version 6 of SQL Backup, the behaviour of the COPYTO keyword has changed for transaction log backups. When you create a transaction log backup file using SQL Backup, and request that the file is copied to another location (either using the COPYTO keyword, or with the "Copy to location" setting in the SQL Backup wizards), the backup files are placed in the log copy queue before they are copied. SQL Backup checks the log copy queue regularly for transaction log files that are waiting to be copied. Files are then copied in the correct order; log files for lower LSNs are copied first. If there is a problem during the copying process (caused by an extended network outage, for example) and the copy fails, the files remain on the log copy queue, ready for another copy attempt. By default, SQL Backup attempts to copy each transaction log backup file as soon as it is added to the log copy queue. If the first copy attempt fails, subsequent copy attempts are made according to the following schedule: Copy attempt - Copy attempt is made... 1 - immediately 2 - 2 minutes after the 1st copy attempt failed 3 - 4 minutes after the 2nd copy attempt failed 4 - 6 minutes after the 3rd copy attempt failed 5 - 8 minutes after the 4th copy attempt failed 6 - 10 minutes after the 5th copy attempt failed All subsequent copies - 10 minutes after the preceding copy attempt failed SQL Backup will continue trying to copy the oldest transaction log backup file every 10 minutes, for up to 24 hours. If you wish to revert to the previous copy behaviour for transaction log backups, edit your log backup job on the source server and add the replace the USESIMPLECOPY keyword. / comments
  1. Community
  2. SQL Backup Previous Versions
  3. COPYTO failed after Mirror failure
Log backup for a database failing to get copied to the log shipping share Category: Troubleshooting & error messages Date: 18 Feb 2010 Product: SQL Backup During the process of a log shipping job, ...
0 votes
COPYTO failed after Mirror failure
  1. Community
  2. SQL Backup Previous Versions
Well the Mirror failure could be a coincdence. Heres the situation.. I had a Mirror failure which required me to ship the logs, which I used Red Gates log shiping, to my secondary server to restore...
2 followers 2 comments 0 votes
Total activity
5
Last activity
Member since
Following
0 users
Followed by
0 users
Votes
0
Subscriptions
2