Виктор Кустов. Informix. Руководство администратора баз данных --------------------------------------------------------------- Email: visor@olma.co.ru ║ mailto:visor@olma.co.ru ---------------------------------------------------------------
1. Теоретические основы. *
1.1 Понятие СУБД сервера. *
1.1.1 Основные функции СУБД *
1.1.2 Типовая организация современной СУБД *
1.2 Понятие архитектуры клиент-сервер. *
2. Теоретические основы СУБД сервера Informix OnLine v.7.X *
2.1 СУБД сервер Informix. *
2.2 Архитектура СУБД сервера Informix OnLine v.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.1 Informix-Enterprise Gateway 7.1 *
2.3.2 Технология и компоненты EDA/SQL *
2.3.2.1 EDA API/SQL *
2.3.2.2 EDA/Link *
2.3.2.3 EDA/SQL Server *
2.3.2.4 EDA/Data Drivers *
2.3.3 Возможности Enterprise Gateway *
2.3.3.1 Прозрачный доступ для чтения и записи *
2.3.3.2 Распределенные соединения *
2.3.3.3 Конфигурирование Enterprise Gateway *
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 Основные функции СУБД
К числу функций СУБД принято относить следующее:
1. Непосредственное управление данными во внешней памяти
Эта функция включает обеспечение необходимых структур внешней памяти как для хранения непосредственных данных, входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, а если использует, то как организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД (это очень важно, поскольку имена объектов базы данных соответствуют именам объектов предметной области).
Существует множество различных способов организации внешней памяти баз данных. Как и все решения, принимаемые при организации баз данных, конкретные методы организации внешней памяти необходимо выбирать в тесной связи со всеми остальными решениями.
2. Управление буферами оперативной памяти
СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно превышает доступный объем оперативной памяти. Понятно, если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Единственным же способом реального увеличения этой скорости является буферизация данных в оперативной памяти. И даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов. При управлении буферами основной памяти приходится разрабатывать и применять согласованные алгоритмы буферизации, журнализации и синхронизации. Заметим, что существует отдельное направление СУБД, которые ориентированы на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в предвидимом будущем объем оперативной памяти компьютеров сможет быть настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.
3. Управление транзакциями
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные ею, во внешней памяти, либо ни одно из этих изменений никак не отражается в состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы отдела кадров с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника будет объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций - обязательное условие даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо существеннее во многопользовательских СУБД. То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый пользователь может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку пользователи многопользовательских СУБД порой могут ощутить присутствие своих коллег).
С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивлентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - это такой способ их совместного выполнения, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы для каждого пользователя по сравнению с однопользовательским режимом).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.
4. Журнализация
Одно из основных требований к СУБД - надежное хранение данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), ижесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть аварийное завершение работы СУБД (из-за ошибки в программе или некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
Но в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежного хранения данных в БД требует избыточности хранения данных, причем та их часть, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенный метод поддержания такой избыточной информации - ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая особо тщательно (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), а порой запись соответствует минимальной внутренней операции модификации страницы внешней памяти. В некоторых системах одновременно используются оба подхода.
Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции выполнением обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после конца восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
5. Языки БД
Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два - язык определения схемы БД (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 имеют сетевые версии, которые просто совместно используют файлы баз данных тех же форматов для ПК, осуществляя при этом сетевые блокировки для разграничения доступа к таблицам и записям. При этом вся работа осуществляется на ПК. Сервер используется просто как общий удаленный диск большой емкости. Такой способ работы приводит к риску потери данных при аппаратных сбоях.
По сравнению с такими системами системы , построенные в архитектуре Клиент - Сервер, имеют следующие преимущества:
2. Теоретические основы СУБД сервера Informix OnLine v.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, Windows NT и 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 или Informix OnLine-Dynamic Server.
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-операторов. Для каждого клиента запускается процесс операционной системы, использующий эту программу. В случае, если клиент прервал работу, но не вышел из своей задачи, то его процесс занимает ресурсы системы, снижая ее производительность.
Одним из последних достижений фирмы стал выпуск нового сервера базы данных OnLine Dynamic Server, которой входит в состав системы начиная с версии 6.0. Этот продукт основан на так называемой Динамической Масштабируемой Архитектуре (Dynamically Scalable Architecture - DSA), которая специально ориентирована на работу с многопроцессорными системами. OnLine Dynamic Server обеспечивает повышение производительности за счет гибкости использования ресурсов СУБД, использование многопоточной архитектуры. Фактически OnLine Dynamic Server берет на себя многие связанные с распределением ресурсов функции операционной системы. В результате уменьшается нагрузка на операционную системы, что в конечном счете приводит к росту производительности.
Для обслуживания клиентов запускаются "виртуальные процессоры" - процессы операционной системы, которые устанавливают связь между клиентом и ядром Informix. Связь устанавливается с помощью специальных "нитей" (thread), которые активизируются только если клиент активен и обращается к серверу базы данных. В случае, если клиент неактивен, "нить" может обслуживать других клиентов.
Число виртуальных процессоров определяет администратор базы данных, исходя из реальных ресурсов вычислительной системы и сети клиентов. Если вычислительная система является многопроцессорной, то разные виртуальные процессоры могут обслуживаться разными реальными процессорами.
В версии 6.0 сетевые функции заложены в ядре СУБД. Поэтому для функционирования в сети OnLine Dynamic Server модули Informix-Net или Informix-Star не требуются.
2.2 Архитектура СУБД сервера Informix OnLine v.7.X
К СУБД, претендующим на роль информационной основы современных предприятий, предъявляются все новые и более жесткие требования. К числу важнейших можно отнести следующие:
Данный раздел посвящен, главным образом, рассмотрению архитектурных особенностей и механизмов сервера INFORMIX-OnLine DS, направленных на удовлетворение перечисленных выше требований. Приводится также информация о средствах распределенных вычислений, безопасности, поддержки национальной среды.
2.2.1 . Динамическая масштабируемая архитектура
Архитектура сервера INFORMIX-OnLine DS получила название "динамическая масштабируемая архитектура" (DSA). Суть ее заключается в том, что одновременно выполняется относительно небольшое число серверных процессов (виртуальных процессоров), которые разделяют между собой работу по обслуживанию множества клиентов. По сравнению с более ранними моделями сервера INFORMIX, где для каждого клиента создавался индивидуальный серверный процесс (рис. 1), новая модель обладает рядом преимуществ:
Для многопроцессорных платформ:
Рис. 1. Модель "один клиент - один серверный процесс".
Пока пользователь анализирует результаты или готовит очередной запрос, серверный процесс простаивает, занимая системные ресурсы.
Архитектура DSA полностью использует возможности симметричных многопроцессорных платформ SMP (Symmetric Multiprocessing systems), и может работать на однопроцессорных платформах. В последующих версиях предполагается расширить архитектуру сервера, обеспечив поддержку слабосвязанных систем и систем с массовым параллелизмом (MPP). Все базовые технологии DSA являются встроенными, они включены в библиотеки сервера, и их применение не зависит от особенностей ОС или аппаратных платформ различных поставщиков.
2.2.1.1 Потоки
Архитектуру INFORMIX-OnLine DS называют также многопотоковой. Для каждого клиента создается так называемый поток, или нить (thread). Поток - это подзадача, выполняемая в рамках одного из серверных процессов.
В некоторых случаях для обслуживания одного клиентского запроса создается несколько параллельных потоков. Потоки создаются также для выполнения внутренних задач сервера - ввода-вывода, журнализации, администрирования и др. Таким образом, одновременно выполняется множество потоков, которые распределяются между наличными виртуальными процессорами (рис. 2).
Рис.2. Многопотоковая модель. Виртуальные процессоры (ВП) не простаивают, если имеются готовые к выполнению пользовательские или системные потоки.
INFORMIX-OnLine DS не полагается на механизмы потоков, имеющиеся в некоторых операционных системах. Он формирует потоки, специфичные для задач обработки баз данных, оптимальные в отношении выделяемой под них памяти, методов планирования и числа инструкций, затрачиваемых на переключение между потоками.
2.2.1.2 Виртуальные процессоры
Виртуальным процессором называется процесс сервера баз данных. Виртуальный процессор можно сравнить с операционной системой. Поток по отношению к нему выступает как процесс, подобно тому, как сам виртуальный процессор является процессом с точки зрения операционной системы.
Виртуальные процессоры (ВП) являются специализированными - они подразделяются на классы в соответствии с типом потоков, для выполнения которых они предназначены. Примеры классов ВП:
CPU - Потоки обслуживания клиентов, реализуют оптимизацию и логику выполнения запросов. К этому классу относятся и некоторые системные потоки.
AIO - Операции асинхронного обмена с диском.
ADM - Административные функции, например, системный таймер.
TLI - Контроль сетевого взаимодействия посредством интерфейса TLI (Transport Layer Interface).
В отличие от операционной системы, которая должна обеспечивать выполнение произвольных процессов, классы виртуальных процессоров спроектированы для наиболее оптимального выполнения заданий определенного вида.
Начальное число виртуальных процессоров каждого класса, создаваемых при запуске INFORMIX-OnLine DS, задается в конфигурационном файле. Однако, потребности в каждом виде обработки не всегда предсказуемы. Инструменты администрирования позволяют динамически, не останавливая сервер, запустить дополнительные виртуальные процессоры. Например, если растет очередь потоков к виртуальным CPU-процессорам, то можно увеличить их число. Точно так же, возможно добавление виртуальных процессоров обмена с дисками, сетевых процессоров взаимодействия с клиентами, создание процессора обмена с оптическим диском, если он отсутствовал в начальной конфигурации. Динамически сократить можно только число виртуальных процессоров класса CPU.
На некоторых мультипроцессорных платформах, где OnLine DS поддерживает родство процессоров (processor affinity), допускается привязка виртуальных CPU-процессоров к определенным центральным процессорам компьютера. В результате производительность виртуального CPU-процессора повышается, поскольку операционная система реже производит переключение процессов. Привязка позволяет также изолировать работу с базой данных, выделяя для этой цели определенные процессоры, в то время как остальные будут заняты другими задачами.
2.2.1.3 Планирование потоков
Сервер осведомлен о степени значимости различных потоков и в соответствии с этим назначает для них приоритеты. Например, потоки ввода-вывода получают приоритеты следующим образом:
Таким образом, гарантируется, что операции записи в логический журнал, от которых зависит восстановление базы данных в случае сбоя, не окажутся в очереди позади операции вывода во временный рабочий файл.
Сами виртуальные процессоры выполняются как высокоприоритетные процессы операционной системы, которые не прерываются, пока не пусты очереди готовых к выполнению потоков.
Выполнение потока не откладывается по истечении заданного кванта времени, как это происходит с процессами в операционной системе. Поток откладывается в двух случаях:
2.2.1.4 Разделение потоков между виртуальными процессорами.
Для каждого класса поддерживаются три очереди потоков, которые разделяются всеми виртуальными процессорами данного класса:
Если выполняемый поток завершается, засыпает или откладывается, то освободившийся вирт