Итератор как программный объект состоит из статических и динамических структур данных. Статическая структура содержит ссылки на функции (или методы), применимые к итератору. Динамическая структура содержит информацию о текущем состоянии итератора (открыт, закрыт, выполняет очередную итерацию), одну или две ссылки на поставщиков.

Методы итератора

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.

Собственно распределением ресурсов и приоритетов в соответствии с установленными значениями занимается специальная компонента сервера OnLine DS - Менеджер выделения памяти (Memory Grant Manager - MGM). Менеджер выделения памяти регулирует объем системных ресурсов, потребляемых PDQ-заданиями, а также:

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

2.2.6 Оптимизатор выполнения запросов по стоимости

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

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

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

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

2.2.7 Средства обеспечения надежности

Сервер INFORMIX-OnLine DS предоставляет следующие средства для восстановления после сбоев и обеспечения отказоустойчивости:

• Зеркалирование дисковых областей
• Полное тиражирование данных сервера
• Быстрое восстановление при включении системы
• Средства архивирования данных

2.2.7.1 . Зеркалирование дисковых областей

Зеркалирование в INFORMIX-OnLine DS - это дублирование связной дисковой области, выделенной под базу данных, на такую же по размеру область. Исходная область называется первичной, а ее копия - зеркальной. Цели, для которых применяется зеркалирование - высокая готовность и оптимизация операций чтения.

Высокая готовность достигается за счет того, что при выходе из строя диска, на котором находится первичная область, сервер автоматически продолжает работу с оставшимся диском без перехода сервера в режим 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). Архивируется одна или несколько дисковых областей. С одной архивной ленты можно восстановить одну или несколько дисковых областей. Поддерживается инкрементальное архивирование (т. е. сохранение только информации, которая изменилась с момента создания последнего полного или инкрементального архива).
• Восстановление данных в оперативном режиме. В случае сбоя носителя, если не затронуты критические для работоспособности INFORMIX-OnLine DS дисковые области, пользователи продолжают взаимодействие с сервером. Доступ к данным, находящимся на вышедшем из строя носителе, возобновляется после завершения процедуры восстановления.
• Составление и просмотр расписания операций архивирования и резервирования. Операции производятся автоматически, по заданному расписанию.
• Метки на архивных лентах. Наличие меток сводит к минимуму риск таких ошибок администратора, как запись на ленту, на которой находится часть активного в данный момент архива, или восстановление данных с устаревшей архивной ленты.
• Интерактивный интерфейс с оператором, основанный на меню и экранных формах.
• Средства восстановления при катастрофах. В случае катастрофического краха информация каталога архивирования/восстановления, поддерживаемого сервером INFORMIX-OnLine DS, может быть прочитана с заголовка архивной ленты.
• Множественные копии архивов на лентах. Сервер INFORMIX-OnLine DS способен одновременно создавать множественные копии архивов и журналов транзакций на нескольких лентопротяжных устройствах. В случае краха восстановление выполняется с любой из копий.
• Опции шифрования и сжатия архивов и журналов транзакций при записи. За счет сжатия объем необходимой вторичной памяти сокращается на величину от 20 до 50 процентов.
• Контроль циклической избыточностью (CRC). Этот метод позволяет контролировать правильность информации, считываемой с ленты. При вводе данных с архивной ленты контрольная сумма, хранящаяся на ленте, сверяется с вычисляемой контрольной суммой.
• Предоставление определенным пользователям прав на архивирование и восстановление некоторых дисковых областей.

2.2.8 Динамическое администрирование

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

Большинство параметров конфигурации сервера являются динамически настраиваемыми, их можно изменить, не останавливая сервера, при помощи утилиты ON-Monitor. Помимо рассмотренных выше менеджера памяти (MGM) и утилиты архивирования OnArchive, средства администрирования сервера INFORMIX-OnLine DS включают также следующие компоненты: интерфейс мониторинга системы, утилиты DB/Cockpit и OnPerf, утилита параллельной загрузки/выгрузки данных.

2.2.8.1 Интерфейс мониторинга системы

Во время инициализации сервера OnLine DS автоматически создается база данных 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-OnLine DS.

2.2.8.3 Утилита OnPerf

OnPerf - утилита с графическим интерфейсом, которая является развитием имевшейся в предыдущих версиях INFORMIX-OnLine утилиты tbstat. Основные новые возможности:

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

При запуске OnPerf формируются два процесса - процесс OnPerf и процесс сбора данных. Процесс сбора данных подключается к разделяемой памяти INFORMIX-OnLine DS и считывает из нее метрики выполнения сервера. Собранные данные передаются процессу OnPerf, который обеспечивает их вывод в графической форме.

OnPerf позволяет администратору задать ряд метрик, которые необходимо буферизовать. Процесс сбора данных записывает такие метрики в буферы сбора данных, откуда администратор периодически сбрасывает информацию в файлы. Содержимое этих файлов можно затем просматривать при помощи утилиты OnPerf.

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

2.2.8.4 Утилита параллельной загрузки

Утилита параллельной загрузки способна параллельно считывать данные из нескольких источников, ускоряя за счет этого процедуры загрузки и выгрузки данных. Предоставляемый ею графический интерфейс позволяет администратору базы данных:

• указать тип файла (ASCII, COBOL, EBCDIC и др.), из которого производится загрузка, и задать необходимые преобразования (например, из EBCDIC в ASCII);
• задать соответствие между структурой загружаемого файла и схемой INFORMIX-базы данных;
• задать выборочную загрузку;
• вызвать просмотрщик (browser) загружаемого файла.

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

2.2.9 Распределенные вычисления

2.2.9.1 Взаимодействие клиент-сервер

Продукты INFORMIX построены на принципах архитектуры клиент/сервер. Это означает, что сервер INFORMIX-OnLine DS выполняется на одном компьютере, а клиентские приложения выполняются на других компьютерах, связанных с сервером сетью. При этом от клиентских приложений серверу по сети пересылаются только SQL-запросы, а от сервера на клиентские машины пересылаются результаты выполнения запросов. Преимущества такой архитектуры заключаются в том, что серверный компьютер, не загруженный выполнением клиентских приложений, способен эффективно обслужить большее число клиентов. Пользователи же в этом случае могут выбрать наиболее удобную для себя платформу, например, персональный компьютер с MS Windows. В частном случае клиент выполняется на той же машине, что и сервер.

Сервер 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. Обработкой сетевого взаимодействия клиентов и серверов в INFORMIX-OnLine DS занимаются сетевые виртуальные процессоры. В конфигурацию сервера, в зависимости от интенсивности сетевого взаимодействия, включается необходимое число сетевых виртуальных процессоров. Обработка сетевого взаимодействия равномерно распределяется между сетевыми виртуальными процессорами.

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

2.2.9.2 Прозрачность расположения данных

Если в сети имеется несколько серверов баз данных, то, в целях повышения эффективности доступа к данным или из других соображений, администраторы могут перемещать или дублировать базы данных или таблицы с одного сервера на другой. Механизм синонимов, поддерживаемый INFORMIX-OnLine DS, позволяет экранировать от прикладных программ изменения местоположения данных.

2.2.9.3 Распределенные базы данных и протокол двухфазовой фиксации транзакций

INFORMIX-OnLine DS поддерживает запросы к распределенным базам данных и автоматически применяет протокол двухфазовой фиксации для транзакций, которые модифицируют данные более чем на одном сервере баз данных, например:

     CONNECT TO stores@italy
     BEGIN WORK
     UPDATE stores:manufact SET manu_code = 'SHM'
     WHERE manu_name = 'Shimara'
     INSERT INTO stores@france:manufact
     VALUES ('SHM', 'Shimara', 30)
     INSERT INTO stores@australia:manufact
     VALUES ('SHM', 'Shimara', 30)
     COMMIT WORK

Здесь BEGIN WORK, COMMIT WORK - инструкции, отмечающие начало и конец транзакции, stores - имя базы данных, italy, france, australia - имена серверов.

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

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

Первая фаза начинается с того, что координатор, получив от пользователя инструкцию COMMIT WORK, рассылает серверамучастникам сообщения о том, что нужно подготовиться к фиксации. Каждый участник решает, может ли он зафиксировать свою часть транзакции, и посылает соответствующее сообщение координатору.

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

Процедура восстановления

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

Оптимизация транзакций

При обработке распределенных транзакций INFORMIX-OnLine DS использует метод оптимизации, основанный на предположении о прерывании транзакции (presumed abort optimization). Смысл его заключается в том, что, если в журнале транзакций отсутствует информация о некоторой глобальной транзакции, то считается, что она прервана. Этот метод позволяет сократить число операций обмена с диском, а также число сообщений, пересылаемых между серверами.

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

Разрешение тупиковых ситуаций

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

2.2.10 Поддержка национальных языков

Поддержка национальных языков (native language support - 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.