Re: Anybody ever seen this before? A power failure causing duplicate keys to appear in a file?

On 4/19/11 5:19 PM, James Lampert wrote:

Anybody ever see this before?

We got a distress call from a customer who'd had a power failure, and
an application that wouldn't come up.

I looked into it, and found that the keyed access path of a crucial
file was being blocked from being reconstructed, because somehow, the
power failure had caused duplicate records to appear in it.

I would suggest reviewing the history log, at least for CPF3100 range of MSGID for anything about that LF besides the condition of "could not be built". I recall such symptoms for some defect conditions or as a legitimate effect of main storage lost [in this case for lack or failure of UPS] without SMAPP or journaling having been enabled to prevent the loss for the data and\or access path.

Explicit STRJRNAP or [more aggressive?] SMAPP would probably prevent the condition, even if origin by defect.

Another scenario might arise instead from the application opening the PF for update while the LF access path was invalid\non-enforce [i.e. the LF being blocked from re-create due to the duplicate key values], and that the application added [by insert or update] the duplicates. If the AccPth was not valid during the open of the PFM, then the open should have signaled the access-path rebuild event [to the QDBSRV01 job] to request the immediate rebuild be scheduled in the QDBSRV## low-priority jobs and to become visible on EDTRBDAP if not already. I do not recall what effects invalid\non-enforce versus invalid\enforce for a UNIQUE defined key. I doubt that is only used for physical keys or constraints; I recall every normal scenario was supposed to ensure invalid w/ enforce, specifically to prevent this scenario. As I recall, the open of the PFM should always fail with CPF5090 when any invalid UNIQUE keyed LF exists over the data. The CPF5090 is the message sent when\after the rebuild request is signaled. If there is a normal condition for invalid\non-enforce, that problem should be prevented again either by explicit STRJRNAP, [more aggressive?] SMAPP, or ensuring after an abnormal termination that the access paths are rebuilt before I/O. The application [or instead a pre-requisite operation to the application] can do that itself, by opening the LFM using the key [open with keyed access] before opening another path to the PFM data. There are also the RECOVERY [with appropriate MAINT] parameter specifications on the CRTLF and CHGLF to move the access path recovery to the *IPL versus *AFTIPL [or *NO]; IIRC the start of rebuild processing is completed in IPL for the former, but IPL continues after all remaining work is offloaded to the database rebuild server jobs even though rebuilds continue... though the RECOVER parameter help text I believe suggests access path rebuild completion.

Regards, Chuck