Carl Wuebkers 'recovery' problem.

Folks, After perusing the responses to Carl's problem I realized that no-one has come up with this answer, so here it is. We had this problem over and over again and started re-creating it on purpose to devise a solution. The solution wound up being to lower the high water marks by 10%: LTXHWM 70 # Long TX high-water mark (percent) LTXEHWM 80 # Long TX exclusive high-water mark (percent) I also bumped the log files to incredible sizes, (24 500k logs, we log to disk, - since this is a development machine I have some free rein on disk - tee hee. Bumping the log files didn't solve it on it's own since no matter how big your logs are, sooner or later someone is going to do a 'LOAD FROM xxx INSERT INTO...' which will throw you into this situation, but the high water marks made a big difference. I also started educating the users NOT to use 'LOAD FROM...' but rather dbload instead. There are a couple of other statements which will really cramp your style - like updates on a big table which don't lock the table first. Generally get your users - and yourself - to use common sense and avoid Loing Transaction situations. You could even turn off logging for BAD transactions. When you do wind up getting locked up in the logfiles - DON'T to that kill thing. Be very careful to check latches and whether the transaction has gone 'critical' before shooting it. On-Line has eventually killed long transactions for me when I couldn't shoot them myself - but every time someone has shot a 'critical' transaction we've been in (In Big George's Words) deep doo-doo. Yeah, I know that most of you already know this but what the hey. j. _____________________________________________________________________________ Jack Parker - Contractor | Hewlett Packard, BSMC Boise, Idaho, USA| I forget how much I remember jparker@hpbs2651.boi.hp.com | (208) 323-5388 (W) (208) 384-1623 (H) | _____________________________________________________________________________