Last weekend, Most of eastern Australia switched to summer time or daylight saving time.
Fun and games. The logshipping is normally done every 2 minutes, unfortunately those jobs which run on the hour (2am became 3am) broke.
SQLserver job agent reruns all jobs between 2am and 3am. So BACKUP LOG was run up to 30 times at 3am. Unfortunately the filename was not sufficiently unique, even a timestamp wasn't enough eg. dbname_200510300300.log
So bang the RESTORE LOG on the failover box breaks as it is now missing those overwriten logs.
Once the alarms are handled. This just required a restore from backup, leaving in STANDBY mode and rolling the failover database forward until it is up-to-date.
Moral of the story, we will investigate more unique filenames and/or having a 61 minute blackout period in the schedule of the log shipping. This doesn't mean the logshipping won't run for one hour, it will just mean it won't be run every 60/x time per hour to make up for the missing hour.
Have Fun
SQL
Daylight saving
Logshipping
Subscribe to:
Post Comments (Atom)
3 comments:
I too have had fun and games with Log Shipping and Daylight Savings time. I discovered an "easy" way to get back into synch. The answer is DIFFERENTIAL backup-Restore to standby and next log cycle works like a charm.
For recovery - in this case where the logs are missing or destroyed - suspend the jobs(backup, copy and recovery) take a differential and apply it to the secondary databases and restart the jobs.
For recovery in this case where the log files were destroyed or if log shipping is out of synch:
pause the LS jobs
Take a differential
apply the differential to the secondary with no recovery
Start the LS jobs (may have to "hide" old logs from before the differential)
Post a Comment