От редакции CITForum.ru: В мартовском номере журнала "Oracle Magazine/Русское издание" был опубликован фрагмент этой статьи.
Мы полностью согласны с редакцией OM/RE в том, что несмотря на весьма почтенный возраст, статья "не потеряла своей значимости до настоящего времени, хотя бы потому, что многие приведенные в ней сведения до сих пор повторяются в самых современных изданиях, где со ссылкой на Кери Миллсапа, а где уже считаются само собой известной информацией" и предлагаем Вашему вниманию полный текст.
Аннотация
Эта статья поможет читателю настраивать сверхбольшие базы данных Oracle (Very Large Database,
в дальнейшем — VLDB) для достижения высокой производительности и высокой доступности при
низких издержках на эксплуатацию. Она описывает решения выбора размера блока данных Oracle,
применения RAID-технологий, использования «линейных» устройств (raw-devices), конфигурирования
журнальных файлов, разбиения табличных пространств на разделы, выбора параметров хранения и
настройки сегментов отката. Статья описывает технологии и связанные с ними ограничения, а также
технически детальные методы для оптимизации конфигурации в рамках этих ограничений.
VLDB является аббревиатурой, принятой для
обозначения СверхБольших Баз Данных (
Very
Large Database). Словосочетание «сверхбольшая»
имеет разное наполнение для разных людей,
но оно всегда связано с ощущением трудности,
сложности, высокой стоимости и риска. VLDB
являются тем, что люди связывают с огромными базами данных, поддержка которых граничит
с искусством. Требуются большая изобретательность, умение планировать, упорный труд и значительные капиталовложения для того, чтобы избежать очень серьезных разочарований при попытке внедрения VLDB.
Операционная сложность является очевидной
проблемой VLDB. Как оператор VLDB Вы должны постоянно оценивать множество сильно связанных параметров. Система будет «наказывать»
попытки применить радикальные или случайные
изменения. Огромные объекты и длительные процессы оставляют Вам мало пространства для маневра при устранении проблемы.
Это требует, в
первую очередь, осторожности при планировании
устранения проблемы. Состояние сотен или даже
тысяч людей зависит от Вашей способности быстро принимать правильные решения. Здесь требуется талант и упорный труд.
Длительность многих важнейших процедур,
например резервное копирование и восстановление, пропорциональна размеру объектов, которыми они манипулируют. Поэтому в больших БД
эти важнейшие процедуры могут требовать очень
больших временных интервалов. С ростом БД
стоимость ошибок увеличивается. Операции —
подобные реконфигурации диска, перестроению
объекта БД, подсчету числа строк в таблице,
откату транзакции, — могут выглядеть вполне
безобидно в небольших БД, но быть полностью
неприемлемыми для VLDB. Если действие требует нескольких часов Вашего рабочего времени,
Вы должны избегать его выполнения.
Увеличивают сложность и другие факторы.
Рассмотрим доступ к данным. Вы можете допустить использование неэффективного запроса,
который требует 2 секунды работы процессора на
высокопроизводительной современной системе с
20 пользователями, но Вы не сможете допустить
такое же время обслуживания в системе с 1,200
пользователями, где идет непрерывная борьба за
фиксаторы (
latches), диски и процессорное время.
Запросы к VLDB должны быть оптимизированы
исключительно хорошо, иначе система развалится.
Более того, многие VLDB становятся «VL» в
первую очередь вследствие большого числа одновременно работающих пользователей и пакетных заданий, создающих большой объем транзакций. Большой объем транзакций создает стрессовые ситуации в подсистеме ввода/вывода связанные с генерацией redo-информации и записью в
файлы данных. Высокий уровень параллелизма
процессов перегружает фиксаторы и механизмы
блокировок, разработанные для перевода доступа к критическим ресурсам в последовательный
режим (serialize).
Чем больше обдумываешь проблему — тем она
сложней выглядит. VLDB часто являются источником данных для важных приложений с высокими требованиями доступности. Разработчики
индустриальных СУБД слышат формулу «семь–дней–по–двадцать–четыре–часа», а мы цепенеем от монументальной сложности этой задачи.
Ввиду электрических и сетевых неисправностей,
некачественных модулей памяти и дисковых контроллеров, ошибок приложений и операционных
систем, модернизации ПО и оборудования и просто случайных ошибок оператора, — достичь
нескольких секунд или минут останова в год
крайне сложно. Как обнаружить и исправить логические разрушения сотен и даже тысяч гигабайт данных, которые образовались вследствие
ошибочного ввода оператора?
Путь к преодолению сложностей, присущих
VLDB, лежит в упрощении БД настолько, насколько это возможно. Вы оптимизируете как
СУБД, так и само приложение для снижения
любых видов нагрузки. Вы выбираете структуры данных, которые минимизируют ввод/вывод
при доступе к данным. Вы создаете приложения с
максимально простыми транзакциями. Вы изолируете влияние вышедших из строя компонент на
минимально возможные подмножества данных.
Вы делайте единицы резервного копирования и
восстановления минимально возможными.
Ниже перечислены некоторые аспекты, позволяющие построить хорошую VLDB:
- Оптимизация выполнения последовательности бизнес-операций
- Оптимизация логической модели данных
- Оптимизация схемы БД
- Построение надежной, высокопроизводительной конфигурации аппаратного обеспечения
- Оптимизация физической конфигурации БД
- Оптимизация SQL-операторов приложений
- Оптимизация операционной системы и инстанции сервера Oracle
- Создание корректных и надежных процедур сопровождения
В этой статье мы исследуем решения для физической конфигурации БД, необходимые для
успешного построения VLDB.
Ирония жизни — в тот день, когда Ваш опыт
в управлении сервером Oracle минимален, Вам
необходимо ввести значение для параметра
db_block_size, которое будет в дальнейшем неизменяемо на протяжении всей жизни БД. Важно то, что значение, которое Вы выбрали для размера
блока данных Oracle, оказывает сильнейшее влияние на производительность системы. Последующие разделы обратят Ваше внимание на некоторые компромиссы, которые необходимо рассмотреть перед выбором размера блока данных Oracle
для Вашей базы данных.
Оптимальный размер блока данных Oracle для
VLDB лежит в пределах от 4KB до 64KB. Наиболее часто используемым является значение 8KB
и, на втором месте, — 16KB. Сервер СУБД
Oracle, установленный на системе с очень быстрой реализацией копирования больших объемов
памяти может эффективно работать с размером
блока в 32KB и даже (как минимум, теоретически) с 64KB. Я не знаком с обстоятельствами, которые могли бы требовать выбора размера
блока для VLDB в 2KB и лишь в очень специальных случаях размер в 4KB будет подходящим
для VLDB. В [6, Millsap (1996)] я давал развернутое техническое описание этого вопроса, здесь
мы ограничимся только выводами 1.
Наиболее важной характеристикой самых
сложных реализаций VLDB является огромная нагрузка на ввод/вывод. Владельцы лучших мировых VLDB вкладывают большие деньги в средства, способные уменьшить нагрузку на
ввод/вывод в их системах. Использование большого размера блока данных СУБД Oracle является простой техникой для уменьшения некоторых
видов нагрузки на ввод/вывод.
- Число операций ввода/вывода — аппаратура
имеет вполне определенную цену одной операции ввода/вывода. Манипуляция с небольшим числом больших блоков данных будет иметь преимущества над манипуляциями
большим числом блоков меньшего размера.
- Производительность индексов — скорость
работы с индексами обратно пропорциональна высоте двоичного дерева (B*-tree) индекса. Больший размер блока Oracle позволит хранить больше ключей в одном блоке что, в
свою очередь, даст лучшую производительность при поиске.
- Снижение сцеплений — сервер Oracle использует сцепление (chaining) для хранения строк таблиц, кластеров данных и хэштаблиц размер которых (строк) превышает размер блока данных. Сцепление частей
строк между несколькими блоками данных
приводит к увеличению числа операций ввода/вывода на одну обрабатываемую строку.
Больший размер блока данных снижает вероятность того, что будет требоваться сцепления для хранения строки, и тем самым,
уменьшает число операций ввода/вывода в
системе.
Сервер Oracle хранит небольшой объем служебной информации фиксированного размера в
каждом блоке БД вне зависимости от того, какой объем пользовательских данных хранится в
этом блоке. Таким образом, чем меньше блоков
находится в БД, тем меньше пространства будет истрачено на накладные эти расходы. Для
очень малых сегментов выигрыш от экономии на
фиксированных накладных расходах может обернуться потерей пространства за счет неиспользуемых завершающих блоков сегмента, но эти потери, в свою очередь, незначительны по сравнению с потерями, вызванными неточным заданием
параметров хранения
2. Использование большого
размера блока Oracle для очень больших сегментов сохраняет примерно от двух до шести процентов общего объема базы данных.
Этот выигрыш ведет к повышению производительности и
снижению стоимости эксплуатации, что особенно заметно на снижении времени резервного копирования/восстановления.
Использование большого размера блока данных Oracle увеличивает риск возникновения узких мест при совместном доступе за исключением
случаев, когда архитектор базы данных понимает
как использовать параметры хранения
initrans и
maxtrans. Значение
initrans должно быть установлено в максимально ожидаемое число транзакций, одновременно манипулирующих блоком данных
3. Таким образом, если Вы увеличили
размер блока данных Oracle в
k раз, то Вам необходимо увеличить значение параметра
initrans
также в
k раз. Для того чтобы позволить динамически расти «таблице списка входов транзакций», Вам необходимо установить значение параметра
maxtrans в значение, превышающее значение
initrans 4.
Неудачный выбор параметров initrans и
maxtrans для сегментов базы данных может
быть причиной возникновения ожиданий пользовательских сессий. Сессии, которые изменяют
блок, имеющий эту проблему, будут мешать другим сессиям получить входы в структуру данных блока, которая позволяют делать реконструкцию данных для достижения непротиворечивости чтения. Эта ситуация, имеющая название
ITL-конкуренция, может быть обнаружена администраторами БД с помощью представления
v$lock. Наблюдения будут показывать сессии,
ожидающие на блокировке TX (очередь транзакций) в режиме блокировки 4 (разделяемый доступ).
Вы в состоянии полностью избежать этих
проблем, используя соответствующие техники,
описанные в стандартной документации компании Oracle по настройке параметров initrans и
maxtrans для сегментов БД.
Хотя большой размер блока данных Oracle имеет преимущества для VLDB, имеются определенные ограничения на максимальный размер блока
данных который Вы можете выбрать.
- Физический размер ввода/вывода — Размер
блока данных СУБД Oracle не должен превышать максимально возможный размер физической операции чтения данных. Убедитесь также, что размер пакетного чтения
для операции полного сканирования таблицы ограничен максимальным размером физического чтения операционной системы. К
примеру, если размер блока данных Вашей
СУБД равен 32KB и параметр db_file_multiblock_read_count равен 32 то маловероятно, что Вы сможете выбирать 1MB =
32KB × 32KB за одну физическую операцию чтения.
- Redo-размер — Процесс, пишущий в журнальные файлы Oracle (LGWR) записывает
целые блоки при изменениях в файлах данных табличных пространств, переведенных
в состояние резервного копирования. Поэтому решение уменьшить объем генерируемой
redo-информации в течение «горячего» резервного копирования, может мотивировать
Вас ограничить размер блока данных Oracle.
- Размер копируемой области памяти — В случае, если Вы выберите размер блока данных,
превышающий максимальный размер памяти, который операционная система в состоянии обработать за одну операцию, Вы может
наблюдать увеличение загрузки процессора
и снижение производительности, связанные
с обработкой больших блоков в SGA.
- Ограничения параллелизма — Максимальное значения для параметров initrans и
maxtrans равно 255. Если блок данных
СУБД Oracle при обычных нагрузках получает более 255 запросов от транзакций на
изменение, то это значит, что размер блока данных выбран слишком большим. Шансы возникновения токай ситуации близки к
нулю: если действительно 255 транзакций
одновременно модифицируют один блок, то
результирующая конкуренция за фиксаторы
будет настолько серьезной, что Вам непременно придется увеличить параметр pctfree
для такого сегмента.
| 1(к тексту) | Чтобы не заставлять Вас искать указанный документ компании Oracle, что кстати является не простым делом, скажу, что одним из специальных случаев, когда выбор в 4KB будет подходящим, заключается в наличии огромного числа небольших сегментов (меньше 100KB). |
| 2(к тексту) | Как мы обсудим позднее, приближенное задание параметров хранения является хорошим компромиссным решением, снижающим стоимость эксплуатации, в сравнении с VLDB с очень точно заданными параметрами хранения. |
| 3(к тексту) | Под транзакцией здесь понимается выполнение операторов insert, update, delete, или select . . . for update |
| 4(к тексту) | Формально, «таблица списка входов транзакций» называется списком интересующихся транзакций (interested transactions list), или ITL. |
Содержание Вперёд
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
