K Nagarajan wrote:
>
> Hi,
>
> > On the surface it looks like there is no problem.  20% free disk space
> > should be enough.  The question is "Is the free space contiguous disk
> > space?".  That is why when you purge the database, the restore works.
> >
> > The other point is that may be 20% free disk space is not enough.  I
> > thought that the restore process restored the file(s) before purging the
> > already existing file(s).  If this is the case, at a point during the
> > restore you will have 2 databases exactly the same.
>
> The restore program first purges the target file and then restores it from
> the backup media, so you wouldn't have the problem of two databases being
> there at the same time.
>
it is never a pleasure to correct a colleague, but the above is not
exactly correct.

RESTORE creates the file it currently fetches from tape in the NEW
domain (invisible to LISTF , as it has not been inserted into the
directory yet). It will only remove the original file from the
permanent domain, after it successfully got all the data from the
tape, then the NEW file is saved into the directory as the last step.
This is necessary to avoid data loss.

The sectors for the NEW file will be allocated on the volumeset where
the file belongs based on its volume(set) restrictions, so the
suggestion
to temporarily increase the permanent disk space through ALTERVOL
commands
will only work on the MPEXL_SYSTEM_VOLUME_SET [do I really type this
faster
than my own name :-))]

So on any RESTORE you will need at minimum as much free permanent disk
space
as the largest file on your backup tape consumes. If you do parallel
tape device
RESTOREs (a <plug>TurboStore</plug> only feature AFAIK) it may be much
more. I
have not looked into it in detail, but it maybe that special STORE
options like
;INTER or ;ONLINE=START/END may result in RESTORE holding multiple NEW
files open
for a longer period of time, which may increase the disk space demand
during the
operation.

Goetz.