Re: Faster RCLSTG's on new machines

On 11-Sep-2014 13:23 -0500, rob@xxxxxxxxx wrote:

Mark S Waterbury on 09/11/2014 02:11 PM wrote:

If you run a RCLSTG not long after a full restore e.g. after
migrating an LPAR to a new physical machine, then RCLSTG should run
really fast, as there really should not be any "damage" to clean
up. As I understand it, a full unload / reload (Save / Restore)
would eliminate almost any "damaged" objects, as they would
probably not restore, and also has the nice side-effect of
"defragmenting" the DASD space used.

I am totally hip to what you are saying. What is odd is that the
RCLSTG requests are run every quarter and they are pretty consistent
within the same LPar. I can't imagine we consistently get the same
'damage'.

Post-reload and reference to /damage/ are likely not germane. The Reclaim Storage (RCLSTG) does not fix "damaged objects". The request also does not "defragment".

The amount of time [esp. if omitting the *DBXREF] is likely almost entirely linearly affected by the total amount of permanent objects for a reclaim done on a routine basis after a normal IPL [and all normal IPL since the prior reclaim], with a great amount of faulting. Having SSD [vs HDD; or permanent data mostly on SSD] will reduce the total time required to fault segments into Main Storage [memory] and the larger the MS the more objects can remain in memory and thus minimize faulting.