| Subject | Re: DROP table statement hangs Firebird Server process with 100% CPU usage |
|---|---|
| Author | |
| Post date | 2018-06-20T10:54:52Z |
---In firebird-support@yahoogroups.com, <greob@...> wrote :
This could be a reason for orphaned pages - when such error (bugcheck) happens, Firebird closes
> Please disregard my comment about the python code (it was wrong anyway, I don't use the "finally" clause, I only commit at the end of the entire loop). Mark Rotteveel > answered my question there: https://dba.stackexchange.com/questions/210010>> My database got corrupted in the past (for an unknown reason) and I thought gfix completely fixed the problem back then, but perhaps it did not, which is the reason why dropping a table is not working now.
gfix could automatically fix very limited number of errors and far not always. For example, it could fix orphan
pages - but only if there was no other errors found. This is not your case, obviously.
> Here is an excerpt from old logs around the time the DB got corrupted:
>
> hostname (Server) Fri May 11 15:54:27 2018
> Database: /home/firebird/my_db.fdb
> database file appears corrupt (/home/firebird/my_db.fdb)
> wrong page type
> page 305659 is of wrong type (expected 7, found 109)
> internal Firebird consistency check (error during savepoint backout (290), file: exe.cpp line: 4056)
all connections and not flushes page cache to disk. Fortunately, gfix not reported this error - it means
it was detected in memory only and not persisted on disk.
Stack trace you provided here shows that engine is inside drop table handler and walks some fragment
chain or blob to release data pages. I asked you to validate database to see if there is some kind of corruption
that make process endless (as you said that Firebird load CPU). Validation found no such errors - at least i
not see it in messages you show.
Probably, larger page cache could help to to drop that table faster.
Regards,
Vlad