Самый простой способ сжать файлы журнала транзакций в зеркальной рабочей базе данных
Какой самый простой способ сжать файл журнала транзакций в зеркальной рабочей базе данных?
Я должен, так как мое дисковое пространство заканчивается.
Я сделаю полное резервное копирование базы данных, прежде чем сделать это, поэтому мне не нужно ничего сохранять в журнале транзакций (верно? У меня ежедневное полное резервное копирование базы данных, вероятно, никогда не потребуется восстановление на определенный момент времени, хотя я буду сохранять опция открыта, если я могу - это все, для чего действительно нужен.ldf, правильно?).
Решено:
Хорошо, после выполнения 2 резервных копий через SSMS (не TSQL) только из журнала, создавая совершенно новый набор резервных копий, диалоговое окно Shrink-Files-Log в SSMS наконец-то заработало, освободив некоторое место на диске.
Не уверен, почему 2 резервные копии, где это было необходимо, или почему TSQL не работал, и не было никакой разницы в сообщаемом "доступном для освобождения месте" в диалоговом окне сжатия (оно составляло 99% для всех попыток сжатия после первого резервного копирования). тоже, но все еще не освободил место), но проблема решена на данный момент. Спасибо всем.
3 ответа
Сделайте резервную копию журнала транзакций любым удобным для вас способом.
Это приведет к удалению журналов транзакций, которые уже были зафиксированы в базе данных, с диска. В идеале вы должны создать задачу обслуживания базы данных, чтобы выполнять ее для вас периодически по именно этой причине - чтобы исключить старые журналы транзакций, чтобы вы не заполнили свой диск.
По другой части вашего вопроса... нет, не совсем. Да, они выполняют эту функцию, но не только эту функцию.
Резервное копирование баз данных (или запись в них) осуществляется не традиционным способом, как в других файлах, поскольку сам файл базы данных постоянно используется и постоянно изменяется. Таким образом, одно резервное копирование "на определенный момент времени" потребует либо перевода базы данных в автономный режим, чтобы "заморозить" ее в согласованном состоянии, либо привести к тому, что другие части резервной копии будут содержать данные, отличные от тех, которые были при запуске резервного копирования.
Журналы транзакций - это записи каждой "транзакции", выполненной базой данных. Вместо записи в файл базы данных каждый раз, когда запись изменяется, обновляется, добавляется, удаляется и т. Д., Эти действия записываются в отдельный файл, журнал транзакций, а затем фиксируются в файле базы данных, когда сервер SQL определяет, что это безопасно. сделать это, не останавливая какую-либо деятельность. Таким образом, журналы транзакций, по сути, являются тем, где изменения в базе данных идут до того, как они фактически становятся изменениями в базе данных [файл].
Таким образом, если вам нужно вернуться к заданному состоянию базы данных или моменту времени, журналы транзакций "воспроизводятся". По сути, не копирование данных файла, а переход к самому последнему состоянию на момент времени, найденному для базы данных, а затем выполнение тех же действий, которые привели базу данных к указанному [более позднему] состоянию. Но важно отметить, что в любой момент ваши журналы транзакций будут содержать транзакции, которые еще не были зафиксированы в базе данных. Таким образом, они представляют собой нечто большее, чем просто возможность восстановления на определенный момент времени. Они содержат [некоторые] изменения, которые вносятся или будут вскоре внесены в базу данных.
Вот почему вы вынуждены делать резервное копирование перед очисткой журналов транзакций - после того, как резервное копирование выполнено, система имеет копию базы данных на определенный момент времени для ссылки для любых будущих восстановлений и может определить, какие транзакции имеют были зафиксированы в базе данных, а какие нет. И с этой информацией система знает, какие устаревшие журналы транзакций удалить для вас, а какие нет.
Однако это может занять некоторое время, в зависимости от размера журналов транзакций. Если вы никогда не делали этого раньше, приготовьтесь, это займет некоторое время.
Это более старый вопрос, но есть некоторые вещи, которые не были хорошо объяснены, и это, мы надеемся, поможет пролить свет. Ответ на вопрос, как сжиматься, в основном был, но это объяснит часть "почему" того, что вы на самом деле делаете.
Резервные копии, в частности, резервные копии журналов, делают несколько вещей. Данные записываются на диск как резервный набор для последующего использования или сбрасываются по мере необходимости. Каждая последующая резервная копия добавляется в этот набор в полностью зарегистрированной БД. Усечение журнала или запуск нового резервного набора разрывает цепочку и ограничивает, или во многих случаях сводит на нет вашу способность к восстановлению до момента времени, когда цепочка не была разорвана.
Данные в журнале фактически не удаляются, а файл журнала не сокращается во время резервного копирования. Активные 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() и получить ожидаемый результат. Я бы порекомендовал сначала попытаться удалить небольшие куски, а не пытаться делать все это одним выстрелом.
Кроме того, вы хотите избежать этого на регулярной основе, так как повторение цикла shrink-autogrow-shrink-autogrow может привести к снижению производительности. (Это может привести к фрагментированным файлам, и сам процесс роста может занять удивительное количество времени, в течение которого ни одна транзакция не сможет зафиксировать. Вырастите ваши файлы достаточно большими, чтобы они не росли автоматически. Автостров должен быть безопасным и не полагался.