Thanks.
I've opened a PMR to see if we can figure out what the damage will be.
Luckily this is a development LPAR that I just refreshed last month, so no problems with production jobs' record locks or data loss.
I will likely just compile an empty set of files rather than restoring the 772 GB physical file after we get it back.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, October 17, 2016 10:42 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: [EXTERNAL] Re: reorg not finishing
On 17-Oct-2016 09:29 -0500, Richard Reeve wrote:
On Oct 17, 2016 8:46 AM, "Maassel, John R." wrote:
[...] Second, if we did, which objects would we have to restore? The
logical file, for sure, but what of the physical and the other
indexes?
I would delete the physical (must first delete all depended on
logicals and indexes) then restore the physical and all logicals.
Or just the SQL request:
DROP TABLE The_PF CASCADE /* where CASCADE is the default */
But then be sure to review what was actually deleted, so as to know
what must be restored.
However for the given situation, I would suggest probably best to
*not* restore. Instead, to create the objects again/anew, from source,
and then copy the non-deleted-record data from the old file into the new
file; i.e. effectively effect what the reorganize request should have
done. That would eliminate any potential issues of origin involving
either the objects or the data as it resided in the existing dataspace;
both on backup media and on DASD. Obviously not a prudent nor likely
even acceptable choice for the current situation, wherein I presume the
intention is to get the data accessible vs necessarily determining the
origin of the issue and anything possibly preventive. But as I alluded
in prior replies, the data may be available as already-reorganized
[something that probably could be confirmed easily enough; maybe just
Display File Description (DSPFD) to show that there are no deleted
records in the member that was reorganized -- and like DSPPFM, the
access to the file.mbr implies the data-reorg is completed, despite the
access-path rebuild phase is blocked by the (presumed to be only) one
problematic LF index].
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.midrange.com_mailman_listinfo_midrange-2Dl&d=DQIF-g&c=3crv0V5Gxwbo5hXTsiQI6g&r=PkbfvkKxtcDeNvEOH5BjJL4QM0EQmj0cLL71lzl405I&m=BwaGLL74yW8JCZcG3MHESFfxoVS_JxjlZm3fvcE8yJg&s=C4NJirSENdKV-_p0XtGvMEa6i1m2v8u3dv9EM2WSw8Q&e=
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://urldefense.proofpoint.com/v2/url?u=http-3A__archive.midrange.com_midrange-2Dl&d=DQIF-g&c=3crv0V5Gxwbo5hXTsiQI6g&r=PkbfvkKxtcDeNvEOH5BjJL4QM0EQmj0cLL71lzl405I&m=BwaGLL74yW8JCZcG3MHESFfxoVS_JxjlZm3fvcE8yJg&s=7gjZ5BbW1jOicvxK2YOE7gXLI3Xz3RgqRxUA9IIfrSs&e= .
Please contact support@xxxxxxxxxxxx for any subscription related questions.
________________________________
Notice from Bob Evans Farms: This e-mail message, including any attachments, may contain confidential information that is intended only for the person or entity to which it is addressed. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments.
midrange.com
