>Message-ID: <[log in to unmask]>
>Date: Wed, 13 Mar 1996 18:17:37 -0500
>Reply-To: [log in to unmask]
>Sender: HP-3000 Systems Discussion <[log in to unmask]>
>From: Denys Beauchemin <[log in to unmask]>
>
>The mists of time are parting a little.  I believe that DBRECOV uses the
>address
 
Yes, the record number of the detail set is logged for DBUPDATE.  No path
information appears in the log record.  A full record list appears for DBPUT
and DBDELETE but the record number is still logged for each.
 
> for detail entry work, and uses the key value (hashing and all that)
>for masters.
 
Yes.  No record number for masters - the primary key is used.
 
> This is why a logging cycle would be unaffected by a cap change
>(expand only for details) but would be totally tumbled after a (detpack,
>reorg) of a detail dataset.
 
Yes, right again.  Changing order is a big no no.
 
> The key value is unique for master entries,
 
Since masters are hashed, physical order is not important - only the key
value.
 
> and
>the record number is unique for detail entries.
>
Right again.  Image keeps a backward chain pointer of deleted entries.  The
last deleted record entry in a detail set is the first DBPUT entry.  If
you somehow mess with this order, like a detpack (or the noaborts option of
DBRECOV), events after this point can't move forward unless you duplicate the
detpack exactly at the same point during a recovery (or create a deleted
record table).  I think we just went beyond reason to theory.
 
>The log record layout in appendix E of the IMAGE manual shows the dataset
>type being recorded as well as the record number.  In addition, for masters
>only, the offset to the key value is recorded as well.  It also seems that
>the key value is recorded also.
>
Right again.
 
>It is interesting to note that, if I am correct, DBRECOV has been using for
>years, the key value for master dataset access and the record number for
>detail dataset access.  If this is the case,
 
Yes it is.  I wrote a logfile list utility long ago and still use it today.
I'm _very_ familar with Image log records - been doing it since 1982.  In
fact, take a look at the "noaborts" option of DBRECOV.  DBRECOV actually must
maintain a _table_ of deleted detail records and perform a translation around
_suppressed_ aborted transactions.  These things get pretty goofy.
 
> why, oh why, can't we get HP to
>see that it is the same thing which is needed to enable MS Access attachments
 
Maybe no one knows Image logging and how DBRECOV works?  Take a poll and see
how many sites do logging.  I think I counted them on one hand last time I
polled.  I have a utility that mirrors our 17 Image log files to an unused
tape drive (multiplexes them as single blocks of data to tape) in real time.
We can recover up-to-the-minute online transtions from tape if our disks go
belly up (which has happened even with RAID).  It is a simple system and is
darn cheap for the protection we get from it!  The down side is you must do a
roll-forward recovery after your reload.  But hey, you are restoring your
system anyway - it only takes a few extra minutes to recover your lost
transactions from tape.
 
Anyone interested in this logfile tape mirror program,  I can send article.
 
Otherwise, Denys.  You are right on.
 
 
----------------------------------------------------------------
Eric J. Schubert                    Senior Data Base Analyst
Office of Information Technologies  Univ of Notre Dame, IN USA
(219) 631-7306                      http://www.nd.edu/~eschuber