|
|
|
|
|
|
|
|
|
|
|
|
Таблица 1 |
|
|
|
|
|
|
Определение уровней изоляции |
|
|
||||
Уровни |
|
АНОМАЛИИ |
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
Microsoft SQL |
|
|
|
|
|
|
|
|
Неповто- |
|
|
|
|
|
||
изоляции |
|
Потерянные |
|
Грязное |
|
|
Фантом |
|
DB2 |
Oracle |
||
SQL/92 |
|
изменения |
|
чтение |
|
ряющееся |
|
|
Server |
|
|
|
|
|
|
чтение |
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
READ |
|
нет |
|
да |
|
да |
|
да |
|
READ |
UNCOMMITTED |
- |
UNCOMMITTED |
|
|
|
|
|
|
|
|
|
UNCOMMITTED |
READ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
READ |
|
нет |
|
нет |
|
да |
|
да |
|
READ |
CURSOR |
READ |
COMMITTED |
|
|
|
|
|
COMMITTED |
STABILITY |
COMMITTED |
||||
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
REPEATABLE |
|
нет |
|
нет |
|
нет |
|
да |
|
REPEATABLE |
READ |
- |
READ |
|
|
|
|
|
READ |
STABILITY |
|||||
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
SERIALIZABLE |
|
нет |
|
нет |
|
нет |
|
нет |
|
SERIALIZABLE |
REPEATABLE |
SERIALIZABLE |
|
|
|
|
|
READ |
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4
Сценарии
Мы приводим сценарии проверки нежелательных ситуаций на примере таблицы EXAMPLE (табл. 2), структура и содержимое которой приведены ниже. Вам предстоит разработать подобные сценарии, работающие с одной из таблиц, созданных Вами в работе № 2.
Таблица 2
Таблица EXAMPLE
id INTEGER
dat INTEGER
1 |
|
100 |
|
|
|
|
|
|
2 |
|
110 |
|
|
|
3 |
|
120 |
|
|
|
4 |
|
130 |
|
|
|
|
|
|
5 |
|
140 |
|
|
|
|
|
|
6 |
|
150 |
|
|
|
7 |
|
160 |
|
|
|
|
|
|
8 |
|
170 |
|
|
|
|
|
|
9 |
|
180 |
|
|
|
10 |
|
190 |
|
|
|
11 |
|
200 |
|
|
|
Ниже приводятся сценарии проверок (табл. 3). Сценарии должны выполняться пошагово, что приводит к тому, что транзакции Т1 и Т2 выполняются параллельно в разных сеансах. Мы подразумеваем, что после выполнения каждого сценария мы восстанавливаем исходное содержимое таблицы
EXAMPLE.
5
|
|
|
|
|
Таблица 3 |
||
|
|
|
Сценарии проверок |
|
|||
|
|
|
|
|
|
|
|
|
Шаг |
|
Транзакция T1 |
|
Транзакция T2 |
|
|
|
|
|
|
|
|
||
|
1. Потерянные изменения |
|
|
|
|
||
|
|
|
|
|
|||
|
1 |
|
BEGIN TRANSACTION |
|
BEGIN TRANSACTION |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2 |
|
UPDATE example SET |
|
|
|
|
|
|
dat=101 WHERE id=1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
3 |
|
|
|
UPDATE example SET |
|
|
|
|
|
|
dat=102 WHERE id=1 |
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|||
|
4 |
|
|
|
COMMIT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5 |
|
COMMIT |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
Если потерянные изменения допускаются, то сценарий |
|
|||||
|
выполнится без ошибок и блокировок. В базе данных |
|
|||||
|
сохранится изменение, сделанное на шаге 2. |
|
|||||
|
|
|
|
|
|
||
|
2. Грязное чтение |
|
|
|
|
||
|
|
|
|
|
|||
|
1 |
|
BEGIN TRANSACTION |
|
BEGIN TRANSACTION |
|
|
|
|
|
|
|
|
|
|
2SELECT * FROM example WHERE id=1
3 |
|
|
|
UPDATE example SET |
|
|
|
dat=101 WHERE id=1 |
|
|
|
|
|
|
|
|
|
|
|
4SELECT * FROM example WHERE id=1
5 |
|
|
|
ROLLBACK |
|
|
|
|
|
6SELECT * FROM example WHERE id=1
Если допускается незавершенное чтение, то сценарий выполнится без ошибок и блокировок. На шаге 2 будут выбраны значения (1,100). На шаге 3 -(1,101). На шаге 4 - (1,100).
6
|
|
|
|
|
|
|
Продолжение табл. 3 |
||
|
|
|
|
|
|
|
|
|
|
|
Шаг |
|
Транзакция T1 |
|
|
Транзакция T2 |
|
||
|
|
|
|
|
|
||||
|
3. Неповторяющееся чтение |
|
|
|
|
||||
|
|
|
|
|
|
|
|
||
|
1 |
|
BEGIN TRANSACTION |
|
BEGIN |
|
|||
|
|
|
TRANSACTION |
|
|
||||
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
2 |
|
SELECT * |
FROM |
example |
|
|
|
|
|
|
WHERE id=1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
3 |
|
[COMMIT] |
|
|
|
UPDATE example SET |
|
|
|
|
|
|
|
dat=101 WHERE id=1 |
|
|
||
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|||
|
4 |
|
|
|
|
|
COMMIT |
|
|
|
|
|
|
|
|
|
|
|
|
|
5 |
|
SELECT * |
FROM |
example |
|
|
|
|
|
|
WHERE id=1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6 |
|
COMMIT |
|
|
|
|
|
|
Если допускается неповторяющееся чтение, то сценарий
выполнится без ошибок и блокировок. Операцию COMMIT на шаге 3 выполнять не придется. На шаге 2 будут выбраны значения (1,100). На шаге 3 - (1,101).
4. Фантом (пример для READ UNCOMMITTED)
1 |
|
BEGIN TRANSACTION |
|
BEGIN |
|
|
TRANSACTION |
||
|
|
|
|
|
|
|
|
|
|
2SELECT * FROM example WHERE dat>180
3 |
|
[COMMIT] |
|
INSERT INTO example |
|
|
VALUES(12,210) |
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4 |
|
|
|
COMMIT |
|
|
|
|
|
5SELECT * FROM example WHERE dat>180
6 
COMMIT
Если допускается фантом, то сценарий выполнится без
ошибок и блокировок. Операцию COMMIT на шаге 3 выполнять не придется. На шаге 2 будут выбраны значения (10,190), (11,200). На шаге 3 - (10,190), (11,200), (12,210).
7
|
|
|
|
|
|
Окончание табл. 3 |
||
|
|
|
|
|
|
|
||
Шаг |
|
Транзакция T1 |
|
|
Транзакция T2 |
|
||
|
|
|
||||||
5. Тупик (пример для REPEATABLE READ) |
|
|
||||||
|
|
|
|
|
|
|
||
1 |
|
SELECT |
id from |
exampe |
|
|
|
|
|
WHERE dat=120 |
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SELECT |
id from |
|
2 |
|
|
|
|
|
exampe |
WHERE |
|
|
|
|
|
|
|
dat=130 |
|
|
|
|
|
|
|
|
|||
3 |
|
UPDATE |
example SET id=3 |
|
|
|
|
|
|
WHERE dat=130 |
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4 |
|
|
|
|
|
UPDATE example SET |
|
|
|
|
|
|
|
id=4 WHERE dat=120 |
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|||
|
|
|||||||
Если система не обнаруживает и не устраняет тупиков, то |
|
|||||||
после выполнения шага 4 транзакции должны взаимно |
|
|||||||
заблокироваться. |
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
Инструментальные средства Microsoft SQL Server
Для выполнения сценариев проверки изолированности следует открыть два окна внутри Microsoft Query Analyzer (либо два экземпляра Microsoft Query Analyzer)
Для того чтобы набор операторов выполнялся внутри транзакции, следует заключить их между строчками BEGIN
TRANSACTION и COMMIT:
BEGIN TRANSACTION
...
...
COMMIT
8