1. Firebird Wrong Page Type Fix

IBSurgeon FirstAidFirstAID is the only solution for automatically repairing corruption that neither gbak nor gfix can handle. FirstAID uses its own layer for low-level database access without using the InterBase or Firebird engine, so it can perform real 'surgical' operations and repair your database when all other standard mechanism's cannot.Using FirstAID together with other standard recovery means such as the default gfix and gbak utilities it is possible to repair a corrupted database in more than 80% of all cases.IBSurgeon has a free Diagnostic version of FirstAID which you can use to accurately check the actual database status. It will analyze the low-level data structures in your database and present you with a detailed log of what may be wrong in the database.

Open the corrupted database with FirstAID Extractor and then double click on the table name, you can browse through the table's data pages. If you decide to recover the data you see in the FirstAID Extractor, you can purchase a license. What you see is what you will recover with the FirstAID Extractor. Make sure to read 'FirstAID (Firebird and InterBase) before attempting recovery.If you want to you can send the diagnostic log to our support service for a free answer on whether your database is recoverable or not, whether its recoverable by IBFirstAid directly, whether you need to use he Extractor or whether we need to perform some manual work to assist the recovery process. We will also try and estimate how much of the your data can be recovered if there really is a serious problem that will not allow 100% recovery.FirstAID is a tool that can automatically diagnose and repair corrupted Firebird or InterBase databases.Two versions of FirstAID are available, one as a free download:There is a free version that allows you to diagnose potential problems with your database and there is also a commercial version that allows you to fix the problems that are found. The diagnostic features allow you to check a database's validity.

Whilst the fully featured version is capable of fixing a number of common database corruption problems.FirstAID uses its own database access layer to connect to analyze and repair a Firebird or InterBase database.There are a large number of possible corruptions that FirstAID has been designed to repair and correct. Some of these are listed below:.Internal gds software consistency check (cannot find tip page (165))The required Transaction Inventory Page is corrupt and the database cannot be opened. It is expected in this instance that neither gbak nor gfix will be able to repair your database (except in the case of a Read Only database). IBFirstAID will repair the missing pages and recover the database.Unknown database I/O error for file '.gdb'Error while trying to read from the database file. This usually indicates that a number of database pages have probably been lost at the end of the database file (power failure?).

In this instance the database cannot be opened. Gfix cannot repair this. FirstAID will recreate the missing system pages and deletes the wrong pointers.Database file appears corrupt.

Wrong page type. Page NNN is of wrong type (expected X, found Y)This error can indicate a number of problems. But typically there are missing pages in the database, or the page that is being accessed is not the expected page type. For example, if the expected page type is 5, it can mean that some data may have been corrupted within a table. Such a corruption may prevent a sucessful backup backup or may make the table unavailable to the database.FirstAID fixes the wrong page pointers and repairs the database.Wrong record length. Cannot find backversion.FirstAID will check every record in database and will try and repair these record-level errors.Other database corruptions can be caused by lost pages.

Tux././blank2.fdb -p 148FBDUMP 1.00 - Firebird Page Dump UtilityDATABASE PAGE DETAILS - Page 148Page Type: 9PAGE DATASequence: 0Waste1: 0Waste2: 0Waste3: 0Waste4: 0Waste5: 0There are 9 sequences defined:Sequence00000: 9Sequence00001: 0Sequence00002: 3Sequence00003: 0Sequence00004: 0Sequence00005: 0Sequence00006: 0Sequence00007: 0Sequence00008: 0Sequence00009: 0The system table holds the defined sequence details but no values for each one. It does have an RDB$GENERATORID column and this starts from 1, not zero. And increments by 1 for each new sequence. Where does this number come from?Looking in the blank database we created, we can see that there are 9 sequences created for system use. SQL SELECT RDB$GENERATORID, RDB$GENERATORNAMECON FROM RDB$GENERATORSCON ORDER BY RDB$GENERATORID;RDB$GENERATORID RDB$GENERATORNAME 1 RDB$SECURITYCLASS2 SQL$DEFAULT3 RDB$PROCEDURES4 RDB$EXCEPTIONS5 RDB$CONSTRAINTNAME6 RDB$FIELDNAME7 RDB$INDEXNAME8 RDB$TRIGGERNAME9 RDB$BACKUPHISTORYThis is a clue, take a look at Sequence00000, above, and see that it contains the value 9.

I suspect therefore, that the very first sequence is used to generate the RDB$GENERATORID value when a new sequence is created. One way to find out is to create a new sequence.

Tux./fbdump./blank2.fdb -p 148FBDUMP 1.00 - Firebird Page Dump UtilityDATABASE PAGE DETAILS - Page 148Page Type: 9PAGE DATA.There are 10 sequences defined:Sequence00000: 10Sequence00001: 0Sequence00002: 3Sequence00003: 0Sequence00004: 0Sequence00005: 0Sequence00006: 0Sequence00007: 0Sequence00008: 0Sequence00009: 0Sequence00010: 666We can see that Sequence00010, that a new sequence has been created. The value in this sequence is 666 in decimal. In addition, we can see that Sequence00000 has increased to 10. So it looks remarkably like the RDB$GENERATORID is itself obtained from a sequence that never appears in RDB$GENERATORS.The value, stored in Sequencen, appears to be the last value that was used and not the next value to be issued.

It is also the total number of sequences that have been created thus far in the database, provided, that the value in is zero.I wonder what happens when we drop a sequence? Tux./fbdump./blank2.fdb -p 148FBDUMP 1.00 - Firebird Page Dump UtilityDATABASE PAGE DETAILS - Page 148Page Type: 9PAGE DATA.There are 10 sequences defined:Sequence00000: 10Sequence00001: 0Sequence00002: 3Sequence00003: 0Sequence00004: 0Sequence00005: 0Sequence00006: 0Sequence00007: 0Sequence00008: 0Sequence00009: 0Sequence00010: 666The generator page has not changed. Sequence00010 still remains at it's previous value - 666 - but this 64 bits of database page representing our recently dropped sequence can never be used again. It has ceased to be a sequence and has become wasted space.Given that RDB$GENERATORID is itself generated from Sequence00000 and cannot therefore reuse any allocated RDB$GENERATORID, it is not surprising that the simplest way of handling a dropped sequence is simply to ignore it.If you are creating and dropping sequences frequently, you may end up with a lot of unused sequences.

Firebird Wrong Page Type Fix

You can restore these to a usable state by dumping and restoring the database. Tux # Shutdown & backup the database.tux -shut -tran 60./blank2.fdbtux -backup./blank2.fdb./blank2.fbktux # Replace (!) and restart the database.tux gbak -replace./blank2.fbk./blank2.fdbWarning: The above will cause the loss of the database if anything goes wrong. The commands used overwrite the blank 2.fdb database from the dumpfile.