Имя: Пароль:
1C
1С v8
Работа с табелем рабочего времени в УПП ред. 1.3
0 Maritime
 
14.10.11
08:45
В организации установлена УПП, клиент-серверный вариант. СУБД: PostgreSQL 8.4.4, платформа 1С 8.2.13.219. Размер базы: 20 ГБ.
Когда работали в УПП ред. 1.2.38.1 (и более ранних) бухгалтер формировала, проводила и перепроводила (если надо было внести  изменения) табель рабочего времени на 160 строк с разбивкой по дням за месяц целиком.
Перешли на ред. УПП 1.3. И начиная с ред. 1.3.13.1 (сейчас уже обновились на ред. 1.3.16.1) такой же табель можно только создать и записать. А при проведении выходит ошибка:

Ошибка СУБД
ERROR: out of shared memory
HINT: You might need to increase max_locks_per_transactions.

И далее предложение закрыть или перезапустить 1С.
Теперь табель проводится объёмом только в 30 строк (что не очень удобно). При чём, если вдруг необходимо внести изменения, этот табель приходится распровести сначала, изменить и провести заново. Т.е. если изменения вносятся в проведённый документ и он ПЕРЕпроводится, выходит та же ошибка, указанная выше, и изменения НЕ сохраняются.

Перешли на платформу 1С 8.2.14.519: проблема осталась. Обновились до платформы 8.2.14.537 - ситуация не изменилась.
Для чистоты эксперимента (на обеих последних платформах поочереди), развернули две тестовые базы (выгрузка от одной даты, т.е. объём введённых данных одинаков) ред. 1.2.38.1 и обновлённую по ред. 1.3.16.1. На ред. 1.2.38.1 - табель на 160 строк проводится, в базе ред. 1.3.16.1 такой же табель при проведении выдатёт ошибку и база закрывается.
Нужна помощь, как можно решить эту проблему (кроме разбивки табеля на существенно меньшее количество строк).
1 smitru
 
14.10.11
08:47
(0) а может стоит всё же выполнить хинт:

HINT: You might need to increase max_locks_per_transactions.
2 Maritime
 
14.10.11
09:00
т.е. поправить настройки PostgreSQL?
Такой вариант протестировали, помогает (при увеличении значений некоторых параметров в postgresql.conf, благо железо сервера позволяет). Могу даже расписать попозже (вдруг кому-то пригодится). Но полазив по различным форумам и поискав в интернете, ощущение, что такая проблема только у нас :).
Но было интересно узнать мнение, может кто-то может подсказать, что такое глобальное в проведение табеля внесли 1с-вцы, из-за чего приходится увеличивать параметры производительности СУБД.
3 smitru
 
14.10.11
09:04
(2) max_locks_per_transactions - это такой же параметр как и сотня других предназначеных именно для "тонкой" поднастройки СУБД под конкретные задачи.. Так что тут подавать на БГ с Страсбург - вряд ли оправдано :-)

ЗЫ.. а у вас корпоративной культурой запрещено изменять дефолтные установки разных серверов?
4 Maritime
 
14.10.11
09:10
Нет, не запрещено. Придётся их менять в ближайшее время, потому что это единственное решение данной проблемы, которое у меня есть на данный момент.
Надеялась найти и узнать ещё какие-нибудь варианты.
5 smitru
 
14.10.11
09:20
(4) это самый простой и самый правильный путь, зачем искать иного типа "в Кацапетовку через Владивосток" :-)
6 Maritime
 
18.10.11
13:50
Проблему решили изменением параметра в настройках СУБД PostgreSQL, файл postgresql.conf:
max_connections = 250.

До этого этот параметр был 25 и при одновременной работе 17 пользователей в базе УПП ред. 1.2 этого хватало.