Периодически журнал регистрации 1С 8.3 портится (неизвестно из-за чего), пишет сообщение, дескать, malformed, и всё. Перенос или удаление файлов журнала регистрации решает проблему, но ценой обнуления журнала.

Читаю http://habrahabr.ru/post/181584/ - вроде все в этой СУБД по теории - однако сбои-то налицо (я очень надеюсь, что сбоит не у всех).

Есть умные настройки SQLite с выбором между скоростью и надежностью: интересно, каковы они в 1С.
http://www.sqlite.org/draft/pragma.html#pragma_synchronous

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

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

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

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

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

И не раз

Вчера восстанавливал по инструкции, указанной в http://catalog.mista.ru/public/402536/.

Пардон http://catalog.mista.ru/public/402536/

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

В backbas.dll в составе 1С:Предприятие 8.3 (8.3.6.2299) стоят такие прагмы:

PRAGMA secure_delete = ON
PRAGMA journal_mode = memory
PRAGMA journal_mode = delete
PRAGMA journal_mode = OFF
PRAGMA read_uncommitted = yes

В sqlite.dll есть подстрока
PRAGMA vacuum_db.synchronous=OFF

Думаю надо заменить
    PRAGMA journal_mode = OFF
на
    PRAGMA journal_mode = WAL

http://www.sqlite.org/draft/pragma.html#pragma_journal_mode

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.

(13) где заменить ?

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

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

(15) написал на [email protected] ?

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

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

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

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

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

https://partners.v8.1c.ru/forum/t/1312905/m/1313322

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

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

(25) возможно

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

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

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

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

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

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

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

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

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

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

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

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

(17) Сейчас попробую написать.

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

(30) Есть же версионирование как внешняя примочка? ВерсииОбъектов, ВерсионированиеОбъектов etc.

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

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

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

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

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

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

(17) Готово, ушло.

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

(2) >> когда же 1с сделает хранение ЖР в основной базе, а не отдельно от неё? Это же напрашивается просто!

Не моё мнение:

СУБД не совсем подходит для ведения журнала. Используя ее мы платим за то что не будем использовать. Это связано с особенностями нагрузки, которая характеризуется огромным и последовательным по времени трафиком на запись, минимальными изменениями данных и сильно разреженными выборками. (SQLite был выбран в качестве компромисса между субд (клиент-серверной) и хранениями в файлах. Кроме того для файлового варианта использование СУБД вообще чуждо.

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

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

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

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

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

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

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

(52) А у сервера много потоков исполнения может быть, там тоже конкуренция (хочется надеяться, что там она корректная и, так сказать, честная).

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

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

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

(53) Ставит то оно ставит, но насколько оно работает создатели не проверяют т.к. это изначально не сетевая, а встраиваемая база данных.
http://sqlite.1065341.n5.nabble.com/AGAIN-SQLite-on-network-share-td85552.html
Но согласен насчет WAL, только лучше перебить на это не одну, а все прагмы journal_mode.

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

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

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

(57) С блокировкой файла трудно ошибиться, но я подозреваю, что в 1С еще какая-нибудь Прагма отключает еще и это. :-)

(57) Там еще несколько опций, насколько я понимаю, WAL - это то, что делает MS-SQL со своей базой (гарантируя при этом безошибочный откат транзакций). И там компромисс между двукратной записью и полным отсутствием защиты. :-)

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

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

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

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

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

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

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

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

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

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

(59)
С чего бы это?
Никак это размер файла не ограничивает. Просто отображать будешь "скользящим окном".

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

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

Я сейчас подумал, что таким же путем можно вести вообще полный архив версий документов, при этом не будет зас..ния основной базы версиями.

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

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

(74) Видимо, быстрее всего писать лог в текст (при этом не выстраивается индекс и нет зависимости скорости записи от объема лога), а потом (например, ночью) его считывать второй БД, а текстовый лог обнулять или перемещать.

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

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

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

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

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

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

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

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

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

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

Ответ от 1С:
pragma journal_mode=wal приводит к частым непрогнозируемым зависаниям и деградации производительности на нагруженных базах или при достаточно большом периоде работы.

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

Для этого из каталога журнала регистрации следует перенести файлы 1Cv8.lgd, и создать пустой файл 1Cv8.lgf.

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

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

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

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

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

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

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

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

(91) 1 поток

(92) Там видимо надо поставить режим WAL и распараллелить потоки мьютексом (наверное сейчас долбятся повторами при ошибках SQLite).

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

(93) Не верю (с) Станиславский. Если два пользователя одновременно записывают документы, то как там один поток может быть?...

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

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

(96) а поиск?

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

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

Имхо, проблему можно решить и без 1С, если административно раз в сутки перезаводить текстовый ЖР, и конвертить прошлый в вид, удобный для анализа. Но при этом все штатные средства просмотра журнала пойдут лесом, а многих такой путь не устраивает, все хотят "vendor way".

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

(96) Глючит не сам WAL, а режим повторной записи без пауз, при помощи которого, очевидно, распараллеливают запись в журнал.

(99) Мьютекс же задерживает поток, у Рихтера это образно описано как кабинка туалета в самолете. :-) Ну да, выстраивает клиентов в очередь. :-)

(101)
Да нет там никакого режима повторной записи без пауз и распаралеливания записи в журнал. Сто раз уже писал - в sqlite базу нельзя писать параллельно, только один писатель в момент. И это сам sqlite отлично поддерживает.

(103) Он возвращает код ошибки, а 1С долбится пока не кончится ошибка.

(103) Я это и имею в виду. А чего там по коду происходит не посмотрите? А то у меня дизассемблера сейчас нету.

Т.е. что происходит когда SQLite возвращает ошибку. У нас есть типичная ошибка, когда серверный процесс 1С зависает и при этом все время растет лог.

Если там тяжело или нет времени то не надо, я уже в 1С написал свое предположение. Вот мой текст письма:

«Здравствуйте, уважаемые сотрудники фирмы 1С!

>В случае возникновения проблем мы рекомендуем использовать старый журнал регистрации.

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

>pragma journal_mode=wal приводит к частым непрогнозируемым зависаниям

Мы наблюдаем также проблему зависания серверных процессов, которая, скорее всего, связана с этой же проблемой (хотя pragma journal_mode=wal и отключен). Серверный процесс rmngr или rphost непрерывно пишет в лог, не снимается при остановке сервера и не отвечает (такие зависшие процессы надо прибивать вручную в диспетчере задач, при этом лог SQLite все время растет). Я могу предполагать (не проверял, но если надо, могу проверить), что попытки записи в базу данных логов не распараллелены и система «долбится» наподобие «дятла», ожидая блокировку, когда в базу SQLite пишет другой процесс или поток. «Частые непрогнозируемые зависания» - это, видимо, из-за того, что несколько «дятлов» (образное сравнение)-потоков подключаются к процессу «долбления», и проблема нарастает, как снежный ком. А если SQLite возвращает ошибку, но при этом все-таки выполняет саму запись в свою БД, то возникает то, что мы видим в процессе эксплуатации 1С:Предприятие.

Мое предложение – проверить, действительно ли не распараллелены транзакции записи в базу SQLite (это можно сделать при помощи нарастающего sleep, а также системных средств – мьютексов и семафоров, которые есть во всех операционных системах, включая Windows и Unix) и распараллелить их, а не обходиться только повторными попытками записи без пауз при возврате от SQLite кода ошибки. Там должны быть два вызова Mutex в начале и в конце транзакции – если их нет, то проблема «частых и неконтролируемых зависаний» – неизбежна именно здесь.

Переход на текстовый режим логов в нашем случае будет означать, что пропадут все наработки, которые уже сделаны для выгрузки логов в базу данных MS-SQL. Если мы будем ежедневно сбрасывать лог в базу MS-SQL и обнулять/очищать лог, то проблема pragma journal_mode=wal, (желательно, в сочетании, с мьютексом) скорее всего, не возникнет? Но зато решится проблема нестабильной работы 1С:Предприятие.

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

(107) и часто ты им такое пишешь? :)

(108) Да вроде вежливо всё. Или там я технически не прав где-то?

(109) Про свои предположения и всякие мьютексы писать необязательно. А про глюки сообщать конечно очень полезно.

(110) Ну там по коду легко посмотреть же, вдруг это оно. Иначе бы не было ошибки с зависанием rmngr и при этом непрерывной записью в лог.

(111) кто писал, тот пускай и разбирается. зачем давать советы, если ты точно не знаешь как оно работает. это неправильно и смешно.

мьютексы какие то. может там нету никаких мьютексов, а ты им про мьютексы...

(112) Писали много раз, предположение, что надо выключать журнал SQLite и включать старый текстовый журнал, ни у кого в 1С не возникло.

(113) Дятлы зато летают, поклев дятлами (если использовать мое образное сравнение) же налицо.

(112) Правильно конечно дизассемблировать. Я так и не разобрался с дизассемблерами, а надо бы за них засесть.

(115) замени sqlite.dll своей dll и сделай свою систему логов

(116) Кстати хорошая идея. Написать транслятор для другой субд например MSSQL

(117) поздно. после письма от romix в 1с уже наорали на индуса, который систему логов писал. в следующем релизе заработает нормально

(116) Лень, вдруг починят. Там же 3 строки заменить, и все будет пучком.

(117) Орефков выше предлагает писать в текст и собирать внешней прогой в SQL, думаю что так на нагруженной базе будет правильнее всего.

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

вообще лучше использовать версионирование. Свое или 1с или сторонних разработок.
А журнал регистраций оставить только для ошибок

(119) "Там же 3 строки заменить". Напиши в 1с и про три строки тоже.

(121) Да, там неопределенность, читать "3 строки (?)".

(120) Тут выше предлагали РБД. Но есть страх, что и там чего нибудь чебурахнется.