Не пересчитываются итоги

1. tonn12 31 10.02.19 21:19 Сейчас в теме
Приветствую.
Убирали дату расчетов итогов для проведения работ (требования подрядчика), работы полностью выполнить подрядчику не удалось и при ближайшем закрытии месяца обнаружились неточности в БУ и НУ. Проанализировав цифры, выяснил что минуса идут от 28.02.0001 г. Начал двигать итоги к нужному месяцу, вопрос удалось решить. Но сейчас при закрытии года выяснилось что на февраль очень большой минус. Начали опять двигать итоги, но ни чего не получалось. Пробовали сбрасывать дату до 01.01.0001, но в итоги сейчас итоги считаются до 31.12.2016 г. и дальше не идут, что я только не делал дата не двигается. В администрировании серверов постоянно растет число в столбце "Захвачено СУБД". Ждали по несколько суток с остановкой работ в центральной базе, но толку ни какого. Что может будь не так? Почему не двигается дата итогов?
Данная проблема не может решится уже около двух недель.
По теме из базы знаний
Найденные решения
10. tonn12 31 13.03.19 10:33 Сейчас в теме
Устранили мы свою проблему. Использовали два метода, но скорей всего надо было всего лишь второй метод и все решилось бы.
Решение:
1. После того как перепробовали все варианты по пересчету итогов решили обратится за помощью к сторонним спецам (от безысходности). Первый, так же как и мы, ни чего не смог сделать. У второго человека все получилось, но был нюанс, он производил работы на другом SQL сервере. Это нас натолкнуло на мысль попробовать боевую базу (он выполнял работы на копии восстановленной из последнего бэкапа) перенести на другой SQL сервер. Т.к. база и лог располагались на подмапленных дисках, то переподключение их не составило особого труда. И случилось чудо, регистр бухгалтерии хозрасчетный пересчитался без каких либо проблем, но у нас был второй регистр с такой же проблемой, налоговый, с ним такой фокус не прошел и тут нам помог второй случай.
2. Внешний спец подкидывал идей что и как надо сделать для решения проблемы, но ни чего не помогало. Взяв ту же копию базы где работал второй спец я начал анализировать технологический журнал, из него выяснил что после пересчета декабря процесс просто зависал, точнее не продолжался, складывалось ощущение что он уходил в ожидание. Начал смотреть profiler, там картина аналогичная, запрос просто не продолжался. Через запрос
Sel ect * Fr om master.dbo.sysprocesses
я узнал что наш процесс висит с ожиданием SOS_SCHEDULER_YIELD. Данный тип ожидания означает что процесс ждет освобождение ресурсов ЦП. Через диспетчер задач увидел что количество потоков на ЦП увеличивается, не быстро, рабочая 1С в это время работала штатно, обмены ходили, пользователи выполняли свою рутинную работу и не жаловался. Начал гуглить решение по устранению этого типа ожидания и в итоге на одном из форумов по SQL человек описывал ситуацию где у него код, который несколько дней назад выполнялся за приемлемое время, вдруг перестал выполнятся вообще и начал уходить в ожидание SOS_SCHEDULER_YIELD. Ему там посоветовали сделать полное обновление статистики, что я и сделал на своей базу при помощи запроса
exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
. Полное обновление статистики на копии выполнялось 12 часов, на боевой 15, но проблему это устранило, регистр бухгалтерии налоговый пересчитался без проблем.

Что бы сразу отвести обвинения и упреки что базу надо обслуживать и настраивать регламентные задания, то все это настроено и обновление статистики происходит каждый день, только из за объема базы мы используем обновление не полное а выборочное.
Остальные ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. alxarz 31 10.02.19 21:43 Сейчас в теме
(1)
что я только не делал дата не двигается.
и выгрузку/загрузку?
3. tonn12 31 10.02.19 22:15 Сейчас в теме
(2)Выгрузка/загрузка куда? В DT? Я извиняюсь, не указал объем базы - 1,8 Тб.
4. alxarz 31 10.02.19 22:28 Сейчас в теме
(3) дата не двигается вообще для всех регистров или для отдельных/некоторых?
5. tonn12 31 10.02.19 22:54 Сейчас в теме
(4)налог и хозрасчетный
6. alxarz 31 11.02.19 00:10 Сейчас в теме
7. tonn12 31 11.02.19 01:07 Сейчас в теме
8. f_fobos 11.02.19 08:51 Сейчас в теме
"что я только не делал" - спрошу на всякий случай, в конфигураторе реиндексацию таблиц и пересчет итогов делали?
9. tonn12 31 11.02.19 10:45 Сейчас в теме
(8)Стандартным методом пересчет итогов не делали, использовали обработки. Пытались ускорить процесс пересчета, но кажется надо будет использовать именно стандартный метод.
Для наглядности вот что сейчас с итогами:
10. tonn12 31 13.03.19 10:33 Сейчас в теме
Устранили мы свою проблему. Использовали два метода, но скорей всего надо было всего лишь второй метод и все решилось бы.
Решение:
1. После того как перепробовали все варианты по пересчету итогов решили обратится за помощью к сторонним спецам (от безысходности). Первый, так же как и мы, ни чего не смог сделать. У второго человека все получилось, но был нюанс, он производил работы на другом SQL сервере. Это нас натолкнуло на мысль попробовать боевую базу (он выполнял работы на копии восстановленной из последнего бэкапа) перенести на другой SQL сервер. Т.к. база и лог располагались на подмапленных дисках, то переподключение их не составило особого труда. И случилось чудо, регистр бухгалтерии хозрасчетный пересчитался без каких либо проблем, но у нас был второй регистр с такой же проблемой, налоговый, с ним такой фокус не прошел и тут нам помог второй случай.
2. Внешний спец подкидывал идей что и как надо сделать для решения проблемы, но ни чего не помогало. Взяв ту же копию базы где работал второй спец я начал анализировать технологический журнал, из него выяснил что после пересчета декабря процесс просто зависал, точнее не продолжался, складывалось ощущение что он уходил в ожидание. Начал смотреть profiler, там картина аналогичная, запрос просто не продолжался. Через запрос
Sel ect * Fr om master.dbo.sysprocesses
я узнал что наш процесс висит с ожиданием SOS_SCHEDULER_YIELD. Данный тип ожидания означает что процесс ждет освобождение ресурсов ЦП. Через диспетчер задач увидел что количество потоков на ЦП увеличивается, не быстро, рабочая 1С в это время работала штатно, обмены ходили, пользователи выполняли свою рутинную работу и не жаловался. Начал гуглить решение по устранению этого типа ожидания и в итоге на одном из форумов по SQL человек описывал ситуацию где у него код, который несколько дней назад выполнялся за приемлемое время, вдруг перестал выполнятся вообще и начал уходить в ожидание SOS_SCHEDULER_YIELD. Ему там посоветовали сделать полное обновление статистики, что я и сделал на своей базу при помощи запроса
exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
. Полное обновление статистики на копии выполнялось 12 часов, на боевой 15, но проблему это устранило, регистр бухгалтерии налоговый пересчитался без проблем.

Что бы сразу отвести обвинения и упреки что базу надо обслуживать и настраивать регламентные задания, то все это настроено и обновление статистики происходит каждый день, только из за объема базы мы используем обновление не полное а выборочное.
11. brunan-g 22.06.20 17:28 Сейчас в теме
Считаю своим долгом опубликовать удачное решение. Оно базировалось на текущем материале.

Проблема: в БП 3.0 есть свой дописанный регистр бухгалтерии "Бюджетный" с 5 субконто. Он перестал пересчитываться на 1.06.2020. Виснет и ничего не происходит, можно ждать сутки или двое... База размером 400 Гб.

Решение:
1. Получил список таблиц, обслуживающих регистры, в терминах 1С
Код:

&НаСервере
Процедура СформироватьНаСервере()
	МассивОбъектов = Новый Массив;
	МассивОбъектов.Добавить("РегистрБухгалтерии.Бюджетный");
	ТаблицаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных(МассивОбъектов,Истина);
КонецПроцедуры




2. Получил таблицу ТаблицаСтруктуры с именами (у вас будет своя):

Назначение	Метаданные	ИмяТаблицы	ИмяТаблицыХранения
"НастройкиХраненияИтоговРегистраБухгалтерии"	"РегистрБухгалтерии.Бюджетный"	""	"_AccRgOpt16447"
"Основная"	"РегистрБухгалтерии.Бюджетный"	"РегистрБухгалтерии.Бюджетный"	"_AccRg16395"
"ИтогиПоСчетам"	"РегистрБухгалтерии.Бюджетный"	""	"_AccRgAT016421"
"ИтогиПоСчетамССубконто1"	"РегистрБухгалтерии.Бюджетный"	""	"_AccRgAT116440"
"ИтогиПоСчетамССубконто2"	"РегистрБухгалтерии.Бюджетный"	""	"_AccRgAT216441"
"ИтогиПоСчетамССубконто3"	"РегистрБухгалтерии.Бюджетный"	""	"_AccRgAT316442"
"ИтогиПоСчетамССубконто4"	"РегистрБухгалтерии.Бюджетный"	""	"_AccRgAT416443"
"ИтогиПоСчетамССубконто5"	"РегистрБухгалтерии.Бюджетный"	""	"_AccRgAT516444"
"ИтогиМеждуСчетами"	"РегистрБухгалтерии.Бюджетный"	""	"_AccRgCT16445"
"ЗначенияСубконто"	"РегистрБухгалтерии.Бюджетный"	"РегистрБухгалтерии.Бюджетный.Субконто"	"_AccRgED16446"
Показать



3. Статистику я проапдейтил не всю, а только по этим таблицам:

UPDATE STATISTICS _AccRgOpt16447
UPDATE STATISTICS _AccRg16395
UPDATE STATISTICS _AccRgAT016421
UPDATE STATISTICS _AccRgAT116440
UPDATE STATISTICS _AccRgAT216441
UPDATE STATISTICS _AccRgAT316442
UPDATE STATISTICS _AccRgAT416443
UPDATE STATISTICS _AccRgAT516444
UPDATE STATISTICS _AccRgCT16445
UPDATE STATISTICS _AccRgED16446

Времени ушло менее 10 минут!
Еще раз обращаю внимание - получите таблицу со своими именами, они будут отличаться! Мой регистр самописный, этих имен в стандартных конфигурациях нет!


4. ???
5. Перенос итогов пошел, причем очень шустро. Проверил выборочно различные отчеты - все работает, как метеор.

Конец.
sevarm; kotlovD; +2 Ответить
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот