Re: Library Authority

   Access paths are saved with the PF, with the data, not with the LF. 
When the PF is restored and the LF is not restored at the same time on 
the same restore request, then the access path of the LF will not be 
restored.  Thus when an\the LF is restored later, for example in a 
separate RSTLIB request [regardless of from which library it was saved], 
the access path will be built asynchronous to the restore; i.e. no 
access path is restored, just the definition of the LF from which the 
defined index is created.  If not planned as part of DR, the creation is 
done at run priority of 52, which means even compiles and other assorted 
non-critical /batch/ tasks will take precedence.  If planned rebuilds 
are part of DR, then they would typically be done ordered according to 
some application priority, and submitted under well-planned work 
management configurations for perhaps aggressive rebuilds, rather than 
the defaulted low-impact rebuild activity that is established as part of 
the QDBSRV## RUNPTY-52 jobs.

Regards, Chuck

[email protected] wrote:
> Are you saying that even if you save access paths when you save LF's
> that if the LF is not in the same library when you do a RSTLIB
> *NONSYS it will rebuild the access path?
_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) mailing list
To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.