|Subject||RE: [firebird-support] High CPU use after restore|
When we restore databases following repair work, I have sometimes had indexes not reactivated where there is a broken reference. I am not sure how Firebird determines what is a terminal broken reference and what isn’t because usually when there is missing reference the restore just fails with an error.
Since we discovered this problem we now have a tool we wrote that checks all indexes and referential constraints are properly enabled before starting using the database.
Neil Pickles - neil@...
First of all thanks for help on the way. After a lot of work (and waiting for restore,backups indexing...) I found out that it actually was as simple as an index that was inactive. The index must have been disabled during my first backup/restore as I am sure I did not do this myself.
The index was a normal foreign key. However the table included a blob column.
Anyone that has an idea why this was disable during backup/restore?
Anyway one the results of this is that I know both have better understanding of firebird and also have better tools for dealing with situations where I need to take down the database.
A restore will rebuild all of the indexes. However, the indexes affected by the v.2.5.1 bug are those that are compound, i.e., multi-column, so they are the only ones you need to rebuild. A backup/restore will not be required.
If you have multi-column primary, foreign or unique key constraints, note that ALTER INDEX <index-name> INACTIVE will not work on a constraint index; but ALTER INDEX <index-name> ACTIVE will rebuild those anyway.
Do I need to say, do this job whilst you have exclusive access as an administrator of the database or as the owner of the affected tables.
Nortek Data Services AS
C.J. Hambros Plass 2C
tlf: +47 95184034