II_DMFRCP_STOP_ON_INCONS_DB variable

Roy Hann wrote:
> 
> I've seen a couple of posts recently advocating setting the
> II_DMFRCP_STOP_ON_INCONS_DB=YES environment variable, apparently to avoid
> having the databases marked inconsistent.  Who can tell me what this
> really does, and what the consequences of setting it are?  I am pretty
> certain that after a server is shut down by setting this flag that life
> does not go on as normal.  What are we expecting from setting this flag?
> Why is it preferable to just letting Ingres mark the database inconsistent?
> 
I was dealing with a site with 6.4/03 on a VMS platform. After a system
crash, the database would always be marked inconsistent (power problems
and a bad UPS). In the errlog.log file you would basically see that it
"ran out of locks". As per tech support, with II_DMFRCP_STOP... defined,
an exclusive "database" lock would be set so locks would not be a
problem and the DMFRCP would not stop prematurely. I believe that this
type of problem existed in 6.4/03 but was corrected in 6.4/04. I do
know, that the next time this site crashed it came up clean!





> [snip].
> ...  How could Ingres have emptied the transaction log if an error occurred
>during recovery???  Shouldn't it have suspended  recovery processing, instead
>of just marking the db inconsistent and saying "good luck now, buddy!"?


Yessir.

What you need to do is to
ingsetenv II_DMFRCP_STOP_ON_INCONS_DB YES
Which does exactly what you claim is the correct action.  The idea is
that if something goes bad during recovery, the recovery server just stops
instead of marking the DB inconsistent and pitching the transaction log.
Now, it's not at all clear that a retry would have worked any better.
But at the very least it gives you time to stop and attempt to think up
some sort of devious strategy to at least know what was going to go wrong.


I am not entirely sure why this setting isn't the default.  I suppose it's
because many DBA's and Ingres admins would not be entirely sure what to do
if the recovery server simply aborted.  (After all, one of the reasons I
rely on Ingres is that my customers don't need high end DBA's and DBadmins.)
Anyway, for critical production databases where there is someone capable
on call, I definitely recommend turning on the stop flag.
By the way, if you have the variable set properly, you'll see a message in
iircp.log at rcp startup.


Karl R. Schendel, Jr.
K/B Computer Associates   schendel@kbcomputer.com
Ingres and Unix Expertise

President, North American Ingres Users Association
president@naiua.org
Ingres Q & A
To William's Home Page

© William Yuan 2000

Email William