Comments
Sort by recent activity
Chris Auckland wrote:
What I would suggest is to take a full backup of the primary database, copy it to the DR server and restore WITH RECOVERY, OR WITH STANDBY. You could then use the log shipping wizard and select the newly restored standby database. This would mean that when you come to use the log shipping wizard the full database has already been copied across and restored, so it is just the jobs that get created through the Log Shipping Wizard.
Hi Chris,
I did not realize that using the "Overwrite existing database" would function as such --- I had incorrectly assumed that it would re-perform the initial backup/restore. The documentation backs up your direction... good to know for next time!
I basically achieved this same result by creating the backup, restoring WITH RECOVERY, and then manually creating a log backup job with copy to dr share, and manually creating the restore job with moveto. It works perfect... just wanted to advise of the issue with using the wizard... particularly the GUI -- the file copy and restore of the database appeared to work; however as the gui was hung, the wizard would not proceed to the next step of creating the jobs.
Thanks! / comments
Chris Auckland wrote:
What I would suggest is to take a full backup of the primary database, copy it to the DR server and restore WITH RECOVERY, OR WITH STANDBY. You could then use the log shipp...
Fair enough! Decision made... Share will be on destination server!
Thank you for the insightful discussion. / comments
Fair enough! Decision made... Share will be on destination server!
Thank you for the insightful discussion.
Thank you for your reply...
I agree with everything you said, and understand how the default setup, using the destination server as the share, functions in respect to reducing network traffic, copying/moving files locally, etc...
However if there was network downtime, or the destination server was unavailable, it wouldn't be as clear which files were pending shipping... the backup would complete into the local folder, but would not be able to copy to a share. So, once connectivity with the destination server was restored, it would need to be determined which logs would need to be delivered, correct?
Keeping the shipping file share on the source server would queue those up, until the destination server was ready to pull them... however, it would result in duplicate network traffic from the restore, then the move. / comments
Thank you for your reply...
I agree with everything you said, and understand how the default setup, using the destination server as the share, functions in respect to reducing network traffic, copy...
Point taken!
Question...
If the network or destination server were unavailable for 1 hour, 3-4 transaction logs backups would not make it into the queue, however the following would.
What would occur on the destination server's restore job? It would be missing 3-4 transaction logs in the sequence.
Thanks again! / comments
Point taken!
Question...
If the network or destination server were unavailable for 1 hour, 3-4 transaction logs backups would not make it into the queue, however the following would.
What would occ...
eddie davis wrote:
Do you want me to submit a request to include the pre and post processing tasks for the backup job appear in the "In Progress" tab?
Yes Please! This has caused much confusion too on our end... / comments
eddie davis wrote:
Do you want me to submit a request to include the pre and post processing tasks for the backup job appear in the "In Progress" tab?
Yes Please! This has caused much confusio...
csm wrote:
I suspect this may be related to have 3 threads... if so is this normal? and is this ok/safe?
I just switched the transaction log backup to use single thread, and only 1 entry appears for that backup. So my suspicious appears to be correct.
Is this normal? Ok? Safe? / comments
csm wrote:
I suspect this may be related to have 3 threads... if so is this normal? and is this ok/safe?
I just switched the transaction log backup to use single thread, and only 1 entry appea...
I just performed that same query to better understand what is occuring behind the scene. SELECT a.backup_start_date, b.physical_device_name, *
FROM msdb..backupset a
INNER JOIN msdb..backupmediafamily b ON a.media_set_id = b.media_set_id
WHERE type = 'L' AND database_name = 'KVZ'
AND a.backup_start_date > '22-May-2007'
ORDER BY a.backup_start_date
Is it normal to see 3 entries for each backup performed by SQL Backup?
For instance, the 10am transaction log backup shows up in 3 rows, with the following differences:
physical_device_name:
d:\SQL Backups\LOG_(local)_KVZ_20070524_100000.sqb
SQLBACKUP_D4283421-E149-4BA4-B0AA-2B61B115864701
SQLBACKUP_D4283421-E149-4BA4-B0AA-2B61B115864702
family_sequence_number:
1
2
3
media_family_id:
FAF0F730-0000-0000-0000-000000000000
FCEE3063-0000-0000-0000-000000000000
DF802B2A-0000-0000-0000-000000000000
logical_device_name:
Red Gate SQL Backup (5.0.0.2770):000000000CBA00000000000002441800000073DF0000000A0102
NULL
NULL
If I look at entries dated before our cutover to SQL Backup, I only see 1 entry per transaciton log backup from the MSSQL backup process.
I suspect this may be related to have 3 threads... if so is this normal? and is this ok/safe? / comments
I just performed that same query to better understand what is occuring behind the scene.SELECT a.backup_start_date, b.physical_device_name, *
FROM msdb..backupset a
INNER JOIN msdb..backupmediafami...