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

The mirroring feature uses the log to keep track of things until it knows that the other server has those changes. So, no, the ldf is not just for point-in-time recovery. (It's also important for some replication schemes, but you aren't doing that.) Even TRUNCATE_ONLY will not throw away logged changes for stuff that SQL might need. The classic example is some large or long-running transaction. If you are halfway through an hour-long transaction and a DBA runs TRUNCATE_ONLY, your stuff won't be purged from the LDF. The LDF may continue to grow or experience other problems. If the DBA kills your connection, waits for the rollback to finish and then runs TRUNCATE_ONLY, then the log should free up.

Have you tried using:

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

to see why the log is so large? Microsoft documents that system table here.

You can also run :

dbcc opentran() 

This is kind of old-school, but it should show you any long-running transactions in that database. Microsoft documents that command here.

I would do is make sure that there is a log backup happening on a schedule.

I would make sure that I give the TRUNCATE_ONLY command a little time to work, sometimes it takes a while for SQL to start writting to a VLF towards the front of the LDF file. If the last VLF in the LDF file is the one that is being written to, then SQL can't shorten the file. Failing that, I'd do a full BACKUP DATABASE (with COPY_ONLY, or wait until the regular backup happens, if that isn't too far off in the future). Sometimes that seems to kick start things, but it might just be that a backup distracts me while waiting for the current VLF to move to the front of the LDF file. After the current VLF moves towards the front of the LDF file, you should be able to use dbcc shrinkfile() and get the expected result. I'd recommend trying to remove small chunks first, rather than trying to do it all in one shot.

Also, you want to avoid doing this on a regular basis, as getting into a repetitive shrink-autogrow-shrink-autogrow cycle can be a performance killer. (It can lead to fragmented files and the actual growth process can take a surprising amount of time, during which no transaction would be able to commit. Grow your files large enough so that they don't autogrow. Autogrow should be a failsafe thing and not relied on.

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

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

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

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

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

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