Журнал регистрации 1С на SQLite - из-за чего возникают сбои? #759191

Периодически журнал регистрации 1С 8.3 портится (неизвестно из-за чего), пишет сообщение, дескать, malformed, и всё. Перенос или удаление файлов журнала регистрации решает проблему, но ценой обнуления журнала. Читаю - вроде все в этой СУБД по теории - однако сбои-то налицо (я очень надеюсь, что сбоит не у всех). Есть умные настройки SQLite с выбором между скоростью и надежностью: интересно, каковы они в 1С.

Периодически журнал регистрации 1С 8.3 портится (неизвестно из-за чего), пишет сообщение, дескать, malformed, и всё. Перенос или удаление файлов журнала регистрации решает проблему, но ценой обнуления журнала. Читаю - вроде все в этой СУБД по теории - однако сбои-то налицо (я очень надеюсь, что сбоит не у всех). Есть умные настройки SQLite с выбором между скоростью и надежностью: интересно, каковы они в 1С.

У 1С, как всегда. Рассчитано для ларька. :)

Блин. Ну когда же 1с сделает хранение ЖР в основной базе, а не отдельно от неё? Это же напрашивается просто!

+ для sql-версии, конечно же. В файловой пусть остается как есть.

Трое суток журнал восстанавливал прошлый раз после сбоя. Слетел при обновлении платформы. Что-то они там недоперемудрили.

Сделай свой журнал через регистры сведений

И не раз

Вчера восстанавливал по инструкции, указанной в .

Пардон

тоже не раз сталкивался

В backbas.dll в составе 1С:Предприятие 8.3 (8.3.6.2299) стоят такие прагмы: В sqlite.dll есть подстрока PRAGMA vacuum_db.synchronous=OFF

Думаю надо заменить     PRAGMA journal_mode = OFF на The WAL journaling mode uses a write-ahead log instead of a rollback journal to implement transactions. The OFF journaling mode disables the rollback journal completely. No rollback journal is ever created and hence there is never a rollback journal to delete. The OFF journaling mode disables the atomic commit and rollback capabilities of SQLite.

где заменить ?

Внутри DLL backbas.dll - хотя наверное правильнее 1С попросить, это только моя гипотеза. Или в настройку это вынести...

Если я правильно понимаю, WAL применяется в MS-SQL и в других базах данных, чтобы при выключении питания и других сбоях можно было откатить неудачную транзакцию.

написал на v8@1c.ru ?

пока 1с НЕ РЕКОМЕНДУЕТ новый формат )))

где про это указано ?

на партнерском форуме было

на курсах по эксперту тоже самое говорят

Для высоконагруженных решений конечно же

в 8.3.7 может быть починили. МОЖЕТ БЫТЬ

Для новых ИБ он ставится по умолчанию, и вернуть старый невозможно.

возможно

Нет ничего лучше для записи логов, чем обычный текстовый файл.

... Если их перенести а в директории создать пустой файл 1Cv8.lgf

нет ничего хуже для ЧТЕНИЯ логов чем ...

Хотя если бы в 1с была встроена нормальная система версионирования, то лог файл был бы не нужен

Да фиг с ним с версионированием. Почему просто не хранят лог внутри базы как таблицу?

Для чтения тоже быстрее простого файла ничего нет. А вот для анализа... Во всем мире логи кидают в текстовые файлы, а потом конвертят их по мере надобности в любой приемлемый формат, одна 1С, как всегда, идёт поперёк. Я вообще не понимаю, как они умудряются запороть файл базы данных sqlite, который вообще-то один из самых надежнейших форматов.

потому что при фатальной ошибке с базой, не почитаешь что случилось + бэкап растет

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

Текстовый лог - хорошо и удобно. Одно непонятно - как 1С умудряется так медленно с ним работать?

Видимо через прагму, которая запрещает журнал транзакций PRAGMA journal_mode = OFF см.

Для чтение быстрее блочное чтение )

нельзя ибо транзакции

Сейчас попробую написать. Частенько использую текстовый лог, но в 1С и с ним проблема (хотя можно извернуться через FileSystemObject). Требуется отбор по пользователям, кто чего менял, тут с базой, наверное, ловчее. Я бы завел по месяцам, 12 баз в год. Есть же версионирование как внешняя примочка? ВерсииОбъектов, ВерсионированиеОбъектов etc.

То есть, нельзя на sql-сервере произвести запись в таблицу вне текущей транзакции? Если так, то да, проблема.

Хотя если отдельная очередь будет в отдельном сеансе, то можно

Это должно было быть сразу, и тогда бы никому журнал регистрации не нужен был, максимум - вход - выход фиксировать

На отдельный сервер/БД же можно - там же свои транзакции.

Можно в Медиавики отгружать :-)

По идее да. Если клиент откроет два сеанса на sql-сервере, один для работы с данными, второй - для протоколирования, то транзакции мешать вести лог не будут.

Готово, ушло. Предложил сделать или вынести это в административные настройки: тогда, я думаю, это обеспечит требуемую для высоко-нагруженных баз степень надежности - а для кого критична скорость, тот поставит PRAGMA journal_mode = OFF. И проблема SQLite, если я правильно ее вижу, будет решена.

>> когда же 1с сделает хранение ЖР в основной базе, а не отдельно от неё? Это же напрашивается просто! Не моё мнение: СУБД не совсем подходит для ведения журнала. Используя ее мы платим за то что не будем использовать. Это связано с особенностями нагрузки, которая характеризуется огромным и последовательным по времени трафиком на запись, минимальными изменениями данных и сильно разреженными выборками. (SQLite был выбран в качестве компромисса между субд (клиент-серверной) и хранениями в файлах. Кроме того для файлового варианта использование СУБД вообще чуждо. Решение перехода на SQLite связано с фундаментальными проблемами в старом журнале регистрации. В частности долгие выборки по любым запросам.

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

Для файловой sql-журнал вообще не уместен, особенно при многопользовательском доступе. Тут текстовые файлы рулят. А для клиент-серверной - почему бы и нет, если мощностей сервера хватает? Можно в конце концов сделать это опцией.

А там же физически файл, SQL сервера как такового нет.

Вот именно, и за этот файл конкурируют на запись куча клиентов, в каждом свой "встроенный сервер sqlite". Это такое же зло, как и 1cd по сети.

ты не прав. сервер сам пишет в эту базу. клиенты - нет

SQLite ставит блокировку на файл. Блокировка может быть сделана корректно (с паузами) - думаю, что там это так и есть, и тогда не должно быть «плохой конкуренции» между клиентами, потоками сервера и т.д., которые одновременно пытаются что-то писать. Тут для 1С 7.7 я делал патч: А у сервера много потоков исполнения может быть, там тоже конкуренция (хочется надеяться, что там она корректная и, так сказать, честная).

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

Какой сервер в случае файловой базы?

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

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

Для чтения быстрее всего отобразить файл в память и работать с ним как с куском памяти.

На 32-битных системах это ограничивает доступный размер файла 4 гб.

Да, есть различные разработки, кто-то писал на .NET выгружалку и выложил с исходниками. Но она тоже ведь встанет при ошибке «malformed». Хотя, может быть, и с меньшей вероятностью, если SQLite-базу все время обнулять подчистую (она чистая и шевелиться будет в течение дня быстрее). С блокировкой файла трудно ошибиться, но я подозреваю, что в 1С еще какая-нибудь Прагма отключает еще и это. :-)

Там еще несколько опций, насколько я понимаю, WAL - это то, что делает MS-SQL со своей базой (гарантируя при этом безошибочный откат транзакций). И там компромисс между двукратной записью и полным отсутствием защиты. :-) А это смотря с какой целью: если вы хотите отобрать события по объекту (документу, элементу справочника) или пользователю, то ничего быстрее СУБД с индексами придумать в принципе нельзя, даже при неограниченном ресурсе ОЗУ. АВЛ-деревья не спроста же придумали в далеком-далеком СССР.

Лучше бы 1С разрешила писать запросы на языке хранилища БД. если это SQL, то пишется на SQL, английскими буковками, используя только транскрипцию Реквизитов, как это было реализовано у 1С++ :)

Вот ты не поверишь. Но я столкнулся с системой, где вот такой подход приводит только к тому, что анализировать Лог просто нереально долго :) ... Идея от 1С писать в SQLlite приветствуется, но все же встает вопрос, почему не было реализовано в составе БД? Зачем было придумывать костыль? Да, может для файловой БД, это и приемлемо. А вот для других версий, SQL и .т.д. уже трагично глупо со стороны 1С :)

Кстати, в своё время реализовал хранение жр в отдельной сиквельной базе. Прям все летало. Потом с переходами-переездами как-то потерялось. А насчёт хранения в БД - версионирование этож тот же лог изменений.

Версионирование средствами прикладного решения - костыль. Это должна обеспечивать платформа независимо от прикладного решения.

Логи разрастаются - это первое, что хочется куда-нибудь вынести, обрезать/сократить и так далее. Например, в ситуации когда на диске кончилось место и надо что-нибудь предпринять.

Необходимость резать логи встречается не чаще, чем необходимость резать базу.

а еще лучше 0 прямая печать на матричный принтер и не затрешь потом )

Точно. Как в банковских калькуляторах у кассиров. Все расчеты печатаются на ленте. Что там умножал и делил - всё можно раскрутить потом.

Потеря базы - это полный аншлаг и все бегают ищут копии, а за потерю логов на практике даже не журят. Ну вот потерялись у нас целых 3 раза, и вроде пока все тихо. То есть, у них ценность другая, а размеры при этом могут быть сопоставимы с основной базой, все эти десятки гигабайт не хочется ежедневно бэкапить. Хотя, в каких-то применениях эти данные могут быть важны, но в этих случаях почему бы не хранить полную историю важных документов через Версионирование 1С.

С чего бы это? Никак это размер файла не ограничивает. Просто отображать будешь "скользящим окном". А вообще как и что с логами делается - во всём цивилизованном мире давно уже решили, одни одинэсники не знают, куда приткнуться, и пытаются велосипеды выдумывать.

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

У мня РИБ-база и мне проще - есть узел, база где не только полный архив базы на случай оперативного восстановления, но и версионирование документов. В этой базе пользователи не работают и проблема производительности меня не волнует.

поделись с миром 1с-ников достижениями в области хранения логов, только чтобы начиная хотябы от 100М записей с возможностью отбора по объекту и пользователю.

Видимо, быстрее всего писать лог в текст (при этом не выстраивается индекс и нет зависимости скорости записи от объема лога), а потом (например, ночью) его считывать второй БД, а текстовый лог обнулять или перемещать. Для многих внедрений SQLite может быть и оптимальный вариант, есть же всякие бухгалтерии и ларьки. Вообще эта часть разработки платформы может быть не самой трудоемкой: ну заменили DLL ту на эту, что-то изменилось к лучшему, а кому-то понравилась бы и другая опция, я думаю, что со временем и другое тоже разработают, когда дойдут руки/приоритеты. Москва же не сразу строилась.

Вот, до romix'а вроде дошло уже. Что ПИСАТЬ в ЛОГ и АНАЛИЗИРОВАТЬ лог - две разные вещи. Поэтому во всём мире мире ЗАПИСЬ лога осуществляется в обычные текстовые файлы, из которых затем различными КОНВЕРТЕРАМИ информация преобразуется в вид, удобный для АНАЛИЗА. Самое простое средство из цивилизованного мира - logrotate. До его принципа в romix сам додумался. Поэтому на месте одинэсников я вместо ведения журнала в sqlite выпустил бы удобный конвертер, который бы с задаваемой пользователем периодичностью заводил новый файл журнала регистрации, а старый бы конвертил хоть в sqlite, хоть в чёрта лысого.

ну дак до склайт так и было, решили совместить, потому как тормзоил ЖР.

"до склайт" было не так. Журнал никуда не конвертировался, а читался из этого же файла.

Сбоит регулярно. Приходится удалять. До применения SQLite логи работали без сбоев, хотя и медленно. Не понятно для чего нужно было использовать SQLite когда есть сервер СУБД основной базы. Почему не использовать его для хранения отдельной базы логов.

Логи, как и бекапы, нужно хранить отдельно от основной базы. Это же азы безопасности. У меня даже роутер выкидывает свои логи на удалёнку...

Зачем? Это не технологические логи, в отрыве от ИБ смысла в них мало.

сейчас эти логи тоже хранятся отдельно. Не понятно почему в формате SQLite а не в формате СУБД основной базы.

ничто не мешает настроить физически отдельное от основной базы место хранения базы логов. Не понятно для чего использовать формат SQLite когда есть формат и сервер СУБД основной базы.

pragma journal_mode=wal приводит к частым непрогнозируемым зависаниям и деградации производительности на нагруженных базах или при достаточно большом периоде работы. В случае возникновения проблем мы рекомендуем использовать старый журнал регистрации. Для этого из каталога журнала регистрации следует перенести файлы 1Cv8.lgd, и создать пустой файл 1Cv8.lgf.

К сожалению ты не в 1С (((

Я подозреваю, что все проблемы решит сочетание  journal_mode=wal и посуточного обрезания лога (365 файлов в год). Или то же самое - с текстом (если получится его методически корректно распарсить в стороннюю базу 1С или SQL).

ну текстовые резать вроде платформа сама умеет

Отправил в 1С предложение добавить там мьютекс (скорее всего, транзакции SQLite не распараллеливаются, и это приводит к зависаниям серверных процессов) и посоветовать методически правильное средство для сбора информации из текстовых логов (может, уже есть готовое, или планируется к разработке).

журнал регистрации пишет 1 процесс. там нет никакой параллельности

а именно агент сервера rgmgr

Потоки же там по числу пользователей, нет?

Похоже они просто не умеют правильно работать с sqlite.

1 поток

Там видимо надо поставить режим WAL и распараллелить потоки мьютексом (наверное сейчас долбятся повторами при ошибках SQLite). На нагруженных же базах лог собирать из текстов по ночам в, скажем, вторую базу 1С с логами в регистре сведений (без SQLite). Как-то так. Не верю (с) Станиславский. Если два пользователя одновременно записывают документы, то как там один поток может быть?...

в серверной пишет . В файловой не знаю

тебе же писали уже, что WAL глючит. Накой тебе этот WAL дался? Пускай тупо в текстовый файл пишут и все будут счастливы.

а поиск?

писали же уже. загружай куда хочешь и ищи сколько хочешь. в тот же SQLite.

Ну, мьютексом потоки не распаралеливаются, а наоборот - выстраиваются в очередь. Писать в sqlite базу в один момент может только один писатель. Поэтому если всё-таки вести лог в sqlite - я бы выделил один специальный поток, в который все остальные асинхронно посылали сообщения, а он их выгребал из очереди и писал в базу. Деградация производительности в wal режиме возможна, если какой-либо из читателей не закрывает запрос на выборку. В этом случае sqlite считает, что есть активные читатели и не может сделать "чекпоинт" - скинуть содержимое из wal-журнала в основную базу данных. Из-за этого разрастается список страниц, размещенных в wal-журнале. А в wal-режиме при любом обращении к странице данных сначала проверяется этот список, чтобы узнать, в каком из файлов находится актуальная версия. Имхо, проблему можно решить и без 1С, если административно раз в сутки перезаводить текстовый ЖР, и конвертить прошлый в вид, удобный для анализа. Но при этом все штатные средства просмотра журнала пойдут лесом, а многих такой путь не устраивает, все хотят "vendor way".

Так это нужно самому все делать