И становится невозможным повторное подключение к базе. Как это можно лечить, есил это как-то лечится?

Посмотреть размер журнала и его тип.

(1) 2.5 гб и .lgd (SQL-LITE)

Журнал в sqlite?
Так сами себе дендроидные андромутанты...

(0) Использовать старый формат ЖР.

(3) Это скорее разработчики, которые вместо нормальной СУБД взяли нечто, не обеспечивающее нормальной многопользовательской работы.

(5) Ага. Те, кто устанавливал 1с и не подумал задать формат журнала

Ну 2.5 Гб это немного. СТранно, но попробуйте старый формат.

Скл лайт ущербный формат. Даже 1с от него отказалась сделав индексы для старого формата

(8) склайт - нормальный формат. Просто использован не по назначению

Ущербный для хайлоада

(10) "Просто использован не по назначению" (с) Я, безмерно любимый и недокопаемо мудрый.

(6) Что тот, что другой - тормозят. Только один еще и блокирует запись. Что мешало добавить настройки для базы ЖР на любом поддерживаемом SQL (MS SQL, PostgreSQL и т.д.)? Это, как минимум, не сложнее встраивания SQLite. Зато никаких проблем с масштабированием.

(12) Чтобы ЖР не входил в состав архива.

(13) Что мешает не архивировать эту отдельно лежащую базу?

(10) Не для хайлоада, а для чтения. Для записи он лучше текстового.

Как раз только завершил "минипроект" по перегрузу данных из SQLite в отдельную базу 1С на MSSQL. При больших объемах данных в ЖР наверное никакой формат не поможет. SQLite блокируется на запись, пока не выдаст нужные данные (да и читает как-то странно - любым вьювером делаешь запрос и быстрее выводится чем платформой 1С). Текстовый формат - если большой период выборки и данные разделяются на файлы по периодам (по дням, например), то при чтении сервер 1С генерит много фоновых заданий для выборки информации из текстовых файликов (в идеале - 1 ФЗ на файл), а такое кол-во соединений не всякий сервер потянет. Возможно сильный рост ЖР можно сдержать, настроив регистрацию только ошибок и предупреждений.
У нас файл lgd за полгода разросся на +100Г. 80% информации в нем были события транзакций (Begin, Commit, Rollback) - их просто не стали тащить в базу MSSQL.

(4) + 100500

(16) Если уж в 1с решили использовать СУБД в качестве хранилища для ЖР, лучше было бы использовать не блокировочник, а версионник. Тот же firebird имеет встраиваемую версию. А он позволяет писать без блокировок при чтении.

(15) Дичь. Для записи лучше текстовый.

(16) "(да и читает как-то странно - любым вьювером делаешь запрос и быстрее выводится чем платформой 1С)"

Ну поди такие же фишечки, как и в MSSQL с его Enterprise Manager

(18) Платформа 1С пока еще не умеет с firebird, а делали не только хранилище, но и отчеты по данным, и поиски в динамическом списке, и регл.задания там же по закачке/обрезке ЖР пакетной. А еще и некоторое из БСП прикрутили.

(19) Значит наоборот, для чтения лучше. Короче в какую-то сторону перекос (по сравнению с текстовым).

Стандартный подход к логированию - локальный лог писать в текст с разбитием на файлы по периодам. Просто. Быстро. Надежно. Удобно сопровождать. А при необходимости тяжелых агрегаций и быстрых выборок - перевыгружать в что-то большое и умное. Типа того же сиквела.
А в 1С в чью-то "светлую" голову пришла идея скрестить ежа и ужа (я про скулайт).

(0) не используйте ЖР в пользовательском режиме, там тупит не сам ЖР а то как его на форму затащили...

откройте его из конфигуратора...


новый формат куда лучше чем старый, у меня 40 гигов на старом формате вешал сервак а на новом все нормально (относительно)

(24) А расскажи нам, в конфигураторе наложить отбор на ЖР...

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

(25) по представлению

(27) Ну просто офигеть....

(28) там отдельная колонка есть :)

а вообще ЖР для отбора по объекту нафиг не нужен, для этого есть версионирование... оно куда лучше и быстрее работает...

а ЖР - это для остального...

по большому счету ЖР - исключительно для программистов, и нефиг туда юзеров пускать вообще...

(5) (12) Какой бы ни был формат, но зависать У ВСЕХ не должно. Это однозначно чьи-то кривые руки.

(30) у всех зависает когда журнал выжрет всю память сервера и 1с очутится в свопе

(31) Сам журнал или таки выборка из него?

(21) Ну так когда-то она и sqlite не умела. В любом случае поддержку способа доступа к ЖР нужно было как-то реализовать. Могли реализовать неблокируемый доступ, но выбрали убогий sqlite, задача которого в 99% случаев сводится к хранению локальных настроек приложений.

(31) В случае SQLite у всех зависает на время выборки из ЖР. А если вдруг ты не попал в индекс - это означает полное чтение всего файла ЖР, который может десятки Гб быть. Причем выше 30-50 Мб/с он не читает, т.к. упирается в 1 поток ЦП.

(27) По представлению и в пользовательском режиме шустро работает.