Re:Has Reclaim Storage becoming outdated?

While I appreciate the CONCEPT here of allowing more parallelization of the reclaim I don't at all support it for a production system. Here's why:

In the last decade I can name two systems that really benefited from RCLSTG and one of those had multiple hard crashes (due to power and storms) in a three day period. Eventually it had to have one to correct issues.

Second it is A LOT of work in most cases to break up workload by ASP.

Third it could cost A LOT of money to have enough disk arms available, preferably in separate RAID sets to supply adequate performance for each ASP.

Fourth there are many parts of RCLSTG that can be run with the system up already.

Fifth what seems to be the most important part of RCLSTG the *DBXREF part usually is a small fraction of the overall time, so I'd start with that only.

So the risk/reward benefit here doesn't work for me.

Remember you can put 8TB EASILY in two drawers of disk today with lots of open slots and hot spares. 8TB isn't a large system......

- Larry "DrFranken" Bolhuis

www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com

On 10/13/2014 11:25 AM, Mark S Waterbury wrote:

Hi, Kenneth:

A single large IASP of ~8TB, even if only 50% occupied, will take a long
time for RCLSTG to analyze.

The following approach may help ...

Instead of one large IASP of 8TB, why not have 8 IASPs of 1TB each? That
way, in the event of a system crash, you could attach and vary on each
separate IASP in a different LPAR and then run the RCLSTG process "in
parallel" ... I would think this should complete much faster than
running RCLSTG against a single large (8 TB) IASP.

Then, once that "parallel RCLSTG" is completed, you can vary off the
IASPs, then attach them and vary them all on to the primary "production"
LPAR once again.

Someone else mentioned "High Availability" -- for example, this approach
would also permit you to vary off one IASP, attach it to another LPAR
and run a full back-up of that IASP on that LPAR, then vary it off and
back onto the "live" production LPAR once again. If you group libraries
into these IASPs based on what "applications" use those libraries, this
could allow you to keep your "warehouse" applications "up and running"
while the "financials" applications are being backed-up, for instance.

HTH,

Mark S. Waterbury