Как насчет журнала транзакций Sql

Question

Я всегда думал, что журнал транзакций SQL отслеживает все транзакции, выполненные в базе данных, поэтому может помочь восстановить файл базы данных в случае неожиданного отключения питания или что-то в этом роде Итак, при нормальном использовании, когда данные фиксируются и записываются на диск, они очищаются, потому что все данные являются хорошими и безопасными в файле mdf. Увидев, что файл ldf растет и читает некоторые, я понимаю, что это не так, и он будет продолжать расти, пока: вы не сжимаете журнал. Только в этот момент все транзакции транзакции очищаются и файл журнала сжимается. Я нашел некоторых sp, кто должен это делать, но также нашел теорию, что вам сначала нужно сделать резервную копию базы данных? Этот последний шаг для меня не имеет смысла, поэтому кто-нибудь может сказать мне, что это правильно, и если да, то почему?

Answer 1

Представьте, что вы (или кто-то) запускаете delete from very_important_table в вашей производственной базе данных. Сервер Sql успешно удаляет, совершает транзакцию и, как вы предлагаете, «забыл» о транзакции.

Позже кто-то заметит, что данные ушли (после всего этого был ваш very_important_table). Вы были бы благодарны в этой ситуации. Sql Server сделал не забыл о транзакции, чтобы вы могли восстановить свою базу данных до момента, непосредственно перед (непреднамеренным) удалением! Как минимум (как упоминалось), если вы используете модель «Полное восстановление».

Это, среди прочего, журнал транзакций хранит всю эту информацию.

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

Но Я считаю, что сокращение журнала транзакций должно быть чем-то для чрезвычайных ситуаций. При нормальной работе вы должны «знать» (или догадываться), насколько большой журнал транзакций будет получен через определенное количество времени (прочитайте: в промежутках между резервными копиями журналов!) И назначьте ему столько места (плюс некоторый запас может быть хорошим идея). Затем вы отключите автоматическое увеличение (или измените его как минимум) и установите предупреждение, когда транзакция станет «слишком большой» (скажем, 80% того, что вы задали как размер, если вы дали ему 50% или 100% запаса). Тогда у вас есть время отреагировать, если что-то пойдет не так.

Помните (как писали другие): резервная копия (журнал) не «сжимает» файл журнала, а просто «пуст». Вы по-прежнему будете видеть одинаковый размер файла в файловой системе, но в нем есть свободное место (DBCC SQLPERF(logspace) покажет вам это).

Если у вас включен автоматический рост, журнал просто заполнит ваш диск, если вы не знаете, и когда диск будет заполнен - ​​bam - ничего не вы можете сделать (в худшем случае даже не резервное копирование или сжатие журнала!).

То, что я пытаюсь сказать, следующее: это непростая тема. Помните!

Может быть, эта статья Microsoft обеспечит отправную точку: How to Stop the transaction log of a SQL Server database from growing unexpectedly

Edit: бы этот вопрос лучше всего подходит для serverfault?

Answer 2

Это зависит от модели восстановления резервной копии.

Возможно, все, что вам нужно или нужно знать, можно найти в this KB article.

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

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

Answer 3

Чтобы восстановить базу данных, в основном сделать следующее:

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

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

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

Answer 4

у вас есть состояние базы данных x, то вы добавляете транзакции y, тогда вы сокращаете транзакцию в 2 раза, поэтому у вас будет только состояние базы данных x + (y/2). если у вас нет резервной копии, у вас нет способа учесть эту недостающую половину y. другими словами, всегда делайте резервную копию. единственным реальным исключением является дублирование базы данных при вводе записей, и вы можете приостановить такой процесс дублирования при сокращении журнала транзакций.

Answer 5

FYI: Когда вы сокращаете журнал транзакций, освобождается место для новых транзакций, оно не освобождает место в файловой системе.

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