Как уменьшить лог файл базы sql
Перейти к содержимому

Как уменьшить лог файл базы sql

  • автор:

Сжатие файла

В этой статье описывается, как на SQL Server уменьшить данные или файл журнала с помощью SQL Server Management Studio или Transact-SQL.

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

Ограничения

  • Основной файл данных не может быть меньше размера первичного файла в базе данных модели.

Рекомендации

  • Максимальный эффект от сжатия достигается после операции, при которой создается много неиспользуемого пространства в хранилище, например после объемной инструкции DELETE, усечения или удаления таблицы.
  • Большинству баз данных требуется некоторое свободное пространство для выполнения обычных ежедневных операций. Если сжатие файла базы данных производится регулярно, но размер базы данных продолжает расти, это означает, что для нормальной работы необходимо свободное пространство. В таких случаях повторное сжатие файла базы данных бессмысленно. События автоматического увеличения, необходимые для увеличения файла базы данных, снижают производительность.
  • Данные, перемещаемые в процессе сжатия файла, могут быть разбросаны по любым доступным местам в файле. Это вызывает фрагментацию индекса и может увеличить время выполнения запросов, выполняющих поиск в диапазоне индекса. Чтобы устранить фрагментацию, предусмотрите возможность перестроения индексов файла после сжатия.
  • Без достаточных на то оснований не следует устанавливать параметр базы данных AUTO_SHRINK равным ON.

Замечания

Выполняемые операции сжатия могут блокировать другие запросы к базе данных и могут заблокировать уже выполняющиеся запросы. В SQL Server 2022 (16.x) операции сжатия файлов имеют параметр WAIT_AT_LOW_PRIORITY. Эта функция является новым дополнительным параметром для DBCC SHRINKDATABASE и DBCC SHRINKFILE . Если новая операция сжатия в режиме WAIT_AT_LOW_PRIORITY не может получить необходимые блокировки из-за длительного выполнения запроса, операция сжатия в конечном итоге истекает через одну минуту и автоматически завершает работу, предотвращая блокировку других запросов. WAIT_AT_LOW_PRIORITY применяется к файлам данных (MDF .ndf & ). Он не применяется к файлам журнала транзакций. Дополнительные сведения см. в разделе DBCC SHRINKFILE.

Разрешения

Необходимо быть членом предопределенной роли сервера sysadmin или предопределенной роли базы данных db_owner .

Использование среды SQL Server Management Studio (SSMS)

Сжатие файла данных или журнала с помощью SSMS

  1. В обозревателе объектовподключитесь к экземпляру компонента SQL Server Database Engine и разверните его.
  2. Разверните узел Базы данных и щелкните правой кнопкой мыши базу данных, которую нужно сжать.
  3. В меню наведите указатель мыши на пункт Задачи, затем на пункт Сжать и выберите команду Файлы. База данных
    Отображает имя выбранной базы данных. Тип файла
    Выберите тип файла. Доступны следующие возможности: Данные и Журнал . Значение по умолчанию: Данные. Выбор другого типа файловой группы соответственным образом изменяет выбор в других полях. Файловая группа
    Выберите файловую группу из списка файловых групп, связанных с выбранным ранее типом файлов . Выбор другой файловой группы соответственным образом изменяет выбор в других полях. Имя файла
    Выберите файл из списка имеющихся файлов выбранной файловой группы и типа. Местонахождение
    Отображает полный путь к текущему выбранному файлу. Путь не редактируется, но его можно скопировать в буфер обмена. Выделенное в данный момент место
    Для файлов данных отображает выделенное в данный момент место. Для файлов журнала отображается выделенное в данный момент пространство, вычисленное на основании результата процедуры SQLPERF(LOGSPACE) модуля DBCC. Доступное свободное место
    Для файлов данных отображается имеющееся в данный момент доступное свободное место, вычисленное на основании результата процедуры SHOWFILESTATS(идентификатор_файла) модуля DBCC. Для файлов журнала отображается имеющиеся в данный момент доступное свободное место, вычисленное на основании результата процедуры SQLPERF(LOGSPACE) модуля DBCC. Освободить неиспользуемое место
    Все неиспользуемое пространство, выделенное для файлов, освобождается для нужд операционной системы, а файл сжимается в последний выделенный экстент, тем самым размер файла уменьшается без перемещения данных. Не производится попыток перемещения строк на нераспределенные страницы. Реорганизовать страницы, перед тем как освободить неиспользуемое место
    Эквивалентно выполнению процедуры SHRINKFILE модуля DBCC, определяющей размер целевого файла. При выборе этого параметра необходимо указать размер целевого файла в поле Сжать файл до . Сжать файл до
    Определяет размер целевого файла для операции сжатия. Размер не может быть меньше текущего выделенного пространства или более общих экстентов, выделенных файлу. Если вводимое значение выходит за допустимые границы, оно будет преобразовано к минимальному или максимальному значению при изменении фокуса ввода или при нажатии на любую кнопку панели инструментов. Очистить файл путем переноса данных в другие файлы той же файловой группы
    Выполняется перенос всех данных из указанного файла. Этот параметр позволяет удалить файл при помощи инструкции ALTER DATABASE. Эта возможность эквивалентна выполнению процедуры SHRINKFILE модуля DBCC с параметром EMPTYFILE.
  4. Выберите тип файла и имя файла.
  5. Дополнительно можно установить флажок Освободить неиспользуемое место . Выбор этого параметра приводит к освобождению всего неиспользуемого пространства файла для ОС и уменьшению размера файла до последнего размещенного экстента. Это уменьшает размер файла без перемещения каких-либо данных.
  6. Дополнительно можно установить флажок Реорганизовать файлы перед освобождением неиспользуемого места . При выборе этого режима необходимо указать значение Сжать файл до . По умолчанию этот флажок снят. Выбор этого параметра приводит к освобождению всего неиспользуемого пространства файла для ОС и попытке перемещения строк в неразмещенные страницы.
  7. При необходимости введите максимальный процент свободного пространства, которое должно остаться в базе данных после ее сжатия. Допустимы значения от 0 до 99. Этот параметр доступен только в том случае, если установлен флажок Реорганизовать файлы перед освобождением неиспользуемого места .
  8. При необходимости установите флажок Очистить файл путем переноса данных в другие файлы той же файловой группы . Выбор этого режима перемещает все данные из указанного файла в другие файлы данной файловой группы. Пустой файл удалить нельзя. Этот режим эквивалентен выполнению процедуры DBCC SHRINKFILE с параметром EMPTYFILE.
  9. Нажмите ОК.

Использование Transact-SQL

Сжатие файла данных или журнала с помощью Transact-SQL

  1. Соединитесь с ядром СУБД .
  2. На стандартной панели выберите пункт Создать запрос.
  3. Скопируйте приведенный ниже пример в окно запроса и нажмите кнопку Выполнить. В следующем примере для сжатия файла в базе данных до 7 МБ используется функция DataFile1 DBCC SHRINKFILE UserDB .
USE UserDB; GO DBCC SHRINKFILE (DataFile1, 7); GO 

См. также

  • Рекомендации по настройке автоувеличения и автосжатия в SQL Server
  • Файлы и файловые группы базы данных
  • sys.databases (Transact-SQL)
  • sys.database_files (Transact-SQL)
  • FILE_ID (Transact-SQL)

Следующие шаги

  • DBCC SHRINKDATABASE (Transact-SQL)
  • DBCC SHRINKFILE (Transact-SQL)
  • Удаление файлов данных или журнала из базы данных
  • Сжатие базы данных

Шринк лога транзакций MS SQL 2008/2012 в экстренном случае или боремся с ошибкой HRESULT=80040E14

Когда при подключении к базе MS SQL появляются ошибки: Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных «ReportServer» заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1 или Ошибка СУБД:
Microsoft OLE Provider for SQL Server: The transaction log for database “ReportServer” is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column is sys.database
HRESULT=80040E14, SQLSTATE=4 2000, native=9002 это значит, что на диске, где расположен лог транзакций закончилось место и теперь СУБД некуда записывать данные о новых транзакциях. Чаще всего такое происходит, когда не установлено никаких ограничений на размер лога и в MS SQL не создано соответствующих планов обслуживания. В таком случае нужно уменьшить размер самого файла транзакций (*.ldf) , другими словами сделать шринк (сжатие) лога. Для этого можно использовать как запрос, так и сжатие лога вручную. Рассмотрим сжатие лога транзакций вручную: Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе — Свойства(Properties) — Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Простая(Simple) — OK. Шринк лога MS SQL 2008/2012 Шринк лога транзакций MS SQL 2008/2012Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе — Задачи(Tasks) — Сжать(Shrink) — Файлы(Files) — установить Тип файла(File type) — Журнал(Log) — в Операция сжатия(Shrink action) — выбрать Реорганизовать страницы, перед тем осводить неиспользуемое место(Reorganize pages before releseasing unused space) — Сжать файл (Shrink file to) —
указать приемлемый размер лога. Шринк лога транзакций MS SQL 2008/2012 Шринк лога транзакций MS SQL 2008/2012 Шаг 3. Установить модель восстановления Полная(Full). Правой кнопкой на базе — Свойства(Properties) — Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Полная(Full) — OK. Шринк лога транзакций MS SQL 2008/2012P.S.: В данной статье даны рекомендации для решения конкретной проблемы. Настройка самого MS SQL здесь не рассматривается!

См. также

Правильная свертка или свертка базы по правилам

Свертка базы Чистка данных Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб) Обработка «Свертка базы по правилам» предназначена для свертки информационных баз системы программ «1С:Предприятие» версии 8.2. Основой обработки являются специальные правила свертки, которые создаются индивидуально для каждой конфигурации информационной базы. Встроенный в обработку генератор правил позволяет быстро создать правила свертки для любой конфигурации. Например, для конфигурации «1С:Бухгалтерия 8, ред. 3.0» правила свертки были созданы за 15 минут! 2400 руб. 22.07.2013 161562 604 527 397

397 604 527 161562

Пометка на удаление номенклатуры, которой нет на остатках и не было в оборотах за определенное время (кол-во месяцев), и перенос ее в указанную папку

Чистка данных Платформа 1С v8.3 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Управленческий учет Платные (руб) Данная обработка определяет неликвидную номенклатуру, метит её на удаление и переносит её в указанную папку, что облегчает работу операторов организации для аналитики и многих процессов, связанных с товаром. 2280 руб. 03.06.2020 15803 12 13 11

11 12 13 15803

Удаление организаций из информационных баз 1С

Чистка данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Россия Платные (руб) Обработка предназначена для удаления организаций из любых информационных баз 1С, имеющих в своем составе справочник «Организации». Работает на обычных и управляемых формах, на базах любого формата и размера. Обработка проверялась на следующих типовых релизах 1С: БП 2.0.66.84, БП 3.0.71.77, БГУ 1.0.59.3, БГУ 2.0.65.17, УТ 10.3.55.3, УТ 11.4.10.57, ЗУП 3.1.11.106, ЗГУ 3.1.11.106, КА 2.4.9.98, УПП 1.3.126.1, УНФ 1.6.18.168, но должна работать и на более старых, так как обработке нужен только справочник «Организации». 3000 руб. 20.11.2019 26872 66 35 71

71 66 35 26872

Замена Номенклатуры+Характеристики

Чистка данных Логистика, склад и ТМЦ Платформа 1С v8.3 План видов характеристик 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб) Настраиваемая обработка, позволяющая заменить пару: Номенклатура+Характеристика в документах, их движениях и независимых регистрах сведений. Без перепроведения. Поможет, если вы по каким-то причинам решили отказаться от характеристик 3600 руб. 04.08.2015 40686 86 70 47

47 86 70 40686

Алгоритм перехода на учет без серий для программного продукта «Управление торговлей» редакция 11 или Комплексная Автоматизация редакция 2. (отказ от серий, удаление серий, отмена серий, без серий, УТ, КА)

Оптовая торговля Логистика, склад и ТМЦ Чистка данных Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб) Если вы начали работать в программном продукте Управление Торговлей, редакция 11 или Комплексная Автоматизация редакция 2 и включили механизм учёта серий, то перейти обратно в учёт без серий будет не так-то просто. Сложность заключается в том, что нужно очистить серии в табличной части документа, например, Реализация Товаров и услуг. Предлагаем алгоритм перехода на учет без серий для программного продукта «Управление торговлей» редакция 11. (Очистка серий.) 2400 руб. 09.04.2019 28098 37 14 39

39 37 14 28098

Удаление битых ссылок 1С в базе без монопольного режима

Чистка данных Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб) Если в вашей информационной базе крутится очень много данных, или база должна быть доступна 24/7 (как в моем случае), или же вы боитесь запускать тестирование и исправление, НО существует потребность удалить битые ссылки, тогда эта обработка сможет Вам помочь. Обработка выявляет битые ссылки как в самих объектах метаданных, так и в их табличных частях(!), а так же может их удалить. 1800 руб. 23.08.2021 8967 14 3 19

19 14 3 8967

Очистка регистров сведений от записей по помеченным на удаление элементам

Чистка данных Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб) в современных конфигурациях стало очень много регистров сведений, хранящих вспомогательную и периодическую информацию и администраторы информационных систем стали сталкиваться с проблемой удаления помеченных на удаление объектов, так как ссылки на них хранятся в многочисленных регистрах сведений. Помочь почистить базу от ненужных записей предназначенная данная внешняя обработка на управляемой форме, которая ищет записи во всех регистрах сведений по помеченным на удаление объектах и очищает по ним записи их после использования данной обработки дальше можно смело пользоваться типовой обработкой удаление помеченных на удаление и проблем с удалением не возникнет! Удачи всем! 1200 руб. 21.01.2022 6905 4 6 8

8 4 6 6905

Очистка кэша 1С. Исполнитель

Чистка данных Инструментарий разработчика Платформа 1С v8.3 Абонемент ($m) Очередная вариативная очистка кэша 1С с помощью Исполнителя 3.0.2.2. 1 стартмани 25.10.2023 4001 3 SerVer1C 25 20

20 3 25 4001
Посмотреть ещё
Комментарии

  • Дата
  • Дата
  • Рейтинг всех уровней
  • Рейтинг 1-го уровня
  • Древо развёрнутое
  • Древо свернутое

Свернуть все
1. adhocprog 1138 15.01.13 20:14 Сейчас в теме

(0) а зачем возвращать в состояние «Полная»?
Можно оставаться на Простой и рассчитывать только на бэкапы.

simuljakr; ZardoZ; + 2 – 1 Ответить
2. aspirator23 340 15.01.13 21:37 Сейчас в теме

(1) Полная более гибкая. А для больших баз еще и быстрая: с одной стороны можно обеспечить маленькие интервалы восстановления, с другой быстрый бэкап в рабочее время.

criptid; Velesstroy_OOO; Areal; logos; caponid; + 5 – Ответить
6. zzz_natali 61 16.01.13 04:48 Сейчас в теме

(2) aspirator23,
Полный бред! Не видела ни разу ни одной фирмы, где в течение дня начинали восстанавливать бакап, а потом еще пол-дня чесали репу, какие доки/транзашки были сделаны, а какие нет(учитывая, что 30-50тичисленное стадо манагеров постоянно разбредается и никого не собрать по тубзикам-курилкам, чтобы выяснить где был реал-тайм).
Выводы: простой режим восстановления, ночной бакап + в обед, если уж так плющит(видела в одной конторке, где сотрудников принудительно выгоняют на хавчик из офиса и базы) и получасовые снапшоты, если уж совсем фобия.

j3d; vitalbasl; andrey-prog; dm68; simuljakr; rrustam11983; ZardoZ; + 7 – Ответить
46. un2qum 6 04.06.21 03:19 Сейчас в теме

ние дня начинали восстанавливать бакап, а потом еще пол-дня чесали репу, какие доки/транзашки были сделаны, а какие нет(учитывая, что 30-50тичисленное стадо манагеров постоянно разбредается и никого не собрать по тубзикам-курилкам, чтобы выяснить где был реал-тайм).
Выводы: простой режим восстановления, ночной бакап + в обед,

все зависит от бизнеса, если вы не видели — это не значит что этого нет.
simuljakr; simvol@s; 1cNBL; EDSign; user1316148; den_marino90; Crazy_Max; + 7 – Ответить
47. zzz_natali 61 04.06.21 08:56 Сейчас в теме

(46)
Мне казалось, что здесь идет около1С’ный тред, а не за банковскую, биллинговую, провайдерскую или какую-то еще сферу, где критически важны состояния баз данных на сотые доли секунды. В конце концов, я совершенно не представляю, что в хозяйстве, скажем, Грефа, администраторы БД режут логи.
ЗЫ. можно не вступать в дискуссию. просто мысли вслух. Всех благ.

48. un2qum 6 06.06.21 02:20 Сейчас в теме
Грефа, администраторы БД режут лог

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

49. zzz_natali 61 07.06.21 08:45 Сейчас в теме

(48)
Не, не, не. Я не попадусь на вашу уловку безотказных кластеров, мирроринга и т.п. 🙂
Как говорится, это совсем другая история.

50. user618912_redgad 13 09.06.21 08:30 Сейчас в теме

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

51. zzz_natali 61 09.06.21 08:49 Сейчас в теме

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

13. mxm2 1250 16.01.13 10:42 Сейчас в теме

(2) aspirator23, Полная модель восстановления — обеспечивает восстановление «с точностью» «до минуты» (имею ввиду из бакапа), но это приводит к тому что разрастается лог (часто он занимает весь диск, и база «останавливается»), Простая модель — позволит восстановить информацию только на момент создания бакапа, никакого (почти) влияния на скорость работы эти модели не имеют (полная модель теоретически медленнее — т.к. при её использовании делается множество «лишних записей» в лог, в отличие от простой модели). подробнее тут http://www.gilev.ru/1c/mssql/backup.htm . Поэтому предпочтительно использовать именно простую модель, с каждодневным бакапом (в наиболее ненагруженное пользователями и фоновыми заданиями время), и с регулярным автоматическим шринкованием, через планы обслуживания СКЛ (кстати использование планов обслуживания 2008/2012 также позволяет «без написаания запросов», производить гибкие настройки многих вещей, в частности бакапов и шринков, да и много чего еще). вот тут еще инфа есть про бакап http://aquablog.3dn.ru/publ/15-1-0-52

Попытка1С; neo-ti; frkbvfnjh; + 3 – Ответить
14. aspirator23 340 16.01.13 11:26 Сейчас в теме

(13) Важное замечание сделал(11).
1.Насчет того что «разрастается лог, который часто занимает весь диск» — это не обсуждаем.
SQL сервер тоже нужно настраивать, а не просто поставить по умолчанию.
2.»предпочтительно использовать именно простую модель, с каждодневным бакапом» — я уже писал, что простая модель хороша для небольших баз. А также в случае если требования по восстановлению
никто не заявляет. А вот если заявляет и база большая, то простой моделью не выкрутишься.
Либо не обеспечишь нормальную периодичность восстановления, либо если обеспечишь, то тогда база будет ложиться
в момент выполнения полного бэкапа при простой модели.

16. mxm2 1250 16.01.13 11:52 Сейчас в теме
(14) aspirator23,

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

Простая модель хороша для любых баз (и больших и не больших), если нет требований по восстановлению на любой момент времени.

onsi; Vin1s; gigapevt; flintic; msvd; + 5 – Ответить
32. AlexO 134 14.11.14 12:55 Сейчас в теме
(14) aspirator23,
Насчет того что «разрастается лог, который часто занимает весь диск» — это не обсуждаем.

Отчего же не обсуждаем? Вы знакомы с проблемой «база загружена не полностью» и её причиной?
(21) МихаилМ,

без предварительного выяснения, почему увеличился размер transaction log,
нет смысла его усекать.

как бы работа самой базы? Наставляемые обновления? Изменения в конфе? Нет?
Это все не приводит к увеличению лога?

3. bintape 15.01.13 22:27 Сейчас в теме
Еще бы автор написал, для чего вообще нужна данная процедура )
4. Kserken 484 15.01.13 22:51 Сейчас в теме

(3) batan, данная процедура нужна в том случае, если логи сильно разрастаются. Было у меня на практике, когда нерадивые сисадмины не следили за логами и они разрастались до размеров нескольких сотен ГБ (240 Гб если быть точным, был и в 70 Гб). Поэтому и приходилось выполнять такие манипуляции.

5. caponid 16.01.13 01:21 Сейчас в теме

Читайте плз документацию к БД она не просто так писана — если бы мог, поставил бы минус публикации — есть стандартные процедуры с бекапом и обрезкой лога.
а то что написано можно делать только на базе без подключенных пользователей — хотя зачем это нужно?? если можно обойтись стандартной процедурой в одну строчку мссиквела.
кому интересно — тот хотя-бы на sql.ru поищет.

randa; theshadowco; + 2 – Ответить
7. aspirator23 340 16.01.13 06:56 Сейчас в теме

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

criptid; gigapevt; mrnovel; kild; KillahPriest; isn; Puk2; artichoke; + 8 – Ответить
31. AlexO 134 14.11.14 12:52 Сейчас в теме
есть стандартные процедуры с бекапом и обрезкой лога.

если про «Усечь журнал транзакций» в 2012 — то он не всегда отрабатывает. А лог нужно урезать обязательно.
(5) caponid,

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

С пользователями делается.
(1) adhocprog,
Можно оставаться на Простой

Когда у вас будут вводить по десятку документов в секунду, тогда и оцените восстановление на любой момент времени.
(9) dvv01,

А почему сразу его не поставить в TRUE?

А потому, что принудительно лог очищается ВСЕГДА. А не как придется в случае автошринка при выгрузке.
А есть случаи, когда нужно обрезать только лог, без бэкапа.

Programmer ASP.NET MVC C#

https://fastoder.com/app?aspnet

При работе с БД, особенно на этапе разработке, очень сильно разрастаются ldf и mdf файлы базы данных.

Для их уменьшения нужно воспользоваться командой DBCC SHRINKFILE.

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

Обезательные аргументы команды: file_name — логическое имя файла, предназначенного для сжатия; target_size — размер файла (в мегабайтах), выражаемый целым числом, если он не указан, то инструкция DBCC SHRINKFILE уменьшает файл до размера файла по умолчанию. Размер по умолчанию представляет собой размер, указанный в момент создания файла.

DBCC SHRINKFILE(dbMyDataBase_log, 1).

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

select * from sysfiles

при этом должна быть открыта ваша БД (dbMyDataBase)

Комментарий:

  • В 11/14/2012 10:46:56 PM, Аноним

Можно все тоже самое сделать через гуи. Это если кто не умеет строить запросы :). правой кнопкой на базе, задачи, шринк, файлы, выбираем лог (там сразу видно на сколько процентов можно уменьшить). Иногда, если лог большой — например гигов 50, то уменьшать (шринкать) его надо 2 раза — с первого раза уменьшаеться, но не полностью. вот так вот :). WishMaker.

Бывает перед тем как чистить нужно сделать BACKUP, без него не уменьшаем. BACKUP LOG dbMyDatabase TO DISK = ‘E:\BD\Backups\dbMy.bak’ DBCC SHRINKDATABASE(N’dbMy’) —to shrink the database GO DBCC SHRINKFILE (dbMy , 0, TRUNCATEONLY)—to shrink data file GO DBCC SHRINKFILE (dbMy_log , 0, TRUNCATEONLY)—to shrink ldf

Developer ASP.NET MVC C#

Форум ФОСС-Он-Лайн

Как уменьшить размер лог-файла транзакций (FossDoc_log.ldf)?

3 сообщения • Страница 1 из 1
writer Техподдержка Сообщения: 60 Зарегистрирован: 06 янв 2009, 17:23

Как уменьшить размер лог-файла транзакций (FossDoc_log.ldf)?

Сообщение writer » 12 янв 2011, 20:27

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

1. Запустите SQL Server Management Studio.

2. Выберите базу данных FossDoc и выполните команду Properties из контекстного меню на данной БД:

Изображение

3. В появившемся диалоге на странице Options установите значение поля Recovery Model в Simple. Нажмите ОК.

Изображение

4. Снова выберите базу данных FossDoc и выполните команду Tasks/Shrink/database из контекстного меню на данной БД.

Изображение

5. В появившемся диалоге нажмите ОК:

Изображение

Размер лог-файла транзакций будет существенно уменьшен.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *