kdv, спасибо. Передам админам - пусть "курят"

Проблема не решилась

Версия 2.1.7
Восстановил из бекапа базу
Минут через 20 та же проблема - при попытке подключиться начинает писать, что сервер не отвечает. На сервере 100500 процессов серверов.
У админов сработал автомат (не успел их предупредить) и они рубанули процессы и перегрузили службу ФБ
В результате та же ошибка с нулевой страницей.

Запустил восстановление. Куда смотреть, почему начинает "подвисать" БД и новые подключения отвергаются сервером?


UPD: есть отчеты, которые запускают за месяц и они формируются очень долго. не может ли там быть какая-то блокировка, которая "вешает" сервер.
Эта проблема началась вчера. В 22:00 была запущена база и всю ночь работала нормально - ночные смены работают по производству.
Но утром, когда подключился "офис", то в районе 10 утра все опять "зависло". Может офисные запросы на конец месяца (отчеты за июль, расчеты и т.п.) загружают сервер настолько, что админские системы распознают ее как "умершую" и убивают процессы. Что приводит к нарушение целостности БД?
Может где-то в конфиге можно настроить менее "эгоистичное" поведение для подключений?

Симонов Денис, что такое FW? (простите за глупые вопросы - я полный нуб в этом всем)

В log-файле перед "зависанием" появились вот такие записи:

"internal gds software consistency check (page in use during flush (210), file: cch.cpp line: 2975)"

и еще вот такая:

"page 1465957, page type 4 lock conversion denied (215)"

Симонов Денис,


Database "d:\MAINBASE.FDB"
Database header page information:
Flags 0
Checksum 12345
Generation 4758
Page size 16384
ODS version 11.1
Oldest transaction 3272
Oldest active 3273
Oldest snapshot 3273
Next transaction 4685
Bumped transaction 1
Sequence number 0
Next attachment ID 66
Implementation ID 16
Shadow count 0
Page buffers 2048
Next header page 0
Database dialect 1
Creation date Aug 5, 2020 15:32:49

Variable header data:
Sweep interval: 0
*END*

Симонов Денис, как эту опцию включить? на что она повлияет кроме "надежности" отключения базы на лету?

Ну и все-таки остается вопрос - нет ли возможности как-то улучшить многопользовательский режим? Несколько десятков одновременных подключений - есть автозадания, которые собирают отчеты по производственному циклу и рассылает на ключевых специалистов. Некоторые отчеты "дорогие" в плане ресурсов.

Ivan_Pisarevsky, вполне возможно, что там могут быть частые вставки и удаления (код очень "мудреный" с вложенностью больше 5 уровней вызовов хранимок). Если поставить принудительный сбор мусора - может помочь?

Basil A. Sidorov, данная опция сказывается на "скорострельности" при частых вставках?

Спасибо всем за помощь и участие

1. Выношу копию для "тяжелых" отчетов (проблема будет в обучении пользователей, чтобы они не забывали переходить)
2. Напрягаю админов по железу
3. Наверное, почищу немного базу, чтобы убрать старые записи, которые точно уже использоваться в оперативной работе не будут (база 2018 года была 21 гиг) - это может сказаться на скорости выполнения запросов