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

Ћцените этот текст:
‚иктор Љустов. Informix. ђуководство администратора баз данных

---------------------------------------------------------------
 Email: visor@olma.co.ru
---------------------------------------------------------------


 1. ’еоретические основы. *

 
1.1 ЏонЯтие ‘“Ѓ„ сервера. *

 
1.1.1 Ћсновные функции ‘“Ѓ„ *

 
1.1.2 ’иповаЯ организациЯ современной ‘“Ѓ„ *

 
1.2 ЏонЯтие архитектуры клиент-сервер. *

 
2. ’еоретические основы ‘“Ѓ„ сервера Informix OnLine v.7.X *

 
2.1 ‘“Ѓ„ сервер Informix. *

 
2.2 Ђрхитектура ‘“Ѓ„ сервера Informix OnLine v.7.X *

 
2.2.1 . „инамическаЯ масштабируемаЯ архитектура *

 
2.2.1.1 Џотоки *

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

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

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

 
2.2.1.5 ќкономиЯ памЯти и других ресурсов *

 
2.2.2 ЋрганизациЯ разделЯемой памЯти *

 
2.2.3 ЋрганизациЯ операций обмена с дисками *

 
2.2.3.1 “правление дисковой памЯтью *

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

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

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

 
2.2.5 ЏараллельнаЯ обработка запросов *

 
2.2.5.1 Ќа чем основана технологиЯ PDQ *

 
2.2.5.2 €тераторы *

 
2.2.5.3 Џримеры применениЯ параллелизма *

 
2.2.5.4 Ѓаланс между OLTP и DSS-приложениЯми *

 
2.2.6 Ћптимизатор выполнениЯ запросов по стоимости *

 
2.2.7 ‘редства обеспечениЯ надежности *

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

 
2.2.7.2 ’иражирование *

 
2.2.7.3 Ѓыстрое восстановление при включении системы *

 
2.2.7.4 Ђрхивирование и восстановление данных *

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

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

 
2.2.8.2 “тилита DB/Cockpit *

 
2.2.8.3 “тилита OnPerf *

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

 
2.2.9 ђаспределенные вычислениЯ *

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

 
2.2.9.2 Џрозрачность расположениЯ данных *

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

 
2.2.10 Џоддержка национальных Языков *

 
2.2.11 ‘редства безопасности класса ‘2 *

 
2.3 „ополнительные компоненты компании Informix длЯ выполнениЯ специфических задач. *

 
2.3.1 Informix-Enterprise Gateway 7.1 *

 
2.3.2 ’ехнологиЯ и компоненты EDA/SQL *

 
2.3.2.1 EDA API/SQL *

 
2.3.2.2 EDA/Link *

 
2.3.2.3 EDA/SQL Server *

 
2.3.2.4 EDA/Data Drivers *

 
2.3.3 ‚озможности Enterprise Gateway *

 
2.3.3.1 Џрозрачный доступ длЯ чтениЯ и записи *

 
2.3.3.2 ђаспределенные соединениЯ *

 
2.3.3.3 Љонфигурирование Enterprise Gateway *

 
2.3.3.4 Ѓезопасность *

 
2.3.4 Ѓиблиотеки сопрЯжениЯ сервера Informix-OnLine DS с менеджерами транзакций: Informix-TP/XA и Informix-TP/TOOLKIT *

 
2.4 ‡аключение *

 
2.5 ‹итература *



 
1. ’еоретические основы.

 
1.1 ЏонЯтие ‘“Ѓ„ сервера.




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



 
1.1.1  Ћсновные функции ‘“Ѓ„



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



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



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

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



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



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



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



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

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

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



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



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



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

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

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

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

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

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



 
5. џзыки Ѓ„



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

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

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

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

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

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



 
1.1.2 ’иповаЯ организациЯ современной ‘“Ѓ„



 
…стественно, организациЯ типичной ‘“Ѓ„ и состав ее компонентов соответствует рассмотренному нами набору функций.

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

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

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

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

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

 
1.2 ЏонЯтие архитектуры клиент-сервер.




 
‚ подавлЯющем большинстве случаев локальнаЯ сеть используетсЯ длЯ коллективного доступа к базам данных.

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

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

 
    ЋпределениЯ:

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

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

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

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

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



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

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

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

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

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



 
2.1 ‘“Ѓ„ сервер Informix.




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



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



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



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



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



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



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



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



 




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



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



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



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

 




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



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



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



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



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

 




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

 




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



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



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

 
2.2 Ђрхитектура ‘“Ѓ„ сервера Informix OnLine v.7.X




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







 высокаЯ производительность 

 
масштабируемость 

 
смешаннаЯ загрузка сервера разными типами задач

 
непрерывнаЯ доступность данных 




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



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



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







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

 
сокращение совокупной потребности клиентов в оперативной памЯти; 

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

 
более рациональное по сравнению с Ћ‘ назначение приоритетов и планирование; 




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






>

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

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


 




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



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



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

 
2.2.1.1  Џотоки



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

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

 






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



 
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). 




 




 
ђис.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  €тераторы



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



 




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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 




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



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

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

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



 
2.2.5.3  Џримеры применениЯ параллелизма



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

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

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

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

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

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

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

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



 
2.2.5.4  Ѓаланс между OLTP и DSS-приложениЯми



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

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

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

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

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

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

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

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

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







 устанавливает приоритет каждого запроса; 

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

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

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




 
2.2.6  Ћптимизатор выполнениЯ запросов по стоимости



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

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

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

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



 
2.2.7  ‘редства обеспечениЯ надежности



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







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

 
Џолное тиражирование данных сервера 

 
Ѓыстрое восстановление при включении системы 

 
‘редства архивированиЯ данных 




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



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

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

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

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

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



 
2.2.7.2  ’иражирование



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

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

 




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



 




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



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







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

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




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

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

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







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

 
возможность вынести приложениЯ 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.



 
2.3 „ополнительные компоненты компании Informix длЯ выполнениЯ специфических задач.


 
2.3.1 Informix-Enterprise Gateway 7.1



 
люз INFORMIX-Enterprise Gateway обеспечивает длЯ инструментальных средств и приложений баз данных, выполнЯемых под управлением операционной системы UNIX или Microsoft Windows, доступ к информации, хранЯщейсЯ в базах данных разных типов. „оступ реализуетсЯ при помощи комплекта программных продуктов Enterprise Data Access SQL (EDA/SQL) фирмы Information Builders, Inc.

 
Ћсновные возможности шлюза INFORMIX-Enterprise Gateway:







 Ѓолее 60 типов релЯционных и нерелЯционных источников данных на 35 различных аппаратных платформах. ‘реди поддерживаемых источников данных - IMS, VSAM, CA-IDMS, Adabas, Oracle, Sybase, Ingres. Џоддерживаемые операционные системы - UNIX, MVS, VM, VMS. 

 
Ђрхитектура клиент/сервер. 

 
Џрозрачный доступ посредством интерфейса SQL или удаленных вызовов процедур. 

 
Џоддержка стандартов ANSI-92 SQL и ANSI-89 SQL. 

 
ђоллируемые курсоры. 

 
€мпорт данных из разнородных источников в базы данных INFORMIX. 

 
ђаспределенные соединениЯ таблиц из разнородных баз данных. 

 
‘редства безопасности. 




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



 
2.3.2 ’ехнологиЯ и компоненты EDA/SQL



 
’ехнологиЯ EDA/SQL фирмы Information Builders, Inc. позволЯет осуществлЯть доступ средствами SQL не только к релЯционным, но и к нерелЯционным источникам данных, таким как иерархические базы данных и файлы с определенной структурой записей (record-oriented files), характерные длЯ мейнфреймов. Љо всем данным, независимо от формата, обеспечиваетсЯ унифицированный релЯционный интерфейс. ’ехнологиЯ EDA/SQL позволЯет также производить соединениЯ данных из разнородных источников.

 
’ехнологиЯ EDA/SQL основана на архитектуре клиент/сервер. Ћна включает четыре ключевых компоненты, необходимые длЯ полного функционированиЯ шлюза Enterprise Gateway.



 
2.3.2.1 EDA API/SQL



 
Џродукт встроен в Enterprise Gateway.

 
EDA API/SQL - библиотека клиентской части, котораЯ обеспечивает интерфейс уровнЯ вызовов, определенный фирмой Information Builders, Inc. Џосредством этого интерфейса приложение клиента выполнЯет инструкции SQL или удаленные вызовы процедур.

 
2.3.2.2 EDA/Link



 
Џродукт встроен в Enterprise Gateway.

 
EDA/Link - интерфейс обмена запросами между клиентами и серверами EDA. €нтерфейсы EDA/Link поддерживают коммуникационные протоколы, формируют пакеты запросов и ответов, производЯт аутентификацию пользователей по паролЯм, преобразуют данные и выЯвлЯют ошибки передачи.



 
2.3.2.3 EDA/SQL Server



 
Ќезависимый продукт, доступный от фирмы Information Builders, Inc.

 
EDA/SQL Server - многопотоковый сервер баз данных, который управлЯет выделением и соединением данных из релЯционных и нерелЯционных источников. EDA/SQL Server управлЯет процессами на хостмашинах. Ћн управлЯет входным потоком запросов данных, инициализирует подпроцессы длЯ интерпретации и транслЯции запросов, вызывает и маршрутизирует хранимые процедуры, используЯ удаленные вызовы процедур, маршрутизирует вывод и осуществлЯет бюджетные функции и функции безопасности между сетевыми серверами.

 
Enterprise Gateway поддерживает EDA/SQL Server версии 2.2 и выше.



 
2.3.2.4 EDA/Data Drivers



 
Ќезависимые продукты, доступные от фирмы Information Builders, Inc.

 
„райверы EDA/Data Drivers отображают запросы SQL или RPC, сгенерированные приложением клиента, на тот Язык, который используетсЯ на целевом источнике данных. Ќапример, длЯ SQL-запроса к базе данных IMS драйвер данных IMS сформирует последовательность вызовов на Языке DL/L, и отошлет клиенту полученный ответ.



 
2.3.3 ‚озможности Enterprise Gateway



 
Enterprise Gateway ЯвлЯетсЯ процессом сервера баз данных INFORMIX, который конвертирует запросы клиентов INFORMIX в запросы EDA/SQL.

 
Љогда от клиентского приложениЯ поступает инструкциЯ SQL или удаленный вызов процедуры, предназначенный длЯ Enterprise Gateway, то он просто перенаправлЯетсЯ на EDA/SQL Server, который затем обращаетсЯ к соответствующим релЯционным или нерелЯционным источникам данных. Ћтветы и данные, полученные от EDA/SQL Server, Enterprise Gateway возвращает приложению клиента.



 
2.3.3.1 Џрозрачный доступ длЯ чтениЯ и записи



 
Enterprise Gateway представлЯет собой единый шлюз, который обеспечивает прозрачный доступ к данным в масштабах предприЯтиЯ. Љонечные пользователи обращаютсЯ к Enterprise Gateway так же, как к серверу баз данных INFORMIX. „оступ на чтение и запись осуществлЯетсЯ посредством стандартных инструкций SQL или удаленных вызов процедур (RPC - Remote Procedure Call).

 
„лЯ SQL поддерживаютсЯ оба стандарта синтаксиса - ANSI-92 SQL и ANSI-89 SQL; текущаЯ версиЯ EDA/SQL поддерживает синтаксис ANSI-89 SQL.

 
„оступ посредством RPC обеспечиваетсЯ длЯ инструментов разработки и приложений INFORMIX, а также третьих фирм. “даленные вызовы процедур EDA/SQL выглЯдЯт как обращениЯ к хранимым процедурам, поэтому длЯ их использованиЯ в приложениЯ требуетсЯ внести лишь минимальные изменениЯ. RPC позволЯют выполнЯть операции чтениЯ и записи и возвращать многострочные результаты.

 
„лЯ обработки многострочных наборов данных, полученных в результате выполнениЯ RPC или инструкции SQL, в Enterprise Gateway поддерживаетсЯ механизм роллируемых курсоров (scroll cursors), который позволЯет осуществлЯть прЯмой и обратный просмотр наборов данных.



 
2.3.3.2 ђаспределенные соединениЯ



 
Enterprise Gateway может участвовать в распределенных соединениЯх, координируемых сервером баз данных INFORMIX. ќто позволЯет импортировать в базы данных INFORMIX и/или интегрировать с ними данные из разнородных внешних источников.



 
2.3.3.3 Љонфигурирование Enterprise Gateway



 
Enterprise Gateway прост в конфигурировании. ‘оединение клиента с Enterprise Gateway конфигурируетсЯ точно так же, как соединение между клиентской частью приложениЯ INFORMIX и сервером INFORMIX-OnLine DS или INFORMIX-SE. Ќапример, приложение под MS Windows, созданное инструментом разработки INFORMIX-NewEra, конфигурируетсЯ одинаково, независимо от того, обращаетсЯ ли оно к серверу баз данных INFORMIX или к Enterprise Gateway.



 
Enterprise Gateway выполнЯетсЯ под управлением операционной системы UNIX и должен иметь доступ к EDA/SQL Server через сеть TCP/IP. ‘оединение Enterprise Gateway и EDA/SQL Server конфигурируетсЯ при помощи обычных конфигурационных файлов TCP/IP и конфигурационного файла EDA/Link.



 
2.3.3.4 Ѓезопасность



 
Enterprise Gateway поддерживает централизованное управление пользовательскими идентификаторами (ID) и паролЯми, отображаЯ их из среды INFORMIX в среду EDA/SQL. EDA/SQL Server обеспечивает безопасность путем взаимодействиЯ с подсистемами безопасности соответствующих Ћ‘. Ќапример, в MVS осуществлЯетсЯ взаимодействие с подсистемами безопасности RACF, ACF2 и CA-Top Secret.



 
2.3.4 Ѓиблиотеки сопрЯжениЯ сервера Informix-OnLine DS с менеджерами транзакций: Informix-TP/XA и Informix-TP/TOOLKIT



 
‚ состав инструментального продукта INFORMIX-ESQL/C входит библиотека C-программ INFORMIX-TP/XA. ќта библиотека обеспечивает длЯ приложений, построенных при помощи INFORMIX-ESQL/C, сопрЯжение сервера INFORMIX-OnLine DS с менеджерами транзакций, основанными на стандарте X/Open-XA, например, TUXEDO System/T. Ђналогичную возможность обеспечивает библиотека 4GL-функций INFORMIX-TP/Toolkit длЯ приложений на основе INFORMIX-4GL. ’акое сопрЯжение позволЯет организовать участие сервера INFORMIX в разнородных распределенных транзакциЯх с серверами баз данных других поставщиков, поддерживающих стандарт X/Open-XA, и использовать прочие преимущества, которые предоставлЯют современные менеджеры транзакций:







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

 
Џерераспределение и баланс загрузки, максимально эффективное использование системных ресурсов. 

 
Њасштабируемость и динамическое переконфигурирование прикладной среды с учетом изменЯющихсЯ потребностей. 

 
Ћбеспечение высокой доступности путем перенаправлениЯ запросов к дублирующим серверам в случае отказа.




 
2.4 ‡аключение




 
…сли рассматривать создание и развитие информационной системы (€‘) как исторический процесс, то оценка ‘“Ѓ„ как базиса длЯ созданиЯ или развитиЯ €‘ может проводитьсЯ по трем направлениЯм:







 Љаковы перспективы ее использованиЯ в будущем? 

 
„опускает ли ‘“Ѓ„ взаимодействие с унаследованными базами данных и компьютерными платформами? 

 
Љаковы потребительские качества существующей версии ‘“Ѓ„? 




 
‚заимодействие с унаследованными базами данных обеспечивает шлюз INFORMIX-Enterprise Gateway.

 
Џродукты последней версии INFORMIX обладают высокими потребительскими качествами. Џеречислим основные из них.

 
‚ысокаЯ производительность

 
…е увеличению способствуют следующие свойства и оптимизирующие механизмы сервера INFORMIX-OnLine DS:







 ЊногопотоковаЯ архитектура 

 
ЏараллельнаЯ обработка 

 
”рагментациЯ таблиц и индексов 

 
ЋптимизациЯ выполнениЯ запросов 

 
ђазделЯемаЯ памЯть 

 
Љеши словарей данных и хранимых процедур 

 
‘обственное управление дисковой памЯтью 

 
Ђсинхронный ввод-вывод 

 
Ћпережающее чтение 




 
‚ысокаЯ производительность на приложениЯх OLTP, DSS, пакетных заданиЯх и их сочетаниЯх подтверждаетсЯ тестами TPC (Transaction processing Performamce Council), особенно на многопроцессорных платформах.

 
Њасштабируемость

 
ќтим термином обозначаетсЯ такое свойство сервера, которое обеспечивает при увеличении доступных вычислительных ресурсов (количества или быстродействиЯ процессоров, числа дисков) соответствующее улучшение системных характеристик. Џод улучшением системных характеристик понимаетсЯ, например,







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

 
ускорение обработки одного запроса; 

 
сохранение того же времени обработки запроса при увеличении объема участвующих в нем таблиц. 




 
Џеречислим свойства и механизмы сервера, обеспечивающие масштабируемость:







 ЊногопотоковаЯ архитектура с поддержкой многопроцессорной обработки. Ћбслуживание клиентов равномерно распределЯетсЯ между всеми наличными процессорами. 

 
’ехнологиЯ PDQ. ‚ыполнение сложного запроса распределЯетсЯ между всеми наличными процессорами. ђезультаты тестов показывают линейное ускорение обработки при увеличении числа процессоров. 

 
”рагментациЯ таблиц. Ћбработка больших таблиц ускорЯетсЯ пропорционально числу фрагментов, располагаемых на разных дисковых устройствах. 

 
ѓибкие средства наблюдениЯ и настройки. „опускаетсЯ динамическое изменение объема и конфигурации ресурсов, используемых сервером - числа виртуальных процессоров, дисковых пространств баз данных. ‚ соответствии с наличием ресурсов и потребностЯми можно оперативно регулировать интенсивность параллельной обработки, изменЯть правила фрагментации таблиц. •Џоддержка распределенных транзакций. Џроизводительность €‘ может наращиватьсЯ путем распределениЯ данных и их обработки между несколькими серверами, свЯзанными сетью. 




 
“ниверсальность сервера

 
‚озможность смешанной загрузки его приложениЯми OLTP, DSS и пакетными заданиЯми, обеспечиваетсЯ средствами параллельной обработки сложных запросов и средствами оперативной настройки, которые позволЯют управлЯть балансом системных ресурсов между разными типами приложений.

 
ЏрактическаЯ осуществимость смешанной загрузки поддерживаетсЯ также всеми механизмами, направленными на эффективное разделение ресурсов и повышение производительности, поскольку без этого невозможно проводить обработку трудоемких запросов, сохранЯЯ приемлемое времЯ отклика длЯ приложений OLTP.

 
‚ысокаЯ доступность данных

 
„анные становЯтсЯ недоступны пользователЯм, если произошел программный или аппаратный сбой, а также если сервер остановлен с целью выполнениЯ определенных административных действий. ‘ервер INFORMIX-OnLine DS обладает рЯдом возможностей, которые позволЯют повысить надежность €‘ и практически отказатьсЯ от плановых простоев:







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

 
Џолное тиражирование данных сервера 

 
ђазвитые средства сохранениЯ данных 

 
‚осстановление некритичных длЯ работы сервера данных в оперативном режиме 

 
€нструменты слежениЯ за состоЯнием сервера 

 
‚ыполнение большинства административных задач, в том числе, настройки, в оперативном режиме 

 
”рагментациЯ таблиц (при отказе одного диска сохранЯетсЯ частичнаЯ доступность таблицы) 




 
”ункциональные возможности сервера

 
‘оответствуют входному уровню стандарта ANSI-92 SQL и включают, помимо рассмотренных выше, следующие средства:







 •ранимые процедуры 

 
’риггеры 

 
Љурсоры 

 
Љаскадные удалениЯ данных 

 
Џоддержка целостности, в том числе, целостности по ссылкам 

 
“ровни изолЯции чтениЯ: 



 грЯзное чтение 

 
подтвержденное чтение 

 
стабильное чтение 

 
повторЯемое чтение 

 
Џоддержка больших бинарных объектов (BLOB) 

 
Џоддержка оптических дисков 




 
‘редства безопасности

 
‚ сервере INFORMIX-OnLine DS эти средства соответствуют стандарту класса C2.

 
Ћткрытость

 
ќто сложное понЯтие, включающее оценки по многим направлениЯм. ‘тепень открытости определЯет степень интегрируемости ‘“Ѓ„ и продуктов, созданных на ее основе, в разнообразных аппаратных, программных, административных, национальных и др. средах, что чрезвычайно важно как длЯ построениЯ €‘ в настоЯщем, так и длЯ ее развитиЯ в будущем. Џеречислим некоторые свойства, характеризующие открытость INFORMIX:







 доступность на множестве платформ, включаЯ Sequent, HP, Sun, IBM, Siemens Nixdorf, NCR; 

 
поддержка, помимо UNIX, операционных систем Windows NT и NetWare; 

 
переносимость прикладных систем между платформами; 

 
возможность включениЯ баз данных INFORMIX в распределенные разнородные €‘, построенные на основе аппаратно-программных платформ и ‘“Ѓ„ разных производителей; 

 
интегрируемость INFORMIX с системами централизованного управлениЯ и администрированиЯ, такими как Tivoli Management Environment (TME), HP OpenView, IBM NetView; 

 
поддержка национальных Языков. 




 
‘редства разработки

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

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







 ђазвитие архитектуры сервера длЯ обеспечениЯ поддержки платформ MPP, а также слабосвЯзанных систем. 

 
ђеализациЯ дискретного тиражированиЯ на уровне отдельных таблиц и других подмножеств данных. 

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




 
‘ущественное соображение при выборе продукта - стабильность, подтверждаемаЯ общим стажем и "запасом лидерства" компании, т. е. общей долей рынка. „олЯ INFORMIX на мировом рынке ‘“Ѓ„ - примерно 20%, в последние годы имеет тенденцию к росту.

 
‚се это позволЯет рассматривать INFORMIX как перспективную ‘“Ѓ„, котораЯ может служить основой длЯ построениЯ развитых €‘.



 
2.5  ‹итература




 
1. ѓ. ѓ. Ѓарон. Џараллельные архитектуры серверов баз данных. Jet Info, ‚ып. 1, 1995.

 
2. INFORMIX-OnLine Dynamic Server. Administrator's Guide, Vol. 1,2. Version 7.1. 1994, INFORMIX SoftWare Inc.

 
3. INFORMIX-OnLine Dynamic Server 6.0, 7.1. Training Course, 1993, 1994, INFORMIX SoftWare Inc.

 
4. INFORMIX-OnLine Enterprise Gateway Version 7.1. Technical Brief. 1994, INFORMIX SoftWare Inc.
Last-modified: Tue, 15 Sep 1998 12:44:51 GMT
Ћцените этот текст: