Как порезать лог 1с
Внимание!
Введение
В этом уроке мы научимся использовать обновлятор для однократного (или регулярного по расписанию) сокращения журнала регистрации в одной или группе баз.
При этом я покажу как сохранять и архивировать сокращаемую часть журнала на отдельный диск.
Пакетные скрипты
Все операции мы будем проводить на закладке обновлятора "Скрипты":
Если вы ещё не работали с пакетными скриптами в обновляторе, советую бегло пробежаться по их возможностям: ссылка.
Оговорка
Всю следующую практическую часть мы будем делать на примере одной базы и запускать этот скрипт вручную.
Но в реальных задачах ничего не помешает нам запускать скрипт для любого количества баз (в том числе параллельно) и сохранять этот скрипт в расписание с уведомлением на почту - обо всё этом здесь.
Простейший вариант скрипта
За сокращение журнала регистрации (для любых типов баз: файловых и серверных) отвечает ключ ReduceEventLogSize в пакетном режиме конфигуратора.
В качестве параметра он принимает новую (левую) границу журнала регистрации в формате ГГГГ-ММ-ДД.
И если мы, например, хотим сократить все записи в журнале регистрации до 1 января 2018 года, то простейший вариант скрипта будет таким:
Добавляем сохранение удаляемой части в архив
Но этого мало. Мы хотим не просто сокращать журнал регистрации (который обычно занимает непростительно много места на системном диске), но ещё и сохранять сокращаемую часть на другом диске (и желательно в сжатом архиватором виде). Чтобы в случае чего к ней можно было обратиться через меню "Файл-Открыть " в конфигураторе.
Предположим, что общим местом хранения архивов журналов регистрации (для всех баз) является папка "x:\Backups\1C\EventLogs".
Этот путь уже должен существовать.
Модифицируем наш скрипт, чтобы сокращаемая часть писалась в эту папку с правильным именем:
Сжимаем сокращаемую часть архиватором
Для этого файл выгрузки сокращаемой части упакуем архиватором 7z (он идёт вместе с обновлятором), а затем удалим сам файл.
Скрипт будет таким:
Всегда сокращаем журнал на текущую дату
У нас получился универсальный скрипт, который уже можно выполнять для группы баз и ставить в планировщик.
Если бы не дата, которая жёстко прописана в скрипте, что делает бессмысленным многократный запуск этого скрипта в неизменном виде.
Давайте изменим скрипт так, чтобы при его запуске всегда подставлялась текущая дата. Это позволит нам поставить скрипт в планировщик на запуск, скажем раз в месяц, и забыть о ручном сокращении журнала регистрации раз и навсегда.
Задача получить текущую дату в скрипте в формате ГГГГ-ММ-ДД не такая простая, если рассматривать универсальное решение для всех случаев жизни.
Но для случая, когда представление даты на компьютере имеет вид ДД.ММ.ГГГГ (обычно это так по умолчанию), вытащить нужные числа и поставить их в нужном порядке можно вот так:
Обратите внимание, что мы здесь просто вытаскиваем по индексу и длине нужные части из даты, которая первоначально имеет вид ДД.ММ.ГГГГ, то есть переводим строку в формате ДД.ММ.ГГГГ в формат ГГГГ-ММ-ДД.
В итоге получим вот такой скрипт:
Удаляем неиспользуемые страницы из журнала регистрации
Вы удивитесь, но несмотря на все вышеописанные процедуры, размер файла в котором журнал физически хранится в формате sqllite не уменьшится совершенно.
То есть если он был 10 гигабайт до процедуры сокращения записей, то 10 гигабайт и останется.
Всё дело в том, что, после удаления записей из журнала регистрации, физически данные с диска не удаляются, а лишь помечаются как удаленные. Это сделано для повышения производительности.
За сжатие журнала регистрации отвечает команда Vacuum, она позволяет удалить все неиспользуемые страницы и дефрагментировать данные.
Выполнение этой команды требует остановки сервера 1с (если речь о серверной базе), чтобы получить монопольный доступ к файлу журнала регистрации.
Поэтому я рекомендую сделать эту операцию (если файл журнала регистрации уже сейчас очень сильно вырос) один раз и в дальнейшем регулярно выполнять сокращение через ключ конфигуратора ReduceEventLogSize (мы его рассмотрели выше). Это позволит удерживать размер журнала регистрации примерно на одном уровне.
Подготовительные работы
Качаем и распаковываем вот этот пункт:
Там 3 утилиты, из которых нам нужна sqlite3.exe.
Альтернативное место для скачивания этой же утилиты - мой сайт (я подписал её своей электронной подписью).
Распакуем эту утилиту, например, в папку "x:\work" и соответственно будем обращаться к ней из скриптов как "x:\work\sqlite3.exe".
Vacuum для файловых баз
Для файловых баз выполним команду Vacuum через новый пакетный скрипт обновлятора, полагая что журнал регистрации хранится в папке с базой в "1Cv8Log\1Cv8.lgd".
Ещё раз напомню, что команду Vacuum имеет смысл выполнять уже после сокращения журнала регистрации при помощи описанного выше ключа конфигуратора ReduceEventLogSize.
Vacuum для серверных баз
С серверными базами всё несколько сложнее, в том смысле что полной автоматизации выполнения команды Vacuum для избранных баз простым пакетным скриптом не достичь.
Не достичь хотя бы потому, что невозможно автоматически определять путь к журналу регистрации серверной базы. Это нужно делать разбором файла настроек сервера 1с (1CV8Clst.lst), который тоже ещё надо правильно обнаружить. Все эти возможности выходят за рамки пакетного скрипта.
Но так как мы изначально планируем сделать Vacuum только после первого сокращения журнала регистрации, то полной автоматизации нам здесь и не надо.
Я опишу лишь примерный порядок действий:
1. Находим папку с настройками кластера 1с. Обычно это что-то типа: "c:\Program Files\1cv8\srvinfo\reg_1541".
Например, так (указанный внутри скрипт пишется и запускается в командном файле vacuum.cmd без обновлятора):
Перед его выполнением нужно остановить службу сервера 1с.
А что если нам требуется определить какой папке соответствует какая база? Для этого открываем файл 1CV8Clst.lst в корне reg_1541 и из него находим, что, например, папке 0deaa216-26dd-4ae0-9483-51a85b38c093 соответствует база test:
То есть мы можем выполнить vacuum как для всех баз на сервере, так и для избранных.
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Рассмотрим случай, когда log-файл 1С «распух» и занимает значительное место на диске. Сколько? Здесь все зависит от вашей конкретной ситуации.
Например, у вас файловая 1С — когда открываете папку с логами, то можете обнаружить файл *.lgp вполне солидного размера. До нескольких Гб. Это и есть Журнал регистрации 1С:Предприятия.
Возникает закономерный вопрос: «Можно ли его уменьшить или вообще избавиться?». Да, но сначала общие моменты.
Где находятся log-файлы
- \1Cv8Log — файловый режим.
- …/srvinfo/reg_xxxx//1Cv8Log — клиент-серверный вариант.
Форматы записи журнала
Новый формат ЖР (SQLite, *.lgd) появился в платформе 1С:Предприятия, начиная с версии 8.3.5. При обновлении платформы автоматическая смена формата ЖР не применяется.
Но если вы создаёте новую информационную базу либо пересоздаёте старую с очисткой каталога 1Cv8Log, на 8.3.5 или выше, то при отсутствии 1Cv8.lgf будет создан журнал нового формата.
На большом количестве пользователей новый формат журнала может оказаться хуже старого режима работы.
Как вернуть старый режим журнала регистрации
Для серверных баз:
- Остановите службу «Агент сервера 1С:Предприятия 8.3».
- Найдите папку 1Cv8Log интересующей вас базы по GUID (…/srvinfo/reg_xxxx/).
- Сделайте резервную копию всех файлов в 1Cv8Log в другое расположение. Можно сразу очистить каталог, если журнал не нужен. После копирования — удалите содержимое 1Cv8Log.
- Создайте пустой файл 1Cv8.lgf.
- Запустите службу «Агент сервера 1С:Предприятия 8.3».
Для файловых баз:
- Завершите работу всех пользователей с базой.
- Найдите папку 1Cv8Log по адресу файловой ИБ.
- Сделайте резервную копию всех файлов в 1Cv8Log в другое расположение. После копирования — очистите содержимое 1Cv8Log.
- Создайте пустой файл 1Cv8.lgf.
- Откройте файловую ИБ.
При необходимости — повторите шаги для каждой базы.
Рекомендации
- Для снижения нагрузки полезно уменьшить детализацию логирования. По умолчанию — значение «Регистрировать ошибки, предупреждения, информацию, примечания».
Настройка журнала регистрации
- Сокращение журнала за счёт удаления устаревших событий, через команду «Сократить». Где указываете дату, до которой требуется удалить события. С возможностью записи удаляемых событий в файл.
Сократить журнал регистрации
- Включите разделение журнала по периодам, выбрав из списка «Час/День/Неделя/Месяц/Год».
- С версии 8.3.12 есть возможность интерактивно выбрать формат ЖР. В данном примере предлагается изменить на новый формат SQLite, но рекомендуем все же оставаться на старом.
Изменение формата журнала регистрации на SQLite
Преобразование из SQLite в последовательный формат ↓
Преобразование журнала регистрации в последовательный формат
Особенности нового формата SQLite
В этом режиме настройка «Разделять хранение журнала по периодам» в Конфигураторе отсутствует. Остаётся кнопка «Сократить» для обрезки части журнала и переноса обрезаемых событий в указанный файл.
Одно «но!» — после этого размер 1Cv8.lgd не уменьшается. Для очистки необходимо выполнить команду vacuum.
- Перед запуском команды обязательно сделайте резервную копию файла 1Cv8.lgd.
- Второе — он не должен быть «занят»; в файловом режиме — без активных сеансов, для клиент-серверного варианта — при остановленном Агенте 1С.
Для этих целей используется утилита sqlite3, которую можно скачать с официального сайта.
Пример команды (расположение утилиты и lgd-файла у вас могут отличаться):
Проблема: На сервере растут логи баз на платформе 8.3.
Необходимо: Часть логов, например, за месяц, оставить доступными напрямую из базы, остальные обрезать и хранить на других дисках. Делать это необходимо автоматически.
Как было раньше(8.1 и 8.2): В конфигураторе можно было указать настройку: «Разделять хранение журнала по периодам» и указать период, например, Неделя. Таким образом, каждая неделя логов хранилась в отдельном файле. Батником копировались и архивировались старые логии на отдельный диск, чтобы они не занимали место на сервере. При необходимости посмотреть «древний» лог, мы возвращали файл за требуемый период на место и просматривали его стандартными средствами 1С.
Как нынче в 8.3: Журнал регистрации хранится в файле 1Cv8.lgd – это файл базы данных sqlite. Настройка «Разделять хранение журнала по периодам» в конфигураторе отсутствует. Осталась кнопка «Сократить», с помощью которой обрезается часть журнала и переносится в указанный файл. Однако после этого размер логов не уменьшается. Что нужно сделать, чтобы размер файла уменьшился, напишу чуть ниже.
Напомню, что все должно работать автоматически. Конфигурация типовая, поэтому трогать ее не будем.
Что было сделано: В планировщике заданий добавил задание, которое выполняет cmd-файл, который запускает 1С с параметрами. В параметре "/Execute", указан путь до обработки, которая копирует часть журнала регистрации в файл, затем эту часть обрезает.
В обработке воспользовался процедурами по работе с журналом регистрации:
Обработку запускаю cmd-файлом:
В параметре «/С» передается период деления журнала регистрации (День / Неделя / Месяц / Год) и путь до места, где будут храниться обрезанные логи.
После сокращения журнала регистрации размер файла журнала регистрации не изменяется. Чтобы он изменился, необходимо остановить агент сервера и выполнить команду vacuum. Затем запустить службу агента сервера. В планировщике заданий добавил задание, которое выполняет следующий cmd-файл:
Утилиту sqlite3.exe можно скачать с официального сайта
Есть идея более простого обрезания и сохранения логов без запуска 1С на сервере с обработкой: можно останавливать агент сервера, переименовывать файл 1Cv8.lgd и запускать сервер. При первом запуске 1С будет создан новый пустой файл журнала регистрации. Главный минус этого варианта: если после переименования файла потребуется посмотреть журнал регистрации, то придется открывать журнал из внешнего файла, который может лежать на недоступном для пользователя диске сервера. В варианте же приведенном выше, в журнале будет храниться история не меньше, чем за указанный период (День / Неделя / Месяц / Год).
В общем-то и все. Если есть замечания и дополнения, добро пожаловать в комментарии. Все важные нюансы обязательно добавлю в статью. Спасибо.
Когда при подключении к базе 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.
Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе - Задачи(Tasks) - Сжать(Shrink) - Файлы(Files) - установить Тип файла(File type) - Журнал(Log) - в Операция сжатия(Shrink action) - выбрать Реорганизовать страницы, перед тем осводить неиспользуемое место(Reorganize pages before releseasing unused space) - Сжать файл (Shrink file to) -
указать приемлемый размер лога.
Шаг 3. Установить модель восстановления Полная(Full). Правой кнопкой на базе - Свойства(Properties) - Параметры(Options) - 4-й сверху пункт Модель восстановления(Recovery model) - Полная(Full) - OK.
P.S.: В данной статье даны рекомендации для решения конкретной проблемы. Настройка самого MS SQL здесь не рассматривается!
Специальные предложения
(0) а зачем возвращать в состояние "Полная"?
Можно оставаться на Простой и рассчитывать только на бэкапы.
(1) Полная более гибкая. А для больших баз еще и быстрая: с одной стороны можно обеспечить маленькие интервалы восстановления, с другой быстрый бэкап в рабочее время.
(2) aspirator23,
Полный бред! Не видела ни разу ни одной фирмы, где в течение дня начинали восстанавливать бакап, а потом еще пол-дня чесали репу, какие доки/транзашки были сделаны, а какие нет(учитывая, что 30-50тичисленное стадо манагеров постоянно разбредается и никого не собрать по тубзикам-курилкам, чтобы выяснить где был реал-тайм).
Выводы: простой режим восстановления, ночной бакап + в обед, если уж так плющит(видела в одной конторке, где сотрудников принудительно выгоняют на хавчик из офиса и базы) и получасовые снапшоты, если уж совсем фобия.
ние дня начинали восстанавливать бакап, а потом еще пол-дня чесали репу, какие доки/транзашки были сделаны, а какие нет(учитывая, что 30-50тичисленное стадо манагеров постоянно разбредается и никого не собрать по тубзикам-курилкам, чтобы выяснить где был реал-тайм).
Выводы: простой режим восстановления, ночной бакап + в обед,
(46)
Мне казалось, что здесь идет около1С'ный тред, а не за банковскую, биллинговую, провайдерскую или какую-то еще сферу, где критически важны состояния баз данных на сотые доли секунды. В конце концов, я совершенно не представляю, что в хозяйстве, скажем, Грефа, администраторы БД режут логи.
ЗЫ. можно не вступать в дискуссию. просто мысли вслух. Всех благ.
у меня есть конкретный 1сный кейс где идет реплицирование транзакций на резервную ноду, восстановление при отказе порядка 2х минут, вариант отката на утро совсем не приемлем, так как к середине дня будет потеряно около 800 документов.
(48)
Не, не, не. Я не попадусь на вашу уловку безотказных кластеров, мирроринга и т.п. :)
Как говорится, это совсем другая история.
(6)
Несколько раз были случаи, когда главные бухгалтера ошибочно портили данные - перезакрывали закрытый месяц, удаляли документы в закрытом периоде. Вот тут и пригождались почасовые бэкапы. Благо места занимают мало.
(50)
Ну, не знаю. Удалять документы в закрытом - запрет редактирования. В конце концов, повторюсь, проще делать снапшоты пока главбуня развлекается с ограниченным периодом полураспада(жизни)
(13) Важное замечание сделал(11).
1.Насчет того что "разрастается лог, который часто занимает весь диск" - это не обсуждаем.
SQL сервер тоже нужно настраивать, а не просто поставить по умолчанию.
2."предпочтительно использовать именно простую модель, с каждодневным бакапом" - я уже писал, что простая модель хороша для небольших баз. А также в случае если требования по восстановлению
никто не заявляет. А вот если заявляет и база большая, то простой моделью не выкрутишься.
Либо не обеспечишь нормальную периодичность восстановления, либо если обеспечишь, то тогда база будет ложиться
в момент выполнения полного бэкапа при простой модели.
- я уже писал, что простая модель хороша для небольших баз. А также в случае если требования по восстановлению
никто не заявляет.
Простая модель хороша для любых баз (и больших и не больших), если нет требований по восстановлению на любой момент времени.
Отчего же не обсуждаем? Вы знакомы с проблемой "база загружена не полностью" и её причиной?
(21) МихаилМ,
как бы работа самой базы? Наставляемые обновления? Изменения в конфе? Нет?
Это все не приводит к увеличению лога?
(3) batan, данная процедура нужна в том случае, если логи сильно разрастаются. Было у меня на практике, когда нерадивые сисадмины не следили за логами и они разрастались до размеров нескольких сотен ГБ (240 Гб если быть точным, был и в 70 Гб). Поэтому и приходилось выполнять такие манипуляции.
(5) То что написано делается без "выгоняния" пользователей.
(6) Попробуйте поработать с большими базами данных. Тогда и опыт появился бы и понимание как это работает.
То что вы не видели, не означает, что у всех также.
если про "Усечь журнал транзакций" в 2012 - то он не всегда отрабатывает. А лог нужно урезать обязательно.
(5) caponid,
Когда у вас будут вводить по десятку документов в секунду, тогда и оцените восстановление на любой момент времени.
(9) dvv01,
А потому, что принудительно лог очищается ВСЕГДА. А не как придется в случае автошринка при выгрузке.
А есть случаи, когда нужно обрезать только лог, без бэкапа.
делаем то же самое. работает на 100%. Выгонять пользователей не нужно. Место на диске за 3 минуты освобождается.
На одной из картинок в параметрах есть такое свойство как "автоматическое сжатие = FALSE".
А почему сразу его не поставить в TRUE? И забыть про все вышеописанное?
(9) dvv01, можно даже настроить, чтобы с логом вообще проблем не было, но в данном примере рассмотрено как это можно сделать просто и быстро
Вредительская статья. Уходить на простую модель без предварительного полного бэкапа - мягко говоря опрометчиво. Ну в общем то и формулировка задачи странная. Проще 1 раз настроить задания по созданию бэкапов и обрезанию логов (о боже с запросами, да да) и забыть об этом.
criptid; Areal; Gang031; Andre_ultra; nvv1970; msvd; DmitrySinichnikov; alest; Дмитрий74Чел; tehas; DissideNtAGiTatoR; randa; Den_D; + 13 – 3 Ответить
Автор забыл добавить что после обратного перехода на полную модель нужно собственно сделать полный бэкап, так как он предыдущими действиями прервал цепочку восстановления, соответственно если есть задания по бэкапу оно не будет выполнятся, пока не пройдет новый фул бэкап.
Метод описанный в статье имеет право на жизнь, но лучше все изначально грамотно спроектировать, что бы проблема с "внезапно" выросшим журналом не было в принципе.
(11) Babuin, по-поводу полного бэкапа добавлю. А вот насчет настройки - это отдельная тема. Я лишь показал, как по-быстрому место освободить. У самого базы висят и все настроено. Так что настройку тут не рассматриваю.
(11) Внезапно выросший журнал, говорите? Легко!
Работает всё давно. Клиент без обслуживания админом, зовёт раз в пятилетку на проблемы. И тут решает он переработать каталог. И в течении двух недель его активной деятельности шлёпаются изменения по паре гигов в час. Внезапно диск под архивы заканчивается и покуда никто за этим не следит, следом, так же внезапно заканчивается и место на диске с логами. И всё. Ничего никуда не едет. Вот теперь можно и админа звать )))
Идея неплоха, но в заголовке статьи не хватает надписи "в экстренном случае" или "когда штатные средства не позволяют"
Действительно, бывают запущенные ситуации, когда с логом уже ничего сделать нельзя (ни бэкап, ни шринк).
Я правильно понимаю, что эта операция поможет в случае, когда на диске уже почти не осталось свободного места?
(12) bforce, дельное замечание по-поводу названия. Да, когда места нет, а его нужно срочно освободить.
Я обычно делаю скриптом. Быстрее получается.
Также можно настроить выполнение по расписанию.
без предварительного выяснения, почему увеличился размер transaction log,
нет смысла его усекать. втом числе и автоусекать.
У меня база 90 Гб. В режиме Siple, ибо то что делают юзеры и программеры с базой часто в модели Full увеличивало базу раз в 5. Даже в Siple модели лог увеличивается, если есть большое количество изменений (15-30 Гб бывает).
Для откатов, делаете дифференцированные бекапы базы в продолжении для (периодичность скажем час) и всё что нужно есть.
Шринк да базе 90 Гб при полной модели при робочих юзерах (лог файл 50-150 Гб) нивжизнь не пройдёт, или будет делаться очень долго. Так как при полной модели в основной базе ещё нет изменений, которые хранятся в лог-файле, а если юзера работают с данными, изменения по которым должны быть записаны. Ну и немаловажный факт - количество юзеров. У меня их за 100 одновременно работающих. Транзакции никто таки не отменял.
Как одноразовая мера, чтобы если база выжрала всё место на диске и отказывается работать, вполне оно. Все равно никто работать уже не будет. Тогда да, это самый эффективный вариант.
(23) echo77, не захотел создавать тестовую базу вот на ней и показал. Действительно, нужно будет изменить скрины.
как раз такая ситуация пришла. База была брошена, франчи установили, уехали и никому до неё не было дела - никакого бэкапа - так иногда только DT-шники выгружали и то когда вспомнят. НО после проведения реиндексации реструктуризации лог вырос до 300 ГБ при базе в 45 ГБ. и почти кончилось место на диске.
причем реально база 19,5 ГБ в локальной файловой копии.(45 ГБ стала после загрузки в существующую DT-архива - может подскажете как правильно вернуть назад. ).
Сделал все как в статье (не стал БЭКАП делать ибо некуда. ограничился выгрузкой в ДТ-архив.) при неработающих пользователях. размер указал 30 ГБ. Шринк прошел очень быстро. Щас настраиваю планы обслуживания (пока на тестовой базе) и ставлю вопрос о приобритении винта специально под бэкапы.
Но у меня такой вопрос
Вроде установил модель обратно в FULL, но даже сделав реиндексацию таблиц после этого размер журнала не изменился. и мало того уже рабочий день заканчивается - куча проведеных документов была, но размер какой был такой остался и дата изменения не изменяется (последние изменения базы - 0:22 - ночью в базе никто не работает кроме меня:) а лога аж 22 числа, т.е. 2 дня назад) - у меня установлено автоувеличение лога на 200 Мб, а базы на 500 МБ, может быть дата изменения меняется только во время увеличения размера.
Хотя после реиндексации размер лога должен был увеличиться на 25 ГБ (так было до шринка) - может кто нибудь разъяснить почему лог на месте стоит? - планы бэкапов еще не подключал т.е никакого архивирования нет.
Есть не самый простой и быстрый, но очень надежный рецепт усечения "пустого" (т.е. данных там нет но файл не уменьшается) файла ldf. Применяю когда ничто другое не помогает. Правда если изначально (при создании базы) файл был создан определенного размера, то этот способ тоже не поможет.
Рецепт простой:
//начинаем транзакцию
BEGIN TRAN
GO
//делаем апдейт какого нибудь поля какой нибудь большой таблицы
UPDATE .
GO
//отменяем транзакцию
ROLLBACK
GO
После этого файл можно усечь на размер заполненных данных в файле ldf.
Рецепт используем столько раз, сколько потребуется.
Зачем используете ПОЛНУЮ модель, если шринкуете транзакционный лог? НУ да ладно это другая тема, а по этой можно просто выполнить запрос (Для примера имя БД "Base"):
Спасибо автору реально помогло. Такой вопрос а где можно почитать по поводу настройки SQL сервера поделитесь ссылками )))
Вчера столкнулись с проблемой большого лога. Спасибо автору, статья полезная. Мне не понятно одно, 1С Сервер может вопрос логов как-то регулировать?
1С вообще практически ничего не может на SQL. SQL-сервер - он сам по себе, и сам управляет своими логами.
Из всего сказанного и из комментариев я что то не совсем понял. Если мы используем полную модель восстановления, сделали полный бэкап, обрезали лог базы, и если вдруг понадобиться восстановиться из бэкапа, то ничего не получиться?
все получится - восстановится на момент бекапа полностью.
Полная же модель подразумевает - восстановление на любой момент времени, что невозможно, если данные транзакций уничтожены (лог транзакций стерт). Поэтому его в таком случае не трут, а также бэкапят вместе с базой. Но это именно для тех, кто понимает, что ему нужно. Для остальных - SIMPLE режим :)
Из всего сказанного и из комментариев я что то не совсем понял. Если мы используем полную модель восстановления, сделали полный бэкап, обрезали лог базы, и если вдруг понадобиться восстановиться из бэкапа, то ничего не получиться?
При полной модели восстановления бэкапы делаются так часто как это возможно для того чтобы процесс восстановления начинать не с испокон веков существования базы а с последнего полного созданного бэкапа + далее накатывают после этого бэкапы логов транзакций. это очень удобно хотя на практике приходилось пользоваться всего пару раз в жизни. У нас например это раз в неделю по четвергам (самое оптимальное время исходя из всех регламентов скуля + сервера 1С).
При простой модели вы сможете восстановить базу только на момент последнего созданного бэкапа.
Если у вас есть нормальное ПО по управлению бэкапами и логами ТЗ (хотя все это можно написать и на SQL) то делается просто.
Полная модель. Создается бэкап базы, хранится, далее бэкапятся логи раз в нужное вам время у нас это 15 минут, логи тоже хранятся, но каждый раз когда проходит полный бэкап базы НОРМАЛЬНО все старые бэкапы базы и логов трутся и начинается новый отсчет времени. Ну и так же настроено месячное хранение базы полугодичное и годовалое которые хранятся отдельно и трутся соответственно когда создаются подобные бэкапы.
При полной модели и наших настройках мы можем восстановить базу максимум с недельной давностью, далее все остальное накатить логами.
Так же мы можем восстановить базу на начало месяца, начало полугодия и начало года но уже без логов транзакций.
Насчет тормозов не могу согласиться с предыдущими ораторами о том что простая модель работает быстрее, они работают одинаково если нормально настрое сервер SQL, просто лог транзакций должен по умолчанию лежать на другом зеркале, отдельно от того зеркала где располагается база. Много раз проверяли что так что так работает одинаково. Если же логи транзакций лежат на том же массиве что и база - безусловно будет работать медленнее.
Если до работы в 1С:Предприятии 8.3 Вы пользовались предыдущими версиями программы (8.2, 8.1, 8.0, не говоря уже о 7.7), то не могли не заметить, что при переходе на версию платформы 8.3 размер информационной базы (ИБ) значительно возрос.
Во-первых, уже просто пустая база занимает места столько, как будто в ней уже очень много данных. Во-вторых, в процессе использования программы размер базы растёт значительно быстрее.
Во многом увеличение размера базы 1С:Предприятие 8.3 в сравнении с предыдущими версиями обусловлено переходом на "управляемые формы", но мы это здесь обсуждать не будем, а рассмотрим некоторые способы сокращения размера базы, которые могут быть полезны обычным пользователям программы.
К сведению программистов, сисадминов и прочих IT-специалистов
Статья предназначается в помощь обычным пользователям, поэтому если Вы знаете какой-то сложный метод, позволяющий уменьшить базу, но который не сможет применить рядовой пользователь 1С, просьба воздержаться от подобных предложений.
Помним, что значительная часть пользователей 1С:Предприятие не разбирается (и не обязана разбираться) в технических особенностях устройства программы, а также функционирования операционной системы и компьютера в целом.
Замечание для обычных пользователей
Поскольку для 1С:Предприятие есть много разных конфигураций, а проблема размера базы одна на всех, то приводить конкретные примеры (если они касаются конфигурации, а не платформы) мы будем для "Бухгалтерии предприятия".
К другим конфигурациям всё сказанное применимо "по аналогии".
Итак, посмотрим некоторые способы сокращения размера базы 1С, а также как сделать так, чтобы база не увеличивалась чрезмерно.
Отказ от ответственности
Все операции, предлагаемые в статье, Вы выполняете на свой страх и риск. Мы лишь приводим информацию в образовательных целях.
Если у Вас есть сомнения - обратитесь к специалисту по 1С Вашей компании.
Не загружайте в базу КЛАДР/ФИАС полностью!
Довольно часто происходит следующее: пользователь берёт и загружает все регионы адресного классификатора. Происходит это обычно по трём основным причинам:
- Пользователь новичок и "не подумал", зачем ему все регионы в базе, то есть загрузил "на всякий случай".
- "Не знал", что можно загрузить только часть справочника (маловероятно, но и так бывает).
- "Надоело" время от времени добавлять новые регионы, когда они реально требуются, но при этом не загружены (два-три-четыре раза добавил новые регионы, а потом надоело и решил загрузить сразу весь справочник, чтобы больше на это не отвлекаться).
В результате в базу 1С попадает очень много лишних данных, а размер самой ИБ возрастает очень существенно. Давайте посмотрим, на сколько именно:
- версия 8.2: 1500 Мб ( + 1 Гб к пустой базе);
- версия 8.3: 3000 Мб ( + 2,5 Гб к пустой базе);
Таким образом, не стоит загружать те регионы, которые реально не используются. Это не просто лишние данные, но они также попадают и в резервные копии (что увеличивает размер бэкапа, а также время его создания).
Если Вы уже загрузили лишнее, то удалите ненужные регионы и размер базы уменьшится.
Как уменьшить старую базу 1С:Предприятие
Это решение подходит для тех случаев, когда база существует давно (годы) и документов в ней накопилось очень много. В таком случае можно избавиться от части документов, выполнив специальную операцию, которая в 1С называется " свёртка информационной базы ".
(!) Обратите внимание, что эта операция не может быть отменена (кроме как восстановлением из резервной копии), поэтому подумайте перед её выполнением (и сделайте копию базы).
Принцип свёртки заключается в том, что в базе есть старые документы, которые на 100% никогда уже не понадобятся. От них можно избавиться, урезав базу до определённой даты (до какой - смотрите сами).
Данная операция выполняется из раздела Администрирование. Где конкретно находится этот пункт, зависит от точной версии программы и конфигурации (в любом случае есть быстрый поиск по меню). Ниже приведён скриншот для одной из версий 1С:Бухгалтерии 8.3.
Читайте также: