>
> 2.0.5 намекался, а не 2.1.х.
> Никаких трудностей в замене на работающей системе. Перерыв на 10 минут.
>
Спасибо за совет. Его и пробовали, именно 2.0.5. К сожалению,
неудачно. После нескольких часов нормальной работы, и действительно
положительного эффекта в плане производительности, происходит
непонятная вещь. Одна транзакция "залипает". Причем совершенно
обычная, никаких тяжелых запросов. gfix -sweep - эффекта не даёт. Если
сделать gfix -shut full -force, то последующий gfix -n выдает lock
conflict on no wait transaction, -database database_name shutdown.
Симулировал на ноутбуке, он нормально отрабатывает на этом "залипании"
deadlock. А из за этой транзакции сильно деградирует общая
функциональность всей системы, и долго сидеть и разбираться с этим на
рабочей системе никто не даст. Причем возврат на старую версию
подобных эффектов не даёт. Я, там, в соседнем треде в "истерике"
разных глупостей понаписывал :-). Хорошо, что уважаемый Dmitry
Yemanov, просветил, что поведение супера и классика в этом плане
идентичное.
Видимо будем собираться мыслями и делать апдейт через backup/restore.
Тут проблема только в том, что gbak -g -b 8 минут занимает, да потом
gbak -c минут 20. За это время успевает накопиться разница в
содержимом баз данных. Не то что бы критичная, но очень желательно
"чтобы восстановимая". Часть можно просто вернуть, повторно запустив
на обработку исходные данные, тогда как другую часть - проблематично.
Думаем написать приложение свое чтобы сделать синхронизацию обоих баз
перед переключением. Да и вроде припоминается, что есть нечто готовое
для репликации между базами под firebird, название только не помню.
Просто надо не спеша обкатать на стенде.
Хотя, что именно пошло не так, для меня до сих пор загадка.
