IBAnalyst теперь является частью HQbird Standard!

IBAnalyst - это инструмент, который позволяет администратору базы данных анализировать детальную статистику Firebird или InterBase и выявлять возможные проблемы с производительностью базы данных, её обслуживанием и взаимодействием приложения с базой данных.

Документация

IBAnalyst наглядно отображает статистику базы данных Firebird (или InterBase) в удобном для пользователя виде и выделяет следующие проблемы:

фрагментация таблиц и BLOB-полей,
версионирование записей,
сборка мусора,
эффективность индексов и т.д.

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

IBAnalyst может получать статистику из работающих производственных баз данных через Services API (рекомендуется) или анализировать текстовый вывод команд gstat -a -r …. Статистика, полученная в периоды пиковой нагрузки, может дать много информации о реальных проблемах производительности в производственных базах данных.

Как IBAnalyst может помочь найти проблемы в вашей базе данных Firebird или InterBase

Давайте рассмотрим ключевые возможности IBAnalyst. Когда вы впервые смотрите на статистику вашей базы данных в IBAnalyst, многое может быть неясно, особенно если IBAnalyst показывает множество предупреждений с красными и жёлтыми ячейками в представлениях Summary, Tables и Index. Рассмотрим несколько реальных примеров статистики.

Сводное представление

Страница Summary показывает много информации, но наиболее ценной является состояние транзакций ( пожалуйста, прочитайте описание возможных состояний транзакций в справке IBAnalyst, она доступна по нажатию F1 или в меню Help).

На этом скриншоте видно, что некоторая транзакция активна в течение длительного времени - «60% от среднесуточного значения». IBAnalyst помечает такое состояние транзакции красным, потому что эта транзакция может препятствовать тому, чтобы накопленные версии считались сервером мусором и, соответственно, подвергались сборке мусора. Это возможная причина замедления: чем больше версий существует для некоторой записи, тем больше времени потребуется на её чтение.

Чтобы найти эту долго выполняющуюся транзакцию, вы можете использовать модуль MON$Logger из FBScanner или выполнить прямой запрос к таблицам MON$. Затем, чтобы выяснить, какие таблицы были затронуты долго выполняющимися транзакциями (таблицы с большим количеством версий записей), нужно перейти в представление «Tables» в IBAnalyst.

Представление Tables

В представлении «Tables» вы можете видеть таблицы и их важные параметры: количество записей, количество версий записей, длину записи, максимальное количество версий и т.д.

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

Row Versions показывает общее количество версий для конкретной таблицы, а строка Max Vers показывает максимальное количество версий, достигнутое некоторой записью. Например, если посмотреть на таблицу NAB, там 11,9 миллиона записей, общее количество версий - 20932, но одна запись имеет 176 версий. Чтение и разбор такого пакета с диска занимает больше времени, поэтому чтение этой записи происходит медленнее, чем чтение других.

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

Представление Index

В некоторых производственных базах данных могут быть индексы, в которых индексируется только одно значение ключа. Это может произойти, потому что база данных разрабатывалась «с расчётом на расширение в будущем», или кто-то просто экспериментировал с индексами во время разработки или тестирования. Вы можете увидеть такие индексы как «Useless» в IBAnalyst:

SKIN04, SKIN05, SKOUT03 и т.д., построенные на столбце, который имеет только одно значение для всех строк (миллионы строк). Эти индексы действительно бесполезны, потому что:

оптимизатор может использовать этот индекс, если вы укажете «where field = …». Поскольку поле содержит только одно значение, использование индекса вызовет бесполезное чтение страниц индекса с диска в память и потребление памяти (и времени), когда сервер будет подготавливать, какие строки показать для этого запроса.
создание индексов является частью процесса восстановления. Дополнительные индексы добавляют дополнительное время.

Конечно, это не всё, что вы можете узнать о своей базе данных в IBAnalyst. Вы также можете найти:

среднее количество транзакций в день
были ли откаты или потерянные соединения, и когда
насколько велики (в мегабайтах) каждая таблица и индекс
таблицы, в которых записи чередуются с BLOB-полями, и поэтому чтение только записей происходит медленнее
пустые таблицы - просто забытые или пустые на момент снятия статистики
индексы с большим количеством дублирующихся ключей (можно задуматься о распределении значений в столбце)
индексы с глубиной 4 и более - возможно, вам нужно увеличить размер страницы для ускорения работы

Автоматические рекомендации

Если вас смущает чтение предупреждений в цветных ячейках, просто откройте «Reports\View recommendations» - здесь собрано всё, что необходимо для производительности базы данных. Пожалуйста, не стесняйтесь задавать любые вопросы ([email protected]).