Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
methodology
Starting Member
31 Posts |
 Posted - 2007-08-01 : 06:42:49
|
| HiI run a full backup once a month and a transaction log backup every 10 mins through working hours for the remainder of the month until the backup is re-initialised at th start of the following month.I backup to virtual sql disk object devices.As the month progresses the backup takes longer and longer whilst the amount of data being backed up every 10 minutes cycle is always roughly the same. its about 5 seconds for a backup on day 1, up to 5 mins at the end of the month.I noticed that NOSKIP was being used in the command - i changed this to SKIP, but it made no difference in the amount of time the backup takes. Isnt this suppoed to stop some sort of integrity scan on all other backup sets in the archive?full syntax of the backup command that runs now is:BACKUP LOG [objectstore] TO [Backup_objectstore] WITH NOFORMAT , NOINIT , NOUNLOAD , NAME = N'objectstore backup', SKIP , REWIND , STATS = 10but as I say, the SKIP command instead of NOSKIP makes no difference.whats going on here?any help appreciated.ThanksAlastair."A computer once beat me at chess - but it was no match for me at kick boxing" - Emo Phillips. |
|
|
rmiao
Master Smack Fu Yak Hacker
7266 Posts |
Posted - 2007-08-01 : 11:37:59
|
| The option is for tape device. |
 |
|
|
Haywood
Posting Yak Master
221 Posts |
Posted - 2007-08-01 : 15:07:46
|
| I found (on 2005) that the increasing number of appended backups to a backup device will create long backup times. As part of the backup operation, a RESTORE HEADERONLY is performed on the device (to see what exists or not, currently). The number of backups appended to the device increases the time for RESTORE HEADERONLY to read the device.You may want to think about changing your backup strategy to more fulls and less appending of log backups. As it stands, if you have to restore on the 29th, you have to restore from the last full backup on the 1st of the previous month and then restore 29 days worth of t-logs. This can be very time consuming, and when a database is 'down', people are anxious to get it back up quickly. Restoring from yesterdays full, and only replaying one days worth of logs will get the db back up and running much quicker. |
|
|
|
|
|
|
|
|
SKIP & NOSKIP back no differnce to backup duration