Очередь файлов

При работе с таблицей БД ядро СУБД должно открыть файлы этой таблицы. Дескриптор открытого файла помещается в очередь файлов, вытесняя при этом, в случае необходимости, дескриптор другого файла с предварительной синхронизацией страниц файла в оперативной памяти и на диске.

Каждая таблица БД это минимум два файла: файл данных и файл индексов.

Данные/индексы могут размещаться в нескольких файлах (до 63). Таким образом, число файлов таблицы может быть до 63*2. При работе с таблицей ее файлы открываются только при необходимости. Чтобы начать работу с таблицей, СУБД открывает первый файл данных и первый файл индексов. Чаще всего пользователи БД размещают таблицу в двух файлах (один файл данных и один индексный файл). Разнесение таблицы более чем в два файла необходимо в редких случаях. Ниже приведен анализ эффективности работы СУБД в зависимости от размера очереди файлов.

Желательно, чтобы при работе с таблицей описания всех её файлов находились в очереди файлов. Таким образом, размер очереди файлов должен быть, как минимум, в 2 раза больше размера очереди таблиц, чтобы вместить описания одного индексного файла и одного файла данных каждой таблицы.

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

СУБД упаковывает данные, и добавляемая упакованная запись помещается на первое свободное место, достаточное для ее размещения. Эти свободные места («дырки») образуются практически случайно, однако замечено, что чем ближе процент сжатия к значению 100 %, тем менее случайным становится процесс появления «дырок». Если СУБД считает информацию несжимаемой (процент сжатия 100 %), то порядок расположения записей в файле будет почти совпадать с порядком их поступления на обработку. Таким образом, если очередная запись выборки данных извлекается из какого-либо файла данных, то следующие записи, вероятнее всего, будут в том же файле. Смена файлов в очереди файлов будет последовательной, что сделает работу СУБД в многопользовательском режиме более эффективной.

Если процент сжатия близок к 100%, то увеличение очереди файлов вдвое по сравнению с очередью таблиц почти не даст повышения эффективности. Чем меньше процент сжатия, тем больше вероятность переключения СУБД с одного файла на другой. Вполне возможно, что при маленьком проценте сжатия будет недостаточно очереди файлов вдвое большей, чем очередь таблиц (могут начаться ощутимые замедления). Однако это происходит только в том случае, когда таблицы состоят более чем из двух файлов.