Earlier today Pierre asked:

> Roll Foward recovery :
> Does someone use this way to mirror Turbo Image database?

Well;  yeah;  "sort of" we do that:

Roll Forward recovery allows you to put the log files on a different
volume set from the volume set the database resides on.  Every
night during the five-or-so hours when production database does
not need to be online for our users we copy database from our
USER volume set to the BACKUP volume set.  After successful
completion of copy we restart logging with a new set of log files
(after saving previous set of log files to another group to go with
previous STORE to tape of BACKUP volume set (we are fairly
paranoid about our mission-critical data) ).

A code snippet from our job stream that runs on the BACKUP
volume set is (edited to protect actual database names).  The
variable LOGGROUP gets set according to the day of the week.
the "PAUSE 30" between RELLOG and GETLOG is in there
because RELLOG is one of those commands that "comes back"
to the prompt right away;  *BUT*  It might take a few seconds to
complete.  If RELLOG is not completely done before do the
GETLOG thing, GETLOG will fail:

!   IF JCW >= FATAL  THEN
!      comment     copy of xxxxxx.xxxx.xxxxxxxx FAILED.  Restart
!      comment     logging on CURRENT file set;  + PRINT WARN
!      JDWARN.PUB
!      LOG LGxx, RESTART
!   ELSE
!      PURGE   [log in to unmask]; NOCONFIRM
!      DSCOPY LGxx@ TO @.!LOGGROUP; MOVE; QUIET
!      RELLOG  LGxx
!      PAUSE    30
!      BUILD     LGxx001; DISC=2048; CODE=LOG
!      GETLOG  LGxx; LOG=LGxx001.xxxx.xxxxxxxx,DISC; AUTO
!      LOG LGxx,START
!   ENDIF

This way if by some *real* bad stroke of luck our Mirrored USER
volume should get hosed up / broke to the point where neither
spindle in the same mirrored pair is useable, we have all info on
the BACKUP volume set necessary to Roll Forward with last night's
copy of the production database....  of course we will be down for
some amount of time until we get the USER volume going again,
bring last night's database copy back, and Roll Forward...  but we
will (at least in theory) not lose a single record from our database.
...  and with the USER volume being mirrored, hopefully odds of
having to do the above for real are slim...


> What do you think about this?

Lot cheaper that NetBase Shadowing....  simpler, too...  AS LONG
AS you can afford the time to fix USER volume and Roll Forward..
and:


Sort of SIDEBAR for another day:  Be advised that over a period
of many months working with the HP RC, we have discovered a
few "interesting" details that effect the above, if you are running
Image/SQL and have your TurboIMAGE databases ATTACHed to
an ALLBASE DBE:  It turns out that that the file names in the
TurboConnect file (TurboIMAGE database name + "TC") and
the ALLBASE DBE are fully qualified....  by itself that is probably
not a surprise....   *BUT*:

It turns out that STORE / VSTORE is not smart enough to realize
it is being asked to STORE / VSTORE *copies* of the IMAGE
database and ALLBASE DBE;  when it looks inside the TC file
and the DBE that have been copied to the BACKUP volume set:
STORE completes without error, but it writes something really
screwy at the front of the tape, and depending on several factors
at the time the tape is cut (not all completely understood (long,
*LONG* story) ), if you are "unlucky" (we were "unlucky" maybe
40-50 percent of the time), all subsequent VSTORE attempts on
that tape will FAIL..   :-(((    Failure mode is TurboIMAGE dataset
counter on VSTORE listing goes nuts and counts IMAGE datasets
in NEGATIVE direction up to a thousand datasets or more;  and
then VSTORE ABORTs in the first few seconds of trying to read
the tape....   arrggghhhh.....

If I get time and others are interested, I can give a more complete
history and description of our "VSTORE failure" saga....

Ken Sletten