From: us275168@mmm.serc.3m.com (Kenneth A. Kiefer)
Newsgroups: comp.databases.ingres
Subject: Re: DEC ULTRIX INGRES checkpoint problem
Date: 19 Nov 92 03:17:26 GMT
Article-I.D.: mmm.1992Nov19.031726.12353
Organization: 3M Company


mae@aplpy.jhuapl.edu (Mary Anne Espenshade) writes:

> ....  I've probably made 30 checkpoints with no
> problem (and have even recovered from the checkpoint a few times).  Last
> week I ran a update and made the checkpoint as usual, neither process
> reported any errors.  When I next attempted to access the database, the
> sql command aborted with the following error message:
>       E_US0010	Database does not exist.
> 
> Going to the error log explained more of
> the problem.  For each attempt to access the database, the following
> series of errors was logged:
> 
>       E_DM923C_CONFIG_FORMAT_ERROR	Error in configuration file format.
>       E_DM923A_CONFIG_OPEN_ERROR	Error occurred opening configuration 
>					file, (aaaaaaaa.cnf).
>       E_DM9265_ADD_DB	Error occurred while trying to add a database.
> 
> I didn't want to try to recover from the checkpoint.  I didn't know
> whether it would be able to find the database or if the checkpoint
> itself was corrupted.  I finally decided to try replacing the
> aaaaaaaa.cnf file with a copy from the previous day's system backup.
> Since this is a binary file, I had no way to determine what had changed
> between the two.  This seems to have worked, since I could then access
> the database and successfully ran the scripts that read the data.
> 
> Hoping that the error was a one-time fluke, I ran the next tape update
> and made another checkpoint, again with no errors reported.  The exact
> same thing happened.  Once again I recovered from a copy of the
> configuration file I had made just before I took the checkpoint (being
> paranoid about such things), but I am left with no way to checkpoint
> this database.
> 
> Two alternatives have been suggested by the system maintainers - copy
> out all the data, recreate and reload the database and start over
> (assuming that the error had something to do with the number of times
> checkpoint had been run), or stop doing checkpoints and just tar the
> database data files to tape (since the checkpoint is only really
> important if journals are tied to it).
> 
> Has anyone else run into this problem?  Is it safe to practically
> ignore it this way or should I be doing something else.
> --
> Mary Anne Espenshade
> ARPA: mae@aplpy.jhuapl.edu
> UUCP: ...!allegra!mimsy!aplcen!aplpy!mae

Here's a hunch.  If you're checkpointing to tape, try including  
the "-d" flag on your ckpdb command to erase the checkpoint 
timestamp history kept in the .cnf file.  Beware, if you're
checkpointing to disk, the -d will also delete your old checkpoints from
disk, so use it judiciously.

The .cnf file stores various pointers and other such stuff about the
database, including the dates/times of the most recent 16 checkpoints.  
As I remember, Ingres 6.2 has a bug where if more than 16 consecutive 
checkpoints are done without the "-d" flag, the checkpoint history 
overflows, clobbering other data in the .cnf file.

Good luck,
Ken Kiefer
kakiefer@mmm.com
Newsgroups: comp.databases.ingres