3_Обработка транзакций в реальном масштабе времени (OLTP - технология)

OLTP - технологии OLTP – Online Transaction Processing, системы оперативной обработки транзакций. Понятие транзакции необходимо для поддержания логической целостности БД. Транзакция - совокупность действий, которая должна выполняться полностью. Если транзакция успешно выполняется, то СУБД фиксирует изменения БД, иначе выполняется откат до состояния, предшествующего транзакции. Транзакция представляет собой последовательность операторов языка SQL, которая рассматривается как неделимое действие над БД. Традиционные транзакции характеризуются 4 свойствами (ACID - Atomicity, Consistency, Isolation, Durability): –атомарности: транзакция должна быть выполнена в целом или не выполнена вовсе. –согласованности: по мере выполнения транзакций данные переходят из одного согласованного состояния в другое, т.е. транзакция не разрушает взаимной согласованности данных. –изолированности: конкурирующие за доступ к БД транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно. –долговечности: если транзакция завершена успешно, то те изменения в данных, которые были ею произведены, не могут быть потеряны ни при каких обстоятельствах (даже в случае последующих ошибок). Итак, транзакция: –последовательность согласованных изменений данных и схемы БД; –каждое логическое действие включает одну или более физических операций над БД.

Транзакция - единица работы в БД Команда Begin Tran[action] начинает транзакцию, все последующие команды образуют блок команд транзакции. Заканчивается транзакция командой Commit Tran[saction] или Commit Work, которая предписывает серверу зафиксировать все изменения, выполненные командами транзакции. Второй вариант - завершение транзакции командой Rollback Tran[saction] или Rollback Work, которая заставляет сервер отменить все изменения, сделанные транзакцией. Указание Work в командах означает завершение всех транзакций. Сервер работает по умолчанию в режиме автоматического начала транзакций, в котором каждая команда рассматривается как транзакция, если нет явных команд определения транзакции. Этот режим устанавливается командой SET IMPLICIT_TRANSACTION OFF. Другой режим неявного начала транзакций (устанавливается командой SET IMPLICIT_TRANSACTION ON) автоматически начинает новую транзакцию, если закончена предыдущая командой фиксации или отката. Откат и фиксация транзакций становятся возможными благодаря журналу транзакций. При выполнении любого оператора SQL, который вносит изменения в БД, СУБД автоматически заносит очередную запись в журнал транзакций и после этого вносит изменения в БД. Если после оператора SQL был выполнен оператор Commit, то в журнале транзакций делается отметка о завершении текущей транзакции. Если же после оператора SQL следовал оператор Rollback, то СУБД просматривает журнал транзакций и отыскивает записи, отражающие состояние измененных строк до внесения изменений и восстанавливает те строки в таблицах БД, которые были изменены текущей транзакцией. Таким образом, аннулируются все изменения в БД.

Управление транзакциями Поддержание механизма транзакций - показатель развитости СУБД. Транзакция может быть представлена отдельной программой, являться частью алгоритма программы или отдельной командой и включать произвольное количество операций, выполняемых в БД. Одной из проблем многопользовательских СУБД является организация одновременного доступа к одним и тем же данным множества пользователей с помощью механизма транзакций (потеря изменений, незафиксированные изменения и т.п.). Потеря изменений - две или несколько программ читают одни и те же данные из БД, вносят в них какие-либо изменения и затем пытаются одновременно записать результат по прежнему месту, но в БД могут быть сохранены изменения, выполненные только одной программой, другие изменения будут потеряны. Незафиксированные изменения - когда в процессе выполнения транзакции одной программой в данные были внесены изменения и тут же прочитаны другой программой, однако затем в первой программе транзакция была прервана оператором Rollback, т.е. вторая программа прочитала неверные, незафиксированные данные. Чтение грязных данных - когда транзакция читает данные, изменяемые параллельной транзакцией. В таком случае временные, неподтвержденные данные могут не удовлетворять ограничениям целостности или правилам. И, хотя к моменту фиксации транзакции они могут быть приведены в «порядок», другая транзакция уже может воспользоваться этими неверными данными, что приведет к нарушению ее работы.

Неповторяющиеся чтение - повторное чтение данных, которые были измены другой транзакцией между первым и вторым чтением. Повторное чтение второй транзакцией считывает другие данные. Проблема повторного чтения состоит в том, что между операциями чтения в одной транзакции другие транзакции могут беспрепятственно вносить любые изменения, так что повторное чтение тех же данные приведет к другому результату. Появление данных-фантомов - когда одна транзакция читает данные, а другая добавляет. Добавленные данные являются невидимыми для первой транзакции, т.е. являются "фантомами". Проблема фантомов возникает, когда выборка данных, сделанная в одной транзакции, изменяется другой транзакцией. Например, мы устанавливаем для поля F1 значение 5000 для всех записей таблицы, затем накладываем constraint (ограничение) на поле F1 сверху числом 5001, а в промежуток между этими 2-мя операциями другая транзакция вносит в таблицу запись с F1 = 5500 Для разрешения этих проблем необходимо изолировать транзакции друг от друга. Для реализации различных уровней изоляции в SQL сервере используются блокировки (LOCKs). Блокировки –важный механизм функционирования сервера. Они применяются для каждого запроса на чтение или обновление данных, а также во многих других случаях (например, при создании новой сессии). Работой с блокировками занимается специальный модуль SQL Serverа – менеджер блокировок (Lock Manager).

Подсистема обработка транзакций СУБД Менеджер транзакций Планировщик Менеджер буферов Менеджер восстановления Менеджер файлов Менеджер доступа Менеджер системы База данных и системный каталог

Менеджер транзакций осуществляет координацию работы транзакций, выполняемых прикладными программами. Он взаимодействует с планировщиком (менеджер блокировок), отвечающим за реализацию выбранной стратегии управления параллельностью; второе название применимо в том случае, если выбран протокол управления на основе системы блокировок. Цель работы планировщика – достижение максимально возможного уровня параллельности, при условии исключения влияния параллельно выполняющихся транзакций друг на друга, поскольку это может послужить источником нарушения согласованности базы данных. Если в процессе выполнения транзакции происходит откат, то БД может находиться в несогласованном состоянии. Задачей менеджера восстановления является предоставление гарантий того, что в подобном случае БД будет автоматически восстановлена в то состояние, в котором она находилась на момент начала выполнения транзакции. Менеджер буферов отвечает за передачу данных основной памяти компьютера и вторичной дисковой памяти.

Транзакции и целостность БД Если все операторы выполнены успешно и в процессе выполнения транзакции не произошло никаких сбоев программного или аппаратного обеспечения, то транзакция фиксируется. Фиксация транзакции (commit)- это действие, обеспечивающее запись на диск изменений в БД, которые были сделаны в ходе выполнения транзакции. До тех пор, пока транзакция не зафиксирована, можно произвести отмену всех изменений и восстановить БД в исходное, на момент начала транзакции, состояние. Если же выполнение транзакции невозможно, БД возвращается в исходное состояние. Откат транзакции (rollback)- это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны операторами SQL в теле текущей незавершенной транзакции. Различаются два вида ограничений целостности: немедленно проверяемые и откладываемые. К немедленно проверяемым относятся ограничения целостности, проверку которых бессмысленно или невозможно откладывать (например, ограничение на возрастные рамки - более 150 лет). Они соответствуют уровню отдельных операторов языка СУБД и при их нарушении производится не откат транзакции, а отвергается определенный оператор. Откладываемые ограничения - это ограничения на БД, а не на какие-либо отдельные операции. По умолчанию они проверяются в конце транзакции, и их нарушение вызывает автоматическую замену оператора COMMIT на оператор ROLLBACK. В некоторых системах поддерживается специальный оператор насильственной поддержки ограничений целостности внутри транзакций.

Сериализация транзакций Во избежание искажения данных в запросах к БД требуется разработать процедуру, обеспечивающую согласованность выполнения параллельных транзакций, т.е. изолированность транзакций. Эта процедура в СУБД носит название сериализации транзакций. Для поддержки параллельной работы транзакции строится специальный план. План выполнения набора транзакций называется сериальным, если результат параллельного выполнения транзакций эквивалентен результату последовательного выполнения этих же транзакций. Сериализация транзакций - механизм выполнения транзакций по некоторому сериальному плану, формируемому самой СУБД. При этом: –в процессе выполнения транзакции программа «видит» только согласованные состояния БД; пользователь никогда не может получить доступ к незафиксированным изменениям в данных, достигнутым в результате действия другой программы; –если две транзакции А и В выполняются параллельно, то СУБД полагает, что результат будет такой же, как если бы транзакция А выполнялась бы первой, а за ней выполнялась другая транзакция В, т.е. они выполняются последовательно.

Существует два подхода к сериализации транзакций: основанный на синхронизационных захватах (блокировках) объектов БД, и подход, основанный на использовании временных меток (если транзакция Т1 началась раньше транзакции Т2, то система обеспечивает такой режим выполнения, как если бы Т1 была целиком выполнена да начала Т2. К недостаткам этого метода можно отнести более частные откаты транзакций, чем в случае использования синхронизационных захватов). Для каждого из этих подходов могут существовать пессимистические и оптимистические варианты решения: первые отличаются тем, что применяются в тех ситуациях, когда конфликты возникают часто и распознаются и разрешаются немедленно при их возникновении; вторые - основываются на том, что результаты всех операций на объектами БД сохраняются в рабочей памяти транзакций. Рассмотрим некоторые методы сериализации транзакций с учетом их пессимистических разновидностей. Основным механизмом достижения изолированности операций является механизм блокировок. Транзакция запрашивает захват объекта в одном из режимов: совместный (S - Shared) для операции чтения объекта или монопольный (X - eXclusive) для операций занесения, удаления и модификации. Для реляционных БД объектами захвата могут быть –файл: несколько отношений с индексами; –отношение (таблица); –страница данных: несколько кортежей (записей), индексная страница; –запись; Чем крупнее объект, тем меньше возможностей распараллеливания выполнения транзакций и меньше накладные расходы.

Сервер устанавливает блокировки автоматически в зависимости от текущего уровня изоляции транзакции, однако при желании вы можете изменить тип с помощью специальных подсказок – хинтов. При открытии новой сессии по умолчанию выбирается уровень изоляции READ COMMITTED. Можно изменить этот уровень для данного соединения с помощью команды: SET TRANSACTION ISOLATION LEVEL Блокировки применяются для защиты совместно используемых ресурсов сервера. В качестве объектов блокировок могут выступать следующие сущности: –База данных (обозначается DB). При наложении блокировки на базу данных блокируются все входящие в нее таблицы. –Таблица (обозначается TAB). При наложении блокировки на таблицу блокируются все экстенты данной таблицы, а также все ее индексы. –Экстент (обозначается EXT). При наложении блокировки на экстент блокируются все страницы, входящие в данный экстент. –Страница (обозначается PAG). При наложении блокировки на страницу блокируются все строки данной страницы. –Строка (обозначается RID). –Диапазон индекса (обозначается KEY). Блокируются на обновление, вставку и удаление данные, соответствующие диапазону индекса.

SQL Server сам выбирает наиболее оптимальный объект для блокировки, однако пользователь может изменить это поведение с помощью команд SQL. При автоматическом определении объекта блокировки сервер должен выбрать наиболее подходящий с точки зрения производительности и параллельной работы пользователей. Чем меньше детализация блокировки (строка – самая высокая степень детализации), тем ниже ее стоимость, но ниже и возможность параллельной работы пользователей. Если выбирать минимальную степень детализации, запросы на выборку и обновление данных будут исполняться очень быстро, но другие пользователи при этом должны будут ожидать завершения транзакции. Степень параллелизма можно увеличить путем повышения уровня детализации, однако блокировка – вполне конкретный ресурс SQL Server, для ее создания, поддержания и удаления требуется время и память. SQL Server может принимать решение об уменьшении степени детализации, когда количество блокированных ресурсов увеличивается. Этот процесс называется эскалацией блокировок. Существует два метода управления конкуренцией для обеспечения параллельной работы множества пользователей – оптимистический и пессимистический. SQL Server использует оптимистическую конкуренцию только при использовании курсоров (cursors). Для обычных запросов на выборку и обновление используется пессимистическая конкуренция.

Блокировки транзакций На основании X- и S- блокировок может быть основан протокол доступа к данным: –Транзакция, предназначенная для извлечения объекта базы данных, должна осуществить наложение S- блокировки на выбранный объект базы данных. –Транзакция, предназначенная для обновления объекта базы данных, должна осуществить наложение X-блокировки на объект базы данных. –Если запрашиваемая блокировка со стороны второй транзакции отвергается из-за конфликта с некоторой другой блокировкой со стороны первой транзакции, то вторая транзакция переходи в режим ожидания. –X-блокировки не снимаются до конца выполнения транзакции (или до выполнения операторов Commit, Rollback). Для обеспечения сериализации транзакций синхронизационные захваты объектов, произведенные по инициативе транзакции, можно снимать только после ее завершения (двухфазный протокол синхронизационных захватов Two- Phase Locks, в соответствии с которым выполнение транзакции разбивается на 2 фазы: накопление захватов и освобождение захватов после фиксации или отката). Механизм блокировок разрешает многопользовательский доступ, однако замедляет выполнение транзакции, что вызвано необходимостью ожидания освобождения занятых данных. Если СУБД реализована таким образом, что может захватывать для выполнения транзакции отдельные записи таблицы, то скорость обработки существенно повысится. Блокировка на уровне записей позволяет достигнуть максимальной производительности за счет того, что объект запись является минимальной структурной единицей БД.

Мертвые блокировки Одной из проблем механизма блокирования являются «мертвые блокировки» (DeadLock). При возникновении подобной ситуации две или более транзакций находятся во взаимном ожидании освобождения блокировок, удерживаемых каждой из них. Рассмотрим пример возникновения тупика: пусть транзакции Т1 и Т2 установили монопольные захваты, соответственно, объектов А1 и А2, после этого транзакция Т1 требуется совместный захват А2, а транзакции Т2 - совместный захват А1. Ни одна транзакция не может продолжиться, монопольные захваты не смогут быть сняты, следовательно, совместные захваты не будут удовлетворены. Поскольку тупики возможны, и никакого естественного выхода из них не может быть, то необходимо такие ситуации обнаруживать и искусственно устранять. Сервер БД имеет встроенный механизм разрешения этой проблемы: –предупреждение ошибочных ситуаций (СУБД заранее определяет ситуации, в которых транзакции могут вызывать появление этой ошибки, и предотвращает их возникновение, например, установлением порядка выполнения транзакций на основе использования временных меток. В частности, метод «Ожидание-отмена» требует, чтобы новые транзакции ожидали завершения старых; в противном случае, транзакция отменяется и перезапускается с той же самой временной меткой); –выявление взаимных блокировок с последующим их устранением (СУБД допускает появление подобных ситуаций в системе, затем распознает их и организует выход из ситуации. Этот метод более прост в реализации, и поэтому нашел практическое применение. Разрушение тупика начинается с выбора в цикле транзакции - жертвы, чтобы обеспечить возможность продолжения работы других транзакций. Критерием выбора является минимизация стоимости транзакции; стоимость определяется на основе многофакторной оценки, в которую входят с разными весами время выполнения, число накопленных захватов, приоритет. Производится ее откат, что обеспечивает продолжение работы другим транзакциям.

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

Четыре уровня изолированности транзакций (стандарт ANSI) Read Uncommited. Не допускается обновление данных, пока не закончится первая транзакция, обновляющая эти данные (0-ой уровень изолированности – запрет потерянных и незафиксированных изменений). Read Commited. Не допускается чтение данных, пока не закончится первая транзакция, обновляющая эти данные (1-ый уровень изолированности нет потерянных и незафиксированных изменений и «грязного чтения»). Repeatable Read. Не допускается обновление и чтение данных, пока не закончится транзакция, обновляющая эти данные (2-ой уровень изолированности – запрещено неповторяемое чтение). Serializable. Не допускается обновление и чтение данных, пока не закончится транзакция, обновляющая или читающая эти данные (3-ий уровень изолированности - нет фантомов). Уровень изолированности транзакций устанавливается командой: SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITED READ COMMITED REPEATABLE READ SERILIZABLE } Автоматический откат транзакции устанавливается командой: SET XACT_ABORT ON Чем выше уровень изолированности, тем меньше возможностей для параллельного выполнения транзакций.

Уровни определения изоляции транзакций (каждый уровень включает в себя предыдущий с предъявлением более жестких требований к изоляции): No trashing of data (запрещение «загрязнения» данных). Запрещается изменение одних их тех же данных двумя и более параллельными транзакциями. Изменять данные может только одна транзакция, если какая-то другая транзакция попытается сделать это, она должна быть заблокирована до окончания работы первой транзакции. No dirty read (запрещение «грязного» чтения). Если данная транзакция изменяет данные, другим транзакциям запрещается читать эти данные до тех пор, пока первая транзакция не завершится. No nonrepeatable read (запрещение неповторяемого чтения). Если данная транзакция читает данные, запрещается изменять эти данные до тех пор, пока первая транзакция не завершит работу. При этом другие транзакции могут получать доступ на чтение данных. No phantom (запрещение фантомов). Если данная транзакция производит выборку данных, соответствующих какому-либо логическому условию, другие транзакции не могут ни изменять эти данные, ни вставлять новые данные, которые удовлетворяют тому же логическому условию.

Типы запросов, связанных с транзакциями В MS Access существуют следующие типы запросов по изменению БД В свойствах этих запросов можно задать условие использования транзакции при изменении БД. Установка в значение ДА означает поддержку транзакции при выполнении запроса. Параметр блокировка записей определяет, какие записи будут заблокированы при выполнении транзакции (всех записей или изменяемой записи). Параметр останов по ошибке позволит выполнить откат. Запрос на создание таблицы Запрос на удаление записи

Существует три метода обработки транзакций в языке VBA: –BeginTrans Обозначает начало транзакции –CommitTrans Обозначает конец успешной транзакции –RollbackTrans Обозначает конец безуспешной транзакции

Типы блокировки записей в MS Access Пессимистическая блокировка ( adLockPessimistic ) – блокировка страницы доступа к записи или записи в таблице или запросе от начала изменения поля в записи до завершения редактирования записи. Оптимистическая блокировка ( adLockOptimistic ) – блокировка страницы доступа к записи или записи в таблице или запросе от начала выполнения метода Update в VBA до завершения записи в БД. Блокировка БД через свойства ярлыка БД может быть заблокирована полностью в момент ее открытия (метод adModeShareExclusive в VBA) Чтобы заблокировать все записи в форме или объекте в режиме таблицы (и в базовых таблицах) во время их изменения, выберите параметр блокировка всех записей (свойство RecordLocks= AllRecords).

Оптимистический метод управления характеризуется тем, что вместо непосредственного чтения данных берется значение из буфера. Никаких блокировок при этом не накладывается. Другие транзакции могут спокойно читать или даже изменять данные. В момент фиксирования транзакции система сравнивает предыдущее (заранее сохраненное) значение данных с текущим. Если они совпадают, выполняются операции блокировки, обновления и разблокировки данных. Если же значения отличаются, то система генерирует ошибку и откатывает транзакцию. Пессимистический метод (формы и запросы только). В этом случае сервер всегда блокирует ресурсы в соответствии с текущим уровнем изоляции – запись или страница (4Кб, т.е. несколько записей). Страница или запись заблокирована, пока пользователь не переместится на другую запись. Оптимистическая блокировка (Default). В формах два или больше пользователя могут редактировать одну и ту же запись одновременно. Если два пользователя пытаются сохранять изменения в ту же запись, Access отображает сообщение пользователю, который пытается сохранять запись вторым. Этот пользователь может отменить запись, копировать запись в буфер или заменять изменения, сделанные другим пользователем. Эта установка обычно используется для чтения данных или в однопользовательских БД. В сообщениях, записи не заперты тогда как сообщение просмотрено или напечатано. В отчетах записи не блокируются, пока отчет просматривается или печатается. В запросах записи не блокируются пока запись выполняется.

Разделяемая блокировка (Shared Lock), обозначается латинской буквой S. Эта самый распространенный тип блокировки, который используется при выполнении операции чтения данных. Гарантируется что данные, на которые она наложена, не будут изменены другой транзакцией. Однако чтение данных возможно. Монопольная блокировка (Exclusive Lock), обозначается латинской буквой X. Этот тип применяется при изменении данных. Если на ресурс установлена монопольная блокировка, гарантируется, что другие транзакции не могут не только изменять данные, но даже читать их.

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

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

Access поддерживает до 5 уровней вложенных транзакций Когда одна транзакция вложена в другую, обновление БД не происходит до тех пор, пока последняя вложенная транзакция не завершится успешно (т.е. пока для нее не выполнится метод CommitTrans). Если этот метод не выполняется или соответствующий метод RollbackTrans выполняется, все вложенные транзакции отменяются. Тип связи, установленной между таблицами, контролирует транзакцию. Для набора данных, использующего метод RollbackTrans для типа связей (в VBA), выполняется откат при выполнении этого метода. Когда данные в БД корректируются через связанные формы, пользователи имеют ограниченные права на контроль транзакций. MS Access контролирует изменения в БД. Решение проблем: определяйте конкурирующие транзакции (например, удалить запись без ее изменения); блокируйте записи для предотвращения выполнения более одной транзакции (блокировка записи позволяет другим читать ее без права изменения).

Создание триггера в проекте БД (ADP) Триггер это объект БД, который запускается на выполнение при выполнении действия в БД. Для создания триггера необходимо указать следующее: –текущую таблицу; –транзакции, изменяющие данные, которые запускают триггер: добавление новых данных (INSERT), обновление существующих данных (UPDATE) или удаление существующих данных (DELETE); –действия, которые триггер будет выполнять сразу после указанных транзакций. Триггеры записываются как инструкции Transact-SQL для БД Microsoft SQL Server. –Примечание 1. Включайте в триггер инструкции RAISERROR и ROLLBACK для ситуаций, когда триггер обнаружит, что изменения не разрешены. Это обеспечит синхронизацию набора записей клиента с данными на сервере. При включении только одной из инструкций RAISERROR или ROLLBACK набор записей клиента не будет отражать текущее состояние данных на сервере. Инструкция RAISERROR должна определяться с уровнем важности >10. –Примечание 2. Выберите параметр, который отключает ограничение внешнего ключа во время выполнения транзакций INSERT и UPDATE, если известно, что новые данные будут нарушать ограничение, либо если ограничение применяется только к данным, уже существующим в БД.