Issue Details (XML | Word | Printable)

Key: CORE-4467
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Unassigned
Reporter: Ivan Arabadzhiev
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.
Firebird Core

MODIFY RDB$INDICES failed internal Firebird consistency check (CCH_precedence: block marked (212), file: cch.cpp line: 4390) ---> unsuccessful metadata update

Created: 20/Jun/14 05:06 PM   Updated: 23/Jun/14 08:22 AM
Component/s: Engine
Affects Version/s: 2.5.2 Update 1
Fix Version/s: None

Environment: Linux x64, 24GB RAM, i5-2400 CPU, SSD Corsair Force3, FB SC

 Description  « Hide
Recently (last month or so) started getting this error on a relatively big database (18 GB, personally I don`t have anything else even close).
Unfortunately, I cannot produce a test case. I have backup/restored the database a few times since the error started appearing and it produces no errors.

There are rarely more than 10-20 active connections to the database (some of the users have extra connections but they mostly perform small read-only transactions).

Under normal workload I have no issues, but there are times when some workstations need to do some relatively heavy synchronizations with the main database - At the time I get the error, there is at least one connection going through a few thousand records (updating them, possibly a few times each) - the transaction could take 5-20 minutes, depending on many factors. During that time, the other connections periodically try to insert/update records and (as expected) get a "lock time-out on wait transaction" when there is a conflict.

Looking at the logs from one of the station - it got the "block marked" error on each retry for about 15 minutes. After that work resumed normally.

I cannot yet say if it is related but the database has a trigger to maintain index statistics, which runs every 1000 records on one of the tables. (it is not new - it has existed since the creation of the database):


Apart from the database size - the environment has not changed much for the past few years. A few new indexes have been added to the mostly used tables due to performance issues with huge volumes.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 20/Jun/14 06:07 PM
At the moment, given the available details. This is a support issue which should be discussed/posted to the support mailing list ( Only if a specific issue is found which requires developer intervention is it appropriate for this case to be opened.