В SQL Server я знаю, что журнал транзакций - это место, где вы можете регистрировать транзакции, прежде чем они, наконец, попадут в файл DB (или MDF). Почему мы не можем напрямую атомарно записывать транзакции в файл DB, где в случае сбоя питания мы можем откат до последнего известного согласованного состояния.Зачем использовать журнал транзакций в качестве промежуточного этапа до записи в базу данных
Каждая база данных SQL Server имеет журнал транзакций, который регистрирует все транзакции и изменения базы данных, сделанные каждой транзакцией. Журнал транзакций является критическим компонентом базы данных.
Why cant we directly atomically write transactions to the DB file where
in case of a power failure we can rollback to the last known consistent state.
Это действительно происходит, но сначала в журнал транзакций, а затем, когда совершил, получил в файл мдф, если Откат, они не хранятся в мдф.
Управление/откат управляется приложением, подключенным к базе данных.
Если произошел сбой системы, вам понадобится этот журнал, чтобы вернуть базу данных в согласованное состояние.
В журнале транзакций хранится каждая транзакция, сделанная в базе данных SQL Server, за исключением некоторых, которые минимально регистрируются как BULK IMPORT или SELECT INTO.
Может ли база данных SQL Server работать без журнала транзакций? Нет, это невозможно из-за конструкции SQL Server.
Операции резервного копирования и восстановления SQL Server происходят в контексте модели восстановления базы данных.
Существует три модели восстановления: простой, полный и объемный.
Как правило, база данных использует полную модель восстановления. Вы можете переключиться на другую модель восстановления в любое время.
Вы в безопасности, если выбрали полную модель восстановления, потому что вы можете восстановить до последней минуты до спуска системы.
для более подробной информации:
Написать вперед каротаж, который не является специфичным для SQL Server, используется в основном для повышения производительности.
Во-первых, журналы транзакций являются только приложениями, поэтому запись изменений в них не несет ответственности за определение определенных блоков в файлах данных, что может быть дорогостоящим для больших таблиц.
Во-вторых, записи журнала транзакций не обязательно содержат все измененные блоки, а скорее различия между старыми и новыми записями. Ввод/вывод данных данных выполняется во всех блоках или даже в экстентах (группы блоков), поэтому изменение даже одного байта в записи потребует записи всего блока (объема) в файл данных, что значительно увеличит объем данных, переданных в каждая сделка.
В-третьих, журналы транзакций могут использоваться для воспроизведения изменений, внесенных в базу данных с момента предыдущей резервной копии, что позволяет восстановить базу данных в произвольный момент времени или после предыдущей резервной копии. Если вы записывали изменения непосредственно в файлы данных и вдруг потеряли эти файлы (например, из-за сбоя диска), единственным вариантом было бы восстановить состояние базы данных во время предыдущей резервной копии. Это, конечно, подразумевает, что ваши журналы транзакций находятся на отдельном устройстве и в идеале мультиплексируются.
Использование TLogs, разумеется, не «используется в основном по соображениям производительности» - это механизм, гарантирующий согласованность. –
@MitchWheat - согласованность может быть гарантирована без каких-либо дополнительных журналов, просто записывая каждое изменение на диск сразу, но это может привести к гибели производительности. – mustaccio
каждое изменение записывается в TLog сразу: вы, похоже, не понимаете, как они работают. –
Любая достойная веб-статья о TLogs объяснит .... –
Можете ли вы указать мне приличную статью в Интернете? –
Не можете найти? –