Важность установки правильного уровня изоляции для манипулирования согласованными данными

Следующий пример иллюстрирует важность установки правильного уровня изоляции для манипулирования согласованными данными в Microsoft AQL Server 2008 (этот пример, правда, с небольшими модификациями, применим и к СУБД Oracle и DB2 9.5). В примере выполняется обновление, выборка обновленного значения и последующий откат транзакции (информацию об интерфейсе OSQL можно найти в приложении Г).

В транзакции TRAN1 значение поля CUST_STATUS_S изменяется с N на Y, после чего инструкция SELECT извлекает модифицированные данные. Уровень изоляции в сессии установлен как READ COMMITED, поэтому отображаются только изменения, зафиксированные в базе данных. Так как инструкция SELECT выполнялась в пределах все той же транзакции, мы смогли увидеть неподтвержденные изменения, выполненные инструкцией UPDATE. Измененные данные будут видны другим транзакциям сеансов, в которых уровень изоляции установлен в READ UNCOMMITED, однако они невидимы транзакциям с другими уровнями изоляции (если отбор выполнялся до прохождения инструкции ROLLBACK TRANSACTION). В примере также показано, что после отката транзакции данные остались неизмененными. Вопросы обеспечения параллелизма работы в многопользовательской среде имеют особую важность. Когда открыто несколько сеансов чтения и записи к общему ресурсу, в базе данных может быть нарушена целостность. Чтобы этого не произошло, в СУБД реализован механизм обеспечения параллелизма работы. На сервере баз данных совместная работа пользователей поддерживается с помощью механизма управления блокировками. Все три ведущих производителя реализовали в своих СУБД собственные сложные средства поддержки блокировок. Блокировки не являются частью стандарта SQL:2003 и языка SQL в общем (хотя в стандарте определено понятие блокировки курсора). Однако их понимание имеет исключительную важность при работе с базами данных.