Управление параллельной работой
Как вы уже знаете, данные в базе данных обычно используются многими программами пользовательских приложений. Ситуация, при которой несколько программ пользовательских приложений читают и пишут одни и те же данные в одно и то же время, называется конкурентным доступом. Следовательно, каждая СУБД должна иметь некоторый механизм управления для разрешения проблем конкурентного доступа. Высокий уровень конкурентного доступа возможен в системе базы данных, которая может управлять многими активными пользовательскими приложениями без их влияния друг на друга. И наоборот, система базы данных, где различные активные приложения влияют друг на друга, поддерживает низкий уровень конкурентного доступа. Этот раздел начинается с описания двух моделей управления конкурентным доступом, которые поддерживает Database Engine. В следующем разделе объясняется, как проблемы конкурентного доступа могут быть решены с использованием транзакций. Это обсуждение включает вводные сведения в четыре свойства транзакций, известные как свойства ACID (Atomicity, Consistency, Isolation, Durability- атомарность, согласованность, изолированность, устойчивость), обсуждаются связанные с транзакциями операторы Transact-SQL, вводится понятие протокола транзакции. Затем рассматривается блокировка и три основных свойства блокировки: модели блокировки, ресурсы блокировки, длительность блокировки. Также вводится важное понятие взаимной блокировки, которая может возникать как результат обычной блокировки.
Подсказки блокировки задают тип блокировки, используемый Database Engine для блокировки данных таблицы. Подсказки блокировки на уровне таблицы могут быть использованы, когда запрашивается точная регулировка типов блокировки для требуемого ресурса. (Подсказки блокировки перекрывают текущий уровень изоляции транзакции для данной сессии.) Все подсказки блокировки записываются как часть предложения from в операторе select. Вы можете использовать следующие подсказки блокировки: ♦ updlock устанавливает блокировку обновлений для каждой строки таблицы в процессе операций чтения. Все блокировки обновлений сохраняются до завершения транзакции; ♦ tab lock (tablockx) устанавливает разделяемую (или исключительную) блокировку таблицы для всей таблицы. Все блокировки сохраняются до завершения транзакции; ♦ rowlock заменяет существующую разделяемую…
Опция locktimeout оператора set может быть использована для задания количества миллисекунд, в течение которых транзакция будет ожидать снятия блокировки. Значение - (значение по умолчанию) указывает на отсутствие времени ожидания, иными словами, транзакция вообще не будет ожидать. Подсказка блокировки readpast предоставляет альтернативу этой опции set.
Информация о блокировке может быть отображена либо при использовании системной процедуры spiock, либо динамически управляемым представлением, называемым sys.dmtraniocks. Поскольку sp_iock является не рекомендуемым средством и не будет поддерживаться в следующих версиях SQL Server, в этом разделе описывается только представление sys.dm_ tran_ locks. Представление sys.dm_tran_iocks возвращает информацию о текущей активной блокировке менеджера ресурсов. Каждая строка отображает активный в настоящий момент запрос на блокировку, которая была предоставлена или предоставление которой ожидается. Столбцы этого представления соответствуют двум группам: ресурсам и запросам. Группа ресурсов описывает ресурсы, которым предоставлена блокировка на основании запросов, а группа запросов описывает запросы на блокировку. Наиболее важными столбцами этого представления…
Взаимная блокировка является особой проблемой одновременной работы с базой данных, при которой две транзакции блокируют выполнение друг друга. Первая транзакция имеет блокировку на некоторый объект базы данных, к которому другая транзакция ожидает доступа, и наоборот. (Обычно несколько транзакций могут вызвать взаимную блокировку, когда они создают циклические зависимости.) В примере 13.5 показана ситуация взаимной блокировки между двумя транзакциями. Если обе транзакции в примере 13.5 будут выполняться в одно и то же время, возникнет взаимная блокировка, и система вернет следующее сообщение: Server: Msg 1205, Level 13, State 45 Transaction (Process id 56) was deadlocked with another process and has been…
В теории каждая транзакция должна быть полностью изолирована от всех других транзакций. Однако в подобном случае объем доступных данных значительно сокращается, потому что операции чтения в транзакции блокируются операциями записи в других транзакциях, и наоборот. Если доступность данных является важным требованием, это свойство должно быть ослаблено с использованием уровней изоляции. Уровни изоляции задают степень, в которой отыскиваемые в транзакции данные будут защищены от изменений в других транзакциях. Прежде чем начать рассмотрение существующих уровней изоляции, в следующем разделе мы вкратце рассмотрим сценарии, которые могут возникнуть при отсутствии блокировок и, следовательно, не существует никакой изоляции между транзакциями.
Если не используется блокировка и, следовательно, не существует изоляции между транзакциями, то могут возникнуть следующие четыре проблемы: ♦ потеря обновлений; ♦ грязное чтение (обсуждавшееся в разд. «Блокировка» ранее); ♦ неповторяемое чтение; ♦ фантомные записи. Проблема потери обновлений при одновременном доступе появляется, когда не существует изолированности одной транзакции от всех других транзакций. Это означает, что несколько транзакций могут читать одни и те же данные и изменять их. Изменения данных, выполненные всеми транзакциями за исключением транзакции, выполнившей эти изменения последней, будут потеряны. Проблема неповторяемого чтения при одновременном доступе появляется, когда один процесс читает данные несколько раз, а другой процесс изменяет те же…
Используя уровни изоляции, вы можете определить, какие проблемы конкурентного доступа могут появиться, а каких можно избежать. Database Engine поддерживает следующие пять уровней изоляции, которые управляют тем, как будут выполнены ваши операции чтения данных: ♦ read uncommitted; ♦ read committed; ♦ repeatable read; ♦ serializable; ф snapshot. Уровни изоляции read uncommitted, repeatable read и serializable доступны только в пессимистической модели конкурентного доступа, в то время как уровень snapshot доступен только в оптимистической модели конкурентного доступа. Уровень изоляции read committed доступен в обеих моделях. Далее описываются четыре уровня изоляции, которые доступны в пессимистической модели конкурентного доступа. Уровень snapshot описывается в разд. «Контроль…
Уровень изоляции read uncommitted предоставляет наипростейшую форму изоляции транзакций, потому что он вообще не изолирует операции чтения других транзакций. Когда транзакция этого уровня изоляции отыскивает строку, она не запрашивает блокировки и не признает никаких существующих блокировок. Данные, которые читаются этой транзакцией, могут быть несогласованными. В этом случае транзакция читает данные, которые были изменены какой-нибудь другой активной транзакцией. Если для второй транзакции позже будет выполнен откат, то значит, что первая транзакция прочла данные, которые никогда реально не существовали. Из четырех проблем одновременного доступа к данным, рассмотренных в предыдущем разделе, read uncommitted допускает грязное чтение, неповторяемое чтение и фантомные записи.
Как вы уже знаете, уровень изоляции read committed имеет две формы. Первая форма применяется для пессимистической модели конкурентного доступа, а вторая форма - для оптимистической модели конкурентного доступа. В этом разделе рассматривается первая форма. Вторая форма read committed snapshot обсуждается в разд. «Контроль версий строк» далее В этом разделе. Транзакция, которая читает строку и использует уровень изоляции read committed, проверяет только лишь, установлена ли исключительная блокировка на эту строку. Если такая блокировка отсутствует, транзакция загружает строку. (Это выполняется при использовании разделяемой блокировки.) Это действие не дает транзакции возможности читать неподтвержденные изменения данных, которые впоследствии могут быть отменены. После чтения значений…
В отличие от уровня изоляции read committed уровень изоляции repeatable read устанавливает разделяемую блокировку на все данные, которые читаются, и сохраняет эту блокировку, пока транзакция не будет подтверждена или отменена. Следовательно, в этом случае выполнение запроса несколько раз внутри транзакции всегда вернет один и тот же результат. Недостатком такого уровня изоляции является то, что одновременный доступ ухудшается, потому что временной интервал, в течение которого другие транзакции не могут обновлять те же данные, значительно больше, чем в случае read committed. Этот уровень изоляции не запрещает другим транзакциям добавлять новые строки, которые появляются в последующих чтениях, следовательно, могут появиться фантомные записи.
© 2019 serversql.ru. Все права защищены.