Firebird woes

[oceanfront]

We are running plastic 3.22 on CentOS 5.7 with Firebird 2.51

It's been running fine, and all of a sudden we cannot create new repositories.

Have you seen anything like this?

Error is:

2011-12-20 13:20:39,931 -1302004848 Coreym 00000000-0000-0000-0000-000000000000 COREY-PAVILLION INFO Operations - Create

repository Hibber

2011-12-20 13:20:40,166 -1302004848 Coreym 00000000-0000-0000-0000-000000000000 COREY-PAVILLION ERROR x - Error in CreateD

b. internal gds software consistency check (cannot start thread)

at FirebirdSql.Data.FirebirdClient.FbConnection.CreateDatabase (System.String connectionString, Int32 pageSize, Boolean f

orcedWrites, Boolean overwrite) [0x00000] in <filename unknown>:0

at x.e (System.String A_0) [0x00000] in <filename unknown>:0

Also, I am wondering what your recommended db is (type and version) for production.

We definitely want to stick with Linux as our plastic server.

[manu]

Hi oceanfront,

from the firebird web page we can find this: http://www.firebirdfaq.org/faq226/

It seems that the database is not healthy. The article describes the possible causes.

There is a way to find out is the database is corrupted:

1) Check if you have the GBAK tool (installed with Firebird)

2) Create a backup: GBAK -user SYSDBA -password masterkey -b corrupt.fdb corrupt.fbk

3) Restore the backup: GBAK -user SYSDBA -password masterkey -C corrup.fbk restored.fdb

4) If the database is corrupt the command output will tell us the reason.

Way to fix it:

1) Check if you have the GFIX tool (installed with Firebird)

2) Run the command like this: GFIX -user SYSDBA -password masterkey -mend -full -ignore corrupt.fdb

3) Create a new backup: GBAK -user SYSDBA -password masterkey -IGNORE -b corrupt.fdb corrupt.fbk

4) Restore the backup as we did before, hopefully the database will be healthy.

Tell me if it works for you,

Manu.

[oceanfront]

Problem solved! Apparently, Firebird by default caches 2048 pages in memory per database, not per server.

Since we have 100+ repositories, this presented a problem on a 32 bit server.

So, we changed DefaultDbCachePages in firebird.conf, from 2048 to 512, as a temporary solution.

The permanent solution is to move to a 64 bit server, where we can address more than 3Gb of ram.

Note that the PAE kernel doesn't help much, since the 32 bit firebird binary still has only 3Gb max.

[manu]

Hi oceanfront!

Good to know it!

[manu]

... Since we have 100+ repositories, ...

You rock!