1

I am running several different Firebird versions (2.0, 2.1) on multiple entry level Windows-based servers with wildly varying hardware. The only matching thing between them is that they are running same home built application with the same database structure.

Lately I've been seeing massive slowdowns on multiple servers. Turns out that database gets corrupted, so each time it breaks, I get to mend, backup and restore the database, and it all is fine for some time (1-2 weeks), and then it repeats once again. Thankfully, I haven't seen any data loss or damage... yet. The thing is that every such downtime results in lost productivity, and often quite some driving for me as some of the databases are in remote locations.

I've been trying to find out what's causing the corruption, but I haven't been able to. The fact that it's running on different hardware hints that it should not be a hardware based problem.

If we rule out hardware issues, I have a bad feeling that it's a bug in Firebird as I'm not doing anything fancy via SQL. Do you have any idea how to find out exactly what's causing the corruption and hopefully fix the problem?

[edit] According to first reply: I get several different problems in firebird.log:

INET/inet_error: read errno = 10054
INET/inet_error: select in packet_receive errno = 10038
Relation has 12 orphan backversions (5 in use) in table LIMITAI (139)
Index 1 is corrupt on page 61700 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1659 (repeats for multiple pages and index numbers)
Page 50801 is an orphan (repeats for multiple pages)

2 Answers 2

3

Check firebird.log. It may contain important information on what's going wrong.
Check how your application handles transactions. Firebird does not like long-running transactions. They result is slowdowns and ultimately (depending on load, etc) server crashes .

For the performance issues I recommend Sinática Monitor.

hth

3
  • Seems like indexes get trashed - when I backup and restore they get rebuilt, so no data loss is suffered. Can it be that because of network issues a running transaction stays in limbo and then slowness and corruption results later on?
    – Rytis
    May 28, 2010 at 9:56
  • 1
    Turns out I really have some stuck transactions. Thanks for the link to Sinatica!
    – Rytis
    May 28, 2010 at 10:08
  • 1
    About transactions being pending because of network issues: It's more likely to happen in Classic Server. Even then it would take at most a couple of hours before the engine detects this and kill the transaction. May 28, 2010 at 11:57
0

Check your servers against following list:

  1. The latest Firebird version is installed
  2. Forced writes mode for database is ON
  3. NTFS file system is used
  4. System has an UPS (if no -- turn off HDDs write cache)
  5. Hardware is reliable (no system hung because of bad memory, no bad sectors etc.)
  6. Usage of RAID with protected memory cache is recomended

Following these simply rules we have servers which runs for years without any incedents.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .