Я не эксперт по 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 между CHECKPOINTs.

Затем вы должны быть абсолютно уверены в том, что этот рост журнала действительно произошел из-за ненормального события (скажем, ежегодной весенней уборки или восстановления ваших самых больших показателей), а не из-за обычного ежедневного использования. Если вы сократите файл журнала до смехотворно небольшого размера, а 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, которая не должна была быть опубликована .

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

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

-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


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)

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

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

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

• Щелкните правой кнопкой мыши на имени базы данных.

• Выберите Задачи → Сжать → База данных.

• Тогда нажмите OK!

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

Я был очень удивлен, что это сработало! Обычно я использовал DBCC раньше, но я просто попробовал это, и он ничего не уменьшал, поэтому я попробовал GUI (2005), и он работал отлично - освободил 17 ГБ за 10 секунд

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

-

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

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

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

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

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

• Как просмотреть журналы транзакций в SQL Server 2008

• Прочитайте файл журнала (* .LDF) в SQL Server 2008

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 используется. В этом случае попробуйте выполнить это несколько раз подряд или найдите способ уменьшить активность базы данных.

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

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

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

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

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

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

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

До сих пор большинство ответов здесь предполагают, что на самом деле вам не нужен файл журнала транзакций, однако, если ваша база данных использует 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 Server слишком занят. Я не хочу делать резервные копии журнала транзакций SQL Server

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

Из мифов журнала транзакций :

Миф: регулярное сокращение бревен - хорошая практика обслуживания

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

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

Журнал резервного копирования DatabaseName с Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

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

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

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

Если ваша база данных находится в модели полного восстановления и если вы не делаете резервную копию TL, измените ее на ПРОСТОЙ.

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

Помните, что журналы TX имеют своего рода минимальный / устойчивый размер, до которого они будут расти. В зависимости от модели восстановления вы не сможете сжать журнал - если в режиме FULL и вы не создаете резервные копии журнала TX, журнал нельзя сжать - он будет расти вечно. Если вам не нужны резервные копии журнала TX, переключите модель восстановления на Simple .

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

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

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

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

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

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

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

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

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

• Архив журнала [DBName] с No_Log

• Сократите базу данных:

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

  Использование T-SQL: - Dbcc Shrinkfile ([Log_Logical_Name])

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 4:

Проверьте ваш файл журнала в SQL 2014, как правило, это можно найти на

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

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

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

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

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

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

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

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

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

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

Пример:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Слегка обновленный ответ, для MSSQL 2017 и с использованием студии управления SQL-сервером. Я пошел в основном из этих инструкций https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

У меня была последняя резервная копия БД, поэтому я сделал резервную копию журнала транзакций. Затем я снова зарезервировал его для хорошей меры. Наконец, я сжал файл журнала и перешел с 20 ГБ до 7 МБ, что намного больше соответствует размеру моих данных. Я не думаю, что журналы транзакций когда-либо были заархивированы с тех пор, как они были установлены 2 года назад ... так что поместите эту задачу в календарь обслуживания.

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

1. Резервное копирование: журнал транзакций
2. Сжатие файлов: журнал транзакций
3. Резервное копирование: журнал транзакций
4. Сжатие файлов: журнал транзакций

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

Обычно он уменьшается до 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