Jeff,
Do you have any "logical data" problems? For instance, we have some
databases in which the data must be "logically consistent" between them.
If one dataset gets restored, the data in the other database must be
modified to reflect that in the restored dataset. (Not a good design,
but stuck with it.) DBGeneral will make sure that a single database is
structurally correct, but cannot ensure that everything is logically
correct.
Been there, done that, got the battle scars.
Hope this helps,
David N. Lukenbill
--------------------------------------------------------------------
David N. Lukenbill
Raytheon Missile Systems Company, Louisville
[log in to unmask]
----------
From: HP3000-L
Sent: Thursday, February 12, 1998 3:47 PM
To: HP3000-L
Cc: jeff-kell
Subject: Opinions solicited on database repair "gotchas"
I just finished recovering from a rather nasty mess, but I'm not 100%
confident that all is well. I'd like to hear any additional concerns
that I should perhaps examine to insure we're safe. Now the gory
details...
Our night operator initiated a partial backup (TurboStore 7x24) last
night just before 6:00 PM, online=start thus sync point ~6:00 PM.
Later that evening she inadvertantly purged a JCL file and through
some rare stroke of genius did a :restore @[log in to unmask]@ from the
aforementioned
backup around 11:00 PM, and didn't bother to call anyone or leave a
note about the "incident".
We do have some users around at night, not to mention batch jobs that
run after backups. Work was being accomplished, at least until
11:00.
At that point, files were restored to their 6:00 PM state *except*
for
files open for access. And yes, horror of horrors, databases were
indeed opened as well. By early morning, reports of broken chains
and
other assorted Image errors started streaming in.
Now bear in mind, at this point I had no idea about the
backup/restore,
just the broken chain reports...
I tried DBGeneral's detail analysis/repair and was greeted by screen
after screen of errors, master keys not matching the detail keys,
you-name-it. While on the phone with their tech support, it occurred
to me that "this dataset doesn't belong here" and :listf,3 showed me
the
create timestamps of "some" datasets being last night at 11:00 PM.
At this point we have one horrible reality and two unpleasant
options:
* anything done from 6:00-11:00 that *did* restore is toast, and we
a) lose the morning's transactions and restore to 6:00 last night,
or b) try to resynch the databases that were hosed.
Now, based on :listf,3 create timestamps and our backup listing, I
figured that:
* any database not on the backup is OK,
* any database that was completely restored is OK except for the
five hour period between the backup and restore
From the remaining "questionable" databases (correct me if I'm wrong)
I would think that if all of the datasets which were *not* restored
*and* not modified since the 6:00 backup time should be OK. I still
ran DBGeneral's global analysis (opt 2.6) anyway to be sure, and got
no structural damage reports.
This narrowed things down to a few that were largely static masters
but
a lot of detail dynamics. Bradmark's tech support uploaded a utility
to rebuild paths (our DBGeneral version was a bit dated and the newer
utility was recommended). Using the 2.6 option along with this
utility
rebuilt the paths in the corrupted details and restored the database
structure, but we no doubt dropped some records in the process.
We've asked users to recheck their transactions from this morning for
any anomalies but so far no reports. We know we lost some data from
the five hours between backup/restore, but the morning's transactions
appear for the most part intact.
Now apart from the obvious "You idiot... your data is probably
corrupt"
comments, are there any other integrity checks I have overlooked that
might bite me later?
Jeff Kell <[log in to unmask]>
begin 777 WINMAIL.DAT
M>)\^(D.)`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$(@`<`
M&````$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0V`!``"`````@`"``$$
M@`$`-````%)%.B!/<&EN:6]N<R!S;VQI8VET960@;VX@9&%T86)A<V4@<F5P
M86ER(")G;W1C:&%S(@!B$@$%@`,`#@```,X'`@`,`!``,P`M``0`5P$!`(``
M`$(````$`$(`$@`@`$QU:V5N8FEL;"P@1&%V:60``$]014Y-04E,.D1A=FED
M($QU:V5N8FEL;"`O2$U30TP```````````!-$`$@@`,`#@```,X'`@`,`!``
M+@`Z``0`7P$!"8`!`"$```!&,$4W0S-%1D$S03-$,3$Q.4,R-C8T.#-"1C`P
M,#`P,``3!P$#D`8`A`$``!(````+`",```````,`)@``````"P`I```````#
M`"X```````,`-@``````0``Y`-"0-&D`.+T!'@!"``$````1````3'5K96YB
M:6QL+"!$879I9`````!``$@`D(DJ:@`XO0$>`'```0```#0```!213H@3W!I
M;FEO;G,@<V]L:6-I=&5D(&]N(&1A=&%B87-E(')E<&%I<B`B9V]T8VAA<R(`
M`@%Q``$````6`````;TX`&B[[\/G\Z.C$=&<)F2#OP``````'@`:#`$````1
M````3'5K96YB:6QL+"!$879I9``````"`1T,`0```"````!/4$5.34%)3#I$
M879I9"!,=6ME;F)I;&P@+TA-4T-,`!X`'@P!````"0```$]014Y-04E,````
M`!X`'PP!````%P```$1A=FED($QU:V5N8FEL;"`O2$U30TP``$``!S`0AT"^
M_S>]`4``"#`0AT"^_S>]`1X`/0`!````!0```%)%.B```````P`--/TW``"&
!43>]
`
end
|
