Re: Save file to tape

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.