ontape restore bug

We are using 9.20HC3 on HP-UX 11.11 still and have run into a bug where the ontape -r command hangs on a chunk and writes more pages than the chunk has allocated. For example, ontape has writtem over 300,000 pages to a 200,000 page chunk. Has anyone been able to create a workaround for this scenario? I realize we need to get off of that version asap, but we need to recover the data any we can. If there is anyone locally in the Los Angeles, CA, we would expecially like to talk to you about this. TIA.

The overcount is caused by updates occurring during the archive. If a page is changed after the archive is started and before the completion of the archive of the dbspace containing the modified page, then the pre-image of the modified page is copied from the physical log to a temp table immediately. After the archive of the dbspace completes the temp table containing these pre-images for that dbspace are pushed out to the tape and the temp table is dropped. During the restore all 200000 pages of the dbspace are slapped down then the pre-images are overwritten to put the dbspace back to its state at the moment the archive began. Is it possible that almost half the pages in the dbspace were modified during the archive? If so then all is well. Art S. Kagel ----- Original Message ----- From: Kevin Struc.... <kevin.struckhoff@newroads.com> At: 11/ 4 9:45 > We are using 9.20HC3 on HP-UX 11.11 still and have run into a bug where the > ontape -r command hangs on a chunk and writes more pages than the chunk has> allocated. For example, ontape has writtem over 300,000 pages to a 200,000 page > chunk. > > Has anyone been able to create a workaround for this scenario? I realize we need > to get off of that version asap, but we need to recover the data any we can. > > If there is anyone locally in the Los Angeles, CA, we would expecially like to > talk to you about this. > > TIA.