Проблемы параллелизма

Лекция 8. Транзакции.

Особенности применения триггера

При использовании триггеров необходимо учитывать следующее:

· При внесении изменений в таблицу, триггеры выполняются в последнюю очередь, после проверки всякого рода связей и ограничений.

· Триггер может быть привязан только к одной таблице.

· У одной таблицы может быть много триггеров разных типов.

· Триггеры могут быть на добавление, изменение и удаление (insert, update, delete) в любых вариациях.

· Триггер вызывается на общую команду изменения данных в таблице, т.е. при вызове update для нескольких записей, он не будет выполняться для каждой записи отдельно, а всего один раз.

· Если в триггере изменяются данные по таблице, к которой привязан триггер, то вся группа триггеров по этой таблице выполняется повторно за исключением этого триггера (если в опциях сервера стоит метка "allow nested triggers").

· Писать триггеры надо так, чтобы не была важна последовательность их вызова.

Пример триггера, который выполняет проверку наличия необходимого товара на складе

CREATE TRIGGER Триггер_ins

ON Сделка FOR INSERT

AS

IF @@ROWCOUNT=1

BEGIN

IF NOT EXISTS(SELECT *

FROM inserted

WHERE inserted.количество<=ALL(SELECT

Склад.Остаток

FROM Склад,Сделка

WHERE Склад.КодТовара=

Сделка.КодТовара))

BEGIN

ROLLBACK TRAN

PRINT

'Отмена поставки: товара на складе нет'

END

END

Обеспечение параллелизма при реализации SQL-запросов. Понятие транзакций. Уровни изолированности транзакций. Распределенные транзакции. Методы управления транзакциями.

Современные СУБД являются многопользовательскими системами, т.е. допускают параллельную одновременную работу большого количества пользователей. При этом пользователи, как правило, не знают о том, работают ли с этими данными дркгие пользователи (или приложения). Для организации такой многопользоватеьской работы была определена логическая единица работы пользователя с БД –транзакция. Работа СУБД организуется таким образом, что у пользователя складывалось впечатление, что их транзакции выполняются независимо от транзакций других пользователей.

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