При частом удалении строк, фрагментируется таблица, а это приводит к созданию многих блоков, которые полностью не заполнены [3]. Этот тип фрагментации может привести к возникновению значительного количества свободных зон, и снижет производительность. Фрагментация блоков данных приводит к следующим проблемам [2]:
- Увеличение количества операции чтения. При обработке запросов снижается производительность системы;
- Увеличение объема, не используемого пространства вследствие образования пустот внутри блоков, таблиц;
- Снижение производительности при чтении. Когда данные не упакованы плотно при, обращении к базе данных выполняется больше операций чтения для получения такого же объема данных [2].
Причина появления фрагментации блоков данных
Фрагментация блоков данных появляется, когда строка удаляется из таблицы и, следовательно, удаляется из блока данных [3].
Методы обнаружения фрагментации блоков данных
Фрагментация блоков данных может быть измерена на двух основных уровнях детализации, как показано ниже:
- На уровне блоков [3];
- На байтовом уровне [3].
Но, нет необходимости измерять фрагментацию блоков данных каждой таблицы. Измерения таких таблиц, в которых, подозрительно, может появиться фрагментации блоков данных или ее размер очень большой [3].
На уровне блоков
С помощью следующего скрипка (см. скрипт 4), можно обнаружить фрагментацию блоков данных на уровне блоков так как, этот метод требует проанализировать таблицу, а затем подсчитать число блоков, которые содержат одну или более строк и это число делится на число используемых блоков [3].
SQL> analyze table PLAN_TABLE compute statistics;
Tabelle wurde analysiert.
SQL> select NUM_ROWS, BLOCKS, AVG_ROW_LEN
2 from dba_tables
3 where table_name = 'PLAN_TABLE';
NUM_ROWS BLOCKS AVG_ROW_LEN
----------------- ------------- ----------------------
0 0 0
SQL> analyze table GET_DATA_TABLE compute statistics;
Tabelle wurde analysiert.
SQL> select NUM_ROWS, BLOCKS, AVG_ROW_LEN
2 from dba_tables
3 where table_name = 'GET_DATA_TABLE';
NUM_ROWS BLOCKS AVG_ROW_LEN
----------------- ------------- ----------------------
96474 97292 5
Скрипт 4. Обнаружения фрагментации блоков данных для таблицы PLAN_TABLE GET_DATA_TABLE через dba_tables.
Скрипт 4. показывает что, таблица PLAN_TABLE, не содержит ни каких данных, так как число блоков, которые содержат одну или более строк = 0 и число используемых блоков = 0 и средний размер строки = 0.
Следующий анализ для таблицы GET_DATA_TABLE показывает что, таблица содержит большое количество данных потому, что число блоков, которые содержат одну или более строк = 96474 и число используемых блоков = 97292 и средний размер строки = 5.
На байтовом уровне
Этот метод требует анализа таблицы (см. скрипт 4). Средняя длина записи умножается на число записей в таблице и делится на число блоков таблицы умноженное на размер блока базы данных [3].
Влияние фрагментации блоков данных на производительность
Фрагментация блоков данных снижает производительность запросов к данным и уменьшает производительность [3]. Производительность изменяется в связи с тем, что чем выше фрагментация блоков данных, тем меньше строк данных выбирается за один доступ к блоку. Издержки не зависят от того, где находится блок, на диске или в КЭШе буфера блоков данных [3].
Серверному процессу легче выбрать 100 блоков данных, содержащих 600 строк вместо 150 блоков данных, содержащих те же 600 строк. Поскольку Oracle выбирает данные поблочно, а не построчно [3].
Решение проблемы фрагментации блоков данных
Существует два метода решения проблемы:
- Первый метод заключается в изменении параметров хранения (pctfree, pctused). Уменьшением параметра pctfree или увеличением параметра pctused, каждый блок будет заполняться большим числом строк, чем в прошлом. Для примера, вместо среднего числа строк на блок равного 20, уменьшением параметра pctfree, среднее число строк на блок можно увеличить до 25.
- Второй метод заключается в реорганизации объекта. Можно написать процедуру, которая могла бы копировать строки фрагментированных блоков в другое место, затем могла бы удалять эти строки (очищая блок), затем добавить их вновь в исходную таблицу. Но такая процедура будет работать очень медленно, неторопливо сканируя все блоки базы данных, которые нуждаются в реорганизации.
Анализ такого типа фрагментации в файле anabd.zip (26654) bytes.