Как очистить журнал транзакций SQL Server?

https://stackoverflow.com/questions/56628

09-06-2019
|

Вопрос

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

Решение

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

Сначала сделайте полную резервную копию

Никогда не вносите никаких изменений в свою базу данных, не убедившись, что вы сможете восстановить ее, если что-то пойдет не так.

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

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

Предположительно ваша база данных находится в FULL режим восстановления.Если нет, то убедитесь, что это:

ALTER DATABASE testdb SET RECOVERY FULL;

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

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Обратите внимание, что \\backup_share\ должен находиться на другой машине, которая представляет собой другое базовое устройство хранения.Резервное копирование их на одну и ту же машину (или на другую машину, которая использует те же базовые диски, или на другую виртуальную машину, находящуюся на том же физическом хосте) на самом деле вам не поможет, поскольку, если машина взорвется, вы потеряете свою базу данных. и его резервные копии.В зависимости от вашей сетевой инфраструктуры может иметь смысл выполнить резервное копирование локально, а затем незаметно перенести его в другое место;в любом случае вам нужно как можно быстрее удалить их с основного компьютера базы данных.

Теперь, когда у вас регулярно выполняется резервное копирование журналов, будет разумно сжать файл журнала до чего-то более разумного, чем то, что он сейчас раздул.Это делает нет значит бег SHRINKFILE снова и снова, пока размер файла журнала не достигнет 1 МБ — даже если вы часто выполняете резервное копирование журнала, он все равно должен учитывать сумму любых одновременных транзакций, которые могут произойти.События автоматического увеличения файлов журнала являются дорогостоящими, поскольку SQL Server должен обнулять файлы (в отличие от файлов данных, когда включена мгновенная инициализация файлов), а пользовательским транзакциям приходится ждать, пока это произойдет.Вы хотите как можно меньше выполнять эту рутину роста-уменьшения-уменьшения и, конечно же, не хотите, чтобы ваши пользователи платили за это.

Обратите внимание: вам может потребоваться дважды создать резервную копию журнала, прежде чем станет возможным сжатие (спасибо, Роберт).

Итак, вам нужно придумать практичный размер файла журнала.Никто здесь не может сказать вам, что это такое, не зная больше о вашей системе, но если вы часто сжимали файл журнала, и он снова увеличивался, хороший водяной знак, вероятно, на 10-50% выше, чем самый большой, который он был. .Допустим, размер файла составляет 200 МБ, и вы хотите, чтобы размер всех последующих событий автоматического увеличения составлял 50 МБ, тогда вы можете настроить размер файла журнала следующим образом:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Обратите внимание: если размер файла журнала в настоящее время> 200 МБ, вам может потребоваться сначала запустить это:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Если вас не волнует восстановление на определенный момент времени

Если это тестовая база данных и вас не интересует восстановление на определенный момент времени, вам следует убедиться, что ваша база данных находится в SIMPLE режим восстановления.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Вставляем базу данных SIMPLE Режим восстановления гарантирует, что SQL Server повторно использует части файла журнала (по сути, постепенно прекращая неактивные транзакции) вместо того, чтобы увеличивать его для хранения записей. все транзакции (например, FULL восстановление выполняется до тех пор, пока вы не создадите резервную копию журнала). CHECKPOINT События помогут контролировать журнал и гарантировать, что он не будет расти, если только вы не создадите много активности t-log между CHECKPOINTс.

Затем вы должны быть абсолютно уверены, что этот рост журнала действительно произошел из-за аномального события (скажем, ежегодной весенней очистки или восстановления ваших крупнейших индексов), а не из-за нормального повседневного использования.Если вы уменьшите файл журнала до смехотворно маленького размера, а SQL Server просто придется снова увеличить его, чтобы приспособиться к вашей обычной деятельности, что вы получите?Смогли ли вы использовать освободившееся дисковое пространство только временно?Если вам нужно немедленное исправление, вы можете запустить следующее:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO

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

Некоторые вещи, которые вы не хотите делать

Создайте резервную копию журнала с помощью TRUNCATE_ONLY вариант, а затем SHRINKFILE.Во-первых, это TRUNCATE_ONLY Этот параметр устарел и больше не доступен в текущих версиях SQL Server.Во-вторых, если вы находитесь в FULL модель восстановления, это приведет к разрушению цепочки журналов и потребует создания новой полной резервной копии.
Отсоедините базу данных, удалите файл журнала и повторно присоедините..Я не могу подчеркнуть, насколько это может быть опасно.Ваша база данных может не восстановиться, она может оказаться подозрительной, возможно, вам придется вернуться к резервной копии (если она у вас есть) и т. д.и т. д.
Используйте опцию «Сжать базу данных». DBCC SHRINKDATABASE и возможность плана обслуживания сделать то же самое — плохая идея, особенно если вам действительно нужно только решить проблему с журналом.Выберите файл, который хотите настроить, и настройте его независимо, используя DBCC SHRINKFILE или ALTER DATABASE ... MODIFY FILE (примеры выше).
Уменьшите файл журнала до 1 МБ..Это выглядит заманчиво, потому что SQL Server позволит мне сделать это в определенных сценариях и посмотреть, сколько места он освобождает!Если ваша база данных не доступна только для чтения (а это так, вы должны пометить ее как таковую, используя ALTER DATABASE), это абсолютно просто приведет к множеству ненужных событий роста, поскольку журнал должен учитывать текущие транзакции независимо от модели восстановления.Какой смысл временно освобождать это пространство только для того, чтобы SQL Server мог медленно и болезненно вернуть его обратно?
Создайте второй файл журнала.Это временно облегчит работу накопителя, заполнившего ваш диск, но это все равно что пытаться заклеить проколотое легкое пластырем.Вам следует разобраться с проблемным файлом журнала напрямую, а не просто добавлять еще одну потенциальную проблему.Помимо перенаправления некоторых действий журнала транзакций на другой диск, второй файл журнала действительно ничего вам не дает (в отличие от второго файла данных), поскольку одновременно можно использовать только один из файлов. Пол Рэндал также объясняет, почему несколько файлов журналов могут вас укусить позже..

Быть инициативным

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

Наихудшие возможные настройки здесь — рост на 1 МБ или рост на 10%.Как ни странно, это значения по умолчанию для SQL Server (на которые я жаловался и просил внести изменения, но безрезультатно) — 1 МБ для файлов данных и 10 % для файлов журналов.Первый слишком мал в наше время, а второй каждый раз приводит к все более и более длительным событиям (скажем, ваш файл журнала составляет 500 МБ, первый рост — 50 МБ, следующий рост — 55 МБ, следующий рост — 60,5 МБ. , и т. д.и т. д.- и при медленном вводе-выводе, поверьте, вы действительно заметите эту кривую).

дальнейшее чтение

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

Сообщение в блоге, которое я написал в 2009 году, когда увидел несколько сообщений типа «вот как сжать файл журнала»..

Сообщение в блоге Брент Озар написал четыре года назад, указывая на несколько ресурсов в ответ на статью в журнале SQL Server Magazine, которая должна нет были опубликованы.

Сообщение в блоге Пола Рэндала, объясняющее, почему важно поддерживать t-log. и почему вам также не следует сжимать файлы данных.

У Майка Уолша есть отличный ответ, охватывающий некоторые из этих аспектов, в том числе причины, по которым вы не сможете немедленно сжать файл журнала..

Другие советы

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Пожалуйста, внимательно прочитайте комментарии ниже, и я предполагаю, что вы уже прочитали принятый ответ.Как я сказал почти 5 лет назад:

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

Щелкните правой кнопкой мыши имя базы данных.
Выберите «Задачи» → «Сжать» → «База данных».
Затем нажмите ХОРОШО!

Обычно я открываю каталог Windows Explorer, содержащий файлы базы данных, чтобы сразу увидеть эффект.

На самом деле я был очень удивлен, что это сработало!Обычно я раньше использовал DBCC, но я только что попробовал это, и ничего не сжалось, поэтому я попробовал графический интерфейс (2005), и он сработал отлично: освободилось 17 ГБ за 10 секунд.

В режиме полного восстановления это может не работать, поэтому вам придется либо сначала создать резервную копию журнала, либо перейти на простое восстановление, а затем сжать файл.[спасибо @onupdatecascade за это]

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

USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

От: DBCC SHRINKFILE (Transact-SQL)

Возможно, вы захотите сначала сделать резервную копию.

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

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

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

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

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

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

«Невозможно уменьшить файл журнала (имя файла журнала), потому что файл логического журнала, расположенный в конце файла, используется»

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

Если вы не используете журналы транзакций для восстановления (т.Вы всегда делаете только полное резервное копирование), вы можете установить для режима восстановления значение «Простой», и журнал транзакций очень скоро сократится и никогда больше не заполнится.

Если вы используете SQL 7 или 2000, вы можете включить «обрезать контрольную точку журнала» на вкладке параметров базы данных.Это имеет тот же эффект.

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

Вот простой и очень неэлегантный & потенциально опасный способ.

Резервная БД
Отсоединить БД
Переименовать файл журнала
Прикрепить БД
Новый файл журнала будет воссоздан.
Удалить переименованный файл журнала.

Я предполагаю, что вы не делаете резервные копии журналов.(Что обрезает журнал).Мой совет - изменить модель восстановления с полный к простой.Это предотвратит раздувание журналов.

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

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

Из Статья Microsoft оBACKUP

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

Чтобы избежать этого, сделайте резервную копию файла журнала. на диск прежде чем сжимать его.Синтаксис будет выглядеть примерно так:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

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

Помимо ответов на этот вопрос, я рекомендую прочитать и понять распространенные мифы о журнале транзакций.Эти показания могут помочь понять журнал транзакций и решить, какие методы использовать для его «очистки»:

От 10 самых важных мифов о журнале транзакций SQL Server:

Миф:Мой SQL-сервер слишком занят.Я не хочу делать резервные копии журнала транзакций SQL Server.

Одной из самых ресурсоемких операций в SQL Server является событие автоматического увеличения файла журнала онлайн-транзакций.Если резервные копии журнала транзакций не создаются достаточно часто, онлайн-журнал транзакций переполнится и ему придется расти.Размер роста по умолчанию составляет 10%.Чем более оживленная база данных, тем быстрее журнал онлайн-транзакций будет расти, если резервные копии журнала транзакций не создаются, создавая резервное резервное копирование журнала транзакций транзакций SQL Server, не блокирует онлайн-журнал транзакций, но событие автоматического роста делает.Он может блокировать всю активность в журнале онлайн-транзакций.

От Мифы о журнале транзакций:

Миф:Регулярная усадка бревен — хорошая практика обслуживания.

ЛОЖЬ.Рост журнала обходится очень дорого, поскольку новый фрагмент должен быть обнулен.Вся активность записи в эту базу данных прекращается до тех пор, пока не будет завершено обнуление, и если запись на диск происходит медленно или размер автоматического увеличения велик, эта пауза может быть огромной, и пользователи это заметят.Это одна из причин, почему вы хотите избежать роста.Если вы сожмете журнал, он снова вырастет, и вы просто тратите работу диска на ненужную игру «сжимать и снова увеличивать».

Этот метод, который рекомендует Джон, не рекомендуется, поскольку нет гарантии, что база данных будет подключена без файла журнала.Измените базу данных с полной на простую, принудительно установите контрольную точку и подождите несколько минут.SQL Server очистит журнал, который затем можно сжать с помощью DBCC SHRINKFILE.

Сначала проверьте модель восстановления базы данных.По умолчанию SQL Server Express Edition создает базу данных для простой модели восстановления (если я не ошибаюсь).

Имя базы данных журнала резервного копирования с Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

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

Ссылаться на:

Восстановление из полного журнала транзакций в базе данных SQL Server.

Если ваша база данных находится в модели полного восстановления и вы не создаете резервную копию TL, измените ее на SIMPLE.

Использовать DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY) команда.Если это тестовая база данных и вы пытаетесь сохранить/освободить место, это поможет.

Однако помните, что журналы TX имеют своего рода минимальный/стационарный размер, до которого они будут расти.В зависимости от вашей модели восстановления вы, возможно, не сможете сжать журнал — если он установлен в ПОЛНОМ режиме и вы не создаете резервные копии журнала TX, журнал невозможно сжать — он будет расти вечно.Если вам не нужны резервные копии журналов TX, измените модель восстановления на Простой.

И помните, никогда, ни при каких обстоятельствах не удаляйте файл журнала (LDF)!Вы практически сразу же повредите базу данных.Приготовлено!Сделанный!Потеряны данные!Если оставить «невосстановленный» основной файл MDF, он может быть навсегда поврежден.

Никогда не удаляйте журнал транзакций — вы потеряете данные!Часть ваших данных находится в журнале TX (независимо от модели восстановления)...если вы отсоедините и «переименуете» файл журнала TX, который эффективно удаляет часть вашей базы данных.

Тем, кто удалил журнал TX, возможно, потребуется запустить несколько команд checkdb и исправить повреждение, прежде чем вы потеряете больше данных.

Прочтите сообщения в блоге Пола Рэндала на эту тему: плохой совет.

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

Посетите сайт Пола – он освещает именно эти вопросы.В прошлом месяце он рассмотрел многие из этих вопросов в своем Миф один день ряд.

Чтобы обрезать файл журнала:

Резервное копирование базы данных
Отсоедините базу данных либо с помощью Enterprise Manager, либо выполнив: Sp_DetachDB [имя_БД]
Удалите файл журнала транзакций.(или переименуйте файл на всякий случай)
Снова подключите базу данных, используя: Sp_AttachDB [имя_БД]
При подключении базы данных создается новый файл журнала транзакций.

Чтобы сжать файл журнала:

Резервное копирование журнала [DBName] с No_Log
Уменьшите базу данных одним из следующих способов:

Используя Enterprise Manager:- Щелкните правой кнопкой мыши базы данных, все задачи, сокращение базы данных, файлы, выберите файл журнала, ОК.

Использование T-SQL: -Сжатый файл Dbcc ([Log_Logical_Name])

Логическое имя файла журнала можно найти, запустив sp_helpdb или просмотрев свойства базы данных в Enterprise Manager.

По моему опыту, на большинстве SQL-серверов нет резервной копии журнала транзакций.Полное или дифференциальное резервное копирование является обычной практикой, но резервное копирование журнала транзакций делается очень редко.Таким образом, файл журнала транзакций растет вечно (пока диск не заполнится).В этом случае модель восстановления должно быть установлено значение "простой".Не забудьте также изменить системные базы данных «model» и «tempdb».

Резервное копирование базы данных «tempdb» не имеет смысла, поэтому модель восстановления этой базы данных всегда должна быть «простой».

Сделайте резервную копию файла MDB.
Остановить службы SQL
Переименуйте файл журнала
Запустить службу

(Система создаст новый файл журнала.)

Удалите или переместите переименованный файл журнала.

Попробуй это:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO

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

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

Резервная БД
Отсоединить БД
Переименовать файл журнала
Присоедините БД (при прикреплении удалите переименованный .ldf (файл журнала). Выделите его и удалите, нажав кнопку «Удалить»)
Новый файл журнала будет воссоздан.
Удалить переименованный файл журнала.

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

Пример:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Это случилось со мной, когда файл журнала базы данных имел размер 28 ГБ.

Что вы можете сделать, чтобы уменьшить это?На самом деле файлы журналов — это файлы данных, которые SQL-сервер сохраняет после совершения транзакции.Для обработки транзакции SQL-сервер выделяет для нее страницы.Но после завершения транзакции они не освобождаются внезапно в надежде, что может произойти такая же транзакция.Это удерживает пространство.

Шаг 1:Сначала запустите эту команду в запросе базы данных. Изученная контрольная точка

Шаг 2:Щелкните правой кнопкой мыши задачу базы данных> Резервное копирование выберите ВЫБЕРИТЕ РАЗРЕШЕНИЯ Тип в качестве журнала транзакции Добавьте адрес назначения и имя файла, чтобы сохранить данные резервного копирования (.bak)

Повторите этот шаг еще раз и на этот раз укажите другое имя файла.

Шаг 3:Теперь перейдите в базу данных правой кнопкой мыши в базе данных

Задачи> Сократывания> Файлы Выберите тип файла в качестве действия в журнале «Сокращение» в качестве выпуска неиспользованного пространства

Шаг 4:

Обычно проверяйте свой файл журнала в SQL 2014, это можно найти в

C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQL2014EXPRESS\MSSQL\DATA

В моем случае его уменьшили с 28 ГБ до 1 МБ.

Некоторые другие ответы мне не помогли:Невозможно было создать контрольную точку, пока база данных была в сети, потому что журнал транзакций был полон (как иронично).Однако после перевода базы данных в аварийный режим мне удалось сжать файл журнала:

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

Журнал транзакций БД Уменьшить до минимального размера:

Резервное копирование:Журнал транзакций
Сжать файлы:Журнал транзакций
Резервное копирование:Журнал транзакций
Сжать файлы:Журнал транзакций

Я провел тесты на нескольких БД: эта последовательность работает.

Обычно это сжимается до 2 МБ.

ИЛИ по сценарию:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow