уальный процессор выбирает из очереди готовых очередной поток с наивысшим приоритетом. Как правило, OnLine DS стремится выполнять поток на одном и том же виртуальном процессоре, поскольку передача его другому процессору требует пересылки некоторого объема данных. Тем не менее, если поток готов к выполнению, он может быть продолжен другим процессором, с целью исключения простоев и обеспечения общего баланса загрузки.
2.2.1.5 Экономия памяти и других ресурсов
Рациональное использование ресурсов операционной системы достигается за счет того, что потоки разделяют ресурсы (память, коммуникационные порты, файлы) виртуального процессора, на котором они выполняются. Виртуальный процессор сам координирует доступ потоков к своим ресурсам. Процессы же, в отличие от потоков, имеют индивидуальные наборы ресурсов, и, если ресурс требуется нескольким процессам, то доступ к нему регулируется операционной системой.
Переключение виртуального процессора с одного потока на другой, в целом, происходит быстрее, чем переключение операционной системы с одного процесса на другой. Операционная система должна прервать один процесс, выполняемый центральным процессором, сохранить его текущее состояние (контекст) и запустить другой процесс, предварительно поместив в ядро его контекст, что требует физической перезаписи фрагментов памяти. Поскольку потоки разделяют виртуальную память и дескрипторы файлов, то переключение виртуального процессора с потока на поток может сводиться к перезаписи небольшого управляющего блока потока, что соответствует выполнению примерно 20 машинных команд. При этом виртуальный процессор как процесс операционной системы продолжает выполняться без прерывания.
2.2.2 Организация разделяемой памяти
Разделяемая память - это механизм операционной системы, на котором основано разделение данных между виртуальными процессорами и потоками сервера. Разделение данных позволяет:
Управление разделяемой памятью реализовано таким образом, что ее фрагментация минимизируется, поэтому производительность сервера при ее использовании не деградирует с течением времени. Изначально выделенные сегменты разделяемой памяти наращиваются по мере надобности автоматически или вручную. При освобождении памяти, занятой сервером, она возвращается операционной системе.
В разделяемой памяти находится информация обо всех выполняемых потоках, поэтому потоки относительно быстро переключаются между виртуальными процессорами. В частности, в разделяемой памяти выделяется область стеков потоков. Стек хранит данные для функций, выполняемых потоком, и другую информацию о состоянии пользовательского сеанса. Размер стека для каждого сеанса устанавливается при помощи переменной окружения.
Важный оптимизирующий механизм сервера - кэши хранимых процедур и словарей данных. Словари данных (system catalog), доступные только на чтение, а также хранимые процедуры, разделяются между всеми пользователями сервера, что позволяет оптимизировать совокупное использование памяти. При загрузке в разделяемую память словарь данных записывается в структуры, обеспечивающие быстрый доступ к информации, а хранимые процедуры преобразуются в выполняемый формат. Все это может существенно ускорить выполнение приложений, обращающихся ко многим таблицам с большим числом столбцов и/или ко многим хранимым процедурам.
2.2.3 Организация операций обмена с дисками
Операции ввода-вывода, как правило, образуют наиболее медленную компоненту обработки баз данных. Поэтому от их реализации существенно зависит общая продуктивность сервера. Для оптимизации ввода-вывода и повышения надежности в сервере INFORMIX-OnLine DS применяются следующие механизмы:
2.2.3.1 Управление дисковой памятью
INFORMIX-OnLine DS поддерживает как собственный механизм управления дисковой памятью, так и управление средствами файловой системы ОС UNIX. Преимущества собственного механизма управления дисковой памятью:
Файловую систему используют в ситуациях, когда нет возможности выделить под базы данных специальные разделы на дисках, или если перечисленные соображения не критичны.
2.2.3.2 Асинхронный ввод-вывод
Для ускорения операций ввода-вывода сервер использует собственный пакет асинхронного ввода-вывода (AIO) или пакет асинхронного ввода-вывода ядра ОС (KAIO), если он доступен. Пользовательские запросы на ввод-вывод обрабатываются асинхронно, поэтому виртуальным процессорам CPU не приходится ждать завершения операции обмена, чтобы продолжить обработку.
2.2.3.3 Опережающее чтение
Сервер OnLine DS может быть сконфигурирован таким образом, чтобы при чтении последовательной таблицы или индексного файла обеспечивалось опережающее чтение нескольких страниц в то время, пока обрабатываются уже прочитанные в разделяемую память данные. Таким образом, сокращается время ожидания обмена с диском, и пользователь быстрее получает результаты запроса.
2.2.4 Поддержка фрагментации таблиц и индексов
INFORMIX-OnLine DS поддерживает горизонтальную локальную фрагментацию таблиц. Это такой способ хранения таблицы, когда совокупность ее строк разбивается на несколько групп согласно некоторому правилу, и эти группы хранятся на разных дисковых разделах. Фрагментация таблиц способствует достижению следующих целей:
Рис.3. Операции чтения-записи фрагментированной таблицы выполняются параллельно, в результате время обработки сокращается пропорционально числу фрагментов.
Различаются два типа правил фрагментации таблиц:
Правило разбиения таблицы задается в SQL-инструкциях
CREATE TABLE (создать таблицу), ALTER TABLE (изменить таблицу). Пример:
CREATE TABLE account ...
FRAGMENT BY EXPRESSION
id_num > 0 AND id_num <= 20 IN dbsp1
id_num >20 AND id_num <= 40 IN dbsp2
REMAINDER IN dbsp3
Здесь dbsp1, dbsp2, dbsp3 - имена областей дискового пространства, выделенного под БД.
INFORMIX-OnLine DS поддерживает также фрагментацию индексов. Различаются два вида фрагментации индексов - зависимая (соответствующая фрагментации таблицы) и независимая. Фрагментированной таблице может соответствовать нефрагментированный индекс. Создание индекса с правилом фрагментации, не совпадающим с правилом фрагментации таблицы, полезно в тех случаях, когда в разных приложениях выборки из таблицы осуществляются на основе разных подмножеств ее атрибутов.
Стратегия фрагментации таблиц и индексов выбирается в зависимости от цели, которая преследуется, от структуры таблицы и характера запросов к ней. Различные стратегии подробно описаны в документации. Например, если основной целью является уменьшение конкуренции при одновременном доступе к таблице, то оптимальной будет фрагментация таблицы по диапазонам значения ключа (или другого столбца, на основе которого производится основной доступ к таблице) и зависимая фрагментация индекса.
INFORMIX-OnLine DS предоставляет средства наблюдения, позволяющие оценить эффективность фрагментации таблиц и индексов по следующим параметрам:
Если наблюдения показывают, что выбранная стратегия не удовлетворяет поставленной цели, то правила фрагментации могут быть изменены динамически, без остановки сервера.
Важно, что фрагментация таблиц и индексов прозрачна для приложений, работающих с базой данных. Изменение правила фрагментации не требует никаких изменений в прикладных системах - оно лишь повышает (или снижает) скорость и экономичность их выполнения.
2.2.5 Параллельная обработка запросов
Параллельная обработка запросов (Parallel Data Query, PDQ) - это технология, которая позволяет распределить обработку одного сложного запроса на несколько процессоров, мобилизовать для его выполнения максимально доступные системные ресурсы, во много раз сокращая время получения результата. Основные типы заданий, на которых проявляется эффект технологии PDQ:
Практически это означает, что отчет или ответ на сложный запрос, от которого зависит принятие ответственного решения, можно получить не завтра (после ночной обработки), а непосредственно во время обычной оперативной дневной работы. Снимаются проблемы, связанные с обработкой и обслуживанием (архивированием, копированием) очень больших таблиц - благодаря фрагментации, параллельной обработке и возможностям выполнения административных действий в оперативном режиме. В результате расширяется класс потенциальных приложений, и, соответственно, круг пользователей, более гибким становится режим работы ИС, причем все это достигается не на узкоспециализированных, а на обычных широко распространенных аппаратных платформах. Таким образом, можно говорить о новом качестве, которое привносит с собой технология PDQ.
Максимальные преимущества эта технология дает на многопроцессорных платформах в условиях применения фрагментации таблиц, где время выполнения запроса сокращается в десятки раз; однако выигрыш в производительности достигается и на однопроцессорных машинах и нефрагментированных таблицах за счет того, что доступ к дискам осуществляется параллельно с другими видами обработки, и за счет максимально полного использования памяти.
2.2.5.1 На чем основана технология PDQ
Реализация запроса состоит из отдельных действий - сканирования, сортировки, группирования и др. Эти действия называются итераторами. Итераторы образуют дерево реализации запроса в том смысле, что результаты выполнения одних итераторов являются исходными данными для других. При обычной обработке итераторы выполняются последовательно. В основе технологии PDQ лежат следующие виды оптимизации и регулирования:
2.2.5.2 Итераторы
Итератор - это программный объект, который осуществляет итеративную (циклическую) обработку некоторого множества данных. Итераторы различаются типом производимой обработки, но имеют единообразный внешний интерфейс (рис. 4). Каждый итератор открывает один (или более) входных потоков данных (data flow), последовательно считывает их и, после обработки, помещает результаты в выходной поток. Итератору безразличен источник входного потока и назначение выходного потока - это может быть диск, другой итератор, сетевое соединение. Мы будем говорить о поставщиках и потребителях потоков данных. Ниже перечислены типы итераторов, применяемые в INFORMIX-OnLine DS:
Рис. 4. Работа итератора не зависит от источников входных данных. Вывод поступает объекту, который вызвал итератор.
SCAN - Сканирует фрагментированные и нефрагментированные таблицы и индексы.
NESTED LOOP JOIN - Реализует стандартную логику соединений методом вложенных циклов (читает строку из одной таблицы, находит все совпадения во второй таблице, читает следующую строку из первой таблицы и т. д.).
MERGE JOIN - Выполняет фазу слияния для соединения методом сортировки и слияния.
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). Итератор не заботится о том, какой тип имеют его поставщики, поскольку он взаимодействует с ними только посредством методов. Из описания методов следует, что запуск дерева, составленного из итераторов, реализует их параллельное выполнение. Для каждого итератора создается поток выполнения, который продвигается по мере того, как получает данные от своих поставщиков. Таким образом в сервере реализуется вертикальный параллелизм - одновременное, конвейерное выполнение различных итераторов.
Рис. 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-заданиями, а также:
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). В случае отказа основного сервера вторичному серверу автоматически или вручную придается статус стандартного, с доступом на чтение и запись (рис. 6, рис. 7). Прозрачное перенаправление клиентов при отказе основного сервера не поддерживается, но оно может быть реализовано в рамках приложений.
Рис. 6. Тиражирование. Основной сервер доступен на чтение и запись, вторичный - только на чтение.
Рис. 7. Когда основной сервер выходит из строя, вторичный переходит в режим стандартного сервера и становится доступен на чтение и запись.
После восстановления основного сервера, в зависимости от значения параметра конфигурации, выбирается один из двух возможных сценариев:
Тиражирование осуществляется путем передачи информации из журнала транзакций (логического журнала) в буфер тиражирования основного сервера, откуда она пересылается в буфер тиражирования вторичного сервера. Такая пересылка может происходить либо в синхронном, либо в асинхронном режиме. Синхронный режим гарантирует полную согласованность баз данных - ни одна транзакция, зафиксированная на основном сервере, не останется незафиксированной на вторичном, даже в случае сбоя основного сервера. Асинхронный режим не обеспечивает абсолютной согласованности, но улучшает рабочие характеристики системы.
Зеркалирование, которое также является прозрачным средством поддержания высокой готовности, обеспечивает только копирование дисковых областей в пределах одной установки сервера INFORMIX-OnLine DS и защищает только от дисковых сбоев. Механизм тиражирования обеспечивает поддержание полной удаленной копии баз данных и защищает от всех видов отказов, включая полный крах одной из установок.
Помимо обеспечения отказоустойчивой работы, тиражирование дает следующие преимущества:
2.2.7.3 Быстрое восстановление при включении системы
При включении сервер всегда проверяет, не произошло ли последнее выключение системы аварийно. В этом случае база данных не разрушена, но множество транзакций, выполнявшихся в момент сбоя, остались в незавершенном, некорректном состоянии. Если сервер выявил такую ситуацию, то он запускает процедуру быстрого восстановления, которая обеспечивает возврат системы в корректное состояние.
2.2.7.4 Архивирование и восстановление данных
INFORMIX-OnLine DS позволяет создавать архивные копии данных, а в дальнейшем фиксировать те изменения, которые произошли на сервере с момента создания архива. Изменения сохраняются в файлах журнала транзакций. Архивные ленты и ленты с копиями журналов транзакций могут записываться параллельно с доступом пользователей к серверу. Процедура восстановления состоит из двух шагов - считывания данных из архивной копии и применения к ним тех изменений, которые были зафиксированы в журналах транзакций.
В состав сервера INFORMIX-OnLine DS входит утилита OnArchive, предоставляющая развитые и гибкие средства архивирования, копирования журналов транзакций и восстановления информации. Ниже перечислены основные возможности этой утилиты:
2.2.8 Динамическое администрирование
В условиях, когда базы данных увеличиваются в размерах, становятся распределенными и служат основой для особо ответственных приложений масштаба предприятия, которые должны работать круглосуточно, возрастает роль развитых динамических средств администрирования. Эти средства должны позволять администраторам оперативно следить за такими характеристиками работы сервера, как использование памяти и виртуальных процессоров, очереди асинхронного ввода-вывода, очереди пакетных заданий и приложений DSS, наличное дисковое пространство, эффективность схем фрагментации и т. п. Если какие-то из характеристик неудовлетворительны, то необходима возможность динамически, не останавливая системы, изменить параметры конфигурации или запустить необходимые административные утилиты.
Большинство параметров конфигурации сервера являются динамически настраиваемыми, их можно изменить, не останавливая сервера, при помощи утилиты ON-Monitor. Помимо рассмотренных в