Re: Save file to tape

[CRPence <CRPbottle@xxxxxxxxx>]

  The OP asks about the restored SAVF [device file size] *FILE 
size, not the database *FILE size, So... the official answer had [to 
have] come from the "load\dump folks" versus "database folks"... 
even if I was the database person contacted and then to have alluded 
to the probability of the dynamic allocation during save explaining 
the size difference for the restored object. :-)

  The *DMPSPC object is allocated in chunks\extents, probably using 
a similar algorithm to the database [larger chunks for multiple 
successive requests], such that the save file object as target of 
the dump [AKA save] may be *larger* than the save file created 
during the restore of that saved save file.  That is because the 
dump space can be pre-created to exactly the size required to hold 
all of the records, into which the dumped\saved records\data are 
then loaded\restored.  As such, a restored save file *FILE object 
should never be larger than the unchanged\saved save file object.

  A restored database file however, may be larger or smaller.  The 
noted response from Debbie does not apply for restored database 
files.  The reply does however allude to how size differences often 
will be seen for copies [note: old reorganize is a form of copy, 
which can increase a dataspace size] of database files.  Although a 
restored database file may change in size from its original, what 
was allocated for data is pre-created to the saved size.  Some of 
the database *FILE composite pieces for various reasons will change 
in size, but the "dataspace" size [what would similarly be described 
as allocated dynamically in extents] would remain identical; i.e. 
any empty extents allocated before save will be part of the 
pre-created data space object.  The overall changes in size from the 
original database *FILE objects in comparison to the restored 
objects are due to differences in the restored file for any changes 
in the network\relationships, changes to the composite pieces being 
built new versus restored [database restore is implemented as create 
then data load], and changes in object sharing [e.g. formats, indexes].

Regards, Chuck

Roger Harman wrote:
> I ran into a similar situation years ago.  I emailed Debbie
> Saugen, the Backup/Recovery wizard @ IBM, and she got the answer
> from the database folks.  To paraphrase (from memory) it's an
> issue of allocation and extents.  When the system creates the
> object, it gets space dynamically. When it restores the object,
> it knows how much space to allocate right off the bat.
>
> My original question was in response to an audit of our
> backup/restore. On a test, the object sizes differed - some
> larger, some smaller.
>
>
> john.earl at 12/08/2009 12:26:03 PM wrote:
> > Has anyone ever heard of a restored save file being of a
> > different size than the original save file that was saved?
> >
> > We have a situation where we wrote a save file with 5300+
> > objects in it to tape, then later restored the save file and to
> > the same system and found that the size of the restored file
> > was about 190K smaller than the the original save file.
> >
> > A DSPSAVF indicates that the same number of objects are in the
> > save file, and there is no obvious loss of data.  The next step
> > is to do a object by object inspection, but before I go down
> > that road I was wondering if there might be a simple
> > explanation that I am just not aware of.