Below is the description of common errors and problems with InterBase/Firebird databases with approximate period of time to fix them. Our statistics allows us to assert that we can save your data within a reasonable period.
This can help you to estimate the price of our services.
Please note, that we are always ready to allow a discount for very big and time-consuming repairing actions. About our pricing see .
All the reasons for errors below are approximate and taken from our practice. We are sure on 70% that the mentioned errors correspond to the reasons and require the indicated period of time for repairing:
Estimation of time to fix common corruptions
-
Internal gds software consistency check (cannot find tip page (165))
Database cannot be opened using engine and provide the following message: Internal gds software consistency check (cannot find tip page (165))
After physical database file corruption the transaction inventory page has been lost (TIP).
Analysis of lost data pages, generation of new pages of transaction calculation instead of the lost ones, database check and test backup/restore.
2 hour and more
99%
-
Database file appears corrupt. Wrong page type. Page NNN is of wrongtype (expected X, found Y)
Error message appeared in standard output or in interbase.log: Database file appears corrupt. Wrong page type. Page NNN is of wrong type (expected X, found Y)
After physical corruption the sequence of database file pages has been changed or there appear wrong values on pointer pages or index root pages, etc.
Analysis of sequence of pages in the database, correction of incorrect links in the sequence, possible regeneration of corrupted pages and generation of new ones. Then data checking by gfix and final backup/restore.
4-6 hours
50-100%.
-
Unknown database I/O error for file "*.gdb". Error while trying to read from file
Database cannot be open and the following error message appears: Unknown database I/O error for file "*.gdb". Error while trying to read from file.
After emergency breakdown of power supply or abnormal server crash several last file database pages are not written to the disk and later the server cannot create the internal database image and open it.
Getting of lost references to pages, their types and number by non-corrupted pages. Generation of new pages instead of the lost ones. Database check by gfix and control backup/restore.
3-5 hours
80%-95%
-
Decompression overran buffer
Error message appears: Internal gds software consistency check (decompression overran buffer (179))
It is a serious database corruption and system tables can be damaged. Sometimes this error occurs after database transfer from one operation system to another through the file copy. It is necessary to study each case.
Analysis of database links, generation of new pages, iteration repairing.
3 hours and more
80%-90%
Error message appears: Internal gds software consistency check. Wrong record length
Some records are corrupted. It may be records from user tables or from system tables. If records are corrupted in system tables, chances are less than in user's.
Usually it is possible to locate wrong records and delete them. Analysis of database, cutting wrong links, iteration repairing.
3 hours and more
60%-90%
-
Database file appears corrupt. Bad checksum
Database file appears corrupt. Bad checksum. Checksum error on database page XX.
Caused by physical corruption. Depending on the page number the case can be either similar to problem 2 or very complex.
Analysis of the problem page depending on its type and then restore of lost links
3 hours and more
99%
-
Cannot find record back version
Database seems to be working, but gbak cannot make backup and gfix does not help this. The error is like: Internal gds software consistency check (cannot find record back version (291)) gds_$receive failed. Exiting before completion due to errors. internal gds software consistency check (can't continue after bug check).
It is a serious corruption and it is very difficult to find its cause. It can be corrupted with physical database corruption, server code errors and rare combinations of metadata structures.
The database requires thorough analysis, and usually the solution is to find and delete problem database objects and then recreate them. Sometimes it is necessary to transfer data to a new database
4 hours and more
85%-99%
-
Next transaction older than oldest active transaction
Internal gds software consistency check (next transaction older than oldest active transaction (266))
Such error occurs only on servers InterBase 4.x-5.x because of the corruption of the header page.
Usually it is necessary to set appropriate transaction parameters on the header page. Transaction numbers are counted after analyzing records on the data pages.
2-3 hours
99,99%
-
Corrupted header page (at least)
Database (of size less than 4Gb) cannot be opened and InterBase does not consider it as a database and IBSurgeon 1.0 beta 2 cannot open it. IBSurgeon 1.0.2 after opening it asks to set page size manually.
At least the header page is corrupted, and this case needs thorough investigation
Regeneration of the database system pages on the basis of its remaining part. This process is very difficult and nobody can be sure it will be 100% a success.
4 hours and more
100%
-
Database file size exceed implementation limit
The database size is 4Gb, and on InterBase 4.x-5.x-6.0.x, and early Firebird 0.9.x versions the database cannot open. The server does not try to open it as is does not see it is as correct.
Implementation limit of InterBase 4.x-5.x-6.0.x, and early Firebird 0.9.x.
Recovery consists in generation of new system pages after analyzing the structure of the rest part of the database and also manual correction of page links. This iteration process is very long but it is usually successful as most often database corruptions occupy only a small area.
6 hours and more
Usually we can save all data (i.e., 100%).
-
Conversion error from string
During database restore there appear errors like Conversion error from string "XXX".
The error might be connected either with erroneous NULL's appearing in NOT NULL fields and backup file corruptions, etc. Each time it is necessary to investigate the database in order to find the problem. Preliminary diagnosis is impossible.
Analysis of the database data in order to see lost pages and transfer the data to a new database to find problem places. This process is iteration and tiresome.
5 hours and more
80%
-
INET/inet_error: read errno = 10054 or 10038 or 10093
Multiple entries in interbase.log with errors 10054, 10038, 10093, etc.
These errors caused by network problems - check your hubs, network adapters, etc. It is not an InterBase error itself, but it may impact InterBase.
In this case it will be technical support, not recovery process. If you have problems and cannot solve this problem, you can request our technical support service.
4 hours and more
100%
-
Partner index description not found (175))
Error messages appears: internal gds software consistency check (partner index description not found (175))
Missed index for primary or foreign key. It may be caused by physical corruption or internal server bugs.
In order to find missed index you should perform the following SELECT statement:
select R.RDB$CONSTRAINT_NAME, R.RDB$INDEX_NAME as REFINDEXNAME, I.RDB$INDEX_NAME as REALINDEX, I.RDB$RELATION_NAME, I.RDB$INDEX_INACTIVE
from RDB$INDICES I RIGHT JOIN RDB$RELATION_CONSTRAINTS R on I.RDB$INDEX_NAME = R.RDB$INDEX_NAME
where R.RDB$CONSTRAINT_TYPE = 'FOREIGN KEY' or R.RDB$CONSTRAINT_TYPE = 'PRIMARY KEY'
order by R.RDB$CONSTRAINT_NAME
Contraint without index (where column REALINDEX will be empty) will be corrupted. Try to recreate this constraint.
If you need help to solve this problem, you may request our technical support service.
Time
2 hours and more
100%
Below some InterBase errors are listed which may be caused by different reasons. Do not hesitate to send us description of your problem - we can help you.
Wrong UDF may cause the following errors in interbase.log:
SCH_validate -- not entered
SCH_validate -- wrong thread
Index corruption may cause the following message in interbase.log:
Page 34672 is an orphan
And this error can occur during intensive inserts/update/delete during the single transaction:
internal gds software consistency check (Too many savepoints (287))
It is hard to recognize the reason without investigation of database in case of the following errors:
internal gds software consistency check (error during savepoint backout (290))
internal gds Software consistency check (size of opt block exceeded (286))
internal gds software consistency check (invalid SEND request (167))
Different reasons. We need to investigate corrupted database.
Individual.
2 hours and more
50-100%
| 
