SQL Log Rescue Annoyances
mglenn
Posts: 25
I recently started working with Log Rescue so some of this could be "user error", but:
1. During install you can choose to install extended stored procs on the default instance or not, but you can't specify a named instance during install (have to do that later).
2. Poor support for analyzing isolated log files. It might help to have more separation between analysis and recovery modes so users can analyze without having to meet the criteria necessary for successful recovery (such as access to the full backup, no missing logs, etc.).
3. Saving a project doesn't buy you much during the most labor intensive step--Choose Database Backups--because it ignores your saved choices and forces you to select files all over again when opening an existing project. (Not such a big deal unless you do frequent transaction log backups.)
Let me know if any of this is user error!
1. During install you can choose to install extended stored procs on the default instance or not, but you can't specify a named instance during install (have to do that later).
2. Poor support for analyzing isolated log files. It might help to have more separation between analysis and recovery modes so users can analyze without having to meet the criteria necessary for successful recovery (such as access to the full backup, no missing logs, etc.).
3. Saving a project doesn't buy you much during the most labor intensive step--Choose Database Backups--because it ignores your saved choices and forces you to select files all over again when opening an existing project. (Not such a big deal unless you do frequent transaction log backups.)
Let me know if any of this is user error!
This discussion has been closed.
Comments
Log Rescue may ask you to install the extended stored procedure, but it also very cleverly installs the XP automatically on the server when you choose to analyze a database on that server.
It's not designed specifically as an analysis/auditing tool, so it does have a shortcoming in that it can't simply dump a list of transactions from the log file. In order to fulfill the role of 'undo for SQL Server', it needs to know about the state of the schema and other things before it can proceed to geterate undo/redo scripts for the changes in the data that happen inside the log. This also results in some lengthy processing times before you can begin to work with the transactions in the log file.
Probably the project management could use some enhancement. I haven't got any suggestions for you in that area.
1. True. Maybe something as simple as a parenthetical statement added to the dialog box "(The extended stored procedure can easily be created for named instances after intallation is complete.)" would help. This would save new customers from needlessly looking around for ways to specify a named instance during install, searching through the help file and possibly even contacting support only to discover a short time later that it's not a problem.
2. I understand. Expanding analysis functionality would obviously increase the price as well and no one would be happy about that.
3. Just retaining file selections in saved projects would be great.
Thanks for the quick response and taking time to discuss my feedback.