home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / ingres / 1933 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  3.3 KB
  1. Path: sparky!uunet!ogicse!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!umn.edu!mmm.serc.3m.com!us275168
  2. From: us275168@mmm.serc.3m.com (Kenneth A. Kiefer)
  3. Newsgroups: comp.databases.ingres
  4. Subject: Re: DEC ULTRIX INGRES checkpoint problem
  5. Message-ID: <1992Nov19.031726.12353@mmm.serc.3m.com>
  6. Date: 19 Nov 92 03:17:26 GMT
  7. Article-I.D.: mmm.1992Nov19.031726.12353
  8. References: <1992Nov13.175814.27160@aplcen.apl.jhu.edu>
  9. Organization: 3M Company
  10. Lines: 63
  11.  
  12.  
  13. mae@aplpy.jhuapl.edu (Mary Anne Espenshade) writes:
  14.  
  15. > ....  I've probably made 30 checkpoints with no
  16. > problem (and have even recovered from the checkpoint a few times).  Last
  17. > week I ran a update and made the checkpoint as usual, neither process
  18. > reported any errors.  When I next attempted to access the database, the
  19. > sql command aborted with the following error message:
  20. >       E_US0010    Database does not exist.
  21. > 
  22. > Going to the error log explained more of
  23. > the problem.  For each attempt to access the database, the following
  24. > series of errors was logged:
  25. > 
  26. >       E_DM923C_CONFIG_FORMAT_ERROR    Error in configuration file format.
  27. >       E_DM923A_CONFIG_OPEN_ERROR    Error occurred opening configuration 
  28. >                    file, (aaaaaaaa.cnf).
  29. >       E_DM9265_ADD_DB    Error occurred while trying to add a database.
  30. > 
  31. > I didn't want to try to recover from the checkpoint.  I didn't know
  32. > whether it would be able to find the database or if the checkpoint
  33. > itself was corrupted.  I finally decided to try replacing the
  34. > aaaaaaaa.cnf file with a copy from the previous day's system backup.
  35. > Since this is a binary file, I had no way to determine what had changed
  36. > between the two.  This seems to have worked, since I could then access
  37. > the database and successfully ran the scripts that read the data.
  38. > 
  39. > Hoping that the error was a one-time fluke, I ran the next tape update
  40. > and made another checkpoint, again with no errors reported.  The exact
  41. > same thing happened.  Once again I recovered from a copy of the
  42. > configuration file I had made just before I took the checkpoint (being
  43. > paranoid about such things), but I am left with no way to checkpoint
  44. > this database.
  45. > 
  46. > Two alternatives have been suggested by the system maintainers - copy
  47. > out all the data, recreate and reload the database and start over
  48. > (assuming that the error had something to do with the number of times
  49. > checkpoint had been run), or stop doing checkpoints and just tar the
  50. > database data files to tape (since the checkpoint is only really
  51. > important if journals are tied to it).
  52. > 
  53. > Has anyone else run into this problem?  Is it safe to practically
  54. > ignore it this way or should I be doing something else.
  55. > --
  56. > Mary Anne Espenshade
  57. > ARPA: mae@aplpy.jhuapl.edu
  58. > UUCP: ...!allegra!mimsy!aplcen!aplpy!mae
  59.  
  60. Here's a hunch.  If you're checkpointing to tape, try including  
  61. the "-d" flag on your ckpdb command to erase the checkpoint 
  62. timestamp history kept in the .cnf file.  Beware, if you're
  63. checkpointing to disk, the -d will also delete your old checkpoints from
  64. disk, so use it judiciously.
  65.  
  66. The .cnf file stores various pointers and other such stuff about the
  67. database, including the dates/times of the most recent 16 checkpoints.  
  68. As I remember, Ingres 6.2 has a bug where if more than 16 consecutive 
  69. checkpoints are done without the "-d" flag, the checkpoint history 
  70. overflows, clobbering other data in the .cnf file.
  71.  
  72. Good luck,
  73. Ken Kiefer
  74. kakiefer@mmm.com
  75.