3.3 Размер сегмента чередования

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

3.3.1 Чередование с малым размером сегмента

Конфигурации с малым размером сегмента чередования распределяют данные небольшими порциями по всем дискам таким образом, что любой запрос на ввод/вывод, в независимости от его размера, приводит к использованию всех дисков в массиве. Преимуществом такого подхода является высокая скорость обмена для любых запросов ввода/вывода. Недостатками подхода является то, что [Chen et al. (1993), 15]:

• Только один запрос на ввод/вывод может выполняться в любой момент времени. Таким образом, за возможность распараллеливания обработки одного запроса по всем дискам, приходиться платить тем, что становиться невозможным параллельная обработка большого числа запросов.
• Все диски должны тратить время для позиционирования для каждого запроса. Таким образом, если размер сегмента чередования меньше чем запрос на ввода/вывод, то два или более диска должны ожидать позиционирования при каждом запросе.

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

3.3.2 Операции с высоким уровнем параллелизма

Если Вы исполняете приложение с высоким уровнем параллелизма на дисковом массиве (т.е. много одновременно исполняемых процессов будут конкурировать за доступ к массиву), то Вы должны убедиться, что размер сегмента чередования имеет достаточно большой размер для того, чтобы любой запрос на ввод/вывод обслуживался ровно одним диском. В противном случае, число физических запросов на ввод/вывод может резко вырасти, что создаст огромную нагрузку на ядро операционной системы и всю подсистему ввода/вывода.

Нельзя гарантировать, что блоки данных Oracle будут выровнены по границам сегментов чередования поэтому, если размер сегмента чередования будет совпадать с размером блока обмена операций ввода/вывода, то это, вероятно, породит больше физических операций, чем число запросов на ввод/вывод. Выбор размера сегмента чередования вдвое больший, чем размер блока ввода/вывода даст 50%-ый шанс того, что операция потребует работы не более чем с одним диском. В общем, использование размера сегмента чередования в k раз большего, чем размер блока ввода/вывода даст вероятность того, что потребуется не более одного диска для обработки одного запроса, равную (k - 1)/k. Для выбранного k Вы должны гарантировать, что Ваш дисковый массив в состоянии выполнить в (k + 1)/k больше операций ввода/вывода, чем генерирует Ваше приложение. Таким образом, если профиль доступа к массиву — это доступ, исключительно основанный на индексе или хэш-структуре при высоком уровне параллелизма, то выбор размера сегмента чередования вдвое или более раз, чем значение параметра db_block_size даст высокую производительность. Если профиль доступа к данным включает частые последовательные сканирования, оптимальный размер сегмента чередования должен быть, как минимум, вдвое больший, чем значение db_file_multiblock_read_count × db_block_size ⁷.

Массив с малым размером сегмента чередования может оказаться плохим выбором для хранения табличного пространства, которое используется сервером Oracle для создания сегментов сортировки в тех случаях, когда одновременно выполняется большое число сортировок. Малый размер сегмента чередования может показать удивительно низкую производительность и при использовании возможности параллельной обработки запроса (PQO), поскольку PQO использует несколько подзапросов, что создает высокий уровень параллелизма даже при одной активной пользовательской сессии.

3.3.3 Операции с низким уровнем параллелизма

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

Прекрасным примером минимального уровня параллелизма с большим объемом последовательной записи на диск является процесс записи в журнальные файлы (LGWR). LGWR является однопоточным процессом, который выполняет большие объемы последовательной записи как при OLTP-нагрузках, так и в течение загрузки данных ⁸.

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

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

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

3.3.4 Трудности

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

• Планирование заданий — не запускайте больших загрузок данных в то время, когда имеется и без того высокая конкуренция за ввод/вывод со стороны процессов решающих важные задачи.
• Размещение данных — размещайте данные Вашей БД по файлам с подобными характеристиками ввода/вывода, размещайте файлы данных на одном массиве только в том случае, если они имеют одинаковый профиль доступа. К примеру, плохо выглядит идея разместить на одном массиве с малым размером сегмента чередования журнальные файлы, если Вы уже поместили на этот массив другие файлы БД, поскольку при этом возникнет конкуренция с процессом LGWR за ввод/вывод.
• Разработка приложения — отдавайте предпочтение однопоточным (или пакетным), высокоактивным загрузкам в БД вместо использования ресурсоемких транзакций, работающих в режиме высокого параллелизма. Плохое проектирование транзакций не только затрудняет построение хорошей дисковой конфигурации, но и приводит к активному использованию механизма фиксаторов и блокировок Oracle, что в свою очередь может породить каскад трудноразрешимых проблем.
• Оптимизация SQL-операторов — сведите к минимуму сортировки и полные сканирования таблиц. Устранение частого запуска операций сортировки или полного сканирования таблиц может дать замечательный результат для всего приложения.

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

3.3.5 Резюме

Не существует единого «наилучшего размера сегмента чередования» для всех видов приложений и даже более того, — для всех видов операций в пределах одного приложения. При хорошем проектировании подсистем ввода/вывода VLDB Вы должны быть готовы к использованию различных размеров сегмента чередования для разных дисковых массивов В общем, следует использовать наименьший из возможных размеров сегмента чередования для того, чтобы исключить возможность появления «горячих зон» (hot spot) на дисках, — с одной стороны, а с другой — Вы не должны уменьшать размер сегмента чередования настолько, чтобы появлялась опасность возникновения неэффективного использования дисков при высоких уровнях параллелизма. Вы должны использовать следующие руководящие принципы при выборе размера сегмента чередования:

• Высокий уровень параллелизма — если Вы ожидаете высокий уровень параллелизма ввода/вывода на дисковом массиве, то используйте размер сегмента чередования как минимум в два раза больший, чем наименьший запрос на ввод/вывод. Для файлов данных сервера Oracle с высоким уровнем параллелизма ввода/вывода это означает, что Вы никогда не должны использовать размер сегмента чередования, меньший чем 2 × db_block_size. Если файл данных часто используется для последовательного чтения, Вы также должны убедиться, что размер сегмента чередования равен как минимум 2 × db_block_size × db_file_multiblock_read_count.
• Низкий уровень параллелизма — если уровень параллелизма мал для отдельного дискового массива, то возможно, Вы захотите использовать размер сегмента чередования меньший, чем размер запросов на ввод/вывод, с целью увеличения пропускной способности дискового массива при малом числе параллельных процессов. Чередование с очень малым размером сегмента может хорошо себя показать, например, для журнальных файлов.

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

1. Определите типы операций ввода/вывода, которые будут иметь место на рассматриваемом дисковом массиве. Наиболее общая ошибка в выборе размера сегмента чередования заключается в неверном заключении об операциях ввода/вывода, присущих данным, располагаемым на дисковом массиве.
2. Создайте несколько массивов с различными размерами сегмента чередования на Вашем оборудовании для использования Вашим приложением.
3. Выполните идентичные задачи на каждом массиве. Проведите тесты с интенсивным использованием операции записи, включая создания табличных пространств, прямые загрузки данных, создания индексов. Проведите тесты с интенсивным использованием операции чтения, включая полные сканирования таблиц и сканирования с использованием индексов.
4. Оцените производительность на Ваших тестах и выберите конфигурацию, показавшую наилучший результат. Ключевыми показателями следует считать затраченное время, число физических операций чтения и записи и, для RAID 5, — число чтений блоков с контрольными суммами.

Мотивируемый размер сегмента чередования для конфигураций серверов Oracle будет лежать в диапазоне 16–32KB для массивов с малым размером сегмента чередования; для массивов с большим размером сегмента чередования — размер будет в два-четыре раза больше, чем максимальный размер блока ввода/вывода. На сегодняшний день большинство платформ поддерживают обмен с максимальным размером 64KB, некоторые платформы позволяют обмениваться блоками в 128KB ⁹. Таким образом, хорошими, для массивов с большим размером сегмента чередования, можно считать размеры в диапазоне от 128KB до 512KB.