From: mae@aplpy.jhuapl.edu (Mary Anne Espenshade)
Subject: DEC ULTRIX INGRES checkpoint problem
Organization: Johns Hopkins University Applied Physics Lab
Date: Fri, 13 Nov 92 17:58:14 GMT

I need some help with an INGRES (specifically the DEC ULTRIX SQL port)
error that appears to be corrupting a database configuration file.
Long and detailed explanation follows.

I'm in a bit of a bind.  I told the people in charge of this computer
system that not getting support would get them burned one day.  Being
able to say "I told you so" is not much comfort when I have to fix the
mess.

The system in question is a DEC 5000, running ULTRIX T4.1A-0 (Rev. 54)
which came with ULTRIX SQL, aka INGRES 6.2/03u (ds3.ulx/01).  This is
just the backend and the SQL terminal monitor, no tools, no embedded
language pre-processors, no QUEL :-( and, of course, no INGRES support.
To add insult to injury, they don't have DEC support on this machine
either (which is what I really need, since DEC did the INGRES port and
so could have introduced errors that don't exist in the version directly
available from Ingres).  They do carry some kind of third party hardware
maintenance on the facility (which includes many kinds of machines from
many vendors running every conceivable flavor of UNIX), but that doesn't
help when the software messes up.

The database in question is updated from tapes of data from an outside
source, received every 4 weeks.  Since the ultimate use of the data
only needs it quarterly, I let two or three tapes accumulate before I
process them.  For each tape, I install the update using SQL scripts and
then make a checkpoint to tape.  The database is read-only otherwise, so
journalling is not turned on.  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.

I checked accessdb (the one forms tool that comes with this version) and
everything appeared normal.  I looked in the actual tables in iidbdb and
the record for the database was there.  I looked in the data directory
and the files were all there.  The only one that had been touched by the
checkpoint was aaaaaaaa.cnf.  Going to the error log explained more of
the problem.  For each attempt to access the database, the following
series of errors was logged:

      ::[1083            , 10399920]: Thu Nov 12 15:22:13 1992 E_DM923C_CONFIG_FORMAT_ERROR	Error in configuration file format.
      ::[1083            , 10399920]: Thu Nov 12 15:22:14 1992 E_DM923A_CONFIG_OPEN_ERROR	Error occurred opening configuration file, (aaaaaaaa.cnf).
      ::[1083            , 10399920]: Thu Nov 12 15:22:14 1992 E_DM9265_ADD_DB	Error occurred while trying to add a database.
      ::[1083            , 10399920]: Thu Nov 12 15:22:14 1992 E_SC010C_DB_ADD	Error adding database.  Name: dafif                    Owner: mae                      Access Mode   0x00000002 Flags   0x00000000
      ::[1083            , 10399920]: Thu Nov 12 15:22:14 1992 E_SC010D_DB_LOCATION	Database Location Name: $default                 Physical Specification: /usr/local/db/ingres/data/default/dafif Flags:   0x00000003
      ::[1083            , 10399920]: Thu Nov 12 15:22:14 1992 E_DM0053_NONEXISTENT_DB	Nonexistent database.
      ::[1083            , 10399920]: Thu Nov 12 15:22:14 1992 E_SC0121_DB_OPEN	Error opening database.  Name: dafif                    Owner: mae                      Access Mode:   0x00000002 Flags   0x00000000
      ::[1083            , 10399920]: Thu Nov 12 15:22:14 1992 E_SC010D_DB_LOCATION	Database Location Name: $default                 Physical Specification: /usr/local/db/ingres/data/default/dafif Flags:   0x00000003
      ::[1083            , 10399920]: Thu Nov 12 15:22:14 1992 E_US0010	Database does not exist.
      ::[1083            , 10399920]: Thu Nov 12 15:22:14 1992 E_SC0123_SESSION_INITIATE	Error initiating session.

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
Newsgroups: comp.databases.ingres