Журнал регистрации в SQLLite. Как урезать? #742418

Сделал штатное сокращение. Место на диске уменьшилось. Как я понял, всё теперь в логе сидит (в логе лога :) Там три файлика - lgd, lgd-shm, lgd-wal. Подозреваю, что последний и есть этот самый лог, судя по размеру. Как этого гада шринкнуть?

открыть каким-либо просмотрщиком sqlite. vacuum закрыть.

У меня Линух. Может, я что не так делаю... Поставил sqlite3 Успешно приаттачил lgd. Сделал вакуум... Никаких изменений. Команду проглотил мгновенно и ничего не сделал.

По-ходу выяснил, что sqlite даже вьюхи и триггеры поддерживает. Вау!

Попробуй не аттачить, а просто открыть: sqlite3 имяфайла vacuum .quit

а просто удалить файлы журнала?

Да, что-то я намудрил с этими аттачами. Запустил просто sqlite3 1Cv8.lgd "VACUUM;" Вроде задумался... Подождем. А мне не надо просто удалить.

попутно такой вопрос есть ЖР за 2014 год (160гиг), надо его разбить на 4 файла (по квартально), как сделать?

а чего же тебе тогда надо?

неужели никто еще не сделал обработку из 1с для администрирования нового лога?

Разбить-то не проблема. А вот прозрачно с ними потом работать, по-ходу - не предусмотрено. Сократить до указанной даты (all) Короче VACCUM шринкнул, но как-то странно. Шринкнулось почти до первоначального размера (до сокращения). При этом уменьшился именно lgd, а lgd-wal наоборот - подрос. При том, что штатно на рабочих базах он в десятки раз меньше.

Для разбиения можно использовать штатные СкопироватьЖурналРегистрации и ОчиститьЖурналРегистрации. Для обоих можно сложные фильтры указывать.

В общем, в плане разбиения на файлики со старым форматом удобнее работать было.

Но в новом формате особой необходимости в разбиении как бы и нет.

"Сократить до указанной даты" а где ты в команде VACUUM дату указал?

хм... у меня за год 200 гигов лог... так ведь это бухгалтерия из 8 человек... а если человек 100 работает? банально бекапить его надо? отдельные файлы бекапить только по изменению, а такой огромный - не есть гуд, а всякие диф бекапы на файловые наверно есть, но что-то меня они пугают...

Нигде. Сократил штатно до этого. Ежедневный диф-бэкап журнала регистрации? Хм... Никогда таким не заморачивался. Умер максим да и хрен с ним. Но если надо - то таки неудобство выходит. Это да. (all) Терзают меня смутные сомнения, что ентот lgd-wal - это одноэсный велосипед какой-то... Какие-то доп-хрени сбоку от основного лога.

А, нет. Таки штатные.

кстати 1с не рекомендует новый формат жр на большой нагрузке (от 100 чел)

Таки я был прав. Это лог. WAL stands for Write Ahead Logging and is some kind of optimization to make transactions faster. VACUUM, выходит, только базу чистит. Может, лог сам шринкается? Но вот когда? Может, когда его "отпускает"? При рестарте сервера приложений типа или еще как-то? Будем посмотреть.

Пруф?

что такое lgd-wal в документации написано. почитай и тебя не будут терзать смутные сомнения.

+ если не хочешь просто удалять файл то попробуй прагму отсюда

+ например PRAGMA wal_checkpoint TRUNCATE

Да я уже нашел типа: 1. -shm file contains an index to -wal file. -shm improves the performance of reading -wal file. 2. If -shm file gets deleted, it get created again during next access to database. 3. If checkpoint is run, -wal file can be deleted. Короче

Ага, спс.

TRUNCATE - нету такого. Чекпоинт сделал. Прибил руками shm и val. Теперь 1С при попытке открыть журнал регистрации пишет sqlite3_exec failed: disk I/O error sql: PRAGMA journal_mode = wal Но хоть при работе не падает. Видать при записи исключение обрабатывается :)

SQLite журнал регистрации к сожалению плохо ведет себя в нагруженных системах. Уже известен ряд проблем связанных с ним. На текущих версиях 8.3.5 при проблемах с этим журналом мы можем порекомендовать использовать старый журнал регистрации. Для это в директории реестра кластера (reg_<Port>) внутри директорий с GUID есть директории 1Cv8Log в них лежат файлы sqlite. Если их перенести а в директории создать пустой файл 1Cv8.lgf, то начнет писаться журнал регистрации как в старых версиях. Следует иметь в виду что журнал будет пустой. Данные останутся в перенесенных файлах.

А, блин. TRUNCATE надо было в скобки брать...

Хм... Будем иметь в виду. Хотя с проблемами пока не сталкивался.

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

Всё страньше и страньше. Лог таки 1С пересоздала, но работать с ним не может :) Сыпет sqlite3_prepare_v2 failed: SQL logic error or missing database sql: SELECT code, name, uuid FROM UserCodes; Хотя весь комплект файлов в наличии...

ясен пень на лету нельзя :)