Отмена действия триггеров без их удаления

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

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

Для ввода в действие и отмены действия триггеров можно применить оператор ALTER TABLE. Для этого применяется следующий синтаксис:

ALTER TABLE <table name>

<ENABLE I DISABLE> TRIGGER <ALL<trigger name>>

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

Еще одно важное соображение состоит в следующем. Если происходит отмена действия триггеров для осуществления в той или иной форме массового импорта данных, то настоятельно рекомендуется закрыть сеансы всех пользователей и перейти в однопользовательский режим, в режим доступа только для владельца базы данных (dbo) или в режим, характеризующийся обоими указанными признаками. Это позволяет исключить возможность ввода в базу данных недопустимой информации посторонними людьми в тот период, когда триггеры не действуют.

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

Порядок запуска триггеров

SQL Server 7.0 Vn предьщущие версии не позволяли управлять порядком запуска триггеров. Как уже было сказано выше, до появления версии 7.0 допускалось единовременно применять только один триггер определенного типа (INSERT, UPDATE или DELETE), поэтому не было смысла вести речь о порядке запуска триггеров. Но в по-следующрхх версиях SQL Server был предусмотрен ограниченный объем средств контроля над тем, какие триггеры должны запускаться и в какой последовательности. Для каждой конкретной таблицы (но не представления, поскольку порядок запуска может быть задан только для триггеров AFTER, а представления допускают использование лишь триггеров INSTEAD OF) разрешалось выбрать один (и только один) триггер, запускаемый в первую очередь. Аналогичным образом была предусмотрена возможность выбрать один (и только один) триггер, запускаемый в последнюю очередь. Все

остальные триггеры рассматривались как не имеющие приоритета по отношению к порадку запуска. Иными словами, нельзя было гарантировать, в каком порядке будет запускаться триггер, для которого задан порядок запуска NONE (не определено). Известно было лишь, что такие триггеры (рис. 13.3) должны быть запущены после завершения первого триггера, FIRST (если он имеется) и до начала работы последнего триггера, LAST (также если он имеется).

Выполнение исходного оператора

завершается

Запуск и завершение работы триггера FIRST

Любой из этих триггеров может быть запущен в любое время после завершения работы триггера FIRST (порядок запуска может измениться), но их работа должна закончиться до того, как появится возможность запустить триггер LAST

Рис. 13.3. Определение порядка запуска триггеров

При создании триггера, который должен запускаться в первую или последнюю очередь, не предъявляются какие-либо особые требования по сравнению с любыми другими триггерами. Единственное различие между триггерами с точки зрения порядка их запуска состоит в том, что для них задаются разные значения приоритета запуска после их создания с использованием специальной системной хранимой процедуры sp settriggerorder.

Вызов хранимой процедуры sp settriggerorder имеет следующий синтаксис:

sp settriggerorder[©triggername =] <trigger name>, [©order =] {FIRST I LAST I NONE} , [©stmttype =] {INSERTUPDATEDELETE}

Для каждого конкретного действия (INSERT, UPDATE или DELETE) должен быть задан только один триггер, который рассматривается как имеющий обозначение FIRST . Аналогичным образом для каждого конкретного действия задается только

один триггер с обозначением LAST . А обозначение NONE может быть присвоено любому количеству триггеров.

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

Управление порядком запуска для обеспечения правильной реализации алгоритмов

В настоящем разделе рассматриваются основные причины, по которым может потребоваться обеспечить определенный порядок запуска триггеров. Необходимость обеспечить запуск одного триггера перед другим чаще всего может быть обусловлена тем, что с помощью ранее запущенного триггера закладывается своего рода фундамент или, вообще говоря, создаются предпосылки осуществления дальнейших действий. При эксплуатации SQL Server 6.5 и предьщущргх версий в основном не прргходилось задумываться о подобных проблемах, поскольку для каждой конкретной таблицы разрешалось задавать только по одному триггеру каждого конкретного типа (UPDATE, DELETE или INSERT). Из этого следовало, что фактически не составляло труда обеспечить запуск триггера одного типа прежде друтого. А поскольк) в триггере были реализованы все связанные с его использованием алгоритмы обработки, достаточно бьыо предусмотреть в коде триггера выполнение в первую очередь тех операций, которые должны стоять на первом месте, а операции, выполняемые в последнюю очередь, поместить на последнее место (таким образом, значительные сложности не возникали).

После выхода версии 7.0 положение дел одновременно и улучшилось, и ухудшилось. С одной стороны, отпала необходимость помещать весь код реализации всех алгоритмов в один триггер. Это оказалось удобным, поскольку дало возможность физически разделить части кода триггера, относящиеся к реализации разных процедур обработки данных, что позволило значительно упростить управление кодом и выборочно отменять на время действие отдельных частей кода (как было сделано в одном из предыдущих разделов с помощью опции N0 CHECK), тогда как другие части кода продолжали функционировать. С другой стороны, обнаруживался недостаток, обусловленный тем, что после разделения кода таким образом исключалась возможность сохранить логическую последовательность реализации в коде алгоритмов поэтапной обработки, которые когда-то можно было реализовать в единственном триггере.

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

Управление порядком запуска для обеспечения производительности

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