Subject Re: [firebird-support] High CPU use after restore
Author Jardar Maatje

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.

Best regards


On Thu, Oct 29, 2015 at 11:03 AM, Helen Borrie helebor@... [firebird-support] <> wrote:

Hello Jardar,

Thursday, October 29, 2015, 9:55:20 PM, you wrote:

The comment about "at least rebuild indexes" does that mean that I can expect this to work or do I risk that I still need to backup/restore?

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.


Jardar Maatje
Nortek Data Services AS
C.J. Hambros Plass 2C
0164 Oslo
tlf: +47 95184034