| Subject | Corruption, was Re: fbclient.dll_unloaded => BEX Exception |
|---|---|
| Author | svanderclock |
| Post date | 2009-11-21T09:31:21Z |
Dear helene,
1/ gfix -v -f => ok i receive error report
2/ gfix -m -i => receive error report
3/ again gfix -v -f => ok i receive error report
4/ backup the data => OK
5/ restore the data => OK with error : some foreign key are not active because of foreign key violation
6/ ISQL => locate and delete all the data in error (only one record in the master database missing, so i delete all the record connected to this reccord)
7/ activate the foreign key
8/ backup the data
9/ restore the data => OK
10/ run gfix -v -f => OK
now everything seam to work weel ... did i forget something ? now can i m be sure now that the integrity of the database is OK? all the corruption is really go away ?
gfix -write sync database.gdb
because in fact the probleme is not only power lost, but it's can also be server crash ! if the FB_inet crash (like out of memory) then if data are not flush the database can be corrupted (i thing it's what happen to me). in fact sometime the fb_inet simply "hang" accepting incomming connection but not answer to them (making the client freezing) ... why ? i don't really know... at the beginning i was thing the the probleme was on the client side, but now i m not sure anymore. As it is an web app, more and more connection arrive and are "trap" like this... stil no more memory availale on the server (monday i will buy 64GO) ... killing the client not change anything and the only way i found was to restart the server ! after you know the story ....
stephane
>hmmm. finally i do like this:
> > if yes what about the foreign key ?
>
> At this point, this is probably not your biggest concern. I hope >that, if you ran gfix -mend, you were working on a file copy of the >database file. If you were working on your only copy, it is likely >now that you will need to call in the IBSurgeon guys to try to >recover your surviving data into a new database. As an initial >step, you can download their free corruption analysis tool >IBFirstAid Diagnostician. From that tool you can get a log that you >can send to them so that they can give you an estimate of what the >recovery would cost.
1/ gfix -v -f => ok i receive error report
2/ gfix -m -i => receive error report
3/ again gfix -v -f => ok i receive error report
4/ backup the data => OK
5/ restore the data => OK with error : some foreign key are not active because of foreign key violation
6/ ISQL => locate and delete all the data in error (only one record in the master database missing, so i delete all the record connected to this reccord)
7/ activate the foreign key
8/ backup the data
9/ restore the data => OK
10/ run gfix -v -f => OK
now everything seam to work weel ... did i forget something ? now can i m be sure now that the integrity of the database is OK? all the corruption is really go away ?
>yes thanks for the link. the first think i do is :
> We have an expression in English - "shutting the stable door after >the horse has bolted". In the hope that this is not such a case, >please study this paper, which shows at least how important it is to >do the right things, in the right order, and only on a COPY of your >database:
>
> http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_db_corr
gfix -write sync database.gdb
because in fact the probleme is not only power lost, but it's can also be server crash ! if the FB_inet crash (like out of memory) then if data are not flush the database can be corrupted (i thing it's what happen to me). in fact sometime the fb_inet simply "hang" accepting incomming connection but not answer to them (making the client freezing) ... why ? i don't really know... at the beginning i was thing the the probleme was on the client side, but now i m not sure anymore. As it is an web app, more and more connection arrive and are "trap" like this... stil no more memory availale on the server (monday i will buy 64GO) ... killing the client not change anything and the only way i found was to restart the server ! after you know the story ....
stephane