2.1 СУБД сервер Informix.

1.Теоретическиеосновы.
1.1ПонятиеСУБДсервера.
1.1.1ОсновныефункцииСУБД
1.1.2ТиповаяорганизациясовременнойСУБД
1.2Понятиеархитектурыклиент-сервер.
2.ТеоретическиеосновыСУБДсервераInformixOnLinev.7.X
2.1СУБДсерверInformix.
2.1.1ОписаниепродуктовInformix
2.1.2Типовыеконфигурации
2.2АрхитектураСУБДсервераInformixOnLinev.7.X
2.2.1.Динамическаямасштабируемаяархитектура
2.2.1.1Потоки
2.2.1.2Виртуальныепроцессоры
2.2.1.3Планированиепотоков
2.2.1.4Разделениепотоковмеждувиртуальнымипроцессорами.
2.2.1.5Экономияпамятиидругихресурсов
2.2.2Организацияразделяемойпамяти
2.2.3Организацияоперацийобменасдисками
2.2.3.1Управлениедисковойпамятью
2.2.3.2Асинхронныйввод-вывод
2.2.3.3Опережающеечтение
2.2.4Поддержкафрагментациитаблицииндексов
2.2.5Параллельнаяобработказапросов
2.2.5.1НачемоснованатехнологияPDQ
2.2.5.2Итераторы
2.2.5.3Примерыпримененияпараллелизма
2.2.5.4БалансмеждуOLTPиDSS-приложениями
2.2.6Оптимизаторвыполнениязапросовпостоимости
2.2.7Средстваобеспечениянадежности
2.2.7.1.Зеркалированиедисковыхобластей
2.2.7.2Тиражирование
2.2.7.3Быстроевосстановлениепривключениисистемы
2.2.7.4Архивированиеивосстановлениеданных
2.2.8Динамическоеадминистрирование
2.2.8.1Интерфейсмониторингасистемы
2.2.8.2УтилитаDB/Cockpit
2.2.8.3УтилитаOnPerf
2.2.8.4Утилитапараллельнойзагрузки
2.2.9Распределенныевычисления
2.2.9.1Взаимодействиеклиент-сервер
2.2.9.2Прозрачностьрасположенияданных
2.2.9.3Распределенныебазыданныхипротоколдвухфазовойфиксациитранзакций
2.2.10Поддержканациональныхязыков
2.2.11СредствабезопасностиклассаС2
2.3 Дополнительные компоненты компании Informix для выполнения
специфическихзадач.
2.3.1Informix-EnterpriseGateway7.1
2.3.2ТехнологияикомпонентыEDA/SQL
2.3.2.1EDAAPI/SQL
2.3.2.2EDA/Link
2.3.2.3EDA/SQLServer
2.3.2.4EDA/DataDrivers
2.3.3ВозможностиEnterpriseGateway
2.3.3.1Прозрачныйдоступдлячтенияизаписи
2.3.3.2Распределенныесоединения
2.3.3.3КонфигурированиеEnterpriseGateway
2.3.3.4Безопасность
2.3.4 Библиотеки сопряжения сервера Informix-OnLine DS с менеджерами
транзакций:Informix-TP/XAиInformix-TP/TOOLKIT
2.4Заключение
2.5Литература
1.Теоретическиеосновы.
1.1ПонятиеСУБДсервера.
Традиционных возможностей файловых систем оказывается недостаточно для
построения даже простых информационных систем. При построении информационной
системы требуется обеспечить: поддержание логически согласованного набора данных;
обеспечениеязыкаманипулированияданными;восстановлениеинформациипослеразного
рода сбоев; реально параллельная работа нескольких пользователей. Для выполнения всех
этих задачь выделяется группа программ, обьедененных в единый программный комплекс.
Этоткомплексноситназваниесистемауправлениябазамиданных(СУБД).Сформулируем
эти(идругие)важныефункцииотдельно.
1.1.1ОсновныефункцииСУБД
КчислуфункцийСУБДпринятоотноситьследующее:
Непосредственноеуправлениеданнымивовнешнейпамяти
Эта функция включает обеспечение необходимых структур внешней памяти как для
хранениянепосредственныхданных,входящихвБД,такидляслужебныхцелей,например,
для убыстрения доступа к данным в некоторых случаях (обычно для этого используются
индексы). В некоторых реализациях СУБД активно используются возможности
существующихфайловыхсистем,вдругихработапроизводитсявплотьдоуровняустройств
внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не
обязаны знать, использует ли СУБД файловую систему, а если использует, то как
организованы файлы. В частности, СУБД поддерживает собственную систему именования
объектов БД (это очень важно, поскольку имена объектов базы данных соответствуют
именамобъектовпредметнойобласти).
Существуетмножестворазличныхспособоворганизациивнешнейпамятибазданных.
Как и все решения, принимаемые при организации баз данных, конкретные методы
организации внешней памяти необходимо выбирать в тесной связи со всеми остальными
решениями.
Управлениебуферамиоперативнойпамяти
СУБД обычно работают с БД значительного размера; по крайней мере этот размер
обычносущественнопревышаетдоступныйобъемоперативнойпамяти.Понятно,еслипри
обращении к любому элементу данных будет производиться обмен с внешней памятью, то
вся система будет работать со скоростью устройства внешней памяти. Единственным же
способомреальногоувеличенияэтойскоростиявляетсябуферизацияданныхвоперативной
памяти.Идажееслиоперационнаясистемапроизводитобщесистемнуюбуферизацию(какв
случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо
большей информацией о полезности буферизации той или иной части БД. Поэтому в
развитых СУБД поддерживается собственный набор буферов оперативной памяти с
собственной дисциплиной замены буферов. При управлении буферами основной памяти
приходится разрабатывать и применять согласованные алгоритмы буферизации,
журнализации и синхронизации. Заметим, что существует отдельное направление СУБД,
которые ориентированы на постоянное присутствие в оперативной памяти всей БД. Это
направление основывается на предположении, что в предвидимом будущем объем
оперативной памяти компьютеров сможет быть настолько велик, что позволит не
беспокоитьсяобуферизации.Покаэтиработынаходятсявстадииисследований.
Управлениетранзакциями
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как
единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT)
изменения БД, произведенные ею, во внешней памяти, либо ни одно из этих изменений
никак не отражается в состоянии БД. Понятие транзакции необходимо для поддержания
логическойцелостностиБД.Есливспомнитьнашпримеринформационнойсистемыотдела
кадров с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить
целостность БД при выполнении операции приема на работу нового сотрудника будет
объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну
транзакцию. Таким образом, поддержание механизма транзакций - обязательное условие
даже однопользовательских СУБД (если, конечно, такая система заслуживает названия
СУБД). НопонятиетранзакциигораздосущественнеевомногопользовательскихСУБД.То
свойство,чтокаждаятранзакцияначинаетсяприцелостномсостоянииБДиоставляетэто
состояние целостным после своего завершения, делает очень удобным использование
понятия транзакции как единицы активности пользователя по отношению к БД. При
соответствующем управлении параллельно выполняющимися транзакциями со стороны
СУБДкаждыйпользовательможетвпринципеощущатьсебяединственнымпользователем
СУБД (на самом деле, это несколько идеализированное представление, поскольку
пользователи многопользовательских СУБД порой могут ощутить присутствие своих
коллег).
СуправлениемтранзакциямивмногопользовательскойСУБДсвязаныважныепонятия
сериализации транзакций и сериального плана выполнения смеси транзакций. Под
сериализаций параллельно выполняющихся транзакций понимается такой порядок
планирования их работы, при котором суммарный эффект смеси транзакций эквивлентен
эффекту их некоторого последовательного выполнения. Сериальный план выполнения
смеси транзакций - это такой способ их совместного выполнения, который приводит к
сериализации транзакций. Понятно, что если удается добиться действительно сериального
выполнения смеси транзакций, то для каждого пользователя, по инициативе которого
образована транзакция, присутствие других транзакций будет незаметно (если не считать
некоторого замедления работы для каждого пользователя по сравнению с
однопользовательскимрежимом).
Существует несколько базовых алгоритмов сериализации транзакций. В
централизованных СУБД наиболее распространены алгоритмы, основанные на
синхронизационных захватах объектов БД. При использовании любого алгоритма
сериализации возможны ситуации конфликтов между двумя или более транзакциями по
доступу к объектам БД. В этом случае для поддержания сериализации необходимо
выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более
транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может
реально (и достаточно неприятно) ощутить присутствие в системе транзакций других
пользователей.
Журнализация
ОдноизосновныхтребованийкСУБД-надежноехранениеданныхвовнешнейпамяти.
Под надежностью хранения понимается то, что СУБД должна быть в состоянии
восстановить последнее согласованное состояние БД после любого аппаратного или
программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так
называемые мягкие сбои, которые можно трактовать как внезапную остановку работы
компьютера(например,аварийноевыключениепитания),ижесткиесбои,характеризуемые
потерейинформациинаносителяхвнешнейпамяти.Примерамипрограммныхсбоевмогут
быть аварийное завершение работы СУБД (из-за ошибки в программе или некоторого
аппаратного сбоя) или аварийное завершение пользовательской программы, в результате
чегонекотораятранзакцияостаетсянезавершенной.Первуюситуациюможнорассматривать
как особый вид мягкого аппаратного сбоя; при возникновении последней требуется
ликвидироватьпоследствиятолькооднойтранзакции.
Но в любом случае для восстановления БД нужно располагать некоторой
дополнительнойинформацией.Другимисловами,поддержаниенадежногохраненияданных
вБДтребуетизбыточностихраненияданных,причемтаихчасть,котораяиспользуетсядля
восстановления, должна храниться особо надежно. Наиболее распространенный метод
поддержаниятакойизбыточнойинформации-ведениежурналаизмененийБД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая
особо тщательно (иногда поддерживаются две копии журнала, располагаемые на разных
физическихдисках),вкоторуюпоступаютзаписиобовсехизмененияхосновнойчастиБД.
ВразныхСУБДизмененияБДжурнализуютсянаразныхуровнях:иногдазаписьвжурнале
соответствуетнекоторойлогическойоперацииизмененияБД(например,операцииудаления
строки из таблицы реляционной БД), а порой запись соответствует минимальной
внутренней операции модификации страницы внешней памяти. В некоторых системах
одновременноиспользуютсяобаподхода.
Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так
называемогопротоколаWriteAheadLog-WAL).Грубоговоря,этастратегиязаключаетсяв
том, что запись об изменении любого объекта БД должна попасть во внешнюю память
журналараньше,чемизмененныйобъектпопадетвовнешнююпамятьосновнойчастиБД.
Известно, если в СУБД корректно соблюдается протокол WAL, то с помощью журнала
можнорешитьвсепроблемывосстановленияБДпослелюбогосбоя.
Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго
говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для
каждой транзакции поддерживать локальный журнал операций модификации БД,
выполненных в этой транзакции, и производить откат транзакции выполнением обратных
операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в
большинстве систем локальные журналы не поддерживают, а индивидуальный откат
транзакции выполняют по общесистемному журналу, для чего все записи от одной
транзакциисвязываютобратнымсписком(отконцакначалу).
При мягком сбое во внешней памяти основной части БД могут находиться объекты,
модифицированные транзакциями, не закончившимися к моменту сбоя, и могут
отсутствоватьобъекты,модифицированныетранзакциями,которыекмоментусбояуспешно
завершились(попричинеиспользованиябуферовоперативнойпамяти,содержимоекоторых
примягкомсбоепропадает).ПрисоблюдениипротоколаWALвовнешнейпамятижурнала
должныгарантированнонаходитьсязаписи,относящиесякоперацияммодификацииобоих
видов объектов. Целью процесса восстановления после мягкого сбоя является состояние
внешнейпамятиосновнойчастиБД,котороевозниклобыпрификсациивовнешнейпамяти
изменений всех завершившихся транзакций и которое не содержало бы никаких следов
незаконченныхтранзакций.Чтобыэтогодобиться,сначалапроизводятоткатнезавершенных
транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных
транзакций,результатыкоторыхнеотображенывовнешнейпамяти.Этотпроцесссодержит
многотонкостей,связанныхсобщейорганизациейуправлениябуферамиижурналом.Более
подробномырассмотримэтовсоответствующейлекции.
ДлявосстановленияБДпослежесткогосбояиспользуютжурналиархивнуюкопиюБД.
Грубоговоря,архивнаякопия-этополнаякопияБДкмоментуначалазаполненияжурнала
(имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для
нормальноговосстановленияБДпослежесткогосбоянеобходимо,чтобыжурналнепропал.
Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются
особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из
архивнойкопиипожурналувоспроизводитсяработавсехтранзакций,которыезакончились
кмоментусбоя.Впринципеможнодажевоспроизвестиработунезавершенныхтранзакций
и продолжить их работу после конца восстановления. Однако в реальных системах это
обычно не делается, поскольку процесс восстановления после жесткого сбоя является
достаточнодлительным.
ЯзыкиБД
Для работы с базами данных используются специальные языки, в целом называемые
языками баз данных. В ранних СУБД поддерживалось несколько специализированных по
своим функциям языков. Чаще всего выделялись два - язык определения схемы БД (SDL Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation
Language).SDLслужилглавнымобразомдляопределениялогическойструктурыБД,т.е.той
структуры БД, какой она представляется пользователям. DML содержал набор операторов
манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять,
модифицировать или выбирать существующие данные. Мы рассмотрим более подробно
языкираннихСУБДвследующейлекции.
В современных СУБД обычно поддерживается единый интегрированный язык,
содержащий все необходимые средства для работы с БД, начиная от ее создания и
обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным
языком наиболее распространенных в настоящее время реляционных СУБД является язык
SQL (Structured Query Language). В нескольких лекциях этого курса язык SQL будет
рассматриваться достаточно подробно, а пока мы перечислим основные функции
реляционнойСУБД,поддерживаемыена"языковом"уровне(т.е.функции,поддерживаемые
приреализацииинтерфейсаSQL).
ПреждевсегоязыкSQLсочетаетсредстваSDLиDML,т.е.позволяетопределятьсхему
реляционной БД и манипулировать данными. При этом именование объектов БД (для
реляционнойБД-именованиетаблициихстолбцов)поддерживаетсянаязыковомуровнев
том смысле, что компилятор языка SQL производит преобразование имен объектов в их
внутренниеидентификаторынаоснованииспециальноподдерживаемыхслужебныхтаблицкаталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их
столбцов.
ЯзыкSQLсодержитспециальныесредстваопределенияограниченийцелостностиБД.
Опять же ограничения целостности хранятся в специальных таблицах-каталогах, и
обеспечение контроля целостности БД производится на языковом уровне, т.е. при
компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД
ограниченийцелостностигенерируетсоответствующийпрограммныйкод.
Специальные операторы языка SQL позволяют определять так называемые
представления БД, фактически являющиеся хранимыми в БД запросами (результатом
любого запроса к реляционной БД является таблица) с именованными столбцами. Для
пользователя представление является такой же таблицей, как любая базовая таблица,
хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить
видимость БД для конкретного пользователя. Поддержание представлений производится
такженаязыковомуровне.
Наконец, авторизация доступа к объектам БД производится на основе специального
набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного
вида пользователь должен обладать различными полномочиями. Пользователь, создавший
таблицуБД,обладаетполнымнаборомполномочийдляработысэтойтаблицей.Вихчисло
входитполномочиенапередачувсехиличастиполномочийдругимпользователям,включая
полномочие на передачу полномочий. Полномочия пользователей описываются в
специальныхтаблицах-каталогах,контрольполномочийподдерживаетсянаязыковомуровн
1.1.2ТиповаяорганизациясовременнойСУБД
Естественно, организация типичной СУБД и состав ее компонентов соответствует
рассмотренномунаминаборуфункций.
ЛогическивсовременнойреляционнойСУБДможновыделитьнаиболеевнутреннюю
часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно
SQL),подсистемуподдержкивременивыполнения,наборутилит.Внекоторыхсистемахэти
части выделяются явно, в других - нет, но логически такое разделение можно провести во
всехСУБД.
ЯдроСУБДотвечаетзауправлениеданнымивовнешнейпамяти,управлениебуферами
оперативной памяти, управление транзакциями и журнализацию. Соответственно можно
выделитьтакиекомпонентыядра(покрайнеймере,логически,хотявнекоторыхсистемах
эти компоненты выделяются явно), как менеджер данных, менеджер буферов, менеджер
транзакцийименеджержурнала.
Как можно было понять из первой части этой лекции, функции этих комонентов
взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны
взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД
обладает собственным интерфейсом, не доступным пользователям напрямую и
используемым в программах, производимых компилятором SQL (или в подсистеме
поддержки выполнения таких программ), и утилитах БД. Ядро СУБД является основной
резидентнойчастьюСУБД.Прииспользованииархитектуры"клиент-сервер"ядроявляется
основнымсоставляющимсервернойчастисистемы.
Основная функция компилятора языка БД - компиляция операторов языка БД в
некоторуювыполняемуюпрограмму.
ОсновнойпроблемойреляционныхСУБДявляетсято,чтоязыкиэтихсистем(аэто,как
правило, SQL) являются непроцедурными, т.е. в операторе такого языка специфицируется
некоторое действие над БД, но эта спецификация не процедура, она лишь описывает в
некоторой форме условия совершения желаемого действия (вспомните примеры из первой
лекции). Поэтому компилятор должен решить, каким образом выполнять оператор языка,
преждечемпроизвестипрограмму.Применяютсядостаточносложныеметодыоптимизации
операторов, которые мы подробно рассмотрим в следующих лекциях. Результатом
компиляции является выполняемая программа, представляемая в некоторых системах в
машинныхкодах,ноболеечастоввыполняемомвнутреннеммашинно-независимомкоде.В
последнем случае реальное выполнение оператора производится с привлечением
подсистемы поддержки времени выполнения, представляющей собой, по сути дела,
интерпретаторэтоговнутреннегоязыка.
Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые
слишком накладно выполнять с использованием языка БД, например, загрузка и разгрузка
БД,сборстатистики,глобальнаяпроверкацелостностиБДит.д.Утилитыпрограммируются
сиспользованиеминтерфейсаядраСУБД,аиногдадажеспроникновениемвнутрьядра.
1.2Понятиеархитектурыклиент-сервер.
В подавляющем большинстве случаев локальная сеть используется для коллективного
доступакбазамданных.
Существуетдваподходакорганизацииколлективногодоступаданным.
Первый подход заключается в том , что файлы данных располагают на дисках файл
сервера и все рабочие станции получают к нему доступ. Этот подход носит название
архитектура"файл-сервер".Еслифайлыданныхрасположенынасервере(вданномслучае
сервер называется "файл-сервер" ) , с ними одновременно работают несколько программ ,
запущенныхнарабочихстанциях.Приэтомпрограммыдолжнысамиследитьзатем,чтобы
изменяемые записи базы данных блокировались для записи и чтения со стороны других
программвовремяизменений.Данныйметодимеетсущественныйнедостаток:файл-сервер
не обеспечивает достаточную производительность при большом количестве рабочих
станций.
Второйподходноситназваниеархитектура"клиент-сервер".
Определения:
Клиент - Рабочая станция для одного пользователя, обеспечивающая режим
регистрацииидр.необходимыенаегорабочемместефункциивычисления,коммуникацию,
доступкбазамданныхидр.
Сервер - один или несколько многопользовательских процессоров с единым полем
памяти, который в соответствии с потребностями пользователя обеспечивает им функции
вычисления,коммуникацииидоступакбазамданных.
Обработка Клиент - Сервер - среда, в которой обработка приложений распределена
междуклиентомисервером.Нередковобработкеучаствуютмашиныразныхтипов,причем
клиент и сервер общаются между собой с помощью фиксированного множества
стандартныхпротоколовобменаипроцедуробращениякудаленнымплатформам.
СУБДсперсональныхЭВМ(такие,какClipper,DBase,FoxPro,Paradox,Clarionимеют
сетевыеверсии,которыепростосовместноиспользуютфайлыбазданныхтехжеформатов
дляПК,осуществляяприэтомсетевыеблокировкидляразграничениядоступактаблицами
записям.ПриэтомвсяработаосуществляетсянаПК.Сервериспользуетсяпростокакобщий
удаленный диск большой емкости. Такой способ работы приводит к риску потери данных
приаппаратныхсбоях.
По сравнению с такими системами системы , построенные в архитектуре Клиент Сервер,имеютследующиепреимущества:
1. позволяют увеличить размер и сложность программ, выполняемых на рабочей
станции;
2. обеспечивает перенесение наиболее трудоемких операций на сервер, являющийся
машинойбольшейвычислительноймощности;
3. уменьшает до минимума возможность потери содержащейся в БД информации за
счет применения имеющихся на сервере внутренних механизмов защиты данных , таких ,
как , например системы трассировки транзакций, откат после сбоя, средства обеспечения
целостностиданных;
4.внесколькоразуменьшаетобъеминформации,передаваемыйпосети.
2.ТеоретическиеосновыСУБДсервераInformix
OnLinev.7.X
2.1СУБДсерверInformix.
Работы над системой управления базами данных Informix были начаты в 1980 г.
Согласно начальному замыслу программный комплекс Informix рассматривался как СУБД,
специально ориентированная для работы в среде ОС UNIX. Для организации хранения
данныхбылвыбранреляционныйподход.СтехпорInformixсталоднойизосновныхСУБД,
работающихвсредеUNIX.
Сейчас продукты Informix уже установлены практически на всех UNIX-компьютерах.
Среди всех ОЕМ фирма выбрала шесть стратегических партнеров. Это: Sequent, HP, SUN,
IBM, Siemens Nixdorf, NCR. Портирование продуктов фирмы на производимые
стратегическимипартнерамиплатформыпроизводитсявпервуюочередь.Практическиэто
означает, что при появлении на рынке новой платформы или новой версии операционной
системыдляплатформыужеимеетсясоответствующаяверсияпродуктовInformix.
СрединеUNIXплатформInformixподдерживаетNetWare,Windows,WindowsNTиDOS.
Фирма Informix объявила и поддерживает программу InSync. Программа объединяет
независимыхразработчиковпрограммногообеспечения.Врамкахэтойпрограммысозданы
программные интерфейсы для связи с СУБД других производителей, в частности СУБД,
функционирующиенанеUNIX-платформах.
2.1.1ОписаниепродуктовInformix
Продукты Informix содержат серверы баз данных, средства разработки и отладки,
коммуникационные средства. Характерной особенностью Informix является наличие
несколькихтиповсерверов,подробнееонихбудетсказанониже.
Начиная с версии 4.0 фирма Informix поставляет сервер базы данных OnLine, который
поддерживает аппарат распределенных транзакций (технология OLTP - on-line transaction
processing), что позволяет по-новому подходить к созданию баз данных с очень большим
объемомхранимойинформации.
Крометого,вInformix-OnLineвключенновыйтипданных-битовыеполя(BLOB-binary
large objects). Битовые поля могут использоваться для мультимедийных приложений
(хранениеизображенийизвука).
2.1.2Типовыеконфигурации
Восновесистем,разработанныхнаосновеСУБДInformix,лежитпринципархитектуры
"клиент-сервер". Клиент - это пользовательская прикладная программа, обеспечивающая
взаимодействие (интерфейс) базы данных с пользователем. Всю работу, связанную с
доступомимодификациейбазыданных,выполняетсервербазыданных(БД-сервер).
Сервер базы данных (database engine), он же ядро базы данных - это отдельная
программа, выполняемая как отдельный процесс. Сервер передает выбранную из базы
информацию по каналу клиенту. Именно сервер работает с данными, заботится об их
размещении на диске. Технологию "клиент-сервер" со стороны сервера обеспечивают
модулиInformix-SE,Informix-OnlineилиInformixOnLine-DynamicServer.
Informix-SEпредставляетсобойсервербазыданных,предназначенныйдляобеспечения
работывсистемахсмалымилисреднимобъемоминформации.
Хранение данных в этом случае осуществляется в файловой системе операционной
системы,чтозначительноупрощаетразработкуиэксплуатациюприложений.
Клиенты и серверы могут находиться на одном компьютере, либо на нескольких,
связанных между собой сетью. Подобное разделение функций дает высокую
производительность и максимальную гибкость. Для обеспечения отношений связи типа
"клиент-сервер"междуразличнымикомпьютерамисосторонысервераприменяетсямодуль
Informix-NET.
Informix-OnLine - это сервер второго поколения, обеспечивающий технологию
распределенных транзакций (OLTP - on-line transaction processing). Технология
распределенных транзакций позволяет выполнять запросы в распределенной базе данных,
физически находящихся на различных компьютерах. По сравнению с Informix-SE сервер
Informix-OnLine имеет специальный тип данных - битовые поля (BLOB - Binary Large
Objects), символьные строки переменной длины, буферизацию транзакций, зеркальный
диск, автоматическое восстановление после системных сбоев, большую скорость (в 2-4
раза).
МодульInformix-Starявляетсясредствомподдержкиработысраспределеннымибазами
данных. Посредством модуля InformixStar осуществляется оперативная обработка
транзакций.
РаботасервераInformixзаключаетсявзапускеспециальнойпрограммы(SQLEXECдля
Informix-SE и SQLTURBO для Informix-OnLine), которая обеспечивает работу всех SQLоператоров. Для каждого клиента запускается процесс операционной системы,
использующийэтупрограмму.Вслучае,есликлиентпрервалработу,ноневышелизсвоей
задачи,тоегопроцессзанимаетресурсысистемы,снижаяеепроизводительность.
Одним из последних достижений фирмы стал выпуск нового сервера базы данных
OnLineDynamicServer,которойвходитвсоставсистемыначинаясверсии6.0.Этотпродукт
основан на так называемой Динамической Масштабируемой Архитектуре (Dynamically
Scalable Architecture - DSA), которая специально ориентирована на работу с
многопроцессорнымисистемами.
OnLine Dynamic Server обеспечивает повышение производительности за счет гибкости
использования ресурсов СУБД, использование многопоточной архитектуры. Фактически
OnLineDynamicServerберетнасебямногиесвязанныесраспределениемресурсовфункции
операционнойсистемы.Врезультатеуменьшаетсянагрузканаоперационнуюсистемы,чтов
конечномсчетеприводиткроступроизводительности.
Для обслуживания клиентов запускаются "виртуальные процессоры" - процессы
операционной системы, которые устанавливают связь между клиентом и ядром Informix.
Связь устанавливается с помощью специальных "нитей" (thread), которые активизируются
только если клиент активен и обращается к серверу базы данных. В случае, если клиент
неактивен,"нить"можетобслуживатьдругихклиентов.
Число виртуальных процессоров определяет администратор базы данных, исходя из
реальныхресурсоввычислительнойсистемыисетиклиентов.Есливычислительнаясистема
является многопроцессорной, то разные виртуальные процессоры могут обслуживаться
разнымиреальнымипроцессорами.
Вверсии6.0сетевыефункциизаложенывядреСУБД.Поэтомудляфункционирования
всетиOnLineDynamicServerмодулиInformix-NetилиInformix-Starнетребуются.
2.2АрхитектураСУБДсервераInformixOnLinev.7.X
КСУБД, претендующим нароль информационнойосновысовременных предприятий,
предъявляютсявсеновыеиболеежесткиетребования.Кчислуважнейшихможноотнести
следующие:
1.высокаяпроизводительность
2.масштабируемость
3.смешаннаязагрузкасервераразнымитипамизадач
4.непрерывнаядоступностьданных
Данный раздел посвящен, главным образом, рассмотрению архитектурных
особенностей и механизмов сервера INFORMIX-OnLine DS, направленных на
удовлетворение перечисленных выше требований. Приводится также информация о
средствахраспределенныхвычислений,безопасности,поддержкинациональнойсреды.
2.2.1.Динамическаямасштабируемаяархитектура
Архитектура сервера INFORMIX-OnLine DS получила название "динамическая
масштабируемая архитектура" (DSA). Суть ее заключается в том, что одновременно
выполняется относительно небольшое число серверных процессов (виртуальных
процессоров), которые разделяют между собой работу по обслуживанию множества
клиентов. По сравнению с более ранними моделями сервера INFORMIX, где для каждого
клиента создавался индивидуальный серверный процесс (рис. 1), новая модель обладает
рядомпреимуществ:
1. снижение нагрузки на операционную систему (число серверных процессов
невелико);
2.сокращениесовокупнойпотребностиклиентоввоперативнойпамяти;
3.снижениеконкуренцииприодновременномиспользованиисистемныхресурсов;
4.болеерациональноепосравнениюсОСназначениеприоритетовипланирование;
Длямногопроцессорныхплатформ:
1.равномернаязагрузканаличныхпроцессоров;
2. ускорение обработки сложных запросов за счет параллельного выполнения на
несколькихпроцессорах.
Пока пользователь анализирует результаты или готовит очередной запрос, серверный
процесспростаивает,занимаясистемныересурсы.
Архитектура
DSA
полностью
использует
возможности
симметричных
многопроцессорныхплатформSMP(SymmetricMultiprocessingsystems),иможетработатьна
однопроцессорных платформах. В последующих версиях предполагается расширить
архитектуру сервера, обеспечив поддержку слабосвязанных систем и систем с массовым
параллелизмом(MPP).ВсебазовыетехнологииDSAявляютсявстроенными,онивключены
в библиотеки сервера, и их применение не зависит от особенностей ОС или аппаратных
платформразличныхпоставщиков.
2.2.1.1Потоки
Архитектуру INFORMIX-OnLine DS называют также многопотоковой. Для каждого
клиента создается так называемый поток, или нить (thread). Поток - это подзадача,
выполняемаяврамкаходногоизсерверныхпроцессов.
В некоторых случаях для обслуживания одного клиентского запроса создается
несколько параллельных потоков. Потоки создаются также для выполнения внутренних
задач сервера - ввода-вывода, журнализации, администрирования и др. Таким образом,
одновременновыполняетсямножествопотоков,которыераспределяютсямеждуналичными
виртуальнымипроцессорами
INFORMIX-OnLine DS не полагается на механизмы потоков, имеющиеся в некоторых
операционных системах. Он формирует потоки, специфичные для задач обработки баз
данных, оптимальные в отношении выделяемой под них памяти, методов планирования и
числаинструкций,затрачиваемыхнапереключениемеждупотоками.
2.2.1.2Виртуальныепроцессоры
Виртуальным процессором называется процесс сервера баз данных. Виртуальный
процессор можно сравнить с операционной системой. Поток по отношению к нему
выступаеткакпроцесс,подобнотому,каксамвиртуальныйпроцессорявляетсяпроцессомс
точкизренияоперационнойсистемы.
Виртуальные процессоры (ВП) являются специализированными - они подразделяются
на классы в соответствии с типом потоков, для выполнения которых они предназначены.
ПримерыклассовВП:
CPU - Потоки обслуживания клиентов, реализуют оптимизацию и логику выполнения
запросов.Кэтомуклассуотносятсяинекоторыесистемныепотоки.
AIO-Операцииасинхронногообменасдиском.
ADM-Административныефункции,например,системныйтаймер.
TLI - Контроль сетевого взаимодействия посредством интерфейса TLI (Transport Layer
Interface).
В отличие от операционной системы, которая должна обеспечивать выполнение
произвольных процессов, классы виртуальных процессоров спроектированы для наиболее
оптимальноговыполнениязаданийопределенноговида.
Начальное число виртуальных процессоров каждого класса, создаваемых при запуске
INFORMIX-OnLineDS,задаетсявконфигурационномфайле.Однако,потребностивкаждом
виде обработки не всегда предсказуемы. Инструменты администрирования позволяют
динамически,неостанавливаясервер,запуститьдополнительныевиртуальныепроцессоры.
Например, если растет очередь потоков к виртуальным CPU-процессорам, то можно
увеличитьихчисло.Точнотакже,возможнодобавлениевиртуальныхпроцессоровобменас
дисками,сетевыхпроцессороввзаимодействиясклиентами,созданиепроцессораобменас
оптическим диском, если он отсутствовал в начальной конфигурации. Динамически
сократитьможнотолькочисловиртуальныхпроцессоровклассаCPU.
На некоторых мультипроцессорных платформах, где OnLine DS поддерживает родство
процессоров (processor affinity), допускается привязка виртуальных CPU-процессоров к
определенным центральным процессорам компьютера. В результате производительность
виртуального CPU-процессора повышается, поскольку операционная система реже
производитпереключениепроцессов.Привязкапозволяеттакжеизолироватьработусбазой
данных,выделяядляэтойцелиопределенныепроцессоры,втовремякакостальныебудут
занятыдругимизадачами.
2.2.1.3Планированиепотоков
Серверосведомленостепенизначимостиразличныхпотоковивсоответствиисэтим
назначает для них приоритеты. Например, потоки ввода-вывода получают приоритеты
следующимобразом:
1.ввод-выводлогическойжурнализации-наивысшийприоритет;
2.ввод-выводфизическойжурнализации-второйпозначимостиприоритет;
3.прочиеоперацииввода-вывода-низшийприоритет.
Такимобразом,гарантируется,чтооперациизаписивлогическийжурнал,откоторых
зависитвосстановлениебазыданныхвслучаесбоя,неокажутсявочередипозадиоперации
выводавовременныйрабочийфайл.
Сами виртуальные процессоры выполняются как высокоприоритетные процессы
операционной системы, которые не прерываются, пока не пусты очереди готовых к
выполнениюпотоков.
Выполнениепотоканеоткладываетсяпоистечениизаданногоквантавремени,какэто
происходитспроцессамивоперационнойсистеме.Потокоткладываетсявдвухслучаях:
1. когда он временно не может выполняться, например, если необходимо дождаться
завершенияобменасдиском,вводаданныхотклиента,снятияблокировки.
2. когда в коде потока встречаются обращения к функции yield. Обращения к ней
вставляются при компиляции запросов, требующих длительной обработки, чтобы их
выполнение не тормозило прохождение других потоков. Для этого выбираются точки,
наиболеебезболезненныедлявыполненияпотока.
2.2.1.4Разделениепотоковмеждувиртуальными
процессорами.
Длякаждогоклассаподдерживаютсятриочередипотоков,которыеразделяютсявсеми
виртуальнымипроцессорамиданногокласса:
Очередь готовых к выполнению потоков.Очередь спящих потоков. В нее помещается,
например, CPU-поток, которому требуется доступ к диску. Предварительно CPU-поток
порождаетзапроснаобменсдиском,дляобслуживаниякоторогоформируетсяAIO-поток.
Завершив обмен с диском, AIO-поток оповещает об этом виртуальный процессор CPU,
который "будит" спящий CPU-поток и перемещает его в очередь готовых потоков.Очередь
ждущих потоков. Эта очередь служит для координации доступа потоков к разделяемым
ресурсам. В нее помещаются потоки, ожидающие какого-либо события, например,
освобождениязаблокированногоресурса.Когдапоток,заблокировавшийэтотресурс,готов
освободить его, просматривается очередь ждущих потоков. Если в ней есть поток,
ожидающийименноэтотресурс,тоонперемещаетсявочередьготовых.
Есливыполняемыйпотокзавершается,засыпаетилиоткладывается,тоосвободившийся
виртуальный процессор выбирает из очереди готовых очередной поток с наивысшим
приоритетом. Как правило, OnLine DS стремится выполнять поток на одном и том же
виртуальном процессоре, поскольку передача его другому процессору требует пересылки
некоторогообъемаданных.Темнеменее,еслипотокготовквыполнению,онможетбыть
продолжен другим процессором, с целью исключения простоев и обеспечения общего
балансазагрузки.
2.2.1.5Экономияпамятиидругихресурсов
Рациональноеиспользованиересурсовоперационнойсистемыдостигаетсязасчеттого,
что потоки разделяют ресурсы (память, коммуникационные порты, файлы) виртуального
процессора, на котором они выполняются. Виртуальный процессор сам координирует
доступ потоков к своим ресурсам. Процессы же, в отличие от потоков, имеют
индивидуальные наборы ресурсов, и, если ресурс требуется нескольким процессам, то
доступкнемурегулируетсяоперационнойсистемой.
Переключение виртуального процессора с одного потока на другой, в целом,
происходит быстрее, чем переключение операционной системы с одного процесса на
другой.Операционнаясистемадолжнапрерватьодинпроцесс,выполняемыйцентральным
процессором, сохранить его текущее состояние (контекст) и запустить другой процесс,
предварительно поместив в ядро его контекст, что требует физической перезаписи
фрагментов памяти. Поскольку потоки разделяют виртуальную память и дескрипторы
файлов, то переключение виртуального процессора с потока на поток может сводиться к
перезаписи небольшого управляющего блока потока, что соответствует выполнению
примерно 20 машинных команд. При этом виртуальный процессор как процесс
операционнойсистемыпродолжаетвыполнятьсябезпрерывания.
2.2.2Организацияразделяемойпамяти
Разделяемая память - это механизм операционной системы, на котором основано
разделение данных между виртуальными процессорами и потоками сервера. Разделение
данныхпозволяет:
Снизитьобщеепотреблениепамяти,посколькуучаствующимвразделениипроцессам,
т. е. виртуальным процессорам, нет нужды поддерживать свои копии информации,
находящейсявразделяемойпамяти.Сократитьчислообменовсдисками,потомучтобуферы
ввода-вывода сбрасываются на диск не для каждого процесса в отдельности, а образуют
один общий для всего сервера баз данных пул. Виртуальный процессор зачастую избегает
выполнения или обращения за результатами операций ввода с диска, поскольку нужная
таблица уже прочитана другим процессором.Организовать быстрое взаимодействие между
процессами. Через разделяемую память, в частности, обмениваются данными потоки,
участвующиевпараллельнойобработкесложногозапроса.Разделяемаяпамятьиспользуется
такжедляорганизациивзаимодействиямеждулокальнымклиентомисервером.
Управление разделяемой памятью реализовано таким образом, что ее фрагментация
минимизируется, поэтому производительность сервера при ее использовании не
деградирует с течением времени. Изначально выделенные сегменты разделяемой памяти
наращиваютсяпомеренадобностиавтоматическииливручную.Приосвобождениипамяти,
занятойсервером,онавозвращаетсяоперационнойсистеме.
Вразделяемойпамятинаходитсяинформацияобовсехвыполняемыхпотоках,поэтому
потоки относительно быстро переключаются между виртуальными процессорами. В
частности, в разделяемой памяти выделяется область стеков потоков. Стек хранит данные
дляфункций,выполняемыхпотоком,идругуюинформациюосостояниипользовательского
сеанса. Размер стека для каждого сеанса устанавливается при помощи переменной
окружения.
Важный оптимизирующий механизм сервера - кэши хранимых процедур и словарей
данных. Словари данных (system catalog), доступные только на чтение, а также хранимые
процедуры, разделяются между всеми пользователями сервера, что позволяет
оптимизировать совокупное использование памяти. При загрузке в разделяемую память
словарьданныхзаписываетсявструктуры,обеспечивающиебыстрыйдоступкинформации,
ахранимыепроцедурыпреобразуютсяввыполняемыйформат.Всеэтоможетсущественно
ускорить выполнение приложений, обращающихся ко многимтаблицамс большимчислом
столбцови/иликомногимхранимымпроцедурам.
2.2.3Организацияоперацийобменасдисками
Операции ввода-вывода, как правило, образуют наиболее медленную компоненту
обработки баз данных. Поэтому от их реализации существенно зависит общая
продуктивностьсервера.Дляоптимизацииввода-выводаиповышениянадежностивсервере
INFORMIX-OnLineDSприменяютсяследующиемеханизмы:
собственное управление дисковой памятью;асинхронный ввод-вывод;опережающее
чтение.
2.2.3.1Управлениедисковойпамятью
INFORMIX-OnLine DS поддерживает как собственный механизм управления дисковой
памятью, так и управление средствами файловой системы ОС UNIX. Преимущества
собственногомеханизмауправлениядисковойпамятью:
Снятие ограничений операционной системы на число одновременно читаемых
таблиц.Оптимизация размещения таблиц - для таблиц выделяются большие области
последовательных физических блоков, в результате ускоряется доступ к ним.Снижение
накладных расходов при чтении - данные с дисков считываются непосредственно в
разделяемую память, минуя буферы ОС.Повышение надежности. При использовании
файловойсистемыINFORMIX-OnLineDSнеможетгарантировать,чтовслучаесбояданные
журнала транзакций не пропадут из-за того, что они остались в буферах ОС и не успели
записаться на диск. Поэтому процедура быстрого восстановления, вызываемая при
перезапускесистемы,необеспечитвэтомслучаецелостностиданных.
Файловуюсистемуиспользуютвситуациях,когданетвозможностивыделитьподбазы
данных специальные разделы на дисках, или если перечисленные соображения не
критичны.
2.2.3.2Асинхронныйввод-вывод
Для ускорения операций ввода-вывода сервер использует собственный пакет
асинхронного ввода-вывода (AIO) или пакет асинхронного ввода-вывода ядра ОС (KAIO),
если он доступен. Пользовательские запросы на ввод-вывод обрабатываются асинхронно,
поэтомувиртуальнымпроцессорамCPUнеприходитсяждатьзавершенияоперацииобмена,
чтобыпродолжитьобработку.
2.2.3.3Опережающеечтение
Сервер OnLine DS может быть сконфигурирован таким образом, чтобы при чтении
последовательной таблицы или индексного файла обеспечивалось опережающее чтение
нескольких страниц в то время, пока обрабатываются уже прочитанные в разделяемую
память данные. Таким образом, сокращается время ожидания обмена с диском, и
пользовательбыстрееполучаетрезультатызапроса.
2.2.4Поддержкафрагментациитаблицииндексов
INFORMIX-OnLine DS поддерживает горизонтальную локальную фрагментацию
таблиц. Это такой способ хранения таблицы, когда совокупность ее строк разбивается на
несколько групп согласно некоторому правилу, и эти группы хранятся на разных дисковых
разделах.Фрагментациятаблицспособствуетдостижениюследующихцелей:
Сокращается время обработки одного запроса. Встроенный в INFORMIX-OnLine DS
механизмPDQприобработкезапросовиспользуетинформациюофрагментациитаблици
создает для сканирования таблицы несколько параллельных потоков. Если стратегия
фрагментациивыбранаудачно,тоускорениепривыборкеизтаблицыпрактическилинейно
зависитотчислафрагментов(рис.3).Снижаетсяуровеньконкуренцииприодновременном
обращении нескольких запросов к одной таблице. INFORMIX-OnLine DS анализирует
правило фрагментации таблицы и во многих случаях способен определить, что данный
запрос относится только к одному ее фрагменту. Если фрагменты хранятся на разных
дисковых устройствах, то разным запросам будут соответствовать обращения к разным
дискам.Повышается готовность (доступность) приложений. Даже если некоторые
фрагменты таблицы недоступны из-за того, что соответствующие диски вышли из строя,
запросы к ней, тем не менее, во многих случаях могут выполняться.Улучшаются
характеристики административных операций, таких как архивирование-восстановление,
загрузка-выгрузка данных, поскольку они применимы к отдельным фрагментам таблиц.
Если таблица разбита на малые фрагменты, то ее восстановление при выходе из строя
одного фрагмента выполняется значительно оперативнее, чем полное восстановление
нефрагментированной таблицы. Полные операции архивирования, восстановления,
загрузки, выгрузки данных также ускоряются, поскольку операции ввода-вывода для
фрагментовтаблицывыполняютсяпараллельно.
Различаютсядватипаправилфрагментациитаблиц:
Равномерное распределение (round robin) - это встроенный в INFORMIX-OnLine DS
механизм фрагментации, который обеспечивает примерно равное число записей в каждом
фрагменте.Распределение по выражению (by expression) - для каждого фрагмента задается
некоторое выражение, зависящее от значений полей записи; истинность выражения
определяет,попадетлизаписьвданныйфрагмент.
Правило разбиения таблицы задается в SQL-инструкциях CREATE TABLE (создать
таблицу),ALTERTABLE(изменитьтаблицу).
Пример:
CREATETABLEaccount...
FRAGMENTBYEXPRESSION
id_num>0ANDid_num<=20INdbsp1
id_num>20ANDid_num<=40INdbsp2
REMAINDERINdbsp3
Здесь dbsp1, dbsp2, dbsp3 - имена областей дискового пространства, выделенного под
БД.
INFORMIX-OnLineDSподдерживаеттакжефрагментациюиндексов.
Различаются два вида фрагментации индексов - зависимая (соответствующая
фрагментации таблицы) и независимая. Фрагментированной таблице может
соответствовать нефрагментированный индекс. Создание индекса с правилом
фрагментации,несовпадающимсправиломфрагментациитаблицы,полезновтехслучаях,
когда в разных приложениях выборки из таблицы осуществляются на основе разных
подмножествееатрибутов.
Стратегияфрагментациитаблицииндексоввыбираетсявзависимостиотцели,которая
преследуется, от структуры таблицы и характера запросов к ней. Различные стратегии
подробноописанывдокументации.Например,еслиосновнойцельюявляетсяуменьшение
конкуренции при одновременном доступе к таблице, то оптимальной будет фрагментация
таблицы по диапазонам значения ключа (или другого столбца, на основе которого
производитсяосновнойдоступктаблице)изависимаяфрагментацияиндекса.
INFORMIX-OnLine DS предоставляет средства наблюдения, позволяющие оценить
эффективностьфрагментациитаблицииндексовпоследующимпараметрам:
1.Распределениеданныхпофрагментам;
2.Балансзапросовнаввод-выводпофрагментам;
3.Статусдисковыхобластей,содержащихфрагменты.
Еслинаблюденияпоказывают,чтовыбраннаястратегиянеудовлетворяетпоставленной
цели,топравилафрагментациимогутбытьизмененыдинамически,безостановкисервера.
Важно,чтофрагментациятаблицииндексовпрозрачнадляприложений,работающихс
базой данных. Изменение правила фрагментации не требует никаких изменений в
прикладных системах - оно лишь повышает (или снижает) скорость и экономичность их
выполнения.
2.2.5Параллельнаяобработказапросов
Параллельнаяобработказапросов(Parallel Data Query, PDQ) -это технология, которая
позволяет распределить обработку одного сложного запроса на несколько процессоров,
мобилизоватьдляеговыполнениямаксимальнодоступныесистемныересурсы,вомногораз
сокращая время получения результата. Основные типы заданий, на которых проявляется
эффекттехнологииPDQ:
обработкасложныхзапросов,включающихсканированиебольшихтаблиц,сортировку,
соединения, группирование, массовые вставки;построение индексов;сохранение и
восстановление данных;загрузка, выгрузка данных, реорганизация баз данных;массовые
операциивставки,удаления,модификацииданных.
Практическиэтоозначает,чтоотчетилиответнасложныйзапрос,откоторогозависит
принятиеответственногорешения,можнополучитьнезавтра(посленочнойобработки),а
непосредственно во время обычной оперативной дневной работы. Снимаются проблемы,
связанныесобработкойиобслуживанием(архивированием,копированием)оченьбольших
таблиц - благодаря фрагментации, параллельной обработке и возможностям выполнения
административных действий в оперативном режиме. В результате расширяется класс
потенциальных приложений, и, соответственно, круг пользователей, более гибким
становитсярежимработыИС,причемвсеэтодостигаетсяненаузкоспециализированных,а
на обычных широко распространенных аппаратных платформах. Таким образом, можно
говоритьоновомкачестве,котороепривноситссобойтехнологияPDQ.
Максимальныепреимуществаэтатехнологиядаетнамногопроцессорныхплатформахв
условиях применения фрагментации таблиц, где время выполнения запроса сокращается в
десятки раз; однако выигрыш в производительности достигается и на однопроцессорных
машинах и нефрагментированных таблицах за счет того, что доступ к дискам
осуществляется параллельнос другими видами обработки, иза счет максимально полного
использованияпамяти.
2.2.5.1НачемоснованатехнологияPDQ
Реализация запроса состоит из отдельных действий - сканирования, сортировки,
группирования и др. Эти действия называются итераторами. Итераторы образуют дерево
реализации запроса в том смысле, что результаты выполнения одних итераторов являются
исходными данными для других. При обычной обработке итераторы выполняются
последовательно. В основе технологии PDQ лежат следующие виды оптимизации и
регулирования:
Параллельный ввод и вывод (на основе горизонтальной фрагментации
таблиц).Распараллеливание отдельных итераторов (на основе методов разбиения
данных).Распараллеливаниепланавыполнениязапроса(путемразбиениядеревареализации
запроса на независимые поддеревья; за счет применения техники потоков
данных).Снижение вычислительной сложности алгоритмов (применение основанных на
хешировании алгоритмов сортировки, соединения, вычисления агрегатных функций (sum,
min, max, avg, ...)).Управление ресурсами, регулирование степени распараллеливания (под
PDQвыделяетсяопределеннаядолясистемныхресурсов).
2.2.5.2Итераторы
Итератор - это программный объект, который осуществляет итеративную
(циклическую) обработку некоторого множества данных. Итераторы различаются типом
производимойобработки,ноимеютединообразныйвнешнийинтерфейс.Каждыйитератор
открываетодин(илиболее)входныхпотоковданных(dataflow),последовательносчитывает
их и, после обработки, помещает результаты в выходной поток. Итератору безразличен
источник входного потока и назначение выходного потока - это может быть диск, другой
итератор, сетевое соединение. Мы будем говорить о поставщиках и потребителях потоков
данных.Нижеперечисленытипыитераторов,применяемыевINFORMIX-OnLineDS:
SCAN - Сканирует фрагментированные и нефрагментированные таблицы и индексы.
NESTED LOOP JOIN - Реализует стандартную логику соединений методом вложенных
циклов(читаетстрокуизоднойтаблицы,находитвсесовпадениявовторойтаблице,читает
следующуюстрокуизпервойтаблицыит.д.).MERGEJOIN-Выполняетфазуслияниядля
соединения методом сортировки и слияния. HASH JOIN - Реализует новый метод
соединенийсхешированием.Дляоднойиздвухсоединяемыхтаблицстроитсяхеш-таблица,
вторая таблица зондируется. Оптимизатор решает, какая из таблиц будет хешироваться.
GROUP - Группирует данные (GROUP BY) и вычисляет агрегатные функции. SORT Сортирует данные. MERGE - Выполняет объединения UNION и UNION ALL (для UNION
используется комбинация итераторов MERGE и SORT). REMOTE - Реализует удаленные
сканированиядляоператоровSELECT.
Итератор как программный объект состоит из статических и динамических структур
данных.Статическаяструктурасодержитссылкинафункции(илиметоды),применимыек
итератору.Динамическаяструктурасодержитинформациюотекущемсостоянииитератора
(открыт,закрыт,выполняеточереднуюитерацию),однуилидвессылкинапоставщиков.
Методыитератора
CREATE() - Создает итератор. Выделяет память для итератора, инициализирует его
структуры, а также остальные методы (open(), next(), close(), free()), т.е. устанавливает
ссылки на функции, соответствующие данному типу итератора. Затем вызывает метод
create() для своих итераторов-поставщиков, которые создадут своих поставщиков, если
таковые имеются, и т. д. Таким образом, вызов метода create() для корневого итератора
приводитксозданиювсегодереваитераторов.
OPEN()-Запускаетитератор.Выполняютсяспецифическиедляданноготипаитератора
инициализирующие действия, возможно, запрос дополнительной памяти. Например, при
запуске итератора сканирования определяется, какие фрагменты необходимо сканировать,
устанавливаетсяуказательнапервыйизних,создаетсявременнаятаблица(еслионанужна),
посылаетсясообщение
MGM (MGM - компонента сервера, которая регулирует выделение ресурсов под
запросы,обрабатываемыесредствамиPDQ;см.обэтомниже,п."БалансмеждуOLTPиDSSприложениями") о запуске потока сканирования. Далее применяется метод open() по
отношению к поставщикам итератора, которые применят его к своим поставщикам и т.д.
Таким образом, для запуска всего дерева итераторов достаточно применить метод open() к
корневомуитератору.
NEXT() - Выполняет одну итерацию. Выполнение начинается с того, что итератор
применяетметодnext()ксвоимпоставщикам,заставляяихтакжеприменитьnext()ксвоим
поставщикам и т. д., пока не сработают итерации поставщиков нижнего уровня. Затем
данныеподнимаютсяснизувверх-каждыйитератор,получивданныеотсвоегопоставщика,
применяет к ним свой специфический вид обработки и передает результат своему
потребителю. Метод next() применяется циклически, пока не поступит признак конца
потокаданных.
CLOSE() - Закрывает итератор. Высвобождает память, выделенную при запуске.
Фактически, эта память могла уже быть высвобождена методом next(), когда он получил
признакконцаданных,посколькуобщийпринципсостоитвтом,чтобыосвобождатьпамять
сразуже,кактолькоонастановитсяненужна.Однако,этоневсегдавозможно.Поэтомуна
метод close() возлагается ответственность за то, чтобы память в любом случае была
освобождена.
Метод close() рекурсивно применяется к поставщикам, тем самым, закрывается все
деревоитераторов.
FREE() - Освобождает итератор. Высвобождает память, выделенную при создании.
Применяетfree()кпоставщикам,такимобразом,освобождаетсявседеревоитераторов.
Благодаряединообразиюинтерфейса,итераторыразныхтиповмогутсоединятьсядругс
другомпроизвольнымобразом(рис.5).Итераторнезаботитсяотом,какойтипимеютего
поставщики, поскольку он взаимодействует с ними только посредством методов. Из
описания методов следует, что запуск дерева, составленного из итераторов, реализует их
параллельное выполнение. Для каждого итератора создается поток выполнения, который
продвигается по мере того, как получает данные от своих поставщиков. Таким образом в
серверереализуетсявертикальныйпараллелизм-одновременное,конвейерноевыполнение
различныхитераторов.
Другой вид параллелизма - горизонтальный - заключается в том, что вместо одного
итератора (например, сканирования) создается несколько однотипных параллельно
выполняемых итераторов. Горизонтальный параллелизм реализуется при помощи
итераторов специального вида - итераторов обмена (EXCHANGE). После того, как дерево
реализации запроса построено, оптимизатор определяет, какие его компоненты имеет
смыслраспараллелить.НадтакойкомпонентойвставляетсяитераторEXCHANGE.Итератор
EXCHANGE создает и запускает несколько экземпляров своего поставщика, обеспечивает
координацию поступающих от них потоков данных и их передачу своему потребителю.
Передачаданныхосуществляетсявэтомслучаенечерезвходыпотребителя,ачерезочереди
пакетоввразделяемойпамяти.
Степень и наиболее оптимальные способы применения вертикального и
горизонтального параллелизма для каждого конкретного запроса определяется
оптимизатором. Оптимизатор принимает решения, исходя из значений параметров
конфигурации, устанавливаемых администратором, пользователем и клиентским
приложением, а также с учетом некоторых внутренних соображений, таких как число
наличныхпроцессоров,фрагментацияучаствующихвзапросетаблиц,сложностьзапросаи
т.д.
Результатытестовпоказывают,чтомеханизмыPDQиоптимизацииINFORMIX-OnLine
DS обеспечивают с увеличением числа процессоров практически пропорциональный рост
производительности.
2.2.5.3Примерыпримененияпараллелизма
Параллельнаясортировка
Сортировка- это фундаментальная операция обработкибаз данных, применяемая при
выполнении таких действий, как построение индексов, соединение методом сортировки и
слияния, группирование; поэтому ускорение сортировки улучшает качество многих
приложений.
При параллельной сортировке совокупность данных разбивается на секции, которые
передаются для сортировки нескольким процессорам. Затем выполняется слияние
отсортированныхсекций.
На практике скорость сортировки ограничивается временем сканирования данных из
таблиц. Это ограничение в значительной мере снимается применением PDQ-алгоритмов
параллельногосканирования.
Параллельноесканирование
Операции построения индексов, соединений, подготовки отчетов, необходимые в
большинстве приложений, требуют сканирования больших объемов данных, если в них
участвуют большие таблицы. Технология PDQ позволяет существенно снизить время
сканирования. Если таблица фрагментирована, то секции сканируются параллельно, при
этом выигрыш во времени примерно пропорционален числу дисков. При сканировании
последовательных таблиц или индексов применяется конфигурация сервера OnLine DS с
опережающим чтением - время отклика сокращается за счет того, что чтение очередных
страницидетпараллельнособработкойужепрочитанных.
Параллельноепостроениеиндексов
Процедура построения индекса начинается с оценки объема данных и определения
числа потоков, необходимых для их сканирования. Затем выполняется параллельное
сканирование данных с применением, там, где это возможно, опережающего чтения.
Считанныеданныепомещаютсявучасткиразделяемойпамяти,изапускаетсяпараллельная
сортировка участков, для каждого из которых строится Вподдерево; затем из них
формируется общий индекс. Потоки сортировки начинают выполняться, не дожидаясь
завершениявсехпотоковсканирования,точнотакже,потокпостроенияиндексанеожидает
завершения всех потоков сортировки - все, что можно, выполняется параллельно. В
результате достигается ускорение, вплоть до десятикратного, по сравнению с
последовательными методами построения индексов - в зависимости от объемов данных,
числаиспользуемыхдисковидоступнойпамяти.
2.2.5.4БалансмеждуOLTPиDSS-приложениями
В современных информационных системах, как правило, требуется одновременное
выполнение разных по характеру запросов к базе данных. Выделяются приложения
обработкиданныхтипаOLTP,DSSипакетнойобработки.
Пример OLTP-запроса: Есть ли свободный номер в какой-либо берлинской гостинице
на8-едекабря?
Пример DSS-запроса: Каковы будут затраты на реализацию стратегии X охраны
здоровья сотрудников по сравнению со стратегией Y с учетом демографического профиля
компании?Зависитлиэффективностьстратегииотрегиона?
Примерами заданий пакетной обработки могут служить массовая загрузка данных,
выдача больших сложных отчетов, выполнение некоторых административных действий,
например,пореорганизациибазыданных.
Ответыназапросыпервоготипадолжнывыдаватьсяпрактическимгновенно,запросы
второго и третьего типов могут обслуживаться достаточно долго, но при отсутствии или
малой интенсивности OLTP-приложений желательно получать ответы на DSS-запросы
максимальнобыстро.
Технология PDQ используется в основном для быстрого выполнения DSS-запросов и
пакетных приложений. Если ее применение ничем не ограничено, то сильно
распараллеленное выполнение нескольких сложных запросов приводит к недопустимому
замедлению OLTP-приложений, выполняющихся на том же сервере. Управление степенью
распараллеливаниязапросовидолейсистемныхресурсов,выделяемыхдляPDQ-обработки,
в среде INFORMIX-OnLine DS осуществляется при помощи нескольких параметров
конфигурированияипеременныхокружения,значениякоторыхдинамическинастраиваемы.
Значения этих параметров и переменных устанавливаются системными администраторами
и,вопределеннойстепени,прикладнымипрограммистамиипользователями.
Программист или пользователь задает тип каждого запроса (обычный или PDQ) и
желаемую степень распараллеливания для PDQ-запросов. Администратор, со своей
стороны,
динамически
ограничивает
максимальную
допустимую
степень
распараллеливания PDQ-запросов, а также определяет долю системных ресурсов,
выделяемых под обработку PDQ-запросов. Параллельная сортировка применяется для
любыхзапросов,втомчисле,обычных.
Таким образом, режим работы сервера INFORMIX-OnLine DS может динамически
изменяться. В часы наиболее активной работы приложений OLTP запросы DSS
выполняются без распараллеливания (когда для каждого запроса создается всегда только
одинпотокклассаCPU)илисневысокойстепеньюраспараллеливания.Востальноевремя,
илинасерверах,гдеприложенияOLTPотсутствуют,устанавливаетсямаксимальнаястепень
использованияPDQ.
Собственнораспределениемресурсовиприоритетоввсоответствиисустановленными
значениямизанимаетсяспециальнаякомпонентасервераOnLineDS-Менеджервыделения
памяти (Memory Grant Manager - MGM). Менеджер выделения памяти регулирует объем
системныхресурсов,потребляемыхPDQ-заданиями,атакже:
устанавливает приоритет каждого запроса;следит за тем, чтобы одновременно
выполнялось не более заданного числа PDQ-запросов;следит за тем, чтобы объем
разделяемой памяти, занятой под обработку сложных запросов, не превышал заданного
уровня;совместно с оптимизатором запросов обеспечивает максимальную при заданных
параметрахстепеньпараллелизманавсехуровнях.
2.2.6Оптимизаторвыполнениязапросовпостоимости
Оптимизатор запросов определяет наиболее оптимальный с точки зрения затрат
системных ресурсов план реализации каждого запроса к базе данных. Учитывается число
обменовсдиском,затратыразделяемойпамяти,затратынапересылкуданныхпосетиидр.
План может включать параллельное выполнение операций или быть строго
последовательным, что зависит как от структуры запроса, так и от ресурсов, выделяемых
MGM.Оптимизаторопираетсянастатистическуюинформациюораспределенииданныхпо
столбцамтаблиц,периодическимсборомкоторойуправляетадминистратор.
Например, если требуется выполнить соединение двух таблиц, находящихся в разных
узлахсети,тооптимизаторспланируетэтуоперациютакимобразом,чтоменьшаяпообъему
таблица будет передана на сервер, содержащий большую таблицу, где и будет выполнено
соединение(необязательновыполнятьегонатомсервере,ккоторомупроизведенопервое
подключение). Дополнительная оптимизация достигается за счет фильтрации таблицы
перед ее пересылкой, т. е. изъятия из нее не участвующих в данной операции соединения
строки/илистолбцов.
Оптимизатор дает возможность разработчику предварительно получить план
выполнения запроса, в том числе, распределенной транзакции. Получив такой план,
разработчик может выяснить, что не располагает достаточной памятью, чтобы сохранить
полученныеврезультатеданные,иличтовыполнениезапросапотребуетслишкомбольших
затрат системных ресурсов. В такой ситуации он либо отложит выполнение запроса на
другоевремя,либопереформулируетзапростак,чтобысузитьобъемвозвращаемыхданных,
либоприметкакое-тодругоерешение.
Прикладной программист или пользователь устанавливает один из двух возможных
уровнейоптимизации- высокий или низкий. Высокий уровень оптимизации предполагает
перебор большого числа возможных вариантов и сам требует больших затрат системных
ресурсов,вчастности,памяти.Оптимизациянизкогоуровняобходитсядешевле,поскольку
перебирается небольшое число предположительно оптимальных вариантов, но остается
вероятность "упустить" наилучший вариант. Например, план выполнения хранимой
процедурывычисляетсязаранеесвысокимуровнемоптимизацииисохраняется,послечего
устанавливается низкий уровень - тогда при обращении к процедуре используется
построенныйзаранеенаиболееоптимальныйплан.
2.2.7Средстваобеспечениянадежности
Сервер INFORMIX-OnLine DS предоставляет следующие средства для восстановления
послесбоевиобеспеченияотказоустойчивости:
Зеркалирование дисковых областейПолное тиражирование данных сервераБыстрое
восстановлениепривключениисистемыСредстваархивированияданных
2.2.7.1.Зеркалированиедисковыхобластей
ЗеркалированиевINFORMIX-OnLineDS-этодублированиесвязнойдисковойобласти,
выделеннойподбазуданных,натакуюжепоразмеруобласть.Исходнаяобластьназывается
первичной, а ее копия - зеркальной. Цели, для которых применяется зеркалирование высокаяготовностьиоптимизацияоперацийчтения.
Высокая готовность достигается за счет того, что при выходе из строя диска, на
котором находится первичная область, сервер автоматически продолжает работу с
оставшимся диском без перехода сервера в режим off-line. Все операции чтения-записи
происходят с зеркальной областью (при условии, что она находится на другом диске).
Восстановление копии на первичном диске после его включения производится в
оперативномрежиме.
Затратыназеркалированиескладываютсяиззатратдисковогопространстваизатратна
дополнительные операции записи. В условиях, когда имеется несколько виртуальных
процессоровобменасдиском,операциизаписинаобадискапроизводятсяпараллельно,и
затраты второго рода сводятся к минимуму. К тому же они компенсируются оптимизацией
операцийчтения,окоторойговоритсяниже.
В идеальном случае зеркалирование должно быть обеспечено для всех областей базы
данных. Крайне желательно поддерживать зеркалирование для критичных областей,
составляющихкорневоепространствобазыданныхипространства,гдехранятсялогический
и физический журналы. При выходе из строя любого из них, если нет зеркального дубля,
сервер немедленно переводится в режим off-line. При отказе других незеркалируемых
областей недоступными становятся только хранящиеся на них таблицы или фрагменты
таблиц - до завершения процедуры их восстановления. Поэтому для наиболее критичных
таблицтакжежелательноподдерживатьзеркалирование.
Оптимизация операций чтения достигается за счет разбиения (split read). Страницы,
относящиесякначальнойполовинеобласти,читаютсяспервичнойобласти,астраницыиз
второй половины - с зеркальной. В результате ускоряется поиск страницы на диске,
посколькумаксимальныйпробегдисковыхголовоксокращаетсявдвое.
2.2.7.2Тиражирование
Тиражирование - это поддержание на другой вычислительной установке копии
объектов базы данных. В INFORMIX-OnLine DS реализовано прозрачное тиражирование
данных с основного сервера баз данных на вторичный (или поддерживающий) сервер, к
которому разрешен доступ только на чтение и который может находиться в другом
географическом пункте. В этой терминологии сервер, не участвующий в тиражировании,
называетсястандартным.
Главная цель тиражирования в INFORMIX-OnLine DS - это обеспечение высокой
готовности (High Availability Data Replication - HDR). В случае отказа основного сервера
вторичномусерверуавтоматическииливручнуюпридаетсястатусстандартного,сдоступом
начтениеизапись.Прозрачноеперенаправлениеклиентовприотказеосновногосерверане
поддерживается,ноономожетбытьреализовановрамкахприложений.
После восстановления основного сервера, в зависимости от значения параметра
конфигурации,выбираетсяодиниздвухвозможныхсценариев:
Восстановленномусерверувновьпридаетсястатусосновного.Вторичныйсервер,перед
возвращением в режим доступа только на чтение, останавливается, чтобы обеспечить
отсоединение клиентов, которые осуществляли доступ на запись.Восстановленный сервер
становится вторичным, а бывшему вторичному, который уже функционирует в режиме
чтения-записи, придается статус основного; клиенты, которые подключены к нему,
продолжаютработу.Этотсценарийобеспечиваетнепрерывнуюдоступностьбазданных.
Тиражирование осуществляется путем передачи информации из журнала транзакций
(логическогожурнала)вбуфертиражированияосновногосервера,откудаонапересылается
в буфер тиражирования вторичного сервера. Такая пересылка может происходить либо в
синхронном, либо в асинхронном режиме. Синхронный режим гарантирует полную
согласованностьбазданных-ниоднатранзакция,зафиксированнаянаосновномсервере,не
останется незафиксированной на вторичном, даже в случае сбоя основного сервера.
Асинхронный режим не обеспечивает абсолютной согласованности, но улучшает рабочие
характеристикисистемы.
Зеркалирование, которое также является прозрачным средством поддержания высокой
готовности, обеспечивает только копирование дисковых областей в пределах одной
установки сервера INFORMIX-OnLine DS и защищает только от дисковых сбоев. Механизм
тиражированияобеспечиваетподдержаниеполнойудаленнойкопиибазданныхизащищает
отвсехвидовотказов,включаяполныйкраходнойизустановок.
Помимо обеспечения отказоустойчивой работы, тиражирование дает следующие
преимущества:
более оперативный доступ к данным для локальных клиентов вторичного
сервера;возможностьвынестиприложенияDSSпреимущественнонавторичныйсервер,где
они выполняются с максимальным использованием PDQ, не подавляя приложений OLTP,
выполняющихсянаосновномсервере.
2.2.7.3Быстроевосстановлениепривключениисистемы
При включении сервер всегда проверяет, не произошло ли последнее выключение
системы аварийно. В этом случае база данных не разрушена, но множество транзакций,
выполнявшихся в момент сбоя, остались в незавершенном, некорректном состоянии. Если
сервер выявил такую ситуацию, то он запускает процедуру быстрого восстановления,
котораяобеспечиваетвозвратсистемывкорректноесостояние.
2.2.7.4Архивированиеивосстановлениеданных
INFORMIX-OnLine DS позволяет создавать архивные копии данных, а в дальнейшем
фиксировать те изменения, которые произошли на сервере с момента создания архива.
Изменениясохраняютсявфайлахжурналатранзакций.Архивныелентыилентыскопиями
журналовтранзакциймогутзаписыватьсяпараллельносдоступомпользователейксерверу.
Процедуравосстановлениясостоитиздвухшагов-считыванияданныхизархивнойкопиии
применениякнимтехизменений,которыебылизафиксированывжурналахтранзакций.
В состав сервера INFORMIX-OnLine DS входит утилита OnArchive, предоставляющая
развитые и гибкие средства архивирования, копирования журналов транзакций и
восстановленияинформации.Нижеперечисленыосновныевозможностиэтойутилиты:
Архивированиеивосстановлениенауровнедисковыхобластей(dbspace).Архивируется
однаилинесколькодисковыхобластей.Соднойархивнойлентыможновосстановитьодну
или несколько дисковых областей. Поддерживается инкрементальное архивирование (т. е.
сохранение только информации, которая изменилась с момента создания последнего
полного или инкрементального архива).Восстановление данных в оперативном режиме. В
случае сбоя носителя, если не затронуты критические для работоспособности INFORMIXOnLineDSдисковыеобласти,пользователипродолжаютвзаимодействиессервером.Доступ
кданным,находящимсянавышедшемизстрояносителе,возобновляетсяпослезавершения
процедурывосстановления.Составлениеипросмотррасписанияоперацийархивированияи
резервирования. Операции производятся автоматически, по заданному расписанию.Метки
наархивныхлентах.Наличиеметоксводиткминимумурисктакихошибокадминистратора,
как запись на ленту, на которой находится часть активного в данный момент архива, или
восстановление данных с устаревшей архивной ленты.Интерактивный интерфейс с
оператором, основанный на меню и экранных формах.Средства восстановления при
катастрофах. В случае катастрофического краха информация каталога архивирования/
восстановления,поддерживаемогосерверомINFORMIX-OnLineDS,можетбытьпрочитанас
заголовка архивной ленты.Множественные копии архивов на лентах. Сервер INFORMIXOnLine DS способен одновременно создавать множественные копии архивов и журналов
транзакций на нескольких лентопротяжных устройствах. В случае краха восстановление
выполняетсяслюбойизкопий.Опциишифрованияисжатияархивовижурналовтранзакций
призаписи.Засчетсжатияобъемнеобходимойвторичнойпамятисокращаетсянавеличину
от20до50процентов.Контрольциклическойизбыточностью(CRC).Этотметодпозволяет
контролировать правильность информации, считываемой с ленты. При вводе данных с
архивной ленты контрольная сумма, хранящаяся на ленте, сверяется с вычисляемой
контрольнойсуммой.Предоставление определеннымпользователям правна архивирование
ивосстановлениенекоторыхдисковыхобластей.
2.2.8Динамическоеадминистрирование
Вусловиях,когдабазыданныхувеличиваютсявразмерах,становятсяраспределенными
и служат основой для особо ответственных приложений масштаба предприятия, которые
должны работать круглосуточно, возрастает роль развитых динамических средств
администрирования.Этисредствадолжныпозволятьадминистраторамоперативноследить
за такими характеристиками работы сервера, как использование памяти и виртуальных
процессоров,очередиасинхронноговвода-вывода,очередипакетныхзаданийиприложений
DSS, наличное дисковое пространство, эффективность схем фрагментации и т. п. Если
какие-тоизхарактеристикнеудовлетворительны,тонеобходимавозможностьдинамически,
не останавливая системы, изменить параметры конфигурации или запустить необходимые
административныеутилиты.
Большинство параметров конфигурации сервера являются динамически
настраиваемыми, их можно изменить, не останавливая сервера, при помощи утилиты ONMonitor.Помиморассмотренныхвышеменеджерапамяти(MGM)иутилитыархивирования
OnArchive, средства администрирования сервера INFORMIX-OnLine DS включают также
следующие компоненты: интерфейс мониторинга системы, утилиты DB/Cockpit и OnPerf,
утилитапараллельнойзагрузки/выгрузкиданных.
2.2.8.1Интерфейсмониторингасистемы
ВовремяинициализациисервераOnLineDSавтоматическисоздаетсябазаданныхSMI
(System Monitoring Interface). Эта база содержит таблицы, которые позволяют получать
следующуюинформациюосостояниисервера:
статус пользователей, ожидающих ресурсов баз данных;профиль выполнения сервера
(счетчики различных вызовов и событий);использование процессоров пользователями и
системой;распределение
дискового
пространства;состояние
журналов
транзакций;состояние дисковых пространств (dbspaces);блокировки;состояние экстентов последовательныхсегментовдисковогопространства,выделенныхподхранениетаблиц.
Во время работы сервера информация в базе данных SMI динамически обновляется.
Она используется административными утилитами, к ней также можно обращаться
посредствомSQL-инструкцииSELECT.
2.2.8.2УтилитаDB/Cockpit
DB/Cockpit - это утилита, которая предоставляет администраторам баз данных
графическийинтерфейсдляслежениязасостояниембазданныхивыполнениянеобходимых
административныхдействий.Основныевозможности:
выдача предупреждений для администратора, если заданные системные параметры
достигли установленных предельных значений;контроль уровней серьезности системных
проблем;монитор активности, который предоставляет сведения об использовании
различных системных ресурсов;запись исторической информации и ее анализ, позволяют
администраторуследитьзаизменениемопределенныхэлементовданных;экраныпрофилей,
которыемогутработатьвтекстовом,схематическомилиграфическомрежимах.
Гибкиесредствадляопределениякритическихзначенийпараметров,придостижении
которых администратор должен получить соответствующее предупреждение, позволяют
предотвратить аномальные состояния сервера и постоянно поддерживать его высокую
работоспособность.
Утилита DB/Cockpit имеет архитектуру клиент/сервер, и позволяет администратору
следить за удаленным сервером. Она состоит из двух основных компонент - зондирующей
(probe) и интерфейсной. Зондирующая компонента работает на том же сервере, где
установлен подлежащий наблюдению сервер INFORMIX-OnLine DS; она выбирает
информацию из базы данных SMI и непосредственно из разделяемой памяти сервера. На
основе этой информации зондирующая компонента инициирует предупреждения для
администратора, записывает заказанную историческую информацию, пересылает данные
для оперативного наблюдения по запросам интерфейсной компоненты. Интерфейсная
компонента работает на любой машине в сети, в том числе, на той, где установлен сервер
баз данных, Она обеспечивает пользовательский интерфейс для слежения за сервером
INFORMIX-OnLine DS, посылает запросы на информацию о состоянии и конфигурации
сервера, анализирует историческую информацию, выдает полученные от зондирующей
компонентыпредупреждения.
УтилитаDB/Cockpitнетребуетбольшихзатратсистемныхресурсов.Существенно,что
зондирующая компонента может работать независимо, и служить "сторожем" для сервера
INFORMIX-OnLineDS.
2.2.8.3УтилитаOnPerf
OnPerf-утилитасграфическиминтерфейсом,котораяявляетсяразвитиемимевшейсяв
предыдущихверсияхINFORMIX-OnLineутилитыtbstat.Основныеновыевозможности:
графический показ метрических значений в реальном времени;выбор метрик, за
которыми нужно наблюдать;просмотр ранее собранной информации, чтобы проследить за
тенденциямиизмененияметрики;сохранениеданныхвфайле,последующийпоказданныхв
имитируемомреальномвремени.
При запуске OnPerf формируются два процесса - процесс OnPerf и процесс сбора
данных.ПроцесссбораданныхподключаетсякразделяемойпамятиINFORMIX-OnLineDSи
считывает из нее метрики выполнения сервера. Собранные данные передаются процессу
OnPerf,которыйобеспечиваетихвыводвграфическойформе.
OnPerfпозволяетадминистраторузадатьрядметрик,которыенеобходимобуферизовать.
Процесс сбора данных записывает такие метрики в буферы сбора данных, откуда
администратор периодически сбрасывает информацию в файлы. Содержимое этих файлов
можнозатемпросматриватьприпомощиутилитыOnPerf.
Выделяется несколько уровней метрик, доступных для слежения, - база данных,
операционнаясистема,центральныйпроцессор,виртуальныйпроцессор,пользовательский
сеанс,дисковаяобласть.
2.2.8.4Утилитапараллельнойзагрузки
Утилитапараллельнойзагрузкиспособнапараллельносчитыватьданныеизнескольких
источников,ускоряязасчетэтогопроцедурызагрузкиивыгрузкиданных.Предоставляемый
еюграфическийинтерфейспозволяетадминистраторубазыданных:
указатьтипфайла(ASCII,COBOL,EBCDICидр.),изкоторогопроизводитсязагрузка,и
задать необходимые преобразования (например, из EBCDIC в ASCII);задать соответствие
между структурой загружаемого файла и схемой INFORMIX-базы данных;задать
выборочнуюзагрузку;вызватьпросмотрщик(browser)загружаемогофайла.
Утилита работает в одном из двух возможных режимов. В режиме быстрой загрузки,
действия, обычно сопровождающие загрузку - проверка целостности по ссылкам,
журнализация,построениеиндексов-выполняютсянепараллельносзагрузкой,апослеее
завершения,чтоускоряетсампроцессзагрузки.
2.2.9Распределенныевычисления
2.2.9.1Взаимодействиеклиент-сервер
Продукты INFORMIX построены на принципах архитектуры клиент/сервер. Это
означает,чтосерверINFORMIX-OnLineDSвыполняетсянаодномкомпьютере,аклиентские
приложениявыполняютсянадругихкомпьютерах,связанныхссерверомсетью.Приэтомот
клиентскихприложенийсерверупосетипересылаютсятолькоSQL-запросы,аотсерверана
клиентские машины пересылаются результаты выполнения запросов. Преимущества такой
архитектуры заключаются в том, что серверный компьютер, не загруженный выполнением
клиентских приложений, способен эффективно обслужить большее число клиентов.
Пользователи же в этом случае могут выбрать наиболее удобную для себя платформу,
например,персональныйкомпьютерсMSWindows.Вчастномслучаеклиентвыполняется
натойжемашине,чтоисервер.
Сервер INFORMIX-OnLine DS содержит все необходимые средства для организации
взаимодействия локальных или удаленных клиентов с сервером базы данных, поэтому
приобретениедополнительныхпродуктовнетребуется.
Для организации взаимодействия клиентских приложений версий 5.0 или 4.1 с
сервером INFORMIX-OnLine DS 7.1 в комплект поставки включен релейный модуль связи
(Relay Module 7.1). Он может использоваться как для локального, так и для сетевого
взаимодействия. Сетевое взаимодействие клиентских приложений версий меньше 6.0 с
сервером INFORMIX-OnLine DS 7.1 возможно также при посредстве одного из
коммуникационных продуктов INFORMIX-NET 5.0 или INFORMIX-STAR 5.0, который
долженбытьустановленнаклиентскоймашине,втомчисле,наPC.
Поддерживаются сетевые протоколы TCP/IP и SPX/IPX. Протокол TCP/IP реализуется
посредством интерфейса сокетов UNIX или TLI, протокол SPX/IPX - посредством
интерфейса TLI. Обработкой сетевого взаимодействия клиентов и серверов в INFORMIXOnLine DS занимаются сетевые виртуальные процессоры. В конфигурацию сервера, в
зависимости от интенсивности сетевого взаимодействия, включается необходимое число
сетевых виртуальных процессоров. Обработка сетевого взаимодействия равномерно
распределяетсямеждусетевымивиртуальнымипроцессорами.
Конфигурация разделяемой памяти включает коммуникационную область, через
которуюлокальныеклиентымогутвзаимодействоватьссервером.Этотвидвзаимодействия
наиболее быстрый, и, кроме того, позволяет разгрузить сеть. Связь через разделяемую
памятьосуществляетсясовместноссетевымиподключениямидляудаленныхклиентов.
2.2.9.2Прозрачностьрасположенияданных
Если в сети имеется несколько серверов баз данных, то, в целях повышения
эффективности доступа к данным или из других соображений, администраторы могут
перемещать или дублировать базы данных или таблицы с одного сервера на другой.
Механизм синонимов, поддерживаемый INFORMIX-OnLine DS, позволяет экранировать от
прикладныхпрограммизмененияместоположенияданных.
2.2.9.3Распределенныебазыданныхипротоколдвухфазовой
фиксациитранзакций
INFORMIX-OnLine DS поддерживает запросы к распределенным базам данных и
автоматически применяет протокол двухфазовой фиксации для транзакций, которые
модифицируютданныеболеечемнаодномсерверебазданных,например:
CONNECTTOstores@italy
BEGINWORK
UPDATEstores:manufactSETmanu_code='SHM'
WHEREmanu_name='Shimara'
INSERTINTOstores@france:manufact
VALUES('SHM','Shimara',30)
INSERTINTOstores@australia:manufact
VALUES('SHM','Shimara',30)
COMMITWORK
Здесь BEGIN WORK, COMMIT WORK - инструкции, отмечающие начало и конец
транзакции,stores-имябазыданных,italy,france,australia-именасерверов.
Внешнетакаятранзакциявыглядиткактранзакциявлокальнойбазе.Насамомделеона
состоитизрядалокальныхтранзакций,каждаяизкоторыхможетбытьлибозафиксирована,
либо прервана. Распределенная транзакция фиксируется только в том случае, если
зафиксированы все локальные транзакции. Если хотя бы одна из локальных транзакций
былапрервана,тонеобходимопрерватьивсеостальные.
Каждая транзакция, реализуемая согласно протоколу двухфазовой фиксации,
выполняется под управлением одного сервера, называемого координатором. В качестве
координаторавыбираетсятекущийсервер.Впримеревышеэтобудетсерверitaly,поскольку
кнемуотноситсяоператорCONNECT.
Перваяфазаначинаетсястого,чтокоординатор,получивотпользователяинструкцию
COMMITWORK,рассылаетсерверамучастникамсообщенияотом,чтонужноподготовиться
кфиксации.Каждыйучастникрешает,можетлионзафиксироватьсвоючастьтранзакции,и
посылаетсоответствующеесообщениекоординатору.
Вторая фаза начинается, когда координатор, получив сообщения от участников,
принимает решение о фиксации или откате транзакции. Если все участники прислали
положительные ответы, то координатор посылает им сообщения о том, чтобы они
зафиксировали свои локальные транзакции. Если хотя бы один участник прислал
отрицательныйответиливообщенеприслалответа,токоординаторпрерываеттранзакцию
ипосылаетвсемучастникамсообщениеотом,чтотранзакциюнужнооткатить.
Процедуравосстановления
Еслиодинизсервероввышелизстроядозавершенияпротоколадвухфазовойфиксации
транзакции, то необходимо восстановить совокупную согласованность распределенных
данных. Для этой цели в INFORMIX-OnLine DS предусмотрены специальные процедуры
восстановления, которые автоматически выполняют все необходимые действия с учетом
того, в какой ситуации и на каком сервере произошел отказ. Единственное, что должен
сделатьвэтойситуацииадминистратор-этоперезапуститьсервер.
Оптимизациятранзакций
При обработке распределенных транзакций INFORMIX-OnLine DS использует метод
оптимизации, основанный на предположении о прерывании транзакции (presumed abort
optimization). Смысл его заключается в том, что, если в журнале транзакций отсутствует
информация о некоторой глобальной транзакции, то считается, что она прервана. Этот
метод позволяет сократить число операций обмена с диском, а также число сообщений,
пересылаемыхмеждусерверами.
Рассматриваемыйметодоптимизациипозволяетисключитьдвашагаизклассического
протокола двухфазовой фиксации транзакций. Во-первых, координатор не производит
синхронизированной записи на диск о начале транзакции. Синхронизированная запись на
диск-дорогостоящаяоперация,икоординаторпроизводитеетольковдвухслучаях-когда
все участники присылают сообщения "могу зафиксировать", и когда все участники
присылаютсообщения"транзакциязафиксирована".Еслипроисходитотказкоординаторадо
принятия решения о фиксации, и в журнале отсутствует информация о данной глобальной
транзакции, то все участники считают, что она прервана, и откатывают свои части
транзакции.Во-вторых, оптимизациядостигается тем,что участники не должны посылать
координаторуподтвержденияоботкатетранзакции.Координатор,еслионпринялрешение
об откате, рассылает участникам соответствующие сообщения, и сразу же откатывает
глобальнуютранзакцию,изымаяинформациюонейизсвойразделяемойпамяти.
Разрешениетупиковыхситуаций
Тупиковая ситуация возникает, например, когда работают два пользователя, и каждый
блокируетобъектданных,необходимыйдругому.Каждомуизних,длятогочтобызавершить
обработку и разблокировать свой объект, необходимо получить доступ к объекту,
заблокированномудругимпользователем.Еслиобаобъектанаходятсянаодномсервере,то
INFORMIX-OnLineDSсамостоятельнообнаруживаетипредотвращаеттакиеситуации.При
обработке
распределенных
запросов
используется
параметр
конфигурации
DEADLOCK_TIMEOUT - время, в течение которого INFORMIX-OnLine DS ожидает
разблокирования объекта данных. По истечении этого периода одному из пользователей
выдаетсясообщениеобошибке.
2.2.10Поддержканациональныхязыков
Поддержканациональныхязыков(nativelanguagesupport-NLS)вINFORMIXоснована
на спецификации X/Open XPG3. Средства NLS в INFORMIX-OnLine DS поддерживают
однобайтные 8-битные платформы NLS. Это позволяет осуществлять упорядочение
текстовыхданных,печататьивводитьдатыиденежныевеличиныпоформатамиправилам,
принятым в той стране, где используются продукты. Стандарт X/Open для NLS также
обеспечивает миграцию приложений баз данных по странам, где используются разные
языки,ссохранениемисходнойфункциональности.
2.2.11СредствабезопасностиклассаС2
Реализованные в INFORMIX-OnLine DS средства протоколирования обеспечивают
полную подотчетность любых манипуляций с объектами баз данных. Средства
протоколирования полностью соответствуют требованиям класса безопасности С2,
установленнымНациональнымцентромкомпьютернойбезопасностиСША.Имеетсяверсия
INFORMIX-OnLine/Secure,котораяобеспечиваетповышенныйуровеньбезопасности.
Администратор может задавать как общие маски протоколирования, так и
специфическиемаскидляконкретныхпользователей.Маскаопределяет,какиедействиянад
объектами баз данных будут фиксироваться. Интерфейс с процедурой протоколирования
осуществляется обращением к утилите onaudit из командной строки. Анализ
регистрационногожурналапроизводитсяприпомощиутилитыonshowauditилисредствами
SQL.
2.3ДополнительныекомпонентыкомпанииInformixдля
выполненияспецифическихзадач.
2.3.1Informix-EnterpriseGateway7.1
Шлюз INFORMIX-Enterprise Gateway обеспечивает для инструментальных средств и
приложений базданных,выполняемых под управлением операционной системыUNIX или
MicrosoftWindows,доступкинформации,хранящейсявбазахданныхразныхтипов.Доступ
реализуется при помощи комплекта программных продуктов Enterprise Data Access SQL
(EDA/SQL)фирмыInformationBuilders,Inc.
ОсновныевозможностишлюзаINFORMIX-EnterpriseGateway:
Более 60 типов реляционных и нереляционных источников данных на 35 различных
аппаратных платформах. Среди поддерживаемых источников данных - IMS, VSAM, CAIDMS,Adabas,Oracle,Sybase,Ingres.Поддерживаемыеоперационныесистемы-UNIX,MVS,
VM,VMS.Архитектураклиент/сервер.ПрозрачныйдоступпосредствоминтерфейсаSQLили
удаленных вызовов процедур.Поддержка стандартов ANSI-92 SQL и ANSI-89
SQL.Роллируемые курсоры.Импорт данных из разнородных источников в базы данных
INFORMIX.Распределенные соединения таблиц из разнородных баз данных.Средства
безопасности.
В компаниях, которые ранее хранили и обрабатывали информацию на мейнфреймах,
формируются распределенные вычислительные среды, включающие разнородные
аппаратные платформы и операционные системы, как открытые, так и собственные
(proprietary), реляционные и нереляционные СУБД. Наличие такой среды - сложная
проблема для отделов информационных систем, которые должны обеспечить своим
пользователям единообразный доступ ко всей имеющейся на предприятии информации.
Шлюз INFORMIX-Enterprise Gateway предлагает современную промышленную технологию
интеграции,отвечающуюпотребностямкорпоративногодоступакданным.
2.3.2ТехнологияикомпонентыEDA/SQL
Технология EDA/SQL фирмы Information Builders, Inc. позволяет осуществлять доступ
средствами SQL не только к реляционным, но и к нереляционным источникам данных,
такимкакиерархическиебазыданныхифайлысопределеннойструктуройзаписей(recordoriented files), характерные для мейнфреймов. Ко всем данным, независимо от формата,
обеспечивается унифицированный реляционный интерфейс. Технология EDA/SQL
позволяеттакжепроизводитьсоединенияданныхизразнородныхисточников.
Технология EDA/SQL основана на архитектуре клиент/сервер. Она включает четыре
ключевых компоненты, необходимые для полного функционирования шлюза Enterprise
Gateway.
2.3.2.1EDAAPI/SQL
ПродуктвстроенвEnterpriseGateway.
EDAAPI/SQL-библиотекаклиентскойчасти,котораяобеспечиваетинтерфейсуровня
вызовов, определенный фирмой Information Builders, Inc. Посредством этого интерфейса
приложениеклиентавыполняетинструкцииSQLилиудаленныевызовыпроцедур.
2.3.2.2EDA/Link
ПродуктвстроенвEnterpriseGateway.
EDA/Link - интерфейс обмена запросами между клиентами и серверами EDA.
Интерфейсы EDA/Link поддерживают коммуникационные протоколы, формируют пакеты
запросов и ответов, производят аутентификацию пользователей по паролям, преобразуют
данныеивыявляютошибкипередачи.
2.3.2.3EDA/SQLServer
Независимыйпродукт,доступныйотфирмыInformationBuilders,Inc.
EDA/SQLServer-многопотоковыйсервербазданных,которыйуправляетвыделениеми
соединением данных из реляционных и нереляционных источников. EDA/SQL Server
управляет процессами на хостмашинах. Он управляет входным потоком запросов данных,
инициализирует подпроцессы для интерпретации и трансляции запросов, вызывает и
маршрутизирует хранимые процедуры, используя удаленные вызовы процедур,
маршрутизируетвыводиосуществляетбюджетныефункцииифункциибезопасностимежду
сетевымисерверами.
EnterpriseGatewayподдерживаетEDA/SQLServerверсии2.2ивыше.
2.3.2.4EDA/DataDrivers
Независимыепродукты,доступныеотфирмыInformationBuilders,Inc.
Драйверы EDA/Data Drivers отображают запросы SQL или RPC, сгенерированные
приложением клиента, на тот язык, который используется на целевом источнике данных.
Например, для SQL-запроса к базе данных IMS драйвер данных IMS сформирует
последовательностьвызововнаязыкеDL/L,иотошлетклиентуполученныйответ.
2.3.3ВозможностиEnterpriseGateway
Enterprise Gateway является процессом сервера баз данных INFORMIX, который
конвертируетзапросыклиентовINFORMIXвзапросыEDA/SQL.
Когда от клиентского приложения поступает инструкция SQL или удаленный вызов
процедуры, предназначенный для Enterprise Gateway, то он просто перенаправляется на
EDA/SQL Server, который затем обращается к соответствующим реляционным или
нереляционным источникам данных. Ответы и данные, полученные от EDA/SQL Server,
EnterpriseGatewayвозвращаетприложениюклиента.
2.3.3.1Прозрачныйдоступдлячтенияизаписи
Enterprise Gateway представляет собой единый шлюз, который обеспечивает
прозрачный доступ к данным в масштабах предприятия. Конечные пользователи
обращаются к Enterprise Gateway так же, как к серверу баз данных INFORMIX. Доступ на
чтениеизаписьосуществляетсяпосредствомстандартныхинструкцийSQLилиудаленных
вызовпроцедур(RPC-RemoteProcedureCall).
Для SQL поддерживаются оба стандарта синтаксиса - ANSI-92 SQL и ANSI-89 SQL;
текущаяверсияEDA/SQLподдерживаетсинтаксисANSI-89SQL.
ДоступпосредствомRPCобеспечиваетсядляинструментовразработкииприложений
INFORMIX, а также третьих фирм. Удаленные вызовы процедур EDA/SQL выглядят как
обращениякхранимымпроцедурам,поэтомудляихиспользованиявприложениятребуется
внестилишьминимальныеизменения.RPCпозволяютвыполнятьоперациичтенияизаписи
ивозвращатьмногострочныерезультаты.
Для обработки многострочных наборов данных, полученных в результате выполнения
RPC или инструкции SQL, в Enterprise Gateway поддерживается механизм роллируемых
курсоров (scroll cursors), который позволяет осуществлять прямой и обратный просмотр
наборовданных.
2.3.3.2Распределенныесоединения
EnterpriseGatewayможетучаствоватьвраспределенныхсоединениях,координируемых
серверомбазданныхINFORMIX.ЭтопозволяетимпортироватьвбазыданныхINFORMIXи/
илиинтегрироватьснимиданныеизразнородныхвнешнихисточников.
2.3.3.3КонфигурированиеEnterpriseGateway
EnterpriseGatewayпроствконфигурировании.СоединениеклиентасEnterpriseGateway
конфигурируется точно так же, как соединение между клиентской частью приложения
INFORMIX и сервером INFORMIX-OnLine DS или INFORMIX-SE. Например, приложение
подMSWindows,созданноеинструментомразработкиINFORMIX-NewEra,конфигурируется
одинаково, независимо от того, обращается ли оно к серверу баз данных INFORMIX или к
EnterpriseGateway.
Enterprise Gateway выполняется под управлением операционной системы UNIX и
должениметьдоступкEDA/SQLServerчерезсетьTCP/IP.СоединениеEnterpriseGatewayи
EDA/SQLServerконфигурируетсяприпомощиобычныхконфигурационныхфайловTCP/IPи
конфигурационногофайлаEDA/Link.
2.3.3.4Безопасность
Enterprise Gateway поддерживает централизованное управление пользовательскими
идентификаторами (ID) и паролями, отображая их из среды INFORMIX в среду EDA/SQL.
EDA/SQL Server обеспечивает безопасность путем взаимодействия с подсистемами
безопасности соответствующих ОС. Например, в MVS осуществляется взаимодействие с
подсистемамибезопасностиRACF,ACF2иCA-TopSecret.
2.3.4БиблиотекисопряжениясервераInformix-OnLineDSс
менеджерамитранзакций:Informix-TP/XAиInformixTP/TOOLKIT
В состав инструментального продукта INFORMIX-ESQL/C входит библиотека Cпрограмм INFORMIX-TP/XA. Эта библиотека обеспечивает для приложений, построенных
припомощиINFORMIX-ESQL/C,сопряжениесервераINFORMIX-OnLineDSсменеджерами
транзакций, основанными на стандарте X/Open-XA, например, TUXEDO System/T.
Аналогичную возможность обеспечивает библиотека 4GL-функций INFORMIX-TP/Toolkit
для приложений на основе INFORMIX-4GL. Такое сопряжение позволяет организовать
участие сервера INFORMIX в разнородных распределенных транзакциях с серверами баз
данныхдругихпоставщиков,поддерживающихстандартX/Open-XA,ииспользоватьпрочие
преимущества,которыепредоставляютсовременныеменеджерытранзакций:
Управление работой нескольких разнородных серверов от разных поставщиков.
Менеджер транзакций выступает как координатор распределенных транзакций между
подключенными к нему серверами, обеспечивая для их реализации протокол двухфазовой
фиксации транзакций и механизмы восстановления.Перераспределение и баланс загрузки,
максимально эффективное использование системных ресурсов.Масштабируемость и
динамическое переконфигурирование прикладной среды с учетом изменяющихся
потребностей.Обеспечение высокой доступности путем перенаправления запросов к
дублирующимсерверамвслучаеотказа.
2.4Заключение
Если рассматривать создание и развитие информационной системы (ИС) как
исторический процесс, то оценка СУБД как базиса для создания или развития ИС может
проводитьсяпотремнаправлениям:
Каковыперспективыееиспользованиявбудущем?ДопускаетлиСУБДвзаимодействие
с унаследованными базами данных и компьютерными платформами?Каковы
потребительскиекачествасуществующейверсииСУБД?
Взаимодействие с унаследованными базами данных обеспечивает шлюз INFORMIXEnterpriseGateway.
Продукты последней версии INFORMIX обладают высокими потребительскими
качествами.Перечислимосновныеизних.
Высокаяпроизводительность
Ее увеличению способствуют следующие свойства и оптимизирующие механизмы
сервераINFORMIX-OnLineDS:
Многопотоковая архитектураПараллельная обработкаФрагментация таблиц и
индексовОптимизация выполнения запросовРазделяемая памятьКеши словарей данных и
хранимых процедурСобственное управление дисковой памятьюАсинхронный вводвыводОпережающеечтение
Высокая производительность на приложениях OLTP, DSS, пакетных заданиях и их
сочетаниях подтверждается тестами TPC (Transaction processing Performamce Council),
особеннонамногопроцессорныхплатформах.
Масштабируемость
Этим термином обозначается такое свойство сервера, которое обеспечивает при
увеличении доступных вычислительных ресурсов (количества или быстродействия
процессоров, числа дисков) соответствующее улучшение системных характеристик. Под
улучшением системных характеристик понимается, например, рост числа обслуживаемых
пользователей с сохранением среднего времени отклика; ускорение обработки одного
запроса; сохранение того же времени обработки запроса при увеличении объема
участвующихвнемтаблиц.
Перечислимсвойстваимеханизмысервера,обеспечивающиемасштабируемость:
Многопотоковая архитектура с поддержкой многопроцессорной обработки.
Обслуживание клиентов равномерно распределяется между всеми наличными
процессорами.ТехнологияPDQ.Выполнениесложногозапросараспределяетсямеждувсеми
наличными процессорами. Результаты тестов показывают линейное ускорение обработки
при увеличении числа процессоров.Фрагментация таблиц. Обработка больших таблиц
ускоряется пропорционально числу фрагментов, располагаемых на разных дисковых
устройствах.Гибкие средства наблюдения и настройки. Допускается динамическое
изменение объема и конфигурации ресурсов, используемых сервером - числа виртуальных
процессоров, дисковых пространств баз данных. В соответствии с наличием ресурсов и
потребностями можно оперативно регулировать интенсивность параллельной обработки,
изменять правила фрагментации таблиц. Поддержка распределенных транзакций.
ПроизводительностьИСможетнаращиватьсяпутемраспределенияданныхиихобработки
междунесколькимисерверами,связаннымисетью.
Универсальностьсервера
Возможность смешанной загрузки его приложениями OLTP, DSS и пакетными
заданиями, обеспечивается средствами параллельной обработки сложных запросов и
средствами оперативной настройки, которые позволяют управлять балансом системных
ресурсовмеждуразнымитипамиприложений.
Практическая осуществимость смешанной загрузки поддерживается также всеми
механизмами, направленными на эффективное разделение ресурсов и повышение
производительности, поскольку без этого невозможно проводить обработку трудоемких
запросов,сохраняяприемлемоевремяоткликадляприложенийOLTP.
Высокаядоступностьданных
Данные становятся недоступны пользователям, если произошел программный или
аппаратный сбой, а также если сервер остановлен с целью выполнения определенных
административных действий. Сервер INFORMIX-OnLine DS обладает рядом возможностей,
которые позволяют повысить надежность ИС и практически отказаться от плановых
простоев:
Зеркалирование дисковых областейПолное тиражирование данных сервераРазвитые
средства сохранения данныхВосстановление некритичных для работы сервера данных в
оперативном режимеИнструменты слежения за состоянием сервераВыполнение
большинства административных задач, в том числе, настройки, в оперативном
режимеФрагментациятаблиц(приотказеодногодискасохраняетсячастичнаядоступность
таблицы)
Функциональныевозможностисервера
Соответствуют входному уровню стандарта ANSI-92 SQL и включают, помимо
рассмотренныхвыше,следующиесредства:
Хранимые процедурыТриггерыКурсорыКаскадные удаления данныхПоддержка
целостности, в том числе, целостности по ссылкамУровни изоляции чтения:грязное
чтениеподтвержденное чтениестабильное чтениеповторяемое чтениеПоддержка больших
бинарныхобъектов(BLOB)Поддержкаоптическихдисков
Средствабезопасности
ВсервереINFORMIX-OnLineDSэтисредствасоответствуютстандартуклассаC2.
Открытость
Это сложное понятие, включающее оценки по многим направлениям. Степень
открытости определяет степень интегрируемости СУБД и продуктов, созданных на ее
основе,вразнообразныхаппаратных,программных,административных,национальныхидр.
средах,чточрезвычайноважнокакдляпостроенияИСвнастоящем,такидляееразвитияв
будущем.Перечислимнекоторыесвойства,характеризующиеоткрытостьINFORMIX:
доступность на множестве платформ, включая Sequent, HP, Sun, IBM, Siemens Nixdorf,
NCR;поддержка, помимо UNIX, операционных систем Windows NT и
NetWare;переносимость прикладных систем между платформами;возможность включения
баз данных INFORMIX в распределенные разнородные ИС, построенные на основе
аппаратно-программных платформ и СУБД разных производителей;интегрируемость
INFORMIX с системами централизованного управления и администрирования, такими как
TivoliManagementEnvironment(TME),HPOpenView,IBMNetView;поддержканациональных
языков.
Средстваразработки
Средства разработки и средства доступа для конечного пользователя, в особенности,
объектно-ориентированный инструмент групповой разработки прикладных систем с
графическим интерфейсом INFORMIX-NewEra, оцениваются экспертами как
высокоразвитые инструменты, отвечающие современным требованиям. Помимо этого
INFORMIX поддерживается многими инструментальными системами независимых
производителей.
С точки зрения развития информационной системы в будущем важны такие
характеристики, как перспективность СУБД по применяемым методам и планируемые
направления развития, поскольку от этого зависят возможности развития ИС.
Архитектурныеитехнологическиерешениясервераотвечаютсовременнымпредставлениям
вэтойобластиипостоянносовершенствуются.Вближайшихверсияхпланируется:
Развитие архитектуры сервера для обеспечения поддержки платформ MPP, а также
слабосвязанных систем.Реализация дискретного тиражирования на уровне отдельных
таблиц и других подмножеств данных.Создание интегрированных средств удаленного
управления и администрирования совокупности серверов INFORMIX-OnLine DS на основе
графического интерфейса, обладающих более изощренными возможностями наблюдения,
обработки событий, планирования, управления базами данных и приложениями.
Интеграция существующих административных утилит с инструментами системного и
сетевогоуправлениядругихпроизводителей,основанныхнапромышленныхифактических
стандартах.
Существенное соображение при выборе продукта - стабильность, подтверждаемая
общимстажеми"запасомлидерства"компании,т.е.общейдолейрынка.ДоляINFORMIX
намировомрынкеСУБД-примерно20%,впоследниегодыимееттенденциюкросту.
ВсеэтопозволяетрассматриватьINFORMIXкакперспективнуюСУБД,котораяможет
служитьосновойдляпостроенияразвитыхИС.
2.5Литература
1.Г.Г.Барон.Параллельныеархитектурысерверовбазданных.JetInfo,Вып.1,1995.
2. INFORMIX-OnLine Dynamic Server. Administrator's Guide, Vol. 1,2. Version 7.1. 1994,
INFORMIXSoftWareInc.
3. INFORMIX-OnLine Dynamic Server 6.0, 7.1. Training Course, 1993, 1994, INFORMIX
SoftWareInc.
4. INFORMIX-OnLine Enterprise Gateway Version 7.1. Technical Brief. 1994, INFORMIX
SoftWareInc.