Ответ 1

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

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

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

Если вы заботитесь о восстановлении на момент времени

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

Предположительно ваша база данных находится в режиме 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 s.

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

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

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

• SHRINKFILE копию журнала с параметром 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 важно и почему вы не должны сокращать свои файлы данных.

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

Ответ 2

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

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

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

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

• Затем нажмите OK!

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

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

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

-

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

Ответ 3

-- 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)

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

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

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

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

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

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

Из Мифы о транзакционных журналах:

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

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

Ответ 9

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

Ответ 10

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

Резервный журнал DatabaseName С Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

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

Обратитесь к:

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

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

Ответ 11

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

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

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

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

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

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

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

Ознакомьтесь с веб-сайтом Paul - он освещает эти самые вопросы. В прошлом месяце он прошел через многие из этих проблем в своей серии "The Myth Day".

Ответ 12

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

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

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

• Журнал резервного копирования [DBName] с No_Log

• Сократите базу данных с помощью:

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

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

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

Попробуйте следующее:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

Ответ 16

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

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

Ответ 17

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

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

Ответ 18

Пример:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Ответ 19

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

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

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

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

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

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

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

Шаг 4:

Проверьте файл журнала обычно в SQL 2014 это можно найти на

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

В моем случае его сокращение от 28 ГБ до 1 МБ

Ответ 20

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

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

Ответ 21

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

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

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

Обычно сокращается до 2 МБ.

ИЛИ с помощью script:

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 ['[email protected]_Name+']; '+
'BACKUP LOG ['[email protected]_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''[email protected]_LogFileName+''', 2) ' +
'BACKUP LOG ['[email protected]_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''[email protected]_LogFileName+''', 2)'
)
GO