БП 2.0 . Закрытие месяца выполняется неоправданно долго (несколько часов) на MSSQL
Дано:
Организация с довольно большим объемом операций по производству.
Закрытие месяца выполняется с каждым месяцем все дольше.
Период рассчитанных итогов меняем. Переиндексацию базы производим. Различные версии MSSQL пробуем (2005/2008/2008R2). Не помогает или помогает на 1 закрытие, потом опять медленно.
В файловом варианте закрытие работает приемлимо, но этот вариант не подходит - повседневная работа встанет (около 20 одновременных пользователей), да и объем скоро перейдет границы допустимого.
В вариант PostgreSQL закрытие работает хорошо, но в "боевых" условиях работа обычных пользователей не тестировалась.
В тестовой базе на PostgreSQL поймали пока только один баг - при дефолтных настройках обмен данными приводит к ошибке типа "слишком много блокировок".
Вопросы:
- встречалось ли у кого-нибудь подобное поведение закрытия месяца?
- есть ли примеры промышленного применения БП 2.0 под управлением PostgreSQL, какие есть нюансы и какие впечатления?
Спасибо.
Организация с довольно большим объемом операций по производству.
Закрытие месяца выполняется с каждым месяцем все дольше.
Период рассчитанных итогов меняем. Переиндексацию базы производим. Различные версии MSSQL пробуем (2005/2008/2008R2). Не помогает или помогает на 1 закрытие, потом опять медленно.
В файловом варианте закрытие работает приемлимо, но этот вариант не подходит - повседневная работа встанет (около 20 одновременных пользователей), да и объем скоро перейдет границы допустимого.
В вариант PostgreSQL закрытие работает хорошо, но в "боевых" условиях работа обычных пользователей не тестировалась.
В тестовой базе на PostgreSQL поймали пока только один баг - при дефолтных настройках обмен данными приводит к ошибке типа "слишком много блокировок".
Вопросы:
- встречалось ли у кого-нибудь подобное поведение закрытия месяца?
- есть ли примеры промышленного применения БП 2.0 под управлением PostgreSQL, какие есть нюансы и какие впечатления?
Спасибо.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) ufedor,
Была аналогичная проблема.
Перенесли бухгалтерию на PostgreSQL. Стали появляться ошибки, в частности в Общем модуле "Налоговый учёт УСН" - процедуры "СписаниеРасходовУСН" и "ОбработатьТаблицуФильтров". Лечится это довольно быстро, но дальше экспериментировать не стали. Перешли на MS SQL. Каждую ночь выполняется регламент (Резервное копирование, Обновление статистики, Реорганизация индекса, Восстановление индекса). Пока проблем с производительностью не обнаружено.
Была аналогичная проблема.
Перенесли бухгалтерию на PostgreSQL. Стали появляться ошибки, в частности в Общем модуле "Налоговый учёт УСН" - процедуры "СписаниеРасходовУСН" и "ОбработатьТаблицуФильтров". Лечится это довольно быстро, но дальше экспериментировать не стали. Перешли на MS SQL. Каждую ночь выполняется регламент (Резервное копирование, Обновление статистики, Реорганизация индекса, Восстановление индекса). Пока проблем с производительностью не обнаружено.
(4) Интересненько.
Ошибки какого плана?
Решаемые на уровне настроек СУБД (такие как количество блокировок) или связанные с особенностями работы механизма запросов например, требующие обновления конфигурации?
Регламенты выполнять не проблема, но особенность работы именно нашей бухгалтерии в том, что иногда за день может проводиться несколько попыток (итераций) одного из этапов закрытия месяца.
ЗЫ УСН это конечно не про нас...
Ошибки какого плана?
Решаемые на уровне настроек СУБД (такие как количество блокировок) или связанные с особенностями работы механизма запросов например, требующие обновления конфигурации?
Регламенты выполнять не проблема, но особенность работы именно нашей бухгалтерии в том, что иногда за день может проводиться несколько попыток (итераций) одного из этапов закрытия месяца.
ЗЫ УСН это конечно не про нас...
(5) ufedor,
Ошибки, связанные с запросами. Приходилось вносить изменения в код. Изменения хоть и не значительные, но лишний раз ковырять конфигурацию желания нет (опять же не охота усложнять себе жизнь при обновлении).
У нас в базе порядка 14 юр.лиц, несколько организаций на УСН. Первые "неудобства" заметили пользователи именно этих организаций. Дальнейших детальных обследований не проводилось.
Ошибки, связанные с запросами. Приходилось вносить изменения в код. Изменения хоть и не значительные, но лишний раз ковырять конфигурацию желания нет (опять же не охота усложнять себе жизнь при обновлении).
У нас в базе порядка 14 юр.лиц, несколько организаций на УСН. Первые "неудобства" заметили пользователи именно этих организаций. Дальнейших детальных обследований не проводилось.
PostgreSQL позиционируется как _лучшая_ бесплатная СУБД.
А что вы понимаете под "нормальной"? Экспресс версии DB2 и Oracle?
Спасибо, нет. А на полновесную еще не факт что раскошелятся.
Только представьте, перевод на Oracle одной бухгалтерии явно не имеет смысла, а перевод всей системы выльется в приличные затраты, и временные, и денежные. Это же еще и специалистов надо переучивать (видимо) которые занимаются поддержкой СУБД...
Реальные предложения есть?
А что вы понимаете под "нормальной"? Экспресс версии DB2 и Oracle?
Спасибо, нет. А на полновесную еще не факт что раскошелятся.
Только представьте, перевод на Oracle одной бухгалтерии явно не имеет смысла, а перевод всей системы выльется в приличные затраты, и временные, и денежные. Это же еще и специалистов надо переучивать (видимо) которые занимаются поддержкой СУБД...
Реальные предложения есть?
Хорошо, давайте поднимем :)
Конечно, замерял. При "подвисании" заметная загрузка процессора только на SQL, клиент и сервер 1С почти ничего не потребляют. Могу даже указать какой запрос выполняется дольше всего:
Конечно, замерял. При "подвисании" заметная загрузка процессора только на SQL, клиент и сервер 1С почти ничего не потребляют. Могу даже указать какой запрос выполняется дольше всего:
ОбщийМодуль.КорректировкаСтоимости.Модуль 844 Таб = Запрос.Выполнить().Выгрузить(); 92,81%
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот