4.9 Мультисерверная среда

Мультисерверное администрирование позволяет создавать задания (jobs) и планы обслуживания (maintenance plans) в одном месте, на сервере, именуемом master. Все задания и планы обслуживания, созданные на master-сервере, могут быть выполнены на любом сервере, указанном для него как подчинённые сервера. Состояние таких заданий также может быть проверено на master-сервере. Использование мультисерверного администрирования позволяет централизовать администрирование на одном SQL сервере. Ценность мультисерверного администрирования зависит в значительной степени от того, сколько SQL серверов им охватывается и сколько заданий и/или планов обслуживания будет сосредоточено на центральном сервере.

Для организации мультисерверного администрирования необходимо иметь минимум два SQL сервера. Один сервер будет выбран как master или MSX, а другие будем обозначать, как подчинённые сервера или TSX. Автору не известно предельное количество подчинённых серверов, которые может обслуживать один master - сервер. Однако существует ограничение, которое оговаривает, что подчинённый SQL Server может иметь только один master - сервер.

Настроить мультисерверное администрирование можно дважды щёлкнув мышкой по папке Management, щёлкнуть правой кнопкой по SQL Server Agent, выбирать Multi Server Administration и выбрать Make this a master. Активизируется визард, который создаст master - сервер и зарегистрирует подчинённые серверы, которые Вы укажете. Пройдите все шаги этого визарда и мультисерверное администрирование будет настроено. После этого Вы сможете добавлять задания и планы обслуживания. Первый экран мастера Make MSX Wizard запрашивает контактную информацию для специального оператора с именем MSXOperator. Это будет единственный оператор, который сможет получать уведомления от многосерверных заданий. Также, если планируется получать уведомления по электронной почте, каждый подчинённый сервер, с которого хотим посылать сообщения электронной почты, должен иметь почтовый профиль для SQL Server Agent. В теме каждого письма электронной почты будет указано, какой из подчинённых серверов послал Вам сообщение.

90 Разработка бизнес - логики базы данных

Разработка бизнес - логики базы данных. Хранимые процедуры и триггера

Как известно, классический подход к построению распределенных приложений предполагает наличие как минимум трех уровней: клиента, уровня бизнес логики и серверной части. В зависимости от расположения слоя бизнес – логики (на стороне сервера или на стороне клиента) можно говорить о так называемом «тонком» или «толстом» клиенте. Для случая, когда серверная бизнес логика размещена в базе данных, можно говорить, о таких инструментах, как хранимые процедуры и различные типы триггеров.

«Хранимые процедуры» - это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде и которые могут запускаться пользователями или приложениями, работающими с базой данных. Хранимые процедуры обычно пишутся либо на специальном процедурном расширении языка SQL (например, PL/SQL для ORACLE или Transact-SQL для MS SQL Server), или на некотором универсальном языке программирования, например, C++, с включением в код операторов SQL в соответствии со специальными правилами такого включения. Основное назначение хранимых процедур - реализация бизнес-процессов предметной области.

«Триггер» - это хранимая процедура, связанные с некоторыми событиями, происходящими во время работы базы данных, вызываемая в автоматическом режиме. В качестве таких событий выступают операции вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер связан. Очень важным является то, что пользователь не может обойти триггер. Триггер срабатывает независимо от того, кто из пользователей и каким способом инициировал событие, вызвавшее запуск триггера. Таким образом, основное назначение триггеров - автоматическая поддержка целостности базы данных. Триггеры могут быть как достаточно простыми, например, поддерживающими ссылочную целостность, так и довольно сложными, реализующими какие-либо сложные ограничения предметной области или сложные действия, которые должны произойти при наступлении некоторых событий. Например, с операцией вставки нового товара в накладную может быть связан триггер, который выполняет следующие действия - проверяет, есть ли необходимое количество товара, при наличии товара добавляет его в накладную и уменьшает данные о наличии товара на складе, при отсутствии товара формирует заказ на поставку недостающего товара и тут же посылает заказ по электронной почте поставщику.

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

91 Механизмы поддержания целостности в базе данных