Logo Host-telecom.com — профессиональный хостинг в Европе! Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Ваш сайт в 8 раз быстрее конкурентов. Хостинг от $2.95

VPS: SSD, KVM, бесплатные бэкапы и администрирование

Все необходимое для вашего сайта и лучшая техподдержка 24/7

хостинг сайтов ГиперХост — хостинг сайтов который Вы искали.

Виртуальный хостинг, Аренда VPS серверов, рация доменных имен, SSL сертификаты

💰 Самые низкие цены на домены

🔒 Отличный хостинг на SSD c бесплатными SSL

💻 Огромнейший выбор dedicated выделенных серверов

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

2.2 Архитектура СУБД сервера Informix OnLine v.7.X

К СУБД, претендующим на роль информационной основы современных предприятий, предъявляются все новые и более жесткие требования. К числу важнейших можно отнести следующие:

  • высокая производительность
  • масштабируемость
  • смешанная загрузка сервера разными типами задач
  • непрерывная доступность данных

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

2.2.1 . Динамическая масштабируемая архитектура

Архитектура сервера INFORMIX-OnLine DS получила название "динамическая масштабируемая архитектура" (DSA). Суть ее заключается в том, что одновременно выполняется относительно небольшое число серверных процессов (виртуальных процессоров), которые разделяют между собой работу по обслуживанию множества клиентов. По сравнению с более ранними моделями сервера INFORMIX, где для каждого клиента создавался индивидуальный серверный процесс (рис. 1), новая модель обладает рядом преимуществ:

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

Для многопроцессорных платформ:

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

Пока пользователь анализирует результаты или готовит очередной запрос, серверный процесс простаивает, занимая системные ресурсы.

Архитектура DSA полностью использует возможности симметричных многопроцессорных платформ SMP (Symmetric Multiprocessing systems), и может работать на однопроцессорных платформах. В последующих версиях предполагается расширить архитектуру сервера, обеспечив поддержку слабосвязанных систем и систем с массовым параллелизмом (MPP). Все базовые технологии DSA являются встроенными, они включены в библиотеки сервера, и их применение не зависит от особенностей ОС или аппаратных платформ различных поставщиков.

2.2.1.1 Потоки

Архитектуру INFORMIX-OnLine DS называют также многопотоковой. Для каждого клиента создается так называемый поток, или нить (thread). Поток - это подзадача, выполняемая в рамках одного из серверных процессов.

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

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

2.2.1.2 Виртуальные процессоры

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

Виртуальные процессоры (ВП) являются специализированными - они подразделяются на классы в соответствии с типом потоков, для выполнения которых они предназначены. Примеры классов ВП:

CPU - Потоки обслуживания клиентов, реализуют оптимизацию и логику выполнения запросов. К этому классу относятся и некоторые системные потоки.

AIO - Операции асинхронного обмена с диском.

ADM - Административные функции, например, системный таймер.

TLI - Контроль сетевого взаимодействия посредством интерфейса TLI (Transport Layer Interface).

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

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

На некоторых мультипроцессорных платформах, где OnLine DS поддерживает родство процессоров (processor affinity), допускается привязка виртуальных CPU-процессоров к определенным центральным процессорам компьютера. В результате производительность виртуального CPU-процессора повышается, поскольку операционная система реже производит переключение процессов. Привязка позволяет также изолировать работу с базой данных, выделяя для этой цели определенные процессоры, в то время как остальные будут заняты другими задачами.

2.2.1.3 Планирование потоков

Сервер осведомлен о степени значимости различных потоков и в соответствии с этим назначает для них приоритеты. Например, потоки ввода-вывода получают приоритеты следующим образом:

  • ввод-вывод логической журнализации - наивысший приоритет;
  • ввод-вывод физической журнализации - второй по значимости приоритет;
  • прочие операции ввода-вывода- низший приоритет.

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

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

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

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

2.2.1.4 Разделение потоков между виртуальными процессорами.

Для каждого класса поддерживаются три очереди потоков, которые разделяются всеми виртуальными процессорами данного класса:

  • Очередь готовых к выполнению потоков.
  • Очередь спящих потоков. В нее помещается, например, CPU-поток, которому требуется доступ к диску. Предварительно CPU-поток порождает запрос на обмен с диском, для обслуживания которого формируется AIO-поток. Завершив обмен с диском, AIO-поток оповещает об этом виртуальный процессор CPU, который "будит" спящий CPU-поток и перемещает его в очередь готовых потоков.
  • Очередь ждущих потоков. Эта очередь служит для координации доступа потоков к разделяемым ресурсам. В нее помещаются потоки, ожидающие какого-либо события, например, освобождения заблокированного ресурса. Когда поток, заблокировавший этот ресурс, готов освободить его, просматривается очередь ждущих потоков. Если в ней есть поток, ожидающий именно этот ресурс, то он перемещается в очередь готовых.

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

2.2.1.5 Экономия памяти и других ресурсов

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

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

2.2.2 Организация разделяемой памяти

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

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

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

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

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

2.2.3 Организация операций обмена с дисками

Операции ввода-вывода, как правило, образуют наиболее медленную компоненту обработки баз данных. Поэтому от их реализации существенно зависит общая продуктивность сервера. Для оптимизации ввода-вывода и повышения надежности в сервере INFORMIX-OnLine DS применяются следующие механизмы:

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

2.2.3.1 Управление дисковой памятью

INFORMIX-OnLine DS поддерживает как собственный механизм управления дисковой памятью, так и управление средствами файловой системы ОС UNIX. Преимущества собственного механизма управления дисковой памятью:

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

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

2.2.3.2 Асинхронный ввод-вывод

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

2.2.3.3 Опережающее чтение

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

2.2.4 Поддержка фрагментации таблиц и индексов

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

  • Сокращается время обработки одного запроса. Встроенный в INFORMIX-OnLine DS механизм PDQ при обработке запросов использует информацию о фрагментации таблиц и создает для сканирования таблицы несколько параллельных потоков. Если стратегия фрагментации выбрана удачно, то ускорение при выборке из таблицы практически линейно зависит от числа фрагментов (рис. 3).
  • Снижается уровень конкуренции при одновременном обращении нескольких запросов к одной таблице. INFORMIX-OnLine DS анализирует правило фрагментации таблицы и во многих случаях способен определить, что данный запрос относится только к одному ее фрагменту. Если фрагменты хранятся на разных дисковых устройствах, то разным запросам будут соответствовать обращения к разным дискам.
  • Повышается готовность (доступность) приложений. Даже если некоторые фрагменты таблицы недоступны из-за того, что соответствующие диски вышли из строя, запросы к ней, тем не менее, во многих случаях могут выполняться.
  • Улучшаются характеристики административных операций, таких как архивирование-восстановление, загрузка-выгрузка данных, поскольку они применимы к отдельным фрагментам таблиц. Если таблица разбита на малые фрагменты, то ее восстановление при выходе из строя одного фрагмента выполняется значительно оперативнее, чем полное восстановление нефрагментированной таблицы. Полные операции архивирования, восстановления, загрузки, выгрузки данных также ускоряются, поскольку операции ввода-вывода для фрагментов таблицы выполняются параллельно.

Различаются два типа правил фрагментации таблиц:

  • Равномерное распределение (round robin) - это встроенный в INFORMIX-OnLine DS механизм фрагментации, который обеспечивает примерно равное число записей в каждом фрагменте.
  • Распределение по выражению (by expression) - для каждого фрагмента задается некоторое выражение, зависящее от значений полей записи; истинность выражения определяет, попадет ли запись в данный фрагмент.

Правило разбиения таблицы задается в SQL-инструкциях CREATE TABLE (создать таблицу), 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 лежат следующие виды оптимизации и регулирования:

  • Параллельный ввод и вывод (на основе горизонтальной фрагментации таблиц).
  • Распараллеливание отдельных итераторов (на основе методов разбиения данных).
  • Распараллеливание плана выполнения запроса (путем разбиения дерева реализации запроса на независимые поддеревья; за счет применения техники потоков данных).
  • Снижение вычислительной сложности алгоритмов (применение основанных на хешировании алгоритмов сортировки, соединения, вычисления агрегатных функций (sum, min, max, avg, ...)).
  • Управление ресурсами, регулирование степени распараллеливания (под PDQ выделяется определенная доля системных ресурсов).

2.2.5.2 Итераторы

Итератор - это программный объект, который осуществляет итеративную (циклическую) обработку некоторого множества данных. Итераторы различаются типом производимой обработки, но имеют единообразный внешний интерфейс. Каждый итератор открывает один (или более) входных потоков данных (data flow), последовательно считывает их и, после обработки, помещает результаты в выходной поток. Итератору безразличен источник входного потока и назначение выходного потока - это может быть диск, другой итератор, сетевое соединение. Мы будем говорить о поставщиках и потребителях потоков данных. Ниже перечислены типы итераторов, применяемые в INFORMIX-OnLine DS:

  • 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). Итератор не заботится о том, какой тип имеют его поставщики, поскольку он взаимодействует с ними только посредством методов. Из описания методов следует, что запуск дерева, составленного из итераторов, реализует их параллельное выполнение. Для каждого итератора создается поток выполнения, который продвигается по мере того, как получает данные от своих поставщиков. Таким образом в сервере реализуется вертикальный параллелизм - одновременное, конвейерное выполнение различных итераторов.

    Другой вид параллелизма - горизонтальный - заключается в том, что вместо одного итератора (например, сканирования) создается несколько однотипных параллельно выполняемых итераторов. Горизонтальный параллелизм реализуется при помощи итераторов специального вида - итераторов обмена (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.

    Назад | Содержание | Вперед

     

  • VDS хостинг Облачный сервер в Нидерландах и Украине

    Аренда виртуального сервера от $7.91

    Партнёрская программа
    $20 за клиента

    Wildcard сертификаты от $74,97 в год.

    Дешевые ssl сертификаты для домена

    Sectigo сертификаты от $7,67 в год.

    хостинг Украина Виртуальный хостинг для сайта от $4,87

    Регистрация домена от $2 в год

    Партнерская программа – $20 за клиента

    VPS с гибкой конфигурацией: за 1€

    Мощные выделенные сервера: от 25€

    Собственный Дата-Центр
    Поддержка 24/7

    Бесплатный конструктор сайтов и Landing Page

    Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

    SSD VPS в Нидерландах под различные задачи от 2.6$

    ATLEX Выделенные серверы: в Европе / в России.

    Виртуальные серверы: в Европе / в России.

    Партнерская программа

    Новости мира IT:

    Архив новостей

    Последние комментарии:

    IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
    тел. +7 495 7861149
    Пресс-релизы — pr@citforum.ru
    Обратная связь
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...