OK, been a while since I've been in this situation, but it seems that access
paths are rebuilt as they are incurred and that it's a batch task vs a part
of the dedicate restore functions, at least for LF's... I recall after
doing a recovery where there should be a job you should see in wrkactjob
that has an I-filename with the name of the file who's index is being
rebuilt. I don't have a 400 in front of me that's IPL'd at the moment, but
there's also a command to view and prioritize the access path rebuilds...and
if you have the CPU and memory power, you can also fire up a few screens and
to a manual open of the LF's you want which will decrease your
downtime...but that presumes access to a command line and should only be
done after the restores are all completed. Seems that we had a client that
didn't save access paths and after the restores were completed I fired up a
few batch subsystems and submitted opens to several batch queue to get
different files going fast...yes, they had the memory and CPU to handle
it....otherwise, as I recall, it was a single treaded operation...
Also, I would hope your journals/journal receivers aren't on the same pack
NOR same I/O controller as your database files as that can KILL
performance...as well...
DR2
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, February 09, 2009 6:21 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Restore on V5R4 after upgrade painfully slow
David Gibbs wrote:
Kirk Goins wrote:
Couple questions come to mind #1 were Access paths saved? Where is
the 2749 in relation to a disk controller? On the Same BUS or IOP?
( this last item can kill tape performance )
Our IT guy replies ...
The save was done with a Go backup option 11 which is the same as a
Go save. By default the access paths are saved. I'm talking with IBM
now and they said they have seen instances where the access paths
were backed up and they were still rebuilt during the restore.
However the only way to confirm that is with a command line which we
don't have since the restore is still running. They are not on the
same bus or IOP.
To suggest that "they have seen" is a daft comment; in the least,
because it seems to imply that there is some unknown defect for which
that sometimes is the effect. While indeed there are some defects for
which that might transpire, it is best stated that access path rebuilds
during restore, regardless that ACCPTH(*YES) was specified, is perfectly
valid and normal for some restores. Specifically for when the DR
strategy did not properly account for what saving access paths can
actually effect; i.e. data in different library than the logical file
that defines the access path, vitiates the intent of the request to save
access paths, since it is not possible to ensure the data and index are
consistent\unchanged so the index objects must be rebuilt for the data
to ensure integrity of the data.
FWiW: Before that restore, I always adjust the message which defines
the SysRqs options, to effect WRKJOB instead of the shipped default of
DSPJOB, in order to enable a command line. In that manner I can issue
WRKACTJOB [JOB(*SYS)], WRKSYSACT [to look for LD tasks], and EDTRBDAP as
necessary, from the SysRqs-3 menu option.
The RSTLIB of *NONSYS can be restarted, thus SysRqs-2 to effect
ENDRQS would enable command line access. However I would perform
several SysRqs-3 OUTPUT(*PRINT) over several minutes to record the
program stack and job locks, for possible later review for any [lack of]
changes.
Regards, Chuck
midrange.com
