Книга: Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Интерфейс gstat

Интерфейс gstat

В отличие от некоторых других инструментов командной строки gstat не имеет своего интерфейса командной строки. Каждый запрос заключается в вызове gstat с переключателями.

Синтаксис:

gstat [переключатели] имя-базы-данных

где имя-базы-данных- полный путь к базе данных.

gstat не является дружественным пользователю инструментом. Некоторые графические инструменты (например, IBAnalyst) четко выполняют ту же работу gstat по выводу результатов, используя Services API. Формы экранов были взяты из утилиты с открытыми кодами IBOConsole[60].

В табл. 18.1 описаны переключатели gstat.

Таблица 18.1. Переключатели gstat

Рекомендуется назначить вывод результатов в текстовый файл и просматривать его в текстовом редакторе.

! ! !

ПРИМЕЧАНИЕ. Поскольку gstat выполняет собственный анализ на уровне файла, она не выполняется в контексте какой-либо транзакции. Следовательно, статистика по индексам также включает информацию по тем индексам, которые используются в незавершенных транзакциях. Например, не будет предупреждений, если отчет показывает некоторые дублирующие записи в индексе первичного ключа.

. ! .

Синтаксис:

gstat -i[ndex] база-данных

Этот ключ отыскивает и отображает статистику по индексам в базе данных: средняя длина ключа (в байтах), общее количество дубликатов и максимальное количество дубликатов одного ключа. Включите переключатель -s[ystem], если вам нужна информация о системных индексах.

К сожалению, не существует способа получить статистику по одному индексу, однако вы можете ограничить результат одной таблицей, используя переключатель -t, за которым следует имя таблицы. Вы можете записать разделенный пробелами список имен таблиц для получения результатов более чем по одной таблице. Если имена ваших таблиц являются чувствительными к регистру - были объявлены идентификаторами, заключенными в кавычки, - то аргументы переключателя -t должны быть записаны в правильном регистре, но не должны заключаться в кавычки. Для таблиц с пробелами в их именах gstat вовсе не работает.

Вы можете добавить переключатель -system, чтобы включить сведения о системных индексах в отчет.

Чтобы запустить утилиту для базы данных employee и направить ее вывод в текстовый файл с именем gstat.index.txt, выполните следующее:

* в POSIX наберите (все в одной строке):

./gstat -index /opt/firebird/examples/employee.fdb -t CUSTOMER -user SYSDBA -password masterkey

> /opt/firebird/examples/gstat.index.txt

* в Win32 наберите (все в одной строке):

gstat -index

"c:Program FilesFirebirdFirebird_1_5examplesemployee.fdb" -t CUSTOMER

-user SYSDBA -password masterkey

> "c:Program FilesFirebirdFirebird_1_5examplesgstat.index.txt"

! ! !

ПРИМЕЧАНИЕ. Двойные кавычки для пути к базе данных требуются в Windows, если ваш путь содержит пробелы.

. ! .

На рис. 18.3 показано, как отображаются данные индексной страницы.

Рис. 18.3. Пример отображения данных индексной страницы

Вначале появляется итоговая информация об индексе. В табл. 18.2 объясняются записи строка за строкой.

Поскольку утилита gstat выполняет свой анализ на уровне файла, она не использует концепции транзакции. Следовательно, статистика по индексам также включает информацию по тем индексам, которые используются в незавершенных транзакциях.

Таблица 18.2. Вывод gstat -i[ndex]

Индекс является древовидной структурой со страницами на одном уровне, ссылающимися на страницы другого уровня и т.д. вплоть до страниц, указывающих на строки данных. Чем больше глубина, тем больше косвенных уровней. Строка Leaf bucket описывает страницы индекса самого низкого уровня, которые указывают на индивидуальные строки.

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

Рис. 18.4. Глубина индекса

Два фактора оказывают влияние на глубину: размеры страницы и ключа. Если глубина больше 3 и размер страницы меньше 8192, то увеличение размера страницы до 8192 или 16 386 должно уменьшить количество косвенных уровней и увеличить скорость.

! ! !

СОВЕТ. Вы можете вычислить приблизительный размер (в страницах) цепочки мах dup на основании статистических данных. Для получения количества узлов на странице разделите узлы (nodes) на количество листьев (leaf buckets). Умножение результата на максимальное количество дублирующих узлов (max dup) дает приблизительное количество страниц.

. ! .

Следующие выдержки являются выводом gstat -index для базы данных с плохой производительностью.

Первый из поддерживаемых индексов, который был создан автоматически для внешнего ключа:

Index RDB$FOREIGNl4 (3)

Depth: 2, leaf buckets: 109, nodes: 73373

Average data length: 0.00, total dup: 73372, max dup: 32351

Fill distribution:

80 - 99% = 109

Строка Depth: 2, leaf buckets: 109, nodes: 73373 Сообщает нам, что нижний уровень индекса имеет 109 листьев (страниц), количество узлов 73 373. Это может и не быть общим количеством строк таблицы. С одной стороны, утилита gstat ничего не знает о транзакциях, поэтому она не может сообщить, найдены ли подтвержденные или неподтвержденные страницы. С другой - столбцы могут иметь значения NULL и не будут попадать в статистику.

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

В строке Average data length: 0.00, total dup: 73372, max dup: 32351 число max dup указывает длину самой длинной цепочки дубликатов, подсчитанной почти для половины узлов. Число total dup говорит, что каждый узел, за исключением одного, является дубликатом.

Это самый классический случай, когда проектировщик применяет внешний ключ без рассмотрения его распределения. Вероятно, это столбец стиля BOOLEAN или таблица соответствия (lookup) либо с очень небольшим количеством значений, либо практически с одним значением.

Примером этому было приложение формирования списка избирателей, которое сохраняло столбец страны проживания. Избирателей было приблизительно 3 миллиона, а регистрация была принудительной. База данных имела таблицу COUNTRY, содержащую более 300 стран, снабженную ключами в кодах стран CCCIT. Она присутствовала чуть ли не в каждой таблице базы данных в качестве внешнего ключа. Беда была в том, что почти все избиратели жили в одной стране.

Средняя длина данных (Average data length) - это средняя длина хранимого ключа. Здесь мало что можно сделать с объявленной длиной. Нулевое значение средней длины означает лишь то, что в процессе сжатия не осталось "пищи" для вычисления среднего значения.

Строка Fill distribution показывает, что все 109 страниц находятся в диапазоне 80-99 процентов, что является хорошим заполнением. Распределение заполнения является долей пространства каждой страницы, используемой для данных и указателей. От восьмидесяти до девяноста процентов - это хорошо. Меньшее распределение заполнения является весьма серьезным напоминанием, что вы должны пересоздать индекс.

Следующий пример показывает статистику сгенерированного системой индекса для первичного ключа в той же таблице:

Index RDB$PRIMARY10 (0)

Depth: 3, leaf buckets: 298, nodes: 73373

Average data length: 10.00, total dup: 0, max dup: 0

Fill distribution:

0 - 19% = 1

80 - 99% = 297

Длина ключа 10 означает, что выполнено некоторое сжатие. Это нормально и хорошо. То что одна строка мало заполнена- вполне нормально: количество узлов не соответствует точно страницам.

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

Index RDB$FOREIGN263 (1)

Depth: 1, leaf buckets: 10, nodes: 481

Average data length: 0.00, total dup: 480, max dup: 480

Fill distribution:

0 - 19% = 10

Total dup и max dup идентичны - каждая строка имеет одинаковое значение в ключе индекса. Селективность не может быть хуже этой. Уровень заполнения, очень низкий для всех страниц, наводит на мысль о разнородных удалениях. Если бы это не было маленькой таблицей, такой индекс был бы ужасен.

Данная таблица - очередь обработки - очень динамична, она хранит до 1000 новых строк в день. После проверки данных строки переносятся в порождающие таблицы, а строки разрабатываемой таблицы удаляются, приводя к замедлению работы системы. Частое резервное копирование и восстановление базы данных необходимо, чтобы дела шли нормально.

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

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

* Если возможно, удаляйте все строки за один раз, а не выполняйте их удаление одну за другой в случайном порядке. Удалите ограничение внешнего ключа, удалите строки и подтвердите транзакцию. Заново создайте ограничение. Поскольку это не длинная транзакция, задерживающая сборку мусора, новый индекс будет полностью пустым.

* Если удаления должны быть последовательными, выберите время, чтобы получить исключительный доступ и использовать ALTER INDEX для пересоздания индекса. Это будет более быстро и предсказуемо, чем инкрементная сборка мусора в огромной цепочке дубликатов.

Оглавление книги