Уровень изоляции транзакций в базе данных имеет набор свойств, к которым относятся:
📕Атомарность: идея здесь в том, что база данных гарантирует завершение транзакции. Если часть транзакции терпит неудачу, она откатывает всю транзакцию.
📕Согласованность: Здесь мы можем сказать, что каждая транзакция переходит из одного состояния в другое, но это гарантирует, что новое состояние соблюдает все ограничения, которые были определены. , такие как уникальный, первичный ключ и т. д. Здесь база данных гарантирует, что транзакция работает на стабильных данных
📕Изоляция: здесь база данных гарантирует, что транзакция работает на стабильных данных.
📕Долговечность: База данных гарантирует отсутствие нештатных ситуаций, таких как отключение электроэнергии или прерывание работы охранником,
Мы называем это безопасностью отключения электричества от сервера, чтобы можно было сделать вызов, для Например, в этом случае данные стали нестабильными.
Процесс устойчивости заключается в том, что любая операция, которую вы выполняете в базе данных, должна быть сначала сохранена в файле журнала транзакций на диске. В этом контексте мы обсудим тему «журнала упреждающей записи» отдельно позже. Затем операция начинает выполняться в базе данных. Таким образом, мы сохранили состояние базы данных перед операцией, и у нас есть два варианта: либо отменить, либо повторить.
два типа изоляции:
🎗️ Блокировка (сегодняшняя тема)
🎗️ Блокировка и управление версиями строк
Прежде чем мы начнем нашу тему, нам нужно договориться о типах блокировок в SQL-сервере. Режимы блокировки:
🎗️ Общий
🎗️ Эксклюзивный
Эксклюзивная блокировка используется, например, при изменении данных в транзакции. В этом случае вам необходимо поставить эксклюзивную блокировку на эти ресурсы до завершения транзакции. Любая другая транзакция, которой нужны эти ресурсы, должна дождаться завершения этой транзакции, после чего заблокированный ресурс будет освобожден. Идея состоит в том, что другая транзакция может прочитать это только в том случае, если это зависит от уровня изоляции, который по умолчанию установлен на чтение зафиксировано. Мы обсудим эти темы позже, даст Бог.
Общая блокировка используется, когда транзакция только читает. В этом случае один и тот же ресурс может использоваться более чем одной транзакцией.
Режимы блокировки:
📀 Зафиксированное чтение ⇒ Значение по умолчанию в SQL-сервере
📀 Чтение незафиксированного
📀 Повторяемое чтение
📀 Сериализуемое чтение
⇒
Грядущая блокировка зависит от блокировок и версий строк, которые мы обсудим в следующем посте.
📀 Снимок
⭐ Чтение незафиксированных
На этом уровне изоляции транзакция не запрашивает никаких блокировок. Это означает, что транзакция может считывать данные, которые еще не стали постоянными, что называется «грязным чтением».
Пример:
Сеанс 1:
Set transaction isolation level read uncommitted Select * from employee where employee_id = 12
Сессия 2:
Begin transaction Update employee set salary = (salary*0.5)+salary where employee_id = 12
В приведенном выше примере мы открыли две сессии, одна читает данные сотрудника, а вторая открыла транзакцию, которая выполняет обновление, но не фиксируется. Однако, если мы запустим сеанс 2, а затем сеанс 1, сеанс 1 будет нормально считывать новые данные, даже если сеанс 2 заблокировал сотрудника. Это связано с тем, что сеанс 1 не использует никаких типов блокировки.
⭐ Read commit
Это уровень изоляции по умолчанию в SQL Server. Мы будем использовать тот же предыдущий пример, но мы изменим уровень изоляции на «установить уровень изоляции транзакции для чтения». Этот уровень изоляции гарантирует, что считанные данные зафиксированы или непротиворечивы. Если мы запустим те же два сеанса выше с изменением уровня изоляции, мы заметим важную вещь: запрос, который читал грязные данные, перешел в стадию ожидания, потому что он запросил общую блокировку, в то время как обновление имело монопольную блокировку. В этом разница между ними.
⭐ Повторяющееся чтение
Если вы хотите, чтобы данные не изменялись на уровне соединения, вы можете использовать этот уровень изоляции.
Пример:
Сеанс 1:
Set transaction isolation level repeatable read Begin transaction Select * from employee Waitfor delay '00:00:05' Select * from employee Commit
Сессия 2:
Begin transaction Update employee set salary = (salary*0.5)+salary where employee_id = 12 Waitfor delay '00:00:10' Commit
В приведенном выше примере, если вы запускаете первый сеанс с повторяемым уровнем изоляции, он считывает данные из таблицы сотрудников, затем ждет пять секунд, а затем снова считывает данные, чтобы убедиться, что вторая транзакция не произвела никаких обновлений. Если мы удалим время задержки обновления, второй выбор в сеансе 1 вернет обновленные данные.
⭐ Serializable read
Serializable похож на повторяемый, но разница в том, что он защищает нас от проблемы, называемой «фантомными данными». Если мы выполним вставку для тех же данных, которые мы только что прочитали, уровень изоляции повторяющегося чтения не обнаружит это, потому что он только защищает нас от изменений в существующих данных. Однако сериализуемый уровень изоляции обнаружит любые новые данные, вставленные в тот же диапазон операции чтения.
Пример:
Сеанс 1:
Set transaction isolation level serializable Begin transaction Select * from employee where department_id = 1 Waitfor delay '00:00:05' Select * from employee where department_id = 1 Commit
Сессия 2:
Begin transaction Insert into employee (employee_id, department_id, salary) values (101, 1, 5000) Waitfor delay '00:00:10' Commit
В приведенном выше примере, если мы запустим первый сеанс на сериализуемом уровне изоляции, он считывает данные из таблицы сотрудников, где Department_id равен 1, затем ждет пять секунд, а затем снова считывает, чтобы убедиться, что новые данные не были вставлены в таблицу. тот же диапазон. Если мы запустим второй сеанс и вставим новые данные с Department_id=1, первый выбор в первом сеансе обнаружит новые данные и не позволит второму выбору вернуть какие-либо данные.
В заключение, выбор правильного уровня изоляции для ваших транзакций зависит от требований вашего приложения и характера ваших данных. Каждый уровень изоляции имеет свои преимущества и недостатки, и вы должны выбрать тот, который соответствует вашим потребностям и гарантирует согласованность данных, параллелизм и производительность.
