The job status of SVFW is probably not directly related to the
messages about the journal missing [and thus files being created without
journaling active]. The SVFW status implies that the database restore
activity [above the LIC] mucking about looking for and notifying of the
missing journal was almost surely _not_ delaying the attempt to load the
data from the save file [performed by LIC\LD tasks]. Instead, that some
disk access delays would have been the origin for the noticed "wait";
little difference should exist between two of the same restore with
regard to disk access, given the existence of the journal in one restore
but not in the other.
The looking for and diagnosing of the condition for the non-existent
*JRN object would account for extra work, and thus some extra time to
complete a restore, however many other issues could exist for the "much
longer" effect; e.g. access path rebuilds often are an impact.
Messaging alone for that scenario is probably not too much of an impact,
even with a very large number of database *FILE objects being affected.
Doubtful much impact at all, on the restore [LIC load] feature
accessing the data in the save file, because the messaging is mostly CPU
and the disk access for messages is the active job message queue.
To prevent the diagnostic messaging for the restore, the /restore/
should be treated as the /recovery/ it was. The journal should have
been accounted for [created or restored] in advance of the restore, just
as would be done for a disaster recovery scenario. Any database file
object restore which is not restoring over an existing object, as other
than merely a data restore, is a /recovery/ scenario for which the
special considerations of DR need be considered also for these more
specific restores. I recall discussions [on this list] about using the
QDFTJRN [or newer iteration of that] support to force journaling to an
alternate journal than originally defined for the files being restore,
to modify the more strict DR definition for such a restore.
On 05-Apr-2012 12:23 , Jack Kingsley wrote:
I just did a restore of a large library and it took much longer than
it should have. I was getting a SVFW and in the joblog it was all
pointing towards the journal that was not there.
On Thu, Apr 5, 2012 at 3:20 PM, Monnier, Gary wrote:
There is a parameter in DSPFD that tells you if the file is
currently journaled. If "File is currently journaled" is no I
don't think you have to worry.