|
Работа с табелем рабочего времени в УПП ред. 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 этого хватало. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |