Re: [Bulk] 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

> On 10/13/2014 2:18 AM, Graap, Kenneth wrote:

I have a Power720 system with 2 active processors, 96GB of RAM and an
8TB iASP - 50% utilized. Not a large system by today's standards.

For some reason, that is still being determined, this system CRASHED
HARD (immediately did a MSD and IPL'ed) right at the beginning of a
work day.

After a hard crash like this it is strongly recommended that a RCLSTG
process be run.

After negotiating a 12 hour window on Sunday, I started running RCLSTG
against the 8TB iASP...

After over 9 hours, the "Reading objects from disk" step was only 51%
complete with an estimated remaining time of almost 9 more hours!

Reclaim Storage in
Progress S02

10/12/14 23:01:46
RCLSTG:
Select/Omit/ASP device or group : *ALL *NONE IASP1
Start date and time . . . . . . : 10/12/14 13:47:38
Current step / total . . . . . : 2 7

Reclaim Storage Step Percent Time Elapsed Time
Remaining
Data base/library/directory recovery 100 00:00:11
00:00:00
>Reading objects from disk 51 09:13:54
08:52:10
Processing data base relationships 0
File ID table recovery 0
Directory recovery 0
Object description verification 0
Final cleanup 0

Total . . . . . . . . . . . . . . . . . . . . : 09:14:05

I had to abort the Reclaim Storage process and bring up the system,
knowing full well that when (or if) I restart RCLSTG it will start
from the beginning again.

It seems like the RCLSTG process needs to be modified in some way that
it can complete in a reasonable amount of time. Maybe it could be
designed to multitask (??) or keep track of what it had done so if
restarted it could continue where it left off (??) ... All I know is
it isn't working for me...

Has anyone else experienced this?

Kenneth
Kenneth E. Graap
NW Natural
System Administrator for IBM Power Systems
503.226.4211 x5537
http://www.linkedin.com/in/kennethgraap