Конфигурирование сервера Oracle для сверхбольших баз...

Конфигурирование сервера Oracle длясверхбольших баз данных

Carry V. MillsapOracle Corporation

21 августа, 1996

Аннотация

Эта статья поможет читателю настраивать сверхбольшие базы данных Oracle (Very Large Database,в дальнейшем — VLDB) для достижения высокой производительности и высокой доступности принизких издержках на эксплуатацию. Она описывает решения выбора размера блока данных Oracle,применения RAID-технологий, использования «линейных» устройств (raw-devices), конфигурированияжурнальных файлов, разбиения табличных пространств на разделы, выбора параметров хранения инастройки сегментов отката. Статья описывает технологии и связанные с ними ограничения, а такжетехнически детальные методы для оптимизации конфигурации в рамках этих ограничений.

2 Конфигурирование сервера Oracle для VLDB

Содержание

1 Введение 21.1 Операционная сложность . . . . . . 21.2 Высокая производительность . . . . 21.3 Высокая доступность . . . . . . . . 31.4 Преодоление сложностей VLDB . . 3

2 Размер блока СУБД Oracle 32.1 Уменьшение нагрузки на ввод/вывод 42.2 Улучшение использования про-

странства . . . . . . . . . . . . . . . 42.3 Предотвращение узких мест при

параллелизме . . . . . . . . . . . . . 42.4 Компромиссы . . . . . . . . . . . . . 5

3 Дисковая конфигурация 53.1 Структурный анализ конфигурации 63.2 RAID . . . . . . . . . . . . . . . . . 83.3 Размер сегмента чередования . . . . 163.4 Размер массива . . . . . . . . . . . . 203.5 Линейные устройства . . . . . . . . 223.6 Конфигурация Oracle . . . . . . . . 23

4 Журнальные файлы 244.1 Баланс производительности и до-

ступности . . . . . . . . . . . . . . . 254.2 Контрольные точки сервера Oracle . 254.3 Восстановление инстанции сервера

Oracle . . . . . . . . . . . . . . . . . 264.4 Размещение журнальных файлов . . 274.5 Размер журнального файла . . . . . 284.6 Число журнальных файлов . . . . . 29

5 Планирование табличных пространств 305.1 Назначение сегментов табличным

пространствам . . . . . . . . . . . . 32

6 Параметры хранения 326.1 Maxextents . . . . . . . . . . . . . . 336.2 Свойства параметров хранения . . . 336.3 Выбор параметров хранения . . . . 34

7 Сегменты отката 357.1 Размер сегмента отката . . . . . . . 367.2 Количество сегментов отката . . . . 37

8 Заключение 38

1 Введение

VLDB является аббревиатурой, принятой дляобозначения СверхБольших Баз Данных (VeryLarge Database). Словосочетание «сверхбольшая»имеет разное наполнение для разных людей,но оно всегда связано с ощущением трудности,сложности, высокой стоимости и риска. VLDBявляются тем, что люди связывают с огромны-ми базами данных, поддержка которых граничитс искусством. Требуются большая изобретатель-ность, умение планировать, упорный труд и зна-чительные капиталовложения для того, чтобы из-бежать очень серьезных разочарований при по-пытке внедрения VLDB.

1.1 Операционная сложность

Операционная сложность является очевиднойпроблемой VLDB. Как оператор VLDB Вы долж-ны постоянно оценивать множество сильно свя-занных параметров. Система будет «наказывать»попытки применить радикальные или случайныеизменения. Огромные объекты и длительные про-цессы оставляют Вам мало пространства для ма-невра при устранении проблемы. Это требует, впервую очередь, осторожности при планированииустранения проблемы. Состояние сотен или дажетысяч людей зависит от Вашей способности быст-ро принимать правильные решения. Здесь требу-ется талант и упорный труд.Длительность многих важнейших процедур,

например резервное копирование и восстановле-ние, пропорциональна размеру объектов, которы-ми они манипулируют. Поэтому в больших БДэти важнейшие процедуры могут требовать оченьбольших временных интервалов. С ростом БДстоимость ошибок увеличивается. Операции —подобные реконфигурации диска, перестроениюобъекта БД, подсчету числа строк в таблице,откату транзакции, — могут выглядеть вполнебезобидно в небольших БД, но быть полностьюнеприемлемыми для VLDB. Если действие тре-бует нескольких часов Вашего рабочего времени,Вы должны избегать его выполнения.

1.2 Высокая производительность

Увеличивают сложность и другие факторы.Рассмотрим доступ к данным. Вы можете до-

Технический Документ Группы по Производительности Корпорации Oracle, 21 августа, 1996

Carry V. Millsap 3

пустить использование неэффективного запроса,который требует 2 секунды работы процессора навысокопроизводительной современной системе с20 пользователями, но Вы не сможете допуститьтакое же время обслуживания в системе с 1,200пользователями, где идет непрерывная борьба зафиксаторы (latches), диски и процессорное время.Запросы к VLDB должны быть оптимизированыисключительно хорошо, иначе система развалить-ся.

Более того, многие VLDB становятся «VL» впервую очередь вследствие большого числа од-новременно работающих пользователей и пакет-ных заданий, создающих большой объем транзак-ций. Большой объем транзакций создает стрессо-вые ситуации в подсистеме ввода/вывода связан-ные с генерацией redo-информации и записью вфайлы данных. Высокий уровень параллелизмапроцессов перегружает фиксаторы и механизмыблокировок, разработанные для перевода досту-па к критическим ресурсам в последовательныйрежим (serialize).

1.3 Высокая доступность

Чем больше обдумываешь проблему — тем онасложней выглядит. VLDB часто являются источ-ником данных для важных приложений с высо-кими требованиями доступности. Разработчикииндустриальных СУБД слышат формулу «семь–дней–по–двадцать–четыре–часа», а мы цепене-ем от монументальной сложности этой задачи.Ввиду электрических и сетевых неисправностей,некачественных модулей памяти и дисковых кон-троллеров, ошибок приложений и операционныхсистем, модернизации ПО и оборудования и про-сто случайных ошибок оператора, — достичьнескольких секунд или минут останова в годкрайне сложно. Как обнаружить и исправить ло-гические разрушения сотен и даже тысяч гига-байт данных, которые образовались вследствиеошибочного ввода оператора?

1.4 Преодоление сложностей VLDB

Путь к преодолению сложностей, присущихVLDB, лежит в упрощении БД настолько, на-сколько это возможно. Вы оптимизируете какСУБД, так и само приложение для снижения

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

Ниже перечислены некоторые аспекты, позво-ляющие построить хорошую VLDB:

• Оптимизация выполнения последовательно-сти бизнес-операций

• Оптимизация логической модели данных

• Оптимизация схемы БД

• Построение надежной, высокопроизводи-тельной конфигурации аппаратного обеспе-чения

• Оптимизация физической конфигурации БД

• Оптимизация SQL-операторов приложений

• Оптимизация операционной системы и ин-станции сервера Oracle

• Создание корректных и надежных процедурсопровождения

В этой статье мы исследуем решения для фи-зической конфигурации БД, необходимые дляуспешного построения VLDB.

2 Размер блока СУБД Oracle

Ирония жизни — в тот день, когда Ваш опытв управлении сервером Oracle минимален, Вамнеобходимо ввести значение для параметра db_-block_size, которое будет в дальнейшем неизме-няемо на протяжении всей жизни БД. Важно то,что значение, которое Вы выбрали для размераблока данных Oracle, оказывает сильнейшее вли-яние на производительность системы. Последую-щие разделы обратят Ваше внимание на некото-рые компромиссы, которые необходимо рассмот-реть перед выбором размера блока данных Oracleдля Вашей базы данных.

Оптимальный размер блока данных Oracle дляVLDB лежит в пределах от 4KB до 64KB. Наибо-лее часто используемым является значение 8KB



и, на втором месте, — 16KB. Сервер СУБДOracle, установленный на системе с очень быст-рой реализацией копирования больших объемовпамяти может эффективно работать с размеромблока в 32KB и даже (как минимум, теорети-чески) с 64KB. Я не знаком с обстоятельства-ми, которые могли бы требовать выбора размераблока для VLDB в 2KB и лишь в очень специ-альных случаях размер в 4KB будет подходящимдля VLDB. В [6, Millsap (1996)] я давал развер-нутое техническое описание этого вопроса, здесьмы ограничимся только выводами 1.

2.1 Уменьшение нагрузки на ввод/-вывод

Наиболее важной характеристикой самыхсложных реализаций VLDB является огром-ная нагрузка на ввод/вывод. Владельцы луч-ших мировых VLDB вкладывают большие день-ги в средства, способные уменьшить нагрузку наввод/вывод в их системах. Использование боль-шого размера блока данных СУБД Oracle являет-ся простой техникой для уменьшения некоторыхвидов нагрузки на ввод/вывод.

• Число операций ввода/вывода — аппаратураимеет вполне определенную цену одной опе-рации ввода/вывода. Манипуляция с неболь-шим числом больших блоков данных бу-дет иметь преимущества над манипуляциямибольшим числом блоков меньшего размера.

• Производительность индексов — скоростьработы с индексами обратно пропорциональ-на высоте двоичного дерева (B*-tree) индек-са. Больший размер блока Oracle позволитхранить больше ключей в одном блоке что, всвою очередь, даст лучшую производитель-ность при поиске.

• Снижение сцеплений — сервер Oracle ис-пользует сцепление (chaining) для хране-ния строк таблиц, кластеров данных и хэш-таблиц размер которых (строк) превыша-ет размер блока данных. Сцепление частей

1Чтобы не заставлять Вас искать указанный документ ком-пании Oracle, что кстати является не простым делом, скажу,что одним из специальных случаев, когда выбор в 4KB будетподходящим, заключается в наличии огромного числа неболь-ших сегментов (меньше 100KB).

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

2.2 Улучшение использования про-странства

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

2.3 Предотвращение узких мест припараллелизме

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

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


Carry V. Millsap 5

данных 3. Таким образом, если Вы увеличилиразмер блока данных Oracle в k раз, то Вам необ-ходимо увеличить значение параметра initransтакже в k раз. Для того чтобы позволить дина-мически расти «таблице списка входов транзак-ций», Вам необходимо установить значение пара-метра maxtrans в значение, превышающее значе-ние initrans 4.Неудачный выбор параметров initrans и

maxtrans для сегментов базы данных можетбыть причиной возникновения ожиданий поль-зовательских сессий. Сессии, которые изменяютблок, имеющий эту проблему, будут мешать дру-гим сессиям получить входы в структуру дан-ных блока, которая позволяют делать реконструк-цию данных для достижения непротиворечиво-сти чтения. Эта ситуация, имеющая названиеITL-конкуренция, может быть обнаружена ад-министраторами БД с помощью представленияv$lock. Наблюдения будут показывать сессии,ожидающие на блокировке TX (очередь транзак-ций) в режиме блокировки 4 (разделяемый до-ступ).Вы в состоянии полностью избежать этих

проблем, используя соответствующие техники,описанные в стандартной документации компа-нии Oracle по настройке параметров initrans иmaxtrans для сегментов БД.

2.4 Компромиссы

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

• Физический размер ввода/вывода — Размерблока данных СУБД Oracle не должен пре-вышать максимально возможный размер фи-зической операции чтения данных. Убеди-тесь также, что размер пакетного чтениядля операции полного сканирования табли-цы ограничен максимальным размером фи-зического чтения операционной системы. Кпримеру, если размер блока данных Вашей

3 Под транзакцией здесь понимается выполнение операто-ров insert, update, delete, или select . . . for update

4 Формально, «таблица списка входов транзакций» на-зывается списком интересующихся транзакций (interestedtransactions list), или ITL.

СУБД равен 32KB и параметр db_file_-multiblock_read_count равен 32 то малове-роятно, что Вы сможете выбирать 1MB =32KB × 32KB за одну физическую операциючтения.

• Redo-размер — Процесс, пишущий в жур-нальные файлы Oracle (LGWR) записываетцелые блоки при изменениях в файлах дан-ных табличных пространств, переведенныхв состояние резервного копирования. Поэто-му решение уменьшить объем генерируемойredo-информации в течение «горячего» ре-зервного копирования, может мотивироватьВас ограничить размер блока данных Oracle.

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

• Ограничения параллелизма — Максималь-ное значения для параметров initrans иmaxtrans равно 255. Если блок данныхСУБД Oracle при обычных нагрузках полу-чает более 255 запросов от транзакций наизменение, то это значит, что размер бло-ка данных выбран слишком большим. Шан-сы возникновения токай ситуации близки кнулю: если действительно 255 транзакцийодновременно модифицируют один блок, торезультирующая конкуренция за фиксаторыбудет настолько серьезной, что Вам непре-менно придется увеличить параметр pctfreeдля такого сегмента.

3 Дисковая конфигурация

Сердцем хорошей СУБД является надежная ипроизводительная подсистема ввода/вывода. По-этому проектирование подсистемы ввода/вывода— важная тема при создании любого приложенияс использованием VLDB.



3.1 Структурный анализ конфигура-ции

На самом высоком уровне абстракции опреде-ление требований к системе является простым де-лом, поскольку все мы желаем трех вещей: произ-водительности, надежности и низкой стоимости.Однако когда мы преобразуем эти общезначимыецели во что-то конкретное, мы сталкиваемся срешениями, основанными на компромиссах. Дляпонимания возникших конфликтов, Вы должнысделать две вещи: (1) понять Ваши цели и (2)разобраться в Ваших технологиях. Весь фокусзаключается в поиске верной микстуры из ско-рости, надежности и стоимости, которая удовле-творит специфичные нужды Вашего бизнеса. Этоозначает что решение, верное для, Вас не всегдабудет подходящим для Вашего соседа.Архитектурные ограничения приходят к нам из

двух источников: (1) это экономические ограни-чения и (2) это технологические ограничения.Экономические ограничения Вам должны бытьясны очень хорошо, и я уверен, Вы не желаетеиметь с ними дело. Однако, даже если вообра-зить, что Вы можете приобрести любое оборудо-вание и программное обеспечение, какое толькопожелаете, Вы все равно столкнетесь с ограниче-ниями технологическими.Предположим, к примеру, что Вы имеете

OLTP-приложение и Вы оптимизировали диско-вую конфигурацию Вашего сервера Oracle длядостижения максимальной производительностипри случайном вводе/выводе в ущерб производи-тельности последовательного доступа к данным.Такое решение может выглядеть вполне разум-ным, поскольку доступ к файлам OLTP-базы дан-ных в подавляющем большинстве основан на опе-рациях чтения с использованием хорошо опреде-ленных индексов или хэш-структур, а также про-извольных (scattered) операциях записи.Однако первый же опыт реорганизации ин-

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

время его реорганизации.Этот пример, как сотни подобных, указыва-

ют нам на важность и трудоемкость пониманияВаших требований и постижения Ваших техно-логий. Наиболее важным Вашим инструментомдолжен стать метод структурного анализа, кото-рый поможет Вам найти правильные ответы наВаши вопросы. В этой статье мы будет струк-турировать анализ конструкции подсистемы вво-да/вывода с помощью разбиения на производи-тельность, доступность и стоимость:

• Производительность

– Скорость случайного чтения

– Скорость случайной записи

– Скорость последовательного чтения

– Скорость последовательной записи

– Влияние параллелизма

• Доступность

– Частота отказов

– Продолжительность простоя

– Снижение производительности при от-казах

• Стоимость

– Стоимость приобретения

– Стоимость обслуживания

В статье мы оценим несколько инструментов итехник в контексте этих категорий. Их описаниедано в последующих разделах.

3.1.1 Производительность

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


Carry V. Millsap 7

• Производительность случайной записи —примером могут служить все операции за-писи данных, индексов и сегментов откатапроцессом DBWR. Эта категория составляетсущественную часть общей массы операцийзаписи в OLTP-системах в период основнойработы. Для хранилищ данных данная кате-гория составляет незначительную или нере-гулярную долю нагрузки.

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

• Производительность последовательной за-писи — примером служит работа LGWR-процесса, запись во временные сегменты,прямые загрузки данных (direct-load), со-здание индексов, создание табличных про-странств и операция восстановления. Проек-тировщики, акцентируясь на транзакциях иобработке запросов иногда забывают эту ка-тегорию. Хотя во время первичной загрузкиданных и в течении всей эксплуатации ба-за данных любого типа генерирует большоечисло операций последовательной записи.

• Влияние параллелизма — в каждой из кате-горий, упомянутых выше, архитектор долженрассмотреть влияние различных уровней па-раллелизма.

3.1.2 Доступность

• Частота отказов — ожидаемое число случа-ев возникновения отказов в единицу време-ни. Частота отказов определяется с помощьюMTTF (mean time to failure — среднее вре-мя возникновения отказа). Для примера, у

жесткого диска с MTTF равным 20,000 ча-сов можно ожидать отказ каждые 23 года.

• Продолжительность простоя — стоимостьпростоя может быть оценена в деньгах, ко-личество которых определяются как некото-рая функция от продолжительности простоя.Стоимость простоя для некоторого событияпропорциональна показателю среднего вре-мени восстановления (MTTR, mean time torepair) для данного события — чем дольшепродолжительность простоя, тем выше стои-мость.

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

3.1.3 Стоимость

• Стоимость приобретения — экономическаяоценка закупки системы.

• Стоимость обслуживания — стоимость экс-плуатации и поддержания системы. Стои-мость обслуживания состоит из эксплуата-ционных издержек, которые зависят от на-дежности системы и из административныхзатрат, зависящих от сложности системы.Например, система сложная в обращении,требующая более подготовленных операто-ров и техников по ремонту, будет иметь бо-лее высокую стоимость обслуживания.

3.1.4 Метод анализа

Декомпозиция на производительность, надеж-ность и стоимость дает нам важный инструментдля построения хорошей системы. Он позволя-ет нам оценить компромиссы как в пределах од-ной категории (например — скорость выполне-ния случайного чтения за счет последовательного



чтения), так и понять влияние одной категориина другую (например — сильную связь междускоростью выполнения последовательной записии продолжительностью простоя).Эти категории также позволяет нам формали-

зовать наши рассуждения о системе. К приме-ру, понимание разных составляющих понятия на-дежности дает нам возможность изучать их неза-висимо: (1) мы можем фокусировать усилия наснижении частоты отказов или (2) мы можемпопытаться снизить продолжительность простоеввследствие отказов, которые мы предотвратить нев силах. И это напоминает нам еще раз, что про-должительность простоя является частично во-просом надежности, а частично — вопросом про-изводительности.Последующие разделы помогут Вам прове-

сти высокоуровневый анализ взаимосвязей про-изводительности, доступности и стоимости припроектировании подсистемы ввода/вывода дляСУБД Oracle. Этот раздел поможет Вам лучшепонять Ваши задачи и технологии, поможет сде-лать Вам более информированные решения, что-бы Вы получили наилучший результат от Вашихинвестиций.

3.2 RAID

На втором месте по ненадежности, после чело-века, в компьютерных системах, является жест-кий диск. Для увеличения надежности дис-ков большинство поставщиков решений сего-дня предлагают дисковые массивы, называемыеRAID — избыточные массивы недорогих дисков(redundant arrays of inexpensive disks). RAID-массивы представляют собой высокопроизводи-тельные, устойчивые к отказам подсистемамиввода/вывода, которые используют менее дорогиетехнологии жестких дисков чем те, что использу-ются в традиционных высоконадежных большихЭВМ.Понятие RAID было введено в 1987 году в ста-

тье опубликованной в Калифорнийском Универ-ситете [9, Patterson et al.(1988)]. Номера уров-ней RAID означают разную организацию простыхтехнологий дисков для достижения производи-тельности и надежности при относительно невы-сокой стоимости.Наиболее важными уровнями RAID, которые

должен понимать архитектор VLDB Oracle явля-

ются 0, 0+1, 3 и 5. Рисунок 1 дает концептуаль-ное представление об этих RAID-конфигурациях.Обратите внимание, что поставщики RAID могутвыбрать для реализации функций чередования изеркалирования либо программное, либо аппарат-ное решение. Этот выбор влияет на количество итипы контроллеров необходимых для реализацииRAID-массива.Производительность, предлагаемая RAID-

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

RAID-массивов в надежности. Дисковая систе-ма, состоящая из сотни дисков с MTTF рав-ной 200.000 часов, сконфигурированная без из-быточности имеет среднее время до потери дан-ных (MTTDL) меньшее чем 83 дня. Та же сотнядисков, организованная в RAID-массив с нали-чием избыточности имеют MTTDL порядка 26лет [Chen et al.(1992), 161-163]. Среднее времявосстановления RAID-конфигураций также пре-восходно. Вы можете изъять диск из активногоRAID-массива 5 уровня и система, тем не менее,будет продолжать работать.Однако, каждая RAID-конфигурация имеет

свою, уникальную, стоимость. Вы можете обна-ружить, что система, которая действительно удо-влетворяет Вашим нуждам слишком дорога, аконфигурация, которую Вы в состоянии себе поз-волить, несет с собой много компромиссных ре-шений. Архитекторы систем на базе СУБД Oracleдолжны двигаться в извилистом лабиринте ком-промиссов, принимая решение о способе приме-нения RAID-массивов.Несколько авторов сделали блестящую работу,

описывая RAID-конфигурации и оценивая RAID-структуры с точки зрения надежности, произво-дительности и стоимости ( [1, Chen et al.(1994)];[2, Gui (1993)]; [11, Sun (1995)]; и многие дру-гие). Последующие разделы содержат итоги этихидей с конкретными рекомендациями о том когдаи как использовать каждый тип RAID-массива


Carry V. Millsap 9

для приложений СУБД Oracle.

3.2.1 Определения

Учебная литература о RAID может иногда вве-сти в заблуждение, поскольку авторы из конъ-юнктурных соображений могут интерпретироватьопределения так как им необходимо. Для того,чтобы сделать эту статью максимально простой,определим предварительно некоторые термины.

• Массив — RAID-конфигурация 0, 0+1, 3 и5 уровня, в которой диски группируются внаборы, называемые группами с коррекци-ей ошибок или дисковыми массивами. Мыбудем называть группу дисков собранных вгруппу с коррекцией ошибок массивом.

• Сегмент чередования — чередование(striping), это программная или аппаратнаявозможность, при которой логически непре-рывные данные записываются порциями,распределенными между дисками в массиве5 . Эти порции называются сегментами.

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

3.2.2 Чередование без избыточности(RAID уровня 0)

RAID 0 является дисковой конфигурациейбез избыточности с чередованием. Чередование,сконфигурированное соответствующим образом,

5 Обратите внимание — striping пишется с одной буквойp.

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

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

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

• Производительность при случайной записи— та же, что и для случайного чтения.

• Производительность при последовательномчтении — отличная при малом размере сег-мента чередования в средах с низким уров-нем параллелизма. Также отличная в средахс высоким уровнем параллелизма при усло-вии, что каждый запрос на чтение попада-ет в один сегмент чередования. Использова-ние слишком малого размера сегмента чере-дования может привести к резкому сниже-нию производительности в средах с высокимуровнем параллелизма.

• Производительность при последовательнойзаписи — та же, что и для последователь-ного чтения.

• Частота отказов — неудовлетворительна. От-каз любого диска массива будет причинойотказа приложений, требующего процедурывосстановления носителя Oracle для каждо-го приложения, имеющего данные на этоммассиве.

• Длительность простоя — неудовлетворитель-на. Продолжительность простоя RAID 0 со-стоит из времени, необходимого на обнару-жение неисправности, замены диска и вы-



Рис. 1. Обзор RAID-архитектур


Carry V. Millsap 11

полнении процедуры восстановлении носите-ля сервера Oracle.

• Снижение производительности в течение от-каза — неудовлетворительно. Любой диск,вышедший из строя, влечет за собой остановприложений, данные которых располагалисьна дисковом массиве, до полного завершенияпроцедуры восстановления носителя Oracle.

• Стоимость приобретения — отличная.RAID 0 является наименее дорогой RAID-конфигурацией.

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

3.2.3 Зеркалирование (RAID уровня 1)

Зеркалирование является фундаментальныминструментом архитектора VLDB для снижениячастоты отказов дисков. Диски с поддержкой зер-кальных копий — это системы, в которых иден-тичные копии Ваших данных записываются надва или более дисков при каждой операции запи-си, что позволяет Вашим приложениям работатьдо тех пор, пока цела хотя бы одна из копий.Несмотря на то, что наблюдается определеннаяпотеря производительности при выполнении опе-рации записи в массивах с зеркалированием посравнению с конфигурациями без избыточности,зеркалирование обеспечивает наилучшую произ-водительность операции записи среди дисковыхконфигураций, устойчивых к сбоям. Зеркалиро-вание особенно полезно для хранения файловданных Oracle с высокой интенсивностью запи-си. Многие архитекторы используют зеркалиро-вание для защиты оперативных и архивных жур-нальных файлов даже тогда, когда стоимостные

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

Дублирование адаптеров, шин и источниковпитания делает зеркалирование еще более нечув-ствительным к отказам оборудования. В продуб-лированной конфигурации с зеркалированием, n–уровневая избыточность использует n одинако-вых адаптеров. На сегодняшний день несколь-ко клиентов компании Oracle используют трех-уровневое дублирование для достижения гибко-сти операции восстановления. Тройное зеркали-рование обеспечивает устойчивость к отказам по-добно двойному зеркалированию и позволяет ад-министратору БД восстанавливать СУБД на лю-бое время в прошлом без использования стриме-ров. Позже мы обсудим одну технику тройногодублирования.

• Производительность при случайном чтении— хорошая. Если реализация контроллераRAID 1 оптимизирует операцию чтения, тонесколько выше, чем у независимого диска,в противном случае — идентична независи-мому диску. Контроллер RAID 1 с оптими-затором будет обслуживать запрос на чте-ние, используя ту копию, для которой сто-имость выполнения операции чтения мини-мальна, оставляя другой диск(и) в зеркаль-ной группе для параллельного обслуживаниядругих запросов.

• Производительность при случайной записи— хорошая. Если реализация контроллераRAID 1 использует оптимизацию чтения, тонесколько хуже, чем у независимого дис-ка, в противном случае — идентична неза-висимому диску. Хотя запись нескольких ко-пий может выполняться параллельно, ско-рость всей операции записи ограничена ско-ростью самого медленного устройства. Ценазаписи n–уровневой реализации RAID 1 рав-на max(w1, w2, · · · , wn), где wi — цена запи-си на i–тое устройство. Оптимизация чтенияданных рассинхронизирует состояния зерка-лированных дисков, вследствие чего wi 6= wj

для i 6= j даже для идентичных дисков.

• Производительность при последовательномчтении — удовлетворительная. См. произ-водительность при случайном чтении. Про-



пускная способность ограничена производи-тельностью одного диска.

• Производительность при последовательнойзаписи — удовлетворительная. См. произво-дительность при случайной записи. Пропуск-ная способность ограничена производитель-ностью одного диска.

• Частота отказов — отличная. N–уровневоедублирование дисковой системы может обес-печить работоспособность системы при вы-ходе из строя до n − 1 дисков в зеркаль-ном наборе. Однако RAID 1 не устраняетпроблемы выхода из строя адаптера, шиныввода/вывода, RAID-контроллера, источни-ка питания, аппаратных или программныхошибок. Для устранения этих видов оши-бок необходимо дублирование оборудования.При n–кратном дублировании всех компо-нент система останется работоспособной привыходе из строя до n−1 адаптеров, шин вво-да/вывода и пр. в пределах одного комплектадублирования. Дублирование является наи-более отказоустойчивой дисковой конфигу-рацией.

• Длительность простоя — отличная. Продол-жительность отказа вызванного n − 1 илименьшим числом дисков или других продуб-лированных компонент равно периоду време-ни, необходимому для замены этих компо-нент. В течение этого времени все прило-жения находятся в рабочем состоянии. Про-должительность простоя при потере данных,обусловленной выходом из строя всех n дис-ков сопоставима с показателем для RAID 0конфигурации. В этом случае все зависимыеприложения будут недоступны.

• Снижение производительности в течение от-каза — отличное. При выходе из строя дискав RAID 1 не будет наблюдаться сниженияпроизводительности всего массива. Однако,на время замены диска, операция включениянового диска в массив будет генерироватьбольшой объем ввода/вывода в восстанавли-ваемой зеркальной группе, что может приве-сти к существенному снижению производи-тельности приложений, читающих или запи-сывающий данные на эту зеркальную груп-

пу. Замена других продублированных аппа-ратных компонент не влечет за собой сниже-ния производительности.

• Стоимость приобретения — плохая. Стои-мость емкости при n–уровневом зераклиро-вании в n раз выше, чем стоимость аналогич-ной емкости для RAID 0. Реализация RAID 1требует специального контроллера RAID 1в дополнение к тому же числу адаптеров,что и для RAID 0. Полное зеркалированиеограничено возможностями подсистемы вво-да/вывода, поскольку n–уровневое зеркали-рование требует в n раз больше посадочныхмест, чем конфигурации без избыточности.

• Стоимость обслуживания — удовлетвори-тельная. Стоимость включает обучение пер-сонала администрированию систем с исполь-зованием зеркалирования, разработку про-граммного обеспечения для интеграции про-цедур зеркалирования в плановые операцииобслуживания и т.д.

3.2.4 Чередование и зеркалирование(RAID уровня 0+1)

Чередование и зеркалирование могут быть объ-единены в то, что многие люди сегодня называют«RAID 0+1» 6 . RAID 0+1 объединяет все преиму-щества и недостатки присущие RAID 0 и RAID 1:отличную производительность, отличную устой-чивость при отказах дисков и высокую стоимостьприобретения. Дублирование дисковых массивовс чередованием является основой для построе-ния высокозагруженных OLTP-приложений, ре-шающих критически важные задачи.

• Производительность при случайном чтении— отличная при всех уровнях параллелиз-ма при условии, что каждый запрос на чте-ние использует один сегмент чередования.Использование слишком малого размера сег-мента чередования может привести к резко-му ухудшению производительности при вы-соком уровне параллелизма. Несколько вы-ше, чем в RAID 0, если используется опти-мизация чтения RAID 1.

6Обратите внимание, что изобретатели термина RAIDвключили в понятие RAID 1 возможности «RAID 0+1» [1,Chen et al.(1994), 153]. Поставщики оборудования обеспечи-ли термину «RAID 0+1» насыщенную и счастливую жизнь.


Carry V. Millsap 13

• Производительность при случайной запи-си — отличная даже при очень высокомуровне параллелизма. Несколько хуже, чемв RAID 0, но много лучше, чем в RAID 5.См. производительность случайной записи вRAID 1.

• Производительность при последовательномчтении — отличная при всех уровнях па-раллелизма при условии, что каждый запросна чтение использует один сегмент чередова-ния. Использование слишком малого разме-ра сегментов чередования может привести крезкому ухудшению производительности привысоком уровне конкуренции. Несколько вы-ше, чем в RAID 0, если используется опти-мизация чтения RAID 1.

• Производительность при последовательнойзаписи — отличная. Несколько хуже чем,чем для RAID 0, но лучше чем для RAID 5.См. производительность последовательнойзаписи в RAID 1.

• Частота отказов — отличная. Та же, что идля RAID 1.

• Длительность простоя — отличная. Та же,что и для RAID 1.

• Снижение производительности в течение от-каза — отличное. То же, что и для RAID 1.

• Стоимость приобретения — плохая. Та же,что и у RAID 1 плюс возможны дополнитель-ные затраты на программное или аппаратноеобеспечение для поддержки чередования.

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

3.2.5 Побитовое чередование (RAID уровня3)

RAID 3 является ответом высокой стоимостиудвоенной избыточности RAID 1. В конфигура-

ции RAID 3 диски организованы в массив, в ко-тором один диск выделен для хранения контроль-ных данных, расположенных на других дисках.В RAID 3 размер сегмента чередования равен1 биту. Конфигурация имеет свойство, котороепозволяет реконструировать данные любого дис-ка с помощью данных, расположенных на другихдисках, используя операцию исключающего ИЛИ(XOR).

Основное достоинство RAID 3 заключается вмного более низкой стоимости чем у RAID 1.Однако низкая производительность выполненияслучайных операций ввода/вывода и низкая про-изводительность при частичном отказе масси-ва делают RAID 3 практически непригоднымдля большинства серверных приложений Oraсle.RAID 3 является лучшим решением для приложе-ний Oracle у которых экономические ограниченияперевешивают требования надежности, с плохооптимизируемыми операциями полного сканиро-вания таблиц, без операций модификаций БД.

• Производительность при случайном чтении— плохая. Синхронизация дисков препят-ствует параллельному выполнению малыхслучайных запросов чтения. Плохая произ-водительность при высоком уровне паралле-лизма.

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

• Производительность при последовательномчтении — очень хорошая для приложений снизким параллелизмом; ухудшается при по-вышении параллелизма.

• Производительность при последовательнойзаписи — очень хорошая для приложений снизким параллелизмом; ухудшается при по-вышении параллелизма.

• Частота отказов — хорошая. RAID 3 можетвыдержать потерю любого диска в массивебез перевода приложения в состояние про-стоя. Потеря двух дисков в массиве станетпричиной простоя и потребует выполнения



восстановления носителя. Обратите внима-ние, что устойчивость реализации RAID 3деградирует с ростом числа дисков в масси-ве и что, в конечном счете, эта деградацияможет привести к большим потерям, чем по-лученная, на стоимости приобретения, эко-номия. Например, удвоение числа дисков вRAID 3 с 5 до 10 сохранит примерно 14% отстоимости приобретения (см. раздел стоимо-сти приобретения RAID 3), в то же время этоудвоение увеличит частоту отказов на 100%.

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

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

• Стоимость приобретения — удовлетвори-тельная. Стоимость дисковой емкости вg/(g − 1) раз выше, чем стоимость той жеемкости для RAID 0, где g — число дисков вмассиве, плюс стоимость специальных дис-ков с синхронизацией и специального кон-троллера для RAID 3. Таким образом, сто-имость приобретения RAID 3 всегда будетвыше, чем стоимость RAID 0, но обычно

меньше, чем стоимость RAID 1 при g > 2.Обратите внимание, что стоимость полногополезного пространства снижается с увели-чением числа дисков в массиве. К примеру,использование массива с пятью дисками при-ведет стоимости, равной 125% от стоимостианалогичной емкости RAID 0, но использо-вание десяти дисков приведет лишь к 111%стоимости от стоимости RAID 0. RAID 3требует специального контроллера RAID 3 вдополнение к адаптерам, необходимым дляRAID 0.

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

3.2.6 Чередование блоков с распределеннымконтролем(RAID уровня 5)

RAID 5 подобен RAID 3 за исключение того,что размер сегмента чередования в RAID 5 мож-но настраивать, а также того, что контрольныеблоки распределены по всем дискам в массиве.Сегмент чередования RAID 5 содержит либо дан-ные, либо контрольную информацию. Любой за-прос на запись в массиве RAID 5 требует вы-полнения шести ресурсоемких операций [11, Sun(1995)]:

1. Чтение блока, в который должна произво-диться запись.

2. Чтение соответствующего контрольного бло-ка.

3. Вычет старой составляющей блока данных изконтрольного блока.

4. Добавление новой составляющей блока дан-ных в контрольный блок.

5. Запись контрольного блока.

6. Запись блока данных.


Carry V. Millsap 15

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

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

• Производительность при случайном чтении— отличная при всех уровнях параллелизмапри условии, что каждый запрос на чтениеиспользует один сегмент чередования. Ис-пользование слишком малых размеров сег-ментов чередования может привести к резко-му ухудшению производительности при вы-соком уровне конкуренции.

• Производительность при случайной запи-си — плохая. Наихудшая при высо-ком уровне параллелизма. Цикл чтение-изменение-запись, присущий RAID 5 и необ-ходимый для поддержания контрольной ин-формации делают его на порядок хуже всравнении с RAID 0. Использование диско-вого кэша может улучшить ситуацию, еслион имеет достаточный размер для обработкинеобходимого уровня параллелизма.

• Производительность при последовательномчтении — отличная при малом размере сег-мента чередования в средах с низким уров-нем параллелизма. Также отличная в средахс высоким уровнем параллелизма при усло-вии, что каждый запрос на чтение попада-ет в один сегмент чередования. Использова-ние слишком малого размера сегмента чере-

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

• Производительность при последовательнойзаписи — удовлетворительная в средах снизким уровнем параллелизма. При высокомуровне параллелизма может быть на поря-док хуже, чем у RAID 0. Большие объемыопераций записи заполняют дисковый кэшRAID 5, сводя к нулю его возможности посмягчению низкой производительности мас-сива. Как и для последовательного чтения,высокий уровень параллелизма при маломразмере сегмента чередования снижает про-изводительность.

• Частота отказов — хорошая. Выход из строялюбого одного диска в массиве не влияетна доступность массива RAID 5 и приложе-ний. Потеря двух дисков приведет к потереданных, которую можно устранить только спомощью восстановления носителя. Следуетотметить, что надежность RAID 5 падает сростом числа дисков в массиве и что потерянадежности может свести к нулю преимуще-ства от невысокой стоимости приобретения.См. частоту отказов для RAID 3.

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

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



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

• Стоимость приобретения — удовлетвори-тельная. Стоимость дисковой емкости вg/(g − 1) раз выше, чем стоимость той жеемкости для RAID 0, где g — число дис-ков в массиве, плюс стоимость контролле-ра RAID 5. Стоимость приобретения RAID 5всегда выше, чем стоимость RAID 0, но в об-щем, меньше, чем стоимость RAID 3 и тео-ретически меньше чем RAID 1 для g > 2.В реальной жизни, ожидания производитель-ности RAID 5 иногда превышают имеющие-ся возможности по конфигурированию. Сто-имость анализа и дополнительного оборудо-вания, в итоге, может оказаться даже выше,чем у RAID 0+1.

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

3.2.7 Резюме

Дисковые технологии развиваются столь стре-мительно, что сложно сделать заключение попроизводительности реализаций различных тех-нологий без некоторого рода обобщений, которыемогут быть в конкретных случаях неверными. Ес-ли Вы живете по золотому правилу знай свои це-ли и понимай доступные технологии, то Вы бу-дете периодически переосмысливать Ваши реше-ния. Лучший путь для осознания Ваших целей ипонимания имеющихся технологий — общение сопытными профессионалами и тщательная прак-тическая проверка Ваших суждений. Увеличениериска для бизнеса требует увеличения важностизадачи тщательного тестирования. Таблица 1 по-казывает оценки различных конфигураций RAIDспециально в применении к серверу Oracle.

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

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

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

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

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

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

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


Carry V. Millsap 17

Уровень RAIDНет 0 1 0+1 3 5

Производительность контрольного файла 2 1 2 1 5 3Производительность журнального файла 4 1 5 1 2 3Производительность пространства system 2 1 2 1 5 3Производительность сегментов сортировки 4 1 5 1 2 3Производительность сегментов отката 2 1 2 1 5 5Файлы с индексами, только чтение 2 1 2 1 5 1Файлы с только последовательным чтением 4 1 5 1 2 3Файлы с высокой активностью DBWR 1 1 2 1 5 5Файлы с интенсивной прямой загрузкой 4 1 5 1 2 3Защищенность данных 4 5 1 1 2 2Стоимость приобретения и сопровождения 1 1 5 5 3 3

Таблица 1. Обзор относительной пригодности RAID-конфигураций от 1 (наилучшая) до 5 (наихудшая) дляразличных типов файлов Oracle. RAID 0+1 является наилучшим техническим решением, но вместе с тем, исамым дорогостоящим. Разумное применение RAID 5 массивов позволяет архитекторам дисковых подсистемснизить стоимость системы с минимальными потерями производительности и надежности. Данные из [11, Sun(1995), 28].

размером сегмента, мы можем сделать некото-рые заключения об его использовании с сервером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 7.Массив с малым размером сегмента чередова-

ния может оказаться плохим выбором для хра-нения табличного пространства, которое исполь-зуется сервером Oracle для создания сегментов

7 В Oracle 7.3 значение db_file_multiblock_read_countможет настраиваться на уровне сессии, что дает более полныйконтроль над производительностью операций полного скани-рования



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

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

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

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

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

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

8 Если быть более точным, LGWR записывает информациютолько в случае выполнения изменений в СУБД с помощьюстандартных операторов SQL. LGWR не записывает информа-цию при прямых загрузках данных (direct-path loads) илипри выполнении транзакций без поддержки восстановления(unrecoverable)

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

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

3.3.4 Трудности

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

• Планирование заданий — не запускайтебольших загрузок данных в то время, когдаимеется и без того высокая конкуренция заввод/вывод со стороны процессов решающих


Carry V. Millsap 19

важные задачи.

• Размещение данных — размещайте данныеВашей БД по файлам с подобными характе-ристиками ввода/вывода, размещайте файлыданных на одном массиве только в том слу-чае, если они имеют одинаковый профиль до-ступа. К примеру, плохо выглядит идея раз-местить на одном массиве с малым разме-ром сегмента чередования журнальные фай-лы, если Вы уже поместили на этот мас-сив другие файлы БД, поскольку при этомвозникнет конкуренция с процессом 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 9. Таким образом хорошими,для массивов с большим размером сегмента че-редования, можно считать размеры в диапазонеот 128KB до 512KB.

3.4 Размер массива

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

9 Максимальный размер блока ввода/вывода на физиче-ском уровне, поддерживаемый системами UNIX, составляетот 64KB до 512KB на большинстве платформ.

массивы. Однако увеличение числа дисков в мас-сиве ведет к росту частоты отказов. Рассмотримэти два вопроса вместе для определения методавыбора оптимального числа дисков в массиве.

3.4.1 Пропускная способность

Чередование, при корректном использовании,является прекрасным инструментом для уве-личения пропускной способности. Чередованиепредоставляет прозрачное распределение опера-ций ввода/вывода между относительно недороги-ми дисками. Это, с одной стороны, дает возмож-ность обслуживать одновременно большое числонебольших операций ввода/вывода, а с другой, —увеличить в разы скорость обмена больших опе-раций ввода/вывода по сравнению со скоростьюсамого быстрого диска [Chen et al. (1993), 151].Для расчета минимального размера RAID-

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

1. Определите устойчивую максимальную про-пускную способность каждого из Вашихжестких дисков. Этот показатель оценивает-ся как устойчивое максимальное число опе-раций ввода/вывода для каждого жесткогодиска 10. Обозначим этот показатель как c,размерность — число операций ввода/выводав секунду.

2. Оцените общее число t операций вво-да/вывода, которое будут генерировать одно-временно работающие транзакции.

3. Рассчитайте общее число r физических опе-раций ввода/вывода в секунду, которые тре-буются от Вашего RAID-массива, с уче-том размера сегмента чередования, исполь-зуя формулу:

r =k + 1

kt,

где k — размер сегмента чередования делен-ный на размер блока ввода/вывода (описание

10 Указанный устойчивый уровень операций ввода/выводарассчитывается поставщиком жесткого диска как наивысшийуровень которого может достичь диск с коэффициентом ути-лизации, не превышающем 60%–70%. Приведенное ограниче-ние на утилизацию дает возможность удерживать время ожи-дания в предсказуемых границах.


Carry V. Millsap 21

Парал-лелизм

Блок вво-да/вывода

Наилучший размерсегмента чередования

Примеры СУБД Oracle

низкий малый k × db_block_size,k = 2, 3, 4, . . .

DBWR

низкий большой k × db_block_size,k = 0.25, 0.5, 1, 2, 3, . . .

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

высокий малый k × db_block_size,k = 2, 3, 4, . . .

OLTP-системы

высокий большой k × db_block_size×db_file_multiblock_

read_count,k = 2, 3, 4, . . .

Массовые формирования от-четности, любые параллельныеоперации СУБД Oracle, любыеодновременно выполняющиесяпакетные задания с высокой за-грузкой ввода/вывода

Таблица 2. Оптимальный размер сегмента чередования как функция от уровня параллелизма и размера блокаввода/вывода. Размер сегмента чередования не должен совпадать с размером блока ввода/вывода в дисковыхмассивах с высоким уровнем параллелизма поскольку границы сегментов чередования не обязательно совпадутс границам блоков ввода/вывода. Таким образом, рекомендуемых размер сегмента чередования должен быть вk раз больше чем размер блока ввода/вывода что будет гарантировать, что каждый запрос ввода/вывода будетобслуживаться одним диском с вероятностью (k − 1)/k.



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

4. Рассчитайте минимальное число дисков g =r/c, которые необходимо включить в диско-вый массив, для поддержания требуемой на-грузки:

g = r/c =k + 1kc

t

5. Обратите внимание, что требуемая пропуск-ная способность r (определенная на шаге 2)может зависеть от размера Вашего диско-вого массива g (рассчитанного на шаге 4).Например, половина дисков от необходимогочисла, могут обслужить примерно половинузапросов на ввод/вывод от транзакций. По-ставщик оборудования может дать информа-цию о максимальном рекомендуемом числедисков в дисковом массиве.

Приведенные формулы могут использовать-ся для расчета дисковых массивов RAID 0 иRAID 0+1. Если Вы будете использовать этутехнику для расчета массива RAID 5, то Вамнеобходимо увеличить оценку необходимого чис-ла запросов на ввода/вывода на одну транзак-цию для отражения того факта, что этот массивимеет большие издержки при выполнении каж-дой операции записи. Влияние дискового кэша,уменьшающего степень этих издержек, несколь-ко усложняет эти вычисления.

3.4.2 Доступность

Расчет правильного размера дискового масси-ва в случае использования RAID 3 или RAID 5является несколько более трудоемким, чем про-сто расчет необходимых устройств для поддерж-ки требуемой пропускной способности. Дополни-тельные сложности связаны с падением произво-дительности конфигураций RAID 3 и RAID 5 вовремя отказа одного из дисков.

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

RAID 0+1 не падает в результате выхода из строядиска благодаря наличию зеркальной копии. Про-цедура расчета оптимального размера массиваRAID 1 или RAID0+1, таким образом, не огра-ничена приведенными выше соображениями.

3.4.3 Резюме

Не существует «наилучшего размера дисково-го массива», годного для любых приложений.Большие, по размеру, дисковые массивы имеютлучшую пропускную способность, но платой заэто является повышение частоты отказов дисковв массиве. Хорошо спроектированные дисковыеподсистемы могут иметь как несколько различ-ных RAID-конфигураций, так и несколько раз-личных размеров, в зависимости от хранимыхданных в каждом массиве.Для массивов RAID 1 и RAID 0+1, большие

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

3.5 Линейные устройства

Линейные устройства являются важным ин-струментом, который использует архитектор


Carry V. Millsap 23

VLDB, для снижения загрузки ЦПУ приложени-ями с высокой интенсивностью записи. Линей-ное устройство (raw device) — это неформати-рованный раздел диска в UNIX, который серверOracle может открыть как файл данных или какоперативный журнал минуя службы буферизацииввода/вывода UNIX-системы. Возможность сер-вера Oracle обходить буферизацию UNIX умень-шает объем кода операционной системы, которыйбудет выполнен при вызове операций записи. Всвязи с этим, линейные устройства рекомендуют-ся для хорошо спроектированных VLDB с высо-кими требованиями транзакционной пропускнойспособности.Линейные устройства, на сегодняшний день,

являются необходимыми, если Вы планируете ис-пользовать параллельный сервер Oracle (OracleParallel Server) под UNIX. Большинство UNIX-реализаций не позволяют двум узлам кластераиметь одновременный доступ к смонтированнойфайловой системе.

Стоимость обслуживания линейных устройстввыше чем для файловых систем UNIX (ufs) [4,Millsap (1995a), 15–17]. Но для VLDB с интенсив-ной записью эта цена крайне мала в сравнении состоимостью ненужной загрузки ЦПУ и уже безтого высокой ценой администрирования системыс сотнями или тысячами дисковых устройств.

• Производительность при случайном чтении— Крайне незначительно лучше по сравне-нию с ufs.

• Производительность при случайной записи— Значительно лучше, в сравнение с ufs, из-за уменьшения объема выполняемого кода.Линейные устройства также позволяют реа-лизовать асинхронный ввод-вывод, если онподдерживается операционной платформой.

• Производительность при последовательномчтении — Незначительно хуже в срав-нение с ufs. Использование линейныхустройств может катастрофически снизитьпроизводительность плохо оптимизирован-ных SQL-приложений по сравнению с ufs-реализацией, поскольку UNIX-кэшированиеработает лучше кэширования сервера Oracleпри полном сканировании таблиц.

• Производительность при последовательнойзаписи — Значительно лучше, в сравнение

с ufs, из-за уменьшения объема выполняе-мого кода и возможности асинхронного вво-да/вывода.

• Частота отказов — Риск возникновения воз-растает из-за необходимости в более опыт-ном администраторе.

• Длительность простоя — Риск увеличе-ния возрастает из-за необходимости в болееопытном администраторе.

• Снижение производительности в течение от-каза — Отличия от нормальной производи-тельности обусловлены замечаниями приве-денными выше.

• Стоимость приобретения — Та же, что дляufs.

• Стоимость обслуживания — Хуже, чем дляufs. Требуется большее обучение и оплататруда персонала для конфигурирования и об-служивания линейных устройств. Конфигу-рирование линейных устройств также тре-буют закупки или разработки программныхсредств для упрощения управления подси-стемой ввода/вывода. Различие стоимостиадминистрирования линейных устройств иufs незаметны на фоне общей стоимости си-стемы ввода/вывода для VLDB с тысячамидисков. Стоимость обслуживания оператив-ных журнальных файлов не изменяется, по-скольку эти файлы архивируются также какна ufs процессом ARCH.

3.6 Конфигурация Oracle

Не существует такой вещи, как единая опти-мальная конфигурация СУБД Oracle для всехVLDB-приложений. Ваша оптимальная смесьскорости, надежности и экономичности зависитот Ваших конкретных задач. Однако мы можетсделать некоторые заключения о том, как Вы мог-ли бы выполнить оптимизацию Вашей конфигу-рации VLDB, если бы Вы не были связаны эко-номическими ограничениями:

• Контрольные файлы

– n-кратное дублирование RAID 0+1



– размещение на независимых подсисте-мах ввода/вывода

– линейные устройства в случае OPS

• Оперативные журнальные файлы

– все файлы одного размера

– линейные устройства


– малый размер сегмента чередования

– размещение на выделенных дисках

• Архивные журнальные файлы

– ufs


– малый размер сегмента чередования

– размещение на выделенных дисках от-дельно от оперативных журнальныхфайлов

• Файлы данных

– все файлы одного из трех стандартныхразмеров

– линейные устройства, если файл актив-но изменяется, либо используется OPS

– ufs, если используется полное сканиро-вание таблиц


– размер сегмента чередования равен, какминимум, 2 × размер ввода/вывода, ес-ли высокий уровень параллелизма

– размер сегмента чередования меньшечем 2 × размер ввода/вывода, если низ-кий уровень параллелизма

– RAID 5, если низкая активность изме-нений файла

• Другие файлы

– ufs

– n-кратное дублирование RAID 1

– размещение согласно стандарту OFA

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

3.6.1 Примеры конфигураций

Вы можете смешивать и оценивать технологиибольшим числом способов. Три простых конфигу-рации БД сервера Oracle представлены в таблице3.Каждая из них требует разного уровня инве-

стиций для достижения заданных целей, опреде-ленных в конфигурации.

• Конфигурация A — Дублирование (n =2, 3) RAID 0+1 для всех файлов, линейныеустройства везде, где это возможно. Мо-жет использоваться для решения критическиважных задач, OPS, очень высокая скоростьтранзакций, очень высокая скорость выпол-нения запросов, сложность обслуживания,высокая стоимость.

• Конфигурация B — RAID 0+1 на линей-ных устройствах для файлов с интенсив-ным уровнем изменений, RAID 5 на ufs длянечасто изменяемых файлов. Сравнительновысокая доступность, непригодна для OPS,средняя скорость выполнения транзакций,очень высокая скорость выполнения запро-сов, средняя сложность обслуживания, сред-няя стоимость.

• Конфигурация C — RAID 0+1 на линей-ных устройствах для файлов с интенсивнымуровнем изменений, RAID 0 на ufs для всехостальных файлов Oracle. Непригодна длярешения критически важных задач, непри-годна для OPS, средняя скорость выполне-ния транзакций, очень высокая скорость вы-полнения запросов, низкая сложность обслу-живания, низкая стоимость.

4 Журнальные файлы

Сервер Oracle использует выделенный процесс,называемый (писателем журнальных файлов redolog writer, LGWR) для записи пакетов записейо транзакциях на диск. Работа LGWR позволяетсерверу Oracle записывать подтвержденные изме-ненные блоки на диск асинхронно по отношениюк пользовательским запросам на подтверждениетранзакций и поддерживать при этом целост-ность данных даже если сервер прервет свою ра-боту в самый неподходящий момент. Выделенный


Carry V. Millsap 25

КонфигурацияТип файла A B C

Оперативные журнальные raw 0+1 raw 0+1 raw 0+1system, temp, rbs raw 0+1 raw 0+1 ufs 0Другие файлы данных raw 0+1 ufs 5 ufs 0Архивные журнальные ufs 0+1 ufs 0+1 ufs 0+1Контрольные файлы ufs 0+1 ufs 0+1 ufs 0+1Другие файлы raw 0+1 ufs 5 ufs 0

Таблица 3. Примеры дисковых конфигураций для Oracle-приложений. Эта таблица описывает три простыеконфигурации с использованием линейных устройств (raw) и файловых систем UNIX (ufs) и различных RAID-массивов для решения разных бизнес-задач. Цели и достоинства конфигураций A, B и C описаны в тексте.

фоновый процесс для последовательного упорядо-чивания и пакетной записи векторов измененийна диск — это основа высочайшей производитель-ности сервера Oracle.

Производительность процесса LGWR являетсякритической для скорости работы OLTP-системи процедур загрузки данных которые не исполь-зуют возможность работы в режиме «без восста-новления» (unrecoverable). В средах, где не вы-полняются интенсивные изменения в базе данныхс помощью стандартных операторов SQL, LGWRне испытывает значительной нагрузки. Деграда-ция производительности и/или увеличение вре-мени простоя будут наблюдаться главным обра-зом в высокоинтенсивных OLTP-системах; имен-но поэтому задача конфигурирования журналь-ных файлов является темой этого раздела.

4.1 Баланс производительности и до-ступности

Борьба между производительностью и надеж-ностью особенно ярко проявляется на приме-ре журнальных файлов. Для оптимизации про-изводительности Вам необходимо конфигуриро-вать LGWR и DBWR так, чтобы операции записивыполнялись как можно реже. Однако для ми-нимизации времени, необходимого для выполне-ния доката данных (roll-forward) при восстанов-лении инстанции, Вам необходимо конфигуриро-вать LGWR и DBWR так, чтобы операции записипроизводились как можно чаще. Решение этойпроблемы заключается в достаточном пониманиитехнологий для того, чтобы выбрать значение па-раметра log_checkpoint_interval, которое былобы и достаточно большим и достаточно малым

для удовлетворения обоих требований.Понимание технологий, относящихся к кон-

фигурированию журнальных файлов, лежит восознании двух ключевых событий: контрольнойточки сервера Oracle и восстановление инстанциисервера Oracle.

4.2 Контрольные точки сервераOracle

Контрольная точка сервера Oracle — это со-бытие, которое начинается в момент, когдаLGWR оповещает DBWR о необходимости запи-си всех модифицированных блоков из кэша дан-ных СУБД, включая как подтвержденные, так ине подтвержденные данные, в файлы данных [8,Concepts (1992), 23, 9-12]. Контрольные точки вы-зывают непродолжительные периоды высокой за-грузки системы — эффект, который администра-тор базы данных стремится минимизировать с по-мощью настроек [7, Admin (1992), 24, 6-7]. Обыч-ные контрольные точки, возникающие в процессеработы, появляется в следующих случаях:

• Переключение журнального файла (logswitch) — когда LGWR заполняет текущийжурнальный файл и пытается переключить-ся на следующий в круговой очереди.

• Предопределенный интервал — LGWR бу-дет порождать контрольную точку либо ко-гда запишет число блоков операционнойсистемы равное значению параметра log_-checkpoint_interval, с момента последнейконтрольной точки, либо когда пройдет чис-ло секунд равное значению параметра log_-



checkpoint_timeout, с момента последнейконтрольной точки.

Размер журнального файла и параметры log_-checkpoint_interval и log_checkpoint_timeoutоказывают наиболее важное влияние на измене-ние производительности при обычной работе ме-ханизма контрольных точек. Многие администра-торы БД отключают тайм-аут, устанавливая егов ноль и регулируют работу механизма контроль-ных точек только с помощью параметра log_-checkpoint_interval. Некоторые администрато-ры деактивируют оба параметра и контрольныеточки возникают лишь вследствие переключенияжурнальных файлов.

4.3 Восстановление инстанции сер-вера Oracle

Длительность времени, необходимая для вы-полнения восстановления инстанции сервераOracle является важным параметром для архи-тектора VLDB, поскольку она определяет период,в течение которого приложение будет недоступнопосле возникновения следующих событий:

• Отказ узла без кластера — отказ процессора,шины или памяти на незащищенном с помо-щью кластера узле.

• Отказ узла параллельного сервера Oracle —отказ одного или нескольких узлов в кон-фигурации с параллельным сервером Oracleбудет причиной кратковременной недоступ-ности всего кластера, которая оканчиваетсяк моменту, когда «выжившие» узлы завершатвосстановление нитей отказавших узлов.

Реализация отложенного, «по требованию», от-ката в Oracle 7.3 делает период недоступностикластера зависящим, в основном, от времени ко-торое необходимо для реконструкции буферногокэша. Диаграмма, сравнивающая время восста-новления после отказа в Oracle 7.3 и Oracle 7.2,приведена на рисунке 2.Восстановление инстанции сервера Oracle —

настраиваемый процесс, время выполнения кото-рого, в основном, зависит от двух факторов [3,Maulik and Patkar (1995)]:

• Объем повторно-применяемой информации(redo-информации), которая была сгенериро-вана с момента последней контрольной точки(чем меньше, тем лучше), и

• Качество буферного кэша базы данных в те-чение выполнения восстановления (чем вы-ше, тем лучше).

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

ру, Вы можете достичь с помощью увеличенияразмера буферного кэша базы данных и умень-шения, тем самым, вероятности промахов в бу-ферном кэше в течение выполнения процедурывосстановления. Увеличение значение параметраdb_block_buffers для работы процесса восста-новления (ценой уменьшения значения парамет-ра shared_pool_size, если необходимо) в общем,уменьшает число промахов в буферном кэше. Втечение процедуры восстановления, при которомне требуется выполнения восстановления носи-теля, Вы не имеете других способов влиять напроцент попаданий в буферный кэш, посколькудолжна быть повторно применена вся информа-ция, которая была сгенерирована с момента по-следней контрольной точки 11.Меняя параметр log_checkpoint_interval в

диапазоне от нескольких килобайт до несколькихсотен мегабайт (в блоках операционной системы)можно достичь приемлемого компромисса с про-

11 Получены важные результаты, относящиеся к восстанов-лению носителя сервера Oracle, когда повреждены несколь-ко файлов данных. Рекомендуется сделать несколько цикловвосстановление-файла/восстановление-инстанции для каждо-го файла данных. В этом случае может наблюдаться луч-шее качество использования буферного кэша базы данных [3,Maulik and Patkar (1995)].


Carry V. Millsap 27

Рис. 2. Временная диаграмма восстановления после отказа для параллельного сервера Oracle 7.2и 7.3. OPS 7.3 откладывает откат транзакций для минимизации периода недоступности кластерапри отказе узла, что дает улучшение производительности восстановления по сравнению с OPS 7.2или ниже. В OPS 7.3 время завершения отката инстанции не связано с доступностью приложений,поскольку все откаты запускаются «по требованию», на уровне транзакций.

изводительностью в OLTP-среде. Скорость дока-та при восстановлении варьируется почти такжекак кардинально, как и требования к скоростидоката 12. В средах с жестко заданными требова-ниями к производительности и надежности малоеизменение log_checkpoint_interval может при-вести к значительному изменению времени вос-становления инстанции. Вследствие этого поископтимального значения log_checkpoint_intervalчасто требует тестирования в среде эксплуата-ции.

4.4 Размещение журнальных файлов

В хорошей конфигурации VLDB высокоактив-ные, с точки зрения ввода/вывода, журнальныефайлы должны быть изолированы от других фай-лов с высокой активностью ввода/вывода на-столько, насколько это возможно. Физическаяизоляция на выделенных дисках и контроллерахпозволит Вам снизить до минимума шанс возник-новения «узкого места» при выполнении опера-ций ввода/вывода в журнальные файлы. Техникаизолирования хорошо комбинируется с рассмот-

12 Администраторы СУБД Oracle дают большой разброспри оценке скорости доката. Я слышал как низкие оценки —50KB/сек, так и высокие — до 1,750KB/сек.

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

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

Сервер Oracle позволяет, если Вы этого же-лаете, архивировать журнальные файлы непо-средственно на ленточное устройство. Имеетсянесколько причин, из-за которых администрато-ры VLDB почти всегда выполняют архивированиена диск и лишь потом делают n копий файлов наленточный накопитель.

• Надежность лучше — ленточный накопи-



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

• Пропускная способность лучше — вы долж-ны помнить, что ARCH-процесс не являетсячисто потоковым процессом копирования, новыполняется лучше на устройствах с воз-можностью произвольного доступа (randomI/O). Архивирование на диск выполняетсянамного быстрее чем на ленточный накопи-тель, что в свою очередь снижает вероят-ность возникновения ненужного «узкого ме-ста».

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

• Время восстановления быстрее — многие ад-министраторы БД хранят максимально воз-можное число архивных журнальных фай-лов на дисках, которые могут быть необхо-димы для восстановления с момента послед-него «горячего» копирования. Такая техникауменьшает продолжительность процесса вос-становления на время необходимое для на-хождения требуемой ленты, ее монтированияи чтения с нее архивных журнальных файловна диск.

4.5 Размер журнального файла

Оптимальный размер журнального файла всистеме зависит от объема генерируемой redo-информации и требований к продолжительностивосстановления инстанции. Для расчета правиль-ного интервала между контрольными точками иразмера журнального файла для Вашей системыиспользуйте следующий метод:

1. Определите требования к времени восста-новления после краха. Обозначим это время,заданное в секундах, как t.

2. Рассчитайте скорость, с которой системаприменяет redo-информацию при восстанов-лении инстанции. Обозначим эту скорость,заданную в байтах в секунду, как r.

3. Установите значение параметра log_-checkpoint_interval в r × t/b, где b —размер блока ввода/вывода в байтах вВашей операционной системе.

4. Создайте журнальные файлы размером f =k × r × t, для некоторого целого k (т.е. fкратно r × t).

5. Если новые контрольные точки накап-ливаются без завершения предыдущих,то Вы должны увеличить значениеlog_checkpoint_interval. Вы можетеопределить частоту возникновения та-ких ситуаций сравнив значения ста-тистик background_checkpoints_startedи background_checkpoints_completed изv$sysstat. Если значения отличаются бо-лее чем на 1, значит контрольные точкине завершались к тому моменту, когданачинались новые.

6. Установите log_buffer в l = 3×n×s, где n —число дисков в массиве, хранящем журналь-ные файлы и s — размер сегмента чередова-ния массива в байтах. Наибольший размероперации записи, генерируемый LGWR, будетпримерно равен l/3 = n× s 13.

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

• снижение частоты переключения журналь-ных файлов;

13 В OLTP-операциях, частые подтверждения транзакцийбудут порождать записи LGWR и LGWR будет делать оченьмного малых записей. В пакетных операциях, нечастые под-тверждения транзакций будут порождать большие объемы незаписанной в журнальный файл информации, расположеннойв журнальном буфере. Если информация будет накапливать-ся быстрее, чем LGWR будет получать команды для записи, тозаполненность буфера более чем на 1/3 будет основанием дляначала записи до l байт, где l — размер журнального буфера,заданного с помощью log_buffer.


Carry V. Millsap 29

• упрощение процедуры размещения журналь-ных файлов;

• снижение сложности при полном восстанов-лении за счет снижения числа обрабатывае-мых файлов;

• снижение частоты возникновения событийожидания контрольных точек и занятостипроцесса архивирования.

Факторы, которые будут влиять на выбор мень-шего значения, могут быть следующими:

• снижение стоимости отказа, связанной с по-терей всех копий активного журнальногофайла 14;

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

• снижение потерь данных в конфигурациях срезервной (standby) БД.

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

4.6 Число журнальных файлов

Число оперативных журнальных файлов даетВам возможность определить, будут ли контроль-ные точки и архивирование журнальных файловпричиной возникновения «узких мест» при обра-ботке транзакций. Выбор правильного числа жур-нальных файлов поможет Вам снизить:

• Ожидания занятой контрольной точки(checkpoint busy wait) — ожидание занятойконтрольной точки возникает, когда LGWRпытается переключиться на журнальныйфайл до того, как связанная с этим жур-нальным файлом предыдущая контрольнаяточка была завершена.

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

• Ожидание занятого процесса архивирования(archiver busy wait) — ожидание занято-го процесса архивирования возникает, когдаLGWR пытается переключиться на журналь-ный файл, который еще не было скопиро-ван в архивный журнальный файл процессомARCH.

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

1. Проверьте событие log file switch (checkpointincomplete) в v$session_wait. Если Вы уста-новили параметр log_checkpoints_to_alert взначение true, то Вы можете определить воз-никновение этой ситуации с помощью тек-стового вхождения «cannot allocate» в файлеalert.log.

2. Снизить частоту возникновения событияожидания контрольной точки Вы можете:

• увеличивая число оперативных жур-нальных файлов для снижения вероят-ности того, что LGWR сможет заполнитьвсе файлы до того, как будет завершенаконтрольная точка; или

• добавляя DBWR процессы для увеличе-ния скорости выполнения контрольнойточки (только если Вы используете син-хронную запись); или

• увеличивая значение параметра db_-block_checkpoint_batch для увеличе-ния скорости выполнения контрольнойточки; или

• уменьшая значение параметра db_-block_buffers для снижения объема ра-боты в контрольной точке; или

• снижая число и размеры сегментов от-ката в базе данных (описанных в ниже-следующем разделе)



Событие ожидания занятого процесса архиви-рования обычно возникает при генерации боль-шого числа транзакций во время пакетной об-работке, когда скорость записи redo-информацииLGWR превышают возможности копирования про-цесса ARCH. Оно также служит причиной возник-новения ожидания контрольной точки — ARCHстановится «узким местом» для завершения всехтранзакций в системе.Следующие техники могут использоваться для

смягчения проблемы:

• Чередование с малым размером сегмента— разместите Ваши архивные журнальныефайлы на дисковом массиве с малым раз-мером сегмента чередования для увеличе-ния скорости обращения к файлам процессомARCH.

• Большее число оперативных журнальныхфайлов — создайте достаточное число опе-ративных журнальных файлов с тем, что-бы LGWR не смог заполнить все журнальныефайлы до того как процесс ARCH закончилкопировать.

• Увеличение числа ARCH-процессов — исполь-зуйте несколько ARCH-процессов с помощьюкоманды сервера Oracle alter system archivelog all to . . . . Консультанты службы под-держки Oracle подготовили несколько ин-струментов для автоматизации этого процес-са.

5 Планирование табличныхпространств

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

• Производительность операций ввода/вывода— каждое табличное пространство должновключать сегменты, имеющие схожие харак-теристики ввода/вывода (уровень паралле-лизма, объем) — такое разбиение упростит

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

• Устойчивость к отказам — малые таблич-ные пространства позволяют минимизиро-вать простой приложения во время работ,требующих перевода этих табличных про-странств в автономный режим (offline). Таб-личное пространство system не может бытьпереведено в автономный режим, также какне может быть удалено и пересоздано, поэто-му храните минимально необходимое числосегментов в этом табличном пространстве.Изоляция сегментов отката в минимальнонеобходимом числе табличных пространствснижает частоту возникновения простоев,поскольку табличное пространство с актив-ным (online) сегментом отката невозможноперевести в автономный режим. Хранениесвязанных, с помощью ссылочной целостно-сти, сегментов в небольшой группе таблич-ных пространств даст Вам возможность ис-пользовать процедуру восстановления на за-данный момент времени («point-in-time), вве-денную в Oracle8.

• Управление пространством — изоляция сег-ментов с коротким временным жизненнымциклом минимизирует влияние фрагмента-ции свободного табличного пространства, ко-торая может блокировать выделение новыхэкстентов сервером Oracle. Администрато-рам VLDB принесет пользу возможность ис-пользования умалчиваемых параметров хра-нения, определенных на уровне табличногопространства, вместо явного указания этихпараметров в описании сегментов.

• Управление квотами — управление квотамипространства в сервере Oracle выполняетсяна уровне пользователей и табличных про-


Carry V. Millsap 31

Рис. 3. Ожидания занятого процесса архивирования. Рисунок демонстрирует, каким образом быст-рый LGWR-процесс может обогнать медленный ARCH-процесс, что приведет к возникновению «узкогоместа» и к снижению производительности. Эпизод (a) демонстрирует состояние инстанции сразупосле старта — процесс LGWR пишет в файл A, процесс ARCH ничего не делает. В эпизоде (b) LGWRпереключился на запись в файл B, позволяя ARCH открыть A и начать его архивирование. В (c)LGWR переключился на файл C, в то время как ARCH еще не обработал A. В эпизоде (d) ARCHпереключился на обработку файла B, в (e) LGWR пишет в файл A. В эпизоде (f) LGWR пытаетсяпереключиться на файл B, но не может выполнить этого, поскольку ARCH еще не сделал его архив-ную копию. Начиная с этого момента, из-за ARCH, системой будут блокироваться попытки фиксациитранзакции до тех пор, пока ARCH не переключиться на файл C.



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

5.1 Назначение сегментов таблич-ным пространствам

Метод, приведенный ниже, поможет Вам при-нять решение о том как разделить сегменты потабличным пространствам.

1. В табличном пространстве system хранитетолько сегменты словаря данных (сегмен-ты, принадлежащие схеме sys). Перенеситетаблицу aud$ в табличное пространство от-личное от system, это позволит Вам управ-лять размером таблицы (усекать ее) не влияяна фрагментацию свободного пространствав табличном пространстве system. Некото-рые эксперты рекомендуют отредактироватьфайл sql.bsq (только строки расположенныениже вхождения //) с тем, чтобы изменитьпараметры хранения таблиц словаря данных,связанных с хранимыми процедурами и триг-герами. Для полной уверенности, делайтеэто совместно со службой поддержки Oracle.

2. Создайте два или более табличных про-странства, предназначенных исключительнодля временных сегментов. Создайте програм-му, которая позволит быстро переключатьна доступное временное табличное простран-ство, отличное от system, в случае недоступ-ности стандартного временного табличногопространства [10, To (1995), 6.12].

3. Создайте одно или более табличных про-странств, предназначенных исключительнодля сегментов отката. Не помещайте сегмен-ты отката в табличные пространства отлич-ные от тех, что были специально для этогоспроектированы.

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

5. По возможности изолируйте сегменты толь-ко для чтения (read only) в табличных про-странствах, которые содержат исключитель-но такие сегменты. Переведите эти таблич-ные пространства в режим «только для чте-ния».

6. Проведите классификацию оставшихся сег-ментов по их размерам. В каждом табличномпространстве храните сегменты с похожимиразмерами.

7. Ограничьте максимальный размер таблично-го пространства в пределах 10GB. Переводнебольшого табличного пространства в авто-номный режим (off-line) потенциально вле-чет лишь ограниченную недоступность базыданных. Недоступность большого таблично-го пространства, из-за потери файла данных,с большей вероятностью приведет к недо-ступности всей базы данных. Использованиемалых табличных пространств позволит по-лучить преимущества от распараллеливанияпроцедуры восстановления на заданный мо-мент времени в Oracle8.

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

6 Параметры хранения

Параметры хранения были долгое время горя-чей темой для обсуждения, поскольку многие ад-министраторы Oracle верили, что важно пытать-ся разместить каждый сегмент в базе данных вне более чем одном экстенте. Многие люди былиобучены тому, что наличие большого числа экс-тентов негативно влияет на производительностьвсех DML-операторов Oracle. Время, потраченноена «сжатие» таблиц и индексов в один экстент —


Carry V. Millsap 33

это время, которое можно было бы потратить начто-то более стоящее 15.

6.1 Maxextents

Действительная причина того, что администра-торы БД Oracle должны обращать внимание напараметры хранения, заключается в том, что вOracle до версии 7.3 максимальное значение па-раметра maxextents ограничено и зависит от зна-чения параметра db_block_buffers. Опасностьтого, что приложение может быть прервано из-за ошибки «max # extents reached» заставлялаадминистраторов помещать сегменты в ограни-ченное количество сегментов. С возможностьюmaxextents unlimited, появившейся в версииOracle 7.3, эта опасность исчезла.Забавно, но для VLDB, параметры хранения

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

• Наличие множества экстентов позволяет эф-фективнее использовать свободное простран-ство с помощью команды truncate . . . dropstorage.

• Вам желательно, чтобы сегменты откатаимели несколько экстентов для снижения за-грузки системы из-за динамического выде-ления и освобождения экстентов [5, Millsap(1995b)].

• Вы хотите иметь возможность закупать но-вые диски с ростом системы и чтобы СУБДOracle динамически размещала новые экс-тенты в соответствии с этим ростом.

• Вам желательна предварительная фрагмен-тация во всех табличных пространствах, со-держащих временные сегменты и сегментыотката для минимизации накладных расхо-дов, связанных с выделением экстентов.

15 Если Вы можете получить улучшение производительно-сти DML-операторов от «сжатия» сегмента, то Вы сможетеполучить то же улучшение с помощью правильного управле-ния сегмента с несколькими экстентами [5, Millsap (1995b)].

6.2 Свойства параметров хранения

Хорошо выбранные параметры хранения VLDBсервера Oracle должны иметь следующие свой-ства:

• Кратность размеру блока данных — все раз-меры экстентов должны быть кратные разме-ру блока данных базы данных. Oracle будетвсегда округлять размер экстента до размераблока данных. Например, неразумно пытать-ся установить значение 10KB для параметраinitial в базе данных с размером блока дан-ных 8KB. Начальный экстент с 8KB–блокомданных всегда будет занимать как минимум16KB, в независимости от того что Вы запро-сите.

• Кратность размеру файла данных — все раз-меры экстентов должны быть кратные ис-пользуемым размерам файлов данных. Этопозволит наилучшим способом использоватьпространство в файлах данных без возник-новения потерь.

• Небольшое число размеров экстентов — чис-ло различных размеров экстентов в каж-дом табличном пространстве должно бытьнебольшим, к примеру — только один раз-мер. Если Вы используете несколько разме-ров экстентов, все они должны быть крат-ные, либо делить друг друга нацело.

На рисунке ниже показаны два файла данных,в которых выделено по два экстента. Малые об-ласти в начале каждого файла представляют за-головки файлов 16.

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



На этом примере большие экстенты B1, B2 иB3 имеют такой размер, что ровно два экстен-та могут разместиться в каждом файле данных.Файл данных, называемый abc01.dbf содержитровно два таких больших экстента. В abc02.dbfнаходится один большой экстент B3, а такженебольшой экстент, обозначенный S1. Оставше-еся свободное пространство, помеченное как F1,имеет большой размер, — почти половину разме-ра файла данных, — но недостаточный для хра-нения еще одного большого экстента, такого какB1, B2 и B3.Экстент S1 — причина появления неиспользу-

емого пространства, поскольку его размер отли-чен от размера больших экстентов, что порож-дает неиспользуемый фрагмент свободного про-странства F1. Фактически, если размер большихэкстентов не кратен размеру S1, то это приведетк тому что оставшееся свободное пространство вabc02.dbf не сможет быть полностью освоено.Для понимания истинного влияния этого типа

проблемы на VLDB, Вам необходимо помнить,что число файлов данных с Oracle7 ограниченонесколькими сотнями, в Oracle8 — несколькимитысячами. Проблема, которая требует одного часаадминистратора базы данных в БД размером 5GBс 20 файлами данных, для аналогичного решенияв VLDB размером в 1000GB и 600 файлами по-требует более 30 часов. Комбинация возрастанияразмеров проблем и более жестких требованийдоступности в среде VLDB погубит администра-тора базы данных если он не сможет реализоватьстандартные решения, подобные тем, что мы об-суждаем.В табличных пространствах, содержащих сег-

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

6.3 Выбор параметров хранения

Процедура, описанная ниже, поможет Вам вы-брать значения параметров хранения, удовлетво-

Блоков Байт ОписаниеOracle

1 8,192 Размер блокаOracle

262,144 2,147,483,648 размер файлаОС

2 ufs=1, raw=2262,142 2,147,467,264 размер полезного

пространства

ряющих ограничениям описанным ранее, для Ва-шей VLDB.

1. Вычислите размер используемого простран-ства, доступного в Ваших файлах данных(использование стандартных размеров дляфайлов данных, как рекомендовалось ранее,упростит эту задачу). Самый простой способсделать это — использовать запрос к пред-ставлению словаря данных dba_free_spaceсразу же после создания файла данных.

selectblocks, bytes

fromdba_free_space

wherefile_name = ’filename’;

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

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

2. Для каждого табличного пространства уста-новите умалчиваемые параметры хранения вследующие значения:

• Выберите значение initial таким, что-бы оно было кратным блоку данных БДи чтобы размер полезного пространствафайла данных был кратен этому значе-нию.

• Установите значение next равнымinitial.


Carry V. Millsap 35

n k = 4n Сегмент, initial, nextблоки Oracle

* 131,071 2 16,3848 32,768 7 57,3447 16,384 15 122,8806 4,096 63 516,0965 1,024 255 2,088,9604 256 1,023 8,380,4163 64 4,095 33,546,2402 16 16,383 134,209,5361 4 65,535 536,862,7200 1 262,142 2,147,467,264

n k = 4n Сегмент, initial, nextблоки Oracle

* 131,071 2 16,3844 10,000 26 212,9923 1,000 262 2,146,3042 100 2,621 21,471,2321 10 26,214 214,745,0880 1 262,142 2,147,467,264

• Установите pctincrease в 0.

Таблицы, приведенные ниже, показывает дваразличных набора параметров хранения, ко-торые подходят под эти ограничения. Каж-дый набор содержит экстент из двух бло-ков, используемый для очень малых сегмен-тов, оставшиеся размеры параметров хра-нения рассчитываются таким образом, что-бы каждый разбивал полезное пространствофайла данных на k равных частей. Различиемежду двумя наборами заключается в выбо-ре числового ряда для k. В первом случаеряд значений — это степень 4, во-втором —степень 10.

3. Везде, где это возможно, используйте умал-чиваемые, определенные на уровне таблич-ного пространства, параметры хранения длясегментов. Оптимальным вариантом былобы наличие только одного набора значенийinitial, next и pctincrease для каждого таб-личного пространства. Для сегментов с ин-дивидуальными параметрами хранения, от-личными от умалчиваемых, используйте сле-дующие правила:

• Установите значение initial таким, что-

бы оно было кратным размеру блокаданных СУБД и чтобы размер полез-ного пространства в файле данных былкратен этому значению.

• Установите значение next равнымinitial.

• Установите значение pctincrease в 0для больших сегментов и в 0 или 100для малых сегментов.

4. Для каждого сегмента с параметрами хра-нения отличными от вышеприведенных, ис-пользуйте индивидуальные значения.

Если Вы используете параметры хранения изтаблицы с k = 10n и размером файла данныхпоказанным ранее, то Вы найдете только шестьразличных наборов параметров хранения при сле-дующем запросе:

select distinct (initial_extent||’,’||next_extent||’,’||pct_increase) "initial,next,pctincrease"

from dba_segments;

initial,next,pctincrease------------------------16384,16384,0212992,212992,02146304,2146304,021471232,21471232,0214745088,214745088,02147467264,2147467264,0

7 Сегменты отката

Сегменты отката — это структуры, данных ко-торые сервер Oracle использует для предоставле-ния следующих услуг:

• Непротиворечивость чтения — сегменты от-ката содержат информацию отката (undo)транзакций. Сервер Oracle использует ин-формацию отката для поддержания непро-тиворечивости чтения запросов, использу-ющих блоки, модифицированные (другимитранзакциями) после начала транзакции.



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

Сегмент отката — это циклическая очередь,состоящая из блоков данных Oracle, в которыепроцессы сервера Oracle записывают информа-цию отката в течение выполнения транзакции.Рисунок ниже демонстрирует сегмент отката с 8экстентами, каждый из которых содержит 4 бло-ка данных Oracle. Блок, нарисованный в центре— это заголовок сегмента отката. Стрелка, ука-зывающая на начало третьего блока во второмэкстенте определяет место, в которое будет про-изводиться очередная запись в сегмент отката.Она называется «указатель записи» в сегментеотката и движется по часовой стрелке повторноиспользуя блоки сегмента отката после заверше-ния круга.

7.1 Размер сегмента отката

Ключевыми ограничениями для правильноговыбора размера сегментов отката являются:

• Достаточно малый для кэширования — бло-ки сегментов отката загружаются и выгру-жаются в SGA по тем же правилам (LRU),что и другие блоки базы данных. Большиеразмеры сегментов отката заполнят большуючасть кэша блоков данных и, тем самым, вы-теснят другие блоки данных (например, бло-ки данных ветвей индексов), которые улуч-шали бы производительность приложения.

Возросшее число неуспехов в кэше блоковданных БД, вызванное большим размеромсегментов отката, не только снизит качествокэша, но резко увеличивает загрузку ЦПУ иподсистемы ввода/вывода.

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

Oracle7 имеет несколько возможностей, кото-рые резко снижают сложность администрирова-ния сегментов отката по сравнению с тем, что мыимели в Oracle6: (1) сегменты отката могут растии сжиматься, и (2) имеется возможность переводасегментов отката в автономный или оперативныйрежимы без необходимости останова инстанции.Даже с учетом этих возможностей администри-рование сегментов отката остается сложной зада-чей в смешанных средах с OLTP и пакетной обра-ботками. Ключевыми средствами, снижающиминегативное влияние сегментов отката на произ-водительность, являются:

• Проектирование приложения — проектируй-те Ваши приложения так, чтобы большиеобъемы DML (особенно вставки) выполня-лись с unrecoverable-опцией везде, где этодопустимо. Для транзакций, которые долж-ны выполняться в обычном режиме, проек-тируйте приложение таким образом, чтобыоно вызывало частые промежуточные фикса-ции. Если Вы не можете выполнить этого,то как минимум, для хранения информацииотката, выбирайте упомянутый ранее боль-шой сегмент отката с помощью команды settransaction use rollback segment.

• Планирование заданий — если Вы вынуж-дены использовать пакетные программы, вы-полняющие большой объем DML-операцийбез промежуточных фиксаций (например,предустановленные программы, которые Вы


Carry V. Millsap 37

не имеете возможности настраивать), то ста-райтесь планировать такие задание такимобразом, чтобы они не конкурировали с ин-тенсивными параллельными процессами ра-ботающими с SGA. Для снижения наклад-ных расходов по поддержанию непротиворе-чивости чтения, а также для предотвращенияошибок «snapshot too old», Вы также должныстараться разделить по времени запуск такихпрограмм и программ читающих изменяемыеданные.

Вы можете использовать следующий метод дляопределения оптимального размера сегментов от-ката для Вашей системы.

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

2. Выберете размер сегмента отката таким, что-бы он был достаточно большим для хране-ния информации отката некоторого неболь-шого числа k одновременно запущенных наи-больших транзакций, которые Вы будете ис-пользовать в момент активности этого сег-мента отката. Критерий для выбора значенияk заключается в минимизации числа блоковв кэше блоков данных БД, выделенных дляхранения сегмента отката. Если наибольшаятранзакция генерирует менее чем один блокБД информации отката, то k = 4, 5, 6 . . . , 10.Если наибольшая транзакция порождает сот-ни килобайт информации отката, то устано-вите k < 4 и побеседуйте с людьми, которыеразработали приложение.

3. Установите значение minextents в диапазонеот 8 до 20 для каждого сегмента отката, а

также значение optimal в значение, гаран-тирующее, что сегмент отката не будет со-кращаться менее чем до 8 (до 20) экстен-тов. Обратите внимание, что большое значе-ние minextents предполагает небольшое зна-чение для размера экстента сегмента отката.Использование нескольких экстентов в сег-мента отката снижает частоту появления со-бытий роста и сжатия [5, Millsap (1995b)].

7.2 Количество сегментов отката

Ограничения на количество сегментов откатаподобны ограничениям на размер сегментов от-ката:

• Достачно малое, чтобы кэшироваться — На-личие слишком большого числа сегментовотката имеет тот же болезненный эффект накачество кэша в SGA и обработку контроль-ной точки, что и слишком большие размерысегментов отката.

• Достаточно большое, чтобы избежать конку-ренции — Наличие слишком малого числасегментов отката будет причиной конкурен-ции за транзакционную таблицу (transactiontable) сервера Oracle, которая храниться взаголовке сегмента отката. Определить на-личие конкуренции за сегменты отката Выможете с помощью показателя undo headerwaits из динамической таблицы производи-тельности v$waitstat.

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

1. Выберите коэффициент достоверности C, где0 < C < 1. К примеру, если Вы хотите полу-чить 90% оценку, то C = 0.90.

2. Оцените максимальное число активныхпользователей в момент пиковой загрузкисистемы. Обозначим это число пользовате-лей как n.



3. Оцените вероятность того, произвольно взя-тая транзакция будет активной в случай-но заданный момент. Обозначим эту вероят-ность как p.

4. Найдите наименьшее значение x для которо-го

P (X ≤ x) > C,

где

P (X ≤ x) =n∑

k=1

P (X = k),

и P (X = x) есть функция бмноминальногораспределения Бернулли, определенная как

P (X = x) =n!

x!(n− x)!px(1− p)n−x.

Если Вы имеете Excel или подобный инстру-мент, то можете найте значение x очень про-сто, как показано на таблице 4.

5. После некоторого времени эксплуатации Выможете выполнить тонкую настройку сегмен-тов отката на основе наблюдений за таблицейv$waitstat. Если присутствует событие ожи-дания undo header waits, то попытайтесь ре-шать проблему с помощью увеличения чис-ла сегментов отката. Если событий ожида-ния заголовка сегмента отката нет, Вы мо-жете удалить один или несколько сегментовотката, не оказывая влияния на производи-тельность системы.

8 Заключение

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

n = 170, p = 0.05x P (X = x) P (X ≤ x)0 0.000 0.0001 0.001 0.0022 0.006 0.0083 0.019 0.0274 0.042 0.0695 0.074 0.1436 0.106 0.2497 0.131 0.3818 0.141 0.5219 0.133 0.65510 0.113 0.76811 0.086 0.85412 0.060 0.91513 0.039 0.95314 0.023 0.97615 0.012 0.98816 0.006 0.99517 0.003 0.99818 0.001 0.99919 0.001 1.000

Итого 1.000

Таблица 4. Оценка требуемого числа сегментов отка-та для OLTP. В данном примере, если мы имеем 170одновременно работающих пользователей, каждый изкоторых запускает 3-секундную транзакцию раз в ми-нуту, наличие 12 сегментов отката будет обеспечиватьтранзакцию сегментом отката в 90% времени. Таблицасоздана в Excel с помощью функции binomidist.


Carry V. Millsap 39

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

Благодарности

Я искренне благодарю друзей за потраченноеими время и полезные комментарии: DominicDelmolino, Greg Doherty, Tim Gorman, ToddGuay, Deepak Gupta, Gary Hallmark, AndrewHoldsworth, Phil Joel, Anjo Kolk, Mark Pavkovic,Richard Powell, Lyn Pratt, Willis Ranney, CraigShallahamer, Hank Tullis, Hugh Ujhazy, PeterUtzig, Mitch Wallace, и Graham Wood.

Список литературы

[1] CHEN, P.; LEE, E.; GIBSON, G.; KATZ, R.;PATTERSON, D. 1994. «RAID:high-performance, reliable secondarystorage» in ACM Computing Surveys, Vol.26 No. 2 (Jun 1994).

[2] GUI, JEFFREY. 1993. «OLTP and SystemReliability» in OLTP Handbook, edited byGary McClain, Intertext/McGraw-Hill, NewYork NY.

[3] MAULIK, B.; PATKAR, S. 1995. «Outagerecovery timings» in Technical ReportsCompendium Vol. I (Dec 1995). Oracleinternal document.

[4] MILLSAP, C. 1995a. «The OFAStandard-Oracle7 for Open Systems». Oracleinternal document, available on-line athttp://www.europa.com/~orapub/.

[5] MILLSAP, C. 1995b. «Oracle7 Server SpaceManagement». Oracle internal document,available on-line athttp://www.europa.com/~orapub/.

[6] MILLSAP, C. 1996. Selecting the OptimalOracle Database Block Size. Oracle internaldocument. Not yet available on-line.

[7] Oracle7 Server Administrator’s Guide. 1996.Oracle standard product documentation,Redwood Shores CA.

[8] Oracle7 Server Concepts Manual. 1996.Oracle standard product documentation,Redwood Shores CA.

[9] PATTERSON, D.; GIBSON, G.; KATZ, R.1988. «A case for redundant arrays ofinexpensive disks (RAID)» in InternationalConference on Management of Data(SIGMOD). ACM, New York: 109-116.

[10] TO, L. 1995. «Outage prevention, detection,and repair» in Technical ReportsCompendium Vol. I (Dec 1995). Oracleinternal document.

[11] Understanding Disk Arrays. 1995. SunMicrosystems white paper, Mountain ViewCA.


http://www.europa.com/~orapub/


Замечания к переводу

Перевод выполнен Михаилом Прусовым (http://mprusov.narod.ru/). По всем вопросам ипредложениям пишите по адресу mailto:[email protected].

Приведенная в библиографии ссылка на http://www.europa.com/~orapub/, по всей види-мости, уже не действительны. Указанные документы можно найти либо на сайте компании Hotsoshttp://www.hotsos.com/, либо на сайте http://www.orapub.com/. В обоих случаях, Вамнеобходимо пройти бесплатную регистрацию.

http://mprusov.narod.ru/

mailto:[email protected]


http://www.hotsos.com/

http://www.orapub.com/

Конфигурирование сервера Oracle для сверхбольших баз...

Documents

Transcript of Конфигурирование сервера Oracle для сверхбольших баз...