Subject | Re: [firebird-support] Problem with database size after the copy operation |
---|---|
Author | Alexandre Benson Smith |
Post date | 2007-10-10T11:58:02Z |
Helen Borrie wrote:
For sure Helen, I know a File system copy is just an identical image of
the other file, but it's not the case, he is using Milan's *fbcopy*
He has a database, let's call it DB1
Then he uses FBCOPY to create a new database (let's call it DB2)
DB2 is smaller than DB1 (since it has no obsolete record versions and
other data that has no meaning in a newly created and populated database)
What I suggested him to do is:
gbak DB1.fdb DB1.fbk -user sysdba -password masterkey
gbak DB1.fbk DB3.fdb -c -user sysdba -password masterkey
then
gbak DB2.fdb DB2.fbk -user sysdba -password masterkey
gbak DB2.fbk DB4.fdb -c -user sysdba -password masterkey
DB3.fdb and DB4.fdb should have the same size even if DB1.fdb is greater
than DB2.fdb.
hope it's clear now.
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
> At 01:44 PM 10/10/2007, you wrote::-)
>
> This is incorrect. A file-copy of a database file is a copy of the
> 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.
>
For sure Helen, I know a File system copy is just an identical image of
the other file, but it's not the case, he is using Milan's *fbcopy*
>Helen, I think my english is much worse than I expected :-)
>> 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.
>
He has a database, let's call it DB1
Then he uses FBCOPY to create a new database (let's call it DB2)
DB2 is smaller than DB1 (since it has no obsolete record versions and
other data that has no meaning in a newly created and populated database)
What I suggested him to do is:
gbak DB1.fdb DB1.fbk -user sysdba -password masterkey
gbak DB1.fbk DB3.fdb -c -user sysdba -password masterkey
then
gbak DB2.fdb DB2.fbk -user sysdba -password masterkey
gbak DB2.fbk DB4.fdb -c -user sysdba -password masterkey
DB3.fdb and DB4.fdb should have the same size even if DB1.fdb is greater
than DB2.fdb.
hope it's clear now.
> ./heLensee you !
>
>
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br