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].