>Database corrupted, how to clear the problem?

This can be one of the most complex support calls that exists! Image has
many layers of consistency checking and keeps current consistency
information in several places. Usually, the originating incident that has
cause the damage has happened sometime in the recent or distant past. System
halts, human error, disc errors, bugs in MPE/IMAGE, and so forth can cause
corruption land mines. These are then later tripped by some other process
and the database is flagged as "logically inconsistent".

If the database is enabled for dumping (not the default) the Image abort
will create diagnostic files that will be very valuable in pointing to the
'root' of the problem.

Critical questions of any software support provider you have or are
considering are:
Can you decode an Image dump?
Can you provide bug catching procedures to identify the program and Image
call parameters that resulted in the abort?
Can you support the database repair/recovery process?

One of the key system admin decision points is the determination of data
loss/repair time to restore/recovery time equation. Some corruption events
are very minor and can be repaired in short order with a small number of
entries lost. Other events may involve a very large number of entries and
restoring to a backup version may be the only option. If you are not using
Image Logging then this equation is certainly shifted somewhat.

Many HP3000 administrators have developed a very false sense of data
security. Each should have two BIG clocks on the wall one indicating the
maximum amount of data loss possible and another showing expected down time
to recover.


Cordially,

Mike Hornsby
CoFounder
Beechglen Development Inc. (beechglen.com)
513-922-0509
[log in to unmask]



----- Original Message -----
From: "Emerson, Tom" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, September 10, 2004 5:16 PM
Subject: [HP3000-L] Database corrupted, how to clear the problem?


> worst thing that can happen on a friday -- "DBG IS DISABLED; ONLY DBCLOSE
ALLOWED"
>
> dbutil reports "database is logically inconsistent"
>
> adager reports "database was in a dynamic transaction, run dbdriver,diag
and follow the instructions"
>
> dbdriver, option 2 (report result in <base>00 file) aborts (!)
>
> and "transaction logging" is NOT enabled for this database.
>
> where should we look next?
>
> [only positive note: this is essentially a "scratchpad" database -- the
data gets fully recalculated every morning -- and is used to show
to-the-minute inventory levels; if push comes to shove, we simply won't have
reliable/usable data for the rest of the day]
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *