Log Rescue Throwing Exceptions
mglenn
Posts: 25
Log Rescue 1.1.0.229
SQL Server 2000 SP4
Windows Server 2000 SP4
Server: 2 GB RAM; Dual Intel Xeon 2.0GHz
Database: 38 GB, Full recovery model; named instance
MDAC 2.8
.Net Framework 1.1
I created a recovery project and added 5 transaction logs (backed up hourly) plus the most recent full backup. There were no file warnings or errors. The analysis phase ran for approx. 18 minutes. Just as it approached 100% complete, Log Rescue threw the following Error:
RedGate.LogRescue.UI.exe – Common Language Runtime Debugging Services
Application has generated an exception that could not be handled.
Process id=0xfac (4012), Thread id =0xd58 (3416)
Click OK to terminate...
Click Cancel to debug...
Notes: Log Rescue was run directly on the database server. Interactive user and batch processes were active at the time. Thinking this could be a factor I tried this again after users had gone home, but one batch still running. The result was another exception. Then I ran Log Rescue against the current transaction log on a test database (copy of the same database, but in Simple Recovery mode) and analysis completed successfully.
Is the lesson here to never use Log Rescue to analyze an active transaction log? Attempting recovery in an active database seems like a bad idea in any case, but do we also have to get everyone out and go into restricted access mode to view the transaction log?
Or maybe there's an entirely different reason for these exceptions...
SQL Server 2000 SP4
Windows Server 2000 SP4
Server: 2 GB RAM; Dual Intel Xeon 2.0GHz
Database: 38 GB, Full recovery model; named instance
MDAC 2.8
.Net Framework 1.1
I created a recovery project and added 5 transaction logs (backed up hourly) plus the most recent full backup. There were no file warnings or errors. The analysis phase ran for approx. 18 minutes. Just as it approached 100% complete, Log Rescue threw the following Error:
RedGate.LogRescue.UI.exe – Common Language Runtime Debugging Services
Application has generated an exception that could not be handled.
Process id=0xfac (4012), Thread id =0xd58 (3416)
Click OK to terminate...
Click Cancel to debug...
Notes: Log Rescue was run directly on the database server. Interactive user and batch processes were active at the time. Thinking this could be a factor I tried this again after users had gone home, but one batch still running. The result was another exception. Then I ran Log Rescue against the current transaction log on a test database (copy of the same database, but in Simple Recovery mode) and analysis completed successfully.
Is the lesson here to never use Log Rescue to analyze an active transaction log? Attempting recovery in an active database seems like a bad idea in any case, but do we also have to get everyone out and go into restricted access mode to view the transaction log?
Or maybe there's an entirely different reason for these exceptions...
Comments
There shouldn't really be a problem with analyzing a live database, in fact the live log is processed by Log Rescue, although it also processes log file backups in the same way.
If you are concerned about availability on a heavily-used database, though, I would think about grabbing the backups and restoring them to a testing server and analyzing the database on that server instead.
I haven't got any suggestions. Someone else is looking into possible causes for the error.