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


577

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



3
В Managment Studio должна быть команда: «Нажмите, чтобы сжать журнал», и все готово.
Французский

Ответы:


750

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

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

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

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

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

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

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


5
Восстановление на определенный момент времени - не единственная причина использования модели полного восстановления. Основной причиной является предотвращение потери данных. Ваш потенциал потери данных - это длина между резервными копиями. Если вы делаете только ежедневное резервное копирование, ваш потенциал потери данных составляет 24 часа. Если вы затем добавляете резервные копии журналов каждые полчаса, ваша вероятность потери данных становится 30 минут. Кроме того, резервные копии журналов необходимы для выполнения любого частичного восстановления (например, восстановления после повреждения).
Роберт Л Дэвис

9
Кроме того, это самый полный и правильный ответ, приведенный на этой странице.
Роберт Л Дэвис

11
Я также хотел бы добавить, что очистка журнала выполняется путем резервного копирования журнала (при полном или массовом восстановлении) или контрольной точки (при простом восстановлении). Однако, если вы находитесь в ситуации, когда вам необходимо сжать файл журнала, этого недостаточно. Вы должны заставить текущий активный VLF возвращаться к началу файла журнала. Вы можете форсировать это в SQL 2008 и новее, выполняя две резервные копии журнала или контрольные точки вплотную. Первый очищает его, а второй циклично возвращает его к началу файла.
Роберт Л Дэвис

2
@Doug_Ivison, потому что в любой момент записи журнала могут быть удалены. Какой смысл позволить вам сделать резервную копию журнала, который является неполным? В простом восстановлении журнал действительно используется только для отката транзакций. Как только транзакция была зафиксирована или откатана, в следующую секунду она может быть удалена из журнала.
Аарон Бертран

3
@zinczinc Хорошо, спасибо за ваш отзыв. Проблема, с которой я сталкиваюсь, ставя сначала ответ, а потом объяснение, состоит в том, что они никогда не будут читать важные части. Лекция, которую я заглушаю читателю, на самом деле гораздо важнее, чем ответ в конце, и ИМХО фон, который я предоставляю, очень важен для принятия такого выбора. Но, эй, если вы хотите отправить однострочный ответ, потому что вы считаете, что это лучше для ОП, пожалуйста, не стесняйтесь использовать эту часть моего ответа, чтобы сделать лучше, из которого мы все можем учиться.
Аарон Бертран

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

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


спасибо Maimonides, это из документов, так что я бы сказал, что это лучшее: P, особенно потому что не был изобретен мной :)
Rui Lima

1
после того, как я это сделал, размер моего журнала не изменился. я сделал что-то неправильно?
chester89

1
Этот подход устанавливает тип восстановления на «FULL», даже если тип восстановления был чем-то другим раньше
Vil

1
Работал как по волшебству! Обратите внимание, что имя файла журнала на самом деле является его логическим именем (которое можно найти в db-> properties-> files)
Бижан,

2
Я бы включил в этот скрипт предложение BACKUP DATABASE, поэтому никто не забудет эту часть. Я говорю это потому, что несколько лет назад я сжал базу данных на диске, где на ней слишком мало свободного места. В процессе сжатия файлы становились больше, и возникала ошибка «Недостаточно места». Результат: я потерял базу данных. К счастью, была база данных журнала, которая потеряла терпимость.
Цезарь

185

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

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


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

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

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

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

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

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

-

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


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

7
@onupdatecascade - хороший вызов для полного восстановления. была другая база данных с огромным журналом: переключился на простую, затем сжал базу данных и переключился обратно на полную. лог файл до 500кб!
Simon_Weaver

26
Сожалею. Но этот ответ просто не может быть более неправильным. Сокращая базу данных, вы будете увеличивать файл журнала транзакций. В ЛЮБОЕ время, когда вы перемещаете данные в базе данных SQL Server, вам потребуется регистрация - вздутие файла журнала. Чтобы уменьшить размер журнала, либо установите для БД простое восстановление, либо (если вам нужны / нужны зарегистрированные данные - и вы почти всегда делаете это в рабочей среде), сделайте резервную копию журнала. Подробности в этих простых, бесплатных видео: sqlservervideos.com/video/logging-essentials sqlservervideos.com/video/sql2528-log-files
Майкл К. Кэмпбелл,

30
Вау, спасибо за получение 1300+ повторений за этот ответ, но это действительно ужасный совет.
Аарон Бертран

8
Вот преувеличение, чтобы продемонстрировать, что происходит и почему сокращение является абсолютно критическим на периодической основе: запись A изменяется 1 миллион раз, прежде чем будет выполнено резервное копирование. Что в журнале? 999 999 частей данных, которые не имеют значения. Если журналы никогда не сокращаются, вы никогда не узнаете, каковы истинные эксплуатационные расходы базы данных. Кроме того, вы, скорее всего, используете важные ресурсы в сети хранения данных. Сокращение является хорошим обслуживанием и поддерживает связь с окружающей средой. Покажите мне кого-то, кто думает, что вы никогда не должны уменьшаться, и я покажу вам кого-то, кто игнорирует их окружение.
Newclique

54

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

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

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

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

 

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


30

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

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

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


15
С уважением, удаление / переименование / воссоздание / замена журнала очень плохая идея. Сокращение должно быть менее рискованным, плюс это довольно просто сделать.
onupdatecascade

12
+1 - неграмотный или нет, этот метод пару раз выводил меня из горячей воды с журналами базы данных, которые заполнили весь диск, так что даже команда сжатия не может быть запущена.
Shaul Behr

3
Нет ли в журнале незарегистрированных транзакций?
Пол

Это может также подойти для небольших БД, но если у вас есть БД объемом 3 или 4 ТБ, это может быть не лучшим решением.
Жак

Это нормально, если вы долго разрабатывали систему и загружали / удаляли тысячи записей в течение периода разработки. Затем, когда вы хотите использовать эту базу данных для развертывания в режиме реального времени, записанные в журнал данные тестирования / разработки являются избыточными и, следовательно, не имеют значения, если они потеряны, нет?
JsonStatham

28

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

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

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


1
Установка простого режима восстановления сама по себе не приведет к магическому сокращению журнала транзакций.
Аарон Бертран

@ Аарон Не по себе, нет. Я предполагал, что OP будет использовать свою тестовую базу данных, и, следовательно, «журнал транзакций очень скоро будет сокращен», но вы правы в том, что это скорее побочный эффект: простой режим восстановления, вероятно, заставит вас в конечном итоге сжаться Журнал транзакций в ближайшее время
Джонатан

« Simple... и никогда больше не заправляйся» - неправда. Я видел, как это происходило (за последние 48 часов) в базе данных, где для Модели восстановления было установлено значение «ПРОСТО». Размер файла журнала был установлен как «ограниченный», и мы проделали огромную работу с ним ... Я понимаю, что это была необычная ситуация. (В нашей ситуации, когда у нас было много места на диске, мы увеличили размер файла журнала и установили рост файла журнала в «неограниченный» ... который, кстати, --interface bug--, после изменения отображается как «ограниченный» "с максимальным размером 2 097 152 МБ.)
Doug_Ivison

2
@Doug_Ivison Да, в журнале транзакций будут открытые транзакции, но они будут удалены в простом режиме, как только будет пройдена контрольная точка. Этот ответ предназначен только для быстрого «моя коробка разработки / тестирования имеет большой журнал транзакций, и я хочу, чтобы он ушел, чтобы мне не приходилось слишком часто беспокоиться об этом», а не когда-либо намеревался перейти в производство. окружающая обстановка. Чтобы повторить: не делайте этого в производстве .
Джонатан

1
Это все правда, и я понимаю, что это был быстрый подход только для разработки. Почему я прокомментировал: пока это не случилось со мной, я действительно думал, что простая модель восстановления НИКОГДА не заполняется ... и я думаю, что мне потребовалось больше времени, чтобы выяснить / решить, в то время как я понял, что необычно большие транзакции могут это сделать.
Doug_Ivison

9

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


... но я делал это десятки раз без проблем. возможно, вы могли бы объяснить, почему БД не может повторно присоединиться.
Джонно Нолан

Я иногда (не очень часто) видел, что SQL Server не может присоединить базу данных к базе данных после удаления файла журнала. Это оставляет вам бесполезный файл MDF. Есть несколько возможностей, которые могут вызвать проблему. На ум приходят транзакции в ожидании отката.
Мрденни

4
Я согласен с этой тактикой, но она должна быть зарезервирована для случаев, когда бревно взорвалось из-за какого-то непредвиденного и / или чрезвычайного события. Если вы устанавливаете работу, чтобы делать это каждую неделю, вы делаете это очень, очень неправильно.
Аарон Бертран

2
Очень, очень верный Аарон.
Мрденни

Да, это только что случилось с нами. Мы хотели выбросить 20 ГБ из файла журнала, так как мы только что создали резервную копию данных перед перемещением базы данных. MSSQL никоим образом не позволит нам повторно присоединить новую базу данных без огромного файла журнала.
Джордж М Восстановить Монику

9

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

3
Я согласен с вашим ответом, за исключением , 1)части. Проблема в том, что если вы сократите его до 1 МБ, события роста, приводящие к нормальному размеру журнала, будут весьма дорогостоящими, и их будет много, если скорость роста останется равной 10% по умолчанию.
Аарон Бертран

9

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

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

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

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

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

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

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

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


5

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

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

DBCC ShrinkFile(yourLogical_LogFileName, 50)

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

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

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

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


Именно так я очищаю файлы журналов на своих устройствах разработки. Среды Prod со всеми сопутствующими стратегиями резервного копирования и т. Д. Я оставляю администраторам баз данных :-)
Joon

TRUNCATE_ONLYбольше не является опцией в текущих версиях SQL Server, и он не рекомендуется для версий, которые его поддерживают (см . ответ Рэйчел ).
Аарон Бертран

5

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

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

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

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

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

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

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

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


+1 За первый ответ упомянуть, что это может быть не очень хорошая идея! В OP указывается тестовая база данных, но это стоит отметить в более общем случае.
Мартин Смит

Я должен был добавить - Если вы удалите журнал TX - Обновить резюме!
ripvlan

4

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

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

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

  • Архив журнала [DBName] с No_Log
  • Сократите базу данных:

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

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

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


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

4

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

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


Простая установка базы данных на простой не уменьшит файл журнала, в каком бы состоянии он ни находился. Это может помочь предотвратить дальнейший рост (но все же может).
Аарон Бертран

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

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

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


3

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

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

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

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

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

введите описание изображения здесь

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

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

введите описание изображения здесь

Шаг 4:

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

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

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


2

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

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

TRUNCATE_ONLYбольше не является опцией в текущих версиях SQL Server, и он не рекомендуется для версий, которые его поддерживают (см . ответ Рэйчел ).
Аарон Бертран

Это работает для меня, используя MSSQL Server 2005 Standard edition
bksi

2

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

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


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

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


1

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

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

0

Пример:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

TRUNCATE_ONLYбольше не является опцией в текущих версиях SQL Server, и он не рекомендуется для версий, которые его поддерживают (см . ответ Рэйчел ).
Аарон Бертран

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

0

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

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


-1

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

  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

1
TRUNCATE_ONLYбольше не является опцией в текущих версиях SQL Server, и он не рекомендуется для версий, которые его поддерживают (см . ответ Рэйчел ).
Аарон Бертран
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.