On 17-Dec-2013 08:02 -0800, rob@xxxxxxxxx wrote:
And, like many people know, a RCLSTG only attempts to fix stuff
that's already been flagged as damaged.
:-( For physical damage [hard\full or soft\partial], the Reclaim
Storage (RCLSTG) merely performs one of its primary functions called
*Damage Notification* which should *not* be confused with any
implication that the feature will have performed any action to "fix
stuff"; irrespective of its previously-detected or as-yet undetected
The Reclaim can not /fix/ physical damage; the only recovery
available for physical damage is to delete the damaged object. The
Reclaim feature will however perform some cleanup activity for a
specific type of /logical-damage/ conditions, such as conditions that
arose from *partially-completed* operations for which a permanent
progress-tracking object [i.e. a recovery object] exists to inform of
the pending recovery. Any other type of logical damage is likely to
pend some recovery actions specific to the logical condition for which
the object is deemed /broken/ by the owning-component of that
object-type+atribute; e.g. for the Database *FILE object, the owning
component would be the OS Database (DB) component for which its
/recovery object/ is the *DBRCVR type x19D4.
We ran a full RCLSTG immediately before the STRBKUBRM.
Fat lot of good that 7 hours and 47 minutes did us.
Twas the following save that flagged it.
Because the reclaim merely notifies of damage rather than
/correcting/ damage, the history log spanning the reclaim request must
be reviewed to determine what objects were previously known or
since-detected to be damaged, during that reclaim processing. The save
will implicitly omit those /notified-as-damaged/ external objects from
the save; I do not recall what transpires for damaged database members
as an internal object type *MEM as subcomponent of the external object
type *FILE. However any objects remaining /logically damaged/ [for
other than the partial\pending work, for which that work was nullified
by a full reclaim] may, as was encountered, still present a problem for
the save [or other supported operations against that object]. As well,
any object that is physically damaged but for which that damage is
not-yet detected, will cause the save processing to fail; i.e.
previously detected damage is avoided by the save, but damage detected
during the save [i.e. encountering previously undetected damage] is
deemed an unrecoverable error for the save processing.
The save is more likely to catch additional problems with either
physical or logical damage, than the reclaim, because the object and
data need to be sufficiently navigable to make a copy of both on the
media. The reclaim does not need to navigate data portions of objects
nor perform some other operations against the object that the save might
need to. For example the reclaim needs to know of each member by name
and association with a parent-object to perform context and owner\aut
recovery, but navigating the member-chain is not required. The logical
validation of the member-chain could be added [though not a good fit in
the design] as part of the reclaim, but of course at a [potentially
large] cost in clock-time for the request... and if in a DCR, would best
request the ability _optionally_ to do so. Similarly if asking the
reclaim to process\verify the data segments.