Резкое увеличение времени расчета себестоимости
Имеем базу УПП 1.3.132.2 на платформе 8.3.14.1630 (MS SQL)
Учет ведется партионный.
Расчет себестоимости за месяц занимает от 2 до 6 часов.
Месяц назад считал расчет себестоимости за октябрь, ноябрь, декабрь. По времени примерно 6 часов.
Пытаюсь сделать это сейчас, и расчет себестоимости делается 2 дня. Причем существенных изменений данных не было. Изменение настроек сервера тоже. Без пользовательской нагрузки на сервер.
Раньше когда я сталкивался с такой проблемой, я делал Тестирование и исправление информационной базы, и после этого скорость увеличивалась, но тогда речь шла об ускорении с 12 часов до 4-6 часов. Но потом это перестало помогать, как вдруг я обнаружил что выгрузка базы в dt и обратная его загрузка, приводит к рекордному увеличению скорости расчета до 2 часов.
Теперь проделав эти процедуры, я не получил никакого эффекта. Кэш очищал, очистил журнал регистрации никакого эффекта. Пробовал даже на другом сервере считать, видимо дело в базе. Думаю возможно это индексы, но со стороны MS SQL не знаю как там вообще что делается, но сисадмин говорит что вам все отлично, что индексы пересчитываются каждую ночь (прикладываю скрин плана обслуживания)
В чем может еще причина резкого увеличения скорости расчета себестоимости?
Учет ведется партионный.
Расчет себестоимости за месяц занимает от 2 до 6 часов.
Месяц назад считал расчет себестоимости за октябрь, ноябрь, декабрь. По времени примерно 6 часов.
Пытаюсь сделать это сейчас, и расчет себестоимости делается 2 дня. Причем существенных изменений данных не было. Изменение настроек сервера тоже. Без пользовательской нагрузки на сервер.
Раньше когда я сталкивался с такой проблемой, я делал Тестирование и исправление информационной базы, и после этого скорость увеличивалась, но тогда речь шла об ускорении с 12 часов до 4-6 часов. Но потом это перестало помогать, как вдруг я обнаружил что выгрузка базы в dt и обратная его загрузка, приводит к рекордному увеличению скорости расчета до 2 часов.
Теперь проделав эти процедуры, я не получил никакого эффекта. Кэш очищал, очистил журнал регистрации никакого эффекта. Пробовал даже на другом сервере считать, видимо дело в базе. Думаю возможно это индексы, но со стороны MS SQL не знаю как там вообще что делается, но сисадмин говорит что вам все отлично, что индексы пересчитываются каждую ночь (прикладываю скрин плана обслуживания)
В чем может еще причина резкого увеличения скорости расчета себестоимости?
Прикрепленные файлы:
По теме из базы знаний
Найденные решения
Постоянно есть подобная проблема у моего клиента. (УПП, база 180 Гб. MS SQL)
Какие-то индексы портятся и скорость перепроведения падает в разы (раз в 5-10). И чтобы месяц перепровести - за выходные нереально.
И реиндексация средствами СУБД - не помогает!
Вот как решили:
Делаем новую базу и разворачиваем туда бэкап. И получаем профиты:
1. Свежие, стройные индексы (ну и конечно снова хорошая скорость перепроведения);
2. Проверка резервной копии;
Какие-то индексы портятся и скорость перепроведения падает в разы (раз в 5-10). И чтобы месяц перепровести - за выходные нереально.
И реиндексация средствами СУБД - не помогает!
Вот как решили:
Делаем новую базу и разворачиваем туда бэкап. И получаем профиты:
1. Свежие, стройные индексы (ну и конечно снова хорошая скорость перепроведения);
2. Проверка резервной копии;
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)Насколько база большая? Я бы делал полное восстановление индексов, это заблокирует работу в базе, поэтому делать это надо ночью, когда никто не работает. Сделал бы обновление статистики - надо посмотреть сколько времени это занимает. Реорганизация индекса исправляет индексы, а полная реиндексация их заново создает. Еще имеет смысл очищать процедурный кэш запросом - создать такой план обслуживания. Вот все эти манипуляции надо сделать с отключенным планом, который на скриншоте и после этого смотреть что и как. Индексы каждую ночь пересчитывать не нужно - достаточно раз в неделю их полностью перестраивать. А вот обновление статистики надо делать почаще - опять же посмотреть перед этим, сколько времени занимает. Причина может быть в неоптимально плане запроса для SQL. Ну и как сами запросы написаны тоже большое значение имеет.
(1) было бы хорошо локализовать проблему: самое простое замерить конфигуратором что именно долго там выполняется. а далее если найдётся виновник. надо разбираться с ним. ещё можно попробовать DBCC FREEPROCCACHE сначала..у меня в базе есть запрос который раз в месяц по неизвестной причине начинает выполнятся дольше чем обычное. очистка процедурного кэша помогает..
(2) сверка базы не устраивает руководство. Нужны движения по периодам для анализа. Но как вариант я начал рассматривать свертку по паре регистров, таких как "Затраты на выпуск Бухгалтерский учет", потому этот регистр чаще всего пишется при расчете себестоимости и это по размеру самая большая таблица базы
(6) Оно хоть и стоя но итерационный расчет вносил по несколько записей по одним и тем же измерениям. Сворачивание не происходило. Сделав вручную, уменьшив объем регистра раз в 5 без потери каких либо данных. Насчет плана запросов я уже и не вспомню как сделал правильно (это было года два назад) но ситуация была аналогичная: расчет себестоимости из 6 часов резко вырос до 2-х дней. Долго покопав, обнаружил что выборка из таблицы идет не по индексам (я их даже перестроил). Толи как-то очистил план запросов чтобы оно создало новый правильный, толи вручную сделал запрос и оно его пересоздало.
(7) Ерунду какую-то написали. Вы предлагаете мне переписать весь типовой код расчета себестоимости? Вы представляете вообще какие это объемы?
Вопрос даже в другом: что произошло с базой/сервером, что один и тот же расчет себестоимости на одних и тех же данных считается намного дольше?
Вопрос даже в другом: что произошло с базой/сервером, что один и тот же расчет себестоимости на одних и тех же данных считается намного дольше?
Если бы не представлял не писал. Обычно дополнительные проверки делаются в проц перед записью документов. Можно сделать отказ от проверок при вычислении себестоимости в одной подписке сразу для всех документов. Если в разных базах одни и те же данные но расчет ведется с разной скоростью сверьте в базах администрирование\ общие настройки\настройки хранения может быть в процессе восстановления последовательности перезаписывается много копий. Сверьте запущенные регламентные задания в обеих базах. Можно посмотреть длительность процедур при запущенном расчете себестоимости.
Сверьте конфигурации обеих баз. Сверьте в базах учетную политику
Сверьте конфигурации обеих баз. Сверьте в базах учетную политику
(13) Цитата Вашего сообщения от 11.02.20 14:26 "Вопрос даже в другом: что произошло с базой/сервером, что один и тот же расчет себестоимости на одних и тех же данных считается намного дольше?"
Один и тот же расчет себестоимости считается у Вас намного дольше, но Ваша цитата от 11.02.20 15:41"я наоборот написал что с одной скоростью"?
Один и тот же расчет себестоимости считается у Вас намного дольше, но Ваша цитата от 11.02.20 15:41"я наоборот написал что с одной скоростью"?
Постоянно есть подобная проблема у моего клиента. (УПП, база 180 Гб. MS SQL)
Какие-то индексы портятся и скорость перепроведения падает в разы (раз в 5-10). И чтобы месяц перепровести - за выходные нереально.
И реиндексация средствами СУБД - не помогает!
Вот как решили:
Делаем новую базу и разворачиваем туда бэкап. И получаем профиты:
1. Свежие, стройные индексы (ну и конечно снова хорошая скорость перепроведения);
2. Проверка резервной копии;
Какие-то индексы портятся и скорость перепроведения падает в разы (раз в 5-10). И чтобы месяц перепровести - за выходные нереально.
И реиндексация средствами СУБД - не помогает!
Вот как решили:
Делаем новую базу и разворачиваем туда бэкап. И получаем профиты:
1. Свежие, стройные индексы (ну и конечно снова хорошая скорость перепроведения);
2. Проверка резервной копии;
(12) вы не поверите но сегодня утром я сделал новую базу, и грузанул туда базу из dt. вот на всякий случай решил ТИИ провести, и потом проверить Расчет себестоимости. Если вы правы, то в принципе сейчас должна быть хорошая скорость, я скоро об этом узнаю.
Но если это правда, это сразу же порождает кучу вопросов, почему реиндексации СУБД не работает, реиндексация во время ТИИ не работает, в чем вообще причина.
Пересоздавать базу конечно если это работает это хорошо, но все таки это костыль
Но если это правда, это сразу же порождает кучу вопросов, почему реиндексации СУБД не работает, реиндексация во время ТИИ не работает, в чем вообще причина.
Пересоздавать базу конечно если это работает это хорошо, но все таки это костыль
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот