Subject | FB deadlock during big table indexing on Linux |
---|---|
Author | taliyev |
Post date | 2006-04-22T16:56:03Z |
We have huge database ( 30 GB) that seems to be working ok on
Windows. We need to port this database to Linux. Transportable
backup file is about 20GB in size. Biggest table is about 185
millions of records.
This backup file can be restored on the Windows server, but when we
try to restore it on the Linux box FB gets deadlocked when it needs
to activate indexes. We have managed to restore database without
index activation. Then we have activated indexes manually one by
one all but the indexes on the biggest table. Any attempt to
activate or drop and restore indexes on the 185 Mln. records table
cause either deadlock , if run through the script, or when we run it
interactively, then after a certain period of time we get an error
that FB cannot read from the temporary file in the temp directory
sort operation failed..
We have checked , and we have enough disk space on the Linux box.
Both Windows and Linux machines have similar hardware
configurations. Both have about 250GB SCSI disk space and 2GB of
memory.
The Linux box has no problem creating indexes on the smaller tables,
but the big one is a trouble. All indexes are based on the single
field with high number of values. Both machines have FB 1.5.3 in
Super Server configuration.
As I said before, this database works fine on the Windows server We
have tried to play with firebird.conf parameters, but none of our
ideas gave as any success in indexing of the big table on Linux..
If anybody has any suggestions, your help will be greatly
appreciated.
Windows. We need to port this database to Linux. Transportable
backup file is about 20GB in size. Biggest table is about 185
millions of records.
This backup file can be restored on the Windows server, but when we
try to restore it on the Linux box FB gets deadlocked when it needs
to activate indexes. We have managed to restore database without
index activation. Then we have activated indexes manually one by
one all but the indexes on the biggest table. Any attempt to
activate or drop and restore indexes on the 185 Mln. records table
cause either deadlock , if run through the script, or when we run it
interactively, then after a certain period of time we get an error
that FB cannot read from the temporary file in the temp directory
sort operation failed..
We have checked , and we have enough disk space on the Linux box.
Both Windows and Linux machines have similar hardware
configurations. Both have about 250GB SCSI disk space and 2GB of
memory.
The Linux box has no problem creating indexes on the smaller tables,
but the big one is a trouble. All indexes are based on the single
field with high number of values. Both machines have FB 1.5.3 in
Super Server configuration.
As I said before, this database works fine on the Windows server We
have tried to play with firebird.conf parameters, but none of our
ideas gave as any success in indexing of the big table on Linux..
If anybody has any suggestions, your help will be greatly
appreciated.