Это опять мы со своей мега базой. Предыдущая серия закончилась на том, что мы перешли с супер сервера на классик. Версия ФБ 3.0.5.33172. Прекратились рандомные повреждения БД с частотой где-то раз в два месяца. Но, теперь напоролись на другую неприятную вещь.

Дано,

1) размер БД сразу после восстановления 290 Гб, в процессе работы размер файла 340 Гб
2) 256 одновременных подключений

Проблема:

Один из запросов перестал выполняться. Запрос простой, выборка из одной таблицы с джоином на нее же. На копии базы этот запрос выполняется за несколько секунд. На рабочей базе он запускается и висит часами без ответа. Если запустить несколько таких запросов, то они все зависнут. Причем другие запросы, в том числе и включающие в выборку данную таблицу, выполняются. Только медленнее. Изучение монитора ресурсов операционной системы показывает наличие нескольких процессов фб, которые непрерывно что-то пишут на диск со скоростью 0.5-2.5 МБ/сек.

В логе файреберда нет ничего, кроме нескольких ошибок 10054, обрыв сетевого соединения. К этим запросам они не относятся, т.к. идут с других машин.


Header page:

Database header page information:
Flags 0
Generation 409227000
System Change Number 1881
Page size 8192
ODS version 12.0
Oldest transaction 405174855
Oldest active 405174856
Oldest snapshot 404420671
Next transaction 408104131
Sequence number 0
Next attachment ID 1119966
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSVC
Shadow count 0
Page buffers 2000
Next header page 0
Database dialect 3
Creation date Sep 28, 2019 11:23:37
Attributes force write

Variable header data:
Database backup GUID: {48F2911F-B2DA-46F5-D7AE-FD80BB5F8F93}
Sweep interval: 0
*END*



Кто виноват и что делать??

К сожалению, запрос оптимизировать уже дальше некуда. Он извлекает список головных
организаций по заданному списку торговых агентов.

Структура данных такая: у организации может быть несколько магазинов, в магазине могут быть
подразделения. За магазином или подразделением закреплены свои торговые агенты.




PLAN SORT (JOIN (DEP INDEX (USR$FKGD_CONTACT1221, USR$FKGD_CONTACT1221, USR$FKGD_CONTACT1221), CON INDEX (GD_X_CONTACT_LB, GD_X_CONTACT_RB)))

Весь справочник GD_CONTACT это 64 000 записей.

платформа ))



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

аккуратно отключили пользователей и перегрузили сервер.

запрос выполняется но целых 11 минут... у нас на копии бд пару секунд.

файл со статистикой прикреплен.

пока, будем ориентировать клиента на бэкап-восстановление на выходных и обновление сервера до ФБ 3.0.8.

rec_version
read_committed
nowait

повторно выполняется тоже больше 10 мин. на незагруженном сервере. Сейчас пошли подключаться пользователи и уже время увеличивается... Один запрос висит 15 минут уже.

Файлы сортировки все по 0Кб. Пока хватает оперативной памяти винде все кэшировать.

count(*) выполняется моментально. более того, он выполнялся моментально даже в той ситуации, когда к этой таблице висели несколько вышеуказанных запросов.

вот, это помогло! теперь работает быстро.

будем искать долгую транзакцию и кто мог сделать массовый апдейт по таблице контактов.

ВСЕМ СПАСИБО! ))