Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | ||
|
В каждый момент времени возможен только один уровень изоляции.
Пример 1. Уровень изоляции конкурирующей транзакции принят по умолчанию (т.е. READ COMMITTED).
В этом примере шаги 4, 6 и 8 демонстрируют черновое чтение.
Шаги 9 и 10 блокируются, потому что данные захвачены конкурирующей транзакцией.
Пользователь 1 (конкурирующая транзакция) | Пользователь 2 (текущая транзакция) |
USE Торговая_фирма BEGIN TRANSACTIONTrA 1. SELECT * FROMТовары | USE Торговая_фирма SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED BEGIN TRANSACTIONTrB 2. SELECT * FROMТовары |
3. UPDATE Товары SETНазвание = ‘Йогурт’ WHERE ID_товара = 4 | |
4. SELECT * FROM Товары (читает измененные и неподтвержденные данные) | |
5. DELETE FROMТовары WHEREID_товара = 4 | |
6. SELECT * FROM Товары (читает измененные и неподтвержденные данные) | |
7. INSERT INTOТовары (Название, категория) VALUES ('Семга', 10) | |
8. SELECT * FROM Товар (читает измененные и неподтвержденные данные) | |
9. UPDATEТовар SETЕдиница_измерения= 'л' WHERE ID_товара = 4 (Блокируется до окончания конкурирующей транзакции) | |
10. DELETE FROMТовар WHERE ID_товара = 4 (Блокируется до окончания конкурирующей транзакции) | |
11. INSERT INTOТовар (Название, Категория) VALUES (‘Минтай’, 9) (выполняется) | |
12. ROLLBACK TRANSACTION TrA SELECT @@Trancount | |
13. ROLLBACK TRANSACTION TrB SELECT @@Trancount |
Пример 2. Уровень изоляции конкурирующей транзакции будет принят по умолчанию (т.е. READ COMMITED).
В шагах 4, 6, 8 осуществляется блокировка данных, захваченных другой транзакцией, в то время как работа с другими данными разрешена (шаг 10)..
Пользователь 1 (конкурирующая транзакция) | Пользователь 2 (текущая транзакция) |
USE Торговая_фирма BEGIN TRANSACTIONTrA 1. SELECT * FROMТовары | USE Торговая_фирма SET TRANSACTION ISOLATION LEVEL READ COMMITTED BEGIN TRANSACTIONTrB 2. SELECT * FROMТовары |
3. UPDATE Товары SETНазвание = 'Хлеб ' WHERE ID_товара = 4 (Захватывает данные) | |
4. SELECT * FROM Товары (Читать нельзя. Команда блокируется до окончания конкурирующей транзакции) | |
5. DELETE FROMТовары WHEREID_товара = 4 (Выполняется) | |
6. UPDATE Товары SETНазвание = 'Молоко ' WHERE ID_товара = 4 (блокируется до окончания конкурирующей транзакции) | |
7. UPDATE Товары SETНазвание = 'Хлебобулочные ' WHERE ID_товара = 4 (выполняется той транзакцией, которая первой захватила данные на изменение или удаление) | |
8. DELETE FROMТовары WHERE ID_товара = 4 (Блокируется до окончания конкурирующей транзакции) | |
9. INSERT INTOТовары (Название, категория) VALUES ('Семга', 999) | |
10. INSERT INTOТовар (Название, категория) VALUES ('Семга', 999) (выполняется) | |
11. ROLLBACK TRANSACTION TrA SELECT @@Trancount | |
12. ROLLBACK TRANSACTION TrB SELECT @@Trancount |
Пример 3. Уровень изоляции конкурирующей транзакции принят по умолчанию (READ COMMITTED).
На шаге 2 транзакция захватила данные чтением и блокирует работу с ними со стороны конкурирующей транзакции (шаги 3, 5), которая может лишь добавлять записи (шаг 7).
Пользователь 1 (конкурирующая транзакция) | Пользователь 2 (текущая транзакция) |
USE Торговая_фирма BEGIN TRANSACTIONTrA 1. SELECT * FROMТовары | USE Торговая_фирма SET TRANSACTION ISOLATION LEVEL REPEATABLE READ BEGIN TRANSACTIONTrB 2. SELECT * FROMТовары (Захватывает данные) |
3. UPDATE Товары SETНазвание = 'Хлебобулочные ' WHERE ID_товара = 4 (Блокируется) | |
4. SELECT * FROM Товары (Возвратит первоначально считанные данные) | |
5. DELETE FROMТовары WHEREID_товара = 4 (Блокируется) | |
6. UPDATE Товары SETНазвание = 'Хлебобулочные ' WHERE ID_товара = 4 (Выполняется, т.к. данные захвачены текущей транзакцией) | |
7. UPDATE Товары SETНазвание = 'Хлебобулочные ' WHERE ID_товара = 4 (выполняется той транзакцией, которая первой захватила данные на изменение или удаление) | |
8. DELETE FROMТовары WHERE ID_товара = 4 (Выполняется т.к. данные захвачены текущей транзакцией) | |
9. INSERT INTOТовары (Название, категория) VALUES ('Семга', 999) (выполняется) | |
10. ROLLBACK TRANSACTION TrA SELECT @@Trancount | |
11. ROLLBACK TRANSACTION TrB SELECT @@Trancount |
Пример 4. Уровень изоляции конкурирующей транзакции принят по умолчанию (READ COMMITTED).
Пример демонстрирует, что текущая транзакция захватила данные чтением (шаг 2) и блокирует любые действия с ними со стороны конкурирующей транзакции вплоть до вставки данных (шаг 7).
Пользователь 1 (конкурирующая транзакция) | Пользователь 2 (текущая транзакция) |
USE Торговая_фирма BEGIN TRANSACTIONTrA 1. SELECT * FROMТовары | USE Торговая_фирма SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTIONTrB 2. SELECT * FROMТовары (Захватывает данные) |
3. UPDATE Товары SETНазвание = 'Хлебобулочные ' WHERE ID_товара = 4 (Блокируется) | |
4. SELECT * FROM Товары (Выполняется) | |
5. DELETE FROMТовары WHEREID_товара = 4 (Блокируется) | |
6. UPDATE Товар SETНазвание = 'Хлебобулочные ' WHERE ID_товара = 4 (выполняется, т.к. данные захвачены текущей транзакцией) | |
7. INSERT INTOТовары (Название, категория) VALUES ('Семга', 999) (Блокируется) | |
8. DELETE FROMТовары WHERE ID_товара = 4 (выполняется т.к. данные захвачены текущей транзакцией) | |
9. INSERT INTOТовары (Название, категория) VALUES ('Семга', 999) (выполняется) | |
10. ROLLBACK TRANSACTION TrA SELECT @@Trancount | |
11. ROLLBACK TRANSACTION TrB SELECT @@Trancount |
Журнал транзакций
Возможность восстановления состояния базы данных после сбоев обеспечивается с помощью журнала транзакций. Журнализация изменений, т. е. сохранение во внешней памяти информации обо всех модификациях БД, тесно связана с управлением транзакциями.
Основным принципом согласованной политики записи изменений в журнал и непосредственно в базу данных является то, что запись об изменении объекта базы данных должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти базы данных. Соответствующий протокол журнализации (и управления буферизацией) называется Write Ahead Log (WAL) - «пиши сначала в журнал», и состоит в том, что если требуется сохранить во внешней памяти измененный объект базы данных, то перед этим нужно гарантировать сохранение во внешней памяти журнала записи о его изменении.
Другими словами, если во внешней памяти базы данных находится некоторый объект базы данных, по отношению к которому выполнена операция модификации, то во внешней памяти журнала обязательно находится запись, соответствующая этой операции. Каждая успешно завершившаяся транзакция должна быть реально зафиксирована во внешней памяти. Какой бы сбой ни произошел, система должна иметь все данные для восстановления состояния базы данных, содержащие результаты всех зафиксированных к моменту сбоя транзакций. Минимальным требованием, гарантирующим возможность восстановления последнего согласованного состояния базы данных, является сохранение во внешней памяти журнала всех записей об изменении базы данных этой транзакцией. При этом последней записью в журнал, производимой от имени данной транзакции, является специальная запись о конце транзакции.
Иногда для восстановления последнего согласованного состояния базы данных после сбоя журнала изменений базы данных явно недостаточно. Основой восстановления в этом случае являются журнал и архивная копия базы данных.
Восстановление начинается с обратного копирования базы данных из архивной копии. Затем для всех закончившихся транзакций в прямом смысле повторно выполняются все операции. Более точно, происходит следующее: по журналу в прямом направлении выполняются все операции; для транзакций, которые не закончились к моменту сбоя, выполняется откат (англ. back up).
Хотя к ведению журнала предъявляются особые требования по части надежности, реально возможна и его утрата. Тогда единственным способом восстановления базы данных является возврат к архивной копии. Конечно, в этом случае не удастся получить последнее согласованное состояние базы данных.
Рассмотрим способы производства архивных копий базы данных. Самый простой способ - архивировать базу данных при переполнении журнала. В этом случае образование новых транзакций временно блокируется. Когда все транзакции закончатся, и, следовательно, база данных придет в согласованное состояние, можно выполнять ее архивацию, после чего начинать заполнять журнал заново.
Можно выполнять архивацию базы данных реже, чем переполняется журнал. При переполнении журнала и окончании всех начатых транзакций можно архивировать сам журнал. Поскольку такой архивированный журнал, по сути дела, требуется только для воссоздания архивной копии базы данных, журнальная информация при архивации может быть существенно сжата.
В заключение сформулируем общие требования к системе восстановления данных в составе СУБД.
1. Пользователь не должен осуществлять рестарт транзакций или повторный ввод данных. Восстановление должно проходить на базе транзакции с помощью отмены или изменения отдельных транзакций.
2. Быстрое восстановление данных обеспечивается генерацией данных, используемых для восстановления.
3. При выполнении процедур автоматизированного восстановления пользователь не должен анализировать состав данных и выбирать сами процедуры.
Для восстановления базы данных СУБД имеют в своем составе сервисные программные средства:
Программы ведения системного журнала регистрируют операции над БД: описание соответствующей транзакции, код пользователя, текст входного сообщения, тип изменения БД, адреса изменяемых данных вместе с их значениями до и после изменения.
Программы архивации используются для регулярного получения копий БД для последующего ее восстановления.
Программы восстановления применяются для возврата БД или некоторых ее частей в состояние, предшествующее возникновению отказа. При этом используют архивную копию БД и системный журнал.
Программы отката ликвидируют последствия выполнения определенной транзакции в БД.
Программы записи контрольных точек и повторного исполнения позволяют ускорить восстановление.
Примеры для самотестирования:
Вариант 1.
1. Пусть дана таблица Товар. На начало транзакций в таблице записей нет:
Дата публикования: 2014-12-08; Прочитано: 380 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!