LogRescue killed my database box
SPROBINSON
Posts: 17
So I was trying out your tool and now our main 24x7 customer-facing production server is totally unavailable, out of memory and off the net. Cool!
Similar to problems reported on this forum, I have just seen:
- LR mysteriously wants to install the ExtendedProcedure when it's already been installed
- During Analysis (70Gb .mdf and 10Gb of .trn log files - all local to LR) LR hangs with System.Out of Memory Exception
Shortly thereafter, my whole database server (and both DB instances, one of which I did not touch with LR) hangs. It runs Enterprise 2000 SP3 with 4Gb RAM.
The last Event messages that made it to external monitoring talk about unpaged memory pool being empty and the network interface dying. Now the server is not responding at all, I'm off to the hosting centre to give it a kick up the backside.
Using LogRecovery 1.0.10.0.
Having read this forum, I will try the 1.1 beta, but I'm distinctly nervous. It's obviously very embarassing to very publicly crash a production server while testing a new tool. Doesn't really encourage my company to want to buy the products! I would suggest you distribute the beta as well as the 1.0 version and give a strong disclaimer to use the beta on large history sets / recovery sets.
In general I'm still believing in your products and I like the honest atmosphere of this support forum.
Regards,
Spike
Similar to problems reported on this forum, I have just seen:
- LR mysteriously wants to install the ExtendedProcedure when it's already been installed
- During Analysis (70Gb .mdf and 10Gb of .trn log files - all local to LR) LR hangs with System.Out of Memory Exception
Shortly thereafter, my whole database server (and both DB instances, one of which I did not touch with LR) hangs. It runs Enterprise 2000 SP3 with 4Gb RAM.
The last Event messages that made it to external monitoring talk about unpaged memory pool being empty and the network interface dying. Now the server is not responding at all, I'm off to the hosting centre to give it a kick up the backside.
Using LogRecovery 1.0.10.0.
Having read this forum, I will try the 1.1 beta, but I'm distinctly nervous. It's obviously very embarassing to very publicly crash a production server while testing a new tool. Doesn't really encourage my company to want to buy the products! I would suggest you distribute the beta as well as the 1.0 version and give a strong disclaimer to use the beta on large history sets / recovery sets.
In general I'm still believing in your products and I like the honest atmosphere of this support forum.
Regards,
Spike
Comments
I apologise for the inconvenience this has caused you. We're working to improve the stability of the current version - very occasionally it can cause problems.
Have you had a chance to try out the beta? I'm hoping it has fixed the issues you were having, but it would be good to have confirmation.
- Neil
Red Gate Software Ltd
To be honest I've been too nervous to run the beta - also too busy recovering the lost database by other means. NB Log Rescue did not kill the database, it just locked up the server when I tried to use Log Rescue to analyse the damaged database.
It's worth saying that the BAK file I was looking at with Log Rescue 1.0 when it locked up my SQL server was probably a corrupt file. Still, presumably Log Rescue will often be looking at damaged files so it's reasonable to assume that it's programmed very defensively as far as I/O etc goes.
I'm staying on your mailing list and will be happy to use future versions of Log Rescue but will probably make sure they are pointing to non-production, recovery SQL Servers before I start loading files into them. Actually it wouldn't hurt for you to have a warning like that within the LR program pop up in a modal dialog box with BIG LETTERS.
E.g. "we strongly recommend you use a non-production SQL Server until you have fully recovered the files; only then when proved safe should you repeat the exercise on a production SQL Server, if necessary". That's what I'll be doing next time. If I remember!
Thanks
Spike