1。"LOG能被HOLD多久",只要你的LOG 对应的 .ldf file足够大, 你的LOG想HOLD多久都可以。不过HOLD的时间越长,BACKUP 的时间也越长, COPY 和 RESTORE 的时间也越长
2。 做LOG SHIPPING 的时候一定要注意保持TRANSACTION LOG BACKUP 的 SEQUENCE. 什么意思呢? 就是说但LOG SHIPPING PROCESS 已经在做 LOG 的BACKUP的时候,你的平常的ROUTINE BACKUP就不要额外去做LOG BACKUP 了,否则会出现错误 : TRANSACTION LOG IS OUT OF SEQUENCE. 当然你如果一定要做,那一定要把你的维护计划所做的 LOG BACKUP 和 LOG SHIPPING 所作的放在一起,然后按次序SHIP 到SECONDARY SRV 上去RESTORE. LOG RESTORE 的时候次序一点不能错。
3。不过你平时做的DB 的BACKUP 不会影响 LOG SHIPPING 的进行
在LOG SHIPPING 已经允许的情况下,通常把LOG BACKUP(APPEND)到一个DEVICE上,这样如果出现问题, PRIMARY SERVER 需要那个LOG 来恢复,你只要找到那个DEVICE然后找到相信的LOG就可以了,否则BY DEFAULT, LOG SHIPPING 只保留当前的BACKUP,如果你要恢复到以前,就问题大了。
平时的BACKUP虽然只作DB部分,你也可以设置DIFFERENCIAL BACKUP 来弥补
2。 做LOG SHIPPING 的时候一定要注意保持TRANSACTION LOG BACKUP 的 SEQUENCE. 什么意思呢? 就是说但LOG SHIPPING PROCESS 已经在做 LOG 的BACKUP的时候,你的平常的ROUTINE BACKUP就不要额外去做LOG BACKUP 了,否则会出现错误 : TRANSACTION LOG IS OUT OF SEQUENCE. 当然你如果一定要做,那一定要把你的维护计划所做的 LOG BACKUP 和 LOG SHIPPING 所作的放在一起,然后按次序SHIP 到SECONDARY SRV 上去RESTORE. LOG RESTORE 的时候次序一点不能错。
3。不过你平时做的DB 的BACKUP 不会影响 LOG SHIPPING 的进行
在LOG SHIPPING 已经允许的情况下,通常把LOG BACKUP(APPEND)到一个DEVICE上,这样如果出现问题, PRIMARY SERVER 需要那个LOG 来恢复,你只要找到那个DEVICE然后找到相信的LOG就可以了,否则BY DEFAULT, LOG SHIPPING 只保留当前的BACKUP,如果你要恢复到以前,就问题大了。
平时的BACKUP虽然只作DB部分,你也可以设置DIFFERENCIAL BACKUP 来弥补