Менеджер транзакций

хранения промежуточных состояний БД.
Методы доступа для организации данных транзакций.

также известна как LSCC) - схема гранулированных синхронизационных захватов;
Multi-Versioning Concurrency

Control (сокращённо MVCC) - многоверсионное управление параллелизмом;
Optimistic Concurrency Control (OCC) - управление оптимистичным параллелизмом.

=> эксклюзивная блокировка (W-lock) для защиты строк от таких операций записи

как INSERT, UPDATE или DELETE.
Одна строка – множественное чтение => совместно используемыtе блокировки (R-lock), которые могут быть предоставлены для операции чтения нескольким одновременным клиентам.

от чтения, но в случае других уровней изолированности, для чтения

необходима R-блокировка, которая будет предоставлена, если никакая другая транзакция не имеет W-блокировки на строке (строках).
Если транзакция READ UNCOMMITTED меняет данные, то ставится W-блокировка

снята сразу после считывания строки
При Repeatable Read и SERIALIZABLE R-блокировки

будут сохранены до конца транзакции.
Все блокировки транзакции будут сняты в конце транзакции независимо от того, как была завершена транзакция.

LOCK TABLE, но снимаются эти блокировки в конце транзакции всегда

неявно, а в случае уровня изолированности READ COMMITTED R-блокировка снимается раньше.
Неявные команды UNLOCK TABLE обычно доступны в диалектах SQL, за исключением, например, MySQL/InnoDB.

использовать SQL Server.

Extent (EXT): Эти блокировки не используются для

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

Page (PAG): Когда SQL Server требуется заблокировать одновременно множество строк, а свободные слоты блокировок заканчиваются, то он может использовать страничные блокировки.

Key (KEY): Лучший уровень блокировки, возможный в SQL Server, вместе с RID блокировкой. KEY блокировки используются в индексах, а RID блокировки - в таблицах-кучах.

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

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

с маленькой гранулярностью, конвертируются в одну блокировку на более высоком

уровне иерархии с большей гранулярностью.

большей гранулярностью, чем несколько (или несколько тысяч) более мелких.
Data contention.

Наложение одной блокировки - действие атомарное, а наложение нескольких блокировок уже таковым не является.
Resource contention. Блокировки занимают место + нуждаются так же и в некотором обслуживании, которое расходует системные ресурсы (проверка на тупики). + предел количества транзакций, которые могут выполняться в системе одновременно без ущерба для производительности.

сервер посчитает, что блокировать на уровне отдельной записи не самое

оптимальное решение, то он заблокирует больший объем.
Можно указать явно, с какой гранулярностью блокировать, с помощью специальных подсказок оптимизатору (hints) (в сторону увеличения!).
ROWLOCK – блокировка на уровне записи.
PGLOCK - блокировка на уровне страницы данных.
TABLOCK – блокировка на уровне таблицы.

транзакции используют уровень изолированности, который не снимает R-блокировки до конца

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

взаимной блокировкой «жертву», за это несёт ответственность код приложения или

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

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

данных всех строк, так что для любой обновленной строки в момент начала любой параллельной транзакции может быть найдена зафиксированная версия.
Эта техника управления параллелизмом исключает время ожидания чтения и обеспечивает всего 2 уровня изолированности:
READ COMMITTED
SNAPSHOT

COMMITTED получит последние зафиксированные версии строк от цепи истории.
Транзакция с

уровнем изолированности SNAPSHOT будет видеть только последние версии строк, зафиксированные во время начала транзакции (или записанные самой транзакцией). В уровне изолированности SNAPSHOT, транзакция никогда не увидит фантомные строки и не может даже предотвратить запись фантомных строк параллельными транзакциями, тогда как изолированность SERIALIZABLE, основанная на механизме LSCC (MGL), препятствует тому, чтобы параллельные транзакции записывали фантомные строки в базу данных. Фактически, транзакция продолжает видеть в снимке фантомные строки, которые параллельные транзакции тем временем удалили из базы данных.
Несмотря на уровень изолированности, как правило, запись также защищена в системах MVCC какой-либо блокировкой строк. Обновление строк, содержание которых тем временем был обновлено другими, будет генерировать ошибки «Your snapshot is too old» («Ваш снимок слишком старый»).

для выполнения вставки, обновления или удаления) будет предоставлена блокировка строки

и приоритет записи, а конкурирующие записи будут помещены в очередь. Блокировки строки реализуются при помощи маркировки записанных строк посредством SCN (англ. «System Change Number» - системный номер изменения) транзакции, порядковыми номерами начатой транзакции. Поскольку SCN строки принадлежит активной транзакции, то эта строка будет зарезервирована для этой транзакции. Использование блокировки по записи означает, что взаимные блокировки возможны, но вместо автоматического прерывания «жертвы», Oracle немедленно находит блокировку строки, которая бы могла привести к взаимной блокировке, вызывает исключение в приложении клиента и ожидает клиента, чтобы разрешить взаимную блокировку явной командой отката (ROLLBACK).

как в дополнение к MVCC с неявной блокировкой строки, Oracle

обеспечивает явные команды «LOCK TABLE», а также явную блокировку строк посредством команды «SELECT ... FOR UPDATE», которая обеспечивает средства для предотвращения невидимых фантомных строк. В Oracle транзакция также может быть объявлена как Read Only (только для чтения).
 
Microsoft также отметил преимущества MVCC, а в SQL Server, начиная с версии 2005, стало возможным настроить в сервере использование управления версиями строк при помощи настроек свойств базы данных посредством команд Transact-SQL, а начиная с версии 2012 – посредством свойств базы данных, как это показано на рисунке 2.9.

для чтения четыре уровня изолированности:

READ UNCOMMITTED считывает строки таблицы без

R-блокировки;
READ COMMITTED (фактически «Read Latest Committed») считывает строки таблицы даже когда они заблокированы посредством MVCC;
REPEATABLE READ (фактически «Snapshot»), использующий MVCC;
SERIALIZABLE, использующий MGL CC с S-блокировками для предотвращения появления фантомных строк.
 
Примечание: независимо от уровня изолированности запись всегда будет нуждаться в защите исключительной блокировкой.

Чтение и запись изменение данных.
Validate: Поиск конфликтов - проверка изменений

данных, которые читала и меняла транзакция, другими транзакциями.
Commit/Rollback: Если конфликтов нет, изменения записываются. Если конфликт обнаружен, то откат транзакции.

Восстановление после поломки основного внешнего носителя базы данных.

откат транзакции в случае взаимной блокировки при параллельном выполнении транзакций.

неустранимого сбоя процессора и т. д. Потеря той части базы

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

рестарта и восстановления согласованности БД
Разрушение носителя: рестарт, восстановление с резервной

копии, восстановление согласованности

выполнении приложений или невозможностью выполнить транзакцию сериализуемым образом
Операции обрыва можно

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

используются другими транзакциями
Пример невосстановимого расписания
w1(x) w2(x) c2 a1
S2L (Двухфазный протокол

с удержанием замков на запись до конца транзакции) гарантирует восстановимость

точку отката)
По команде commit – зафиксирует всё до неявной точки

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

запись изменений в БД до момента успешного выполнения всех операций,

входящих в транзакцию, и получения команды подтверждения транзакции (commit).
Иногда используется другой подход: система записывает изменения в БД, не дожидаясь завершения транзакции, а старые значения данных сохраняет на время выполнения транзакции в сегментах отката.

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

изменениях. Обычно записывается "старое" и "новое" содержимое изменённых записей, чтобы можно было восстановить прежнее состояние БД при откате транзакции (по команде rollback) или при откате текущей операции (в случае возникновения ошибки).
Данные в RBS хранятся до тех пор, пока транзакция, изменяющая эти данные, не будет завершена. Потом они могут быть перезаписаны данными более поздних транзакций.

чтобы при необходимости можно было вернуться к состоянию БД в

точке сохранения: откатить работу от текущего момента до точки сохранения (rollback to <имя_точки>) или зафиксировать работу от начала транзакции до точки сохранения (commit to <имя_точки>).
На одну транзакцию может быть несколько точек сохранения (ограничение на их количество зависит от СУБД).

данные обо всех изменениях всех объектов БД. Журнал недоступен пользователям

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

операции записи, начала и конца транзакций
Каждая запись содержит данные отката

(undo)и «наката» (redo)
При фиксации запись журнала обязательно «выталкивается» на диск

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

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

было возможным, необходимо вести журнал обновлений
При нормальной работе БД все

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

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

восстановленном состоянии базы данных.

отказа и какие были активными (не завершены)
Если необходимо, повторить изменения

зафиксированных транзакций
Оборвать незавершенные до отказа транзакции (выполнить откат)

SQL Server;
откат восстановленной базы данных, файла, файловой группы или страницы

до момента сбоя.
поддержка репликации транзакций;
поддержка решений высокого уровня доступности и аварийного восстановления

транзакции (прямой просмотр журнала)
Фаза наката (redo): при прямом просмотре, выполнить

все операции зафиксированных транзакций
Фаза отката (undo): обратный просмотр журнала, откат всех операций незавершенных транзакций

блоки БД
После записи БД можно очистить журнал
Возобновить нормальную работу системы

'C:\tmp\saledat.mdf',
SIZE = 10,
MAXSIZE = 50,
FILEGROWTH = 5

)
LOG ON ( NAME = Sales_log, FILENAME = 'C:\tmp\salelog.ldf',
SIZE = 5MB,
MAXSIZE = 25MB,
FILEGROWTH = 5MB ) ;

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

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

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

сжатие.
DBCC SHRINKFILE (DataFile1, 7); DataFile1 – имя файла, 7 – размер в МБ);

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

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