The right thing to do to avoid this kind of corruption is make diary backups and ensure you can restore them!
If you can't backup or not restore the entire database (including reactivating all foreign keys) you must stop immediately and try to fix the database. I think you ran this database corrupted for a long time or without a backup/restore for a long time. Fabiano. De: [email protected] [mailto:[email protected]] Em nome de Ann Harrison Enviada em: segunda-feira, 24 de fevereiro de 2014 17:58 Para: [email protected] Assunto: Re: [firebird-support] Wrong page type, how to examine/fix? Kjell, >>> >>> >>> >>>> On Feb 24, 2014, at 7:24 AM, Kjell Rilbe <[email protected] >>>> >>>> database file appears corrupt >>> (D:\DATADIA\DATA\FIREBIRD\BACKUP\DIAMONDS.FDB) >>>> -wrong page type >>>> -page 12301932 is of wrong type (expected 4, found 7) >>> Alas, not a great situation. Page type 4 is a pointer page - an array >>> of data page numbers that's one level of indirection in resolving >>> record locations. Page type 7 is ani index page. Fortunately, pointer >>> pages can be reconstructed from the rest of the database structure. I >>> think that the free version of IBFirstAid will tell you which table is >>> missing a pointer page. From there, the paid version should be able to >>> fix the problem. >> >> If the errors are located in a specific index (or unique constraint), >> would it be a good idea to drop that index/constraint and try a regular >> gbak backup/restore cycle? No, the indexes are fine in this case. If the error had been "expected 7 encountered n" then you might have been able to disable the index. But there's a doubly allocated page and the second allocation was as an index - before the page was released from the table. A pointer page doesn't contain data - just the page numbers of data pages. It's essential to the structure of the table and you can't drop the table with a missing pointer page. >> >> And if the errors are located in a table's data pages - drop the table >> and do gbak backup/restore? >> >> I did get an indication that it might be in a table I can recreate by >> other means... > > Tried to drop the entire table that I found has corruption, but as I > suspected it didn't work. Pity. :-) I also see there's no way to get > gbak to skip that table, which would probably have been useful. Or am I > wrong? > Back in the dark ages, I used to fix this sort of corruption by hand, but IBSurgeon has tools that will (I believe with high confidence) fix it automatically and in place. Logically, it's not very hard - just find the unreferenced data pages, put them in an array in the right order, put that array on an unused page, format the page as a pointer page and fix the RDB$PAGES table. Actually, it's a royal pain without a good tool. Check with Paul Beach at IBPhoenix for all the details. There's nothing you can do to fix the database without tools. However, if your application doesn't use the damaged table, you can keep running until you have time to fix the problem. And no, there won't be a reproducible case. And yes, you should be prepared to provide lots of details about version, environment, usage etc. The page allocation algorithms take a huge beating and have for years - new bugs in that area are rare and elusive. But, unfortunately, not beautiful - think coelacanth, not unicorn. Good luck, Ann >
