Log Rescue Throwing Exceptions

Undo for SQL Server.

Moderator: eddie davis

Log Rescue Throwing Exceptions

Postby mglenn » Sat Sep 16, 2006 12:13 am

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...
mglenn
 
Posts: 16
Joined: Wed Sep 13, 2006 2:36 pm

Postby Brian Donahue » Sat Sep 16, 2006 12:23 pm

Hi Mike,

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.
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Postby mglenn » Sun Sep 17, 2006 1:59 am

Okay, so what can we do about the errors?
mglenn
 
Posts: 16
Joined: Wed Sep 13, 2006 2:36 pm

Postby Brian Donahue » Tue Sep 19, 2006 12:26 pm

Hi Mike,

I haven't got any suggestions. Someone else is looking into possible causes for the error.
Brian Donahue
 
Posts: 6670
Joined: Mon Aug 23, 2004 10:48 am

Postby mglenn » Tue Sep 19, 2006 12:59 pm

Thanks. It is good to know I should normally have no problem analyzing an active database (other than contention).
mglenn
 
Posts: 16
Joined: Wed Sep 13, 2006 2:36 pm


Return to SQL Log Rescue

Who is online

Users browsing this forum: No registered users and 0 guests