|Subject||RE: causes for disabled indexes|
I also have that experience when restoring. But as you said only when there are problems in the underlying table. Like duplicate values in a column that has a unique index.
In that case i can only reenable the index when fixing the table. In the cases I’m talking about there are no obvious problems but the indexes are disabled nevertheless and can simply be reenabled.
Since I do not have that problem in a controlled environment I can’t say if my cases are also connected to restoring or not. I can say that in this case, if gbak would have left those indexes disabled it does not report it back via an errorcode.
I know from experience that a restore can sometimes leave indexes in a disabled state, and you would usually get an error when trying to activate it as it was left disabled during the restore phase due to a minor data issue. The errorlevel returned by GBAK is greater than 0 so you can detect when this has happened without having to check all the indexes.
We see this with our firebird databases on occasion, it’s preferable to the restore just failing and having to be run again without restoring indexes and manually identifying and dealing with the data issue then turning all the indexes back on again. It seems to be minor data issues that cause the index gets left disabled by GBAK, bigger issues and the restore will just stop with an error.
I’m using firebird embedded (2.5 and 3) in an on-premise solution. I get sometimes reports of slow behaviour and when checking those databases I can see that some or all indexes are disabled.
I can than simply enable those indexes and all seems well afterwards. Gfix does not find any problems and backup/restore works without a problem either then.
Are there some known causes that will result in disabled indexes without breaking the database otherwise?
The application itself doesn’t touch indexes directly they just get created at some point.