| Subject | FB 2.1.4 (vlad) crached (frozen fb_inet_server.exe and index corrupted) |
|---|---|
| Author | svanderclock |
| Post date | 2010-04-04T09:10:18Z |
Hello,
My server is again crached ! everthing on the server was frozen (all the fb_inet_server.exe was without any activity at all). no other choice than restart the server ! also some index was corrupted. this is a serious bug as it's appear regularly and especially we don't do anything extraordinary on our database !
when all the connection froze the activity was :
* FB 2.1.4 (vlad) classic server
* Windows 2008 R2 dedicated to firebird, 32 go of memory (10Go free
on the task manager).
* the database is around 20GO, paze size 8ko
* around 30 fb_inet_server connection. most of them doing only some select
* some index update intensive Insert/update SQLs was just (really just) committed (with success, the api return ok) when the server crash. around 2000 row was updated on some table with lot of index in it
* 28 hours before the crash, more than 12 000 000 row was deleted and inserted in somes tables with lot of index in it (same table as before).
* one process was doing for more than severals hours a sweep of the database
* in the firebird.log i have read :
Sun Apr 04 06:20:59 2010
BTR_remove: root page gc not allowed
IE: the server crach at Sun Apr 04 07:50:20 2010
* fb_lock_print -a gave me a file of 20mo, below just the header
LOCK_HEADER BLOCK
Version: 144, Active owner: 0, Length: 134217728, Used: 7962104
Semmask: 0x0, Flags: 0x0001
Enqs: 1115858718, Converts: 13984493, Rejects: 3435435, Blocks: 21324196
Deadlock scans: 1347, Deadlocks: 0, Scan interval: 10
Acquires: 1419387432, Acquire blocks: 35824257, Spin count: 0
Mutex wait: 2.5%
Hash slots: 2039, Hash lengths (min/avg/max): 2/ 10/ 29
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (40): forward: 29080, backward: 821664
Free owners (33): forward: 2387208, backward: 2467096
Free locks (25572): forward: 5025208, backward: 5036024
Free requests (40500): forward: 3279720, backward: 3624720
Lock Ordering: Enabled
* gfix run for more than one hours and gave me this result :
Summary of validation errors
Number of index page errors : 27
this bug is very serious and appear randomly but regurlary ! 2 days ago (before to do the massive isert/update) i do a gfix on the database and it's show that everything was clean. so it's seam that doing a lot of insert / update on some table that have lot of row and lot of index (a live database with have lot of select too) finnaly corrupt the index ! i don't know if it's also connected with the sweep that was performed at the same time...
thanks by advance for all your comments !
stephane
My server is again crached ! everthing on the server was frozen (all the fb_inet_server.exe was without any activity at all). no other choice than restart the server ! also some index was corrupted. this is a serious bug as it's appear regularly and especially we don't do anything extraordinary on our database !
when all the connection froze the activity was :
* FB 2.1.4 (vlad) classic server
* Windows 2008 R2 dedicated to firebird, 32 go of memory (10Go free
on the task manager).
* the database is around 20GO, paze size 8ko
* around 30 fb_inet_server connection. most of them doing only some select
* some index update intensive Insert/update SQLs was just (really just) committed (with success, the api return ok) when the server crash. around 2000 row was updated on some table with lot of index in it
* 28 hours before the crash, more than 12 000 000 row was deleted and inserted in somes tables with lot of index in it (same table as before).
* one process was doing for more than severals hours a sweep of the database
* in the firebird.log i have read :
Sun Apr 04 06:20:59 2010
BTR_remove: root page gc not allowed
IE: the server crach at Sun Apr 04 07:50:20 2010
* fb_lock_print -a gave me a file of 20mo, below just the header
LOCK_HEADER BLOCK
Version: 144, Active owner: 0, Length: 134217728, Used: 7962104
Semmask: 0x0, Flags: 0x0001
Enqs: 1115858718, Converts: 13984493, Rejects: 3435435, Blocks: 21324196
Deadlock scans: 1347, Deadlocks: 0, Scan interval: 10
Acquires: 1419387432, Acquire blocks: 35824257, Spin count: 0
Mutex wait: 2.5%
Hash slots: 2039, Hash lengths (min/avg/max): 2/ 10/ 29
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (40): forward: 29080, backward: 821664
Free owners (33): forward: 2387208, backward: 2467096
Free locks (25572): forward: 5025208, backward: 5036024
Free requests (40500): forward: 3279720, backward: 3624720
Lock Ordering: Enabled
* gfix run for more than one hours and gave me this result :
Summary of validation errors
Number of index page errors : 27
this bug is very serious and appear randomly but regurlary ! 2 days ago (before to do the massive isert/update) i do a gfix on the database and it's show that everything was clean. so it's seam that doing a lot of insert / update on some table that have lot of row and lot of index (a live database with have lot of select too) finnaly corrupt the index ! i don't know if it's also connected with the sweep that was performed at the same time...
thanks by advance for all your comments !
stephane