From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: Transaction system reliability
Organization: 
Date: Wed, 7 Oct 1992 22:40:58 GMT

In article <9210061409.AA11415@valandil.YP.sun386i>, melkor!valandil!mal 
(Michael A Leo) writes:
> ...[warning about halting machine right after running iishutdown
> --better to wait until all INGRES processes are gone]...
> 
>   However, if something needs to be recovered, the dmfrcp
> process may still be running.

Right, if some user was executing a huge update and you stopped the
server out from under him/her ("stop server" in iimonitor), then the
recover process (RCP) has to take over and undo the job by working its
way backwards through the transaction log file and reapplying the before
image pages to the database.  This can easily take as long or longer
than it took to run the original update as far as it got.  The RCP may
carry on for many minutes, and we've seen it go on for close to a half
an hour.  It all depends on how big your transaction log is, how fast
your system is, and how many uncommitted active transactions are in the
transaction log.

>   It is very dangerous to shut down the operating while 
> the dmfrcp is still running.

It's not desireable, but I don't know that I would describe it as _very_
dangerous.  I don't think we've ever suffered an inconsistent or
corrupted database as a result of this kind of shutdown (at least in
recent versions of INGRES--before 6.3 was very buggy).  INGRES is
designed to handle machine crashes and unexpected interruptions--that's
why you pay so much for it, and that's why there _is_ a transaction log
and a recovery process.  Even after a hard machine crash, when you bring
INGRES back up, the RCP kicks in and reads through the transaction log
file and puts everything back in place.  

>   I am not sure what scenario causes the dmfrcp to take 
> over the recovery process, and I can only simulate it by
> killing the DBMS server via kill -KILL or stop/id, when the
> DBMS server is recovering an aborted transaction.

Under normal circumstances, the server takes care of its own rollbacks. 
It's only under extraordinary circumstances that the RCP steps in.  I've
seen this, as you did, when a server gets stopped abruptly, either by
the OS with "kill -KILL" or "stop/id"; or by "stop server" in iimonitor;
or when it crashes due to an internal error; or when it exceeds its
internal maximum error count and kills itself.

In over 3 years of INGRES v6 experience, I've seen the server die or
killed it myself scores of times, and I've seen this cause a problem on
only one occasion.  In this case, the server passed off recovery of a
transaction to the RCP for very mysterious reasons.  This one turned out
to be a lulu, of course, and the problem was compounded when we found
that the DMFJSP couldn't roll forward our checkpoints due to btree
problems.  However, the original cause of the whole thing was an
internal error in the server, and not a failure to recover from a rude
shutdown.

You're right to be more cautious about the RCP, and to let it finish on
its own before halting the machine, but I think the general experience
will bear out a certain robustness in the INGRES logging and recovery
(LAR) system.

I would certainly be interested to know if other readers agree with my
assessment.

--Mark Jaeger				internet: cs_mj@gsbvax.uchicago.edu
Graduate School of Business		yellnet:  (312) 702-0328
University of Chicago			faxnet:   (312) 702-0233
Disclaimer: My opinions are my own and not those of my employer.
Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.

Newsgroups: comp.databases.ingres