Subject | Re: [firebird-support] database growing too much after bulk import |
---|---|
Author | Sergio H. Gonzalez |
Post date | 2008-11-05T18:56:04Z |
Thanks for the answers!
a gstat gives me this about the table. Unfortunatelly I don't know how to
interpret it. May I have some help in this matter?
STOCK (153)
Primary pointer page: 231, Index root page: 232
Average record length: 0.00, total records: 0
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 2762, data page slots: 2762, average fill: 39%
Fill distribution:
0 - 19% = 391
20 - 39% = 1115
40 - 59% = 1075
60 - 79% = 181
80 - 99% = 0
And the DatabaseGrowthIncrement part in the config file is the default. It's
commented out.
# ----------------------------
# Disk space preallocation
#
# Sets the amount of preallocated disk space in bytes. Disk space
# preallocation allows to reduce physical file fragmentation and to make
# database work in out of disk space condition. With preallocation enabled,
# engine allocates 1/16nth of already allocated disk space at a time but
# not less than 128KB and no more than DatabaseGrowthIncrement (128MB by
# default). To disable preallocation set DatabaseGrowthIncrement to zero.
# Shadow database files are not preallocated.
#
# Type: integer
#
#DatabaseGrowthIncrement = 134217728
So, is this a normal behaviour of the database? I thought it could be an error
in the design on the STOCK table. The "import" section of my app erases all the
records before importing from the DBF file. This task will run just one time
when the databse starts to work in production, and no more. Is that OK? Anyway,
this growing was observed after doing a backup/restore, so there are no old
versions of records. Am I right?
Thanks again!!
-s
a gstat gives me this about the table. Unfortunatelly I don't know how to
interpret it. May I have some help in this matter?
STOCK (153)
Primary pointer page: 231, Index root page: 232
Average record length: 0.00, total records: 0
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 2762, data page slots: 2762, average fill: 39%
Fill distribution:
0 - 19% = 391
20 - 39% = 1115
40 - 59% = 1075
60 - 79% = 181
80 - 99% = 0
And the DatabaseGrowthIncrement part in the config file is the default. It's
commented out.
# ----------------------------
# Disk space preallocation
#
# Sets the amount of preallocated disk space in bytes. Disk space
# preallocation allows to reduce physical file fragmentation and to make
# database work in out of disk space condition. With preallocation enabled,
# engine allocates 1/16nth of already allocated disk space at a time but
# not less than 128KB and no more than DatabaseGrowthIncrement (128MB by
# default). To disable preallocation set DatabaseGrowthIncrement to zero.
# Shadow database files are not preallocated.
#
# Type: integer
#
#DatabaseGrowthIncrement = 134217728
So, is this a normal behaviour of the database? I thought it could be an error
in the design on the STOCK table. The "import" section of my app erases all the
records before importing from the DBF file. This task will run just one time
when the databse starts to work in production, and no more. Is that OK? Anyway,
this growing was observed after doing a backup/restore, so there are no old
versions of records. Am I right?
Thanks again!!
-s