Hi,

I've got exactly the same kind of corruption with the port of FB 1.5.3.4870
I made for AIX 5.1 and >.
My super server works very well. However, I launched a little "stress"
program to check the robustness
of my port and then after a few hours of stress, my database becomes
corrupted. Mostly every time
I launch my stress test on a freshly created database, I've got a corruption
after about 30 minutes to
4 or 5 hours. I did my tests on a mono processor AIX box as well as multi
processors systems
(4 and 8 CPU), and the final result is always the same. The only difference
is that the corruption seems to
happen sooner on the multi processors systems.
Also notice that the corruption happen with small database (less than 200Mo).

First, I believed that the problem was specific to my AIX port, and was
probably due to the fact
that I could have forgotten to change sensitive stuffs in FB source code for
AIX... But I rechecked every
.H, .EPP and .CPP files; and I can't see any location where I could have
missed a #ifdef AIX ...
Now reading that you and other people also got corrupted databases on
plateforms that are well supported,
I'm pretty sure my problem is not AIX specific...
I'm in touch with Alex Peshkov for the AIX port and following is what I sent
to him concerning this database
corruption problem :


I have a little stress ODBC based client program that launches several
threads that do intensive insert, select, update, delete, and insert select
from in parallel on a small database that consist of 3 tables with a few
indexes.

Trying this stress program with my build of FB super server, after a few
hours, the database becomes corrupted.

For example, running gfix -user SYSDBA -password masterkey
/compile/stresspack/database/stressdb.dbf -validate -full,
I've got :
Summary of validation errors
Number of record level errors : 1
Number of index page errors : 3

For this example, running gbak on the corrupted database works and a restore
give me a valid database. What surprising me is that there is absolutely no
warning or error message in the firebird.log file when the database become
corrupted until I shutdown the database and try gfix / gbak on it. Following
is the contents of the firebird.log file after a gfix -shut -force 0. I feel
very strange the message "database ` shutdown" : what is this ` character ?
It makes me feel that the fbserver memory has been corrupted.

aix51 (Server) Wed Nov 29 11:55:01 2006
Database: /compile/stresspack/database/stressdb.dbf
database ` shutdown
internal gds software consistency check (error during savepoint backout
(290))

aix51 (Server) Wed Nov 29 12:00:56 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 1 is corrupt on page 182 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:00:56 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 2 is corrupt on page 190 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:00:56 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 3 has orphan child page at page 179 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:00:56 2006
Database: /compile/stresspack/database/stressdb.dbf
Relation has 2 orphan backversions (1406 in use) in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:01:45 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 1 is corrupt on page 182 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:01:45 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 2 is corrupt on page 190 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:01:45 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 3 has orphan child page at page 179 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:01:45 2006
Database: /compile/stresspack/database/stressdb.dbf
Relation has 2 orphan backversions (1406 in use) in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:02:12 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 1 is corrupt on page 182 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:02:12 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 2 is corrupt on page 190 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:02:12 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 3 has orphan child page at page 179 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:02:12 2006
Database: /compile/stresspack/database/stressdb.dbf
Relation has 2 orphan backversions (0 in use) in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:03:58 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 1 is corrupt on page 182 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:03:58 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 2 is corrupt on page 190 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:03:58 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 3 has orphan child page at page 179 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:03:58 2006
Database: /compile/stresspack/database/stressdb.dbf
Relation has 2 orphan backversions (0 in use) in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:33:07 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 1 is corrupt on page 182 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:33:07 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 2 is corrupt on page 190 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:33:07 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 3 has orphan child page at page 179 in table CONCUR (128)

aix51 (Server) Wed Nov 29 12:33:07 2006
Database: /compile/stresspack/database/stressdb.dbf
Relation has 2 orphan backversions (0 in use) in table CONCUR (128)

I've been able to get situations where the database is so corrupted that
gfix + gbak cannot repair the database ! Following are some messages from
gfix and gbak in such situations :

gfix -user SYSDBA -password masterkey
/compile/stresspack/database/stressdb.dbf -validate
Summary of validation errors
Number of index page errors : 23
Number of database page errors : 1

gfix -user SYSDBA -password masterkey
/compile/stresspack/database/stressdb.dbf -validate -full
Summary of validation errors
Number of index page errors : 73
Number of database page errors : 334



gbak -v -user SYSDBA -password masterkey
/compile/stresspack/database/stressdb.dbf
/compile/stresspack/database/stressdb.bak
gbak: readied database /compile/stresspack/database/stressdb.dbf for backup
gbak: creating file /compile/stresspack/database/stressdb.bak
gbak: starting transaction
gbak: database /compile/stresspack/database/stressdb.dbf has a page size of
4096 bytes.
gbak: writing domains
gbak: writing domain RDB$1
gbak: writing domain RDB$2
gbak: writing domain RDB$3
gbak: writing domain RDB$4
gbak: writing domain RDB$5
gbak: writing domain RDB$6
gbak: writing domain RDB$7
gbak: writing domain RDB$8
gbak: writing domain RDB$9
gbak: writing domain RDB$10
gbak: writing domain RDB$11
gbak: writing domain RDB$12
gbak: writing shadow files
gbak: writing tables
gbak: writing table CONCUR
gbak: writing column MYCOL4NAM
gbak: writing column MYCOL3NAM
gbak: writing column MYCOL2NAM
gbak: writing column MYCOL1NAM
gbak: writing table FOOBAR
gbak: writing column MYCOL4NAM
gbak: writing column MYCOL3NAM
gbak: writing column MYCOL2NAM
gbak: writing column MYCOL1NAM
gbak: writing table BACKUP
gbak: writing column MYCOL4NAM
gbak: writing column MYCOL3NAM
gbak: writing column MYCOL2NAM
gbak: writing column MYCOL1NAM
gbak: writing functions
gbak: writing types
gbak: writing filters
gbak: writing id generators
gbak: writing stored procedures
gbak: writing exceptions
gbak: writing Character Sets
gbak: writing Collations
gbak: writing data for table BACKUP
gbak: 20000 records written
gbak: 40000 records written
gbak: 60000 records written
gbak: 80000 records written
gbak: 100000 records written
gbak: 120000 records written
gbak: 140000 records written
gbak: 160000 records written
gbak: 180000 records written
gbak: 200000 records written
gbak: 220000 records written
gbak: 240000 records written
gbak: 260000 records written
gbak: 280000 records written
gbak: 300000 records written
gbak: 320000 records written
gbak: 340000 records written
gbak: 360000 records written
gbak: 380000 records written
gbak: 400000 records written
gbak: 420000 records written
gbak: 440000 records written
gbak: 460000 records written
gbak: 480000 records written
gbak: 500000 records written
gbak: 502379 records written
gbak: writing index FOO1
gbak: writing index FOO2
gbak: writing index FOO3
gbak: writing index FOO4
gbak: writing data for table FOOBAR
gbak: 335 records written
gbak: writing index IND1
gbak: writing index IND2
gbak: writing index IND3
gbak: writing index IND4
gbak: writing data for table CONCUR
gbak: ERROR: database file appears corrupt ()
gbak: ERROR: wrong page type
gbak: ERROR: page 12034 is of wrong type (expected 7, found 5)
gbak: ERROR: gds_$receive failed
gbak: Exiting before completion due to errors

and then I've got this kind of messages in firebird.log file :

aix51 (Server) Tue Nov 28 14:04:20 2006
Database: /compile/stresspack/database/stressdb.dbf
Page 12034 wrong type (expected 7 encountered 5)

aix51 (Server) Tue Nov 28 14:04:20 2006
Database: /compile/stresspack/database/stressdb.dbf
Index 4 is corrupt on page 12034 in table CONCUR (128)

aix51 (Server) Tue Nov 28 14:04:47 2006
Database: /compile/stresspack/database/stressdb.dbf
Page 9375 is an orphan


Ideas are very welcome.

Regards,

Toon.






"will.honor" <will.honor@...> wrote:
--- In firebird-support@yahoogroups.com, "jason"
<jasonthepolymath@...> wrote:

>
> I find large databases always corrupt, I think you need to devise
> some kind of archive process.
>
> Perhaps copy the .gdb away to archive.gdb and then run some sql
> commands to wipe out old data ?
>

This is an unacceptable approach here. All data is required at the
moment. In any case the DB is not that large. My biggest one is 5GB
and the smallest to go corrupt is only 1GB. Not huge by database
standards.

Regards,
Will.






---------------------------------
Access over 1 million songs - Yahoo! Music Unlimited.

[Non-text portions of this message have been removed]