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

Question

Приветствую.
Убирали дату расчетов итогов для проведения работ (требования подрядчика), работы полностью выполнить подрядчику не удалось и при ближайшем закрытии месяца обнаружились неточности в БУ и НУ. Проанализировав цифры, выяснил что минуса идут от 28.02.0001 г. Начал двигать итоги к нужному месяцу, вопрос удалось решить. Но сейчас при закрытии года выяснилось что на февраль очень большой минус. Начали опять двигать итоги, но ни чего не получалось. Пробовали сбрасывать дату до 01.01.0001, но в итоги сейчас итоги считаются до 31.12.2016 г. и дальше не идут, что я только не делал дата не двигается. В администрировании серверов постоянно растет число в столбце "Захвачено СУБД". Ждали по несколько суток с остановкой работ в центральной базе, но толку ни какого. Что может будь не так? Почему не двигается дата итогов?
Данная проблема не может решится уже около двух недель.

Accepted Answer

Устранили мы свою проблему. Использовали два метода, но скорей всего надо было всего лишь второй метод и все решилось бы.
Решение:
1. После того как перепробовали все варианты по пересчету итогов решили обратится за помощью к сторонним спецам (от безысходности). Первый, так же как и мы, ни чего не смог сделать. У второго человека все получилось, но был нюанс, он производил работы на другом SQL сервере. Это нас натолкнуло на мысль попробовать боевую базу (он выполнял работы на копии восстановленной из последнего бэкапа) перенести на другой SQL сервер. Т.к. база и лог располагались на подмапленных дисках, то переподключение их не составило особого труда. И случилось чудо, регистр бухгалтерии хозрасчетный пересчитался без каких либо проблем, но у нас был второй регистр с такой же проблемой, налоговый, с ним такой фокус не прошел и тут нам помог второй случай.
2. Внешний спец подкидывал идей что и как надо сделать для решения проблемы, но ни чего не помогало. Взяв ту же копию базы где работал второй спец я начал анализировать технологический журнал, из него выяснил что после пересчета декабря процесс просто зависал, точнее не продолжался, складывалось ощущение что он уходил в ожидание. Начал смотреть profiler, там картина аналогичная, запрос просто не продолжался. Через запрос [CODE]Sel ect * Fr om master.dbo.sysprocesses[/CODE] я узнал что наш процесс висит с ожиданием SOS_SCHEDULER_YIELD. Данный тип ожидания означает что процесс ждет освобождение ресурсов ЦП. Через диспетчер задач увидел что количество потоков на ЦП увеличивается, не быстро, рабочая 1С в это время работала штатно, обмены ходили, пользователи выполняли свою рутинную работу и не жаловался. Начал гуглить решение по устранению этого типа ожидания и в итоге на одном из форумов по SQL человек описывал ситуацию где у него код, который несколько дней назад выполнялся за приемлемое время, вдруг перестал выполнятся вообще и начал уходить в ожидание SOS_SCHEDULER_YIELD. Ему там посоветовали сделать полное обновление статистики, что я и сделал на своей базу при помощи запроса [CODE]exec sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'[/CODE]. Полное обновление статистики на копии выполнялось 12 часов, на боевой 15, но проблему это устранило, регистр бухгалтерии налоговый пересчитался без проблем.

Что бы сразу отвести обвинения и упреки что базу надо обслуживать и настраивать регламентные задания, то все это настроено и обновление статистики происходит каждый день, только из за объема базы мы используем обновление не полное а выборочное.