Добрый день!
Я не программист Баз данных но хотел бы разобраться.
Досталась по наследству программа и БД на firebird, размер базы 2.4 Гб.
Выполнил переход с версии FireBird 2.0 на версию 3.0.

конфиг вот такой
ServerMode = Super
DefaultDbCachePages = 50000
TempBlockSize = 2M
TempCacheLimit = 364M
AuthServer = Legacy_Auth, Srp, Win_Sspi
AuthClient = Legacy_Auth, Srp, Win_Sspi
UserManager = Legacy_Auth, Srp
TracePlugin = fbtrace2db
WireCrypt = Enabled
RemoteServicePort = 3050
LockMemSize = 9M
LockHashSlots = 30011
GuardianOption = 1

количество пользователей до 50.

в час пик ну очень медленно работает!
Установил себе HQbird и пытаюсь разобраться устранить ошибки в базе.

Отобрал проблематичные таблицы и индексы, но вот знаний не хватает разобраться что нужно сделать.
например в таблице Produce колонка records тут все понятно присутствует поле blob, А вот со стольными ну темный лес, ребята кто пользовался помогите расшифровать что нужно оптимизировать?

На 2.0 совсем не возможно было работать. После перехода на 3.0 все заработало нормально и сейчас работает без проблем. Мне кажется что все тормаза происходят из-за того что не правильно осуществляются запросы и ошибки в базе таблицах.

Ребят, кто разбирается в Database Analyst от HQbird подскажите какие проблемы в таблицах и в индексах?

Ivan_PisarevskyРазмер БД совсем детский, если она стала жестоко тупить на двойке, то видимо клиент совсем кривой.

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

конфигурация, база крутится на виртуальной машине под нее отданы ресурсы
процессор E-2630 v3 2.40Ghz
Виртуальных процессоров 16
Память 16 Гб


Вот фрагмент репорта

Current database page size is 8192 bytes.

Your database have 1 tables fragmented with blobs (see
"Tables fragmented by blobs" list below). Increasing page size can
make these tables much fragmented than now, and some other tables
that have blob fields with data less than new page size can became
fragmented too.

--------------------------------------------------------
Fragmented tables count: 1.
Fragmented tables can slowdown performance. You can monitor listed
tables - if fragmentation will be worse in the course of time, you
need to make backup/restore. Here is the list of tables with data
greater than 200 kilobytes and average fill less than 60%.

COMPANY_RAZDEL : 57%, Records 8845, Pages 80


--------------------------------------------------------
Bad indices count: 3.
By `bad` we name indices with many duplicate keys (90% of all keys)
and big groups of equal keys (30% of all keys). Big groups of equal
keys slowdown garbage collection - MaxEquals here is % of max groups
of keys having equal values. Index search for such an index is not
efficient. You can drop such indices (if they are not on FK
constraints).

Index ( Relation) Duplicates MaxEquals
RDB$FOREIGN84 ( DOLGSSCHETS) : 100%, 49%
LOCALCALC_IDX1 ( LOCALCALC) : 100%, 33%
NACLAD_IDX2 ( NACLAD) : 100%, 82%

--------------------------------------------------------

Еще в репорте было по поводу таблицы blob, но тут вроде и мне понятно что не стоит в базе хранить изображения.
И куча пустых таблиц -- вот только я не знаю мешают они работе или нет?!

На физической машине где живет виртуалка 4-e диска SAS в раиде 10