| Subject | Re: [firebird-support] Re: HELP!! Database corrupted |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-08-14T02:46:20Z |
At 11:30 AM 14/08/2009, you wrote:
And when Carlos directed you to the best-known tools for recovering corrupt data, you countered that you weren't interested in anything you might have to pay for.
For your future reference, the database engine reports a consistency check error when it encounters any situation where it cannot make sense of the current state of a database and its associated dynamic structures. If possible, it will try to provide clues about the problem (in this case, the transaction inventory page, or TIP, was lost.). That happened because something in your environment corrupted or blocked that structure (in memory or on disk) and the engine could not proceed with its operation. At that point, the database was probably still OK, although not in a state where existing or new connections could function.
Possible hostile external conditions include bad RAM, disk errors, arbitrary locking by an external program such as anti-virus or file backup, even someone trying to file-copy the database while it had attachments. Allowing the host machine to get into a state where memory and/or disk resources are marginal might also give rise to such conditions. There is no magic wand for finding out: it is up to you to discover for yourself who was doing what to what and why - and to prevent it happening again, of course.
The gfix tools are there for solving some (but certainly not all) the problems that might be left behind from such hostile events. However, because gfix -mend actually changes the data in a database, it can be a weapon of mass destruction if used in the wrong conditions: you have a good chance of aggravating a minor (or temporary) condition, as happened to you.
Another time, if you decide to try to use the gfix tools, it would be a really good idea to use them properly and with the proper safeguards taken. You can study this subject in detail in this article:
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_db_corr
(available in English and Portuguese).
For now, your primary concern should be to find out what was happening on that machine at the point where the first consistency check occurred -- be it hardware faults, unwise system or software operations or whatever. With luck, there will be a timestamped entry in firebird.log.
./heLen
>Nobody answered my questions and I noticed that there are very few messages in the forum. Is there any problem I don´t know?Your attitude, perhaps?
>I would really like to know the opinion of those who know much more than I about my questions because I want to know what is the best thing to do.Really? But when Vlad (who is a Firebird core developer) pointed out your misplaced assumption about a bug in gfix, you seemed to argue that you knew better than he does.
And when Carlos directed you to the best-known tools for recovering corrupt data, you countered that you weren't interested in anything you might have to pay for.
For your future reference, the database engine reports a consistency check error when it encounters any situation where it cannot make sense of the current state of a database and its associated dynamic structures. If possible, it will try to provide clues about the problem (in this case, the transaction inventory page, or TIP, was lost.). That happened because something in your environment corrupted or blocked that structure (in memory or on disk) and the engine could not proceed with its operation. At that point, the database was probably still OK, although not in a state where existing or new connections could function.
Possible hostile external conditions include bad RAM, disk errors, arbitrary locking by an external program such as anti-virus or file backup, even someone trying to file-copy the database while it had attachments. Allowing the host machine to get into a state where memory and/or disk resources are marginal might also give rise to such conditions. There is no magic wand for finding out: it is up to you to discover for yourself who was doing what to what and why - and to prevent it happening again, of course.
The gfix tools are there for solving some (but certainly not all) the problems that might be left behind from such hostile events. However, because gfix -mend actually changes the data in a database, it can be a weapon of mass destruction if used in the wrong conditions: you have a good chance of aggravating a minor (or temporary) condition, as happened to you.
Another time, if you decide to try to use the gfix tools, it would be a really good idea to use them properly and with the proper safeguards taken. You can study this subject in detail in this article:
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_db_corr
(available in English and Portuguese).
For now, your primary concern should be to find out what was happening on that machine at the point where the first consistency check occurred -- be it hardware faults, unwise system or software operations or whatever. With luck, there will be a timestamped entry in firebird.log.
./heLen