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


 <dd><B>2.2.1.5  <A NAME="_Toc408113426">ќкономиЯ памЯти и других ресурсов</A></B>


 <dd>ђациональное использование ресурсов операционной системы достигаетсЯ за счет того, что потоки разделЯют ресурсы (памЯть, коммуникационные порты, файлы) виртуального процессора, на котором они выполнЯютсЯ. ‚иртуальный процессор сам координирует доступ потоков к своим ресурсам. Џроцессы же, в отличие от потоков, имеют индивидуальные наборы ресурсов, и, если ресурс требуетсЯ нескольким процессам, то доступ к нему регулируетсЯ операционной системой.

 <dd>Џереключение виртуального процессора с одного потока на другой, в целом, происходит быстрее, чем переключение операционной системы с одного процесса на другой. ЋперационнаЯ система должна прервать один процесс, выполнЯемый центральным процессором, сохранить его текущее состоЯние (контекст) и запустить другой процесс, предварительно поместив в Ядро его контекст, что требует физической перезаписи фрагментов памЯти. Џоскольку потоки разделЯют виртуальную памЯть и дескрипторы файлов, то переключение виртуального процессора с потока на поток может сводитьсЯ к перезаписи небольшого управлЯющего блока потока, что соответствует выполнению примерно 20 машинных команд. Џри этом виртуальный процессор как процесс операционной системы продолжает выполнЯтьсЯ без прерываниЯ.


 <dd>2.2.2  <A NAME="_Toc408113427">ЋрганизациЯ разделЯемой памЯти</A>


 <dd>ђазделЯемаЯ памЯть - это механизм операционной системы, на котором основано разделение данных между виртуальными процессорами и потоками сервера. ђазделение данных позволЯет:


<UL>

<UL>

 <dd><LI>‘низить общее потребление памЯти, поскольку участвующим в разделении процессам, т. е. виртуальным процессорам, нет нужды поддерживать свои копии информации, находЯщейсЯ в разделЯемой памЯти.</LI>

 <dd><LI>‘ократить число обменов с дисками, потому что буферы ввода-вывода сбрасываютсЯ на диск не длЯ каждого процесса в отдельности, а образуют один общий длЯ всего сервера баз данных пул. ‚иртуальный процессор зачастую избегает выполнениЯ или обращениЯ за результатами операций ввода с диска, поскольку нужнаЯ таблица уже прочитана другим процессором.</LI>

 <dd><LI>Ћрганизовать быстрое взаимодействие между процессами. —ерез разделЯемую памЯть, в частности, обмениваютсЯ данными потоки, участвующие в параллельной обработке сложного запроса. ђазделЯемаЯ памЯть используетсЯ также длЯ организации взаимодействиЯ между локальным клиентом и сервером. </LI></UL>
</UL>


 <dd>“правление разделЯемой памЯтью реализовано таким образом, что ее фрагментациЯ минимизируетсЯ, поэтому производительность сервера при ее использовании не деградирует с течением времени. €значально выделенные сегменты разделЯемой памЯти наращиваютсЯ по мере надобности автоматически или вручную. Џри освобождении памЯти, занЯтой сервером, она возвращаетсЯ операционной системе.

 <dd>‚ разделЯемой памЯти находитсЯ информациЯ обо всех выполнЯемых потоках, поэтому потоки относительно быстро переключаютсЯ между виртуальными процессорами. ‚ частности, в разделЯемой памЯти выделЯетсЯ область стеков потоков. ‘тек хранит данные длЯ функций, выполнЯемых потоком, и другую информацию о состоЯнии пользовательского сеанса. ђазмер стека длЯ каждого сеанса устанавливаетсЯ при помощи переменной окружениЯ.

 <dd>‚ажный оптимизирующий механизм сервера - кэши хранимых процедур и словарей данных. ‘ловари данных (system catalog), доступные только на чтение, а также хранимые процедуры, разделЯютсЯ между всеми пользователЯми сервера, что позволЯет оптимизировать совокупное использование памЯти. Џри загрузке в разделЯемую памЯть словарь данных записываетсЯ в структуры, обеспечивающие быстрый доступ к информации, а хранимые процедуры преобразуютсЯ в выполнЯемый формат. ‚се это может существенно ускорить выполнение приложений, обращающихсЯ ко многим таблицам с большим числом столбцов и/или ко многим хранимым процедурам.


 <dd>2.2.3  <A NAME="_Toc408113428">ЋрганизациЯ операций обмена с дисками</A>


 <dd>Ћперации ввода-вывода, как правило, образуют наиболее медленную компоненту обработки баз данных. Џоэтому от их реализации существенно зависит общаЯ продуктивность сервера. „лЯ оптимизации ввода-вывода и повышениЯ надежности в сервере INFORMIX-OnLine DS применЯютсЯ следующие механизмы:


<UL>

<UL>

 <dd><LI>собственное управление дисковой памЯтью; </LI>

 <dd><LI>асинхронный ввод-вывод;</LI>

 <dd><LI>опережающее чтение. </LI></UL>
</UL>


 <dd><B><A NAME="_Toc408113429">2.2.3.1 “правление дисковой памЯтью</A></B>


 <dd>INFORMIX-OnLine DS поддерживает как собственный механизм управлениЯ дисковой памЯтью, так и управление средствами файловой системы Ћ‘ UNIX. Џреимущества собственного механизма управлениЯ дисковой памЯтью:


<UL>

<UL>

 <dd><LI>‘нЯтие ограничений операционной системы на число одновременно читаемых таблиц. </LI>

 <dd><LI>ЋптимизациЯ размещениЯ таблиц - длЯ таблиц выделЯютсЯ большие области последовательных физических блоков, в результате ускорЯетсЯ доступ к ним.</LI>

 <dd><LI>‘нижение накладных расходов при чтении - данные с дисков считываютсЯ непосредственно в разделЯемую памЯть, минуЯ буферы Ћ‘. </LI>

 <dd><LI>Џовышение надежности. Џри использовании файловой системы INFORMIX-OnLine DS не может гарантировать, что в случае сбоЯ данные журнала транзакций не пропадут из-за того, что они остались в буферах Ћ‘ и не успели записатьсЯ на диск. Џоэтому процедура быстрого восстановлениЯ, вызываемаЯ при перезапуске системы, не обеспечит в этом случае целостности данных. </LI></UL>
</UL>


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


 <dd><B>2.2.3.2  <A NAME="_Toc408113430">Ђсинхронный ввод-вывод</A></B>


 <dd>„лЯ ускорениЯ операций ввода-вывода сервер использует собственный пакет асинхронного ввода-вывода (AIO) или пакет асинхронного ввода-вывода Ядра Ћ‘ (KAIO), если он доступен. Џользовательские запросы на ввод-вывод обрабатываютсЯ асинхронно, поэтому виртуальным процессорам CPU не приходитсЯ ждать завершениЯ операции обмена, чтобы продолжить обработку.


 <dd><B><A NAME="_Toc408113431">2.2.3.3 Ћпережающее чтение</A></B>


 <dd>‘ервер OnLine DS может быть сконфигурирован таким образом, чтобы при чтении последовательной таблицы или индексного файла обеспечивалось опережающее чтение нескольких страниц в то времЯ, пока обрабатываютсЯ уже прочитанные в разделЯемую памЯть данные. ’аким образом, сокращаетсЯ времЯ ожиданиЯ обмена с диском, и пользователь быстрее получает результаты запроса.


 <dd>2.2.4  <A NAME="_Toc408113432">Џоддержка фрагментации таблиц и индексов</A>


 <dd>INFORMIX-OnLine DS поддерживает горизонтальную локальную фрагментацию таблиц. ќто такой способ хранениЯ таблицы, когда совокупность ее строк разбиваетсЯ на несколько групп согласно некоторому правилу, и эти группы хранЯтсЯ на разных дисковых разделах. ”рагментациЯ таблиц способствует достижению следующих целей:


<UL>

<UL>

 <dd><LI>‘окращаетсЯ времЯ обработки одного запроса. ‚строенный в INFORMIX-OnLine DS механизм PDQ при обработке запросов использует информацию о фрагментации таблиц и создает длЯ сканированиЯ таблицы несколько параллельных потоков. …сли стратегиЯ фрагментации выбрана удачно, то ускорение при выборке из таблицы практически линейно зависит от числа фрагментов (рис. 3). </LI></UL>
</UL>


 <dd><IMG SRC="informix_7.gif" WIDTH=416 HEIGHT=293 ALIGN="LEFT" HSPACE=12>


 <dd>ђис.3. Ћперации чтениЯ-записи фрагментированной таблицы выполнЯютсЯ параллельно, в результате времЯ обработки сокращаетсЯ пропорционально числу фрагментов.


<UL>

<UL>

 <dd><LI>‘нижаетсЯ уровень конкуренции при одновременном обращении нескольких запросов к одной таблице. INFORMIX-OnLine DS анализирует правило фрагментации таблицы и во многих случаЯх способен определить, что данный запрос относитсЯ только к одному ее фрагменту. …сли фрагменты хранЯтсЯ на разных дисковых устройствах, то разным запросам будут соответствовать обращениЯ к разным дискам. </LI>

 <dd><LI>ЏовышаетсЯ готовность (доступность) приложений. „аже если некоторые фрагменты таблицы недоступны из-за того, что соответствующие диски вышли из строЯ, запросы к ней, тем не менее, во многих случаЯх могут выполнЯтьсЯ. </LI>

 <dd><LI>“лучшаютсЯ характеристики административных операций, таких как архивирование-восстановление, загрузка-выгрузка данных, поскольку они применимы к отдельным фрагментам таблиц. …сли таблица разбита на малые фрагменты, то ее восстановление при выходе из строЯ одного фрагмента выполнЯетсЯ значительно оперативнее, чем полное восстановление нефрагментированной таблицы. Џолные операции архивированиЯ, восстановлениЯ, загрузки, выгрузки данных также ускорЯютсЯ, поскольку операции ввода-вывода длЯ фрагментов таблицы выполнЯютсЯ параллельно. </LI></UL>
</UL>


 <dd>ђазличаютсЯ два типа правил фрагментации таблиц:


<UL>

<UL>

 <dd><LI>ђавномерное распределение (round robin) - это встроенный в INFORMIX-OnLine DS механизм фрагментации, который обеспечивает примерно равное число записей в каждом фрагменте. </LI>

 <dd><LI>ђаспределение по выражению (by expression) - длЯ каждого фрагмента задаетсЯ некоторое выражение, зависЯщее от значений полей записи; истинность выражениЯ определЯет, попадет ли запись в данный фрагмент. </LI></UL>
</UL>


 <dd>Џравило разбиениЯ таблицы задаетсЯ в SQL-инструкциЯх


 <dd>CREATE TABLE (создать таблицу), ALTER TABLE (изменить таблицу). Џример:

 <dd>CREATE TABLE account ...

 <dd>FRAGMENT BY EXPRESSION

 <dd>id_num &gt; 0 AND id_num &lt;= 20 IN dbsp1

 <dd>id_num &gt;20 AND id_num &lt;= 40 IN dbsp2

 <dd>REMAINDER IN dbsp3

 <dd>‡десь dbsp1, dbsp2, dbsp3 - имена областей дискового пространства, выделенного под Ѓ„.

 <dd>INFORMIX-OnLine DS поддерживает также фрагментацию индексов. ђазличаютсЯ два вида фрагментации индексов - зависимаЯ (соответствующаЯ фрагментации таблицы) и независимаЯ. ”рагментированной таблице может соответствовать нефрагментированный индекс. ‘оздание индекса с правилом фрагментации, не совпадающим с правилом фрагментации таблицы, полезно в тех случаЯх, когда в разных приложениЯх выборки из таблицы осуществлЯютсЯ на основе разных подмножеств ее атрибутов.

 <dd>‘тратегиЯ фрагментации таблиц и индексов выбираетсЯ в зависимости от цели, котораЯ преследуетсЯ, от структуры таблицы и характера запросов к ней. ђазличные стратегии подробно описаны в документации. Ќапример, если основной целью ЯвлЯетсЯ уменьшение конкуренции при одновременном доступе к таблице, то оптимальной будет фрагментациЯ таблицы по диапазонам значениЯ ключа (или другого столбца, на основе которого производитсЯ основной доступ к таблице) и зависимаЯ фрагментациЯ индекса.

 <dd>INFORMIX-OnLine DS предоставлЯет средства наблюдениЯ, позволЯющие оценить эффективность фрагментации таблиц и индексов по следующим параметрам:


<UL>

<UL>

 <dd><LI>ђаспределение данных по фрагментам; </LI>

 <dd><LI>Ѓаланс запросов на ввод-вывод по фрагментам; </LI>

 <dd><LI>‘татус дисковых областей, содержащих фрагменты. </LI></UL>
</UL>


 <dd>…сли наблюдениЯ показывают, что выбраннаЯ стратегиЯ не удовлетворЯет поставленной цели, то правила фрагментации могут быть изменены динамически, без остановки сервера.

 <dd>‚ажно, что фрагментациЯ таблиц и индексов прозрачна длЯ приложений, работающих с базой данных. €зменение правила фрагментации не требует никаких изменений в прикладных системах - оно лишь повышает (или снижает) скорость и экономичность их выполнениЯ.


 <dd><A NAME="_Toc408113433">2.2.5 ЏараллельнаЯ обработка запросов</A>


 <dd>ЏараллельнаЯ обработка запросов (Parallel Data Query, PDQ) - это технологиЯ, котораЯ позволЯет распределить обработку одного сложного запроса на несколько процессоров, мобилизовать длЯ его выполнениЯ максимально доступные системные ресурсы, во много раз сокращаЯ времЯ получениЯ результата. Ћсновные типы заданий, на которых проЯвлЯетсЯ эффект технологии PDQ:


<UL>

<UL>

 <dd><LI>обработка сложных запросов, включающих сканирование больших таблиц, сортировку, соединениЯ, группирование, массовые вставки; </LI>

 <dd><LI>построение индексов; </LI>

 <dd><LI>сохранение и восстановление данных; </LI>

 <dd><LI>загрузка, выгрузка данных, реорганизациЯ баз данных; </LI>

 <dd><LI>массовые операции вставки, удалениЯ, модификации данных. </LI></UL>
</UL>


 <dd>Џрактически это означает, что отчет или ответ на сложный запрос, от которого зависит принЯтие ответственного решениЯ, можно получить не завтра (после ночной обработки), а непосредственно во времЯ обычной оперативной дневной работы. ‘нимаютсЯ проблемы, свЯзанные с обработкой и обслуживанием (архивированием, копированием) очень больших таблиц - благодарЯ фрагментации, параллельной обработке и возможностЯм выполнениЯ административных действий в оперативном режиме. ‚ результате расширЯетсЯ класс потенциальных приложений, и, соответственно, круг пользователей, более гибким становитсЯ режим работы €‘, причем все это достигаетсЯ не на узкоспециализированных, а на обычных широко распространенных аппаратных платформах. ’аким образом, можно говорить о новом качестве, которое привносит с собой технологиЯ PDQ.

 <dd>Њаксимальные преимущества эта технологиЯ дает на многопроцессорных платформах в условиЯх применениЯ фрагментации таблиц, где времЯ выполнениЯ запроса сокращаетсЯ в десЯтки раз; однако выигрыш в производительности достигаетсЯ и на однопроцессорных машинах и нефрагментированных таблицах за счет того, что доступ к дискам осуществлЯетсЯ параллельно с другими видами обработки, и за счет максимально полного использованиЯ памЯти.


 <dd><B>2.2.5.1  <A NAME="_Toc408113434">Ќа чем основана технологиЯ PDQ</A></B>


 <dd>ђеализациЯ запроса состоит из отдельных действий - сканированиЯ, сортировки, группированиЯ и др. ќти действиЯ называютсЯ итераторами. €тераторы образуют дерево реализации запроса в том смысле, что результаты выполнениЯ одних итераторов ЯвлЯютсЯ исходными данными длЯ других. Џри обычной обработке итераторы выполнЯютсЯ последовательно. ‚ основе технологии PDQ лежат следующие виды оптимизации и регулированиЯ:


<UL>

<UL>

 <dd><LI>Џараллельный ввод и вывод (на основе горизонтальной фрагментации таблиц). </LI>

 <dd><LI>ђаспараллеливание отдельных итераторов (на основе методов разбиениЯ данных). </LI>

 <dd><LI>ђаспараллеливание плана выполнениЯ запроса (путем разбиениЯ дерева реализации запроса на независимые поддеревьЯ; за счет применениЯ техники потоков данных). </LI>

 <dd><LI>‘нижение вычислительной сложности алгоритмов (применение основанных на хешировании алгоритмов сортировки, соединениЯ, вычислениЯ агрегатных функций (sum, min, max, avg, ...)). </LI>

 <dd><LI>“правление ресурсами, регулирование степени распараллеливаниЯ (под PDQ выделЯетсЯ определеннаЯ долЯ системных ресурсов). </LI></UL>
</UL>


 <dd><B>2.2.5.2  <A NAME="_Toc408113435">€тераторы</A></B>


 <dd>€тератор - это программный объект, который осуществлЯет итеративную (циклическую) обработку некоторого множества данных. €тераторы различаютсЯ типом производимой обработки, но имеют единообразный внешний интерфейс (рис. 4). Љаждый итератор открывает один (или более) входных потоков данных (data flow), последовательно считывает их и, после обработки, помещает результаты в выходной поток. €тератору безразличен источник входного потока и назначение выходного потока - это может быть диск, другой итератор, сетевое соединение. Њы будем говорить о поставщиках и потребителЯх потоков данных. Ќиже перечислены типы итераторов, применЯемые в INFORMIX-OnLine DS:


 <dd><IMG SRC="informix_8.gif" WIDTH=416 HEIGHT=252 ALIGN="LEFT" HSPACE=12>


 <dd>ђис. 4. ђабота итератора не зависит от источников входных данных. ‚ывод поступает объекту, который вызвал итератор.


 <dd>SCAN - ‘канирует фрагментированные и нефрагментированные таблицы и индексы.

 <dd>NESTED LOOP JOIN - ђеализует стандартную логику соединений методом вложенных циклов (читает строку из одной таблицы, находит все совпадениЯ во второй таблице, читает следующую строку из первой таблицы и т. д.).

 <dd>MERGE JOIN - ‚ыполнЯет фазу слиЯниЯ длЯ соединениЯ методом сортировки и слиЯниЯ.

 <dd>HASH JOIN - ђеализует новый метод соединений с хешированием. „лЯ одной из двух соединЯемых таблиц строитсЯ хеш-таблица, втораЯ таблица зондируетсЯ. Ћптимизатор решает, какаЯ из таблиц будет хешироватьсЯ.

 <dd>GROUP - ѓруппирует данные (GROUP BY) и вычислЯет агрегатные функции.

 <dd>SORT - ‘ортирует данные.

 <dd>MERGE - ‚ыполнЯет объединениЯ UNION и UNION ALL (длЯ UNION используетсЯ комбинациЯ итераторов MERGE и SORT).

 <dd>REMOTE - ђеализует удаленные сканированиЯ длЯ операторов SELECT.

 <dd>€тератор как программный объект состоит из статических и динамических структур данных. ‘татическаЯ структура содержит ссылки на функции (или методы), применимые к итератору. „инамическаЯ структура содержит информацию о текущем состоЯнии итератора (открыт, закрыт, выполнЯет очередную итерацию), одну или две ссылки на поставщиков.

 <dd>Њетоды итератора

 <dd>CREATE() - ‘оздает итератор. ‚ыделЯет памЯть длЯ итератора, инициализирует его структуры, а также остальные методы (open(), next(), close(), free()), т.е. устанавливает ссылки на функции, соответствующие данному типу итератора. ‡атем вызывает метод create() длЯ своих итераторов-поставщиков, которые создадут своих поставщиков, если таковые имеютсЯ, и т. д. ’аким образом, вызов метода create() длЯ корневого итератора приводит к созданию всего дерева итераторов.

 <dd>OPEN() - ‡апускает итератор. ‚ыполнЯютсЯ специфические длЯ данного типа итератора инициализирующие действиЯ, возможно, запрос дополнительной памЯти. Ќапример, при запуске итератора сканированиЯ определЯетсЯ, какие фрагменты необходимо сканировать, устанавливаетсЯ указатель на первый из них, создаетсЯ временнаЯ таблица (если она нужна), посылаетсЯ сообщение

 <dd>MGM (MGM - компонента сервера, котораЯ регулирует выделение ресурсов под запросы, обрабатываемые средствами PDQ; см. об этом ниже, п. "Ѓаланс между OLTP и DSS-приложениЯми") о запуске потока сканированиЯ. „алее применЯетсЯ метод open() по отношению к поставщикам итератора, которые применЯт его к своим поставщикам и т.д. ’аким образом, длЯ запуска всего дерева итераторов достаточно применить метод open() к корневому итератору.

 <dd>NEXT() - ‚ыполнЯет одну итерацию. ‚ыполнение начинаетсЯ с того, что итератор применЯет метод next() к своим поставщикам, заставлЯЯ их также применить next() к своим поставщикам и т. д., пока не сработают итерации поставщиков нижнего уровнЯ. ‡атем данные поднимаютсЯ снизу вверх - каждый итератор, получив данные от своего поставщика, применЯет к ним свой специфический вид обработки и передает результат своему потребителю. Њетод next() применЯетсЯ циклически, пока не поступит признак конца потока данных.

 <dd>CLOSE() - ‡акрывает итератор. ‚ысвобождает памЯть, выделенную при запуске. ”актически, эта памЯть могла уже быть высвобождена методом next(), когда он получил признак конца данных, поскольку общий принцип состоит в том, чтобы освобождать памЯть сразу же, как только она становитсЯ не нужна. Ћднако, это не всегда возможно. Џоэтому на метод close() возлагаетсЯ ответственность за то, чтобы памЯть в любом случае была освобождена.

 <dd>Њетод close() рекурсивно применЯетсЯ к поставщикам, тем самым, закрываетсЯ все дерево итераторов.

 <dd>FREE() - Ћсвобождает итератор. ‚ысвобождает памЯть, выделенную при создании. ЏрименЯет free() к поставщикам, таким образом, освобождаетсЯ все дерево итераторов.

 <dd>ЃлагодарЯ единообразию интерфейса, итераторы разных типов могут соединЯтьсЯ друг с другом произвольным образом (рис. 5). €тератор не заботитсЯ о том, какой тип имеют его поставщики, поскольку он взаимодействует с ними только посредством методов. €з описаниЯ методов следует, что запуск дерева, составленного из итераторов, реализует их параллельное выполнение. „лЯ каждого итератора создаетсЯ поток выполнениЯ, который продвигаетсЯ по мере того, как получает данные от своих поставщиков. ’аким образом в сервере реализуетсЯ вертикальный параллелизм - одновременное, конвейерное выполнение различных итераторов.

 <dd><IMG SRC="informix_9.gif" WIDTH=416 HEIGHT=260 ALIGN="LEFT" HSPACE=12>


 <dd>ђис. 5. €тераторы выполнЯютсЯ параллельно, каждый может продвигатьсЯ по мере того, как поступают данные от его поставщиков.


 <dd>„ругой вид параллелизма - горизонтальный - заключаетсЯ в том, что вместо одного итератора (например, сканированиЯ) создаетсЯ несколько однотипных параллельно выполнЯемых итераторов. ѓоризонтальный параллелизм реализуетсЯ при помощи итераторов специального вида - итераторов обмена (EXCHANGE). Џосле того, как дерево реализации запроса построено, оптимизатор определЯет, какие его компоненты имеет смысл распараллелить. Ќад такой компонентой вставлЯетсЯ итератор EXCHANGE. €тератор EXCHANGE создает и запускает несколько экземплЯров своего поставщика, обеспечивает координацию поступающих от них потоков данных и их передачу своему потребителю. Џередача данных осуществлЯетсЯ в этом случае не через входы потребителЯ, а через очереди пакетов в разделЯемой памЯти.

 <dd>‘тепень и наиболее оптимальные способы применениЯ вертикального и горизонтального параллелизма длЯ каждого конкретного запроса определЯетсЯ оптимизатором. Ћптимизатор принимает решениЯ, исходЯ из значений параметров конфигурации, устанавливаемых администратором, пользователем и клиентским приложением, а также с учетом некоторых внутренних соображений, таких как число наличных процессоров, фрагментациЯ участвующих в запросе таблиц, сложность запроса и т. д.

 <dd>ђезультаты тестов показывают, что механизмы PDQ и оптимизации INFORMIX-OnLine DS обеспечивают с увеличением числа процессоров практически пропорциональный рост производительности.


 <dd><B>2.2.5.3  <A NAME="_Toc408113436">Џримеры применениЯ параллелизма</A></B>


 <dd>ЏараллельнаЯ сортировка

 <dd>‘ортировка - это фундаментальнаЯ операциЯ обработки баз данных, применЯемаЯ при выполнении таких действий, как построение индексов, соединение методом сортировки и слиЯниЯ, группирование; поэтому ускорение сортировки улучшает качество многих приложений.

 <dd>Џри параллельной сортировке совокупность данных разбиваетсЯ на секции, которые передаютсЯ длЯ сортировки нескольким процессорам. ‡атем выполнЯетсЯ слиЯние отсортированных секций.

 <dd>Ќа практике скорость сортировки ограничиваетсЯ временем сканированиЯ данных из таблиц. ќто ограничение в значительной мере снимаетсЯ применением PDQ-алгоритмов параллельного сканированиЯ.

 <dd>Џараллельное сканирование

 <dd>Ћперации построениЯ индексов, соединений, подготовки отчетов, необходимые в большинстве приложений, требуют сканированиЯ больших объемов данных, если в них участвуют большие таблицы. ’ехнологиЯ PDQ позволЯет существенно снизить времЯ сканированиЯ. …сли таблица фрагментирована, то секции сканируютсЯ параллельно, при этом выигрыш во времени примерно пропорционален числу дисков. Џри сканировании последовательных таблиц или индексов применЯетсЯ конфигурациЯ сервера OnLine DS с опережающим чтением - времЯ отклика сокращаетсЯ за счет того, что чтение очередных страниц идет параллельно с обработкой уже прочитанных.

 <dd>Џараллельное построение индексов

 <dd>Џроцедура построениЯ индекса начинаетсЯ с оценки объема данных и определениЯ числа потоков, необходимых длЯ их сканированиЯ. ‡атем выполнЯетсЯ параллельное сканирование данных с применением, там, где это возможно, опережающего чтениЯ. ‘читанные данные помещаютсЯ в участки разделЯемой памЯти, и запускаетсЯ параллельнаЯ сортировка участков, длЯ каждого из которых строитсЯ ‚поддерево; затем из них формируетсЯ общий индекс. Џотоки сортировки начинают выполнЯтьсЯ, не дожидаЯсь завершениЯ всех потоков сканированиЯ, точно так же, поток построениЯ индекса не ожидает завершениЯ всех потоков сортировки - все, что можно, выполнЯетсЯ параллельно. ‚ результате достигаетсЯ ускорение, вплоть до десЯтикратного, по сравнению с последовательными методами построениЯ индексов - в зависимости от объемов данных, числа используемых дисков и доступной памЯти.


 <dd><B>2.2.5.4  <A NAME="_Toc408113437">Ѓаланс между OLTP и DSS-приложениЯми</A></B>


 <dd>‚ современных информационных системах, как правило, требуетсЯ одновременное выполнение разных по характеру запросов к базе данных. ‚ыделЯютсЯ приложениЯ обработки данных типа OLTP, DSS и пакетной обработки.

 <dd>Џример OLTP-запроса: …сть ли свободный номер в какой-либо берлинской гостинице на 8-е декабрЯ?

 <dd>Џример DSS-запроса: Љаковы будут затраты на реализацию стратегии X охраны здоровьЯ сотрудников по сравнению со стратегией Y с учетом демографического профилЯ компании? ‡ависит ли эффективность стратегии от региона?

 <dd>Џримерами заданий пакетной обработки могут служить массоваЯ загрузка данных, выдача больших сложных отчетов, выполнение некоторых административных действий, например, по реорганизации базы данных.

 <dd>Ћтветы на запросы первого типа должны выдаватьсЯ практически мгновенно, запросы второго и третьего типов могут обслуживатьсЯ достаточно долго, но при отсутствии или малой интенсивности OLTP-приложений желательно получать ответы на DSS-запросы максимально быстро.

 <dd>’ехнологиЯ PDQ используетсЯ в основном длЯ быстрого выполнениЯ DSS-запросов и пакетных приложений. …сли ее применение ничем не ограничено, то сильно распараллеленное выполнение нескольких сложных запросов приводит к недопустимому замедлению OLTP-приложений, выполнЯющихсЯ на том же сервере. “правление степенью распараллеливаниЯ запросов и долей системных ресурсов, выделЯемых длЯ PDQ-обработки, в среде INFORMIX-OnLine DS осуществлЯетсЯ при помощи нескольких параметров конфигурированиЯ и переменных окружениЯ, значениЯ которых динамически настраиваемы. ‡начениЯ этих параметров и переменных устанавливаютсЯ системными администраторами и, в определенной степени, прикладными программистами и пользователЯми.

 <dd>Џрограммист или пользователь задает тип каждого запроса (обычный или PDQ) и желаемую степень распараллеливаниЯ длЯ PDQ-запросов. Ђдминистратор, со своей стороны, динамически ограничивает максимальную допустимую степень распараллеливаниЯ PDQ-запросов, а также определЯет долю системных ресурсов, выделЯемых под обработку PDQ-запросов. ЏараллельнаЯ сортировка применЯетсЯ длЯ любых запросов, в том числе, обычных.

 <dd>’аким образом, режим работы сервера INFORMIX-OnLine DS может динамически изменЯтьсЯ. ‚ часы наиболее активной работы приложений OLTP запросы DSS выполнЯютсЯ без распараллеливаниЯ (когда длЯ каждого запроса создаетсЯ всегда только один поток класса CPU) или с невысокой степенью распараллеливаниЯ. ‚ остальное времЯ, или на серверах, где приложениЯ OLTP отсутствуют, устанавливаетсЯ максимальнаЯ степень использованиЯ PDQ.

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


<UL>

<UL>

 <dd><LI>устанавливает приоритет каждого запроса; </LI>

 <dd><LI>следит за тем, чтобы одновременно выполнЯлось не более заданного числа PDQ-запросов; </LI>

 <dd><LI>следит за тем, чтобы объем разделЯемой памЯти, занЯтой под обработку сложных запросов, не превышал заданного уровнЯ; </LI>

 <dd><LI>совместно с оптимизатором запросов обеспечивает максимальную при заданных параметрах степень параллелизма на всех уровнЯх.</LI></UL>
</UL>


 <dd>2.2.6  <A NAME="_Toc408113438">Ћптимизатор выполнениЯ запросов по стоимости</A>


 <dd>Ћптимизатор запросов определЯет наиболее оптимальный с точки зрениЯ затрат системных ресурсов план реализации каждого запроса к базе данных. “читываетсЯ число обменов с диском, затраты разделЯемой памЯти, затраты на пересылку данных по сети и др. Џлан может включать параллельное выполнение операций или быть строго последовательным, что зависит как от структуры запроса, так и от ресурсов, выделЯемых MGM. Ћптимизатор опираетсЯ на статистическую информацию о распределении данных по столбцам таблиц, периодическим сбором которой управлЯет администратор.

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

 <dd>Ћптимизатор дает возможность разработчику предварительно получить план выполнениЯ запроса, в том числе, распределенной транзакции. Џолучив такой план, разработчик может выЯснить, что не располагает достаточной памЯтью, чтобы сохранить полученные в результате данные, или что выполнение запроса потребует слишком больших затрат системных ресурсов. ‚ такой ситуации он либо отложит выполнение запроса на другое времЯ, либо переформулирует запрос так, чтобы сузить объем возвращаемых данных, либо примет какое-то другое решение.

 <dd>Џрикладной программист или пользователь устанавливает один из двух возможных уровней оптимизации - высокий или низкий. ‚ысокий уровень оптимизации предполагает перебор большого числа возможных вариантов и сам требует больших затрат системных ресурсов, в частности, памЯти. ЋптимизациЯ низкого уровнЯ обходитсЯ дешевле, поскольку перебираетсЯ небольшое число предположительно оптимальных вариантов, но остаетсЯ вероЯтность "упустить" наилучший вариант. Ќапример, план выполнениЯ хранимой процедуры вычислЯетсЯ заранее с высоким уровнем оптимизации и сохранЯетсЯ, после чего устанавливаетсЯ низкий уровень - тогда при обращении к процедуре используетсЯ построенный заранее наиболее оптимальный план.


 <dd>2.2.7  <A NAME="_Toc408113439">‘редства обеспечениЯ надежности</A>


 <dd>‘ервер INFORMIX-OnLine DS предоставлЯет следующие средства длЯ восстановлениЯ после сбоев и обеспечениЯ отказоустойчивости:


<UL>

<UL>

 <dd><LI>‡еркалирование дисковых областей </LI>

 <dd><LI>Џолное тиражирование данных сервера </LI>

 <dd><LI>Ѓыстрое восстановление при включении системы </LI>

 <dd><LI>‘редства архивированиЯ данных </LI></UL>
</UL>


 <dd><B><A NAME="_Toc408113440">2.2.7.1 . ‡еркалирование дисковых областей</A></B>


 <dd>‡еркалирование в INFORMIX-OnLine DS - это дублирование свЯзной дисковой области, выделенной под базу данных, на такую же по размеру область. €сходнаЯ область называетсЯ первичной, а ее копиЯ - зеркальной. –ели, длЯ которых применЯетсЯ зеркалирование - высокаЯ готовность и оптимизациЯ операций чтениЯ.

 <dd>‚ысокаЯ готовность достигаетсЯ за счет того, что при выходе из строЯ диска, на котором находитсЯ первичнаЯ область, сервер автоматически продолжает работу с оставшимсЯ диском без перехода сервера в режим off-line. ‚се операции чтениЯ-записи происходЯт с зеркальной областью (при условии, что она находитсЯ на другом диске). ‚осстановление копии на первичном диске после его включениЯ производитсЯ в оперативном режиме.

 <dd>‡атраты на зеркалирование складываютсЯ из затрат дискового пространства и затрат на дополнительные операции записи. ‚ условиЯх, когда имеетсЯ несколько виртуальных процессоров обмена с диском, операции записи на оба диска производЯтсЯ параллельно, и затраты второго рода сводЯтсЯ к минимуму. Љ тому же они компенсируютсЯ оптимизацией операций чтениЯ, о которой говоритсЯ ниже.

 <dd>‚ идеальном случае зеркалирование должно быть обеспечено длЯ всех областей базы данных. Љрайне желательно поддерживать зеркалирование длЯ критичных областей, составлЯющих корневое пространство базы данных и пространства, где хранЯтсЯ логический и физический журналы. Џри выходе из строЯ любого из них, если нет зеркального дублЯ, сервер немедленно переводитсЯ в режим off-line. Џри отказе других незеркалируемых областей недоступными становЯтсЯ только хранЯщиесЯ на них таблицы или фрагменты таблиц - до завершениЯ процедуры их восстановлениЯ. Џоэтому длЯ наиболее критичных таблиц также желательно поддерживать зеркалирование.

 <dd>ЋптимизациЯ операций чтениЯ достигаетсЯ за счет разбиениЯ (split read). ‘траницы, относЯщиесЯ к начальной половине области, читаютсЯ с первичной области, а страницы из второй половины - с зеркальной. ‚ результате ускорЯетсЯ поиск страницы на диске, поскольку максимальный пробег дисковых головок сокращаетсЯ вдвое.


 <dd><B>2.2.7.2  <A NAME="_Toc408113441">’иражирование</A></B>


 <dd>’иражирование - это поддержание на другой вычислительной установке копии объектов базы данных. ‚ INFORMIX-OnLine DS реализовано прозрачное тиражирование данных с основного сервера баз данных на вторичный (или поддерживающий) сервер, к которому разрешен доступ только на чтение и который может находитьсЯ в другом географическом пункте. ‚ этой терминологии сервер, не участвующий в тиражировании, называетсЯ стандартным.

 <dd>ѓлавнаЯ цель тиражированиЯ в INFORMIX-OnLine DS - это обеспечение высокой готовности (High Availability Data Replication - HDR). ‚ случае отказа основного сервера вторичному серверу автоматически или вручную придаетсЯ статус стандартного, с доступом на чтение и запись (рис. 6, рис. 7). Џрозрачное перенаправление клиентов при отказе основного сервера не поддерживаетсЯ, но оно может быть реализовано в рамках приложений.

 <dd><IMG SRC="informix_10.gif" WIDTH=416 HEIGHT=232 ALIGN="LEFT" HSPACE=12>


 <dd>ђис. 6. ’иражирование. Ћсновной сервер доступен на чтение и запись, вторичный - только на чтение.


 <dd><IMG SRC="informix_11.gif" WIDTH=416 HEIGHT=232 ALIGN="LEFT" HSPACE=12>


 <dd>ђис. 7. Љогда основной сервер выходит из строЯ, вторичный переходит в режим стандартного сервера и становитсЯ доступен на чтение и запись.


 <dd>Џосле восстановлениЯ основного сервера, в зависимости от значениЯ параметра конфигурации, выбираетсЯ один из двух возможных сценариев:


<UL>

<UL>

 <dd><LI>‚осстановленному серверу вновь придаетсЯ статус основного. ‚торичный сервер, перед возвращением в режим доступа только на чтение, останавливаетсЯ, чтобы обеспечить отсоединение клиентов, которые осуществлЯли доступ на запись. </LI>

 <dd><LI>‚осстановленный сервер становитсЯ вторичным, а бывшему вторичному, который уже функционирует в режиме чтениЯ-записи, придаетсЯ статус основного; клиенты, которые подключены к нему, продолжают работу. ќтот сценарий обеспечивает непрерывную доступность баз данных. </LI></UL>
</UL>


 <dd>’иражирование осуществлЯетсЯ путем передачи информации из журнала транзакций (логического журнала) в буфер тиражированиЯ основного сервера, откуда она пересылаетсЯ в буфер тиражированиЯ вторичного сервера. ’акаЯ пересылка может происходить либо в синхронном, либо в асинхронном режиме. ‘инхронный режим гарантирует полную согласованность баз данных - ни одна транзакциЯ, зафиксированнаЯ на основном сервере, не останетсЯ незафиксированной на вторичном, даже в случае сбоЯ основного сервера. Ђсинхронный режим не обеспечивает абсолютной согласованности, но улучшает рабочие характеристики системы.

 <dd>‡еркалирование, которое также ЯвлЯетсЯ прозрачным средством поддержаниЯ высокой готовности, обеспечивает только копирование дисковых областей в пределах одной установки сервера INFORMIX-OnLine DS и защищает только от дисковых сбоев. Њеханизм тиражированиЯ обеспечивает поддержание полной удаленной копии баз данных и защищает от всех видов отказов, включаЯ полный крах одной из установок.

 <dd>Џомимо обеспечениЯ отказоустойчивой работы, тиражирование дает следующие преимущества:


<UL>

<UL>

 <dd><LI>более оперативный доступ к данным длЯ локальных клиентов вторичного сервера; </LI>

 <dd><LI>возможность вынести приложениЯ DSS преимущественно на вторичный сервер, где они выполнЯютсЯ с максимальным использованием PDQ, не подавлЯЯ приложений OLTP, выполнЯющихсЯ на основном сервере. </LI></UL>
</UL>


 <dd><B>2.2.7.3  <A NAME="_Toc408113442">Ѓыстрое восстановление при включении системы</A></B>


 <dd>Џри включении сервер всегда проверЯет, не произошло ли последнее выключение системы аварийно. ‚ этом случае база данных не разрушена, но множество транзакций, выполнЯвшихсЯ в момент сбоЯ, остались в незавершенном, некорректном состоЯнии. …сли сервер выЯвил такую ситуацию, то он запускает процедуру быстрого восстановлениЯ, котораЯ обеспечивает возврат системы в корректное состоЯние.


 <dd><B>2.2.7.4  <A NAME="_Toc408113443">Ђрхивирование и восстановление данных</A></B>


 <dd>INFORMIX-OnLine DS позволЯет создавать архивные копии данных, а в дальнейшем фиксировать те изменениЯ, которые произошли на сервере с момента созданиЯ архива. €зменениЯ сохранЯютсЯ в файлах журнала транзакций. Ђрхивные ленты и ленты с копиЯми журналов транзакций могут записыватьсЯ параллельно с доступом пользователей к серверу. Џроцедура восстановлениЯ состоит из двух шагов - считываниЯ данных из архивной копии и применениЯ к ним тех изменений, которые были зафиксированы в журналах транзакций.

 <dd>‚ состав сервера INFORMIX-OnLine DS входит утилита OnArchive, предоставлЯющаЯ развитые и гибкие средства архивированиЯ, копированиЯ журналов транзакций и восстановлениЯ информации. Ќиже перечислены основные возможности этой утилиты:


<UL>

<UL>

 <dd><LI>Ђрхивирование и восстановление на уровне дисковых областей (dbspace). ЂрхивируетсЯ одна или несколько дисковых областей. ‘ одной архивной ленты можно восстановить одну или несколько дисковых областей. ЏоддерживаетсЯ инкрементальное архивирование (т. е. сохранение только информации, котораЯ изменилась с момента созданиЯ последнего полного или инкрементального архива). </LI>

 <dd><LI>‚осстановление данных в оперативном режиме. ‚ случае сбоЯ носителЯ, если не затронуты критические длЯ работоспособности INFORMIX-OnLine DS дисковые области, пользователи продолжают взаимодействие с сервером. „оступ к данным, находЯщимсЯ на вышедшем из строЯ носителе, возобновлЯетсЯ после завершениЯ процедуры восстановлениЯ. </LI>

 <dd><LI>‘оставление и просмотр расписаниЯ операций архивированиЯ и резервированиЯ. Ћперации производЯтсЯ автоматически, по заданному расписанию. </LI>

 <dd><LI>Њетки на архивных лентах. Ќаличие меток сводит к минимуму риск таких ошибок администратора, как запись на ленту, на которой находитсЯ часть активного в данный момент архива, или восстановление данных с устаревшей архивной ленты. </LI>

 <dd><LI>€нтерактивный интерфейс с оператором, основанный на меню и экранных формах. </LI>

 <dd><LI>‘редства восстановлениЯ при катастрофах. ‚ случае катастрофического краха информациЯ каталога архивированиЯ/восстановлениЯ, поддерживаемого сервером INFORMIX-OnLine DS, может быть прочитана с заголовка архивной ленты. </LI>

 <dd><LI>Њножественные копии архивов на лентах. ‘ервер INFORMIX-OnLine DS способен одновременно создавать множественные копии архивов и журналов транзакций на нескольких лентопротЯжных устройствах. ‚ случае краха восстановление выполнЯетсЯ с любой из копий. </LI>

 <dd><LI>Ћпции шифрованиЯ и сжатиЯ архивов и журналов транзакций при записи. ‡а счет сжатиЯ объем необходимой вторичной памЯти сокращаетсЯ на величину от 20 до 50 процентов. </LI>

 <dd><LI>Љонтроль циклической избыточностью (CRC). ќтот метод позволЯет контролировать правильность информации, считываемой с ленты. Џри вводе данных с архивной ленты контрольнаЯ сумма, хранЯщаЯсЯ на ленте, сверЯетсЯ с вычислЯемой контрольной суммой. </LI>

 <dd><LI>Џредоставление определенным пользователЯм прав на архивирование и восстановление некоторых дисковых областей.</LI></UL>
</UL>


 <dd>2.2.8  <A NAME="_Toc408113444">„инамическое администрирование</A>


 <dd>‚ условиЯх, когда базы данных увеличиваютсЯ в размерах, становЯтсЯ распределенными и служат основой длЯ особо ответственных приложений масштаба предприЯтиЯ, которые должны работать круглосуточно, возрастает роль развитых динамических средств администрированиЯ. ќти средства должны позволЯть администраторам оперативно следить за такими характеристиками работы сервера, как использование памЯти и виртуальных процессоров, очереди асинхронного ввода-вывода, очереди пакетных заданий и приложений DSS, наличное дисковое пространство, эффективность схем фрагментации и т. п. …сли какие-то из характеристик неудовлетворительны, то необходима возможность динамически, не останавливаЯ системы, изменить параметры конфигурации или запустить необходимые административные утилиты.

 <dd>Ѓольшинство параметров конфигурации сервера ЯвлЯютсЯ динамически настраиваемыми, их можно изменить, не останавливаЯ сервера, при помощи утилиты ON-Monitor. Џомимо рассмотренных в