Comments
Sort by recent activity
Congratulations - that fixed it. Tested both LATEST_FULL and LATEST_ALL successfully on multiple servers, multiple databases, mixed number of FULL, DIFF and LOG backup files. All OK.
Thanks for your help and THANK YOU for a great set of products in the SQL Toolkit. Backup is great, while Compare and DataCompare are absolutely essential to me now. [image] / comments
Congratulations - that fixed it. Tested both LATEST_FULL and LATEST_ALL successfully on multiple servers, multiple databases, mixed number of FULL, DIFF and LOG backup files. All OK.
Thanks for y...
The Lucky 13 syndrome - alas, not the cause. When I first hit this problem I was using a different test database and there were just 4 skipped log backups out of 5 or 6 total. :?
Not so easy after all! [image] / comments
The Lucky 13 syndrome - alas, not the cause. When I first hit this problem I was using a different test database and there were just 4 skipped log backups out of 5 or 6 total. :?
Not so easy afte...
The backups were created using 6.4.0.56 (unpatched). Multiple backup threads, 256 bit encryption, compression level 4.
The restore attempt was done on the dev/test server using the patched 6.4.0.1001 files. When I initially tried this with the unpatched .56 release, the restore attempt would never start at all as per the >10 files bug. / comments
The backups were created using 6.4.0.56 (unpatched). Multiple backup threads, 256 bit encryption, compression level 4.
The restore attempt was done on the dev/test server using the patched 6.4.0.1...
How many log backup files are in your test set? I did not see any log restore attempts when I only had 3 log backups after the differential, but I did see the wrong-log-backup restore attempt when I had quite a few more. / comments
How many log backup files are in your test set? I did not see any log restore attempts when I only had 3 log backups after the differential, but I did see the wrong-log-backup restore attempt when...
I have run a profiler trace against 3 different restore processes. One in which Latest_All succeeds, one in which it fails on a "to new" log backup restore and then one using restore log against the full log set that the previous "latest_all" should have used.
In the Latest_all attempt that fails, the last action attempted by the SQBCoreService process is the first log restore (from a set of 3 virtual devices) after the database restores for, presummably, the preceeding full and differential backups, also from sets of virtual devices. / comments
I have run a profiler trace against 3 different restore processes. One in which Latest_All succeeds, one in which it fails on a "to new" log backup restore and then one using restore log against t...
I made a further discovery by chance when I tried the RESTORE_LATEST on a different database from my primary test candidate. This one had far more frequent log backups, so I had about 8 log backup files after the differential. The RESTORE_LATEST correctly identified the FULL and DIFF backups and restored those, but then it tried to start restoring the LOG from the 5th one in the sequence and failed due to mismatched LSN. So, it may be that it is not the restore component that is failing when "it doesn't restore the LOG backups" but rather the backup file search component. If I can get a chance, I will redo this test with a trace in the next couple of days. / comments
I made a further discovery by chance when I tried the RESTORE_LATEST on a different database from my primary test candidate. This one had far more frequent log backups, so I had about 8 log backup...