Re: Efficiency question on file extents...

On 15-Feb-2012 16:09 , sjl wrote:

But what are the implications of doing the

CHGLF FILE(MYLIB/MYLF) FRCRBDAP(*YES) ACCPTHSIZ(*MAX1TB)

on my logical files, as suggested in the article?

All of the LF's currently have FRCRBDAP(*NO)

An LF does not "have" the [attribute of\set to] FRCRBDAP(*NO). The Force Rebuild Access Paths parameter is an _action_ which is requested, rather than an _attribute_ of the file that can be [re]set.

The implications of *MAX1TB is mostly a cost in memory footprint [esp. access path journaling; e.g. SMAPP] and a benefit in their likely availability to implement a query. If the AccPth is not to be used by queries, only for /native/ I\O, then probably best to not change the access path size [if the number of rows will never exceed the limit of the *MAX4GB].

Also FWiW, IIRC the change of the Access Path Size will force the rebuild of the access paths irrespective the specification on the FRCRBDAP parameter; I believe that *YES just forces the work to be done asynchronously in the [low priority] QDBSRV## jobs, so if specific Work Management is desirable for the rebuild activity [e.g. better RunPty] then specify FRCRBDAP(*NO) for the CHGLF performed synchronously within a job submitted with the desired performance characteristics.

Regards, Chuck