Database Integrity Check Failed

Posted on by Alan

A quick tip for Firepower when you have a database error.  This has mostly come up when I’m trying to get fancy with the delete_rules.pl script. My advice to you is just don’t. When TAC or the Cisco documentation says that deleting custom Snort rules is an all or nothing proposition, believe it.

Every once in a while you’ll get a database error that will cause an operation to fail. In my case, it’s the scheduled backup. The web page doesn’t give you a lot go to on at first glance, but under your schedule, it should tell you more at the bottom of the calendar.

If you ssh in and run DBCheck.pl, you’ll see something like this:

[Tue Feb  5 13:15:50 2019][FATAL]  [missing eo reference]    database [sybase],table [rule_header] column [uuid], uuid [fcd5fc7a-2889-11e9-ab40-b1c5df20061d],rev_uuid [NULL]

indicating a bad database entry for a snort rule.
This is easily fixed by typing
OmniQuery.pl -db sdb -e “delete from rule_header where uuid =’fcd5fc7a-2889-11e9-ab40-b1c5df20061d’;”
Pay close attention to the table (rule_header in this case). I’ve also seen EOPermissions, EORevisionStore, and EOContainerStore (or all 4).
TAC also likes to suggest the “slow repair,”
for i in `ls -1|egrep -v “.BAK$”|sed ‘s/….$//’|sort|uniq`; do repair_table.pl -frames $i;done 
but I’ve never had that actually fix anything. Note here that you have to actually be in /var/lib/mysql/sfsnort for this to actually do anything despite TAC’s insistence that it can be run from anywhere in the file system.