Приветствую.
Убирали дату расчетов итогов для проведения работ (требования подрядчика), работы полностью выполнить подрядчику не удалось и при ближайшем закрытии месяца обнаружились неточности в БУ и НУ. Проанализировав цифры, выяснил что минуса идут от 28.02.0001 г. Начал двигать итоги к нужному месяцу, вопрос удалось решить. Но сейчас при закрытии года выяснилось что на февраль очень большой минус. Начали опять двигать итоги, но ни чего не получалось. Пробовали сбрасывать дату до 01.01.0001, но в итоги сейчас итоги считаются до 31.12.2016 г. и дальше не идут, что я только не делал дата не двигается. В администрировании серверов постоянно растет число в столбце "Захвачено СУБД". Ждали по несколько суток с остановкой работ в центральной базе, но толку ни какого. Что может будь не так? Почему не двигается дата итогов?
Данная проблема не может решится уже около двух недель.
Убирали дату расчетов итогов для проведения работ (требования подрядчика), работы полностью выполнить подрядчику не удалось и при ближайшем закрытии месяца обнаружились неточности в БУ и НУ. Проанализировав цифры, выяснил что минуса идут от 28.02.0001 г. Начал двигать итоги к нужному месяцу, вопрос удалось решить. Но сейчас при закрытии года выяснилось что на февраль очень большой минус. Начали опять двигать итоги, но ни чего не получалось. Пробовали сбрасывать дату до 01.01.0001, но в итоги сейчас итоги считаются до 31.12.2016 г. и дальше не идут, что я только не делал дата не двигается. В администрировании серверов постоянно растет число в столбце "Захвачено СУБД". Ждали по несколько суток с остановкой работ в центральной базе, но толку ни какого. Что может будь не так? Почему не двигается дата итогов?
Данная проблема не может решится уже около двух недель.
По теме из базы знаний
- Статья из цикла «Личный опыт» «Устранение ошибок выгрузки, загрузки конфигураций в 1С: Предприятие 7.7»
- Работа с итогами регистров
- Устранение расхождений между регистрами РАУЗ (регл) и регистрами учета ТМЦ, НЗП в УПП 1.3 и КА 1.1
- Почему Вы не обслуживаете итоги?
- Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами
Найденные решения
Устранили мы свою проблему. Использовали два метода, но скорей всего надо было всего лишь второй метод и все решилось бы.
Решение:
1. После того как перепробовали все варианты по пересчету итогов решили обратится за помощью к сторонним спецам (от безысходности). Первый, так же как и мы, ни чего не смог сделать. У второго человека все получилось, но был нюанс, он производил работы на другом SQL сервере. Это нас натолкнуло на мысль попробовать боевую базу (он выполнял работы на копии восстановленной из последнего бэкапа) перенести на другой SQL сервер. Т.к. база и лог располагались на подмапленных дисках, то переподключение их не составило особого труда. И случилось чудо, регистр бухгалтерии хозрасчетный пересчитался без каких либо проблем, но у нас был второй регистр с такой же проблемой, налоговый, с ним такой фокус не прошел и тут нам помог второй случай.
2. Внешний спец подкидывал идей что и как надо сделать для решения проблемы, но ни чего не помогало. Взяв ту же копию базы где работал второй спец я начал анализировать технологический журнал, из него выяснил что после пересчета декабря процесс просто зависал, точнее не продолжался, складывалось ощущение что он уходил в ожидание. Начал смотреть profiler, там картина аналогичная, запрос просто не продолжался. Через запрос я узнал что наш процесс висит с ожиданием SOS_SCHEDULER_YIELD. Данный тип ожидания означает что процесс ждет освобождение ресурсов ЦП. Через диспетчер задач увидел что количество потоков на ЦП увеличивается, не быстро, рабочая 1С в это время работала штатно, обмены ходили, пользователи выполняли свою рутинную работу и не жаловался. Начал гуглить решение по устранению этого типа ожидания и в итоге на одном из форумов по SQL человек описывал ситуацию где у него код, который несколько дней назад выполнялся за приемлемое время, вдруг перестал выполнятся вообще и начал уходить в ожидание SOS_SCHEDULER_YIELD. Ему там посоветовали сделать полное обновление статистики, что я и сделал на своей базу при помощи запроса . Полное обновление статистики на копии выполнялось 12 часов, на боевой 15, но проблему это устранило, регистр бухгалтерии налоговый пересчитался без проблем.
Что бы сразу отвести обвинения и упреки что базу надо обслуживать и настраивать регламентные задания, то все это настроено и обновление статистики происходит каждый день, только из за объема базы мы используем обновление не полное а выборочное.
Решение:
1. После того как перепробовали все варианты по пересчету итогов решили обратится за помощью к сторонним спецам (от безысходности). Первый, так же как и мы, ни чего не смог сделать. У второго человека все получилось, но был нюанс, он производил работы на другом SQL сервере. Это нас натолкнуло на мысль попробовать боевую базу (он выполнял работы на копии восстановленной из последнего бэкапа) перенести на другой SQL сервер. Т.к. база и лог располагались на подмапленных дисках, то переподключение их не составило особого труда. И случилось чудо, регистр бухгалтерии хозрасчетный пересчитался без каких либо проблем, но у нас был второй регистр с такой же проблемой, налоговый, с ним такой фокус не прошел и тут нам помог второй случай.
2. Внешний спец подкидывал идей что и как надо сделать для решения проблемы, но ни чего не помогало. Взяв ту же копию базы где работал второй спец я начал анализировать технологический журнал, из него выяснил что после пересчета декабря процесс просто зависал, точнее не продолжался, складывалось ощущение что он уходил в ожидание. Начал смотреть profiler, там картина аналогичная, запрос просто не продолжался. Через запрос
Sel ect * Fr om master.dbo.sysprocessesexec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'Что бы сразу отвести обвинения и упреки что базу надо обслуживать и настраивать регламентные задания, то все это настроено и обновление статистики происходит каждый день, только из за объема базы мы используем обновление не полное а выборочное.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Устранили мы свою проблему. Использовали два метода, но скорей всего надо было всего лишь второй метод и все решилось бы.
Решение:
1. После того как перепробовали все варианты по пересчету итогов решили обратится за помощью к сторонним спецам (от безысходности). Первый, так же как и мы, ни чего не смог сделать. У второго человека все получилось, но был нюанс, он производил работы на другом SQL сервере. Это нас натолкнуло на мысль попробовать боевую базу (он выполнял работы на копии восстановленной из последнего бэкапа) перенести на другой SQL сервер. Т.к. база и лог располагались на подмапленных дисках, то переподключение их не составило особого труда. И случилось чудо, регистр бухгалтерии хозрасчетный пересчитался без каких либо проблем, но у нас был второй регистр с такой же проблемой, налоговый, с ним такой фокус не прошел и тут нам помог второй случай.
2. Внешний спец подкидывал идей что и как надо сделать для решения проблемы, но ни чего не помогало. Взяв ту же копию базы где работал второй спец я начал анализировать технологический журнал, из него выяснил что после пересчета декабря процесс просто зависал, точнее не продолжался, складывалось ощущение что он уходил в ожидание. Начал смотреть profiler, там картина аналогичная, запрос просто не продолжался. Через запрос я узнал что наш процесс висит с ожиданием SOS_SCHEDULER_YIELD. Данный тип ожидания означает что процесс ждет освобождение ресурсов ЦП. Через диспетчер задач увидел что количество потоков на ЦП увеличивается, не быстро, рабочая 1С в это время работала штатно, обмены ходили, пользователи выполняли свою рутинную работу и не жаловался. Начал гуглить решение по устранению этого типа ожидания и в итоге на одном из форумов по SQL человек описывал ситуацию где у него код, который несколько дней назад выполнялся за приемлемое время, вдруг перестал выполнятся вообще и начал уходить в ожидание SOS_SCHEDULER_YIELD. Ему там посоветовали сделать полное обновление статистики, что я и сделал на своей базу при помощи запроса . Полное обновление статистики на копии выполнялось 12 часов, на боевой 15, но проблему это устранило, регистр бухгалтерии налоговый пересчитался без проблем.
Что бы сразу отвести обвинения и упреки что базу надо обслуживать и настраивать регламентные задания, то все это настроено и обновление статистики происходит каждый день, только из за объема базы мы используем обновление не полное а выборочное.
Решение:
1. После того как перепробовали все варианты по пересчету итогов решили обратится за помощью к сторонним спецам (от безысходности). Первый, так же как и мы, ни чего не смог сделать. У второго человека все получилось, но был нюанс, он производил работы на другом SQL сервере. Это нас натолкнуло на мысль попробовать боевую базу (он выполнял работы на копии восстановленной из последнего бэкапа) перенести на другой SQL сервер. Т.к. база и лог располагались на подмапленных дисках, то переподключение их не составило особого труда. И случилось чудо, регистр бухгалтерии хозрасчетный пересчитался без каких либо проблем, но у нас был второй регистр с такой же проблемой, налоговый, с ним такой фокус не прошел и тут нам помог второй случай.
2. Внешний спец подкидывал идей что и как надо сделать для решения проблемы, но ни чего не помогало. Взяв ту же копию базы где работал второй спец я начал анализировать технологический журнал, из него выяснил что после пересчета декабря процесс просто зависал, точнее не продолжался, складывалось ощущение что он уходил в ожидание. Начал смотреть profiler, там картина аналогичная, запрос просто не продолжался. Через запрос
Sel ect * Fr om master.dbo.sysprocessesexec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'Что бы сразу отвести обвинения и упреки что базу надо обслуживать и настраивать регламентные задания, то все это настроено и обновление статистики происходит каждый день, только из за объема базы мы используем обновление не полное а выборочное.
Считаю своим долгом опубликовать удачное решение. Оно базировалось на текущем материале.
Проблема: в БП 3.0 есть свой дописанный регистр бухгалтерии "Бюджетный" с 5 субконто. Он перестал пересчитываться на 1.06.2020. Виснет и ничего не происходит, можно ждать сутки или двое... База размером 400 Гб.
Решение:
1. Получил список таблиц, обслуживающих регистры, в терминах 1С
Код:
2. Получил таблицу ТаблицаСтруктуры с именами (у вас будет своя):
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. Перенос итогов пошел, причем очень шустро. Проверил выборочно различные отчеты - все работает, как метеор.
Конец.
Проблема: в БП 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. Перенос итогов пошел, причем очень шустро. Проверил выборочно различные отчеты - все работает, как метеор.
Конец.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот