Закрытие месяца выполняется неоправданно долго (несколько часов) на MSSQL

Дано:
Организация с довольно большим объемом операций по производству.
Закрытие месяца выполняется с каждым месяцем все дольше.
Период рассчитанных итогов меняем. Переиндексацию базы производим.  Различные версии MSSQL пробуем (2005/2008/2008R2). Не помогает или  помогает на 1 закрытие, потом опять медленно.
В файловом варианте закрытие работает приемлимо, но этот вариант не  подходит - повседневная работа встанет (около 20 одновременных  пользователей), да и объем скоро перейдет границы допустимого.
В вариант PostgreSQL закрытие работает хорошо, но в "боевых" условиях работа обычных пользователей не тестировалась.  
В тестовой базе на PostgreSQL поймали пока только один баг - при  дефолтных настройках обмен данными приводит к ошибке типа "слишком много  блокировок".
Вопросы:  
- встречалось ли у кого-нибудь подобное поведение закрытия месяца? Как боролись?
- есть ли примеры промышленного применения БП 2.0 под управлением PostgreSQL, какие есть нюансы и какие впечатления?

Версия платформы и конфигурации последние (проблема проявлялась и на предыдущих релизах)

- Какое время выполнения обработки закрытия в файловом и клиент-серверном варианте?
 - Что происходит с загрузкой "железа" в момент обработки на сервере 1С и сервере SQL (если это разные машины, то смотреть загрузку ресурсов на каждой).
 - Какие процедуры наиболее длительные показывает "Замер производительности"?

По-порядку
Самая тяжелая операция - Закрытие счетов 20, 23, 25, 26
На файловой версии выполняется около 20-25 минут при запуске с сервера (из локального каталога), на SQL - от примерно 20 минут до примерно 8 часов.
Прикладываю замер производительности (снимался на конфигурации БП 2.0.34.13, 1С 8.2.15.301, SQL 2008R2 SP1).
Это не сильно нагруженный сервер, тестовый, с параметрами близкими к реальному.
Закрытие идет без малого 2 часа, в какой процедуре проблема там видно.
Загрузка ресурсов: в этом варианте субд и сервер 1с стоят на одной машине, памяти им достаточно, процессор: загружено 1 ядро из 4 процессом SQL (25%+-2%).
То есть этот запрос вызывает коллапс у сервера субд, однако он в результате выполняется.
Я пытался провести дальнейший анализ, при каких параметрах начинаются тормоза. Думал, дело в отборе (одна и та же функция вызывается с отбором по списку номенклатуры и без) - диагноз не подтвердился. Дальнейших исследований не проводил.

Понятно. Тогда такие действия:

 - Обновить до последней версии (у вас несколько релизов не хватает).
 - Протестировать на последнем релизе.
 - Если проблемы сохраняются, то через отладчик "выдернуть" текст запроса, который там выполняется.
 - Текст запроса тестировать через Консоль запросов.
Кстати, при переходе на 15-ю платформу выполняли реструктуризацию данных через "Тестирование и исправление"?

Эх, жаль, а я думал что вот наконец дельный совет дадут
Обновить до последней версии - уже обновили но еще не запускали. Почти уверен что результат будет тот же - проблема тянется примерно с 2010 года, после накопления 1.5 лет работы в одной базе. Думаю, что в 1с об этой проблеме либо не знают, либо забили.
Обрезать базу каждый год можно не предлагать, иначе нам тоже что-нибудь отрежут.
Текст запроса можно получить хоть на демо базе, их там будет 2 если не ошибаюсь - с отбором и без. Только что это даст?
Насчет реструктуризации: где это написано?
"Конвертация конфигураций, информационных баз, внешних обработок и       внешних отчетов при переходе от версии 8.2.14 к версии 8.2.15 не требуется"
Но я точно знаю что база выгружалась и загружалась, думаю что это равносильно реструктуризации, даже если она предположительно нужна.
Еще раз повторю, проблема появилась гораздо раньше чем 8.2.15
Если других предложений нет, предлагаю на этом закончить.

> Эх, жаль, а я думал что вот наконец дельный совет дадут
> ...
> Насчет реструктуризации: где это написано?
> ...
> Если других предложений нет, предлагаю на этом закончить.

Несколько странная манера  просить о помощи таким способом?

> Обрезать базу каждый год можно не предлагать,
почему?
> иначе нам тоже что-нибудь отрежут.
и это единственная причина?

> > Обрезать базу каждый год можно не предлагать,
> почему?
Потому что, если база используется хоть для какого то анализа, то потеря предыдущих периодов ложет крест на это анализе!

ну, если "потеря"...! А если не "терять"? Или вы формируете оборотку за пятилетку?

Неужели анализ ведут только по оборотке? У нас по крайней мере анализируется 2-3 года.