Comments
Sort by recent activity
Great, that'll do fine as a work-around.
Thanks,
Nick / comments
Great, that'll do fine as a work-around.
Thanks,
Nick
Thanks for looking into it Petey,
Your query of just the backupset returns the following (ordered by start date):
backup_start_date backup_set_id
2010-11-30 03:20:07.000 1838861
2010-11-30 07:14:19.000 1842905
2010-11-30 08:07:09.000 1843890
2010-11-30 09:02:04.000 1843943
2010-11-30 10:03:51.000 1844058
2010-11-30 11:03:50.000 1844186
2010-11-30 12:04:11.000 1844331
2010-11-30 12:37:56.000 1844368
2010-11-30 12:40:30.000 1844369
2010-11-30 13:06:16.000 1844558
2010-11-30 14:06:06.000 1844816
2010-11-30 15:03:53.000 1844981
2010-11-30 16:03:40.000 1845113
as you can see there is no other log created between 8:07 and 9:02. In fact why should that even matter given that the designated point in time for the restore is 8am? (see the STOPAT directive in the code, which uses the @tijd variable). The filenames that the RESTORE lists at the end would seem to be correct to me: for 8am it would need the 032007, the 071418, and finally the 080708 logs.
To me it seems a multi-threading issue. There seem to be 4 threads involved in restoring the 090203 log. (Which it shouldn't even be restoring at all).
Your query with the join to backupmediafamily quadruples the resultset, with family_sequence_number 1, 2, 3 and 4 for each backupset. Would you like me to post those entire results here?
Regards, Nick / comments
Thanks for looking into it Petey,
Your query of just the backupset returns the following (ordered by start date):
backup_start_date backup_set_id
2010-11-30 03:20:07.000 1838861
2010-11-30 07:14:19...
Ah, that explains it then. Thanks for the info.
Except: I'm now not 100% sure, but I think the WITH RECOVERY options will then fail, leaving the database in recovery mode. And that makes the shorthand notation of RESTORE LOG WITH RECOVERY STOPAT *.LOG.sqb (with a wildcard) unusable whenever there is a LOG later than the STOPAT present.
That is a great pity for us, as we would now be forced to write complex routines that need to determine the exact fileset of logs needed for the STOPAT.
Regards, Nick / comments
Ah, that explains it then. Thanks for the info.
Except: I'm now not 100% sure, but I think the WITH RECOVERY options will then fail, leaving the database in recovery mode. And that makes the shorth...
Thanks for confirming Peter.
And yes, of course I was missing the wildcard possibility for step 2.
Nick / comments
Thanks for confirming Peter.
And yes, of course I was missing the wildcard possibility for step 2.
Nick