Выбор оптимального размера блока
Выбор оптимального размера блока
Соответствие размера блока базы данных и размера блока файловой системы является залогом наибольшей эффективности операций ввода-вывода. Если определить размер блока БД слишком маленьким, то операционная система считает больше блоков БД, чем необходимо и неизвестно, пригодятся ли дополнительно считанные данные или нет. Если нет, то эти дополнительные блоки прочитаны впустую. Блоки имеющие бОльший размер обычно лучше из-за механизма поведения индексов. Если каждый блок будет содержать оптимальное количество информации, то нам потребуется прочитать меньше индексных блоков и индексных уровней для того, чтобы найти и прочитать данные. Количество индексных уровней в двоичном дереве (B-tree) прямо влияет на эффективность извлечения данных. Если мы избегаем чтения одного уровня индекса, то мы экономим одну дополнительную операцию ввода-вывода на запрос записи.
Определение количества записей на блок базы (RPB)
Для того, чтобы определить количество записей в блоке базы данных нам необходимо разделить размер блока базы данных на средний размер записи и прибавить к полученному значению 20 байт на издержки на дополнительную служебную информацию.
Таблица 2 являет собой хорошее руководство по определению числа RPB (records per block). Если полученный при делении результат лежит у нижней границы интервала для большинства ваших записей (колонка «средний размер записи»), то можно выбрать следующее по возрастанию значение RPB. Лучше рискнуть небольшой фрагментацией данных, чем иметь неиспользуемое место в каждом блоке.
Определение количества блоков в кластере
Обычно количество блоков в кластере определяется количеством записей в таблице и оптимально выбранным количеством записей на блок. Большие таблицы требуют большого количества блоков в кластере. В таблице 3 можно видеть минимальное количество записей, которое может целиком заполнить кластер. Можно выбрать меньшее значение блоков в кластере, если необходимо заполнить малое количество кластеров.
Экстенты небольшого размера для предотвращения косвенной адресации
Оптимальный размер экстента базы данных зависит от операционной и файловой систем сервера. В прошлом оптимальный размер экстента был меньше, чем 500Мб. Такой размер был оптимален для предотвращения косвенной адресации операций ввода-вывода. Такая адресация возникает тогда, когда файл не может быть адресован при помощи одной единственной inode-таблицы. Когда операционной системе необходимо считать данные из файла по определенному адресу, то она обращается к inode-таблице с помощью которой определяет физический адрес блока и считывает его. В случае косвенной адресации для определения физического адреса блока необходимо просмотреть несколько inode-таблиц, что увеличивает количество операций чтения на чтение одного блока данных с диска. Это ухудшает производительность дисковой системы и такой адресации необходимо избегать. Как правило, файлы размером менее чем 2Gb имеют мало шансов быть фрагментированными и для доступа к ним не используется косвенная адресация. Поэтому экстенты БД размером в 2Gb обычно должны рассматриваться как оптимальный размер файла экстента БД. Для очень больших баз данных ограничение в 2Gb может привести к очень большому количеству экстентов, поэтому здесь требуются другие размеры. Для уменьшения шансов возникновения косвенной апдресации необходимо размещать данные на современных файловых системах и использовать максимум 8Gb. Для этого необходимо включить опцию «large file» для базы данных, что является, в принципе, обязательным для любой базы данных. О том как это сделать рассказано чуть ниже.
Небольшие области хранения для быстрого исполнения офф-лайновых утилит
В настоящее время большинство утилит OpenEdge работают в онлайн-режиме. Однако существуют утилиты, которые требуют остановки базы данных перед своим выполнением. Для того, чтобы сократить время простоя базы данных необходимо минимизировать объем обрабатываемых данных.
Лучшим примером такого подхода будет перестройка индексов. Если мы выполняем утилиту idxcompact или idxfix, то достигаем практически тех же самых результатов, что и idxbuild. Однако иногда бывает необходимо выполнить именно idxbuild из-за повреждения индекса или в силу каких-то других соображений. Если эта утилита запущена, то ей необходимо просканировать всю область хранения для того, чтобы быть уверенным, что у нас есть указатель на каждую запись. Если все записи находятся в одной области хранения, то это может занять значительное количество времени. Всегда быстрее отсканировать часть (только необходимые записи в отдельной области) чем всю базу данных целиком.
Экстенты должы иметь возможность роста
Последний экстент каждой области, включая область primary recovery (но исключая after-image) должен быть типа v — variable extent или экстент переменной длины. Казалось бы, что наблюдение за дисковой емкостью и планирование роста базы данных должны свести необходимость в таких экстентах на нет. Однако, они необходимы если вы ожидаете заполнение фиксированных экстентов и одновременно с этим не уверены, что можете остановить базу данных для добавления экстентов постоянного размера. Экстенты переменной длины позволяют избежать незапланированного останова. (Прим — с версии 10.1x возможно добавление экстентов в режиме онлайн — prostcrt addonline… /dmi)
Включение поддержки больших файлов
Эта опция должна быть всегда включена для базы данных. Однако, как мы видели выше — использования больших файлов необходимо избегать. Эта опция должна быть включена как правило для избежания аврийного останова базы данных во время неконтроллируемого роста. (или для больших баз на современных файловых системах с экстентами 8Gb — /dmi)
Включение «large files» позволяет иметь размер экстента до 1 TB при условии того, что файловая система поддерживает такие файлы. На UNIX необходимо включать поддержку больших файлов средствами операционной системы для каждой файловой системы. На системах Windows файл может занять весь том без проблем, но по умолчанию поддержка больших файлов базой данных так же выключена на windows (по соображениям совместимости)
Для того, чтобы включить поддержку больших файлов базой данных необходимо ввести следующую команду
Разделение (партиционирование) данных
Распределение данных между областями хранения по функциональным признакам является хорошим заделом на будущее. В дальнейшем, когда появится возможность вертикального партиционирования данных ваше приложение уже будет готово к этому.
Другое преимущество такого разделения касается случаев повреждения базы данных. Идентифицировать поврежденные данные в этом случае гораздо легче.