предупреждение: пожалуйста, внимательно прочитайте комментарии ниже, и я предполагаю, что вы уже прочитали принятый ответ. Как я сказал, почти 5 лет назад:

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

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

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

• нажмите кнопку OK!

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

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

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

--

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

From:DBCC SHRINKFILE (Transact-SQL)

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

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

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

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

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

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

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

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

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

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

1. резервное копирование DB
2. отсоединить DB
3. переименовать файл журнала
4. присоединить DB
5. новый файл журнала будет воссоздана
6. удалить переименованный файл журнала.

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

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

с мифы журнала транзакций:

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

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

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

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

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

DBCC ShrinkFile(yourLogical_LogFileName, 50)

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

смотрите:

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

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

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

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

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

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

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

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

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

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

для усечения файла журнала:

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

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

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

• сжать базу данных, либо:

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

  использование T-SQL :- Инструкция DBCC Shrinkfile Команда ([Log_Logical_Name])

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

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

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

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

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

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

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

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

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

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

1. резервное копирование DB
2. отсоединить DB
3. переименовать файл журнала
4. Attach DB (при подключении удалить переименовано .ЛДФ (лог-файл).Выберите его и удалите, нажав кнопку Удалить)
5. новый файл журнала будет воссоздана
6. удалить переименованный файл журнала.

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

пример:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

Это произошло со мной, где файл журнала базы данных был 28 GBs.

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

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

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

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

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

Задачи> Сжатие> Файлы выбрать file типа как отчет Сжать действие как освободить неиспользуемое пространство

Шаг 4:

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

C:\Program файлы\Microsoft SQL Server\MSSQL12.MSSQL2014EXPRESS\MSSQL\DATA

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

DB журнал транзакций сокращение до минимального размера:

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

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

обычно сжимается до 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