Как почистить лог sql 1с

Как сжать или удалить файл лога базы 1с в sql

Такая ошибка может возникнуть если на диске недостаточно место. Часто происходит это из-за разросшегося файла log базы 1с.

Удалить или сжать (шринк) лога базы очень просто. Достаточно проделать действия ниже.

Инструкция

• В менеджере sql нажать правой клавишей на нужной базе — Свойства — Параметры — Модель восстановления — Выбрать «Простая».

• Опять правой клавишей на нужной базе — Задачи — Сжать — Файлы — Тип файла — Выбрать «Журнал». Ниже пункт Сжать файл до — устанавливаем «0«. Нажимаем ОК.

• Вернуть параметру Уровень восстановления значение «Полная».

Выполнить все шаги нужно для каждой базы данных.

Автоматическая очистка log файлов в MS SQL

Как настроить MS SQL 2012 Standart для автоматической очистки log файлов, при системе восстановления «Полный»?

Сейчас приходится раз в 2 месяца вручную менять способ восстановления на «Простой» сжимать логи до 0 и восстанавливать обратно к режиму «Полный», а потом каждую неделю проверять сколько места на диске. Потому что за 2 месяца БГУ объемом 4Гб нарашивает логов на 65Гб.

По теме из базы знаний

• Тонкая настройка ежедневного резервного копирования базы данных 1С средствами SQL ver. 2014 (SP3) — 12.0.6024.0 (X64)
• Описание почти всех событий технологического журнала
• Собираем образ виртуальной машины с PostgreSQL и платформой 1С. Цикл «Многопоточный CI для 1С c Packer, Vagrant и Jenkins», часть 2
• Познавательный PowerShell
• Резервное копирование и восстановление 1С баз на PostgreSQL в Windows с помощью pgAdmin, bat-файлов и планировщика

Найденные решения
4. dim_1c 23.02.19 11:24 Сейчас в теме

(3) А зачем Вам в таком случае модель восстановления Full? Используйте Simple.
А по хорошему, надо настроить регламентное резервное копирование и таких проблем быть не должно.

Alsegan; collider; acanta; + 3 – Ответить
Остальные ответы

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

Свернуть все
2. Xershi 1427 23.02.19 09:26 Сейчас в теме
(1) написать скрипт и включить его в план обслуживания.
Если загуглить думаю текст можно найти.
3. Alsegan 23.02.19 09:31 Сейчас в теме

(2) Скрипт который будет сам менять с «Полный» на «Простой» и чистить логи?
А каких нибудь стандартных способов очистки логов без смены системы восстановления нет?

PS Базы бекапятся каждый вечер

4. dim_1c 23.02.19 11:24 Сейчас в теме

(3) А зачем Вам в таком случае модель восстановления Full? Используйте Simple.
А по хорошему, надо настроить регламентное резервное копирование и таких проблем быть не должно.

Alsegan; collider; acanta; + 3 – Ответить
9. Alsegan 24.02.19 10:03 Сейчас в теме

(4)Прочитал статью, поменял на модель Simple , но до конца не понял — нужно ли писать дополнительные скрипты для урезания логов или же MS SQL сам их будет обрезать?

10. dim_1c 24.02.19 11:40 Сейчас в теме

(9) Вот, что нам говорят MS Docs: «Автоматически освобождает место на диске, занятое журналами, устраняя таким образом необходимость в управлении размером журналов транзакций.»

Автоматически освобождает — это не shrink, это переиспользование места журнала. Скорее всего это решит Вашу проблему. Но теоретически возможна ситуация когда sql server запишет в журнал много информации (для отката в случае необходимости какой-то длительной «тяжелой» транзакции). В общем, помониторьте какое-то время размер журнала.

И, конечно, надо помнить (MS Docs): «Изменения с момента создания последней резервной копии не защищены. В случае аварийной ситуации эти изменения придется вносить повторно.»

Как сжать или удалить файл лога базы 1С SQL

Узнать о том, что файл слишком большой, можно либо увидев сообщение от Windows о том, что место на диске закончилось, или же при появлении ошибки.

А может и то и другое )))

Чтобы с этим справится, запускаем наш MSSMS (Microsoft SQL Server Managment Studio)

Выбираем нашу базу, по правой клавише мыши — Свойства

Переходим в «Параметры» — Модель восстановления — Простая

Теперь опять ПКМ — Задачи — Сжать — Файлы

Выбираем «Реорганизовать страницы. «

Сжать файл до 0

И возвращаемся к предыдущему пункту и возвращаем «Модель восстановления» — Полная

Почему растет LOG в MS SQL ?

Друзья, почти ежедневно сталкиваюсь с тем, что на курсе: Администратор 1С, при опросе студентов, на предмет «Как Вы организовали бэкап в MS SQL?». Очень редко кто пишет: «Да, помимо «полного» я делаю и бэкап журналов транзакций».

К сожалению, редко кто делает бэкап ЖТР (

И тем самым открывает прямой путь к таким проблемам как:

«Распух лог в MS SQL», «Сильно увеличился LDF», «Разрастается log, что делать?», «Журнал занял все свободное место на диске», и многое, многое другое.

В этой статье я не буду рассыпать терминами и сложными понятиями гуру специалиста DBA, нет!

Так как вижу реальную картину, реальную проблематику вопроса, на более чем 5000 тыс студентов (Что проходили у нас курс: Администратор 1С). И реальность она несколько в другом!

Большинство не делает бэкапов журналов транзакций, так как не понимает зависимостей (связей), между их созданием и размерами самого журнала (*ldf).

Собственно цель данной статьи, максимально понятно, на простом языке, объяснить и закрыть раз и навсегда проблему растущего лога в MS SQL!

Приступим…

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

Файл *LDF он же и есть наш журнал транзакций!

Что там хранится?

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

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

Если говорить еще проще, благодаря бэкапу ЖТР есть возможность восстановить базу фактически на любой момент времени (вплоть до нужной секунды)!

При этом следует понимать, что никаких по факту данных из 1С в прямом смысле этого слова в журнале нет!

Все данные пишутся в файл *mdf, а вот фиксация этих действий пишется в *ldf, по каждому действию (транзакции), что происходит у Вас в 1С. Все что делают пользователи в 1С, фиксируется в журнале транзакций, только сам факт (фиксация) произошедших событий в базе, а не сами данные.

Собственно отсюда и название «Журнал транзакций». Конечно на практике все сложнее, но в упрощенном для понимания виде все именно так.

Почему растет лог файл в MS SQL (*ldf) ?

Конечно, если учитывать что каждое действие сделанное пользователем в 1С фиксируется в журнале транзакций, то он просто не может не расти! И здесь также стоит отметить, что не только действие пользователя влияет на рост журнала, но и различные регламентные задачи (фоновые различные процессы), особенно сильно заметен рост, когда происходит в базе 1С реструктуризация. Собственно при обновлении конфигурации также можем замечать “взрывной” рост журнала транзакций.

К слову мы только что ответили на частый вопрос: «Вот у меня лог не разрастался» в базе «А», а в базе «Б» растет очень быстро».

Конечно если с базой «Б» пользователи работают интенсивно или различные фоновые, регламентные задачи (их много), безусловно, он будет расти быстрее, такова физика работы «MS SQL»!

MS SQL всегда (в “полной” модели восстановления) будет пытаться зафиксировать, фактически все действия в базе. И журнал будет расти до тех пор, пока мы не сделаем его бэкап, этим мы и «усекаем» его!

«Простая» и «полная» модель восстановления

Да, «полная» модель восстановления подразумевает, что в журнал будем писать «По максимуму» все возможное. Все что сможет записать MS SQL, он туда запишет. Исключения конечно есть. К примеру, когда свободное место закончилось на диске или есть ограничения на сам лог (если установили). Есть и другие причины, но мы сейчас не об этом.

Нам важно понимать одно: «Полная» модель = «Полный» лог! А значит, есть возможность не терять данные, при необходимости восстановится на любой момент времени (фактически до секунды), а выполнив бэкап еще и «заключительного фрагмента журнала» и вообще ничего не потерять!

На сайте Microsoft можно найти информацию о том, что единственная «рабочая» модель, предназначенная для реальной работы, есть только «Полная» модель восстановления! Так как в работе недопустимо терять данные, а это гарантированно произойдет в «Простой» модели восстановления, если случится “сбой”.

«Простая» модель восстановления может использоваться для тестирования, разработки, для временного переключения (Обязательно! С предварительным бэкапом базы и лога). К примеру, только на время реструктуризации ее можно включить, а потом обратно вернуть в «Полную» модель. Есть и другие случаи, когда мы только временно переключаем режим с «Полной в Простой» Но работаем всегда в “полной” модели восстановления!

В “простой” модели мы никак не можем восстановиться (в случаи чего) на интересующий нас момент времени. Только на тот момент, когда сделан либо «полный» бэкап, либо «полный» + «разностный»!

Вывод:

Только в «полной» модели мы должны работать! Она не зря «по умолчанию» в MS SQL!

«Активная» и «Неактивная» часть журнала

Сперва дадим ответ на вопрос: «Что происходит в момент создания бэкапа ЖТР ?»

Чтоб разобраться в этом вопросе, нам нужно понимать, что журнал транзакций может быть «условно разделен» на две части: «Активная» и «Неактивная» часть журнала.

«Активная» – содержит изменения, которые были сделаны в базе, но еще не зафиксированы на диске.

«Неактивная» – изменения уже зафиксированы на диске, следовательно, можно усекать неактивную часть журнала (делать бэкап), вплоть до его активной части!

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

И вот в момент, когда мы создаем бэкап журналов транзакций, мы тем самым «усекаем» его «неактивную» часть (точнее это делает сам MS SQL), вплоть до начала его активной части!

При этом вначале всегда происходит его бэкап, а только после уже «усечение», как на рисунке выше.

Бэкап журналов нужно делать довольно часто (раз на 30-60 мин), особенно если с базой активно работают пользователи, он может вырасти довольно быстро, и конечно без автоматизации этого процесса не обойтись!

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

Вывод:

В «полной» модели восстановления бэкап журналов транзакций НЕОБХОДИМ! Если Вы не хотите в один прекрасный день обнаружить, что свободное место на диске, где он находится, уже закончилось!

Если ЛОГ уже вырос ?

Конечно, если Вы раньше не делали бэкапов журналов, лог соответственно вырос, то здесь одним бэкапом журналов транзакций не обойтись!

И вот почему:

Читать далее.

Зарегистрируйтесь, чтоб продолжить чтение статьи
Зарегистрироваться / Войти

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Успехов Вам, Коллега!