Блокировки в среде MS SQL Server

Пользователю чаще всего не нужно предпринимать никаких действий по управлению блокировками. Всю работу по установке, снятию и разрешению конфликтов выполняет специальный компонент сервера, называемый менеджером блокировок.

MS SQL Server поддерживает различные уровни блокирования объектов (или детализацию блокировок), начиная с отдельной строки таблицы и заканчивая базой данных в целом. Менеджер блокировок автоматически оценивает, какое количество данных необходимо блокировать, и устанавливает соответствующий тип блокировки. Это позволяет поддерживать равновесие между производительностью работы системы блокирования и возможностью пользователей получать доступ к данным.

Блокирование на уровне строки позволяет наиболее точно управлять таким доступом, поскольку блокируются только действительно изменяемые строки. Множество пользователей могут одновременно работать с данными с минимальными задержками. Платой за это является увеличение числа операций установки и снятия блокировок, а также большое количество служебной информации, которое приходится хранить для отслеживания установленных блокировок.

При блокировке на уровне таблицы производительность системы блокирования резко увеличивается, так как необходимо установить лишь одну блокировку и снять ее только после завершения транзакции. Пользователь при этом имеет максимальную скорость доступа к данным. В то же время они не доступны никому другому, потому что вся таблица заблокирована. Приходится ожидать, пока текущий пользователь завершит работу.

Действия, выполняемые пользователями при работе с данными, сводятся к операциям двух типов: их чтению и изменению. В операции по изменению включаются действия по добавлению, удалению и собственно изменению данных.

В зависимости от выполняемых действий сервер накладывает определенный тип блокировки из следующего перечня:

· Коллективные блокировки. Они накладываются при выполнении операций чтения данных (например, SELECT). Если сервер установил на ресурс коллективную блокировку, то пользователь может быть уверен, что уже никто не сможет изменить эти данные.

· Блокировка обновления. Если на ресурс установлена коллективная блокировка и для этого ресурса устанавливается блокировка обновления, то никакая транзакция не сможет наложить коллективную блокировку или блокировку обновления.

· Монопольная блокировка. Этот тип блокировок используется, если транзакция изменяет данные. Когда сервер устанавливает монопольную блокировку на ресурс, то никакая другая транзакция не может прочитать или изменить заблокированные данные. Монопольная блокировка не совместима ни с какими другими блокировками, и ни одна блокировка, включая монопольную, не может быть наложена на ресурс.

· Блокировка массивного обновле ния. Накладывается сервером при выполнении операций массивного копирования в таблицу и запрещает обращение к таблице любым другим процессам. В то же время несколько процессов, выполняющих массивное копирование, могут одновременно вставлять строки в таблицу.

Помимо перечисленных основных типов блокировок SQL Server поддерживает ряд специальных блокировок, предназначенных для повышения производительности и функциональности обработки данных. Они называются блокировками намерений и используются сервером в том случае, если транзакция намеревается получить доступ к данным вниз по иерархии и для других транзакций необходимо установить запрет на наложение блокировок, которые будут конфликтовать с блокировкой, накладываемой первой транзакцией.

Ранее рассмотренные блокировки относятся к данным. Помимо перечисленных в среде SQL Server существует два других типа блокировок: блокировка диапазона ключей и блокировка схемы (метаданных, описывающих структуру объекта).

Блокировка диапазона ключей решает проблему возникновения фантомов и обеспечивает требования сериализуемоститранзакции. Блокировки этого типа устанавливаются на диапазон строк, соответствующих определенному логическому условию, с помощью которого осуществляется выборка данных из таблицы.

Блокировка схемы используется при выполнении команд модификации структуры таблиц для обеспечения целостности данных.

"Мертвые" блокировки

"Мертвые", или тупиковые, блокировки характерны для многопользовательских систем. "Мертвая" блокировка возникает, когда две транзакции блокируют два блока данных и для завершения любой из них нужен доступ к данным, заблокированным ранее другой транзакцией. Для завершения каждой транзакции необходимо дождаться, пока блокированная другой транзакцией часть данных будет разблокирована. Но это невозможно, так как вторая транзакция ожидает разблокирования ресурсов, используемых первой.

Без применения специальных механизмов обнаружения и снятия "мертвых" блокировок нормальная работа транзакций будет нарушена. Если в системе установлен бесконечный период ожидания завершения транзакции (а это задано по умолчанию), то при возникновении "мертвой" блокировки для двух транзакций вполне возможно, что, ожидая освобождения заблокированных ресурсов, в тупике окажутся и новые транзакции. Чтобы избежать подобных проблем, в среде MS SQL Server реализован специальный механизм разрешения конфликтов тупикового блокирования.

Для этих целей сервер снимает одну из блокировок, вызвавших конфликт, и откатывает инициализировавшую ее транзакцию. При выборе блокировки, которой необходимо пожертвовать, сервер исходит из соображений минимальной стоимости.

Полностью избежать возникновения "мертвых" блокировок нельзя. Хотя сервер и имеет эффективные механизмы снятия таких блокировок, все же при написании приложений следует учитывать вероятность их возникновения и предпринимать все возможные действия для предупреждения этого. "Мертвые" блокировки могут существенно снизить производительность, поскольку системе требуется достаточно много времени для их обнаружения, отката транзакции и повторного ее выполнения.

Для минимизации возможности образования "мертвых" блокировок при разработке кода транзакции следует придерживаться следующих правил:

· выполнять действия по обработке данных в постоянном порядке, чтобы не создавать условия для захвата одних и тех же данных;

· избегать взаимодействия с пользователем в теле транзакции;

· минимизировать длительность транзакции и выполнять ее по возможности в одном пакете;

· применять как можно более низкий уровень изоляции.

Уровни изоляции SQL Server

Уровень изоляции определяет степень независимости транзакций друг от друга. Наивысшим уровнем изоляции является сериализуемость, обеспечивающая полную независимость транзакций друг от друга. Каждый последующий уровень соответствует требованиям всех предыдущих и обеспечивает дополнительную защиту транзакций.

SQLServer поддерживает все четыре уровня изоляции, определенные стандартом ANSI.

Уровеньизоляцииустанавливаетсякомандой:

SETTRANSACTIONISOLATIONLEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }

· READ UNCOMMITED – незавершенное чтение, или допустимо черновое чтение. Низший уровень изоляции, соответствующий уровню 0. Он гарантирует только физическую целостность данных: если несколько пользователей одновременно изменяют одну и ту же строку, то в окончательном варианте строка будет иметь значение, определенное пользователем, последним изменившим запись. По сути, для транзакции не устанавливается никакой блокировки, которая гарантировала бы целостность данных. Для установки этого уровня используется команда:

SETTRANSACTIONISOLATIONLEVELREADUNCOMMITTED

· READ COMMITTED – завершенное чтение, при котором отсутствует черновое, "грязное" чтение. Тем не менее в процессе работы одной транзакции другая может быть успешно завершена и сделанные ею изменения зафиксированы. В итоге первая транзакция будет работать с другим набором данных. Это проблема неповторяемого чтения. Данный уровень изоляции установлен в SQL Server по умолчанию и устанавливается посредством команды:

SET TRANSACTION ISOLATIONLEVEL READ COMMITTED

· REPEATABLE READ – повторяющееся чтение. Повторное чтение строки возвратит первоначально считанные данные, несмотря на любые обновления, произведенные другими пользователями до завершения транзакции. Тем не менее на этом уровне изоляции возможно возникновение фантомов. Его установка реализуется командой:

SET TRANSACTION ISOLATIONLEVEL REPEATABLE READ

· SERIALIZABLE – сериализуемость. Чтение запрещено до завершения транзакции. Это максимальный уровень изоляции, который обеспечивает полную изоляцию транзакций друг от друга. Он устанавливается командой:

SET TRANSACTION ISOLATIONLEVEL SERIALIZABLE

В каждый момент времени возможен только один уровень изоляции.

Таблица 1. Уровень изоляции конкурирующей транзакции принят по умолчанию (READ COMMITTED). В примере шаги 4, 6 и 8 демонстрируют черновое чтение. Шаги 9 и 10 блокируются, потому что данные захвачены конкурирующей транзакцией.
Пользователь user1 Конкурирующая транзакция	Пользователь user2 Текущая транзакция
USE basa_user2 BEGIN TRANSACTION TRA	USE basa_user2 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED BEGIN TRANSACTION TRB
1. SELECT * FROM Товар	2. SELECT * FROM Товар
3.UPDATE Товар SET остаток=остаток+10 WHERE КодТовара=4	4. SELECT * FROM Товар (читает измененные неподтвержденные данные)
5.DELETEFROMТоварWHEREКодТовара=4	6. SELECT * FROM Товар (читает измененные неподтвержденные данные)
7. INSERT Товар (Название, остаток) VALUES ('SS',999)	8. SELECT * FROM Товар (читает измененные неподтвержденные данные)
12. ROLLBACK TRANSACTION TRA	9. UPDATE Товар SET остаток=остаток+10 WHERE КодТовара=4 (блокируется до окончания конкурирующей транзакции)
10.DELETE FROM Товар WHERE КодТовара=4(блокируется до окончания конкурирующей транзакции)	11.INSERT Товар(Название, остаток) VALUES ('SS',999) (выполняется)
13. ROLLBACK TRANSACTION TRB SELECT @@TRANCOUNT
Таблица 16.2. Уровень изоляции конкурирующей транзакции принят по умолчанию (READ COMMITTED). В примере шаги 4, 6 и 8 демонстрируют блокировку данных, захваченных другой транзакцией, в то время как работа с другими данными разрешается (шаг 10).
Пользователь user1 Конкурирующая транзакция	Пользователь user2 Текущая транзакция
USE basa_user2 BEGIN TRANSACTION TRA	USE basa_user2 SET TRANSACTION ISOLATION LEVELREAD COMMITTED BEGIN TRANSACTION TRB
1. SELECT * FROM Товар	2. SELECT * FROM Товар
3. UPDATE Товар SET остаток=остаток+10 (захватывает данные)	4. SELECT * FROM Товар WHERE КодТовара=4 (блокируется до окончания конкурирующей транзакции)
5. DELETE FROM Товар WHERE КодТовара=4	6. UPDATE Товар SET остаток=остаток+10 WHERE КодТовара=4 (блокируется до окончания конкурирующей транзакции)
7. UPDATE Товар SET остаток=остаток+10 WHERE КодТовара=4 (выполняется той транзакцией, которая первой захватила данные на изменение или удаление)	8. DELETE FROM Товар WHERE КодТовара=4 (блокируется до окончания конкурирующей транзакции)
9. INSERT Товар (Название, остаток) VALUES ('SS',999)	10. INSERT Товар(Название, остаток) VALUES ('SS',999) (выполняется)
11. ROLLBACK TRANSACTION TRA SELECT @@TRANCOUNT	12. ROLLBACK TRANSACTION TRB SELECT @@TRANCOUNT

 

Таблица 16.3. Уровень изоляции конкурирующей транзакции принят по умолчанию (READ COMMITTED). На шаге 2 транзакция захватила данные чтением и блокирует работу с ними со стороны конкурирующей транзакции (шаги 3, 5), которая может лишь добавлять записи (шаг 7).
Пользователь user1 Конкурирующая транзакция	Пользователь user2 Текущая транзакция
USE basa_user2 BEGIN TRANSACTION TRA	USE basa_user2 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ BEGIN TRANSACTION TRB
1. SELECT * FROM Товар	2. SELECT * FROM Товар (захватывает данные)
3. UPDATE Товар SET остаток=остаток+10 WHERE КодТовара=4 (блокируется)	4. SELECT * FROM Товар (блокируется до окончания конкурирующей транзакции)
5. DELETE FROM Товар WHERE КодТовара=4 (блокируется)	6. UPDATE Товар SET остаток=остаток+10 WHERE КодТовара=4 (выполняется, т.к. данные захвачены текущей транзакцией)
7. INSERT Товар (Название, остаток) VALUES ('SS',999) (выполняется)	8. DELETE FROM Товар WHERE КодТовара=4 (выполняется, т.к. данные захвачены текущей транзакцией)
10. ROLLBACK TRANSACTION TRA SELECT @@TRANCOUNT	9. INSERT Товар(Название, остаток) VALUES ('SS',999) (выполняется)
	11. ROLLBACK TRANSACTION TRB SELECT @@TRANCOUNT
Таблица 16.4. Уровень изоляции конкурирующей транзакции принят по умолчанию (READ COMMITTED). Пример демонстрирует, что текущая транзакция захватила данные чтением (шаг 2) и блокирует любые действия с ними со стороны конкурирующей транзакции вплоть до вставки данных (шаг 7).
Пользователь user1 Конкурирующая транзакция	Пользователь user2 Текущая транзакция
USE basa_user2 BEGIN TRANSACTION TRA	USE basa_user2 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTION TRB
1. SELECT * FROM Товар	2. SELECT * FROM Товар (захватывает данные)
3. UPDATE Товар SET остаток=остаток+10 WHERE КодТовара=4 (блокируется)	4. SELECT * FROM Товар (выполняется)
5. DELETE FROM Товар WHERE КодТовара=4 (блокируется)	6. UPDATE Товар SET остаток=остаток+10 WHERE КодТовара=4 (выполняется, т.к. данные захвачены текущей транзакцией)
7. INSERT Товар (наименование, остаток) VALUES ('SS',999) (блокируется)	8. DELETE FROM Товар WHERE КодТовара=4 (выполняется, т.к. данные захвачены текущей транзакцией)
10. ROLLBACK TRANSACTION TRA SELECT @@TRANCOUNT	9. INSERT Товар(Название, остаток) VALUES ('SS',999) (выполняется)
	11. ROLLBACK TRANSACTION TRB SELECT @@TRANCOUNT

Использование sp_lock

Прежде чем показать запрос, автоматизирующий обнаружение проблемных запросов, хотелось бы поговорить о другой важной характеристике запросов с низкой производительностью, а именно, о безудержной трате ресурсов.

Sp_who2 показывает хорошую картину процессов, которые могут блокировать другие процессы, и некоторое начальное представление об использовании ресурсов типа CPU и I/O, но не говорит ничего о различных блокировках, наложенных для исполнения процесса.

Рисунок 1. После KILL в Important_Data нет записей.

Блокировка – это «нормальное» действие SQL Server, то есть это механизм, посредством которого SQL Server управляет параллельным доступом к данному ресурсу нескольких конкурирующих процессов. Однако как DBA вы должны распознавать поведение блокировок, явно указывающее, что что-то не так.

Распространенные типы блокировок:

§ RID – блокировка одной строки

§ KEY – диапазон ключей в индексе

§ PAG – блокировка страницы данных или индекса

§ EXT – блокировка экстента

§ TAB – блокировка таблицы

§ DB – блокировка БД

В дополнение к типам блокировок, относящимся к ресурсам или объектам, у SQL Server есть общие режимы блокировок:

§ S – Совмещаемая (или разделяемая, Shared) блокировка

§ U – блокировка обновления (Update)

§ X – монопольная (Exclusive) блокировка

§ Intent-блокировки (IS, IU, IX) – используются для создания иерархии блокировок.

§ BU – используется при массовой заливке данных в таблицу

§ Sch-S и Sch-M – блокировки схемы.

Из режимов и типов блокировок, приведенных выше, можно создавать комбинации. Так, например, можно создать блокировку таблицы (TAB) в режиме «Х», то есть эксклюзивном. Это значит, что процесс запрашивает или получает эксклюзивную блокировку таблицы. Естественно, удержание такой блокировки на существенное время может привести к проблемам с блокировками.

В SQL Server есть хранимая процедура sp_lock, предоставляющая массу полезной для DBA информации о количестве и типах блокировок, запрошенных процессом.

Примечание: В SQL Server 2005 и выше эквивалентом sp_lock является компонент SQL ServerDatabaseEngine- динамическое административное представление sys.dm_tran_locks.

На рисунке 9 показан результат выполнения sp_lock для SPID 51, Плохого Запроса.

Рисунок 9. Блокировки Плохого Запроса.

Здесь вы можете видеть, что наложено много блокировок, в основном эксклюзивных блокировок уровня строки, как показывают режим "X" и тип "RID". Когда один SPID, накладывающий такое количество блокировок- что-то точно идет не так, как должно.

Часто простого подсчета блокировок и, что важнее, типов блокировок от отдельного SPID, достаточно, чтобы помочь обнаружить плохо выполняющийся запрос, даже если нет явного блокирования работы. Запрос блокировок, так же как и запрос подключений, расходуют память, и даже разделяемые блокировки, которые могут и не блокировать доступ к данным, иногда могут иметь большое влияние на производительность из-за нагрузки на память и другие ресурсы.

Листинг 1. Блокировки в базе данных при уровне изоляции Зафиксированное чтение (CommittedRead)

Выходные данные процедуры sp_lock:
/Заголовки столбцов таблицы/
Spid - идентификатор процесса
Dbid - идентификатор базы данных
Objid - идентификатор объекта
Indid - индивидуальный идентификатор
Тип - тип ресурса (степень детализации)
Ресурс - идентификатор ресурса
Режим - режим блокирования
Статус - статус блокировки

USE PUBS SET TRANSACTION ISOLATION LEVEL READ COMMITTED BEGIN TRAN SELECT * FROM author WHERE au_lname = `Ringer` EXEC sp_lock @@spid COMMIT TRAN

Листинг 2. Блокировки ключей и разделяемые блокировки при уровне изоляции Повторяемое чтение (RepeatableRead)

USE PUBS SET TRANSACTION ISOLATION LEVEL REPEATABLE READ BEGIN TRAN SELECT * FROM authors WHERE au_lname = `Ringer` EXEC sp_lock @@spid COMMIT TRAN

Листинг 3. Блокировки диапазона ключа при уровне изоляции Упорядочиваемый (Serializable)

USE PUBS SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRAN SELECT * FROM authors WHERE au_lname = `Ringer` EXEC sp_lock @@spid COMMIT TRAN

Листинг 4. Исключающие блокировки при уровне изоляции Зафиксированное чтение (ReadCommitted)

USE PUBS SET TRANSACTION ISOLATION LEVEL READ COMMITTED BEGIN TRAN UPDATE authors SET contract = 0 WHERE au_lname = `Ringer` EXEC sp_lock @@spid COMMIT TRAN

Листинг 5. Блокировки строк при уровне изоляции Зафиксированное чтение (ReadCommitted)

SQL Batch: USE PUBS SET TRANSACTION ISOLATION LEVEL READ COMMITTED BEGIN TRAN updatenewTitles SET price = 3.99 WHERE type = `business` EXEC sp_lock @@spid ROLLBACK TRAN

 

Управление параллельностью

Определение. Управление параллельностью – это процесс организации одновременного выполнения в базе данных различных операций, гарантирующий исключение их взаимного влияния друг на друга.

Важнейшей целью создания баз данных является организация параллельного доступа многих пользователей к общим данным, используемым ими совместно. Обеспечить параллельный доступ относительно несложно, если все пользователи будут только читать данные, помещенные в базу. В этом случае работа каждого из них не оказывает никакого влияния на работу остальных пользователей. Однако, если два и более пользователей одновременно обращаются к базе данных и хотя бы один из них обновляет хранимую в базе информацию, возможно взаимное влияние процессов друг на друга, способное привести к несогласованности данных.

Данная задача аналогична задачам, стоящим перед любой многопользовательской компьютерной системой. В этом случае несколько пользователей получают возможность одновременно выполнять операции благодаря использованию концепции мультипрограммирования, позволяющей двум и более программам (или транзакциям) выполняться в одно и то же время. Например, многие системы включают подсистему ввода/вывода, способную выполнять обработку операций ввода/вывода, в то время как центральный процессор осуществляет другие операции. Подобные системы позволяют двум и более транзакциям выполняться одновременно. Система начинает выполнение первой транзакции и продолжает ее выполнение до первой операции ввода/вывода. На время выполнения этой операции система приостанавливает выполнение первой транзакции и переходит к выполнению команд второй транзакции. Когда второй транзакции понадобится выполнить операцию ввода/вывода, управление будет возвращено первой транзакции и ее выполнение будет продолжено с той точки, в которой она была приостановлена. Выполнение первой транзакции будет продолжено до достижения следующей операции ввода/вывода. Выполнение операций двух транзакций чередуется, и таким образом достигается их параллельное выполнение. Кроме того, общая производительность системы (количество работы, выполняемой на протяжении заданного временного интервала) повышается, поскольку процессор выполняет команды другой транзакции, вместо того чтобы ожидать завершения выполняемой операции ввода/вывода.

Несмотря на то что каждая из транзакций может сама по себе выполняться вполне корректно, подобное чередование операций способно приводить к неверным результатам, из-за чего целостность и согласованность базы данных будет нарушена. Рассмотрим три примера потенциальных проблем, которые могут иметь место при параллельном выполнении транзакций – проблему потерянного обновления, проблему зависимости отнефиксированных результатов и проблему несогласованности обработки.

Восстановление базы данных

Определение. Восстановление базы данных– это процесс возвращения базы данных в корректное состояние, утраченное в результате сбоя или отказа.

Для хранения данных в общем случае может быть использовано четыре различных типа носителей: оперативная память, магнитный диск, магнитная лента, оптический диск (носители расположены в порядке возрастания их надежности). Оперативная память представляет собой временноехранилище информации, содержимое которого в случае отказа системы обычно разрушается. Магнитные диски представляют собой оперативноепостоянное хранилище информации. Диски более надежны и значительно дешевле, чем основная память, однако скорость доступа к информации у них меньше на три-четыре порядка. Магнитная лента представляет собой автономный постоянный носитель информации, надежность которого существенно выше, чем у магнитного диска, а стоимость намного ниже. Однако эти носители предоставляют только последовательный доступ к информации, причем скорость его относительно невелика. Оптические диски являются более надежными носителями информации, чем магнитные ленты, достаточно недорогими, более быстродействующими и к тому же, допускающими произвольный доступ к информации. Оперативную память часто называют первичной памятью, а магнитные диски и ленты – вторичной памятью. Устойчивые хранилища обеспечивают надежное сохранение информации, размещая несколько ее копий на различных постоянных носителях (обычно дисках), одновременный отказ которых маловероятен. В частности, устойчивое хранение информации может быть организовано с использованием RAID-технологии, гарантирующей, что отказ отдельного дискового устройства (даже в процессе передачи данных) не вызовет потери данных.

Транзакции представляют собой основную единицу восстановления в системах с базами данных. Именно менеджер восстановления СУБД обеспечивает поддержку двух из четырех основных свойств транзакций – атомарность и продолжительность, – даже при наличии сбоев в системе. Менеджер восстановления должен гарантировать, что при восстановлении после сбоя для каждой отдельной транзакции в базе данных будут постоянно фиксироваться либо все внесенные ею изменения, либо ни одного из них. Ситуация осложняется тем фактом, что запись в базу данных не представляет собой атомарного действия (выполняемого за один шаг), и поэтому существует вероятность, что, когда выполнение транзакции будет завершено, внесенные ею изменения не будут реально отражены в базе данных по той простой причине, что еще не достигли файлов базы данных.

При выполнении операций чтения СУБД осуществляет следующие действия:

– определяет дисковый адрес блока данных, содержащего запись с заданным значением первичного ключа;

– считывает блок данных с диска и помещает его в буфер СУБД в оперативной памяти;

– копирует сведения заданного поля из буфера СУБД в элемент данных.

При выполнении операции записи СУБД осуществляет следующие действия:

– определяет дисковый адрес блока данных, содержащего запись с заданным значением первичного ключа;

– считывает блок данных с диска и помещает его в буфер СУБД в оперативной памяти;

– копирует сведения из элемента данных в буфер СУБД;

– выводит блок данных из буфера СУБД в оперативной памяти на диск.

Буферы СУБД занимают определенную часть оперативной памяти и используются для обмена данными с вторичной памятью системы. Только после того, как соответствующий буфер выгружен во вторичную память, можно считать, что выполненные операции обновления приобрели постоянный характер. Выгрузка буферов в базу данных может инициироваться по специальной команде (например, по команде завершения транзакции) или же автоматически, как только буфер будет заполнен. Выдачу явного указания о необходимости записи содержимого буферов во вторичную память называют принудительной записью.

Если отказ системы произойдет между записью данных в буфер и выгрузкой буфера во вторичную память, менеджер восстановления должен уточнить состояние транзакции, выполнявшей запись в момент аварии. Если транзакция уже выдала команду завершения, то для обеспечения продолжительности ее результатов менеджер восстановления должен повторно (redo) ее выполнить (иногда говорят, прогнать), чтобы восстановить все внесенные ею изменения.

С другой стороны, если на момент отказа системы транзакция еще не была завершена, менеджер восстановления должен отменить (undo) любые ее результаты (откатить транзакцию в базе данных), что будет гарантировать соблюдение ее атомарности. Если требуется откатить только одну транзакцию, то это – частичный откат. Частичный откат может инициироваться графиком, когда транзакция откатывается и перезапускается по требованию протокола управления параллельностью. Кроме того, транзакция может отменяться по внутренним причинам, например, по требованию пользователя или в результате возникновения исключительной ситуации в прикладной программе. Если требуется выполнить откат всех активных транзакций, то это – глобальный откат.

Типичная СУБД должна предоставлять такие функции восстановления, как:

– механизм резервного копирования, предназначенный для периодического создания копий базы данных;

– средства ведения журнала, в котором фиксируются текущее состояние транзакций и вносимые в базу данных изменения;

– функция создания контрольных точек, обеспечивающая перенос выполняемых в базе данных изменений во вторичную память с целью сделать их постоянными;

– менеджер восстановления, обеспечивающий восстановление согласованного состояния базы данных, нарушенного в результате отказа.