Гибридная база данных (или система) характеризуется тем, что она в опреде­ленное время суток показывает характеристики и ведет себя как типичная сис­тема онлайновой обработки транзакций (OLTP), а все остальное время выступает как система поддержки принятия решений (DSS). Чтобы не уходить далеко от реальности, скажем, что в нашем мире есть очень мало систем OLTP, если взглянуть на это дело с чисто транзакционной точки зрения. Идея получе­ния данных из базы данных сводится к заданию запросов к базе данных и выпол­нению отчетов, которые и позволяют превращать данные в информацию. И пакетные, и онлайновые запросы делают именно это. Основная цель при на­стройке гибридной системы - достижение 

баланса 

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

конфигурирование и настройку системы намного более проблематичными.

Данный раздел предназначен для указания общих направлений, ключевых за­просов и проблем при управлении гибридными системами. »

Например, ранее в этой главе мы рекомендовали определять правильный размер блока базы данных Oracle для настраиваемой системы, выбирая относи­тельно малые размеры блоков для систем OLTP и сравнительно большие разме­ры блоков для систем DSS. Если приходится иметь дело с гибридной системой, такая постановка вопроса, естественно, приводит к дилемме. Какой размер блока выбрать - 8 Кбайт или 16 Кбайт? Вспомните еще один совет из данного раздела: "Если у вас возникли сомнения, остановитесь на большем размере блока".

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

уровня блока, чтобы избежать возникающей из-за увеличения размера блока

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

Долю проблем дает и        аспект системы. Вот только некото-

рые из них:

Оптимальная конфигурация сегмента отката

Эффективное управление конкуренцией на уровне блока

Управление блокировками

Число одновременно работающих пользователей базы данных

Число одновременных подключений к базе данных

•        Сервисные соглашения, включая среднее время восстановления базы данных

Частота создания резервных копий и управление ими

Частота работ по анализу таблиц и индексов

Требования высокой надежности

Управление данными, включая архивирование и чистку данных

Аспект DSS имеет свой собственный набор уникальных вопросов. К ним, на­ряду со многими другими, относятся:

Манипулирование данными и их "причесывание" (massaging)

Управление сложными требованиями отчетности

Стратегии индексирования

Отделение объектов, используемых только для чтения, от объектов, применяемых для записи

Сортировки в памяти и конфигурирование временных табличных пространств

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

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

Вот один технический совет, относящийся к управлению

гибридными системами, который мы хотели бы предложить всем заинтересованным лицам. Даже в том случае, если настраиваемая среда имеет независимые окна для аспектов DSS и OLTP, и при этом АБД уверен, что эти окна никогда не пересекутся, попробуйте предположить (хотя бы из соображений правильного определения размеров системы -памяти, ЦП и дисков), что они все-таки пересеклись. Мы от всего сердца и накопленного нами промышленного опыта дарим всем вам этот совет. В мире, в котором мы все живем, нет места для слова "никогда". Как говаривал агент 007: "Никогда не говори никогда!".