Comments
Sort by recent activity
Petey,
If this functionality already exists within the tool, please let me know.
Would it be beneficial to add an optional parameter to the RESTORE LOG command within SQL Backup that would instruct the application to "skip" over any files that return error 4326 (SQL error 4326: SQL error 4326: The log in this backup set terminates at LSN xxx, which is too early to apply to the database. A more recent log backup that includes LSN xxx can be restored.)? Perhaps it could work something like a LATEST_* clause for logs by determining which logs can be restored. I've written custom code around SQL Backup to accomplish this in the past, but it seems like it would be a powerful option to include.
Thanks,
-Mike / comments
Petey,
If this functionality already exists within the tool, please let me know.
Would it be beneficial to add an optional parameter to the RESTORE LOG command within SQL Backup that would instruct...
Linda,
Will there be a patch back-ported for 6.x? My company did not purchase the support agreement, so I think we'd have to pay for 7.0.
Thanks,
-Mike / comments
Linda,
Will there be a patch back-ported for 6.x? My company did not purchase the support agreement, so I think we'd have to pay for 7.0.
Thanks,
-Mike
Peter,
I finally got around to testing the combination of LATEST_ALL with STOPAT. This is probably by design, but I noticed that the restore worked exactly as you indicated it would, as long as the STOPAT value was later than the most recent database-level backup. However, if I specify a STOPAT value earlier than the most recent database-level backup, the process will still restore the most recent FULL, followed by the most recent DIFFERENTIAL, and then it will fail when it attempts to apply the LOG backups. This behavior can be illustrated by the following example.
Assume I have the following available backups:
L-8
L-7
D-6
L-5
L-4
D-3
L-2
L-1
F-0
If I attempt to set the STOPAT parameter to a datetime value between L-4 and L-5, the LATEST_ALL parameter seems to still force the restore of F-0 followed by D-6 before processing the STOPAT cutoff time. As I said, this is probably by design. However, it might be beneficial for SQL Backup to be able to apply the STOPAT criteria before it selects which backup sets it is going to use.
Anyway, just thought I would share the results of my testing. Keep up the good work, it is much appreciated.
Regards,
-Mike Eastland / comments
Peter,
I finally got around to testing the combination of LATEST_ALL with STOPAT. This is probably by design, but I noticed that the restore worked exactly as you indicated it would, as long as th...
Peter,
The patch appears to have addressed this particular issue. Thank you for the quick turnaround.
Now, I have yet to upgrade my remaining servers to 6.5. In order to do so, would I need to install the base 6.5 release and then apply the patch as I did with this test server?
Thanks,
-Mike / comments
Peter,
The patch appears to have addressed this particular issue. Thank you for the quick turnaround.
Now, I have yet to upgrade my remaining servers to 6.5. In order to do so, would I need to in...
Peter,
Please ignore my previous upgrade question. I think I've got it covered.
Thanks again for the quick resolution.
-Mike / comments
Peter,
Please ignore my previous upgrade question. I think I've got it covered.
Thanks again for the quick resolution.
-Mike
Peter,
I would not be opposed to trying to recreate the error. However, I want to be sure that something is different, such as a higher debug setting etc, in order to provide you with additional troubleshooting information. It seems that just flipping back to the multiple files for the sake of having the process generate another error doesn't really get us closer to the root cause.
Thanks,
-Mike / comments
Peter,
I would not be opposed to trying to recreate the error. However, I want to be sure that something is different, such as a higher debug setting etc, in order to provide you with additional t...
Peter,
The process has executed successfully the past four consecutive days since the switch was made back to using a single backup file. I'll watch it for the rest of the week, but it appears this change has resolved my particular issue.
That being said, have there been any other reports of customers having issues with striping backupsets across multiple files? At my previous employer, I did this frequently with the larger databases I managed using native SQL Server backups and it seemed to work fine.
Thanks again for your time.
-Mike Eastland / comments
Peter,
The process has executed successfully the past four consecutive days since the switch was made back to using a single backup file. I'll watch it for the rest of the week, but it appears thi...
Peter,
The process has not failed since the switch was made back to writing the full backupset to a single file. This is not a problem for me currently, but I think other customers with larger databases could see significant performance gains in their backup jobs by striping large database backups across multiple files.
I'm not sure how you want to leave this. I'm fine with considering the issue closed from my end, but I would also be happy to provide any additional information that might help troubleshoot the underlying issue.
Thanks,
-Mike / comments
Peter,
The process has not failed since the switch was made back to writing the full backupset to a single file. This is not a problem for me currently, but I think other customers with larger dat...
Peter,
I made one change to the backup process for this particular database last night. Instead of striping the backup across multiple files, I went back to writing it to a single file. Subsequently, the restore process completed successfully this morning. Is it possible that trying to restore from multiple backup files is causing this problem?
Thanks,
-Mike / comments
Peter,
I made one change to the backup process for this particular database last night. Instead of striping the backup across multiple files, I went back to writing it to a single file. Subsequen...