Re: DSPFD command and journals.

[CRPence <CRPbottle@xxxxxxxxx>]

  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.

Regards, Chuck

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.