Automatic Indexing Of Files
Travis Or Stephanie Meyers
I Restored Our Test Environment The Other Day. I Do This Quite Often. The
Jobs To Execute The Restore Finished Normally. I Noticed That The
Interactive Response Time Was Terrible. When I Looked At The Active Jobs,
I Saw 5 Different Jobs: QDBSRV01, QDBSRV02, QDBSRV03, QDBSRV04, And
QDBSRC05. They Were Indexing My Test Files. I Couldn't End Them Or Put
Them On Hold. So, I Called IBM. They Walked Me Through Putting Them On
Hold. Then, Everything Was Fine.
IBM Said That The System Automatically Reindexed Files, When It Thinks That
It Has A Better Way To Do It. They Said That It Is Usually Caused By A
PTF. However, I Have Restored Our Test Environment Several Times Since The
Last PTF Was Applied, With No Trouble. I Checked My Back-Up Program To
Make Sure That It Is Saving The Access Paths, And It Is.
I Will Need To Restore My Test Environment Soon. Does Anyone Know Of
Anything Besides A PTF Or Failure To Save Access Paths That Could Cause
Something Like This?
Thanks For Your Time,
Stephanie Meyers
--
tsme...@gmi.net
Bradley V. Stone
On 21 Dec 1997 22:27:29 GMT, "Travis Or Stephanie Meyers"
<tsme...@gmi.net> wrote:
Depending on how your system is set up, the 400 will automatically
rebuild your index's on restore. This builds the largest indexes
first and excludes paths that aren't needed. It does this either
during an ipl, after and ipl, or when the file is first used
(obviously this is the case that you ran into). I don't believe that
you can actually save an access path. It will have to be rebuilt upon
restore or ipl.
If there is a problem with this procedure during an IPL or a restore,
you most likely need a ptf.
Bradley V. Stone
bvs...@usa.net
http://prairie.lakes.com/~bvstone/
1992 Yamaha FJ1200
1969 Suzuki T250
"I was on fire.... and I was dry!"
OSITim
>Depending on how your system is set up, the 400 will automatically
>rebuild your index's on restore. This builds the largest indexes
>first and excludes paths that aren't needed. It does this either
>during an ipl, after and ipl, or when the file is first used
>(obviously this is the case that you ran into). I don't believe that
>you can actually save an access path. It will have to be rebuilt upon
>restore or ipl.
>
>If there is a problem with this procedure during an IPL or a restore,
>you most likely need a ptf.
>
>
In point of fact, you can save acess paths when you save a physical file by
specifying ACCPTH(*YES) on the SAVxxx commands. However, upon the restore
whether or not the system actually uses them is another question.
You probably already know this, but just saving a LF object does NOT save its
access path. You must save the physical file AND specify ACCPTH(*YES)
Before you do another restore, if I were you, I would ensure that
1. Both systems are at the same Version/Release/PTF level.
2. The indices (LFs) on the restore system do match the LFs from the save
system. You can ensure this by saving the LFs in addition to the PFs.
3. The Acess paths on the save system are valid before doing the save. use
DSPFD FILE(mylib/*ALL) TYPE(*MBR) OUTPUT(*OUTFILE) FILEATR(*LF *PF)
OUTFILE(outfile). Query the outfile for files where MBINDX <> "Y"
Use the EDTRCYA command to control which access paths are rebuilt, if the
system does decide to rebuild them.