УТ 11 Последняя полностью типовая
Postgresql
Организация занимается оптовой продажей сигарет.
Вопрос такой почему тестирование и исправление базы занимает больше 6 дней.
Больше всего времени тратит на проверку логической целостности Штрихкодов и упаковок.
Доброго! А что по размерам таблиц?
Встречал я разные глюки с Постгре.
У нас доходило до того, что файловая копия базы в некоторых моментах до 20 раз быстрее работала, чем ее серверная копия на постгре.
Но тут у нас просто админы не могли нормально настроить
Базу на ССД или еще лучше в рам-диск!
В рам диске попробуйте выполнить эту противоречивую операцию =)
Выгрузить в ДТ, создать чистую базу и загрузить из ДТ-шника я так понимаю уже пробовали?
(4)
База на ссд, в раме таже история, выгрузить и загрузить в чистую таже история.
Я даже больше скажу это не единственная база такая есть еще похожие и все связаны с сигаретами и вся проблема в справочнике ШтрихкодыУпаковокТоваров
(20)сколько записей в таблице? при проверке ссылочной целостности проверяются все остальные объекты, использующие записи проверяемой таблицы по ссылкам
Да похоже так и есть, либо с обновлением что нибудь поправят в УТ с хранением такого типа данных. Я думаю проблема не только у меня а у всех кто работает с сигаретами
(22) Там по факту 3 таблицы:
Справочник.ШтрихкодыУпаковокТоваров, Имя таблицы хранения: Reference23920
Справочник.ШтрихкодыУпаковокТоваров.ВложенныеТовары, Имя таблицы хранения: Reference23920.VT24136, Назначение: ТабличнаяЧасть
Справочник.ШтрихкодыУпаковокТоваров.ВложенныеШтрихкоды, Имя таблицы хранения: Reference23920.VT24144, Назначение: ТабличнаяЧасть
Но у второй "ВложенныеШтрихкоды" вроде нет ссылочных элементов.
Такой запрос сможешь в консоли выполнить?
Выбрать
Сумма(1) КАК Шапки,
0 КАК Линии
из Справочник.ШтрихкодыУпаковокТоваров
объединить все
выбрать
0,
Сумма(1)
из Справочник.ШтрихкодыУпаковокТоваров.ВложенныеТовары
(28)
При вычислении количества записей на языке запросов следует всегда использовать функцию КОЛИЧЕСТВО, а не СУММА. В противном случае, при количестве записей 10 млн. и более произойдет переполнение, что связано с разрядностью числа по умолчанию (7 разрядов), используемого в СУБД платформой 1С:Предприятие.
Неправильно:
СУММА(1)
ЕСТЬNULL(СУММА(1), 0)
Правильно:
КОЛИЧЕСТВО(*)
КОЛИЧЕСТВО(<Поле>)
При вычислении количества записей на языке запросов следует всегда использовать функцию КОЛИЧЕСТВО, а не СУММА. В противном случае, при количестве записей 10 млн. и более произойдет переполнение, что связано с разрядностью числа по умолчанию (7 разрядов), используемого в СУБД платформой 1С:Предприятие.
А источник не можете указать? Просто интересно почитать.
Выбрать
Сумма(1) КАК Шапки,
0 КАК Линии
из Справочник.ШтрихкодыУпаковокТоваров
объединить все
выбрать
0,Сумма(1)
из Справочник.ШтрихкодыУпаковокТоваров.ВложенныеШтрихкоды
(43)
Проблема в медлительности именно в этих 2 галочках.
Если сделать отдельно только с первой галочкой(Проверка логической целостности), то тест проходит быстро.
Проблема изза второй галочки (проверка ссылочной целостности)
(57)
По ссылке выгрузка загрузка не решает проблемы, сейчас проверяю на mssql сервере есть ли разница , достаточно 20 процентов прохождения чтоб подсчитать разницу. Жду)
Надо указывать версию потсгреса, судя по тому что jit = on то это 12 postgres и выше, его кстати лучше в off установить.
from_collapse_limit = 8
join_collapse_limit = 6
max_connections хватит 350 с головой, temp buffers вернуть по умолчанию 8 MB под виндой чем больше значение тем меньше скорость работы с временными таблицами.
row_security = off
synchronous_commit = off
Ну и я надеюсь 1с и постгрес добавлен в исключения как для встроенного антивируса так и для стороннего если он есть. И стоп старт службы постгреса, после изменений конфига, не забываем делать.
Разница не заметна после этих настроек. Также продолжает долго проверять логическу целостность ШтрихкодыУпаковокТоваров.
Где то 20% проверки за 12 часов.
Спецом даже проц разогнал на 5.1Ггц думаю скорости не увижу.
А там еще есть долгая проверка уже реализаций.
Вот и выходит тестирование где то с неделю. И с каждым месяцем работы в базе думаю будет еще дольше.