        ‚иктор Љустов. Informix. ђуководство администратора баз данных

---------------------------------------------------------------
 Email: visor@olma.co.ru і mailto:visor@olma.co.ru
---------------------------------------------------------------
</pre>

 <dd><B>1. ’еоретические основы.</B> <A HREF="#_Toc408113413">*</A>

 <dd>1.1 ЏонЯтие ‘“Ѓ„ сервера. <A HREF="#_Toc408113414">*</A>

 <dd><I>1.1.1 Ћсновные функции ‘“Ѓ„</I> <A HREF="#_Toc408113415">*</A>

 <dd><I>1.1.2 ’иповаЯ организациЯ современной ‘“Ѓ„</I> <A HREF="#_Toc408113416">*</A>

 <dd>1.2 ЏонЯтие архитектуры клиент-сервер. <A HREF="#_Toc408113417">*</A>

 <dd><B>2. ’еоретические основы ‘“Ѓ„ сервера Informix OnLine v.7.X</B> <A HREF="#_Toc408113418">*</A>

 <dd>2.1 ‘“Ѓ„ сервер Informix. <A HREF="#_Toc408113419">*</A>

 <dd>2.2 Ђрхитектура ‘“Ѓ„ сервера Informix OnLine v.7.X <A HREF="#_Toc408113420">*</A>

 <dd><I>2.2.1 . „инамическаЯ масштабируемаЯ архитектура</I> <A HREF="#_Toc408113421">*</A>

 <dd>2.2.1.1 Џотоки <A HREF="#_Toc408113422">*</A>

 <dd>2.2.1.2 ‚иртуальные процессоры <A HREF="#_Toc408113423">*</A>

 <dd>2.2.1.3 Џланирование потоков <A HREF="#_Toc408113424">*</A>

 <dd>2.2.1.4 ђазделение потоков между виртуальными процессорами. <A HREF="#_Toc408113425">*</A>

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

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

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

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

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

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

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

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

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

 <dd>2.2.5.2 €тераторы <A HREF="#_Toc408113435">*</A>

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

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

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

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

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

 <dd>2.2.7.2 ’иражирование <A HREF="#_Toc408113441">*</A>

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

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

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

 <dd>2.2.8.1 €нтерфейс мониторинга системы <A HREF="#_Toc408113445">*</A>

 <dd>2.2.8.2 “тилита DB/Cockpit <A HREF="#_Toc408113446">*</A>

 <dd>2.2.8.3 “тилита OnPerf <A HREF="#_Toc408113447">*</A>

 <dd>2.2.8.4 “тилита параллельной загрузки <A HREF="#_Toc408113448">*</A>

 <dd><I>2.2.9 ђаспределенные вычислениЯ</I> <A HREF="#_Toc408113449">*</A>

 <dd>2.2.9.1 ‚заимодействие клиент-сервер <A HREF="#_Toc408113450">*</A>

 <dd>2.2.9.2 Џрозрачность расположениЯ данных <A HREF="#_Toc408113451">*</A>

 <dd>2.2.9.3 ђаспределенные базы данных и протокол двухфазовой фиксации транзакций <A HREF="#_Toc408113452">*</A>

 <dd><I>2.2.10 Џоддержка национальных Языков</I> <A HREF="#_Toc408113453">*</A>

 <dd><I>2.2.11 ‘редства безопасности класса ‘2</I> <A HREF="#_Toc408113454">*</A>

 <dd>2.3 „ополнительные компоненты компании Informix длЯ выполнениЯ специфических задач. <A HREF="#_Toc408113455">*</A>

 <dd><I>2.3.1 Informix-Enterprise Gateway 7.1</I> <A HREF="#_Toc408113456">*</A>

 <dd><I>2.3.2 ’ехнологиЯ и компоненты EDA/SQL</I> <A HREF="#_Toc408113457">*</A>

 <dd>2.3.2.1 EDA API/SQL <A HREF="#_Toc408113458">*</A>

 <dd>2.3.2.2 EDA/Link <A HREF="#_Toc408113459">*</A>

 <dd>2.3.2.3 EDA/SQL Server <A HREF="#_Toc408113460">*</A>

 <dd>2.3.2.4 EDA/Data Drivers <A HREF="#_Toc408113461">*</A>

 <dd><I>2.3.3 ‚озможности Enterprise Gateway</I> <A HREF="#_Toc408113462">*</A>

 <dd>2.3.3.1 Џрозрачный доступ длЯ чтениЯ и записи <A HREF="#_Toc408113463">*</A>

 <dd>2.3.3.2 ђаспределенные соединениЯ <A HREF="#_Toc408113464">*</A>

 <dd>2.3.3.3 Љонфигурирование Enterprise Gateway <A HREF="#_Toc408113465">*</A>

 <dd>2.3.3.4 Ѓезопасность <A HREF="#_Toc408113466">*</A>

 <dd><I>2.3.4 Ѓиблиотеки сопрЯжениЯ сервера Informix-OnLine DS с менеджерами транзакций: Informix-TP/XA и Informix-TP/TOOLKIT</I> <A HREF="#_Toc408113467">*</A>

 <dd>2.4 ‡аключение <A HREF="#_Toc408113468">*</A>

 <dd>2.5 ‹итература <A HREF="#_Toc408113469">*</A>


 <dd><B><A NAME="_Toc408988601"><A NAME="_Toc408113413">1. ’еоретические основы.</A></A>

 <dd><I><A NAME="_Toc408988602"><A NAME="_Toc408113414">1.1 ЏонЯтие ‘“Ѓ„ сервера.</A></A></B>
</I>


 <dd>’радиционных возможностей файловых систем оказываетсЯ недостаточно длЯ построениЯ даже простых информационных систем. Џри построении информационной системы требуетсЯ обеспечить: поддержание логически согласованного набора данных; обеспечение Языка манипулированиЯ данными; восстановление информации после разного рода сбоев; реально параллельнаЯ работа нескольких пользователей. „лЯ выполнениЯ всех этих задачь выделЯетсЯ группа программ, обьедененных в единый программный комплекс. ќтот комплекс носит название  система управлениЯ базами данных (‘“Ѓ„). ‘формулируем эти (и другие) важные функции отдельно.


 <dd>1.1.1  <A NAME="_Toc408113415">Ћсновные функции ‘“Ѓ„</A>


 <dd>Љ числу функций ‘“Ѓ„ принЯто относить следующее:


 <dd>1. Ќепосредственное управление данными во внешней памЯти


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

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


 <dd>2. “правление буферами оперативной памЯти


 <dd>‘“Ѓ„ обычно работают с Ѓ„ значительного размера; по крайней мере этот размер обычно существенно превышает доступный объем оперативной памЯти. ЏонЯтно, если при обращении к любому элементу данных будет производитьсЯ обмен с внешней памЯтью, то всЯ система будет работать со скоростью устройства внешней памЯти. …динственным же способом реального увеличениЯ этой скорости ЯвлЯетсЯ буферизациЯ данных в оперативной памЯти. € даже если операционнаЯ система производит общесистемную буферизацию (как в случае Ћ‘ UNIX), этого недостаточно длЯ целей ‘“Ѓ„, котораЯ располагает гораздо большей информацией о полезности буферизации той или иной части Ѓ„. Џоэтому в развитых ‘“Ѓ„ поддерживаетсЯ собственный набор буферов оперативной памЯти с собственной дисциплиной замены буферов. Џри управлении буферами основной памЯти приходитсЯ разрабатывать и применЯть согласованные алгоритмы буферизации, журнализации и синхронизации. ‡аметим, что существует отдельное направление ‘“Ѓ„, которые ориентированы на постоЯнное присутствие в оперативной памЯти всей Ѓ„. ќто направление основываетсЯ на предположении, что в предвидимом будущем объем оперативной памЯти компьютеров сможет быть настолько велик, что позволит не беспокоитьсЯ о буферизации. Џока эти работы находЯтсЯ в стадии исследований.


 <dd>3. “правление транзакциЯми


 <dd>’ранзакциЯ - это последовательность операций над Ѓ„, рассматриваемых ‘“Ѓ„ как единое целое. ‹ибо транзакциЯ успешно выполнЯетсЯ, и ‘“Ѓ„ фиксирует (COMMIT) изменениЯ Ѓ„, произведенные ею, во внешней памЯти, либо ни одно из этих изменений никак не отражаетсЯ в состоЯнии Ѓ„. ЏонЯтие транзакции необходимо длЯ поддержаниЯ логической целостности Ѓ„. …сли вспомнить наш пример информационной системы отдела кадров с файлами ‘Ћ’ђ“„Ќ€Љ€ и Ћ’„…‹›, то единственным способом не нарушить целостность Ѓ„ при выполнении операции приема на работу нового сотрудника будет объединение элементарных операций над файлами ‘Ћ’ђ“„Ќ€Љ€ и Ћ’„…‹› в одну транзакцию. ’аким образом, поддержание механизма транзакций - обЯзательное условие даже однопользовательских ‘“Ѓ„ (если, конечно, такаЯ система заслуживает названиЯ ‘“Ѓ„). Ќо понЯтие транзакции гораздо существеннее во многопользовательских ‘“Ѓ„. ’о свойство, что каждаЯ транзакциЯ начинаетсЯ при целостном состоЯнии Ѓ„ и оставлЯет это состоЯние целостным после своего завершениЯ, делает очень удобным использование понЯтиЯ транзакции как единицы активности пользователЯ по отношению к Ѓ„. Џри соответствующем управлении параллельно выполнЯющимисЯ транзакциЯми со стороны ‘“Ѓ„ каждый пользователь может в принципе ощущать себЯ единственным пользователем ‘“Ѓ„ (на самом деле, это несколько идеализированное представление, поскольку пользователи многопользовательских ‘“Ѓ„ порой могут ощутить присутствие своих коллег).

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

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


 <dd>4. †урнализациЯ


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


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

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

 <dd>‚о всех случаЯх придерживаютсЯ стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). ѓрубо говорЯ, эта стратегиЯ заключаетсЯ в том, что запись об изменении любого объекта Ѓ„ должна попасть во внешнюю памЯть журнала раньше, чем измененный объект попадет во внешнюю памЯть основной части Ѓ„. €звестно, если в ‘“Ѓ„ корректно соблюдаетсЯ протокол WAL, то с помощью журнала можно решить все проблемы восстановлениЯ Ѓ„ после любого сбоЯ.

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

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

 <dd>„лЯ восстановлениЯ Ѓ„ после жесткого сбоЯ используют журнал и архивную копию Ѓ„. ѓрубо говорЯ, архивнаЯ копиЯ - это полнаЯ копиЯ Ѓ„ к моменту начала заполнениЯ журнала (имеетсЯ много вариантов более гибкой трактовки смысла архивной копии). Љонечно, длЯ нормального восстановлениЯ Ѓ„ после жесткого сбоЯ необходимо, чтобы журнал не пропал. Љак уже отмечалось, к сохранности журнала во внешней памЯти в ‘“Ѓ„ предъЯвлЯютсЯ особо повышенные требованиЯ. ’огда восстановление Ѓ„ состоит в том, что исходЯ из архивной копии по журналу воспроизводитсЯ работа всех транзакций, которые закончились к моменту сбоЯ. ‚ принципе можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после конца восстановлениЯ. Ћднако в реальных системах это обычно не делаетсЯ, поскольку процесс восстановлениЯ после жесткого сбоЯ ЯвлЯетсЯ достаточно длительным.


 <dd>5. џзыки Ѓ„


 <dd>„лЯ работы с базами данных используютсЯ специальные Языки, в целом называемые Языками баз данных. ‚ ранних ‘“Ѓ„ поддерживалось несколько специализированных по своим функциЯм Языков. —аще всего выделЯлись два - Язык определениЯ схемы Ѓ„ (SDL - Schema Definition Language) и Язык манипулированиЯ данными (DML - Data Manipulation Language). SDL служил главным образом длЯ определениЯ логической структуры Ѓ„, т.е. той структуры Ѓ„, какой она представлЯетсЯ пользователЯм. DML содержал набор операторов манипулированиЯ данными, т.е. операторов, позволЯющих заносить данные в Ѓ„, удалЯть, модифицировать или выбирать существующие данные. Њы рассмотрим более подробно Языки ранних ‘“Ѓ„ в следующей лекции.

 <dd>‚ современных ‘“Ѓ„ обычно поддерживаетсЯ единый интегрированный Язык, содержащий все необходимые средства длЯ работы с Ѓ„, начинаЯ от ее созданиЯ и обеспечивающий базовый пользовательский интерфейс с базами данных. ‘тандартным Языком наиболее распространенных в настоЯщее времЯ релЯционных ‘“Ѓ„ ЯвлЯетсЯ Язык SQL (Structured Query Language). ‚ нескольких лекциЯх этого курса Язык SQL будет рассматриватьсЯ достаточно подробно, а пока мы перечислим основные функции релЯционной ‘“Ѓ„, поддерживаемые на "Языковом" уровне (т.е. функции, поддерживаемые при реализации интерфейса SQL).

 <dd>Џрежде всего Язык SQL сочетает средства SDL и DML, т.е. позволЯет определЯть схему релЯционной Ѓ„ и манипулировать данными. Џри этом именование объектов Ѓ„ (длЯ релЯционной Ѓ„ - именование таблиц и их столбцов) поддерживаетсЯ на Языковом уровне в том смысле, что компилЯтор Языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. ‚нутреннЯЯ часть ‘“Ѓ„ (Ядро) вообще не работает с именами таблиц и их столбцов.

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

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

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


 <dd><A NAME="_Toc408113416">1.1.2 ’иповаЯ организациЯ современной ‘“Ѓ„</A>


 <dd><A NAME="_Toc408988603"><A NAME="_Toc408113417">…стественно, организациЯ типичной ‘“Ѓ„ и состав ее компонентов соответствует рассмотренному нами набору функций.

 <dd>‹огически в современной релЯционной ‘“Ѓ„ можно выделить наиболее внутреннюю часть - Ядро ‘“Ѓ„ (часто его называют Data Base Engine), компилЯтор Языка Ѓ„ (обычно SQL), подсистему поддержки времени выполнениЯ, набор утилит. ‚ некоторых системах эти части выделЯютсЯ Явно, в других - нет, но логически такое разделение можно провести во всех ‘“Ѓ„.

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

 <dd> ЋсновнаЯ функциЯ компилЯтора Языка Ѓ„ - компилЯциЯ операторов Языка Ѓ„ в некоторую выполнЯемую программу.

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

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

 <dd><B><I>1.2 ЏонЯтие архитектуры клиент-сервер.</A></A></B>
</I>


 <dd><A NAME="_Toc408113418">‚ подавлЯющем большинстве случаев локальнаЯ сеть используетсЯ длЯ коллективного доступа к базам данных.

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

 <dd>    ‚торой подход носит название архитектура "клиент-сервер".

 <dd>    ЋпределениЯ:

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

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

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

 <dd>     ‘“Ѓ„  с  персональных ќ‚Њ ( такие,  как Clipper, DBase, FoxPro, Paradox,  Clarion имеют сетевые версии, которые просто совместно используют файлы баз данных тех же форматов длЯ ЏЉ, осуществлЯЯ при этом сетевые блокировки длЯ разграничениЯ доступа к таблицам и  записЯм.  Џри этом  всЯ работа осуществлЯетсЯ на ЏЉ.  ‘ервер используетсЯ просто как общий удаленный диск большой емкости.  ’акой способ работы приводит к риску потери данных при аппаратных сбоЯх.

 <dd>     Џо  сравнению  с  такими  системами  системы , построенные в архитектуре Љлиент - ‘ервер,  имеют следующие преимущества:

<UL>

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

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

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

 <dd><LI> в несколько раз уменьшает объем информации, передаваемый по сети.</LI></UL>

 <dd><B>2. ’еоретические основы ‘“Ѓ„ сервера Informix OnLine v.7.X</A></B>


 <dd><B><I><A NAME="_Toc408113419">2.1 ‘“Ѓ„ сервер Informix.</A></B>
</I>


 <dd>ђаботы над системой управлениЯ базами данных Informix были начаты в 1980 г. ‘огласно начальному замыслу программный комплекс Informix рассматривалсЯ как ‘“Ѓ„, специально ориентированнаЯ длЯ работы в среде Ћ‘ UNIX. „лЯ организации хранениЯ данных был выбран релЯционный подход. ‘ тех пор Informix стал одной из основных ‘“Ѓ„, работающих в среде UNIX.


 <dd>‘ейчас продукты Informix уже установлены практически на всех UNIX-компьютерах. ‘реди всех Ћ…Њ фирма выбрала шесть стратегических партнеров. ќто: Sequent, HP, SUN, IBM, Siemens Nixdorf, NCR. Џортирование продуктов фирмы на производимые стратегическими партнерами платформы производитсЯ в первую очередь. Џрактически это означает, что при поЯвлении на рынке новой платформы или новой версии операционной системы длЯ платформы уже имеетсЯ соответствующаЯ версиЯ продуктов Informix.


 <dd>‘реди не UNIX платформ Informix поддерживает NetWare, Windows, Windows NT и DOS.


 <dd>”ирма Informix объЯвила и поддерживает программу InSync. Џрограмма объединЯет независимых разработчиков программного обеспечениЯ. ‚ рамках этой программы созданы программные интерфейсы длЯ свЯзи с ‘“Ѓ„ других производителей, в частности ‘“Ѓ„, функционирующие на не UNIX-платформах.


 <dd>2.1.1 Ћписание продуктов Informix


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


 <dd>ЌачинаЯ с версии 4.0 фирма Informix поставлЯет сервер базы данных OnLine, который поддерживает аппарат распределенных транзакций (технологиЯ OLTP - on-line transaction processing), что позволЯет по-новому подходить к созданию баз данных с очень большим объемом хранимой информации.


 <dd>Љроме того, в Informix-OnLine включен новый тип данных - битовые полЯ (BLOB - binary large objects). Ѓитовые полЯ могут использоватьсЯ длЯ мультимедийных приложений (хранение изображений и звука).


 <dd><IMG SRC="informix_1.gif" WIDTH=407 HEIGHT=160>


 <dd>2.1.2 ’иповые конфигурации


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


 <dd>‘ервер базы данных (database engine), он же Ядро базы данных - это отдельнаЯ программа, выполнЯемаЯ как отдельный процесс. ‘ервер передает выбранную из базы информацию по каналу клиенту. €менно сервер работает с данными, заботитсЯ об их размещении на диске. ’ехнологию "клиент-сервер" со стороны сервера обеспечивают модули Informix-SE, Informix-Online или Informix OnLine-Dynamic Server.


 <dd>Informix-SE представлЯет собой сервер базы данных, предназначенный длЯ обеспечениЯ работы в системах с малым или средним объемом информации.

 <dd><IMG SRC="informix_2.gif" WIDTH=379 HEIGHT=248>


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


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


 <dd>Informix-OnLine - это сервер второго поколениЯ, обеспечивающий технологию распределенных транзакций (OLTP - on-line transaction processing). ’ехнологиЯ распределенных транзакций позволЯет выполнЯть запросы в распределенной базе данных, физически находЯщихсЯ на различных компьютерах. Џо сравнению с Informix-SE сервер Informix-OnLine имеет специальный тип данных - битовые полЯ (BLOB - Binary Large Objects), символьные строки переменной длины, буферизацию транзакций, зеркальный диск, автоматическое восстановление после системных сбоев, большую скорость (в 2-4 раза).


 <dd>Њодуль Informix-Star ЯвлЯетсЯ средством поддержки работы с распределенными базами данных. Џосредством модулЯ InformixStar осуществлЯетсЯ оперативнаЯ обработка транзакций.


 <dd>ђабота сервера Informix заключаетсЯ в запуске специальной программы (SQLEXEC длЯ Informix-SE и SQLTURBO длЯ Informix-OnLine), котораЯ обеспечивает работу всех SQL-операторов. „лЯ каждого клиента запускаетсЯ процесс операционной системы, использующий эту программу. ‚ случае, если клиент прервал работу, но не вышел из своей задачи, то его процесс занимает ресурсы системы, снижаЯ ее производительность.

 <dd><IMG SRC="informix_3.gif" WIDTH=363 HEIGHT=319>


 <dd>Ћдним из последних достижений фирмы стал выпуск нового сервера базы данных OnLine Dynamic Server, которой входит в состав системы начинаЯ с версии 6.0. ќтот продукт основан на так называемой „инамической Њасштабируемой Ђрхитектуре (Dynamically Scalable Architecture - DSA), котораЯ специально ориентирована на работу с многопроцессорными системами. OnLine Dynamic Server обеспечивает повышение производительности за счет гибкости использованиЯ ресурсов ‘“Ѓ„, использование многопоточной архитектуры. ”актически OnLine Dynamic Server берет на себЯ многие свЯзанные с распределением ресурсов функции операционной системы. ‚ результате уменьшаетсЯ нагрузка на операционную системы, что в конечном счете приводит к росту производительности.

 <dd><IMG SRC="informix_4.gif" WIDTH=363 HEIGHT=206>


 <dd><A NAME="_Toc408113420">„лЯ обслуживаниЯ клиентов запускаютсЯ "виртуальные процессоры" - процессы операционной системы, которые устанавливают свЯзь между клиентом и Ядром Informix. ‘вЯзь устанавливаетсЯ с помощью специальных "нитей" (thread), которые активизируютсЯ только если клиент активен и обращаетсЯ к серверу базы данных. ‚ случае, если клиент неактивен, "нить" может обслуживать других клиентов.


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


 <dd>‚ версии 6.0 сетевые функции заложены в Ядре ‘“Ѓ„. Џоэтому длЯ функционированиЯ в сети OnLine Dynamic Server модули Informix-Net или Informix-Star не требуютсЯ.

 <dd><B><I>2.2 Ђрхитектура ‘“Ѓ„ сервера Informix OnLine v.7.X</A></B>
</I>


 <dd>Љ ‘“Ѓ„, претендующим на роль информационной основы современных предприЯтий, предъЯвлЯютсЯ все новые и более жесткие требованиЯ. Љ числу важнейших можно отнести следующие:


<UL>

<UL>

 <dd><LI>высокаЯ производительность </LI>

 <dd><LI>масштабируемость </LI>

 <dd><LI>смешаннаЯ загрузка сервера разными типами задач</LI>

 <dd><LI>непрерывнаЯ доступность данных </LI></UL>
</UL>


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


 <dd><A NAME="_Toc408113421">2.2.1 . „инамическаЯ масштабируемаЯ архитектура</A>


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


<UL>

<UL>

 <dd><LI>снижение нагрузки на операционную систему (число серверных процессов невелико); </LI>

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

 <dd><LI>снижение конкуренции при одновременном использовании системных ресурсов; </LI>

 <dd><LI>более рациональное по сравнению с Ћ‘ назначение приоритетов и планирование; </LI></UL>
</UL>


 <dd>„лЯ многопроцессорных платформ:


<UL>

<UL>
>

 <dd><LI>равномернаЯ загрузка наличных процессоров; </LI>

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

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


 <dd>ђис. 1. Њодель "один клиент - один серверный процесс".


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


 <dd>Ђрхитектура DSA полностью использует возможности симметричных многопроцессорных платформ SMP (Symmetric Multiprocessing systems), и может работать на однопроцессорных платформах. ‚ последующих версиЯх предполагаетсЯ расширить архитектуру сервера, обеспечив поддержку слабосвЯзанных систем и систем с массовым параллелизмом (MPP). ‚се базовые технологии DSA ЯвлЯютсЯ встроенными, они включены в библиотеки сервера, и их применение не зависит от особенностей Ћ‘ или аппаратных платформ различных поставщиков.

 <dd><B>2.2.1.1  <A NAME="_Toc408113422">Џотоки</A></B>


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

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

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


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


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


 <dd><B><A NAME="_Toc408113423">2.2.1.2 ‚иртуальные процессоры</A></B>


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

 <dd>‚иртуальные процессоры (‚Џ) ЯвлЯютсЯ специализированными - они подразделЯютсЯ на классы в соответствии с типом потоков, длЯ выполнениЯ которых они предназначены. Џримеры классов ‚Џ:

 <dd>CPU - Џотоки обслуживаниЯ клиентов, реализуют оптимизацию и логику выполнениЯ запросов. Љ этому классу относЯтсЯ и некоторые системные потоки.

 <dd>AIO - Ћперации асинхронного обмена с диском.

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

 <dd>TLI - Љонтроль сетевого взаимодействиЯ посредством интерфейса TLI (Transport Layer Interface).

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

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

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


 <dd><B>2.2.1.3  <A NAME="_Toc408113424">Џланирование потоков</A></B>


 <dd>‘ервер осведомлен о степени значимости различных потоков и в соответствии с этим назначает длЯ них приоритеты. Ќапример, потоки ввода-вывода получают приоритеты следующим образом:


<UL>

<UL>

 <dd><LI>ввод-вывод логической журнализации - наивысший приоритет; </LI>

 <dd><LI>ввод-вывод физической журнализации - второй по значимости приоритет; </LI>

 <dd><LI>прочие операции ввода-вывода- низший приоритет. </LI></UL>
</UL>


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

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

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


<UL>

<UL>

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

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


 <dd><B>2.2.1.4  <A NAME="_Toc408113425">ђазделение потоков между виртуальными процессорами.</A></B>


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


<UL>

<UL>

 <dd><LI>Ћчередь готовых к выполнению потоков. </LI>

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

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


 <dd>…сли выполнЯемый поток завершаетсЯ, засыпает или откладываетсЯ, то освободившийсЯ вирт