Уменьшает ли резервное копирование базы данных размер журнала транзакций?


8

Я пытаюсь собрать некоторые знания о базах данных SQL, и у меня есть несколько вопросов о файле журнала транзакций (LDF).

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

Насколько я понимаю, резервное копирование базы данных:

  1. Усекает журнал транзакций и
  2. Уменьшает размер

файла LDF на диске путем «очистки» журналов внутри него.

Теперь кажется, что я не правильно понял это, потому что файл журнала, кажется, имеет фиксированный размер. Мой актуальный вопрос звучит так:

Что в действительности делает усечение журналов с файлом журнала (LDF)? Этот процесс должен предотвращать переполнение дисков.

Пожалуйста, исправьте меня, если я не правильно понимаю некоторые понятия.

Спасибо!

Ответы:


20

Файл журнала транзакций (LDF) состоит из множества виртуальных файлов журнала (VLF) внутри. Думайте об этом как о шкафу с несколькими выдвижными ящиками. Вы можете выбрать большой или маленький шкаф - но он все равно будет фиксированного размера с разным количеством ящиков.

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

Когда вы создаете резервную копию журнала транзакций, вы действительно делаете следующее:

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

Резервные копии не меняют размер вашего кабинета (файл журнала).


Привет, Брент, спасибо, что разъяснили мне это, ценю! В общем, вы не можете уменьшить размер «шкафа», вы можете только опустошить ящики. Сейчас я читаю много постов людей, говорящих о том, чтобы уменьшить размер журнала. Относится ли это к уменьшению размера VLF (содержимого ящика) и фактическому уменьшению размера файла LDF на диске? Из того, что я могу теперь понять, вы не можете уклониться от «кабинета». Спасибо!
Энтони

@ Энтони, да, вы можете уменьшить размер шкафа, уменьшив размер файла журнала, но, как правило, это очень плохая идея (по причинам, о которых вы читали.)
Брент Озар

Я бы наложил вето на утверждение, что сокращение TLog - это плохо. Доступ к Tlog довольно последовательный. в природе. При сжатии журнала не требуется реорганизация данных (как для файлов данных. Вы можете освободить пространство только после последнего активного указателя). Так что это не вызывает никакой фрагментации вообще.
Хайко Хатцфельд

1
@HeikoHatzfeld его восстановление - блокирующая операция, которая не использует мгновенную инициализацию файлов, поэтому она очень медленная. Вето отменено. ;-)
Брент Озар

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

6

Сопоставление и смешивание

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

Объясняя

В файле журнала транзакций ядро ​​базы данных хранит изменения, внесенные в данные в базе данных, независимо от того, находится ли база данных в модели восстановления SIMPLE или в модели восстановления FULL. (Важный)

Теперь файл журнала транзакций базы данных - это не просто один контейнер непрерывного хранения, а набор виртуальных файлов журнала (VLF), которые создаются в последовательном порядке внутри файла журнала транзакций (TLog). Размер VLF варьируется в зависимости от того, какую версию SQL Server вы используете в настоящее время, а также от начального размера, выбранного вами при создании файла TLog, а также от того, какой размер вы выбрали (если есть) для параметра автоматического увеличения TLog файл.

Ссылки:
- Важное изменение в алгоритме создания VLF в SQL Server 2014 (SQLSkills.com)
- Начальные порядковые номера VLF и размер файла журнала по умолчанию (SQLSkills.com)
- Внутри механизма хранения: подробнее о циклическом характере журнала (SQLSkills). ком)
... а может и в обратном порядке

Когда данные изменяются в базе данных, компонент Database Engine запишет эти изменения в TLog соответствующей базы данных для обеспечения согласованности транзакций. Это также известно как КИСЛОТА - атомарность, согласованность, изоляция, долговечность . Фактические переводы этих изменений хранятся в VLF-файлах TLog (файла). Когда VLF заполнен, самые новые транзакции будут храниться в следующем доступном VLF в последовательном порядке.

Исключения

Однако, если достигнут конец файла TLog, изменения будут сохранены в первом VLF в начале файла TLog. (объяснено в Inside the Storage Engine: подробнее о круговой природе бревна )

Если нет доступных VLF для хранения новых транзакций и если настроен параметр автоматического роста, компонент Database Engine будет увеличивать файл TLog на определенную величину и создавать дополнительные VLF в зависимости от размера, определенного в настройках автоматического роста и формулы объяснено в разделе Важное изменение алгоритма создания VLF в SQL Server 2014 . Дальнейшие транзакции могут быть сохранены в следующем VLF внутри файла TLog.

Резервное копирование файла TLog

Когда вы запускаете резервное копирование файла TLog, все, что вы делаете, это говорите ядру базы данных:

  • взгляните на файл TLog
  • определить, когда произошла последняя резервная копия журнала транзакций (LSN: порядковый номер журнала; для дальнейшего исследования)
  • установить контрольную точку в файле TLog ( контрольные точки базы данных (SQL Server) )
  • сохраните резервную копию файла TLog на диске / ленте, отслеживая предыдущий LSN и последний переданный LSN непосредственно перед завершением резервного копирования
  • перенести все модификации в «базу данных»
  • пометить VLF как многоразовые

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

Автоматическое усечение файла TLog

... но если у компонента Database Engine есть несколько свободных циклов, и он не находится под очень сильным давлением, он иногда просматривает файл TLog, замечает Checkpoint и освобождает VLF для повторного использования. Пространство внутри файла TLog все еще используется VLF (того же размера, того же места), но они могут свободно использоваться повторно.

Это задокументировано в разделе «Усечение журнала транзакций» :

За исключением случаев задержки по какой-либо причине, усечение журнала происходит автоматически следующим образом: - В простой модели восстановления после контрольной точки.

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

Есть несколько случаев, когда этого не происходит:

Хотя автоматическое усечение журнала может быть отложено из-за множества факторов. Для получения информации о том, что может задержать усечение журнала, см. Факторы, которые могут задержать усечение журнала .

Визуализация усечения журнала

Усечение журнала можно наблюдать, когда вы запрашиваете размер TLog с помощью операторов SQL или отчета о пространстве базы данных в пользовательском интерфейсе SSMS. Вы можете заметить, что используемое пространство внутри файла TLog может составлять только 1% от доступного размера файла TLog.

Уменьшить или не уменьшить

Общая рекомендация - не сокращать файл TLog, потому что он вырос по определенной причине и, возможно, снова увеличится до того размера, который был когда-то. Но это история для другого поста. Есть несколько веских причин, одна из которых - когда вы воссоздаете размер VLF внутри вашего файла TLog.

Отвечая на ваши вопросы

Встроенный прямо под ваши предположения и вопросы

Насколько я понимаю, резервное копирование базы данных:

  • Усекает журнал транзакций и

Это неверное предположение. Резервное копирование вашей базы данных (FULL, DIFFERENTIAL) ничего не делает с файлами TLog. Полная резервная копия создаст согласованное состояние вашей базы данных вместе с подтвержденными транзакциями из файла TLog. Резервная копия DIFF создаст согласованное состояние всех прошлых резервных копий TLog с момента последней полной резервной копии вашей базы данных.

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

  • Уменьшает размер

Нет, при рассмотрении резервных копий FULL и DIFF. Нет, при рассмотрении резервных копий TLOG, но это освободит VLF внутри файла TLog, если у ядра базы данных есть свободное время.

Что в действительности делает усечение журналов с файлом журнала (LDF)? Этот процесс должен предотвращать переполнение дисков.

Усечение журналов позволяет использовать VLF повторно. Это все.

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

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


4

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

Насколько я понимаю, резервное копирование базы данных:

  • Усекает журнал транзакций и
  • Уменьшает размер

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

Это также не уменьшает журнал транзакций. Для сокращения логов вы должны использовать dbcc shrinkfileкоманду

Что в действительности делает усечение журналов с файлом журнала (LDF)? Этот процесс должен предотвращать переполнение дисков.

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

Прочитав ответ, я настоятельно рекомендую прочитать о журнале транзакций на SQLSKILLS.com.


Спасибо Шанки, очень ценю ваши объяснения! Поэтому, когда резервные копии усекают журналы, они на самом деле не уменьшают размер файла LDF, они только «освобождают место» для других транзакций, которые будут обрабатываться внутри этого файла журнала. Правильно ли я предположил это? Спасибо!
Энтони

Вы абсолютно правы.
Шэнки
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.