| Subject | Re: [firebird-support] Problem with database size after the copy operation |
|---|---|
| Author | Helen Borrie |
| Post date | 2007-10-10T04:27:16Z |
At 01:44 PM 10/10/2007, you wrote:
on-disk image of the file at the time it is read by the file-copying
utility. The filesystem has has no knowledge of the meaning of the
contents of the database file. A file copy of a database will
contain all of the obsolete record versions that are present when the
copy occurs.
It is not unusual for any active writable source file to be
fragmented. In creating the "snapshot image" of the file, the
operating system will gather up all of the fragments of the source
file in preparation for copying to the destination. If the new copy
is less fragmented than the source file, it would be expected to be a
few bytes smaller than the source file, as is the case here.
utility (gbak, or its equivalent in Service Manager), then restoring
that backup will always produce a smaller database. This *is* the
condition where obsolete record versions are not transported. The
restore also eliminates "spare" blocks of space and writes to exactly
the number of blocks needed to accommodate the database and its data.
You should not use file-copying utilities to back up or duplicate any
database. Always use the internal tools.
./heLen
>chsarvani wrote:This is incorrect. A file-copy of a database file is a copy of the
> > Hi,
> >
> > I am using fbcopy tool for copying from one FDB to another FDB.After
> > copying the data from source FDB to destination FDB successfully, the
> > size of both the databases should be same.
> > But it is observed that the size of source FDB differs from that of
> > size of destination FDB. But when I compare the databases, the data is
> > copied correctly.
> >
> > If the source FDB is of size 19,517 KB, the destination FDB size is
> > 19,484 KB.
> >
> > Why there is change in the database size after the successfully
> > copying the data.
> >
> > Regards,
> > Sarvani
> >
> >
>
>Because the destination DB has "only the records", the source DB has
>all the same records, plus space used by deleted records, plus data from
>obsolete record versions and so on.
on-disk image of the file at the time it is read by the file-copying
utility. The filesystem has has no knowledge of the meaning of the
contents of the database file. A file copy of a database will
contain all of the obsolete record versions that are present when the
copy occurs.
It is not unusual for any active writable source file to be
fragmented. In creating the "snapshot image" of the file, the
operating system will gather up all of the fragments of the source
file in preparation for copying to the destination. If the new copy
is less fragmented than the source file, it would be expected to be a
few bytes smaller than the source file, as is the case here.
>try backin-up and restore both and you will see the same size.Also not correct. If you back up a database using Firebird's backup
utility (gbak, or its equivalent in Service Manager), then restoring
that backup will always produce a smaller database. This *is* the
condition where obsolete record versions are not transported. The
restore also eliminates "spare" blocks of space and writes to exactly
the number of blocks needed to accommodate the database and its data.
You should not use file-copying utilities to back up or duplicate any
database. Always use the internal tools.
./heLen