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])