Dead in the water: SQL Log Rescue Freeze

[binggeli]

For the second day in a row, I have single-handedly brought the database server down, using SQL Log Rescue.

I am pretty sure that I must have done something wrong, but I cannot figure out for the life of me what's going on.

Yes, I am new to SQL Log Rescue, but I have used other, similar tools in the past and never had any issues with crashing database servers.

DAY 1:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tried to run SQL Log Rescue remotely (from my office computer to the database server in the remote data center). Since I didn't want the extended SP on my local instance of SQL Server (never use any databases on my machine), I let SQL Log Rescue install the extended SP on the remote server.

Then SQL Log Rescue came up with a screen full of potential backups, but they all had the "red x" icon and said they were unavailable. Unchecked the "Use the following backups" (or similar) check box and clicked Next.

Then I got the "Analyzing Transaction Log" (or something like that) window with a progress bar, and SQL Log Rescue just sat there. And sat there. And nothing happened for minutes. No progress in the progress bar either.

So I shut down SQL Log Rescue (clicked Cancel) and within seconds, our production database went down.

I had to call the data center and somebody had to walk over to our server and cold-reboot it because it was frozen and didn't accept any commands from anyone anymore.


DAY 2:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Because red-gate has this awesome advertising slogan, "Recover SQL Server data without any downtime" I thought I'd give it another try.

This time, however, I installed SQL Log Rescue directly on the database server, let it do its thing with the extended SP (which I thought was odd since that got installed yesterday already . . . ?) and wanted to find out when some specific data were entered into a client account.

Same thing all over again. Got as far as the window with the progress bar but nothing happened whatsoever. No "busy" cursor, no little thingies moving along in the progress bar, nothing at all.

So I thought I'd make use of the Cancel button, saw a message that stated something about SQL Log Rescue wanting to cancel the operation and waited. And waited. And waited.

Within a few minutes, our production database went down again.

Unfortunately, I couldn't get a hold of anyone at the data center at that time (they were all out working on different servers for other clients at just that time), and I ended up with a 40-minute downtime.



So, has anyone else had any similar experiences?
If so, how can I fix this?

We're running SQL Server 2000 on a Windows 2000 Server with 3GB of RAM.


Can anyone help me to get SQL Log Rescue running, or should I ask for my money back? Just wondering.



Thanks,

Dee

[Brian Donahue]

Can you please write to support@red-gate.com for a beta version of Log Rescue? The problem here is most likely that the process is spawning more threads than your OS can safely handle. We have introduced some throttling to prevent this but the fix is only available internally at this time.
_________________
Brian Donahue
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521

[binggeli]

Greatly appreciate your reply.

Did what you suggested. We'll have to see how that turns out.



Thank you,
Dee

[dejansen]

I have purchased SQL Backup and since SQL Log Rescue came with it, I'd like to give SQL Log Rescue a spin to see how it compares to Lumigent's Log Explorer. It would be great to have some assurance that it will not bring down my SQL servers. Thank you.

[Brian Donahue]

SQL Log Rescue performs minimal actions on the server. It installs an extended stored procedure on the server and that reads the log file to return the relevant bits of data. The rest of the work is done on the client.

The only way that I can see Log Rescue killing a server (if the client is another computer; a workstation on the same network) is if the SQL Server is low on memory or badly unstable. For instance a SQL Server with lots of extended stored procedure code and low memory could be the culprit.
_________________
Brian Donahue
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521