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.

 

Cheers,

Neil Pickles - [email protected]

 

From: [email protected] 
[mailto:[email protected]] 
Sent: 31 October 2015 17:58
To: [email protected]
Subject: Re: [firebird-support] High CPU use after restore

 

  

Hi


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

 

Jardar

 

On Thu, Oct 29, 2015 at 11:03 AM, Helen Borrie [email protected] 
[firebird-support] <[email protected]> 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?



 <mailto:[email protected]> 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.

Helen





 

-- 

Jardar Maatje

Nortek Data Services AS

C.J. Hambros Plass 2C

0164 Oslo

tlf: +47 95184034

 



Reply via email to