We use RoadRunner (soon to become once again, Back Pack. It's behavior is
similar for the DBSTORE option.
We do not have time for a full backup, even though we perform an on-line backup.
We use a partial (not incremental) backup that picks up files modified since the
previous full backup. What is good about the DBSTORE option for us is that if
even a single dataset has been modified, the whole data base will be on the
tape. I have not paid attention to how this works when only the root file has a
new modify date because we use the tapes to restore for Netbase resync purposes
only a specifically stated (some variation on occasion) subset of files and data
bases. Or use the month end partial for a copyover to a static monthly reporting
system, etc.
Here is the scenario (stop reading if you are not interested) that prompted my
question earlier:
Last night (actually early this morning) we had to resync (a Netbase concept)
our Amisys data bases on the shadow system. Normally we let Netbase use the
modification datetime stamp of the root file that is always the date and time
that RoadRunner under the aegis of a DBSTORE parameter updated the root file as
it stored the data base on the master system. Just as I was about to release the
resync process itself after a successful restore, the operator called me to
altert me to the fact that some job had unexpectedly (not under his control)
logged on. I quickly checked to modification date and time, and indeed this job,
opening the data base in mode 5 had "polluted" the date-time stamp. Since I was
aware of this unexpected change in the date-time stamp, I was able to handle the
matter in a different manner. Had I not known, we would have discarded about
seven hours worth of transactions that had occurred on the master system.
Anyway, I was quite surprised to see the even Mode 5 modifies the root file.
This is counter-intuitive to say the least.
===================
Leonard S. Berkowitz
Perot Health Care Systems
(Harvard Pilgrim Health Care account)
voice: 617-509-1212
fax: 617-509-3737
pager: 781-226-2431
Doug Werth <[log in to unmask]> on 01/10/2001 04:47:09 PM
Please respond to Doug Werth <[log in to unmask]>
To: [log in to unmask]
cc: (bcc: Leonard Berkowitz/CORP/HPHC)
Subject: Re: [HP3000-L] TurboImage rootfile modification
date
Patrick Mullen writes:
> There are run time fields in the root file that get modified during a
> DBOPEN (regardless of Mode)...They revert back to zero (in the cases I
> examined) upon DBCLOSE...So in effect, no lasting modification transpired
> although a run time modification took place (returned to its/their
> initial/default values upon DBCLOSE, in the fields I examined)...
>
> I must say that I, too, was surprised but now understand how it happened.
>
> The coresponding/underlying datasets do *not* get an updated 'mod date'
> during dbfind/dbget on a Mode 5 opened database, however...
A side effect to this behavior is that an incremental backup will consider
this root file modified today, thus backing it up. Moreover, using the
default TurboStore option ";FULLDB" will cause TurboStore to write the
entire database to tape, even though none of it has been modified. This can
be quite a surprise to find a large archive database on a partial backup.
Another issue is that TurboStore sets the DBSTORE flag and writes the last
logfile and datestamp to each root file it backs up. In doing so, TurboStore
is also updating the access and modify dates of the root file in the file
label. Consequently, databases appear to have been modified just because
they have been backed up.
I suspect that because of the speed and capacity of DDS2, DDS3, and DLT
drives that most users are just doing daily full backups and no longer
running incremental backups or this issue would have received a lot more
attention. And those that are concerned about the length of daily backups
are selectively backing up files rather than using the ";DATE=" parameter of
TurboStore.
Has anyone else noticed this behavior? Has it been a problem for you? Just
curious.
Doug.
Doug Werth Beechglen Development Inc.
[log in to unmask] Cincinnati, Ohio
|
