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
© William Yuan 2000
Email William