Какая информация записывается в журнал транзакций

Какая информация записывается в журнал транзакций

Каждая база данных SQL Server имеет как минимум два файла, с ней ассоциирующихся: один файл данных, в котором непосредственно хранятся данные и как минимум один файл журнала транзакций. Журнал транзакций это основной компонент системы управления базами данных (СУБД). Все изменения в базе данных записываются в журнал транзакций. Используя эту информацию, СУБД может определить какая транзакция какие изменения внесла в данные SQL Server.

Оператор CREATE DATABASE используется для создания базы данных Microsoft SQL Server. Опция этой команды LOG ON используется для определения журнала транзакций создаваемой базы данных. Впервые созданные данные помещаются в файл данных, а запись изменений этих данных помещается в файле журнала транзакций.
Как только делаются изменения в базе, журнал транзакций растет. Поскольку большинство изменений вносимых в базу, журналируются, Вам нужно будет отслеживать размер журнала транзакций, потому что, если данные постоянно меняются, журнал соответственно вырастает.
Каждая контрольная точка Microsoft SQL Server гарантирует что все записи в журнале и все модифицированные страницы данных корректно записаны на диск. Файл журнала транзакций используется Microsoft SQL Server в процессе операции восстановления базы данных, чтобы зафиксировать завершенные транзакции и откатить незавершенные. Информация, записывающаяся в журнал транзакций, включает:

• Время начала каждой транзакции;
• Изменения внутри каждой транзакции и информацию для их отката (для этого используются снимки страниц данных до, и после транзакции);
• Информация о распределении памяти для страниц БД (выделении и изъятии экстента);
• Информация о завершении или откате каждой транзакции.

Эти данные Microsoft SQL Server использует в целях повышения целостности данных. Журнал транзакций используется при старте SQL Server, для того чтобы отменить сделанные изменения и установить состояние базы данных на момент, предшествующий началу изменений.
При запуске SQL Server для каждой БД начинается процесс регенерации (recovery). SQL Server определяет те транзакции, которые необходимо откатить. Это происходит в том случае, когда неизвестно все ли изменения из кэша записаны на диск. Поскольку при выполнении контрольной точки все изменения сбрасываются на диск, то с нее и стартует процесс регенерации, который производит фиксацию транзакций на диск. Все изменения на страницах, сделанные до контрольной точки, уже записаны на диск, поэтому нет смысла для сброса их на диск еще раз и изменения, выполненные до контрольной точки, не берутся к рассмотрению.
При необходимости отката транзакции SQL Server копирует снимки страниц данных до изменений, сделанных с момента запуска оператора BEGIN TRANSACTION.
Вы можете использовать журнал транзакций при восстановлении базы данных. В этом случае журналируется фиксация транзакций. В процессе фиксации транзакций SQL Server сохраняет все сделанные изменения в базе данных на диске.
Журнал транзакций полезен для устранения ошибок в базе данных, ошибок транзакций и позволяет обеспечить целостность данных.

Некоторые операции не всегда журналируются

Microsoft SQL Server не выполняет журналирование в тех случаях, когда могут возникнуть проблему с нехваткой дискового пространства при быстром увеличении журнала транзакций.
Для некоторых операций, таких как CREATE INDEX, Microsoft SQL Server не ведет протоколирование для каждой новой страницы. Вместо этого SQL Server записывает достаточно информации, чтобы определить, как CREATE INDEX отработал, и принять решение о том фиксировать изменения или сделать откат.
Если опция базы данных select into/bulkcopy установлены в TRUE, Microsoft SQL Server не записывает в журнал транзакций информацию о следующих операциях: операции массового копирования, Select into, WRITETEXT и UPDATETEXT. Поскольку эти операции не регистрируются в журнале транзакций, то SQL Server не сможет использовать восстановление журнала транзакций для отмены этих операций.
Если же выполняется одно из этих действий, когда опции select into/bulkcopy установлены в TRUE, то необходимо убедиться в том что резервная копия содержала изменения, сделанные этими операциями, в случае если потребуется последующее восстановление.

Резервное копирование журнала транзакций

Для того чтобы повысить эффективность стратегии резервирования и восстановления БД, необходимо периодически делать резервные копии журнала транзакций. Создать резервную копию журнала транзакций можно с помощью команды BACKUP LOG. При использовании копирования журнала транзакций, при необходимости, базу данных можно восстановить на любой момент времени, содержащийся в копии журнала. Если Вы не резервируете журнал перед его усечением, то восстановить сможете только последнюю копию базы данных, все изменения прошедшие с этого времени будут потеряны.
После того как Microsoft SQL Server заканчивает резервное копирование журнала транзакций, он усекает его неактивную часть, тем самым, высвобождая место. SQL Server может повторно использовать высвобожденное место, т.к. журнал транзакций непрерывно растет и ему требуется свободное пространство. Активная часть журнала содержит изменения, которые были сделаны в базе и еще не зафиксированы на диске.
Microsoft SQL Server пытается запустить процесс контрольной точки всякий раз когда журнал транзакций заполняется более чем на 70 процентов, или при получении ошибки переполнения журнала транзакций, а также при останове SQL Server (если используется SHUTDOWN WITH NOWAIT) операция контрольной точки будет запущена для каждой базы данных. При включенной опции ‘trunc. log on chkpt.’ становится бесполезным выполнение резервного копирования журнала транзакций, поскольку информация о производимых изменениях постоянно уничтожается и неактивная часть журнала транзакций урезается каждый раз после выполнении процесса контрольной точки. По существу эта опция показывает, что Вы не сможете использовать журнал транзакций при восстановлении. Журнал транзакций необходим для отката изменений и в процессе регенерации при старте SQL Server. Используйте эту опцию только для тех систем, для которых не важны потери изменений, сделанных в течение всего дня, потому что в этом случае Вы сможете восстановить только последнюю копию базы данных, а сделанные позже изменения восстановить будет невозможно. Применяется это редко.
Если журнал транзакций урезается с помощью оператора BACKUP LOG , то нельзя делать его копию до тех пор, пока не будет создана полная копия базы данных или дифференциальная копия. Дифференциальная копия содержит в себе только те изменения, которые произошли с момента последней полной копии базы данных.
Также желательно избегать резервирования журнала транзакций после любых не журналируемых операций, которые произошли после последнего полного резервного копирования базы данных. Сделайте лучше полную копию базы данных или разностное резервное копирование.
И в заключении, при добавлении или удалении любого файла из базы данных Вы должны создать полную копию. Восстановить в этом случае базу данных на момент, предшествующий ее изменению, используя журнал транзакций, не удастся.

Изменение опций базы данных

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

exec sp_dboption pubs ‘trunc. log on chkpt.’, ‘false’

Эта команда отменит усечение журнала транзакций для базы данных pubs. Чтобы увидеть список всех текущих настроек базы данных, можно просто запустить эту процедуру без дополнительных параметров. Например:

exec sp_dboption pubs

Также опции БД можно изменить в Enterprise Manager. Для впервые созданной базы данных наибольшая часть опций установлена в значение False. В Microsoft SQL Server Desktop edition, однако, опция усечения журнала транзакций в контрольной точке установлена в значение True. На практике это может и не создавать проблем с восстановлением данных, все зависит от схемы резервного копирования и восстановления.
Также Вы можете установить опцию усечения журнала транзакций после контрольной точки на серверах разработчиков прикладных программ, поскольку в этом случае не так важно сохранять каждую тестовую транзакцию.

Эта статья дает лишь сжатое представление о том, как использовать журнал транзакций Microsoft SQL Server. Тема резервного копирования и восстановления баз данных достаточно сложна и мы ее коснулись лишь только поверхностно. Главная задача этой статьи показать какое важное значение имеет журнал транзакций. Часто новые базы данных создаются с очень маленьким размером журнала транзакций и с использованием опции ‘trunc. log on chkpt.’. Эта опасная комбинация потому как в этом случае журнал транзакций нельзя будет использовать после сбоев оборудования или программных ошибок, а также ошибок системы. Убедитесь в том, что Ваши базы данных SQL Server надежно защищены, планируя и осуществляя резервное копирование журнала транзакций, а также продумав эффективный план восстановления.

Журнал транзакций

Реализация в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакции обеспечивается специальным механизмом, для поддержки которого создается некоторая системная структура, называемая Журналом транзакций

Однако назначение журнала транзакций гораздо шире Он предназначен для обес­печения надежного хранения данных в БД

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

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

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

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

Это, собственно, и означает, что восстанавливается последнее по времени согласованное состояние базы данных.

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

— Индивидуальный откат транзакции. Этот откат должен быть применен в следующих случаях: — стандартной ситуацией отката транзакции является ее явное завершение

— аварийное завершение работы прикладной программы, которое логически эквивалентно выполнению оператора ROLLBACK, но физически имеет иной механизм выполнения;

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

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

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

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

Во всех трех случаях основой восстановления является избыточное хранение данных. Эти избыточные данные хранятся в журнале, содержащем последова­тельность записей об изменении базы данных.

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

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

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

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

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

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

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

1. Когда транзакция Т1 начинается, в протокол заносится запись

<Т1 Begin transaction>

2. На протяжении выполнения транзакции в протоколе для каждой изменяемой записи записывается новое значение: <T1.ID_RECORD, атрибут, новое значение . >. Здесь ID_RECORD — уникальный номер записи.

Если все действия, из которых состоит транзакция Т1, успешно выполнены, то транзакция частично фиксируется и в протокол заносится <Т1 СОММIТ>.

После того как транзакция фиксирована, записи протокола, относящиеся к Т1 используются для внесения соответствующих изменений в БД.

Если происходит сбой, то СУБД просматривает протокол и выясняет, какие транзакции необходимо переделать. Транзакцию Т1 необходимо переделать, если протокол содержит обе записи <Т1 BEGIN TRANSACTION> и <Т1 СОММIТ>. БД может находиться в несогласованном состоянии, однако все новые значения измененных элементов данных содержатся в протоколе, и это требует повторного выполнения транзакции. Для этого используется некоторая системная процедура REDO(), которая заменяет все значения элементов данных на новые, просматривая протокол в прямом порядке.

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

Альтернативный механизм с немедленным выполнением предусматривает вне­сение изменений сразу в БД, а в протокол заносятся не только новые, но и все старые значения изменяемых атрибутов, поэтому каждая запись выглядит <Т1.ID_RECORD, атрибут новое значение старое значение . >. При этом запись в журнал предшествует непосредственному выполнению операции над БД. Когда транз­акция фиксируется, то есть встречается команда <Т1.СОММIТ> и она выполняется, то все изменения оказываются уже внесенными в БД и не требуется никаких дальнейших действий по отношению к этой транзакции.

При откате транзакции выполняется системная процедура UNDO(), которая воз­вращает все старые значения в отмененной транзакции, последовательно прохо­дя по протоколу начиная с команды BEGIN TRANSACTION.

Для восстановления при сбое используется следующий механизм:

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

— Если сбой произошел после выполнения последней команды изменения БД, но до выполнения команды фиксации, то команда фиксации выполняется, а с БД никаких изменений не происходит. Работа происходит только на уровне протокола.

— Однако следует отметить, что проблемы восстановления выглядят гораздо сложнее приведенных ранее алгоритмов, с учетов того, что изменения как в журнал, так и в БД заносятся не сразу, а буферизуются. Этому посвящен следующий раздел.

Транзакции и механизмы их контроля

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

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

Атомарность. Транзакция либо выполняется полностью либо не выполняется вовсе.

Согласованность. При завершении транзакции не должны быть нарушены ограничения накладываемые на данные (например constraints в БД). Согласованность подразумевает, что система будет переведена из одного корректного состояния в другое корректное.

Изолированность. Параллельно выполняемые транзакции не должны влиять друг на друга, например менять данные которые использует другая транзакция. Результат выполнения параллельных транзакций должен быть таким, как если бы транзакции выполнялись последовательно.

Устойчивость. После фиксации изменения не должны быть утеряны.

Журнал транзакций

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

Журнал содержит значения, которые данные имели до и после их изменения транзакцией. Write-ahead log strategy обязывает добавлять в журнал запись о предыдущих значениях до начала, а о конечных после завершения транзакции. В случае внезапной остановки системы БД читает лог в обратном порядке и отменяет изменения сделанные транзакциями. Встретив прерванную транзакцию БД выполняет ее и вносит изменения о ней в журнал. Находясь в состоянии на момент сбоя, БД читает лог в прямом порядке и возвращает изменения сделанные транзакциями. Таким образом сохраняется устойчивость транзакций которые уже были зафиксированы и атомарность прерванной транзакции.

Простое повторное выполнение ошибочных транзакций недостаточно для восстановления.

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

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

Чтение фиксированных данных (Read Committed)

Проблема грязного чтения (Dirty Read) заключается в том, что транзакция может прочесть промежуточный результат работы другой транзакции.

Пример. Начальное значение баланса 0$. Т1 добавляет к балансу 50$. Т2 считывает значение баланса (50$). Т1 отменяет изменения и завершается. T2 продолжает выполнение располагая неверными данными о балансе.

Решением является чтение фиксированных данных (Read Committed) запрещающее читать данные, измененные транзакцией. Если транзакция A изменила некоторый набор данных, то транзакция B при обращении за этими данными вынуждена ожидать завершения транзакции A.

Повторяемое чтение (Repeatable Read)

Проблема потерянных изменений (Lost Updates). Т1 сохраняет изменения поверх изменений Т2.

Пример. Начальное значение баланса 0$ и две транзакции одновременно пополняют баланс. T1 и T2 читают баланс равный 0$. Затем T2 прибавляет 200$ к 0$ и сохраняет результат. T1 прибавляет 100$ к 0$ и сохраняет результат. Итоговый результат 100$ вместо 300$.

Проблема неповторяемого чтения (Unrepeatable read). Повторное чтение одних и тех же данных возвращает разные значения.

Пример. Т1 читает значение баланса равное 0$. Затем Т2 добавляет к балансу 50$ и завершается. Т1 повторно читает данные и обнаруживает несоответствие с предыдущим результатом.

Повторяемое чтение (Repeatable Read) гарантирует что повторное чтение вернет тот же результат. Данные прочитанные одной транзакцией запрещено менять в других до завершения транзакции. Если транзакция A прочла некоторый набор данных, то транзакция B при обращении за этими данными вынуждена ожидать завершения транзакции A.

Упорядоченное чтение (Serializable)

Проблема фантомного чтения (Phantom Reads). Два запроса выбирающие данные по некоему условию возвращают разные значения.

Пример. T1 запрашивает количество всех пользователей баланс которых больше 0$ но меньше 100$. T2 вычитает 1$ у пользователя с балансом 101$. T1 повторно выполняет запрос.

Упорядоченное чтение (Serializable). Транзакции выполняются как полностью последовательные. Запрещается обновлять и добавлять записи, подпадающие под условия запроса. Если транзакция A запросила данные всей таблицы, то таблица целиком замораживается для остальных транзакций до завершения транзакции A.

Планировщик (Scheduler)

Устанавливает очередность в которой должны выполняться операции при параллельно протекающих транзакциях

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

Механизмы контроля параллельных заданий (Concurrency Control)

Оптимистический основан на обнаружении и разрешении конфликтов, пессимистический на предотвращении возникновения конфликтов

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

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

Блокировка (Locking)

Если одна транзакция заблокировала данные, то остальные транзакции при обращении к данным обязаны ждать разблокировки

Блок может накладываться на базу данных, таблицу, ряд или аттрибут. Совместный захват (Shared Lock) может быть наложен на одни данные несколькими транзакциями, разрешает всем транзакциям (включая наложившую) чтение, запрещает изменение и монопольный захват. Монопольный захват (Exclusive Lock) может быть наложен только одной транзакцией, разрешает любые действия наложившей транзакции, запрещает любые действия остальным.

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

Пример. Первая транзакция ждет освобождения данных захваченных второй, в то время как вторая ждет освобождения данных, захваченных первой.

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

С определенной периодичностью производится поиск взаимоблокировок. Один из способов обнаружения — по времени, то есть считать что взаимоблокировка произошла если транзакция выполняется слишком долго. Когда взаимоблокировка найдена, то одна из транзакций откатывается, что дает возможность другим транзакциям участвующим во взаимоблокировке завершиться. Выбор жертвы может быть основан на стоимости транзакций или их старшинстве (Wait-Die и Wound-wait схемы).

Каждой транзакции T присваивается временная метка TS содержащая время начала выполнения транзакции.

Если TS(Ti) < TS(Tj), то Ti ждет, иначе Ti откатывается и начинается заново с той же временной меткой.

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

Если TS(Ti) < TS(Tj), то Tj откатывается и начинается заново с той же временной меткой, иначе Ti ждет.

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

Пессимистическое решение проблемы взаимоблокировок не позволяет транзакции начать выполнение если есть риск возникновения взаимоблокировки

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

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

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

Двухфазный коммит обеспечивает выполнение коммита на всех репликах БД

Каждая БД вносит информацию о данных которые будут изменены в лог и отвечает координатору ОК (Voting Phase). После того как все ответили ОК координатор отсылает сигнал обязывающий всех произвести коммит. После коммита сервера отвечают ОК, если хоть один не ответил ОК, то координатор отсылает сигнал отмены изменений всем серверам (Completion Phase).

Метод временных меток

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

Каждой транзакции назначается временная метка TS соответствующая времени начала выполнения. Если Ti старше Tj, то TS(Ti) < TS(Tj).

Когда транзакция откатывается, ей назначается новая временная метка. Каждый объект данных Q задействованный транзакцией помечается двумя метками. W-TS(Q) — временная метка самой молодой транзакции, успешно выполнившей запись над Q. R-TS(Q) — временная метка самой молодой транзакции, выполнившей запись чтения над Q.

Когда транзакция T запрашивает чтение данных Q возможны два варианта.

Если TS(T) < W-TS(Q), то есть данные были обновлены более молодой транзакцией, то транзакция T откатывается.

Если TS(T) >= W-TS(Q), то чтение выполняется и R-TS(Q) становится MAX(R-TS(Q), TS(T)).

Когда транзакция T запрашивает изменение данных Q возможны два варианта.

Если TS(T) < R-TS(Q), то есть данные уже были прочитаны более молодой транзакцией и если произвести изменение, то возникнет конфликт. Транзакция T откатывается.

Если TS(T) < W-TS(Q), то есть транзакция пытается перезаписать более новое значение, транзакция T откатывается. В остальных случаях изменение выполняется и W-TS(Q) становится равным TS(T).

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

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

Русские Блоги

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

Операции, поддерживаемые журналом транзакций

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

• Восстановить отдельные транзакции
  Если приложение выдает инструкцию ROLLBACK или ядро ​​базы данных обнаруживает ошибку (например, потерю связи с клиентом), используйте журнал, чтобы откатить изменения, сделанные незавершенными транзакциями.
• Восстановление всех незавершенных транзакций при запуске SQL Server
  При сбое сервера под управлением SQL Server база данных может находиться в таком состоянии: некоторые изменения не были записаны из кэша в файл данных, и в файле данных есть незавершенные транзакции Изменения. Когда экземпляр SQL Server запущен, он выполнит операцию восстановления для каждой базы данных, найдет каждую ожидающую транзакцию в журнале транзакций и откатит ее, чтобы обеспечить целостность базы данных. Это восстановление называетсяВосстановление экземпляра。
• Повернуть восстановленную базу данных, файл, файловую группу или страницу до точки отказа
  После того, как аппаратные потери или сбой диска влияют на файлы базы данных, пользователи используют прошлые резервные копии базы данных для восстановления базы данных. Прошлые данные резервной копии базы данных, очевидно, являются состоянием на момент резервного копирования и не будут включать данные, сгенерированные в течение периода от завершения резервного копирования до момента сбоя базы данных, поскольку все модификации данных записываются в файле журнала повторов.SQL Server будет применять записи операций в журнале транзакций к восстановленному файлу данных., Чтобы база данных могла быть восстановлена ​​до того момента, когда произойдет сбой носителя хранения данных, этот вид восстановления называетсяВосстановление медиа。
• Поддержка репликации транзакций
  Принцип репликации транзакций состоит в том, чтобы сначала отправлять начальный моментальный снимок в базе данных издателя каждому подписчику, а затем отслеживать изменения в данных в базе данных издателя, фиксировать отдельные изменения данных и изменять Данные отправляются подписчику. Агент чтения журнала отслеживает журнал транзакций каждой базы данных, настроенной для репликации транзакций, и копирует транзакции, помеченные для репликации, из журнала транзакций в базу данных распространителя. Только подтвержденные транзакции могут быть отправлены в базу данных распространения.
• Поддержка решений высокой доступности и аварийного восстановления
  Альтернативные серверные решения, группы доступности AlwaysOn, зеркалирование базы данных и доставка журналов в значительной степени зависят от журналов транзакций.

Организация файлов журнала транзакций

1. Журнал транзакций физической архитектуры

Журнал транзакций — это просто файл журнала, в котором записывается поведение транзакций и изменения базы данных в соответствующей базе данных. Когда вы создаете новую базу данных вместе с файлом базы данных, будет файл журнала транзакций с расширением ldf по умолчанию. Конечно, база данных также может быть оснащена несколькими файлами журналов.
SQL Server логически делит физический файл журнала на несколько виртуальных файлов журнала (Virtual Log File, VLF). Используя аналогию, файл журнала (ldf) похож на поезд, а каждая машина представляет собой файл виртуального журнала (VLF).

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

2. Логическая архитектура журнала транзакций

Прежде чем любые изменения, внесенные в объекты базы данных, будут сохранены в базе данных, соответствующие записи логической операции базы данных сначала будут записаны в файл журнала. Эта запись будет записана последовательно до логического конца файла журнала, и будет назначен глобально уникальный порядковый номер журнала (LSN). Этот порядковый номер идет в точном порядке. Если в журнале есть два порядковых номера LSN2> LSN1, это означает, что LSN2 расположен после LSN1.

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

Усечение журнала

Перемотка физического журнала
Журнал транзакций представляет собой файл перемотки. Например, предположим, что существует база данных, которая содержит физический файл журнала, разделенный на четыре виртуальных файла журнала. Когда база данных создана,Файл логического журнала (VLF с записями журнала)ИзФайл физического журнала (включая все VLF)Начало начало. Новые записи журнала добавляются вКонец логического журнала, А затем разверните до конца физического журнала. Усечение журнала освободит все виртуальные журналы, все записи которых отображаются до минимального порядкового номера журнала восстановления (MinLSN), а усеченные части журнала помечаются как повторно используемые.

Усечение журнала
Усечение журнала в основном используется для предотвращения заполнения журнала.Усечение журнала изменяет состояние VLF файла журнала базы данных, который не содержит активных транзакций (незавершенных транзакций), на повторное использование, освобождая пространство в логическом журнале, чтобы физический журнал транзакций мог повторно использовать пространство.Если журнал транзакций никогда не усекается, он в итоге заполнит все дисковое пространство, выделенное для физического файла журнала. но,Перед усечением журнала необходимо выполнить операцию контрольной точки, чтобы записать грязные страницы и информацию журнала транзакций в текущую память из памяти на диск.
На следующих рисунках показан журнал транзакций до и после усечения. На первом рисунке показан журнал транзакций, который никогда не был усечен. В настоящее время логический журнал использует четыре виртуальных файла журнала. Логический журнал начинается до первого файла логического журнала и заканчивается в виртуальном журнале 4. Запись MinLSN находится в виртуальном журнале 3. Виртуальный журнал 1 и виртуальный журнал 2 содержат только неактивные записи журнала. Эти записи могут быть усечены. Виртуальный журнал 5 все еще не используется и не принадлежит текущему логическому журналу.

• В простом режиме восстановления происходит после контрольной точки.
• В модели полного восстановления или модели массового восстановления происходит после резервного копирования журнала (если с момента последнего резервного копирования была создана контрольная точка).

Как просмотреть записи журнала транзакций

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

После выполнения операции журнала запросов в SSMS вы можете увидеть все записи журнала. Я перехватил некоторые результаты. На рисунке несколько столбцов. Вот значения столбцов:

• CurrentLSN: текущий номер LSN. Каждая запись в журнале транзакций идентифицируется уникальным порядковым номером журнала (LSN). LSN сортируется следующим образом: если LSN2 больше, чем LSN1, изменение, описанное записью журнала, идентифицированной LSN2, происходит после изменения, описанного записью журнала LSN1.
• Операция, выполняемая соответствующим номером LSN, записывается в столбце «Операция». Несколько общих и важных значений Операции перечислены ниже:
• Начало транзакции LOP_BEGIN_XACT
• LOP_LOCK_XACT получить блокировку
• LOP_MODIFY_ROW изменить строку (конкретный измененный объект можно просмотреть в AllocUnitName)
• LOP_COMMIT_XACT совершить транзакцию
• LOP_DELETE_ROWS удалить данные
• LOP_INSERT_ROWS вставить данные
• Контекст: контекст операции.
• Имя транзакции показывает имя созданной базы данных.
• TransactoinID: идентификационный номер транзакции.
• Фиксированная длина записи журнала: фиксированная длина файла виртуального журнала, записанного LSN.
• Предыдущий номер LSN: предыдущий номер LSN.
• AllocUnitID: идентификатор единицы выделения, которой принадлежит измененный фрагмент данных
• AllocUnitName: имя таблицы измененных данных.
• Идентификатор слота: первая запись страницы данных, на которой расположены данные
• PartitionID: идентификатор раздела страницы данных, на которой расположены данные

Интеллектуальная рекомендация

Использование Mybatis paging assistant и General Mapper

Трансфер изhttps://blog.csdn.net/zbw18297786698/article/details/53945729/ 1. Представление Mybatis paging assistant 2. Использование Mybatis paging assistant 3. В программе Java установите параметры п.

64-битная целочисленная проблема

Название Описание Введите положительное целое число n, посчитайте количество его положительных множителей, n <= 10 ^ (12), например, когда n = 30, на выходе должно быть 8. Исходный код Анатомия Лог.

Кратко поговорим о шаблонах проектирования-мост

1. Что такое режим моста Режим моста (Bridge) отделяет абстрактную часть от части реализации, так что все они могут быть изменены независимо. Схема структуры UML выглядит следующим образом: Среди них .

Простое приложение Android Android (1)

Простое приложение Android Android (1) Во-первых, кратко Помните, — я не узнал простое приложение Android. (Операция дизайна учебной программы) Пример Пакет: Ссылка: https: //pan.baidu.com/s/1leq1owku.

Формат вывода строк Python

# В основном используют способ форматирования строки для вывода, в общем, строка в формате вывода.