Subject Re: [firebird-support] The size of my data file increased abnormally
Author Helen Borrie
At 11:06 AM 26/01/2005 +0800, you wrote:

>firebird-support!
>
> The size of my data file increased quickly and abnormally .(
> FB1.5.0 on RedHat 9.0/linux 2.4.2 )
>
>
>+--------------------------------------------------------------------------+
> -rw------- 1 root root 612315136 Jan 25 09:15
> AccountData.gdb
> -rw------- 1 root root 623349760 Jan 25 14:05
> AccountData.gdb
> -rw------- 1 root root 628793344 Jan 25 16:47
> AccountData.gdb
> -rw------- 1 root root 638668800 Jan 26 10:39
> AccountData.gdb
>
>+--------------------------------------------------------------------------+
>
> There are about 2000 records being inserted into both the table A
> and B hourly .
>
> CREATE TABLE A (
> CDRID INTEGER NOT NULL,
> DOMAINNO INTEGER NOT NULL,
> CALLINGNO NUMBER_2,
> CALLEDNO NUMBER_2,
> CALLINGTIME TIMESTAMP NOT NULL,
> TALKINGTIME INTEGER NOT NULL,
> DIALFEE MONEY,
> CALLINGIP NUMBER_2,
> CALLEDIP NUMBER_2,
> FEEOFAGENT MONEY,
> AREACODE NUMBER_2,
> PREFIXCODE VARCHAR(20),
> REALCALLEDNO NUMBER_2,
> HIREOR VARCHAR(20) DEFAULT 'normal',
> FEEOFADMIN MONEY,
> FEEOFTRADER MONEY,
> HIREORAGENT VARCHAR(20),
> DIRECTION VARCHAR(20)
> );
> ALTER TABLE A ADD CONSTRAINT PK_A PRIMARY KEY (CDRID);
> CREATE INDEX A_IDX1 ON A (CALLINGTIME, DOMAINNO, CALLINGNO);
> CREATE INDEX A_IDX2 ON A (AREACODE, CALLINGTIME, DOMAINNO);
>
> CREATE TABLE B (
> CDRID INTEGER NOT NULL,
> DOMAINNO INTEGER NOT NULL,
> CALLINGNO NUMBER_2,
> CALLEDNO NUMBER_2,
> CALLINGTIME TIMESTAMP NOT NULL,
> TALKINGTIME INTEGER NOT NULL,
> DIALFEE MONEY,
> CALLINGIP NUMBER_2,
> CALLEDIP NUMBER_2,
> FEEOFAGENT MONEY,
> AREACODE NUMBER_2,
> PREFIXCODE VARCHAR(20),
> REALCALLEDNO NUMBER_2,
> HIREOR VARCHAR(20) DEFAULT 'normal',
> FEEOFADMIN MONEY,
> FEEOFTRADER MONEY,
> HIREORAGENT VARCHAR(20),
> DIRECTION VARCHAR(20)
> );
> ALTER TABLE B ADD CONSTRAINT PK_B PRIMARY KEY (CDRID);

It doesn't seem abnormal. This represents a period of > 25 hours, 4000
inserts per hour, or around 100,000 inserts. Assuming a 4 Kb page size and
one row to a page, that's potentially 400 Mb in new page allocations, not
counting new index pages. Since the actual growth was only 26 Mb,
including new index pages, clearly a lot of pages contained multiple rows
and some space was probably available to re-use.

If this level of growth is a problem, you can probably reduce it by
sweeping the database more often (to free up space on existing pages) and
by setting some indexes inactive during these large inserts; or by
periodically rebuilding the indexes.

./heLen