On 01 May 2013 06:02, Robert Clay wrote:
The views were physically missing.
Clarification of what "The views" were or are; e.g. what is the
source that re-creates those that have been found to be missing? For
example, was each based on a UDTF that perhaps was dropped? I presume
this is *not* about any SQL /catalog VIEW/ files gone missing, neither
from the system libraries nor user libraries.
FWiW, in my experience, the most typical cause of user-created
database objects having gone /missing/ originates from running under
commitment control unknowingly or unexpectedly, such that a failure to
/COMMIT/ the CREATE request has the object disappear when the job ends.
A similar problem is for requests to DLTF or DROP that had failed, and
for /recovery/ of the failed database operation run without isolation,
the request would be run to completion during the IPL; the SCPF joblog
would log it, as well a message in the history. For any VIEWs gone
missing, I would review the /last altered/ time for the based-on TABLE
objects. I would not be surprised if an origin for such an issue might
originate with CHGPF SRCFILE(named) DLTDEPLF(*YES). And unlikely...
although I have never used the feature to enable restore of logical
files before the physical files, I could imagine having used that
feature without completing all of the work to complete the restore might
give rise to issues; perhaps one manifest as an apparent loss of some
VIEWs. But because no mention was made of any prior restore activity, I
doubt that feature was used prior to the PTF activity.
IBM's answer on the PMR was, basically that without journaling,
there really was no way to know what happened but that the PTFs
shouldn't have touched them. So, no real help there. They did
suggest taking a snapshot of QSYS2.SYSVIEWS as a base list to
compare to later in case it happens again. At least that way,
we would know which views were missing.
There is more than just journaling... but that requires knowledge and
effort to ferret out more than what is simple and obvious. IMO a
/snapshot/ of the data from SYSVIEWS is somewhat daft, whereas object
auditing is a conspicuously good approach; optionally also changing the
journaling for the system Database Cross Reference could enable some
other details that could be revealing.
The general Object Auditing [tracking delete, create, and object
management operations] is the simplest and most effective means to
review for who\what deleted the SQL VIEW files... if that was in effect
when the DROP\DLTF transpired; a T-DO entry in the QAUDJRN, IIRC.
Also if the PTF application during IPL effected the loss, then there
would likely be evidence logged in the spooled SCPF joblog from that
IPL. If not there, then in a system job where some PTF might have
/submitted/ its work; e.g. QDBSRVXR2 system job. If indeed the PTF
application is related, then any other job which might have done PTF
work could have its joblog reviewed; e.g. the job loading and applying
the PTFs before the IPL... and any jobs started after the IPL that were
atypical, or any that lasted longer than typical.
Depending on when a file was deleted and when the last change of the
receivers [which can be prevented by changing the journal environment]
for the QDBSRVXR processing, its journal will contain at least somewhat
informative /timing/ details for the deletion of the VIEW; i.e. the
corresponding delete of the row where DBXFIL='TheViewNam' from the
QDBXREF file, and depending on how the VIEW was deleted, may even
contain some extra information. Oddly, I forget the name of the
journal, but it should have naming QDB* in QSYS.
midrange.com
