Каков механизм для Отката транзакции в SQL-сервере?
При каждом обновлении в базе данных сначала записывается запись в журнал, содержащая описание изменения. Например, если вы обновляете значение столбца с A на B, журнал будет содержать запись об обновлении, что-то вроде: в таблице T столбец C был изменен с A на B для записи с ключом K транзакцией с идентификатором I. Если вы откатите транзакцию, механизм начнет сканировать журнал в обратном направлении в поисках записей о работе, проделанной вашей транзакцией, и отменит эту работу: когда он найдет запись об обновлении с A на B, он изменит значение обратно на A. Вставка будет отменена удалением вставленной строки. Удаление будет отменено вставкой строки обратно. Это описано в Логическая архитектура журнала транзакций и Журнал транзакций с опережением записи.
Это объяснение высокого уровня, точные внутренние детали того, как это происходит, недокументированы для неспециалистов и не подлежат вашей проверке или изменению.
Взгляните на ROLLBACK TRANSACTION (Transact-SQL)
Откат явной или неявной транзакции к началу транзакции к началу транзакции или к точке сохранения внутри транзакции.
Что касается того, как это делается, все изменения данных в транзакции хранятся в журнале транзакций, при этом в журнале также зарезервировано дополнительное место для записей отмены на случай отката. Каждый журнал транзакций содержит достаточно информации, чтобы отменить сделанные изменения, так что при необходимости можно отменить изменения. (А также воспроизвести их в сценарии DR)
Если мы возьмем в качестве примера простую операцию удаления (поскольку я расшифровал ее здесь как пример содержимого журнала), удаляемая запись хранится внутри записи журнала транзакций LOP_DELETE_ROWS, и с некоторыми нетривиальными усилиями вы можете расшифровать и продемонстрировать, что вся строка находится внутри записи журнала.
Если транзакция будет откатана, будет использовано зарезервированное в журнале пространство отмены, и ряд будет вставлен заново. Причина резервирования места для отмены заключается в том, что журнал транзакций не может быть заполнен в середине транзакции, не оставляя места для завершения или отката.