Модель сервера базы данных

 

Развитием RDA-модели стала модель сервера базы данных. Ее сердцевиной является механизм хра­нимых процедур. В отличие от RDA-модели, определенные для конкретной предметной области информационной системы события, правила и про­цедуры, описанные средствами языка SQL, хранятся вместе с данными на сервере системы и на нем же выполняются. Иначе говоря, прикладной компонент полностью размещается и вы­полняется на сервере системы. Схематично DBS-модель при­ведена на рис. 2.5.

На клиентских установках в DBS-модели размещается только интерфейсный компонент (компонент представления), что существенно снижает требования к вычислительной установке клиента. Пользователь через интерфейс системы на клиентской установке направляет на сервер базы дан­ных только лишь вызовы необходимых процедур, запросов и других функций по обработке данных. Все затратные операции по доступу и обработке данных выполняются на сервере и кли­енту направляются лишь результаты обработки, а не наборы данных, как в RDA-модели. Этим обеспечивается существен­ное снижение трафика сети в DBS-модели по сравнению с RDA-моделыо.

Следует, однако, заметить, что на сервере системы выпол­няются процедуры прикладных задач одновременно всех пользователей системы. В результате резко возрастают тре­бования к вычислительной установке сервера, причем как к объему дискового пространства и оперативной памяти, так и к быстродействию. Это основной недостаток DBS-модели.

К достоинствам же DBS-модели, помимо разгрузки сети, относится и более активная роль сервера сети, размещение, хранение и выполнение на нем механизма событий, правил и процедур, возможность более адекватно и эффективно “настра­ивать” распределенную информационную систему на все нюансы предметной обла­сти. Также более надежно обеспечивается согласованность состояния и изменения данных и, вследствие этого, повышается надежность хранения и обработки данных, эффек­тивно координируется коллективная работа пользователей с общими данными.

 

Модель сервера приложений

 

Чтобы разнести требования к вычислительным ресурсам сервера в отношении быстродействия и памяти по разным вы­числительным установкам, используется модель сервера при­ложений. Суть AS-модели заключается в переносе прикладно­го компонента информационной системы на специализированный в отношении по­вышенных ресурсов по быстродействию дополнительный сервер системы. Схема AS-модели приведена на рис. 2.6.

Как и в DBS-модели, на клиентских установках распола­гается только интерфейсная часть системы, т. е. компонент представления. Однако вызовы функций обработки данных на­правляются на сервер приложений, где эти функции совместно выполняются для всех пользователей системы. За выполнени­ем низкоуровневых операций по доступу и изменению данных сервер приложений, как в RDA-модели, обращается к SQL-сер­веру, направляя ему вызовы SQL-процедур, и получая, соответ­ственно, от него наборы данных. Как известно, последователь­ная совокупность операций над данными (SQL-инструкций), имеющая отдельное смысловое значение, называется транзак­цией. В этом отношении сервер приложений от клиентов сис­темы управляет формированием транзакций, которые выпол­няет SQL-сервер. Поэтому программный компонент СУБД, ин­сталлируемый на сервере приложений, еще называют также монитором обработки транзакций (Transaction Processing Monitors – TRM), или просто монитором транзак­ций.

AS-модель, сохраняя сильные стороны DBS-модели, позво­ляет более оптимально построить вычислительную схему ин­формационной системы, однако, как и в случае RDA-модели, повышает трафик сети.

В еще не устоявшейся до конца терминологии по моделям и технологиям “Клиент-сервер” RDA-модель характеризуют еще как модель с так называемыми “толстыми”, а DBS-модель и AS-модель как модели, соответственно, с “тонкими” клиен­тами. По критерию звеньев системы RDA-модель и DBS-мо­дель называют двухзвенными (двухуровневыми) системами, а AS-модель трехзвенной (трехуровневой) системой.

В практических случаях используются смешанные моде­ли, когда простейшие прикладные функции и обеспечение ог­раничений целостности данных поддерживаются хранимыми на сервере процедурами (DBS-модель), а более сложные функ­ции предметной области (так называемые правила бизнеса) реализуются прикладными программами на клиентских уста­новках (RDA-модель) или на сервере приложений (AS-модель).

 

Мониторы транзакций

 

Основой эффективности функционирова­ния многопользова-тельских систем “Клиент-сервер” является эффективное управление транзакциями. Собственно само понятие транзакции возникло именно в процессе исследования принципов построения и функционирования централизованных многопользовательских реляционных СУБД. Транзакции игра­ют важную роль в механизме обеспечения СУБД ограничений целостности базы данных. Ограничения целостности непос­редственно проверяются по завершению очередной транзакции. Если условия ограничений целостности данных не выполня­ются, то происходит “откат” транзакции (выполняется SQL-инструкция ROLLBAСК), в противном случае транзакция фик­сируется (выполняется SQL-инструкция COMMIT).

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

потерянные изменения;

“грязные” данные;

неповторяющиеся чтения.

Потерянные изменения возникают тогда, когда две тран­закции одновременно изменяют один и тот же объект базы данных. В том случае, если в силу каких-либо причин, напри­мер, из-за нарушений целостности данных, происходит откат, скажем, второй транзакции, то вместе с этим отменяются и все изменения, внесенные в соответствующий период времени пер­вой транзакцией. В результате первая еще не завершившаяся транзакция при повторном чтении объекта не “видит” своих ранее сделанных изменений данных. Очевидным способом пре­одоления подобных ситуаций является запрет изменения дан­ных любой другой транзакцией до момента завершения пер­вой транзакции – так называемая блокировка объекта.

“Грязные” данные возникают тогда, когда одна транзак­ция изменяет какой-либо объект данных, а другая транзакция в этот момент читает данные из того же объекта. Так как первая транзакция еще не завершена и, следовательно, не про­верена согласованность данных после проведенных или вовсе еще только частично проведенных изменений, то вторая тран­закция может “видеть” соответственно несогласованные, т. е. “грязные” данные. Опять-таки способом недопущения таких ситуаций может быть запрет чтения объекта любой другой транзакцией, пока не завершена первая транзакция, его изме­няющая.

Неповторяющиеся чтения возникают тогда, когда одна транзакция читает какой-либо объект базы данных, а другая до завершения первой его изменяет и успешно фиксируется. Если при этом первой, еще не завершенной, транзакции требу­ется повторно прочитать данный объект, то она “видит” его в другом состоянии, т. е. чтение не повторяется. Способом недо­пущения подобных ситуаций в противоположность предыду­щему случаю является запрет изменения объекта любой дру­гой транзакцией, когда первая транзакция на чтение еще не за­вершена.

Механизм изоляции транзакций и преодоления ситуаций несогласованной обработки данных в общем виде основывает­ся на технике сериализации транзакций. План (способ) выполнения совокупности транзакций называется сериальным, если результат совместного выполнения транзакций эквива­лентен результату некоторого последовательного их выпол­нения. Сериализацией транзакций в этом смысле является орга­низация их выполнения по некоторому сериальному плану. Существуют два различных подхода сериализации транзакций:

 синхронизационные захваты (блокировки) объектов базы данных;

 временные метки объектов базы данных.

В первом подходе определяется два основных режима зах­ватов – совместный режим (Shared) и монопольный режим (eXclusive). При совместном режиме осуществляется разделя­емый захват, требующий только операций чтения. Поэтому та­кой захват еще называют захватом по чтению. При монополь­ном режиме осуществляется неразделяемый захват, требующий операций обновления данных. Такой захват, соответственно, еще называют захватом по записи.

Наиболее распространенным вариантом первого подхода является реализация двухфазного протокола синхронизаци­онных захватов (блокировок) объектов базы данных – 2PL (Two-Phase Locks). В соответствии с данным протоколом выполнение транзакции происходит в два этапа. На первом этапе (первая фаза) перед выполнением любой операции транзакция запрашивает и накапливает захваты необходимых объектов в со­ответствующем режиме. После получения и накопления необхо­димых захватов (блокировок) осуществляется вторая фаза – фиксация изменений (или откат по соображениям целостности данных) и освобождение захватов.

При построении сериальных планов допускается совме­щение только захватов по чтению. В остальных случаях тран­закции должны “ждать”, когда необходимые объекты разбло­кируются (освободятся). Более изощренные стратегии сериа­лизации транзакций основываются на “гранулировании” объектов захвата (файл базы данных, отдельная таблица, стра­ница файла данных, отдельная запись-кортеж). Соответствен­но при этом расширяется номенклатура синхронизационных режимов захватов, например, в совместном режиме (по чте­нию) может быть захвачен и в целом файл и отдельные его стра­ницы, или в другом случае обеспечивается совместный режим захвата файла с возможностью монопольного захвата отдель­ных его объектов – таблиц, страниц или записей-кортежей). Грануляция синхронизационных блокировок позволяет строить более эффективные планы сериализации транзакций.

Существенным недостатком синхронизационных захва­тов является возможность возникновения тупиковых ситуа­ций (Deadlock). Предположим, одна транзакция на первой фазе установила монопольный захват одного объекта, а другая тран­закция монопольный захват второго объекта. Для осуществле­ния полного набора своих операций первой транзакции еще тре­буется совместный захват второго объекта, а второй транзак­ции, соответственно, совместный захват первого объекта. Ни одна из транзакций не может закончить первую фазу, т. е. пол­ностью накопить все необходимые захваты, так как требуемые объекты уже монопольно захвачены, хотя были свободны к мо­менту начала осуществления транзакций.

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

Еще одной проблемой является технология, или, лучше сказать, алгоритм разрушения тупиков. В общем плане такие алгоритмы основываются на выборе транзакции-жертвы, ко­торая временно откатывается для предоставления возможнос­ти завершения выполнения операций другим транзакциям, что, конечно же, в определенной степени нарушает принцип изоли­рованности пользователей. В качестве “жертвы” выбирается или самая “дешевая” транзакция, в смысле затрат на выполнение, или транзакция с наименьшим приоритетом.

Более простой альтернативой технике синхронизационных захватов является техника временных меток. Суть этого ме­тода заключается в том, что каждой транзакции приписывает­ся временная метка, соответствующая моменту начала вы­полнения транзакции. При выполнении операции над объектом транзакция “помечает” его своей меткой и типом операции (чтение или изменение). Если при этом другой транзакции тре­буется операция над уже “помеченным” объектом, то выполня­ются действия по следующему алгоритму:

 проверяется, не закончилась ли транзакция, первой “по­метившая” объект;

 если первая транзакция закончилась, то вторая транзак­ция помечает его своей меткой и выполняет необходимые опе­рации;

 если первая транзакция не закончилась, то проверяется конфликтность операций (напомним, что конфликтно любое сочетание, кроме “чтение-чтение”);

 если операции неконфликтны, то они выполняются для обеих транзакций, а объект до завершения операций помечает­ся меткой более поздней, т. е. более молодой транзакции;

 если операции конфликтны, то далее происходит откат более поздней транзакции и выполняется операция более ран­ней (старшей) транзакции, а после ее завершения объект поме­чается меткой более молодой транзакции и цикл действий по­вторяется.

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

СУБД идеологии “Клиент-сервер”, называемые иногда в противовес однопользовательским (“настольным”) “тяжелыми” системами (Oracle, SyBase, Informix, Ingres и др.), составляют одно из наиболее интенсивно развивающихся направлений цен­трализованных многопользова-тельских систем, охватывая сво­им управлением сотни тысяч гигабайтов дан­ных, и в этом отношении еще долгое время будут играть роль фактического стандарта корпоративных информационных си­стем.