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

Это более старый вопрос, но есть некоторые вещи, которые не были хорошо объяснены, и мы надеемся, что это прольет свет. В основном был дан ответ на вопрос, как сжать, но это объяснит часть того, что вы на самом деле делаете, «почему».

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

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

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

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

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

Функция зеркалирования использует журнал для отслеживания событий, пока не узнает, что на другом сервере есть эти изменения. Итак, нет, ldf не предназначен только для восстановления на определенный момент времени. (Это также важно для некоторых схем репликации, но вы этого не делаете.) Даже TRUNCATE_ONLY не отбрасывает зарегистрированные изменения для вещей, которые могут понадобиться SQL. Классический пример - это какая-то крупная или длительная транзакция. Если вы прошли половину часовой транзакции и администратор базы данных выполняет TRUNCATE_ONLY, ваши данные не будут удалены из LDF. LDF может продолжать расти или испытывать другие проблемы. Если администратор баз данных прервет ваше соединение, ждет завершения отката и затем запустит TRUNCATE_ONLY, журнал должен освободиться.

Вы пробовали использовать:

select log_reuse_wait_desc from sys.databases where name = 'mydb' 

чтобы понять, почему журнал такой большой? Microsoft документирует эту системную таблицу Вот.

Вы также можете запустить:

dbcc opentran() 

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

Я бы сделал, чтобы убедиться, что резервное копирование журнала выполняется по расписанию.

Я бы позаботился о том, чтобы дать команде TRUNCATE_ONLY немного времени, чтобы поработать, иногда требуется время, чтобы SQL начал запись в VLF в начале файла LDF. Если последний VLF в файле LDF - это тот, в который выполняется запись, то SQL не может сократить файл. В противном случае я бы сделал полное РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ (с COPY_ONLY или подождал, пока не произойдет регулярное резервное копирование, если это не так уж и далеко в будущем). Иногда кажется, что это запускает вещи, но может быть просто резервная копия отвлекает меня, ожидая, пока текущий VLF переместится в начало файла LDF. После того, как текущий VLF переместится в начало файла LDF, вы сможете использовать dbcc shrinkfile () и получить ожидаемый результат. Я бы рекомендовал сначала попытаться удалить небольшие куски, чем пытаться сделать все за один раз.

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

Сделайте резервную копию журнала транзакций, любым методом, который вам удобнее всего.

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

Согласно другой части вашего вопроса ... нет, не совсем. Да, они выполняют эту функцию, но не только эту функцию.

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

Журналы транзакций - это записи каждой «транзакции», выполненной базой данных. Вместо того, чтобы записывать в файл базы данных каждый раз, когда запись изменяется, обновляется, добавляется, удаляется и т. Д., Эти действия записываются в отдельный файл, журнал транзакций, а затем фиксируются в файле базы данных, когда сервер SQL определяет, что это безопасно. сделать это, не останавливая какую-либо деятельность. Таким образом, журналы транзакций, по сути, являются местом, куда вносятся изменения в базе данных, прежде чем они фактически станут изменениями в базе данных [файле].

Итак, если вам нужно вернуться к заданному состоянию базы данных или моменту времени, журналы транзакций «воспроизводятся». По сути, не копирование данных файла, а переход к самому последнему состоянию на определенный момент времени, найденному для базы данных, а затем выполнение всех тех же действий, которые привели базу данных в указанное [более позднее] состояние. Но важно отметить, что в любой момент ваши журналы транзакций будут содержать транзакции, которые еще не были зафиксированы в базе данных. Так что это больше, чем просто возможность выполнять восстановление на определенный момент времени. Они содержат [некоторые] изменения, которые вносятся или будут вскоре внесены в базу данных.

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

Однако это может занять некоторое время, в зависимости от размера журналов транзакций. Если вы никогда не делали этого раньше, приготовьтесь, это займет некоторое время.