Thanks to Gilles, Chris, Denys, Eric, etc. for enlightening me to my misunderstanding of Image Logging. Learning can be fun(and humbling at the same time). ---------- >From: owner-hp3000-l >To: Multiple recipients of list HP3000-L >Subject: Re: (no subject given) >Date: Thursday, March 14, 1996 8:33PM > >>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 >